我的一个用户今天早上有一个BSOD，所以我查看了事件日志，看看可能是什么原因。 我没有发现任何与BSOD有关的明显的东西，但是我发现了一些其他的东西，这引起了我的一些担心。 他在应用程序事件日志中有以下内容：
Windows无法访问GPO的文件gpt.ini cn = {2FE8F71F-F5A6-4829-A6D0-1858E327ED8C}，cn = policies，cn = system，DC = amci，DC = unm，DC = edu。 该文件必须位于<\ ourdomain \ SysVol \ ourdomain \ Policies {2FE8F71F-F5A6-4829-A6D0-1858E327ED8C} \ gpt.ini>位置。 （该系统找不到指定的path。 ）。 组策略处理中止。
我在这个网站上search了类似的问题，并且遇到了这个post 。 但是，这更多是因为迁移问题。 我们的服务器至less在3年内没有变化。 但是这篇文章的确帮助解释了我注意到GPO似乎不再适用的事实。 对我们来说，问题是我们都不是系统pipe理员。 （几年前，我在公元前做过一门课，但是WOW在相当一段时间里没有做任何事情）。我的问题是，我们是否有NTFRS的问题，正如Tim Long所说的（即使我们是不迁移任何东西，改变我们的服务器等）？
更可能是某种DNS问题。 组策略设置从：
\\domain.name.in.full\sysvol
如果客户端无法将domain.name.in.full转换为Windows可以连接的东西，则会出现这种问题。 几个testing来尝试：
nslookup为domain.name.in.full
如果它返回一个IP地址，或更好的IP地址列表，那么DNS工作正常。 如果不是，那么解决这个问题。
从CMD窗口执行dir \\domain.name.in.full\sysvol
如果nslookup能够正常工作，但是不能，那么Windows名称parsing失败。 检查以确保NetBIOS TCP Helper服务正在运行。 我有一个案例，在计算机实验室映像上禁用了此服务，并且该实验室中的所有计算机都没有得到GPO。