The Cobbler’s Children have now shoes
When I was younger, I heard a phrase “The cobbler’s children have no shoes” and similar things which implied that frequently, people within a particular industry are less likely to want to utilize their skills as home when they’re not working. I was reminded of this a few weeks ago while I was on vacation. I logged onto my work computer and noticed that I was unable to connect to work via DirectAccess. Upon further investigation, I noticed that the IP Helper Service wasn’t running and that there did not appear to be any settings for DirectAccess present on the computer.
“No Problem,” I thought, I’ll just connect via VPN, run “klist –li 0x3e7 purge” to flush my computer’s Kerberos tokens, and refresh GPOs via “gpupdate /force”. Instead of success, I see the following:
C:\windows\system32>gpupdate /force Updating policy...
Computer policy could not be updated successfully. The following errors were encountered:
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. User Policy update has completed successfully.
To diagnose the failure, review the event log or run GPRESULT /H GPReport.html f rom the command line to access information about Group Policy results.
C:\windows\system32>
Since I was able to accomplish what I needed over VPN and wanted to get back to not working, I decided to just leave the computer connected over VPN, cross my fingers, and look back on it in a few days. Things always work better after being left alone, right? The next day, I rebooted and tried again, but saw the same message. This left me with a difficult decision, spend vacation time troubleshooting my own computer, or turn it off and deal with it later. I turned it off.
A few days later, I powered on the computer again and found that things hadn’t changed yet. I connected via VPN and tried another “GPUPDATE /force”, and found that things were still no different. This time I had some time that I could spend on troubleshooting the problem and decided to take a look. In the Event Logs, I see an SCECLI 1704 telling me that the GPOs applied successfully.
Frustrated that I’m getting an error in one window while another tells me that everything is fine, I do what anyone troubleshooting while on vacation does…I powered off the computer and went back to not working.
A couple of days later, I powered on the laptop and found the symptoms had not yet changed. This time, I decided that I needed to fix the problem. I opened up a browser and went to bing.com so that I could do a search for the error. Between the first three results, I was able to find my solution. I found two hits to TechNet articles which described the same message, but had a variable listed where mine had “LocalGPO”, and I also did not have the event log entries that they referred to. Those entries were:
https://technet.microsoft.com/en-us/library/dd392577(v=ws.10).aspx
https://technet.microsoft.com/en-us/library/dd392529(WS.10).aspx
The other link was more helpful and contained the exact error, including that the problem was with “LocalGPO”. That post was:
[https://rays-it.blogspot.com/2011/03/event-1096-processing-of-group-policy.html](https://rays-it.blogspot.com/2011/03/event-1096-processing-of-group-policy.html%0A "https://rays-it.blogspot.com/2011/03/event-1096-processing-of-group-policy.html
")
It directed me to the file registry.pol under C:\Windows\System32\GroupPolicy. I looked into that directory and found the following:
C:\windows\system32>cd GroupPolicy\machine
C:\Windows\System32\GroupPolicy\Machine>dir Volume in drive C is OSDisk Volume Serial Number is 38AD-4B6E
Directory of C:\Windows\System32\GroupPolicy\Machine
10/09/2012 05:18 PM <DIR> . 10/09/2012 05:18 PM <DIR> .. 10/09/2012 05:18 PM 552 comment.cmtx 12/13/2012 03:29 PM 0 Registry.pol 08/29/2012 11:55 AM <DIR> Scripts 2 File(s) 552 bytes 3 Dir(s) 5,458,456,576 bytes free
C:\Windows\System32\GroupPolicy\Machine>
Since I was using an elevated command prompt, I tried a rename of the registry.pol file followed by re-applying of the GPOs:
C:\Windows\System32\GroupPolicy\Machine>ren registry.pol registry_pol.bak
C:\Windows\System32\GroupPolicy\Machine>dir Volume in drive C is OSDisk Volume Serial Number is 38AD-4B6E
Directory of C:\Windows\System32\GroupPolicy\Machine
12/27/2012 11:20 PM <DIR> . 12/27/2012 11:20 PM <DIR> .. 10/09/2012 05:18 PM 552 comment.cmtx 12/13/2012 03:29 PM 0 registry_pol.bak 08/29/2012 11:55 AM <DIR> Scripts 2 File(s) 552 bytes 3 Dir(s) 5,458,456,576 bytes free
C:\Windows\System32\GroupPolicy\Machine>gpupdate /force Updating policy...
Computer Policy update has completed successfully. User Policy update has completed successfully.
C:\Windows\System32\GroupPolicy\Machine>
Finally, the GPOs applied successfully. I was then able to start the IP Helper service and it stayed running. I looked and saw that my computer was now connected to work via DirectAccess.
So after trying the tried and true troubleshooting techniques of rebooting and ignoring the problem, I was finally able to do a web search and had my answer in just a few minutes. Maybe I should have started with that. Maybe next time. But spending time troubleshooting computers at home, even work computers, is just not how I wanted to spend my time-off. The old adage is true: The Cobbler’s children have no shoes.