This is both for my own documentation, as well as to provide Google and others with a solution to this horrible problem. After searching the web, I was unable to find a solution that worked for me, so I got creative and tried a few of my own. Thankfully, one of them worked, or this would have been a longer day than it already has been.
Here are the symptoms:
- Error Event Id: 1030 – Windows cannot query for the list of Group Policy objects. A message that describes the reason for this was previously logged by the policy engine. This error occurs on the CLIENT machine anytime a user logs in or gpupdate /force is ran.
- Error Event ID: 1058 – Windows cannot access the file gpt.ini for GPO CN= The file must be present at the location. This error also happens every time the user logs in or gpupdate /force is ran.
- \\domain.local\ – Works but if you attempt to open any of the shares you get the error – \\domain\sysvol is not accessible. You might not have permission to use this network resource. contact the administrator of this server to find out if you have access to permissions.
- \\server.domain.local\sysvol\ – Works just fine (weird)
- pinging domain.local resolves to server.domain.local – Which is also as it should be.
Here is what I tried first based on research online:
- Restarting Distributed File system DFS in the services menu (no affect)
- Deleted all GPO policies and created new ones (no affect)
- re-ordered my network cards priority by going to Network Connections->advanced->advanced. (no affect)
- deleted and re-created my sysvol share (no affect)
- check permissions on sysvol (they were all fine)
- check DNS (all fine)
- checked for errors in the server event log with regards to File Replications Server aka FRS (nothing)
- checked various KB articles on Microsoft regarding the 1058 error… (no affect).
When it still didn’t work, I still needed a solution:
So here’s what I realized: DFS was working. The share itself was working… However, it appears that DFS takes over the sharename domain.local when it should be re-routing it to my domain controller. DFS isn’t nice though and will not let you recreate a new share with the sysvol name (at least not easily). So here’s what I did to fix it in the short term (and possibly the log term if it holds up):
- Removed the share on sysvol (not normally recommend)
- Opened DFS, and started the create a new root share
- I then created a STANDALONE dfs root titled sysvol and pointed it at c:\winnt\sysvol\sysvol\
- Created new group policy and tested it on a client (worked yay!)
I’m not sure that it will be the complete solution, but so far so good. I’m a little concerned about CertEnroll not working on the domain, as well as REMINST. It’s possible that the same trick will work to get them to work as well.
If you end up finding and using my solution, please leave me a comment, or if you found a way to improve it let me know.