{"id":12556,"date":"2020-01-10T00:15:00","date_gmt":"2020-01-09T23:15:00","guid":{"rendered":"http:\/\/159.69.82.204\/win\/?p=12556"},"modified":"2020-01-09T20:07:21","modified_gmt":"2020-01-09T19:07:21","slug":"windows-10-v1909-and-a-possible-gpo-issue-part-2","status":"publish","type":"post","link":"https:\/\/borncity.com\/win\/2020\/01\/10\/windows-10-v1909-and-a-possible-gpo-issue-part-2\/","title":{"rendered":"Windows 10 V1909 and a possible GPO Issue &ndash; Part 2"},"content":{"rendered":"<p><img loading=\"lazy\" decoding=\"async\" style=\"float: left; margin: 0px 10px 0px 0px; display: inline\" src=\"http:\/\/www.borncity.com\/blog\/wp-content\/uploads\/2015\/01\/win102.jpg\" width=\"58\" align=\"left\" height=\"58\">[<a href=\"https:\/\/www.borncity.com\/blog\/?p=226760\" target=\"_blank\" rel=\"noopener noreferrer\">German<\/a>]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. <\/p>\n<p><!--more--><\/p>\n<h2>Some background<\/h2>\n<p><img loading=\"lazy\" decoding=\"async\" alt=\"\" src=\"https:\/\/vg07.met.vgwort.de\/na\/fd7a56c5ccae4e699980e1c8cfc3b37a\" width=\"1\" height=\"1\">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. <\/p>\n<p>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 <a href=\"https:\/\/borncity.com\/win\/2019\/12\/30\/windows-10-v1909-und-ein-mgliches-gpo-problem\/\">Windows 10 V1909 and a possible GPO Issue<\/a>. After publishing, I got feedback from readers also observing the behavior.&nbsp; <\/p>\n<h2>New details about the problem<\/h2>\n<p>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 <em>Configure security policy processing<\/em>) 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:<\/p>\n<blockquote>\n<p>GPSVC(4dc.62c) 08:47:18:084 ProcessGPOs(Machine): Processing extension Registrierung<br \/>GPSVC(4dc.62c) 08:47:18:084 ReadStatus: Read Extension's Previous status successfully.<br \/>GPSVC(4dc.62c) 08:47:18:084 ReadGPOList:++<br \/>GPSVC(4dc.62c) 08:47:18:084 CheckGPOs: ReadGPOList count = 0<br \/>GPSVC(4dc.62c) 08:47:18:085 CompareGPOLists:&nbsp; One list is empty<br \/>GPSVC(4dc.62c) 08:47:18:085 GPLockPolicySection: Sid = (null), dwTimeout = 30000, dwFlags = 0x40<br \/>GPSVC(4dc.62c) 08:47:18:085 bMachine = 1 <br \/>GPSVC(4dc.62c) 08:47:18:085 Global Sync Lock Called<br \/>GPSVC(4dc.62c) 08:47:18:086 Writer Lock got immediately.<br \/>GPSVC(4dc.62c) 08:47:18:086 Global Lock taken successfully<br \/>GPSVC(4dc.62c) 08:47:18:086 ProcessGPOList:++ Entering for extension Registrierung<br \/>GPSVC(4dc.62c) 08:47:18:086 MachinePolicyCallback: Setting status UI to Richtlinie \"Registrierung\" wird \u00fcbernommen&#8230;<br \/>GPSVC(4dc.62c) 08:47:18:090 LogExtSessionStatus: Successfully logged Extension Session data<br \/>GPSVC(4dc.62c) 08:47:18:091 GPLockPolicySection: Sid = (null), dwTimeout = 60000, dwFlags = 0x42<br \/>GPSVC(4dc.62c) 08:47:18:091 Registry Sync Lock Called<br \/>GPSVC(4dc.62c) 08:47:18:091 Writer Lock got immediately.<br \/>GPSVC(4dc.62c) 08:47:18:091 Registry Lock taken successfully<br \/>GPSVC(4dc.62c) 08:47:18:094 ResetPolicies: Entering.<br \/>GPSVC(4dc.62c) 08:47:18:094 SetPolicyOwnerOnKey: Setting owner on reg key on &lt;Software\\Policies&gt;.<br \/>GPSVC(4ec.66c) 08:58:41:299 SetPolicyOwnerOnKey: Setting owner on reg key on &lt;Software\\Policies&gt;.<br \/>GPSVC(4ec.66c) 08:58:41:299 SetPolicyOwnerOnKey: Setting owner on reg key on &lt;Software\\Microsoft\\Windows\\CurrentVersion\\Policies&gt;.<br \/>GPSVC(4ec.66c) 08:58:41:299 SetPolicyOwnerOnKey: Setting owner on reg key on &lt;System\\CurrentControlSet\\Policies&gt;.<br \/>GPSVC(4ec.66c) 08:58:41:300 ParseRegistryFile: Entering with &lt;C:\\ProgramData\\ntuser.pol&gt;.<br \/>GPSVC(4ec.66c) 08:58:41:300 DeleteRegistryValue: Deleted Software\\Policies\\Microsoft\\SystemCertificates\\EFS\\EFSBlob<br \/>GPSVC(4ec.66c) 08:58:41:301 DeleteRegistryValue: Deleted Software\\Policies\\Microsoft\\SystemCertificates\\EFS\\Certificates\\<br \/>13A2741223481A329363D0BDCEAA9995FED85A70\\Blob<br \/>GPSVC(4ec.66c) 08:58:41:301 DeleteRegistryValue: Deleted Software\\Policies\\Microsoft\\SystemCertificates\\EFS\\CRLs\\<br \/>\u2026.<br \/>GPSVC(4dc.62c) 08:47:18:098 DeleteRegistryValue: Deleted Software\\Policies\\Microsoft\\Windows\\System\\EnableSmartScreen<br \/>GPSVC(4dc.62c) 08:47:18:099 DeleteRegistryValue: Deleted Software\\Policies\\Microsoft\\Windows\\System\\ShellSmartScreenLevel<br \/>GPSVC(4dc.62c) 08:47:18:099 RegCleanUpKey:&nbsp; Failed to delete value &lt;DisableAntiSpyware&gt; with 5.<br \/>GPSVC(4dc.62c) 08:47:18:099 DeleteRegistryValue: Failed to delete Software\\Policies\\Microsoft\\Windows Defender\\DisableAntiSpyware<br \/>GPSVC(4dc.62c) 08:47:18:099 ParseRegistryFile: Callback function returned false.<br \/>\u2026<br \/>GPSVC(4dc.62c) 08:47:18:238 ProcessGPOs(Machine): Extension Registrierung ProcessGroupPolicy failed, status 0x80004005.<\/p>\n<\/blockquote>\n<p>At the end of the log there is suddenly an access error 0x80004005. Could this be a trace to the root cause?<\/p>\n<h3>Blame the Windows Defender<\/h3>\n<p>In further tests Markus digged into the matter and found a possible root cause. He wrote in a follow-up mail: <\/p>\n<blockquote>\n<p>The Windows Defender (we use it as AV solution) is to blame!<\/p>\n<\/blockquote>\n<blockquote>\n<p>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. <\/p>\n<\/blockquote>\n<p>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:<\/p>\n<blockquote>\n<p>GPSVC(4ec.66c) 08:58:41:281 ProcessGPOs(Machine): &#8212;&#8212;&#8212;&#8212;&#8212;<br \/>GPSVC(4ec.66c) 08:58:41:281 ProcessGPOs(Machine): Processing extension Registrierung<br \/>GPSVC(4ec.66c) 08:58:41:282 ReadStatus: Read Extension's Previous status successfully.<br \/>GPSVC(4ec.66c) 08:58:41:282 ReadGPOList:++<br \/>GPSVC(4ec.66c) 08:58:41:282 CheckGPOs: ReadGPOList count = 0<br \/>GPSVC(4ec.66c) 08:58:41:282 CompareGPOLists:&nbsp; One list is empty<br \/>GPSVC(4ec.66c) 08:58:41:283 GPLockPolicySection: Sid = (null), dwTimeout = 30000, dwFlags = 0x40<br \/>GPSVC(4ec.66c) 08:58:41:283 bMachine = 1 <br \/>GPSVC(4ec.66c) 08:58:41:283 Global Sync Lock Called<br \/>GPSVC(4ec.66c) 08:58:41:283 Writer Lock got immediately.<br \/>GPSVC(4ec.66c) 08:58:41:283 Global Lock taken successfully<br \/>GPSVC(4ec.66c) 08:58:41:283 ProcessGPOList:++ Entering for extension Registrierung<br \/>GPSVC(4ec.66c) 08:58:41:283 MachinePolicyCallback: Setting status UI to Richtlinie \"Registrierung\" wird \u00fcbernommen&#8230;<br \/>GPSVC(4ec.66c) 08:58:41:284 GetWbemServices: CoCreateInstance succeeded<br \/>GPSVC(4ec.66c) 08:58:41:288 ConnectToNameSpace: ConnectServer returned 0x0<br \/>GPSVC(4ec.66c) 08:58:41:297 LogExtSessionStatus: Successfully logged Extension Session data<br \/>GPSVC(4ec.66c) 08:58:41:297 GPLockPolicySection: Sid = (null), dwTimeout = 60000, dwFlags = 0x42<br \/>GPSVC(4ec.66c) 08:58:41:297 Registry Sync Lock Called<br \/>GPSVC(4ec.66c) 08:58:41:297 Writer Lock got immediately.<br \/>GPSVC(4ec.66c) 08:58:41:297 Registry Lock taken successfully<br \/>GPSVC(4ec.66c) 08:58:41:299 ResetPolicies: Entering.<br \/>GPSVC(4ec.66c) 08:58:41:299 SetPolicyOwnerOnKey: Setting owner on reg key on &lt;Software\\Policies&gt;.<br \/>GPSVC(4ec.66c) 08:58:41:299 SetPolicyOwnerOnKey: Setting owner on reg key on &lt;Software\\Microsoft\\Windows\\CurrentVersion\\Policies&gt;.<br \/>GPSVC(4ec.66c) 08:58:41:299 SetPolicyOwnerOnKey: Setting owner on reg key on &lt;System\\CurrentControlSet\\Policies&gt;.<br \/>GPSVC(4ec.66c) 08:58:41:300 ParseRegistryFile: Entering with &lt;C:\\ProgramData\\ntuser.pol&gt;.<br \/>GPSVC(4ec.66c) 08:58:41:300 DeleteRegistryValue: Deleted Software\\Policies\\Microsoft\\SystemCertificates\\EFS\\EFSBlob<br \/>GPSVC(4ec.66c) 08:58:41:301 DeleteRegistryValue: Deleted Software\\Policies\\Microsoft\\SystemCertificates\\EFS\\Certificates\\<br \/>13A2741223481A329363D0BDCEAA9995FED85A70\\Blob<br \/>GPSVC(4ec.66c) 08:58:41:301 DeleteRegistryValue: Deleted Software\\Policies\\Microsoft\\SystemCertificates\\EFS\\CRLs\\<br \/>GPSVC(4ec.66c) 08:58:41:301 DeleteRegistryValue: Deleted Software\\Policies\\Microsoft\\SystemCertificates\\EFS\\CTLs\\<br \/>GPSVC(4ec.66c) 08:58:41:302 DeleteRegistryValue: Deleted Software\\Policies\\Microsoft\\MicrosoftEdge\\PhishingFilter\\EnabledV9<br \/>GPSVC(4ec.66c) 08:58:41:302 DeleteRegistryValue: Deleted Software\\Policies\\Microsoft\\Windows\\System\\EnableSmartScreen<br \/>GPSVC(4ec.66c) 08:58:41:303 DeleteRegistryValue: Deleted Software\\Policies\\Microsoft\\Windows\\System\\ShellSmartScreenLevel<br \/>GPSVC(4ec.66c) 08:58:41:308 DeleteRegistryValue: Deleted Software\\Policies\\Microsoft\\Windows Defender\\DisableAntiSpyware<br \/>GPSVC(4ec.66c) 08:58:41:308 DeleteRegistryValue: Deleted Software\\Policies\\Microsoft\\Windows Defender\\AllowFastServiceStartup<br \/>GPSVC(4ec.66c) 08:58:41:309 DeleteRegistryValue: Deleted Software\\Policies\\Microsoft\\Windows Defender\\ServiceKeepAlive<br \/>GPSVC(4ec.66c) 08:58:41:309 DeleteRegistryValue: Deleted Software\\Policies\\Microsoft\\Windows Defender\\RandomizeScheduleTaskTimes<br \/>GPSVC(4ec.66c) 08:58:41:310 DeleteRegistryValue: Deleted Software\\Policies\\Microsoft\\Windows Defender\\Exclusions\\Exclusions_Paths<br \/>GPSVC(4ec.66c) 08:58:41:310 DeleteRegistryValue: Deleted Software\\Policies\\Microsoft\\Windows Defender\\Exclusions\\Paths\\c:\\empirumagent<br \/>GPSVC(4ec.66c) 08:58:41:311 DeleteRegistryValue: Deleted Software\\Policies\\Microsoft\\Windows Defender\\Quarantine\\PurgeItemsAfterDelay<br \/>GPSVC(4ec.66c) 08:58:41:311 DeleteRegistryValue: Deleted Software\\Policies\\Microsoft\\Windows Defender\\Real-Time Protection\\DisableOnAccessProtection<br \/>GPSVC(4ec.66c) 08:58:41:311 DeleteRegistryValue: Deleted Software\\Policies\\Microsoft\\Windows Defender\\Real-Time Protection\\DisableIOAVProtection<br \/>GPSVC(4ec.66c) 08:58:41:311 DeleteRegistryValue: Deleted Software\\Policies\\Microsoft\\Windows Defender\\Real-Time Protection\\DisableScanOnRealtimeEnable<br \/>GPSVC(4ec.66c) 08:58:41:312 DeleteRegistryValue: Deleted Software\\Policies\\Microsoft\\Windows Defender\\Real-Time Protection\\DisableBehaviorMonitoring<br \/>GPSVC(4ec.66c) 08:58:41:312 DeleteRegistryValue: Deleted Software\\Policies\\Microsoft\\Windows Defender\\Real-Time Protection\\DisableRawWriteNotification<br \/>.<br \/>GPSVC(4ec.66c) 08:58:42:062 ProcessGPOList: Extension Registrierung was able to log data. RsopStatus = 0x0, dwRet = 0, Clearing the dirty bit<\/p>\n<\/blockquote>\n<p>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. <\/p>\n<ul>\n<li>Directly after installing a Windows 10 V1909 client and Defender active, the GPOs do not work.\n<li>If, after setting up a Windows 10 V1909 client, he re-enables Windows Defender via the <em>security filtering<\/em> policy for the machine, everything seems to work normally. <\/li>\n<\/ul>\n<p>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)! <\/p>\n<h3>A buggy signature\/engine?<\/h3>\n<p>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 &#8211; 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:<\/p>\n<blockquote>\n<p>I'll quickly script an update via PowerShell into our deployment and see if the problem can be solved.<\/p>\n<p>Let's see if the cmdlet Update-MpSignature can help.<\/p>\n<\/blockquote>\n<p>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! <\/p>\n<p>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 &#8211; so third parties can benefit from it. <\/p>\n<p><strong>Similar articles:<\/strong><br \/><a href=\"https:\/\/borncity.com\/win\/2019\/12\/30\/windows-10-v1909-und-ein-mgliches-gpo-problem\/\">Windows 10 V1909 and a possible GPO Issue<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"<p>[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 &hellip; <a href=\"https:\/\/borncity.com\/win\/2020\/01\/10\/windows-10-v1909-and-a-possible-gpo-issue-part-2\/\">Continue reading <span class=\"meta-nav\">&rarr;<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[463,2],"tags":[2221,47,2107],"class_list":["post-12556","post","type-post","status-publish","format-standard","hentry","category-issue","category-windows","tag-gpo","tag-issue","tag-windows-10-v1909"],"_links":{"self":[{"href":"https:\/\/borncity.com\/win\/wp-json\/wp\/v2\/posts\/12556","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/borncity.com\/win\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/borncity.com\/win\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/borncity.com\/win\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/borncity.com\/win\/wp-json\/wp\/v2\/comments?post=12556"}],"version-history":[{"count":0,"href":"https:\/\/borncity.com\/win\/wp-json\/wp\/v2\/posts\/12556\/revisions"}],"wp:attachment":[{"href":"https:\/\/borncity.com\/win\/wp-json\/wp\/v2\/media?parent=12556"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/borncity.com\/win\/wp-json\/wp\/v2\/categories?post=12556"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/borncity.com\/win\/wp-json\/wp\/v2\/tags?post=12556"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}