A while ago I go I looked into a laptop not being able to access anything on the network. As this customer has Direct Access deployed I knew I had to start my troubleshooting with the following command: netsh dns show state
As you can tell from the screenshot above, the laptop thinks it’s outside the corporate network and has Direct Access configured and enabled. I tried pinging various resources (on the domain) but they all failed. That would make sense as the client is trying to build a Direct Access tunnel, but fails to do so. Besides that, the name resolution policy also kicks in. The result is that neither remote or local connectivity is working. In such a situation one should suspect an issue with the Network Location Service that is deployed on the network. However this was an isolated case as no other clients were showing similar issues…
The reason name resolution and thereby all other domain related tasks are failing is the fact that the Direct Access name resolution policies are in place and force all DNS requests for the domain zone to be resolved by the Direct Access DNS service. That one is not reachable as we don’t have a valid Direct Access Connection… In order to mitigate this I thought I’d kill the name resolution policies locally and see if I’d be able to get it talking to the domain again.
Delete both DA-…. keys. They can be found below HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient\DnsPolicyConfig. Reboot the client afterwards. In my case I could see connectivity (and name resolution) was now working again. But processing GPO’s still failed:
In the event log:
Event 1096: The processing of Group Policy failed. Windows could not apply the registry-based policy settings for the Group Policy object LocalGPO. Group Policy settings will not be resolved until this event is resolved. View the event details for more information on the file name and path that caused the failure.
Some googling led me the following information:
The instructions to fix this:
- Rename (or delete) C:\Windows\System32\GroupPolicy\Machine\Registry.pol
- Start > run > cmd (as admin)
- Gpedit.msc
- Below administrative templates change a (not matter which) setting and then revert it. This will trigger the creation of a new registry.pol file
- gpupdate /force
- Gpo’s should process correctly now.
Now you might wonder, how does this registry.pol gets in such a condition that group policy processing starts the fail? I stumbled across the following post:
In the comments section there’s a comment from Mike Niccum which seems to be very interesting. We checked our exclusions on our Endpoint Protection and as Mike explains we’re also seeing the missing antivirus exclusion. We added it and in the coming weeks we’ll see whether new issues will pop up or not.
- Present (Wrong?) exclusion: C:\Windows\System32\GroupPolicy\Registry.pol
- Missing exclusion: C:\Windows\System32\GroupPolicy\Machine\Registry.pol
9 comments