ANAVEM
Reference
Languagefr
How to Execute PowerShell Scripts at Windows Startup Using Group Policy

How to Execute PowerShell Scripts at Windows Startup Using Group Policy

Configure Group Policy Objects in Windows Server 2025 to automatically run PowerShell scripts when Windows 11 computers start up in an Active Directory domain environment.

Emanuel DE ALMEIDAEmanuel DE ALMEIDA
3/16/2026 15 min 0
mediumgroup-policy 8 steps 15 min

Why Use Group Policy for PowerShell Startup Scripts?

Managing startup scripts through Group Policy Objects provides centralized control over script execution across your Windows domain environment. Instead of manually configuring each computer or relying on local startup folders, GPO-based startup scripts ensure consistent execution, centralized management, and proper security controls.

In Windows Server 2025 and Windows 11 24H2 environments, PowerShell startup scripts executed via Group Policy run with SYSTEM privileges before user logon, making them ideal for system configuration tasks, software installations, network drive mappings, and security policy enforcement. The scripts execute reliably across all domain-joined computers without requiring local administrator intervention on each machine.

What Are the Key Benefits of GPO Startup Scripts?

Group Policy startup scripts offer several advantages over alternative approaches. They provide centralized deployment from a single location, automatic execution on every startup, consistent timing before user logon, and integration with Active Directory security groups for targeted deployment. Unlike logon scripts that run in user context, startup scripts have full system access and can perform administrative tasks that require elevated privileges.

The PowerShell Scripts tab in Group Policy Management, introduced in recent Windows versions, provides better execution control compared to traditional batch scripts, including proper error handling, execution policy management, and integration with Windows PowerShell's security features.

How Does Script Execution Timing Work in Windows 11?

Understanding the startup sequence is crucial for reliable script execution. Windows 11 processes Group Policy computer settings during startup, before user logon begins. The configured timing delays ensure network connectivity is established and domain controllers are accessible before script execution starts. This prevents common failures where scripts attempt to access network resources before the network stack is fully initialized.

Modern Windows environments benefit from the enhanced Group Policy processing in Windows Server 2025, which provides better handling of slow network connections and improved synchronization between policy application and script execution timing.

Implementation Guide

Full Procedure

01

Prepare Your PowerShell Script and Copy to SYSVOL

First, create your PowerShell script and place it in a location accessible to all domain computers. The SYSVOL share is the standard location for Group Policy scripts.

Create a test script to verify the process works:

# Create test script content
$scriptContent = @'
# Startup Script Test
$timestamp = Get-Date -Format "yyyy-MM-dd HH:mm:ss"
$computerName = $env:COMPUTERNAME
$logMessage = "$timestamp - Startup script executed on $computerName"

# Write to Event Log
Write-EventLog -LogName Application -Source "Application" -EventId 1001 -EntryType Information -Message $logMessage

# Create log file
$logPath = "C:\Windows\Temp\startup_script.log"
Add-Content -Path $logPath -Value $logMessage
'@

# Save script to local file
$scriptContent | Out-File -FilePath "C:\temp\startup-test.ps1" -Encoding UTF8

Copy the script to the SYSVOL location on your domain controller:

copy "C:\temp\startup-test.ps1" "C:\Windows\SYSVOL\sysvol\yourdomain.com\scripts\startup-test.ps1"

Set proper permissions for the script file:

icacls "C:\Windows\SYSVOL\sysvol\yourdomain.com\scripts\startup-test.ps1" /grant "Domain Computers:(RX)"
Pro tip: Always test your PowerShell script manually before deploying via GPO. Use the NETLOGON share path for simpler UNC references: \\%LogonServer%\NETLOGON\script.ps1

Verification: Confirm the script exists and is accessible by running dir \\yourdomain.com\NETLOGON\startup-test.ps1 from a domain computer.

02

Open Group Policy Management Console and Create New GPO

Launch the Group Policy Management Console to create a new Group Policy Object for your startup script.

Open GPMC as a domain administrator:

gpmc.msc

Navigate to your domain in the console tree and create a new GPO:

  1. Expand your domain (e.g., yourdomain.com)
  2. Right-click on Group Policy Objects
  3. Select New
  4. Enter a descriptive name: PowerShell Startup Scripts
  5. Click OK

The new GPO will appear in the Group Policy Objects container. This GPO is created but not yet linked to any organizational unit, so it won't affect any computers yet.

Warning: Don't link the GPO to the domain root until you've fully configured and tested it. Start with a test OU containing only a few computers.

Verification: Confirm the new GPO appears in the Group Policy Objects list with the name you specified.

03

Configure PowerShell Startup Script in GPO Settings

Edit the newly created GPO to add your PowerShell startup script configuration.

Right-click your new GPO and select Edit. This opens the Group Policy Management Editor. Navigate to the startup scripts section:

  1. Expand Computer Configuration
  2. Expand Policies
  3. Expand Windows Settings
  4. Click on Scripts (Startup/Shutdown)
  5. Double-click Startup

In the Startup Properties dialog, click the PowerShell Scripts tab (not the Scripts tab). This is specifically for PowerShell scripts and provides better execution control.

Add your script:

  1. Click Add...
  2. In the Script Name field, enter the UNC path: %LogonServer%\NETLOGON\startup-test.ps1
  3. Leave Script Parameters blank unless your script requires specific parameters
  4. Click OK

Your script now appears in the PowerShell Scripts list. You can use the Up and Down buttons to control execution order if you have multiple scripts.

Pro tip: Use the %LogonServer% variable instead of hardcoding the domain controller name. This ensures the script works even if clients authenticate against different DCs.

Verification: The script should appear in the PowerShell Scripts list with the correct path. Click OK to save the configuration.

04

Configure PowerShell Execution Policy via Group Policy

Windows 11 has a default PowerShell execution policy of Restricted, which blocks script execution. Configure the execution policy through Group Policy to allow your startup scripts to run.

In the same Group Policy Management Editor, navigate to the PowerShell execution policy settings:

  1. Go to Computer Configuration
  2. Expand Policies
  3. Expand Administrative Templates
  4. Expand Windows Components
  5. Click on Windows PowerShell
  6. Double-click Turn on Script Execution

Configure the execution policy:

  1. Select Enabled
  2. In the Execution Policy dropdown, choose Allow local scripts and remote signed scripts (RemoteSigned)
  3. Click OK

This policy allows locally stored scripts to run while requiring remote scripts to be digitally signed, providing a good balance of security and functionality.

Warning: Never set the execution policy to Unrestricted in a production environment. RemoteSigned provides adequate security while allowing your domain-based startup scripts to execute.

Alternative method: If you prefer not to change the execution policy globally, you can modify your script configuration in Step 3 to use the Scripts tab instead of PowerShell Scripts tab, with these parameters:

Script Name: %windir%\System32\WindowsPowerShell\v1.0\powershell.exe
Script Parameters: -ExecutionPolicy Bypass -File "%LogonServer%\NETLOGON\startup-test.ps1"

Verification: The policy should show as Enabled with RemoteSigned selected in the Group Policy Editor.

05

Configure Startup Script Timing and Delays

Configure timing settings to ensure the network is ready before your PowerShell script executes. This prevents common failures due to network services not being available at startup.

In the Group Policy Management Editor, navigate to the startup timing policies:

  1. Go to Computer Configuration
  2. Expand Policies
  3. Expand Administrative Templates
  4. Expand System
  5. Click on Group Policy

Configure the startup policy processing wait time:

  1. Double-click Specify startup policy processing wait time
  2. Select Enabled
  3. Set the wait time to 60 seconds (or 120 for slower networks)
  4. Click OK

Configure the logon script delay:

  1. Double-click Configure Logon Script Delay
  2. Select Enabled
  3. Set the delay to 1 minute (60 seconds)
  4. Click OK

These settings ensure that:

  • The system waits for network connectivity before processing Group Policy
  • Scripts have adequate time to execute before user logon begins
  • Network resources are available when your script runs
Pro tip: For environments with slow WAN links or wireless connections, increase the startup wait time to 120 seconds to prevent script execution failures.

Verification: Both policies should show as Enabled with your specified time values in the Group Policy Editor.

06

Link GPO to Target Organizational Unit

Link your configured GPO to an organizational unit to apply it to specific computers. Start with a test OU before applying to production systems.

In the Group Policy Management Console, navigate to your target OU:

  1. Expand your domain
  2. Navigate to the OU containing your test computers (e.g., Test Computers)
  3. Right-click the OU
  4. Select Link an Existing GPO...
  5. Select your PowerShell Startup Scripts GPO
  6. Click OK

Verify the GPO link and precedence:

  1. Click on the OU in the left pane
  2. Check the Linked Group Policy Objects tab
  3. Ensure your GPO appears in the list
  4. Note the Link Order - lower numbers have higher precedence

If you need to adjust the link order (when multiple GPOs affect the same computers):

  1. Select your GPO in the Linked Group Policy Objects list
  2. Use the arrow buttons to move it up or down
  3. Higher precedence GPOs (lower link order numbers) override conflicting settings
Warning: Always test GPO changes on a small group of computers first. Create a dedicated test OU with 2-3 computers before linking to larger OUs or the entire domain.

Verification: The GPO should appear in the Linked Group Policy Objects tab for your target OU with the correct link order.

07

Force Group Policy Update and Test Script Execution

Apply the new Group Policy settings to a test computer and verify that your PowerShell startup script executes correctly.

On a test computer in the target OU, force a Group Policy update:

gpupdate /force

Check that the new policy is applied:

gpresult /r

Look for your GPO name in the output under "Applied Group Policy Objects". If it doesn't appear, check the GPO link and ensure the computer is in the correct OU.

Restart the test computer to trigger the startup script:

shutdown /r /t 0

After the computer restarts, verify script execution by checking the Event Log:

Get-EventLog -LogName Application -Source Application -Newest 10 | Where-Object {$_.EventID -eq 1001}

Also check for the log file created by the script:

type C:\Windows\Temp\startup_script.log

If the script didn't execute, check the Group Policy event logs for errors:

Get-WinEvent -LogName "Microsoft-Windows-GroupPolicy/Operational" -MaxEvents 20 | Where-Object {$_.LevelDisplayName -eq "Error"}
Pro tip: Use gpresult /h gpreport.html to generate a detailed HTML report of all applied Group Policy settings, including startup scripts.

Verification: You should see evidence of script execution in both the Event Log (Event ID 1001) and the log file with the current timestamp and computer name.

08

Monitor and Troubleshoot Script Execution

Implement monitoring and troubleshooting procedures to ensure your startup scripts continue working reliably across your environment.

Create a monitoring script to check startup script execution across multiple computers:

# Monitor startup script execution across domain computers
$computers = Get-ADComputer -Filter "OperatingSystem -like '*Windows 11*'" -Properties Name

foreach ($computer in $computers) {
    $computerName = $computer.Name
    try {
        $lastEvent = Get-WinEvent -ComputerName $computerName -LogName Application -MaxEvents 1 -FilterXPath "*[System[EventID=1001]]"
        if ($lastEvent) {
            Write-Host "$computerName - Last execution: $($lastEvent.TimeCreated)" -ForegroundColor Green
        } else {
            Write-Host "$computerName - No startup script execution found" -ForegroundColor Red
        }
    } catch {
        Write-Host "$computerName - Unable to connect or check logs" -ForegroundColor Yellow
    }
}

Common troubleshooting steps for script execution failures:

Check Group Policy application:

gpresult /scope computer /v

Verify script file permissions:

icacls "\\yourdomain.com\NETLOGON\startup-test.ps1"

Test script execution manually:

powershell.exe -ExecutionPolicy RemoteSigned -File "\\yourdomain.com\NETLOGON\startup-test.ps1"

Check for execution policy blocks:

Get-ExecutionPolicy -List

Common issues and solutions:

  • Event ID 1055/1130: Network not ready - increase startup wait time to 120 seconds
  • Access denied errors: Verify Domain Computers group has Read & Execute permissions on script file
  • Script not found: Check SYSVOL replication status and UNC path syntax
  • Execution policy errors: Verify the PowerShell execution policy GPO is applied correctly
Warning: Startup scripts run in SYSTEM context, not user context. Avoid operations that require user profile access or interactive elements in startup scripts.

Verification: Your monitoring script should show successful execution timestamps for all target computers. Any failures should be investigated using the troubleshooting steps above.

Frequently Asked Questions

What's the difference between PowerShell Scripts tab and Scripts tab in Group Policy startup configuration?+
The PowerShell Scripts tab is specifically designed for .ps1 files and provides better execution control, automatic PowerShell.exe invocation, and integration with execution policy settings. The Scripts tab is for traditional batch files and executables, requiring manual PowerShell.exe specification with -ExecutionPolicy parameters for PowerShell scripts. The PowerShell Scripts tab is the recommended approach for modern Windows environments.
Why do startup scripts fail with network-related errors and how can I fix timing issues?+
Startup scripts often fail because they execute before network services are fully initialized. Configure 'Specify startup policy processing wait time' to 60-120 seconds and 'Configure Logon Script Delay' to 1-2 minutes in Group Policy. This ensures network connectivity is established before script execution begins. Event IDs 1055 and 1130 typically indicate timing-related failures that these settings resolve.
How do I troubleshoot PowerShell execution policy blocks in Group Policy startup scripts?+
Windows 11 defaults to Restricted execution policy which blocks PowerShell scripts. Configure 'Turn on Script Execution' policy under Computer Configuration > Administrative Templates > Windows Components > Windows PowerShell, setting it to 'Allow local scripts and remote signed scripts' (RemoteSigned). Alternatively, use the Scripts tab with parameters: -ExecutionPolicy Bypass -File to override policy restrictions for specific scripts.
What permissions are required for PowerShell startup scripts in SYSVOL and how do I set them correctly?+
PowerShell startup scripts run as SYSTEM and require the Domain Computers group to have Read & Execute permissions on the script file. Use 'icacls scriptfile.ps1 /grant "Domain Computers:(RX)"' to set proper permissions. Place scripts in SYSVOL\domain\scripts\ or NETLOGON share for automatic replication across domain controllers. Avoid placing scripts in user-accessible locations to prevent unauthorized modifications.
Can I target specific computers or groups with Group Policy PowerShell startup scripts?+
Yes, use security filtering and WMI filtering in Group Policy Management Console. Link the GPO to specific OUs containing target computers, or use Security Filtering to specify computer groups. For advanced targeting, create WMI filters based on computer properties like operating system version, hardware specifications, or custom registry values. This allows precise control over which computers execute your startup scripts without affecting the entire domain.
Emanuel DE ALMEIDA
Written by

Emanuel DE ALMEIDA

Microsoft MCSA-certified Cloud Architect | Fortinet-focused. I modernize cloud, hybrid & on-prem infrastructure for reliability, security, performance and cost control - sharing field-tested ops & troubleshooting.

Discussion

Share your thoughts and insights

You must be logged in to comment.

Loading comments...