To ensure a PowerShell script or executable runs automatically at Windows startup, the most reliable method is creating a Scheduled Task in the Task Scheduler. This approach bypasses common limitations of the Startup folder and allows for precise control over execution privileges, timing, and error handling. By configuring the task to trigger on system boot with elevated permissions, you guarantee that your automation executes consistently every time the machine starts.
Why Use Task Scheduler Instead of Startup Folders
Placing a shortcut in the
C:\Users\\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup directory is simple but often fails for scripts requiring administrative privileges or specific environment contexts. Many modern security policies restrict what can run from this location without explicit user interaction. The Task Scheduler provides a more robust framework because it can be configured to run under the SYSTEM account or the logged-in user, regardless of whether the window is visible. Additionally, tasks can be set to delay start, retry on failure, and log events, which are critical features for maintaining stable background processes.
Creating the Scheduled Task via GUI
For users who prefer a graphical interface, the Task Scheduler offers a straightforward wizard. Open the Start menu, search for "Task Scheduler," and select the application. In the right-hand Actions pane, click "Create Basic Task." Give your task a descriptive name, such as "Run MyScript At Boot," and an optional description. When prompted for the trigger, select "When the computer starts." This ensures the task initiates immediately after the operating system loads, before any user logs in if desired.
Next, choose the action type. Select "Start a program" and browse to the path of your
.exe file or PowerShell executable. If you are running a PowerShell script, do not select the script directly. Instead, select
powershell.exe located in
C:\Windows\System32\WindowsPowerShell\v1.0\. In the "Add arguments" field, enter the command line needed to execute your script, such as
-ExecutionPolicy Bypass -File "C:\Path\To\Script.ps1". This argument combination ensures that script signing restrictions do not block execution during the automated process.
Finally, check the box labeled "Open the Properties dialog for this task when I click Finish." This step is crucial because it allows you to configure advanced settings immediately. In the General tab, ensure "Run whether user is logged on or not" is selected. You may also need to check "Run with highest privileges" if your script requires administrative rights. In the Conditions tab, uncheck "Start the task only if the computer is on AC power" to allow execution on laptops running on battery. Save the changes and provide administrator credentials if prompted.
Automating Task Creation with PowerShell
For IT administrators or developers managing multiple machines, using a PowerShell script to create the task programmatically is more efficient. This method ensures consistency across environments and avoids manual configuration errors. You can use the
New-ScheduledTaskAction,
New-ScheduledTaskTrigger, and
New-ScheduledTaskSettingsSet cmdlets to define the behavior.
The following example demonstrates how to create a task that runs a PowerShell script at startup with elevated privileges:
$Action = New-ScheduledTaskAction -Execute "powershell.exe" -Argument "-NoProfile -ExecutionPolicy Bypass -File C:\Scripts\MyTask.ps1"
$Trigger = New-ScheduledTaskTrigger -AtStartup
$Settings = New-ScheduledTaskSettingsSet -AllowStartIfOnBatteries -DontStopIfGoingOnBatteries -StartWhenAvailable
$Principal = New-ScheduledTaskPrincipal -UserId "SYSTEM" -LogonType ServiceAccount -RunLevel Highest
Register-ScheduledTask -TaskName "MyAutomationTask" -Action $Action -Trigger $Trigger -Settings $Settings -Principal $Principal
This script registers a task named "MyAutomationTask." It uses the SYSTEM account for maximum compatibility and ensures the task does not stop if the device switches power modes. Note that running tasks as SYSTEM means the script cannot access user-specific profiles or network drives mapped to a specific user. If user context is required, change the
-UserId parameter to
"NT AUTHORITY\INTERACTIVE" or a specific username.
Troubleshooting Common Issues
Even with correct configuration, tasks may fail silently. First, verify the execution policy by checking the event viewer for errors related to script signing. If the task fails to start, ensure the file paths in both the GUI and PowerShell methods are absolute and do not contain spaces without proper quoting. For PowerShell scripts, always include
-NoProfile to prevent initialization scripts from interfering with the task's environment.
Another frequent issue is the task waiting indefinitely for user input. Ensure that your script or executable is designed to run non-interactively. If your script opens a GUI window, consider using
-WindowStyle Hidden in PowerShell to prevent blocking the startup sequence. For further details on managing interruptions in Windows 11, refer to our guide on
Stopping a Windows 11 PowerShell Script Task in Task Scheduler.
Additionally, if you are trying to keep the terminal window visible or on top, standard startup tasks will hide the console by default. To achieve visibility, you must modify the task properties to allow interactive sessions or use specific window management techniques. See
Keeping PowerShell Terminal Windows On Top During Startup for those specific configurations.
Frequently Asked Questions
Can I run a PowerShell script without installing it as a service?
Yes, using the Task Scheduler is the preferred method for running scripts without converting them into full Windows services. Services require more complex setup and debugging overhead, whereas scheduled tasks are lightweight and easy to modify through the GUI or PowerShell.
Why does my task fail when I am not logged in?
This usually happens because the task is configured to run only when the user is logged on. In the task properties, under the General tab, select "Run whether user is logged on or not." This allows the task to execute in the background using the SYSTEM account or a specified user account, independent of active sessions.
How do I pass arguments to an .exe file in the scheduler?
In the "Edit Task" window, locate the "Add arguments (optional)" field next to the program path. Enter any required flags or parameters here. For example, if your executable needs a config file, add
--config C:\path\to\config.json in this field.
Is it safe to run tasks as the SYSTEM account?
Running as SYSTEM provides broad permissions but limits access to user-specific resources like the desktop or user profile folders. Only use SYSTEM if your script performs system-wide operations. For user-specific tasks, assign the task to the specific user account instead.
How can I view the output of a scheduled task?
Scheduled tasks do not display output by default. To capture results, redirect output in your script to a log file using
Out-File or
> redirection. You can also check the "History" tab in the Task Scheduler to see success or failure status codes.