组策略排错经验谈
对于网络管理员来讲，关于组策略的问题可能听到最多的抱怨就是：“我设置了一个策略，为什么它不生效？”。对于一些比较大的网络环境，组策略可以减轻网管人员的管理工作量，但其出问题的几率还是比较大的。这一方面是由于我们日常操作不慎引起的，另一方面是由于策略之间相互影响而造成最终的结果与设想不一致。
组策略应用要点
这里，笔者给出几点微软不推荐的做法：
（1）不要删除两条默认的策略（默认域策略和默认域控制器策略），很多问题的发生都是由删除这两条默认策略引起的。而且要使用组策略管理控制台（GPMC）工具备份这两条默认策略，用于将来还原。如果直接通过GPMC删除默认策略时，我们会发现是行不通的，但是，稍有经验的读者知道如何删除它们。既然是一个不推荐的做法，希望大家不要删除它们。
（2）组策略是不能够链接在用户组上的。有很多初次接触活动目录的管理员，经常设想将组策略生效于某一用户组，这是行不通的。组策略不是为用户组设定的策略，而是一组策略的集合，只能链接在站点、组织单元和域上面。
（3）组策略的生效问题
1）生效顺序
正常生效顺序：本地策略→站点策略→域策略→父OU策略→子OU策略。
我们使用时，在出现登录对话框前，会有“应用安全策略”的提示，这也就是本地策略生效的过程。
发生冲突时，最新的策略设置会覆盖其他设置。计算机设置高于用户设置（即使用户设置是后设置的）。父容器组策略设置与子容器设置发生冲突时，子容器中组策略的设置将最终生效。同一容器的多个策略按照优先权顺序进行生效。所以，当在一个容器上面链了多个GPO时，不妨仔细看看它们的顺序，很有可能问题是顺序不当引起的。
2）生效时间
在默认情况下，非域控制器的计算机每90分钟刷新一次策略，其中含有随机的30分钟时间偏移量，时间偏移量保证了多个计算机不会同时连接到同一个域控制器上面。域控制器每5分钟刷新一次，保证了紧急更新的组策略设置（安全性设置）能够得到及时执行，可以在“域控制器组策略重新刷新时间间隔”里面进行更改，如图1所示。
图1 进入“域控制器组策略重新刷新时间间隔”进行更改
在Windows 2000里面可以使用“secedit/refreshpolicy machine_policy”或“secedit /refreshpolicy user_policy”命令强制刷新，在Windows XP或Windows Server 2003使用“gpresult /force”命令强制刷新。如果新做的设置没有生效，不妨考虑一下是否为刷新时间间隔的问题。
组策略常规排错法
如果您平时是按照以上建议做的，结果组策略的某些设置还是没有按预期生效，我们就需要做排错处理了。
（1）确保客户端拿到了相关的策略。比如：希望域内所有的计算机不要显示上次登录的用户名以确保安全，可是在所有的用户端上都没有生效，说明此条策略很有可能客户端没有拿到。从Gpresult或者是组策略结果集，可以知道客户端拿到了哪些策略。前者是命令行模式，后者是图形界面，功能都是相同的。关于Gpresult的使用，读者可以参考《网管员世界》2005年10月刊中《我拿什么来诊断你—活动目录常见故障排错工具》一文，其中有详细的讲解。下面介绍组策略结果集的使用。
打开gpmc.msc，单击“组策略结果收集向导”，选择是本机还是远程计算机，选择为哪一个用户显示最终结果，我们就可以查看结果了，如图2所示。
在“组策略对象→应用的策略”中，我们能够看到出问题的客户端应用了哪些GPO，没有应用哪些GPO，如果某一条组策略没有被应用，那么设置必定没有生效，因为计算机根本就没有拿到这个策略。
正如案例中所述的那个问题（希望域内所有的计算机不要显示上次登录的用户名以确保安全，可惜在所有的用户端上都没有生效），后来在随机的客户端运行gpresult，结果发现，为计算机设置的不显示上次登录的用户名策略（当时命名为Do not Display last logon name）根本就没有应用到客户端，自然策略不会生效。
（2）如果网络里面有多台域控制器，要确保多台域控制器的策略保持一致，检查方法是运行gpotool（需要安装Windows Resource Kit工具包）。
Validating DCs...
Available DCs:
mic-technet.dc.mic
Searching for policies...
Found 4 policies
Policy {31B2F340-016D-11D2-945F-00C04FB984F9}
Friendly name: Default Domain Policy
Policy OK
==========================================================
Policy {6AC1786C-016F-11D2-945F-00C04FB984F9}
Friendly name: Default Domain Controllers Policy
Policy OK
==========================================================
Policy {90BD780C-D2E8-44CB-97B8-80B343852457}
Friendly name: Do not display logon name
Policy OK
==========================================================
Policy {CC2C8E4F-FA55-4824-AC75-0122494DCC31}
Friendly name: user
Policy OK
==========================================================
Policies OK |
这是一次运行gpotool的结果，当然，笔者这里只是模拟一个虚拟环境，如果只有一台域控制器，读者可以拿出问题日志与正常日志进行比对，便会发现问题所在。设想，如果有两台域控制器它们之间的复制出了问题，那么意味着每个域控制器的组策略不统一了，自然客户端在应用时会发生问题。
（3）检查组策略对象是否在AD中和Sysvol中，而且GUID是否与正确的GPO相关联。
1）查看组策略的GUID。
2）用Search.vbs检查LDAP协议正确性，GPO和GUID是否为真正意义的对应。
（注：Search.vbs是Windows Server 2003安装光盘Support\Tools\ Support.cab下的一个脚本工具，可以将GPO名称解析为GUID。）
使用方法：
cscript search.vbs "LDAP://dc=mydomain,dc=com"
/C:"&(objectClass= groupPolicyContainer)(displayName=Default Domain
Policy)" /P:name /S:SubTree |
将mydomain和com换成您自己的域名。
返回结果如图3所示
（3）以上两步结束后，如果仍然没有查到问题所在，可以激活“Userenv.log”。
打开注册表编辑器，定位至HKEY_LOCAL_ MACHINE\Software\ Microsoft\Windows NT\ CurrentVersion\ Winlogon。
新建dword值：UserEnv DebugLevel，数据为10002 （Windows 2000/XP），Windows Server 2003改为30002。重新启动后在%SystemRoot%\Debug\ UserMode\下可找到Userenv.log 文件。该文件对我们解决用户配置文件和组策略处理方面的问题很有帮助。
例如，有时会在该文件中发现：
USERENV(178.63c) 22:27:23:188 EvalList: Object
<cn={7AF890C0-01AB-4F23-9734-DD69D2462FA1},
cn=policies,cn=system,DC=dc,DC=mic> cannot be accessed |
这说明登录的用户对要应用给他的GPO是没有权限的，这时就要注意组策略的权限问题。
（4）如果是和安全设定有关的策略没有生效，可以开启“Winlogon”：
打开注册表编辑器，定位至HKEY_LOCAL_MACHINE\ Software\Microsoft\Windows NT\CurrentVersion\Winlogon\
GPExtensions\{827D319E-6EAC-11D2-A4EA-00C04F79F- 83A}，新建一个dword值，名称为Extension DebugLevel，数值设为2，刷新策略，这样
在以下位置Windows\ Security\Logs生成Winlogon.log，所有安全设定会被详细记录在里面。
举例来说，启动基于Windows 2000的计算机时，事件查看器大约每5分钟记录一次事件ID 1202和1000。
当查看 Winlogon.log 文件时，会发现下面的错误信息。
Error 1332: No mapping between account names
and security IDs was done.Cannot find Power Users. |
很明显，这是有人给Power Users组做了安全权利指派，但是当计算机被提升成为域控制器后，Power Users组就会被删除掉，然而组策略里却没有将其权限相应的删除，计算机就会不停地找（准确的说是对应）Power Users组，因此就会报错。
当我们在查看Userenv.log和Winlogon.log时，可以关注以下信息：fail，error，cannot等这些失败、错误信息。
经验排错法
上面说的是排错的一般方法，属于事物的普遍性，如果我们能够掌握一些特殊规律，在排错时有针对性地进行检查，效果往往会更好一些。
1．应用程序管理策略不工作
首先激活日志（注意：这里说的日志是专门监视应用程序管理策略的），打开注册表，在以下位置HKEY_LOCAL_ MACHINE\Software\Policies\Microsoft\ Windows\Installer新建一个字符串值，命名为Logging，值设为voicewarmup。这里，voicewarmup有不同的含义，其中，i：表示状态消息；w：非致命警告；e：所有错误信息；a：启动操作；r：特定操作记录；u：用户请求；c：初始用户界面参数；m：内存不足；p：终端属性；v：详细输出；o：磁盘空间不足消息。
除了修改注册表外，我们还可以在组策略中激活该日志。激活该日志后，重新执行一遍安装程序，这样整个安装程序的详细内容就会被记录下来，在命令行键入cd %temp%，查找以mis开头扩展名为log的文件就是了，文件名是随机的。
关于应用程序的安装问题，笔者的经验是，要么是GPO有问题，要么就是MSI安装包有问题。当然，还有一种特殊情况—操作系统问题，比如，有些软件就没有办法安装在特定的操作系统上，或者目标计算机的“添加/删除程序”不能正常使用。笔者的经验是，使用一个标准的MSI包进行问题隔离，看看究竟是MSI包的问题还是GPO问题，这样，排错的目标性就很明确了。
2．注册表、软件策略、登录/注销/启动/
关闭脚本不生效
检查Registry.pol 文件是否正确，该文件可以用记事本打开。
3．文件夹重定向策略不生效
关于文件夹重定向，在实际工作中这一块的问题比较多，但是这些问题都是由于管理员的粗心导致。
当您在做重定向设置时，重定向的文件夹是否是从网络路径获取的？用户是否可以通过网络找到这个文件夹？排措时可以在地址栏里使用UNC路径试试是否可以正常访问这个文件夹。
每一位用户对这个文件夹是否有写的权限？默认情况下，每一个文件夹被共享出来后，每位用户对它只有读取权限。
4．假象错误
有一类错误根本就不是组策略错误，但是很容易让人误以为是组策略错误。
（1）在域控制器计算机上每隔 5 分钟，成员服务器计算机上每隔 20 分钟，事件查看器中都会记录下列错误信息：
Userenv 1000
Windows cannot access the registry information
at \\domainname.com\sysvol\domainname.com\Policies\
{ file://\\domainname.com\sysvol\domainname.com\Policies\{31B2F340-016D
D-11D2-945F-00C04FB984F9}\Machine\registry.pol with (1398).
SceCli 1001
Security policy cannot be propagated.Cannot
access the template.Error code=3.
Userenv 1000
The Group Policy client-side extension Security
was passed flags (17) and returned a failure status code of (3).
NtFrs 13508
Description:The File Replication Service is
having trouble enabling replication from
(computername) to (computername) for C:\winnt\sysvol\domain; retrying. |
表面上看，错误是由Userenv报的，很容易让人感觉是组策略出了问题，但经过多方检查，这个错误的根源是时间不统一。
解决这一问题的方法就是将所有计算机与域控制器的时钟进行时间同步：
| net time \\(domain controller name)/set/y |
在所有出现此问题的服务器上停止然后重新启动文件复制服务，打开事件查看器，确定没有再出现错误。
（2）域控制器的组策略对象无法使用，当使用时，会记录或显示多个问题。
应用程序日志中包含下列错误消息：
UserEnv 1000 The Group Policy client-side
extension Security was passed flags
(17) and returned a failure status code of (3).
SceCli 1001 Security policy cannot be
propagated.Cannot access the template.
Error code = 3. \\domain name\sysvol\domain name\Policies\
{31B2F340-016D-11D2-945F-00C04FB984F9}\
Machine\Microsoft\Windows NT\SecEdit\GptTmpl.inf.
UserEnv 1000 Windows cannot access the
registry information at \\domain name\sysvol\
domain name\Policies\{31B2F340-016D-11D2-945F-
00C04FB984F9}\Machine\registry.pol with (51). |
当使用“域安全”策略和“默认域控制器安全设置”策略尝试访问“组策略”对象时，将显示“Group Policy Error”这一错误消息。此消息指出“Failed to Open Group Policy Object. You may not have appropriate rights. Details：The network path not found.”
原因：导致这一问题的原因是主域控制器上面有多个网络适配器，而主网络适配器却没有绑定“文件和打印共享”，自然，当域控制器尝试通过主网络适配器访问其 Sysvol 共享以读取组策略时，因为通过该适配器无法访问此共享，所以操作不成功。
同样，这个问题从根源上说也不是组策略出了问题，而是网络适配器的故障，但却是由UserEnv表现出来的。
组策略排错备忘录
（1）一定要确认客户端是否拿到了您设定的策略，很多组策略故障其实并不是真正意义上的故障，是客户端根本就没有拿到相关的策略。这里，还要注意一点，那就是组策略有计算机策略和用户策略，笔者曾经见过不少人在一个OU内（该OU下有10个用户）链接了一个组策略，内容是关闭所有计算机的自动播放，结果策略没有生效。切记，计算机策略对计算机生效，用户策略对用户生效。
（2）检查用户对组策略是否有读取权限，重点排查UserEnv中的cannot access语句。
（3）若有多台成员服务器，要确保组策略的一致性，也就是说，这些服务器之间的复制正常，方法：gpotool。
（4）安全策略关注Winlogon.log，其他问题仔细看看UserEnv.log。
（5）确保故障不是由软件Bug引起的，如何确定是否为软件Bug，笔者的经验是：做隔离，搭一个试验环境，模拟生产环境，排除其他的干扰，看看问题是否会重现。
（6）透过现象看本质，有些问题以组策略的问题形式表现出来，但往往不一定是组策略的问题。
| 
系统管理员讲述组策略排错经验谈
