The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →“Run Windows PowerShell scripts first at computer startup, shutdown” is a Windows Group Policy setting that changes script order on a computer. When enabled, applicable PowerShell scripts run before other applicable startup or shutdown scripts. It does not schedule scripts generally, change user logon processing, or bypass PowerShell’s execution policy.
To use it reliably, create a plain-text .ps1 file, register it in the computer’s startup or shutdown script configuration, verify that the effective execution policy permits it, and then enable the policy with the exact wording above. Policy-template wording and editor placement can vary by Windows version and ADMX template, so confirm those details in the templates installed in your environment.
As an Amazon Associate I earn from qualifying purchases.
What the policy actually controls
The setting controls the order of two kinds of computer-side processing:
Free tools Windows power users keep installed
One-click scans. No signup required.
- Startup: scripts run while Windows is starting the computer.
- Shutdown: scripts run while Windows is shutting the computer down.
With the setting enabled, Windows PowerShell scripts are processed before other applicable startup or shutdown scripts. The scope is the computer, not an individual user account. It is therefore separate from user logon and logoff script processing.
#1 Best Overall
This is an ordering preference, not a general-purpose scheduler. It does not create a script task, retry a failed script, make a script run when no startup or shutdown event occurs, or override permissions and execution-policy checks. If no PowerShell script is configured for the relevant event, enabling the setting has nothing to order.
Startup, shutdown, computer and user processing
These distinctions prevent the most common configuration mistake: enabling a computer startup policy while expecting a script to run when a user signs in.
| Question | What this setting does |
|---|---|
| When does it act? | During computer startup and computer shutdown processing. |
| What does it prioritize? | Applicable Windows PowerShell scripts before other applicable startup or shutdown script types. |
| Which policy side? | Computer policy; it is not a user logon-policy setting. |
| What does it not do? | It does not act as a general scheduler or replace execution-policy, signing, permissions, or trust controls. |
Prepare a script Windows can run
Use a .ps1 file
Microsoft describes a PowerShell script as a plain-text file with a .ps1 extension. Save the script with that extension rather than as a document format that adds hidden formatting or a second extension.
Recommended Free Tools
Test the file directly before putting it into startup or shutdown processing. From the directory containing the file, invoke it with an explicit relative path such as:
.[?25lStartup.ps1[?25hOn Windows PowerShell, the .[?25l prefix identifies a script in the current directory. You can also call the script by its full path. An explicit path avoids ambiguity about whether PowerShell should treat a command name as a script file.
Rank #2
Check what the script needs
Startup and shutdown are constrained environments. Before relying on ordering, identify whether the script depends on a network connection, a service that may not yet be available, or an interactive desktop. Those dependencies affect whether a correctly ordered script can complete successfully. Keep the script’s required resources and expected timing documented with the policy assignment.
Find and enable the Group Policy setting
The exact location and wording presented in a policy editor depend on the Windows version and the ADMX templates installed by your organization. Use the setting’s complete name as the search term: Run Windows PowerShell scripts first at computer startup, shutdown.
- Open the Group Policy editor used for the target computer: the Local Group Policy Editor for a standalone machine, or the Group Policy Management Editor for a domain-managed computer.
- Select the computer side of policy editing. Do not configure a user logon or logoff script area for this startup/shutdown requirement.
- Search the installed administrative templates for Run Windows PowerShell scripts first at computer startup, shutdown. If the label or location differs, verify that the ADMX template matches the Windows edition and version you administer.
- Open the policy, set it to Enabled, and apply the change.
- In the computer startup/shutdown script configuration exposed by your templates, add the relevant
.ps1file and provide its path. Keep the path stable and accessible during the event for which it is configured. - Apply the computer policy through your organization’s normal Group Policy refresh and change-control process, then test a controlled restart or shutdown.
Enabling the ordering policy without adding a PowerShell script does not produce any visible action. Conversely, adding a script without confirming the ordering policy leaves Windows to use its normal processing order.
Execution policy: the gate that ordering cannot bypass
PowerShell’s execution policy determines whether script files may run. Microsoft documents Restricted as allowing individual commands while preventing script files. Microsoft’s current Windows PowerShell documentation describes RemoteSigned as the Windows default: local scripts may run, while scripts downloaded from the internet require a signature unless they have been unblocked.
| Execution-policy value or scope | Operational meaning |
|---|---|
| Restricted | Individual commands are permitted, but script files are blocked. |
| RemoteSigned | Local scripts are permitted; downloaded scripts require signatures unless they are unblocked. |
| Process | Process-level scope. When Group Policy does not define a policy, it is the highest scope in the documented order. |
| CurrentUser | User-level scope used in the documented order when Group Policy does not define a policy. |
| LocalMachine | Computer-local scope used after Process and CurrentUser when Group Policy does not define a policy. |
| MachinePolicy | Computer Group Policy scope. It takes precedence over local settings. |
| UserPolicy | User Group Policy scope. It takes precedence over local settings. |
Inspect the effective configuration before changing anything:
Get-ExecutionPolicy -ListThis command displays every scope, including Group Policy scopes. The documented local order is Process, then CurrentUser, then LocalMachine when Group Policy does not define a policy. If MachinePolicy or UserPolicy is set, Group Policy takes precedence. A local Set-ExecutionPolicy command can report success while the effective policy remains unchanged because a higher-precedence Group Policy scope overrides it.
Windows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallCrashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteDo not treat the startup-order setting as an execution-policy exception. If the effective policy blocks the file, putting PowerShell first does not make the file executable. Resolve the policy conflict through the administrative scope that controls it, rather than assuming a local change will win.
Why a startup PowerShell script may not run
The script is in the wrong policy area
A computer startup script is different from a user logon script. Confirm that the file is assigned to computer startup or shutdown processing and that you are editing computer policy, not user policy.
The file is not a PowerShell script
Check the complete filename. It must be a plain-text .ps1 file. A file that appears to end in .ps1 but actually ends in another extension will not be treated as the intended script.
The path is ambiguous or unavailable
Test the script with its full path or with .[?25lStartup.ps1[?25h from its directory. Then verify that the startup or shutdown assignment points to the same file and that the path remains available during the event. A script that relies on a network location can fail if the network is not ready; one that calls a service can fail if that service has not started.
Rank #4
- Book - powershell for sysadmins: workflow automation made easy
- Language: english
- Binding: paperback
The effective execution policy blocks it
Run Get-ExecutionPolicy -List and inspect all scopes. Restricted blocks script files. If a Group Policy scope is populated, changing LocalMachine or another local scope will not override it.
The script expects an interactive desktop
Startup and shutdown processing is not the same as launching a script from a user’s PowerShell window. Remove prompts and desktop-only assumptions, and make the script’s required inputs and outputs explicit. If an operation needs user interaction, it belongs in a user-session design rather than an unattended startup/shutdown path.
The ordering policy is enabled but the result is unchanged
The policy only changes relative order. It does not guarantee that a script will finish before an external dependency becomes available, nor does it add retries or error handling. Check the script’s own exit behavior and its dependencies, then test the relevant event again.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Designing the order you actually need
Use startup ordering for prerequisites
Place a PowerShell script first when later startup scripts depend on a preparation step that the PowerShell script performs. Keep that dependency one-directional and documented: identify what the first script creates or configures and what later scripts consume.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Scan for outdated or missing drivers - takes under a minute3Clear out junk files and repair common Windows errorsUse shutdown ordering for cleanup
For shutdown, define what must be captured or stopped before other shutdown scripts run. Avoid assuming that a resource available during normal operation will remain available until the final shutdown stage.
Best Value
Keep scripts repeatable
A startup event can occur more than once over the life of a computer, and administrative testing may run the script repeatedly. Write operations so that an already-created setting, directory, or configuration does not cause an avoidable failure. Record meaningful errors where administrators can retrieve them without relying on an interactive window.
Separate ordering from trust
Use trusted script sources, review changes, limit permissions, and apply signing or other enterprise controls appropriate to the environment. Ordering answers “which applicable script is processed first”; it does not answer “whether this script is safe.”
Security limits and administrative safeguards
Microsoft’s exact warning is: The execution policy isn’t a security boundary, it’s defense in depth.
That warning applies here. Execution policy can reduce accidental execution and enforce administrative conventions, but it is not a complete malware-control mechanism. The startup-order policy is even narrower: it changes processing order and supplies no independent trust decision.
- Review the script contents and its source before assigning it to computers.
- Use the least privilege compatible with the task.
- Prefer signed or otherwise controlled scripts when your organization’s process requires it.
- Audit both the policy assignment and the effective execution-policy scopes.
- Test startup and shutdown behavior on a representative computer before broad deployment.
A practical verification checklist
- Confirm the requirement is computer startup or shutdown, not user logon or logoff.
- Confirm the file is plain text with a
.ps1extension. - Run it manually with an explicit path and correct any script errors first.
- Check whether the script depends on network access, services, or an interactive desktop.
- Assign the file in the computer startup or shutdown script configuration.
- Enable Run Windows PowerShell scripts first at computer startup, shutdown in the matching administrative template.
- Run
Get-ExecutionPolicy -Listand resolve any blocking or higher-precedence Group Policy scope. - Test the actual startup or shutdown event and review the script’s observable results.
What to remember
This Group Policy option is a narrowly scoped ordering control. It makes applicable PowerShell scripts run before other applicable computer startup or shutdown scripts, but it does not schedule scripts, convert user logon scripts into startup scripts, or override execution policy. Reliable deployment depends on an explicit .ps1 path, a matching computer-policy assignment, an effective execution policy that permits the file, and a script designed for the resources available during startup or shutdown.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
