PowerShell: Using RunOnce to have script survive reboot

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:

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:

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 😉

Recent Articles

Automating with PowerShell: making stolen tokens useless with Global Secure Access

Last week I watched Merill Fernando talk to Alex Pavlovsky and Marilee Tuscak from the Entra team about something I’d kinda put under the “needs a GSA licence” branch and i’d check it out later, turns out that like most people, I half-assed the documentation and it turns out it doesn’t. There’s two features that come with any P1 license; Compliant network check and Source IP Restoration. So BP, P1, or even frontline worker licenses already have this.

CIPP ❤️ #IntuneForMSPs

We’re Joining #IntuneForMSPs 🎉

Being invited by Microsoft to join a global initiative is a big moment for us, and we want to be clear about why it matters. #IntuneForMSPs is Microsoft’s program to help MSPs deliver Microsoft 365, Intune, and Copilot services at scale, and CIPP is now part of it, bringing the largest MSP community in the channel directly to Microsoft.

The return of CyberDrain CTF

CyberDrain CTF returns! (and so do I!)

It’s been since september that I actually picked up a digital pen equivalent and wrote anything down. This was due to me being busy with life but also my side projects like CIPP. I’m trying to get back into the game of scripting and blogging about these scripts. There’s still so much to automate and so little time, right? ;)