AD复制排错

解决方案快照
问题：AD复制问题排错
解决方案：使用一种基本的方法，利用Windows Server支持工具监控和修复AD复制的问题。
需要条件：Windows Server 2003或Windows 2000，Windows Server支持工具
难度：3（最高5）
解决方案步骤：
1、检查目标DC的OS和目录服务是否运行正常；
2、检查DNS在源和目标DC上是否运行正常；
3、确认目标DC可以解析到源DC；
4、检查Kerberos和它所依赖的服务；
5、检查防火墙设置。

AD复制是当一个DC的目录有变动时，自动复制到其它DC的方法。AD是非常健壮的服务，容错性很强。由于AD可以是分布式的多DC架构，丢失部分数据并不会影响到整个目录服务。在AD森林中，我们不仅要监控DC的基本情况，还需要关注DC间复制的运行情况。以我的经验，如果不对森林中的复制进行监控，经过一段时间之后很可能会崩溃，即使你已经很仔细地进行DC的配置也无济于事。监控和修复复制中出现的问题比修复那些不断在森林中累积的问题要容易得多。但不管你是否对AD复制进行了监控，你肯定无法避免地遇到需要在AD中排查错误。在本文中我会介绍一些复制的基本原则，以及一些在AD复制排错时经常用到的简单的方法。AD复制的排错有时会很迷糊；按照我的步骤可以让你觉得这项任务还是有一些方法的，而不是靠魔法或感觉。

基础
要找出一个最好的复制排错的方法是很困难的。当然你肯定是希望使用一种能尽可能快的方法来解决问题；不过，也不能跳过最终可能会拖延整个排错进程的步骤。我发现使用一个逻辑性强，彻底的方法效果是最好的。大家希望直接进入正题，使用一个全能的排错工具，这种反应是很自然的，但是你应该首先使用一个逻辑性较强的方法来检验整个过程是否能顺利地进行。在经过多次排错，经验丰富之后，你可以跳过其中的许多步骤。但最开始还是要仔细地执行每一步，以确保你不会直接做出错误的判断，或者不得不重来一次。从检查DC的OS开始，然后检查目录服务的情况。接着检查DC间的基本通信。最后，检查DC间在互相判断是否认证时所使用的协议是否能正常运行。按照这些步骤可以帮助大家解决90%以上的复制问题。

检查基础架构
第一步是检查DC的OS是否工作正常。复制错误可能是由于DC上的一些本地错误而导致的，你需要确认服务器的基础服务是正常的。如果你之前没有做过，那要在所有生产系统上先安装最新的Windows Server支持工具。（本文我介绍的所有工具都是Windows Server支持工具。）可以从微软下载中心下载这些工具（http://www.microsoft.com/downloads）。输入关键字“support tools”，按照你的操作系统版本和SP版本来查找。在一个大环境中解决所有问题可能是不切实际的；不过，你可以使用Internet搜索引擎和微软知识库（KB，http://support.microsoft.com/search/?adv=1）来解决大部分影响重大的问题。
安装好Windows Server支持工具后，先查看事件日志。首先，检查系统日志中的警告和错误。如果在系统日志中发现错误，试试运行NetDiag。即使不用它的命令行选项，NetDiag也会运行23个和系统网络配置相关的测试。这些测试中包括一些和域成员关系、DNS、客户端配置、信任关系、Kerberos和LDAP功能相关的测试。如果你发现某个测试有问题，用/test:testname和/v选项再运行一次NetDiag，获取关于这个测试的详细分析结果。本文稍后还会用到另外一个重要的NetDiag选项/fix，它可以重新注册服务器的DNS入口。
如果目录服务日志有错误，运行DCDiag。DCDiag是一款用于对DC进行全面测试的工具。即使不使用命令行选项，DCDiag都可以运行27个和DC相关的测试。和NetDiag相似，如果你发现某个测试有问题，用/test:testname和/v选项再运行一次DCDiag，获取详细测试分析数据。别把太多时间花在这些系统日志测试的错误上；系统日志中任何最近的错误都可能导致测试失败。
如果在上面的测试中没有发现什么问题——即，NetDiag和DCDiag没有发现任何OS或目录服务相关的错误——那就请开始检查复制吧。最佳的方法是从检查DCDiag测试结果开始，因为DCDiag会运行一些扩展的复制测试。
现在我们使用如图1所示的域来看看如何排查一个常见的错误。这个域的名称是Deuby.net，有3台DC。名为Godan和Kohai的DC位于Hub站点中。名为Sandan的DC位于Branch站点中，通过一个带有复制的站点链接，连接到Hub站点，该复制的时间间隔是15分钟。假设更新没有从Kohai复制到Godan。复制总是入站的操作，因此，即使站点中的复制是由一台DC的修改而触发的，你也需要考虑到目标DC上已经从其它DC上主动“拉”过来的更新。从应该接收更新的DC上开始你的排错吧。在我的示例中，这台DC是Godan。

图1：有3台DC的域的示例

图2是在Godan上运行DCDiag输出结果的一部分。注意复制测试会因为错误“[KOHAI] DsBindWithSpnEx()由于错误1722失败，RPC服务器不可用。”失败，尽管这个错误信息很难理解，我们仍然可以通过这个信息找到问题的原因。这个问题很明显和Kohai这台DC相关。但“DsBindWithSpnEx()”是什么意思？“BindWithSpn”告诉我们的是当Godan试图绑定（即，连接和认证）到Kohai时出现错误了。因而这个问题似乎是因为Godan无法和Kohai进行通信而导致的。

图2：DCDiag的输出

我们需要判断Godan是否可以定位到它的复制伙伴Kohai。第一个要做的测试是ping Kohai的IP地址，检查最基本的网络连接。如果没有问题，可以用Kohai的名字来ping（即，用DNS的A记录）。不过，利用这种方法并不能做出结论，因为DC并不是通过解析它复制伙伴的A记录（例如，dc1.mycompany.com）来找到它们的，而是通过解析一个特定的DNS规范名称（即CNAME Alias），这个名称在森林中是唯一的。
森林中的每台DC都必须为DsaGuid._msdcs.ForestName名称注册它的CNAME；这个CNAME可以在复制系统中标识出这是一台DC。CNAME记录会映射到DC的A记录，A记录中包含了它的IP地址。例如，DNS CNAME为dc1.mycompany.com的可能是d40c01da-23fa-46e6-8bf3798503e2590f._msdcs.mycompany.com。CNAME记录是d40c01da-23fa-46e6-8bf3798503e2590f._msdcs.mycompany.com CNAME dc1.mycompany.com。注意目录服务代理（DSA，Directory Service Agent）的GUID（全球唯一标识）中第一部分的GUID是DC的CNAME（确切地说是objectGUID属性），而不要误解为DC计算机对象的GUID。实际上，它是站点容器DC中的NTDS Settings对象的GUID。例如，如果DC1在Hub站点中，它的DN（Distunguished Name）可能是CN=NTDS Settings，CN=DC1，CN=Servers，CN=Hub，CN=sites，CN=configuration，DC=mycompany，DC=com。
如果出现问题的DC不能解析它复制伙伴的CNAME，那它就接收不到更新。因此，你首先要找出Kohai基于GUID的DNS CNAME；然后看看Godan能否解析到这个CNAME。可能最简单的方法是启动AD站点和服务（dssite.msc），展开到Godan的站点（即，Hub，Server容器，KOHAI计算机对象），然后在NTDS Settings容器上点击右键，选择属性。Kohai的CNAME存储在DNS Alias字段中，如图3所示。将该字符串复制并粘贴到Godan的命令行中，如图4所示，用于判断复制引擎是否能解析Kohai。如果DNS不能通过Kohai的CNAME来解析它，复制就不能进行。注意使用与Godan的CNAME类似的查询就可以正确地解析。

图3：查看Kohai的CNAME

图4：判断复制引擎是否能解析Kohai

现在我们已经找到了问题，可能是Kohai的DNS CNAME丢失了。有两种方法可以进行重新注册。最直接的方法是重启Netlogon服务；不过，这种方法会使得Kohai和它的活动用户间的通信暂时不可用。而如果DC出现了复制问题就要导致它的服务暂时不可用，这并不是我们想要的。另外一种影响较小的方法是运行NetDiag /fix。/fix参数是专门用于重新注册DC需要的所有DNS记录。注册好了DNS记录后，NetDiag可以干净地运行，但会报一个警告，新添加的CNAME需要一段时间才能复制到第二台DNS服务器上（即网卡的DNS配置中指定的第二台DNS服务器）。

DNS的错误配置
从上面的例子可以看出，DNS的配置错误是导致AD出现问题的最主要的根源。DNS配置很复杂，而且与AD的功能紧密地集成在一起；许多错误的方法都可能导致DNS配置出现问题。如果你的DC出现DNS查找失败或其它“无法定位”等类型的错误，你需要检查以下设置。
检查DC上的客户端设置的IP地址是否正确（本地连接的TCP/IP属性）。如果DC同时还是DNS服务器，建议的配置是将主DNS入口指向它自己。（在Longhorn Server中，如果Dcpromo在运行，系统会自动将DNS入口指向自己，即127.0.0.1。）第二台DNS服务器应该指向相同域中的另一台DC。要了解更多关于DC上不同类型的DNS客户端配置的利弊，请参见微软的文章“Best practices for DNS client settings in Windows 2000 Server and in Windows Server 2003”（http://support.microsoft.com/kb/825036）。
DC的主DNS服务器是它定位网络资源的唯一方法。因此，你可以通过控制DC的主DNS入口来控制它可以访问哪些服务器和域。如果你不知道DC自己的DNS服务是否在正常运行，把主DNS入口指向另外一台正常的DNS服务器。
确认DC是否已经注册了它所需要的资源记录。和复制相关的有3条记录。两个CNAME（前面已经讨论了）及A记录（即，主机名到IP地址的解析）。可以运行DCDiag /test:connectivity来检查这些记录是否已经注册到DC的主DNS服务器上，如果没有注册或有问题，还可以用NetDiag命令来重新注册这些记录。如果仍然注册失败，运行DCDiag /test:Registerindomain /Dns Domain:dnsdomainname来检查当前DC的配置是否能正确地进行注册。A记录必须映射到正确的IP地址。记住，这些注册项必须复制到该DC的复制伙伴使用的DNS服务器上。（注意IPConfig /RegisterDNS命令并不能完全注册好这些DC需要的DNS记录。）
对于在森林配置中的子域DC，你需要再检查第三条记录：Glue记录。Glue记录是DNS服务器提供给森林的子域使用的A记录，保存在根域的正向查找区域中。Glue记录可以解决一系列catch-22循环引用的问题：要从域外查找子域中的一台主机，需要先查询已经通过域认证的DNS服务器；不过，你无法解析到认证服务器，因为它的A记录正位于你要获取DNS信息的域中！在根域上为子域的DNS服务器设置第二套A记录就可以解决这个引用问题，从而可以将子域连接到根域。使用DCDiag /DnsDelegation参数（DCDiag /test:DNS /DnsDelegation）可以对DC的Glue记录进行测试。

访问拒绝
第二种常见的错误一般是DC和它的复制伙伴的访问被拒绝。在常规情况，访问的问题不会出现，因为所有DC的机器帐户都是Enterprise Domain Controllers组的成员。因此，出现了访问拒绝的错误就意味着在复制成员间存在认证问题。最常见的根源是其中一台DC上的时间不同步。复制自身并不依赖于时间——但是Kerberos却依赖于时间。Kerberos要求DC间必须进行时间同步；如果它们的内部时钟出现5分钟以上的时差（默认值），Kerberos就会出错，你会收到访问源DC被拒绝的错误信息。系统日志中会记录Kerberos错误，同时还很可能包含W32Time错误。
使用Net Time /QuerySNTP命令来查看哪些DC的时间服务器有问题。从定义上说，DC是域的成员。如果DC不是根域的PDC竞争者，它的时间服务器的配置应该是空的，因为非PDC的DC，它的默认Network Time Protocol（NTP）服务器是域中的PDC。如果出现问题的DC位于子域中，PDC会把根域中的DC当作时间源，而且这些DC反过来会把父域（通常是根域）的PDC当作整个森林的权威时间源。使用Net Time /SetSNTP:命令移除对某个指定时间服务器的引用。然后可以用手动用W32tm命令来控制DC的NTP设置。要强制DC定位一个时间源并和它进行同步，运行W32tm /Resync /Rediscover命令。还可以运行W32tm /Config /Syncfromflags:DOMHIER命令和域中的DC进行同步。要检查域中所有DC的NTP设置，运行W32tm /Monitor命令。看看系统托盘上的时钟何时会发生变化。
如果时间已经很久未进行同步，DC自己的Kerberos票据已经过期，遇到这种情况就必须在DC上禁用掉Key Distribution Center（KDC），然后重启。（要禁用KDC，在控制面板的服务程序中，停止服务，并将启动类型设置为禁用。）这些操作会清空Kerberos票据，并强制让DC从其它DC上获取新的票据。

其它说明
首先，要有耐心。企业环境中的复制可能需要一段时间才能完成，在排错时同样如此。例如，如果一台DC没有响应，Knowledge Consistency Checker（KCC）会等待90分钟才重新计算DC的连接对象。
在现在这个安全至上的时代，要考虑到防火墙设置的变化也可能会导致复制失败。还要检查那些无法ping通的服务器，尽管它们自身是正常运行的，以及那些某些协议正常，但有些协议却没有响应的服务器。要了解防火墙所需的DC端口，请参阅微软的文章“Active Directory Replication over Firewalls”（http://www.microsoft.com/technet/prodtechnol/windows2000serv/technologies/activedirectory/deploy/confeat/adrepfir.mspx）。
关于各种Windows Server产品所需要的端口，请参阅微软知识库文章“Service overview and network port requirements for the Windows Server system”（http://support.microsoft.com/kb/832017）。
如果你觉得目录日志提供的信息仍然不够，访问注册表的HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Ntds\Diagnostics子键，启用NTDS日志。要启用哪个键值取决于你需要调查的区域（例如，Knowledge Consistency Checker，Name Resolution，Replication Events）。默认值是0，最大值是5。通常你可以设置为3。监控目录日志以外的日志，如果你不再需要日志那就禁用它。
信任KCC。不要在KCC看起来没有按照你的预期那样创建拓扑时去怀疑它。如果KCC并没有像预期那样运行，你的站点拓扑很可能并没有按照你预计的那样进行配置。例如，你可能需要确认和该DC所属站点相关联的子网是否能连接到DC的IP地址。
最后，如果你看到DC已经很长一段时间没有进行复制的错误，你最好不要再浪费时间进行排错了。你必须重装DC，从AD中移除它的元数据，然后重新加入AD。一位MVP同事曾经说过，“DC就像一队士兵一样；你可以踢走其中一个，把另一个类似的放在他的位置上。”

放下你的指挥棒
复制是AD的关键功能，但给复制排错通常被认为是一种黑色艺术。要减少复制的神秘因素，首先要使用一种逻辑性很强的方法来保证这种方法是可行的；然后，检查DC的操作系统是否能正常工作，检查它的目录服务、DNS配置、DC间的通信、Kerberos和它的依赖项（例如，Windows时间服务），以及防火墙配置。按照本文提供的这些步骤进行操作，可以把AD复制排错的过程从妖术变成靠得住的方法。