Freigeben über

Group Policy client side extensions

  • Artikel

A couple of months ago I was assisting a customer with a very strange Group Policy problem. The first sign of the problem was when some users complained that they weren’t notified of upcoming password expiries.

My initial thought was that it could probably be that the Default Domain Policy was not being applied properly as this is the only area where the password policies were being set for this customer (the settings in the Password Policy settings were correct).

Trying to recreate the issue we started up a test box and executed GPRESULT /R, but didn’t notice anything out of the ordinary.

I then suggested we get one of the affected machines to determine what the cause is, maybe this way we can replicate the issue on a clean machine.

These were my troubleshooting steps:

  1. Execute GPRESULT /h C:\GPORSOP\Report.html
  2. Checked the report and noticed that not all of the client side extensions are being processed – specifically the Security extension.
  3. Did a bit of research and found the following KB article: https://support.microsoft.com/kb/216357.
  4. Checked Security Group Policy Extension in registry, comparing with a healthy machine and noticed that the affected machine had an additional REG_DWORD entry called NoMachinePolicy which was set to “1”.
    Easy way to check this (GUID is static for all Windows Operating Systems):
    reg query "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\GPExtensions\{827D319E-6EAC-11D2-A4EA-00C04F79F83A}" /f NoMachinePolicy /t REG_DWORD
  5. Removed the NoMachinePolicy.
  6. Executed GPUPDATE /force.
  7. Whaalaaaa! All client side extensions processed successfully.

 The question now is why the entry was enabled on a few machines.

I found some blog articles around automated OS deployment where the deployment process would get stuck on the Interactive Logon text which would cause the process to stop. Disabling the security client side extension by adding the NoMachinePolicy=1 entry would disable this and the process would then be able to continue.The deployment team at this customer confirmed that this was not the case during their deployment process, so the only other explanation could be malware/virus, but I'm still not sure.

Luckily the amount of affected machines were very small in this case.

Hopefully someone else out there will come across this article if they experience this very interesting issue.

Until next time......

Michael Hall

Comments

  • Anonymous
    November 05, 2015
    Thanks Michael, We've been fighting this strange problem on a few dozen server for months. I just wish I had found your article before I figured it out the hard way, on my own.