Why Your Group Policy Startup Script Isn’t Running (Even Though the GPO Looks Correct)

When managing a Windows Active Directory environment, it’s easy to assume that if a Group Policy Object (GPO) contains both Computer and User settings, everything inside it will apply automatically.

Unfortunately, that’s not how Active Directory processes policy.

I recently ran into an issue where a PowerShell startup script successfully copied desktop wallpapers to every Windows machine except one. The script worked perfectly when run manually, and the user account was identical across all machines.

It wasn’t a permissions or script issue—it was a classic GPO scoping oversight.

The Symptoms

• The Script Worked on Most PCs: The wallpaper folder was created and files copied successfully on nearly every machine.
• One Computer Failed completely: No folder, no files, no script execution.
• Identical User Context: The same domain user was logging into all machines.
• Clean GP Updates: Running gpupdate /force completed with zero errors.
• The Smoking Gun: Running a computer-scoped policy check revealed the issue:

Bash

gpresult /scope computer /r

The Output:

Plaintext

Applied Group Policy Objects
-----------------------------
Default Domain Policy

The specific GPO containing the startup script was completely missing from the applied list.

Computer vs. User Configuration: The Divide

Although Computer and User configurations coexist inside the same GPO container, Windows processes them as completely independent entities based on where the GPO is linked.

Configuration Type	When It Applies	Common Use Cases
Computer Configuration	During system boot (before user login)	Startup/shutdown scripts, security baselines, firewall rules, Windows Update policies.
User Configuration	During user logon	Folder redirection, drive maps, desktop backgrounds, user registry preferences, logon/logoff scripts.

The Root Cause: Misaligned OUs

In this scenario, the startup script was nested inside a GPO named Folder Redirection & Drive Maps.

Because it dealt with user environment settings, that GPO was exclusively linked to User OUs (e.g., OU=Mortals, OU=OlderPCs).

However, the troubleshooting computer object lived here:

Plaintext

OU=Computers,OU=NetherRealm,DC=domain,DC=local

The GPO Processing Rule: Because the computer object did not reside within an OU hierarchy where the GPO was linked, Windows completely ignored the Computer Configuration side of that GPO. The startup script never stood a chance.

How to Confirm the Issue

If you suspect a machine isn’t evaluating your computer policies, run the following command in an elevated command prompt:

Bash

gpresult /scope computer /r

Look closely under the Applied Group Policy Objects section. If your GPO isn’t listed, the computer isn’t target scope.

For an advanced, granular look at filtered GPOs (and why they were denied, such as WMI filters or security permissions), export an HTML report:

Bash

gpresult /h gpresult.html

The Solution: Implement a Split GPO Architecture

To fix the issue, extract the startup script from the user-linked policy and place it into a dedicated GPO targeted directly at your computer objects.

1. Create a Dedicated Computer GPO

Create a GPO named GPO – Computer Settings and configure your startup scripts or wallpaper deployment there.

2. Link it Correctly

Link this new GPO directly to the OU=Computers container.

As soon as the target machine was rebooted within scope of the new link, the startup script executed perfectly.

Best Practice: Keep Your GPOs Separated

Mixing Computer and User configurations within a single GPO is technically permissible, but separating them into dedicated policies is an industry best practice.

Computer-Only GPOs

Link to Computer OUs

• Computer Baselines
• Startup/Shutdown Scripts
• Windows Security & BitLocker
• Power Management

User-Only GPOs

Link to User OUs

• Folder Redirection
• Drive Mapping & Printers
• Desktop & Start Menu Restraints
• User Registry Preferences

The Benefits of Clean Separation

• Simplified Troubleshooting: If a drive map fails, you immediately look at User OUs. If a software deployment fails, you look at Computer OUs.
• Faster Policy Processing: Windows doesn’t waste cycles parsing empty or irrelevant sections of a GPO.
• Cleaner gpresult Audits: Your HTML reports become significantly easier to read and diagnose.

Sometimes, a failing script isn’t broken at all—it’s just waiting for its policy to be linked to the right house.