微软域AD排错
常见 AD 排错工具1、enable ndsi diagnostics log:hklmsystemcurrentcontrolsetservicesntdsdiagnostics取值范围：0-3可在
常见 AD 排错工具
1、enable ndsi diagnostics log:
hklmsystemcurrentcontrolsetservicesntdsdiagnostics
取值范围：0-3
可在事件查看器目录服务中查看，3为上限, 日志量相当大，应注意调整日志文件大小。
2、dcdiag
dcdiag /v（详细输出） /c(开启所有项的测试) /a（对站点内所有DC 进行测试）
3、netdom
对客户机加入域及信任关系管理
Example:
netdom query dc
netdom query fsmo
5-10的错误是由于对网络结构的错误认识。
4、netdiag
Example:
netdiag /debug 〉netdiag041218.txt （加debug 参数为最详细记录）
notepad netdiag0411218.txt
5错误是由网络配置造成的
第二部分：AD 维护中三种常见故障：
一、DNS 配置相关故障
1、综述：AD 中DNS 起到路标和指示灯的作用，至少50的AD 故障源于DNS.
DNS 中最重要的是SRV 纪录而不是A 纪录，通常SRV 纪录对应有一个A 纪录
,SRV Record example: _ldap._tcp,dc._msdcs.xyz.com.600 IN srv 0 100 389 dcserver1.xyz.com
用户登录域时通过dns 服务器找寻dc 的，_msdcs区域中包含所有dc 的服务纪录，作用就是为了定位域控制器和全局编目服务器，win2k 中若有多个域则只有根域中有该区域，子域中没有。
2、几个验证和修复工具
（1）使用nslookup 来记录dns 记录是否完整
（2）若dns 记录缺失，可通过：
a ：重新启动Net Logon服务
b ：使用nltest.exe /seregdns （安装support tools工具后才会有）
注意dns 配置要求：允许动态更新，区域名称和AD 域名相一致，dns 服务器本身需要配置dns 域名后缀
3、实例演示：验证和修复dns 故障
2003中_msdcs区域作为独立一个区域存在，若出现机器登录域非常慢，90是dns 出了问题。
（1）若出现记录缺失情况：
stop netlogon & start netlogon 重新启动该服务，其实每次关机重启时均会重新启动该服务。
（2）若无任何记录区域
则新建记录区域，若操作过程中出现无法删除和拒绝提示时，则可能是因为多台DC 之间状态没有同步，只需稍等片刻即可。
多域环境中，_msdcs区域必须分开创建，否则只能找到本域的dc ，而找不到森林中其它域的gc 服务器
（3）修复工具
nltest.exe /dzregdns
特点：速度快且不会对用户有影响
,从安全角度考虑，最好将dns 配置成活动目录集成区域,2003中新添条件转发特性。
二、关于DC 之间的复制故障
nt4单向复制，PDC-〉BDC ，存在很多弊端。
DC 之间复制的内容：
（1）目录服务复制：主要是数据库的复制（AD 对象，包括用户，计算机等）
（2）文件复制服务（FRS)sysvol 文件夹，包括组策略实体。
2、排错工具
(1)AD replication monitor图形工具
a. 检查ad 复制
b. 图形化显示复制拓扑
c. 强制复制
（2）命令行工具repadmin
a. 诊断dc 间复制故障
b. 确认复制伙伴
c. 确认活动目录对象复制来源
d. 强制复制
dc 之间的文件复制服务
dc 之间复制sysvol 共享文件夹
（1）netlogon 共享：低版本客户端的登录脚本和系统策略
（2）sysvol 共享：为win2k 及以后客户端提供组策略，导致组策略分发不成功
命令行排错工具：ntfsutil
3、通常复制故障：
,（1）拒绝访问：时钟不同步，网络故障
（2）dns 查找故障，dsa 操作无法继续
（3）操作被排队或没有显示任何复制链接
（4）复制访问被拒绝或正在删除名称上下文
（5）站点之间存在重复的连接对象
（6）多个域控中所应用的组策略不一致
（7）目录服务因太忙而无法完成操作
其中3-7项建议等待一段时间一般会自动解决
4、实例演示：使用工具诊断复制故障
（1）AD 中通常会自动生成环形复制拓扑结构，域服务器之间的复制间隔为5分钟，3台DC 之间的同步大概需要为15分钟左右（基于100M 以太网），使用站点和服务来操作。
（2）若无法复制成功，可利用复制监视器工具来控制复制。
强制生成复制拓扑结构和显示复制拓扑结构，拓扑结构图中可以查看操作主机角色是否正常工作; 察看复制对象的USN(update serial number);察看复制过程中的一些错误
（3）dsastat
三、Operation Master Roles(fsmo)
1、何时需要转移操作主机角色？
2、决定操作主机角色拥有者：图形化接口工具和ntdsutil
3、移转方式：transfer(在线移转）和seize(强制转移)
4、移转工具：图形化接口工具（AD 用户和计算机、AD 域和信任关系、AD 架构）
5、命令行方式下转移FSMO 角色：
ntdsutil.exe
roles
,connections
connect to server servername
quit
seize pdc
rid master
infrastructure master
schema master
domain naming master
transfer
quit
尽可能使用transfer 而不是seize, 当中的servername 是即将成为操作主机角色的服务器，图形方式下，需要先连接其他的域控制器后才可以更改操作主机角色
第三部分：Troubleshooting Case Study
1、AD 的问题一般分四个层面：网络问题、活动目录的支撑服务（dns/wins/etc）、活动目录的复制问题、域控制器的个体原因。
2、典型案例：
case(1):时间源同步问题
case(2):
问题背景：用户登录或访问服务器，经常出现“由于时间差异，访问拒绝“的提示
问题解决：
与kerveros 协议有关，用来代替原先的ntlm 协议，所有的计算机（包括client 和server,os 为win2k 及以上），会自动将根域的PDC 模拟器作为时间服务器，W32Time 服务按照一定的周期进行时钟校正：从计算机启动开始，尝试以45分钟作为间隔，联系时钟服务器，进行时钟同步；如果同步成功，以8小时为间隔，进行同步验证；如果同步失败，开始尝试进行时钟同步。为了保证时间服务器正常工作，在根域的PDC 模拟器上建议设置外部时间源，指向INTERNET 上的时间服务器，在其他计算机上保证Windows Time服务正常启动。
,具体要求：dc 之间时间相差不能超过5分钟，client 与dc 之间相差不能超过30分钟
问题根源：kerberos 协议要求计算机时钟同步经过分析，发现客户端计算机启动某个应用程序，会在启动时与服务器（一台unix 计算机）进行时钟校准，而该服务器时钟与DC 始终存在约45分钟的差异，将域控制器时钟与服务器同步，并建议设定同一时间源。
CASE(3)
问题描述：某客户报告，客户端计算机启动缓慢，在出现“正在准备网络连接“提示时，会有长时间停留，经过检查发现，客户端计算机虽然已经正确配置了DNS 服务器地址，但在同时作为域控制器的DNS 服务器上，发现没有相应的记录，客户使用了SOMEDOMAIN 形式的域名。
问题原因：Win2k sp4/winxp/2003不在顶级域下注册dns 记录
解决方法：修改注册表和使用组策略（客户端本地计算机策略/管理模版/网络/DNS客户端），在客户现场，临时使用了手动加载netlogon.dns 文件的方法（应该注册的dns 记录）
systemroot/system32/config/netlogon.dns(应该写到dns 服务器内的记录) ，将记录复制到dns 服务器数据库中，应先将集成的dns 区域改成主区域，然后到dns 数据库记录文件进行粘贴，然后再修改为AD 集成的DNS 区域（存在多个域时工作量大）
CASE(4)通过修改注册表强行卸载dc:
键值位置：hklm/system/controlsset/control/productoptions/ProductType LanmanNt 修改为/ServerNT，重启机器此时然后便可以卸载dc 了，原理为启动时会检查该键值，如果为ServerNT ，便不启动dc 所需的相应服务，但也有些副作用，如intersitemesseging 服务会报错，应为它仍然会启动，而它相关联的服务均已停止故出现报错信息，此时应该将该服务设为手动或禁用，强行卸载完DC 后，应该在保留的DC 上利用NTDSUTIL 工具中的metadata cleanup 将无用的信息清除掉。
不能卸载之可能原因：网络问题，不能连通操作主机；长久没有同步等等。
本文来自“十万个为什么”电脑学习网 http://www.why100000.com