2

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)

Gup3rSuR4c
  • 661
  • 3
  • 14
  • 29
  • What is the output from Get-ExecutionPolicy, and does the script run if you launch it from the shell prompt? – Greg Askew Jun 28 '13 at 00: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 '13 at 00:46

6 Answers6

2

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

Tohuw
  • 498
  • 2
  • 9
  • 24
1

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

MDMarra
  • 100,734
  • 32
  • 197
  • 329
  • I swear I've tried that before... I'll give a shot again, brb. – Gup3rSuR4c Jun 27 '13 at 04: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 '13 at 05: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 '13 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 '13 at 18:36
  • Changing the share permissions to `Authenticated Users` allows the `Test-Path` to work, but the script still doesn't run... – Gup3rSuR4c Jun 27 '13 at 18:58
  • I got `POWERSHELL -File "\\2012-F-01\Software$\Scripts\Computer Startup.ps1"` to work by bypassing the Execution Policy, so I set it to Unrestricted through a GPO and it still does not work... I just don't get it... – Gup3rSuR4c Jun 27 '13 at 19:28
  • Wait, you're using share permissions *and* NTFS permissions? Generally, share permissions are set to `Everyone - Full Control` and you use NTFS permissions to control access. Can you update your question with both the Share *and* NTFS ACLs? – MDMarra Jun 27 '13 at 23:27
  • I've updated my question with the ACLs. – Gup3rSuR4c Jun 27 '13 at 23:58
  • 1
    Computers are a member of Authenticated Users. – Tohuw Jan 07 '15 at 01:59
1

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
splattered bits
  • 928
  • 3
  • 11
  • 23
  • 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 04 '20 at 22:42
0

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.

HostBits
  • 11,796
  • 1
  • 25
  • 39
0

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.

Noral Kuhlmann
  • 1
0

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...

Jarrod L. J. Gibson
  • 566
  • 3
  • 18