组策略故障实际案例排错

场景描述:

一朋友公司,遇到这样一个问题,不管用户端的DNS是手动指定还是DHCP自动分配,都解析不了,如图,手动指定的是192.168.1.5,但nslookup的时候却是192.168.1.88

clip_image002

网络拓扑:根据朋友的描述,我画了一个拓扑图

clip_image004

192.168.1.88 是原来2003的dc地址

192.168.1.5 是08R2的dc地址

由于公司需要,公司从2003的域模式迁移到了08R2上,并确认信息复制没有问题的情况下,退出了2003的dc并降级删除!迁移步骤绝对没有报错!

然而现在出现的现象就如开头所看到的,不管是手动还是DHCP自动配置DNS,都不能进行解析,他会首先找原来的2003DC作为解析源

问题分析:

1,问题发生时间:自动2003dc迁移到08R2,并且2003dc降级退出以后,由此我们可以知道大概是在什么样的情景下隐患的造成了我们现有的故障

2,问题发生的对象:所有加入域的计算机都这个现象,没有加入域的计算机一切正常,由此可以知道,问题大概出在服务器端,并且DNS没有问题,可能是某个全局设置有问题?

3,由以上2点,我们大概已经把目标锁定到了组策略,因为只有组策略的设置可以是全局的,可以控制计算机的所有相关设置,为了验证这一点,我让他弄了一台新电脑在Workgroup一切正常,加入域后就不正常了,这就说明了问题,计算机加入域之后,设置的变化只有组策略能做到!而且是全局策略!

问题解决:

1, 打开服务器的gpmc,查看我们现有的策略,发现存在的全局策略太多,如果一个一个的去看很费时间,那么我们可以通过2个方法来快速的定位,第一个就是点中其中一个策略,然后在右边查看设置一栏,一个一个的去看,这个时效性也不是很高!但不失为一个办法!

clip_image006

2, 打开一台客户端的运行,并收集客户端所应用的策略,通过对每个策略的检查,发现在计算机策略―管理模板―网络―DNS客户端,已经被启用,并可以看到GPO的名字是DNS_Client,这个方法效率相对来说高了一点!

clip_image008

3, 定位好了以后,我们就可以到服务器上进行修改,删除原来2003的设置,并添加为08R2的设置即可恢复网络

clip_image010

总结:

从这个事故当中,我们可以看到,就算你记忆力在好,真都不如烂笔头,不要太高估自己,在IT运维过程中,自己所更改的设置,所操作的步骤,特别是不是细节的细节,还是尽量的记录下来,这对于后期的排错会很有帮助,这不是危言耸听,值得你借鉴!


IT之梦---你---我---他

2013年05月13日 23:45

你可能感兴趣的:(客户端,dns,无法解析,nslookup,组策略)