RunOnce is a default windows function that could be used to have scripts survive a reboot.

As an engineer that works for a MSP, I tend to come into many different situations and networks for different companies. During most of this work I’ve found that scripting is key to maintaining a healthy network and minimizing workloads for our first line support. We tend to use MSP-aimed tooling to make sure we are able to deploy these scripts to clients and servers and have a central location and storage for these scripts. That way everyone always works with the same version of a script and we only have to preform maintenance on a single location.

the only issue about some of these scripts is that they have to run as multi-tiered scripts. an example would be the installation of .NET followed by a back-end application that requires .NET to be installed prior to booting(e.g. Exact Globe software). To resolve this you could choose to use Powershell remoting and create a workflow, but this requires the machine to be accessible remotely, something that could prove difficult if a client only has a single server.

the solution is actually very straight forward, Split your script into 2 files(or even 10 if you require it) and use the RunOnce registry key at the end of your script to kickoff the next script.

Example Powershell:

1
2
3

Write-Host "Changing RunOnce script." -foregroundcolor "magenta"
$RunOnceKey = "HKLM:\Software\Microsoft\Windows\CurrentVersion\RunOnce"
set-itemproperty $RunOnceKey "NextRun" ('C:\Windows\System32\WindowsPowerShell\v1.0\Powershell.exe -executionPolicy Unrestricted -File ' + "C:\Tempscript\TempScript2.ps1")

Example VBScript:

1
2
3

set ObjectShell = WScript.CreateObject("WScript.Shell")
strRunOnce = "HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunOnce\TempScript"
ObjectShell.RegWrite strRunOnce, "cscript c:\tempscript\tempscript2.vbs", "REG_SZ"

I’ve seen several other engineers point out that RunOnce should be used carefully and I agree partly – On client machines it could cause unexpected behavior as users don’t necessarily have all the permissions required for installations, or a different user logs onto the system than the one that wanted to run the script.

Another solution is using DSC, Which is higher maintenance but sometimes more accurate.

On Servers where you mostly control who logs on and at what times, So I believe these RunOnce scripts to be one of the best to survive reboots, DCS’s are bit more of a hack to maintain – Next to Powershell remoting of course 😉