I've got a couple of Server 2012 instances on Amazon EC2 and I'm in the process of setting up the GPOs. All of the settings of the GPOs are being applied fine, except none of the PowerShell scripts specified on computer startup are actually being executed. The scripts are sitting on a UNC share which has Authenticated Users applied to it with full permissions. I'm assuming it probably has something to do with the Execution Policy, but I'm not sure how to automatically bypass it. I could just go in each instance and bypass the Execution Policy, but that's obviously not a good idea, plus I'm eventually going to connect Windows 7 computers that will be running the same scripts.

How can I get the scripts to actually run? Google searches hasn't yielded a whole lot...

Current Permissions

Share - Authenticated Users (Full)

NTFS - Everyone (Full); CREATOR OWNER (Special); SYSTEM (Full)

  • What is the output from Get-ExecutionPolicy, and does the script run if you launch it from the shell prompt?
    – Greg Askew
    Jun 28, 2013 at 0:36
  • Because I overwrote it with a GPO, Get-ExecutionPolicy says Unrestricted. If I open PowerShell and manually run it, the script works fine.
    – Gup3rSuR4c
    Jun 28, 2013 at 0:46

6 Answers 6


Late reply, but your problem is probably the default of 2012 to delay logon scripts. Try a lower setting at:

Computer Configuration\Policies\Administrative Templates\System\Group Policy\Configure Logon Script Delay


If its a computer policy, authenticated users isn't what you want. You need to give Domain Computers read access.

  • I swear I've tried that before... I'll give a shot again, brb.
    – Gup3rSuR4c
    Jun 27, 2013 at 4:51
  • Nope, this did not work. The share permissions give Domain Users and Domain Computers full access and the NTFS permissions give CREATOR OWNER, SYSTEM, Domain Users and Domain Computers full access as well. Is there anything else? Manually running the script works fine if that matters...
    – Gup3rSuR4c
    Jun 27, 2013 at 5:05
  • All that means is that you had more than one problem :) Are you sure your script executes correctly as SYSTEM, which is the context that it will run as in this case? Grab a copy of psexec and run psexec -s cmd and call your PS script from there. It will execute as SYSTEM and hopefully give you some useful output.
    – MDMarra
    Jun 27, 2013 at 12:41
  • So, using PSEXEC -S CMD followed by POWERSHELL -Command "Test-Path '\\2012-F-01\Software$\Scripts\Computer Startup.ps1'" results in Test-Path : Access is denied. It's gotta be permissions, but I'm not sure what else to add in the permissions...
    – Gup3rSuR4c
    Jun 27, 2013 at 18:36
  • 1
    Computers are a member of Authenticated Users.
    – Tohuw
    Jan 7, 2015 at 1:59

I think PowerShell scripts run remotely from a Windows share are considered part of the Internet, so you have a few options:

  • The Execution Policy needs to be Remote Signed and you have to sign the scripts.
  • The Execution Policy needs to be Unrestricted.
  • Copy the script locally, at which point you can run it if your Execution Policy is Remote Signed or Unrestricted.
  • When calling powershell.exe, use the -ExecutionPolicy parameter with a value of Unrestricted
  • I'm in this exact situation, but can't find any Microsoft documentation advising powershell computer startup scripts need special consideration since the batch scripts work fine. Can you cite any official sources on the topic?
    – gregg
    Dec 4, 2020 at 22:42

You could instead store the files with the GPO files. when you go in to put in the script you should see a "show files" button. Click that to bring up the folder in which the scripts should be placed. Once in that folder you can simply click "Add" and choose the file.

Otherwise, you can add Domain Computers with read access, as the computers will be the ones authenticating against the share at startup, not the users.

  • 2
    Domain Computers are a member of Authenticated Users.
    – Tohuw
    Jan 7, 2015 at 2:01

This is an old topic but the answer most likely is there are SPACES in the filename and/or path of the PowerShell script in the Startup Properties of the GPO. To fix simply put double quotes around the full path of the PowerShell Script Name that is not running in the Startup Properties of the GPO.

Startup "Script Name" before: \\SERVERNAME\Scripts\Install KBs\Install KBs.ps1 This shows no Last Run in GPResults. The EventLog is no help it shows ErrorCode 0 ScriptElaspedTimeInSeconds 0. However in the registry at HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy\State\Machine\Scripts\Startup\#\#, where # is numbers, it shows the real ErrorCode 0xfffd0000 (4294770688). This is due to the script not being found - due to the space(s).

Startup "Script Name" after: "\\SERVERNAME\Scripts\Install KBs\Install KBs.ps1" Now in GPResults the Last Run for the script shows it ran. The registry, at the key above, shows ErrorCode 0x0, which is normal.

This solved and fixed solution is tested on Windows 7 Enterprise. I did not need to change permissions but AUTHENTICATED USERS with Read permission was present which allows the Computer Object to Read the PowerShell script.


I ran into the same issue. When I attempted to run the script from the \domain.local\netlogon folder, it gives me an error that the execution policy doesn't allow running remote scripts. I ran get-executionpolicy and it's set to "Restricted". I ran set-executionpolicy remotesigned but that didn't help because it's not digitally signed.

I ran get-help about_signing and it tells me i have to sign the script with a digital certificate from a CA or self-signed cert. A lot of work just to write a Windows 7 powershell logon script. However, it runs without a problem on systems with a higher version of Powershell (Server 2012 R2, Windows 7 with PS5). Now I have to figure out how to install WMF5.0 on each workstation without WSUS or suck it up and sign the stupid script.

Thanks Bill Gates...

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .