Continuing PowerShell Scripts After Reboot - How to do it?
In some cases, you may have to continue the execution of a certain PowerShell script after a device reboot. This applies to both local and remote execution environments.
In this article, we’ll look at different possibilities for continuing a PowerShell script after a reboot.
Using Task Scheduler for Local Computers

We can use the Task Scheduler, a utility that is already installed on all Windows devices, in the local computer environment, which means the script is executed locally on the device.
When you open the Task Scheduler, you may notice some predefined schedules for first- and third-party applications such as Microsoft Edge, Google Chrome, and Firefox.

In this example, we can see that during installation, Google Chrome is setting up a task scheduler to run this:
“"C:\Program Files (x86)\Google\GoogleUpdater\143.0.7482.0\updater.exe"”
This is how Google Chrome checks constantly for updates. This happens not only on a daily basis but also when a user logs in. Firefox, Microsoft Edge, and other third-party apps do the same thing.
In our case, we want to set up a task that runs a PowerShell script after a system restart so you don’t have to restart the script manually.
Example 1: Run a Script Block After Reboot

In this example, let’s assume that you only want a certain command or script block to be executed after reboot. The code below performs the following:
# Initial actions
Write-Host "Performing initial actions before reboot..."
# Command to run a script block upon reboot
$scriptBlock = {
Write-Host "This is the continuation after reboot."
}
# Convert script block to a Base64 encoded string to pass it to the scheduled task
$encodedCommand = [Convert]::ToBase64String([Text.Encoding]::Unicode.GetBytes($scriptBlock.ToString()))
# Creating the scheduled task
$action = New-ScheduledTaskAction -Execute 'Powershell.exe' -Argument "-EncodedCommand $encodedCommand"
$trigger = New-ScheduledTaskTrigger -AtStartup
Register-ScheduledTask -Action $action -Trigger $trigger -TaskName "ContinueAfterReboot" -Description "My task to continue script execution after reboot"
# Restart the computer (uncomment in actual use)
Restart-ComputerEssentially, we store the script block in a variable, encode it to base64, and then create the task schedule.
The task will include the action of running PowerShell.exe with the encoded script block. From a trigger perspective, this is where the magic happens. As you can see, the Task Scheduler’s trigger will be -AtStartup, which means it will run after the computer is rebooted.
When the system starts up, the task triggers, launching PowerShell with the encoded script block as an argument, effectively resuming the script's execution exactly where you want it to.

Example 2: Run the Same or Another Script Based on a Registry Key

If your script is much more complex, or if you want to run another PowerShell script after the reboot, then we’ll need to adjust the task schedule.
The updated code will look like this:
# Check for the registry key to determine if this is the initial run or continuation
if (Test-Path -Path "HKCU:\Software\Test\ISRun") {
# This is a continuation after reboot
Write-Host "Continuing with the next part of the script..."
# Perform the next part of the script...
# Clean up: Remove the registry key and scheduled task if no longer needed
Remove-Item -Path "HKCU:\Software\Test\ISRun"
Unregister-ScheduledTask -TaskName "ContinueAfterReboot" -Confirm:$false
}
else {
# This is the initial run
Write-Host "Performing initial actions..."
# Set a registry key to indicate the script has run
New-Item -Path "HKCU:\Software\Test" -Force
New-ItemProperty -Path "HKCU:\Software\Test" -Name "ISRun" -Value "true" -PropertyType "String" -Force
# Schedule this script to run after reboot
$action = New-ScheduledTaskAction -Execute 'Powershell.exe' -Argument "-File `"$PSScriptRoot\$(Split-Path -Path $MyInvocation.MyCommand.Path -Leaf)`""
$trigger = New-ScheduledTaskTrigger -AtStartup
Register-ScheduledTask -Action $action -Trigger $trigger -TaskName "ContinueAfterReboot" -Description "Task to rerun the script after reboot"
# Restart the computer (uncomment in actual use)
Restart-Computer
}So, what is happening here? This logic can be a little tricky, so allow me to explain:
- First, we check if a certain registry key exists in: "HKCU:\Software\Test\ISRun"
- If the key exists, then it means that the script was already executed, so we continue to delete the registry key and the scheduled task created by the script
- If the registry key does not exist, we use the ELSE statement, which implies that this is the first time the script has been executed, and:
- We create the above registry key to notify the script on the next run that it has already executed and doesn’t need to perform the actions again.
- In the same statement, we create the Task Scheduler to run PowerShell.exe and pass the location of the PowerShell script we want to run as arguments.
- We set the Task Scheduler again to -AtStartup to ensure it executes after reboot.
Using Restart-Computer for Remote Computer

The Restart-Computer -Wait command makes restarting remote computers easier. This command instructs your script to wait for the computer to restart before moving ahead.
Here's how you can use it:
Restart-Computer -ComputerName "RemotePC1", "RemotePC2" -Wait -For PowerShell -Timeout 600 -Delay 2
The Restart-Computer cmdlet, which includes the -Wait parameter, can be used to manage reboot and continue operations for remote computers. This parameter pauses the script's execution until the specified remote computers have completed their restart process.
However, keep in mind that, according to the Microsoft documentation, the -Wait parameter does not apply when restarting the local machine. If you include both remote and local computer names in the ComputerName parameter, the cmdlet returns a non-terminating error for the local machine while waiting for the remote machines to reboot.
This command restarts RemotePC1 and RemotePC2, then waits up to 600 seconds (10 minutes) for them to restart and continue running the script, checking in every two seconds to see if they're back online.
Final Takeaways

- PowerShell script continuity after a device restart becomes absolutely possible once you understand how PowerShell interacts with startup triggers and scheduled tasks.
- Task Scheduler provides a simplistic method for local automation, especially when using encoded commands or script blocks that take effect at system startup.
- Registry-based logic creates a simple state machine that helps your script understand whether it is on its first run or returning after a reboot
- Remote devices can rely on Restart-Computer with the -Wait parameter to pause execution until the machines are on.
Conclusion

You can use these methods to automate tasks that need a restart without manual intervention.
Whether you're deploying software updates or making system changes, these techniques ensure that your PowerShell scripts continue execution seamlessly after a reboot, making the process smoother and more efficient.
Continuing PowerShell Scripts After Reboot FAQ
How can the Windows Task Scheduler be utilized in a PowerShell script to ensure it continues execution after a system reboot?

By creating a scheduled task with New-ScheduledTaskAction and New-ScheduledTaskTrigger, encoded in Base64, and registered with Register-ScheduledTask to run at system startup, ensuring the script resumes post-reboot.
How can a PowerShell script determine if it is running for the first time or continuing after a reboot, and what method does it use to handle this scenario?

The script checks a registry key. If the key exists, it's a continuation post-reboot; if not, it's the first run. It sets the key during the first run, schedules itself to rerun, and removes the key upon completion after reboot.
How can a PowerShell script determine if it is running for the first time or continuing after a reboot, and what method does it use to handle this scenario?

The script checks a registry key. If the key exists, it's a continuation post-reboot; if not, it's the first run. It sets the key during the first run, schedules itself to rerun, and removes the key upon completion after reboot.
