Loopback Powershell Logon Script GPO created in 2k8r2 does not work on 2k12r2 client but it works just fine on windows 7 RRS feed

  • Question

  • See title.

    What I've done:

    • I manually ran the Powershell scripts on the 2k12r2 client and they run perfectly.
    • I've checked gpresult and says that everything has applied successfully on 2k12r2 client.
    • Nothing in the logs just for event id 1530 but that is "normal" and I also get it on windows 7.
    • Both computers are in the same OU and only have this GPO applied to them. Inheritance is Blocked.

    Any suggestions on how I can troubleshoot?

    Thank you

    Monday, February 26, 2018 5:01 PM


  • i have given up. thank you all.
    • Marked as answer by SilentCow Tuesday, February 27, 2018 7:15 PM
    Tuesday, February 27, 2018 7:15 PM

All replies

  • I would advise to add some logging on your script so that you can get more details about the execution as just checking the logs in event viewer won't be enough.

    This posting is provided AS IS with no warranties or guarantees , and confers no rights.

    Ahmed MALEK

    My Website Link

    My Linkedin Profile

    My MVP Profile

    Monday, February 26, 2018 5:18 PM
  • Also - make sure that both the computer and the user have permission to read the GPO. The computer will need permission to apply the GPO.

    If my answer helped you, check out my blog: https://deployhappiness.com

    Monday, February 26, 2018 6:09 PM
  • Group Policy loopback processing has a few difficult abstractions that are only made more complicated by how Group Policy obtains and processes Group Policies to begin with. I noticed you said that Inheritance is blocked, and that could mean access inheritance and group policy inheritance. I'll cover both just in case.


    First, get a resultant set of policy for a machine where the policy is successful, and one for a machine where it is failing. You might get more detailed information via a comparison that way. And the details there might help you solve the problem. This will identify any precedence issues caused by competing policies. 


    Currently, as far as I know, Group Policy objects are obtained by the Computer object that is processing the group policies. So, if the computer object cannot obtain the policy objects in question, then the policy will fail. If some of the computer objects can obtain the user GPOs, but not others, then you may experience some problems with loopback processing. To prevent this, I would check the OUs to ensure "Authenticated Users" has access through the entire OU tree to the locations where the policies are enabled, just to prevent any problems. You will also need to check the Security Filtering, and WMI Filtering to make sure that the policy isn't being filtered accidentally. Since Loopback policies also get processed with the user account that logs into the device, ensure that the users accessing the devices have read access to the GPO, otherwise it may fail.


    Loopback processing also has a couple of different modes, Replace and Merge. In replace mode, the original user policies get bypassed, and only the computer's loopback policy is applied. In merge mode, both the computer's user policy and the user's user policies get applied, but if there is a conflict, the computer's user policy ALWAYS takes precedence.


    You'll also want to make sure there isn't a competing policy that disables loopback processing mode that has higher precedence on the affected machines. If there is, then it won't work. You can try and make sure that it is enabled by having: Computer Configuration\Administrative Templates\System\Group Policy\Configure user group policy loopback processing mode  set to "enabled" on the policy with the user policy to be looped back.


    Another thing to check, might be the powershell script execution policy, which can be checked via the cmdlet Get-ExecutionPolicy -list. If the policy doesn't allow the script to run, it may not run. You can also try using a batch file that executes the script using the command: 

    C:\[path to powershell]\powershell.exe -ExecutionPolicy Bypass -file "[path to script]"


    Hopefully this helps!

    Monday, February 26, 2018 6:22 PM
  • @joseph_moody. Thank you. Confirmed.
    Monday, February 26, 2018 6:25 PM
  • @Mr X. Thank you. I'll go research how to do that.
    Monday, February 26, 2018 6:26 PM
  • @avinikas. Thank you. execution policy was set to remotesign changed to unrestricted still didn't work.

    did the comparisons on the gpresults but winning gpo is good.

    gave it explicit permissions. nothing. will continue to troubleshoot.

    • Edited by SilentCow Monday, February 26, 2018 6:52 PM
    Monday, February 26, 2018 6:52 PM
  • > * I manually ran the Powershell scripts on the 2k12r2 client and they run perfectly.

    You are aware of the dumb 5 Minute delay for logon scripts that was introduced in Windows 8.1 (and thus also in 2012R2?

    Tuesday, February 27, 2018 8:49 AM
  • @Martin Binder. Indeed, Thank you for pointing that out. I left it on for 12 hours and applied the gpo that reduces the delay to 0 yesterday and nothing still won't run. Initially I was hoping it was going to be something silly like this. Now I'm focusing more on logging as the possible troubleshooting step.

    • Edited by SilentCow Tuesday, February 27, 2018 4:52 PM
    Tuesday, February 27, 2018 4:50 PM
  • i have given up. thank you all.
    • Marked as answer by SilentCow Tuesday, February 27, 2018 7:15 PM
    Tuesday, February 27, 2018 7:15 PM