One of my users had a BSOD this morning, so I looked at the event log to see what could be the cause. I didn't find anything obvious related to the BSOD, but I did find something else which causes me some concern. He had the following in his application event log:
Windows cannot access the file gpt.ini for GPO cn={2FE8F71F-F5A6-4829-A6D0-1858E327ED8C},cn=policies,cn=system,DC=amci,DC=unm,DC=edu. The file must be present at the location <\ourdomain\SysVol\ourdomain\Policies{2FE8F71F-F5A6-4829-A6D0-1858E327ED8C}\gpt.ini>. (The system cannot find the path specified. ). Group Policy processing aborted.
I searched on this website for similar issues, and came across this post. However, this was more for a migration issue. Our servers really haven't changed in at least 3 years. But that post did help explain the fact that I've noticed that GPO's don't seem to be applied anymore. The problem, for us, is that none of us are system administrators. (I did have a class on AD several years ago, but WOW, havne't done anything in it for quite some time.) My question is, do we have an issue with NTFRS, as Tim Long suggests (even though we're not migrating anything, changing our servers, etc)?
More likely is some kind of DNS issue. Group Policy settings are pulled from:
\\domain.name.in.full\sysvol
If the client can't turn domain.name.in.full into something that Windows can connect to, you'll get this kind of problem. A couple of tests to try out:
nslookup for domain.name.in.full
If it returns an IP address, or better yet a list of IP addresses, then DNS is working correctly. If it is not, then fix that problem.
Do a
dir \\domain.name.in.full\sysvol
from a CMD windowIf the nslookup works, but this doesn't, then Windows name-resolution is failing. Check to make sure the NetBIOS TCP Helper service is running. I had one case where this service was disabled on a computer lab image, and none of the machines in that lab got GPOs.