专 题 |
电脑入门 | 操作系统 | 办公软件 | 电脑DIY | 网页制作 | 等级考试 | 网络专栏 |
会员登陆 | 会员退出
会员注册 | 会员列表
 当前位置:> 网络学院 > 阅读新闻 打印本页


网管经验共享:组策略相关故障排错经验谈

 时间:2006-9-4 11:19:30
 

 对于网络管理员来讲,关于组策略的问题可能听到最多的抱怨就是:“我设置了一个策略,为什么它不生效?”。对于一些比较大的网络环境,组策略可以减轻网管人员的管理工作,但其出问题的几率还是比较大的。这一方面是由于我们在日常操作时不慎引起的,另一方面是由于策略相互影响而造成最终的结果与设想不一致。

  组策略应用要点

  这里,笔者给出几点微软不推荐的做法:

  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 2003使用gpresult /force强制刷新。如果新做的设置没有能够生效,不妨考虑一下是否为刷新时间间隔问题。

 

组策略常规排错法

  如果您平时是按照以上建议做的,结果组策略的某些设置还是没有按照预期生效,我们就需要做排错处理了。

  1.首先,确保客户端拿到了相关的策略。比如,希望域内所有的计算机不要显示上次登录的用户名以确保安全,可是在所有的用户端都没有生效,说明这条策略很有可能客户端就没有拿到。从Gpresult或者是组策略结果集,可以知道客户端拿到了哪些策略。前者是命令行模式,后者是图形界面,功能都是相同的。下面介绍组策略结果集的使用。

  (1)打开gpmc.msc,单击组策略结果收集向导,选择是本机还是远程计算机,选择为哪一个 用户显示最终结果,我们就可以查看结果了(如图2)。

  

  图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 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 返回结果

  3.以上两步结束后,如果仍然没有查到问题所在,可以激活userenv.log:

  打开注册表编辑器,定位至HKEY_LOCAL_MACHINE\Software\ Microsoft\Windows NT\ CurrentVersion\Winlogon。

  新建dword值:UserEnv DebugLevel,数据为10002 (Windows 2000/XP),Windows 2003改为30002。重新启动后在%SystemRoot%\Debug\ UserMode\下可找到Userenv.log 文件。该文件对我们解决用户配置文件和组策略处理方面的问题很有帮助。

  例如,有时会在该文件中发现:

  USERENV(178.63c) 22:27:23:188 EvalList: Object cannot be accessed

  这说明登录的用户对要应用给他的GPO是没有权限的,这时就要注意组策略的权限问题。

  4.如果是和安全设定有关的策略没有生效,可以开启Winlogon:

  打开注册表编辑器,定位至HKEY_LOCAL_MACHINE\Software\ Microsoft\Windows NT\ CurrentVersion\Winlogon\ GPExtensions\{827D319E-6EAC-11D2-A4EA-00C04F79F83A},新建一个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.透过现象看本质,有些问题以组策略的问题形式表现出来,但往往不一定是组策略的问题。

 

【】【 】【关闭】来源:铁通呼伦贝尔信息港   

 ·上一条:看RMVB影片也中招 查杀媒体文件病毒 (9-4)
 ·下一条:省钱大法 手机红外线连接笔记本电脑上网 (9-4)
 相关专题:
 尚无信息
 相关信息:网管经验共享:组策略相关故障排错经验谈
 尚无信息
╣ 网管经验共享:组策略相关故障排错经验谈 会员评论[共 0 篇] ╠
╣ 我要评论 ╠
姓 名:   密 码:   新人注册
  推荐文章  
- 网络管理之ARP协议篇
- 网络服务器架构概述
- 动态主机配置协议
热门图片信息
尚无热门图片