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:

http://technet.microsoft.com/en-us/library/dd392577(v=ws.10).aspx
http://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: 

http://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.