[German]In Windows 10 November 2019 Update (Version 1909), there appears to be an issue with Group Policies, because they cannot be enabled reliably. I already mentioned this a few days ago. Now I have received new information from an affected blog reader. Possibly the Windows Defender, which is distributed via the ISO installation media for Windows 10 version 1909, is involved in the problems.
Advertising
Some background
German blog reader Markus K. informed me at the end of 2019 about a strange observation in Windows 10 November 2019 Update (Version 1909). On freshly installed Windows 10 November 2019 Update (Version 1909) test systems Group Policy settings does not work in a reliable way.
Markus K. wrote in a mail to me that on computers running Windows 10 version 1909 it is simply a matter of chance whether a group policy takes effect or not. Neither the event log nor the GPSVC log are very useful, he said. I mentioned this on December 30, 2019 in the blog post Windows 10 V1909 and a possible GPO Issue. After publishing, I got feedback from readers also observing the behavior.
New details about the problem
Within the last hours blog reader Markus K. informed me about his further findings. Tips given in comments to the previous blog post (like caching or setting policy Configure security policy processing) seem to be useless. Markus wrote: I followed all hints given in the blog, unfortunately without result. By the way, the log looks like this:
GPSVC(4dc.62c) 08:47:18:084 ProcessGPOs(Machine): Processing extension Registrierung
GPSVC(4dc.62c) 08:47:18:084 ReadStatus: Read Extension's Previous status successfully.
GPSVC(4dc.62c) 08:47:18:084 ReadGPOList:++
GPSVC(4dc.62c) 08:47:18:084 CheckGPOs: ReadGPOList count = 0
GPSVC(4dc.62c) 08:47:18:085 CompareGPOLists: One list is empty
GPSVC(4dc.62c) 08:47:18:085 GPLockPolicySection: Sid = (null), dwTimeout = 30000, dwFlags = 0x40
GPSVC(4dc.62c) 08:47:18:085 bMachine = 1
GPSVC(4dc.62c) 08:47:18:085 Global Sync Lock Called
GPSVC(4dc.62c) 08:47:18:086 Writer Lock got immediately.
GPSVC(4dc.62c) 08:47:18:086 Global Lock taken successfully
GPSVC(4dc.62c) 08:47:18:086 ProcessGPOList:++ Entering for extension Registrierung
GPSVC(4dc.62c) 08:47:18:086 MachinePolicyCallback: Setting status UI to Richtlinie "Registrierung" wird übernommen…
GPSVC(4dc.62c) 08:47:18:090 LogExtSessionStatus: Successfully logged Extension Session data
GPSVC(4dc.62c) 08:47:18:091 GPLockPolicySection: Sid = (null), dwTimeout = 60000, dwFlags = 0x42
GPSVC(4dc.62c) 08:47:18:091 Registry Sync Lock Called
GPSVC(4dc.62c) 08:47:18:091 Writer Lock got immediately.
GPSVC(4dc.62c) 08:47:18:091 Registry Lock taken successfully
GPSVC(4dc.62c) 08:47:18:094 ResetPolicies: Entering.
GPSVC(4dc.62c) 08:47:18:094 SetPolicyOwnerOnKey: Setting owner on reg key on <Software\Policies>.
GPSVC(4ec.66c) 08:58:41:299 SetPolicyOwnerOnKey: Setting owner on reg key on <Software\Policies>.
GPSVC(4ec.66c) 08:58:41:299 SetPolicyOwnerOnKey: Setting owner on reg key on <Software\Microsoft\Windows\CurrentVersion\Policies>.
GPSVC(4ec.66c) 08:58:41:299 SetPolicyOwnerOnKey: Setting owner on reg key on <System\CurrentControlSet\Policies>.
GPSVC(4ec.66c) 08:58:41:300 ParseRegistryFile: Entering with <C:\ProgramData\ntuser.pol>.
GPSVC(4ec.66c) 08:58:41:300 DeleteRegistryValue: Deleted Software\Policies\Microsoft\SystemCertificates\EFS\EFSBlob
GPSVC(4ec.66c) 08:58:41:301 DeleteRegistryValue: Deleted Software\Policies\Microsoft\SystemCertificates\EFS\Certificates\
13A2741223481A329363D0BDCEAA9995FED85A70\Blob
GPSVC(4ec.66c) 08:58:41:301 DeleteRegistryValue: Deleted Software\Policies\Microsoft\SystemCertificates\EFS\CRLs\
….
GPSVC(4dc.62c) 08:47:18:098 DeleteRegistryValue: Deleted Software\Policies\Microsoft\Windows\System\EnableSmartScreen
GPSVC(4dc.62c) 08:47:18:099 DeleteRegistryValue: Deleted Software\Policies\Microsoft\Windows\System\ShellSmartScreenLevel
GPSVC(4dc.62c) 08:47:18:099 RegCleanUpKey: Failed to delete value <DisableAntiSpyware> with 5.
GPSVC(4dc.62c) 08:47:18:099 DeleteRegistryValue: Failed to delete Software\Policies\Microsoft\Windows Defender\DisableAntiSpyware
GPSVC(4dc.62c) 08:47:18:099 ParseRegistryFile: Callback function returned false.
…
GPSVC(4dc.62c) 08:47:18:238 ProcessGPOs(Machine): Extension Registrierung ProcessGroupPolicy failed, status 0x80004005.
At the end of the log there is suddenly an access error 0x80004005. Could this be a trace to the root cause?
Blame the Windows Defender
In further tests Markus digged into the matter and found a possible root cause. He wrote in a follow-up mail:
Advertising
The Windows Defender (we use it as AV solution) is to blame!
We have a GPO with security filtering with a computer group, where you can put a computer to turn off the Defender. If you install the computer with Windows Defender disabled, all GPOs will be applied! If you install the same device again with activated Defender, GPOs will fail.
Markus joined the test system with Windows 10 version 1909 [and Defender turned off] back into the computer group and rebooted the client twice. Here is a new log extract:
GPSVC(4ec.66c) 08:58:41:281 ProcessGPOs(Machine): —————
GPSVC(4ec.66c) 08:58:41:281 ProcessGPOs(Machine): Processing extension Registrierung
GPSVC(4ec.66c) 08:58:41:282 ReadStatus: Read Extension's Previous status successfully.
GPSVC(4ec.66c) 08:58:41:282 ReadGPOList:++
GPSVC(4ec.66c) 08:58:41:282 CheckGPOs: ReadGPOList count = 0
GPSVC(4ec.66c) 08:58:41:282 CompareGPOLists: One list is empty
GPSVC(4ec.66c) 08:58:41:283 GPLockPolicySection: Sid = (null), dwTimeout = 30000, dwFlags = 0x40
GPSVC(4ec.66c) 08:58:41:283 bMachine = 1
GPSVC(4ec.66c) 08:58:41:283 Global Sync Lock Called
GPSVC(4ec.66c) 08:58:41:283 Writer Lock got immediately.
GPSVC(4ec.66c) 08:58:41:283 Global Lock taken successfully
GPSVC(4ec.66c) 08:58:41:283 ProcessGPOList:++ Entering for extension Registrierung
GPSVC(4ec.66c) 08:58:41:283 MachinePolicyCallback: Setting status UI to Richtlinie "Registrierung" wird übernommen…
GPSVC(4ec.66c) 08:58:41:284 GetWbemServices: CoCreateInstance succeeded
GPSVC(4ec.66c) 08:58:41:288 ConnectToNameSpace: ConnectServer returned 0x0
GPSVC(4ec.66c) 08:58:41:297 LogExtSessionStatus: Successfully logged Extension Session data
GPSVC(4ec.66c) 08:58:41:297 GPLockPolicySection: Sid = (null), dwTimeout = 60000, dwFlags = 0x42
GPSVC(4ec.66c) 08:58:41:297 Registry Sync Lock Called
GPSVC(4ec.66c) 08:58:41:297 Writer Lock got immediately.
GPSVC(4ec.66c) 08:58:41:297 Registry Lock taken successfully
GPSVC(4ec.66c) 08:58:41:299 ResetPolicies: Entering.
GPSVC(4ec.66c) 08:58:41:299 SetPolicyOwnerOnKey: Setting owner on reg key on <Software\Policies>.
GPSVC(4ec.66c) 08:58:41:299 SetPolicyOwnerOnKey: Setting owner on reg key on <Software\Microsoft\Windows\CurrentVersion\Policies>.
GPSVC(4ec.66c) 08:58:41:299 SetPolicyOwnerOnKey: Setting owner on reg key on <System\CurrentControlSet\Policies>.
GPSVC(4ec.66c) 08:58:41:300 ParseRegistryFile: Entering with <C:\ProgramData\ntuser.pol>.
GPSVC(4ec.66c) 08:58:41:300 DeleteRegistryValue: Deleted Software\Policies\Microsoft\SystemCertificates\EFS\EFSBlob
GPSVC(4ec.66c) 08:58:41:301 DeleteRegistryValue: Deleted Software\Policies\Microsoft\SystemCertificates\EFS\Certificates\
13A2741223481A329363D0BDCEAA9995FED85A70\Blob
GPSVC(4ec.66c) 08:58:41:301 DeleteRegistryValue: Deleted Software\Policies\Microsoft\SystemCertificates\EFS\CRLs\
GPSVC(4ec.66c) 08:58:41:301 DeleteRegistryValue: Deleted Software\Policies\Microsoft\SystemCertificates\EFS\CTLs\
GPSVC(4ec.66c) 08:58:41:302 DeleteRegistryValue: Deleted Software\Policies\Microsoft\MicrosoftEdge\PhishingFilter\EnabledV9
GPSVC(4ec.66c) 08:58:41:302 DeleteRegistryValue: Deleted Software\Policies\Microsoft\Windows\System\EnableSmartScreen
GPSVC(4ec.66c) 08:58:41:303 DeleteRegistryValue: Deleted Software\Policies\Microsoft\Windows\System\ShellSmartScreenLevel
GPSVC(4ec.66c) 08:58:41:308 DeleteRegistryValue: Deleted Software\Policies\Microsoft\Windows Defender\DisableAntiSpyware
GPSVC(4ec.66c) 08:58:41:308 DeleteRegistryValue: Deleted Software\Policies\Microsoft\Windows Defender\AllowFastServiceStartup
GPSVC(4ec.66c) 08:58:41:309 DeleteRegistryValue: Deleted Software\Policies\Microsoft\Windows Defender\ServiceKeepAlive
GPSVC(4ec.66c) 08:58:41:309 DeleteRegistryValue: Deleted Software\Policies\Microsoft\Windows Defender\RandomizeScheduleTaskTimes
GPSVC(4ec.66c) 08:58:41:310 DeleteRegistryValue: Deleted Software\Policies\Microsoft\Windows Defender\Exclusions\Exclusions_Paths
GPSVC(4ec.66c) 08:58:41:310 DeleteRegistryValue: Deleted Software\Policies\Microsoft\Windows Defender\Exclusions\Paths\c:\empirumagent
GPSVC(4ec.66c) 08:58:41:311 DeleteRegistryValue: Deleted Software\Policies\Microsoft\Windows Defender\Quarantine\PurgeItemsAfterDelay
GPSVC(4ec.66c) 08:58:41:311 DeleteRegistryValue: Deleted Software\Policies\Microsoft\Windows Defender\Real-Time Protection\DisableOnAccessProtection
GPSVC(4ec.66c) 08:58:41:311 DeleteRegistryValue: Deleted Software\Policies\Microsoft\Windows Defender\Real-Time Protection\DisableIOAVProtection
GPSVC(4ec.66c) 08:58:41:311 DeleteRegistryValue: Deleted Software\Policies\Microsoft\Windows Defender\Real-Time Protection\DisableScanOnRealtimeEnable
GPSVC(4ec.66c) 08:58:41:312 DeleteRegistryValue: Deleted Software\Policies\Microsoft\Windows Defender\Real-Time Protection\DisableBehaviorMonitoring
GPSVC(4ec.66c) 08:58:41:312 DeleteRegistryValue: Deleted Software\Policies\Microsoft\Windows Defender\Real-Time Protection\DisableRawWriteNotification
.
GPSVC(4ec.66c) 08:58:42:062 ProcessGPOList: Extension Registrierung was able to log data. RsopStatus = 0x0, dwRet = 0, Clearing the dirty bit
The error code 0x80004005 no longer appears in the log. Markus wrote that he can reproduce this behavior. His first speculation was that it could be due to the Defender settings. But during tests within the last days with different scenarios there was a crude error pattern.
- Directly after installing a Windows 10 V1909 client and Defender active, the GPOs do not work.
- If, after setting up a Windows 10 V1909 client, he re-enables Windows Defender via the security filtering policy for the machine, everything seems to work normally.
At some point, he came up with the idea of updating Windows Defender on a client manually by having it check for updates. The result: The GPOs are applied again (as expected)!
A buggy signature/engine?
Markus concludes that the signature files distributed in the ISO installation file for Windows 10 version 1909 and/or the Defender engine are simply broken. This would explain the problems with freshly installed test systems with active Defender – and the observation, that the GPOs are suddenly working at a later time. However, he does not understand why the Defender update does not happen immediately after a client is installed. His concluding comment:
I'll quickly script an update via PowerShell into our deployment and see if the problem can be solved.
Let's see if the cmdlet Update-MpSignature can help.
In addition, Markus pointed out, that he didn't found problems in the Defender eventlog. He concluded: Too bad about the weeks of wasted time and damaged nerves!
The question to the affected people would be now, can these findings be confirmed? If it is due to the ISO installation medium, I could give Microsoft a hint. Thanks to Markus for providing the previous findings for publication in the blog – so third parties can benefit from it.
Similar articles:
Windows 10 V1909 and a possible GPO Issue
Advertising
Welcome to Tamper Protection
https://support.microsoft.com/en-us/help/4490103/windows-10-prevent-changes-to-security-settings-with-tamper-protection
https://support.microsoft.com/en-us/help/2769299/improve-windows-defender-baseline-engines-platform
"If this feature is enabled, disabling Windows defender by using the DisableAntiSpyware group policy key will be prevented. You can continue to register other antivirus solution in Windows Security Center."
you can use NSudo to gain (restore) access:
– first, stop Windows Defender service
net stop WinDefend /y || sc stop WinDefend
– then disable the new protection
reg add "HKLM\SOFTWARE\Microsoft\Windows Defender\Features" /v TamperProtection /t REG_DWORD /d 0 /f
Thanks for the hint – Tamper Protection has also been mentioned as a suspicion in the 1st German blog post. But it doesn't explains, why the issues is gone after updating Defender manually once. Guess, Microsoft has patched something, that will be delivered via an defender update.
The difference between consistently working or not is only the Windows Defender Engine/Signature version.
Update after domain join and before reboot all is working nice.
Leave it as Microsoft delivers it and GPOs fail.
Hi,
We also faced the same issues, this blog saved me a huge amount of time. Raised it with MS but was told they won't fix it in the ISO directly and you have to update or wait for the next release of windows….
Hi,
Any news?
My fix was to remove all GPO settings related to managing Defender related settings and to manage Defender settings with SCCM and/or Intune. This resolved all issues for us, just stop managing Defender settings with GPO.
I just happened to only have 2 settings I was setting with GPO, as soon as I removed them from the policy, everything worked great. We've now been deploying 1909 using the original ISO for months over several hundred workstations with no issues at all
Here were our only 2 settings
-Join Microsoft MAPS
-Select cloud protection level