Use PowerShell to Create Job that Runs at Startup

Summary: Microsoft Scripting Guy, Ed Wilson, talks about creating a job that runs at startup.

Microsoft Scripting Guy, Ed Wilson, is here. One of the needs that never seems to change is the need to run a startup script. In the old days, that meant placing a .bat or .vbs file in a startup folder, or listing it in the RUN key in the user folder. But those techniques do not work with Windows PowerShell scripts. That is because, by default, the .ps1 file extension is not associated with PowerShell.exe, but rather, with the ISE or Notepad. Of course you can change this, but it is not recommended. In Windows PowerShell 1.0, the technique seemed to be to use a .bat file, or less often, use a .vbs file to launch a Windows PowerShell script. That worked, but it was a kludge.

Beginning with Windows PowerShell 3.0, with Windows PowerShell scheduled jobs, it is possible to natively and easily create a Windows PowerShell startup script (and one that does not rely on Group Policy).

A few steps are required to create a Windows PowerShell script that runs at startup as a Windows PowerShell scheduled job:

1. Open the Windows PowerShell console with admin rights.
2. Create a new job trigger and specify the type as a startup trigger.
3. Specify a short random interval for the startup trigger to prevent race conditions at startup.
4. Create the new scheduled job and specify the job trigger and the full path to the startup script.

Create the job trigger

To create the job trigger, open the Windows PowerShell console with admin rights by right clicking the Windows PowerShell icon on the Start page or from the task bar, and then choosing Run as Administrator from the action menu.

Use the New-JobTrigger cmdlet to create a startup trigger. To do this, select the –AtStartup parameter. It is a good idea to specify a random delay period of 30 seconds to one a minute to help to avoid race conditions at startup. This will also help ensure a greater chance of success for the job. Store the returned trigger object in a variable. I like to call this variable $trigger as shown here:

$trigger = New-JobTrigger -AtStartup -RandomDelay 00:00:30

Create the scheduled job

Use the Register-ScheduledJob cmdlet to create a scheduled job. The trigger that you stored in the $trigger variable specifies when the script will run. In this case, at startup. Make sure to specify the complete path to the script that will run, and also ensure that the file will be accessible when the script runs. Specify a unique and descriptive name for the scheduled job, and press ENTER. The command is shown here:

Register-ScheduledJob -Trigger $trigger -FilePath C:\fso\Get-BatteryStatus.ps1 -Name GetBatteryStatus

Check the script

Make sure that the script is something that will run ok as a scheduled job. In general, that means a script that will not expose any GUI components. It also means that it is a script that can run in the context of the account that will run the scheduled job, that the job will have access to the script, and that it can be found.

For example, a script stored in a network shared folder, might not be the best choice if your network links are slow coming up. I like a script that records the data in a text file, event log, a database, or something like that. In the following script, the results of a WMI query are stored in a text file in the same folder that contains the script:

Check status of the job

After rebooting my laptop and signing in, I use the Get-Job cmdlet to check the status of the scheduled job. The command is simple, and as shown here, the output tells me that the job completed:

I go to my output folder and look for the text file. In the end, the presence of the text file is the best indicator that the scheduled job worked properly. The file I found is shown here:

That is all there is to using Windows PowerShell to create a scheduled job that runs at startup. Windows PowerShell Scheduled Job Week will continue tomorrow when I will talk about advanced scheduled jobs.

I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.

Ed Wilson, Microsoft Scripting Guy