排查 AD 复制错误 8477 - Windows Server

本文介绍 Active Directory 复制失败并出现错误 8477 的问题：“复制请求已发布;正在等待答复”。原始 KB 数： 2758780 注意家庭用户：本文仅适用于技术支持代理和 IT 专业人员。如果你正在寻找解决问题的帮助，请询问Microsoft社区(https://answers.microsoft.com)。现象本文介绍对 Active Directory 复制错误 8477 进行故障排除时涉及的症状、原因和解决方法步骤：

本文介绍 Active Directory 复制失败并出现错误 8477 的问题：“复制请求已发布;正在等待答复”。

原始 KB 数： 2758780

注意

家庭用户： 本文仅适用于技术支持代理和 IT 专业人员。如果你正在寻找解决问题的帮助，请询问Microsoft社区。

现象

本文介绍对 Active Directory 复制错误 8477 进行故障排除时涉及的症状、原因和解决方法步骤：“复制请求已发布;正在等待答复”。

本文中讨论的症状通常与事件 8477 的发生有关，但也可能与与缓慢或延迟复制相关的其他事件观察到。在排查此类问题时，应考虑可能导致复制延迟并相应地修正的所有因素。

repadmin.exe /showreps /verbose 的输出可能会报告复制尝试失败，错误 8477 - “复制请求已发布;正在等待答复”

repadmin.exe /showreps /verbose

DC=Contoso,DC=com  
Default-First-Site-Name\DomainController via RPC  
    DSA object GUID: <source DCs ntds settings object object guid>  
    Address: <source DCs ntds settings object object guid>._msdcs.Contoso.Com  
    DSA invocationID: <source DCs NTDS DB invocation id>  
    DO_SCHEDULED_SYNCS WRITEABLE COMPRESS_CHANGES NO_CHANGE_NOTIFICATIONS PREEMPTED  
    USNs: 1158544/OU, 111052/PU  
    Last attempt @ <Date Time> was delayed for a normal reason, result 8477 (0x211d):  
The replication request has been posted; waiting for reply.  
    Last success @ <Date Time>

来自repadmin.exe/queue 的输出可能会报告大量排队的入站复制请求和前所未有的长时间执行

Repadmin /queue

repadmin running command /queue against server localhost  

Queue contains 26 items.  
Current task began executing at <Date Time>.  
Task has been executing for 86 minutes, 12 seconds.  

[6485] Enqueued <Date Time> at priority 590  
SYNC FROM SOURCE  
NC DC=Contoso,DC=com  
DC Default-First-Site-Name\DomainController  
DC object GUID <source DCs ntds settings object object guid>  
DC transport addr <source DCs ntds settings object object guid>._msdcs.Contoso.com  
ASYNCHRONOUS_OPERATION WRITEABLE PERIODIC NEVER_NOTIFY PREEMPTED

注意

当入站复制请求排队时，通常会在抢占的复制任务后观察到事件 8477。此事件由事件 8461 指示 - 复制操作已抢占。

使用dcdiag.exe时，最近升级的域控制器的初始化可能会延迟，等待完成初始同步

Directory Server Diagnosis  

Performing initial setup:  
   Trying to find home server...  
   Home Server = DomainController  
The directory service on DomainController has not finished initializing.  
In order for the directory service to consider itself synchronized, it must  
attempt an initial synchronization with at least one replica of this  
server's writeable domain. It must also obtain Rid information from the Rid  
FSMO holder.  
The directory service has not signalled the event which lets other services  
know that it is ready to accept requests. Services such as the Key  
Distribution Center, Intersite Messaging Service, and NetLogon will not  
consider this system as an eligible domain controller.  
   * Identified AD Forest.  
   Done gathering initial info.  
The directory service on BOULDERDC01 has not finished initializing.  
In order for the directory service to consider itself synchronized, it must  
attempt an initial synchronization with at least one replica of this  
server's writeable domain. It must also obtain Rid information from the Rid  
FSMO holder.  
The directory service has not signalled the event which lets other services  
know that it is ready to accept requests. Services such as the Key  
Distribution Center, Intersite Messaging Service, and NetLogon will not  
consider this system as an eligible domain controller.  
Done gathering initial info.

注意

在将新的副本域控制器提升到环境中的过程中，上述dcdiag.exe的输出是正常行为。在这种情况下，应给予 8477 次时间，以便清除正常复制周期，然后再考虑或执行修正活动。

使用dcdiag.exe时，“复制”测试用例可能会发出“复制延迟警告”

Starting test: Replications  
   REPLICATION LATENCY WARNING  
   DomainController: A long-running replication operation is in progress  
      The job has been executing for 84 minutes and 22 seconds.  
      Replication of new changes along this path will be delayed.  
      This is normal for a new connection, or for a system
      that has been down a long time.  
      Enqueued <Date Time> at priority 90  
      Op:             SYNC FROM SOURCE  
      NC DC=Contoso,DC=com  
      DSADN <source DCs ntds settings object object guid>  

DSA transport addr <source DCs ntds settings object object guid>._msdcs.Contoso.com  
   ......................... DomainController passed test Replications

可以在目录服务事件日志中记录“NTDS 复制”事件 1580

事件源	事件 ID	事件字符串
NTDS 复制	1,580	长时间运行的Active Directory 域服务入站复制任务已完成以下参数。已用时间（分钟）： 84 操作：同步副本选项： 0x21000051参数 1： DC=Contoso，DC=com 参数 2： <源 DC ntds 设置对象对象 guid> 参数 3：参数 4：长时间运行的复制任务也可能发生在系统不可用或目录分区长时间不可用时。长时间运行的复制任务可能指示大量更新，或源目录服务中发生的大量复杂更新。在非关键时间执行这些更新可能会阻止复制延迟。在添加新目录分区以Active Directory 域服务时，长时间运行的复制任务是正常的。由于新的安装、全局目录升级或知识一致性检查器（KCC）生成的连接，可能会出现这种情况。其他数据错误值：操作成功完成。

原因

8477（复制请求已发布;正在等待答复）状态是信息性的，表示正常的 Active Directory 复制操作，指示复制当前正在从源进行，尚未应用于目标域控制器数据库副本。

但是，长时间存在此事件可能表明目标域控制器上的 Active Directory 复制出现问题。可能的原因可能包括：

低可用物理内存、高延迟或低带宽网络链接、CPU 使用率过高或磁盘 I/O，用于域控制器正在复制的数据量
Active Directory 域服务中对象的更改率高（AD DS）
可能会妨碍或延迟正常复制功能的第三方实用工具
未启用链接值复制的大型组（大于 5000 个成员）
最近对 Active Directory 架构的修改，其中修改或编制了大量架构属性

解决方法

至少应在复制合作关系中对目标域控制器执行复制错误 8477 的调查。本文的解决方法部分将讨论 Active Directory 管理员应根据“原因”部分解决错误 8477 的可能原因的技术。

低可用物理内存、高延迟或低带宽网络链接、CPU 使用率过高或磁盘 I/O，用于域控制器正在复制的数据量

Active Directory 域控制器应尽可能少地配置其他角色和应用程序，理想情况下，域控制器应该是仅用于服务查询和身份验证请求的单一用途服务器。排查 Active Directory 性能问题时，最好先分析系统是否有不必要的或冗余的任何其他应用程序、服务或任务。

作为初始步骤，IT 专业人员应检查任务管理器（以及适当情况下的资源监视器）的总体 CPU 和内存使用情况，以确定它是否异常高或偏离预定义基线。如果不存在基线，Microsoft最佳做法表明，持续和重复 CPU 使用率超过 80% 将被视为高，应进一步调查。

排查域控制器上的 CPU 使用率过高问题 - 排查域控制器上的高 CPU 使用率问题

有关磁盘使用情况，在Active Directory 域控制器上，Ntds.dit 和 edb.log 文件应该是系统上最活跃的文件。若要确定情况是否如此，应执行性能日志记录和分析（如下所示）。

低带宽、高延迟或繁忙网络连接也可能导致Active Directory 域控制器出现错误 8477。应使用性能监视器、网络监视器或其他此类工具从域控制器收集网络性能数据指标。有关监视和测量复制流量的指南，请参阅 Active Directory 复制流量。

性能监视器包括直接开箱即用的服务器性能顾问的主要功能。在系统数据收集器集中，Active Directory 诊断集类似于服务器性能顾问，生成包含 Active Directory 性能调查关键指标的报告，并为Active Directory 域控制器上的非特色行为提供警告。报告顶部包含任何警告。下面是一个示例：

WARNING	-
症状：	系统遇到过多分页
原因：	系统上的可用内存较低。
详细信息：	系统上的总物理内存无法处理负载。
解决方法：	升级物理内存或减少系统负载
相关：	内存诊断
症状：	在目录服务器上，Ntds.dit 和 Edb.log 应该是最活跃的文件。在这种情况下，C：\Windows\NTDS\ntds.dit 的 I/O 速率最高（84.622 操作/秒）。

Active Directory 域服务中对象的更改率高（AD DS）

在繁忙的 Active Directory 环境中，每个计划复制之间的对象可能会发生大量更改。如果环境中预期会出现这种情况，则应适当调整组织基础结构的各个方面，以简化有效的复制。

如果 IT 管理员不知道或不期望大量更改并且收到错误 8477，则应进行调查以确定环境中发生哪些更改，以及这些更改是预期还是应用程序或服务出现问题的结果。执行此任务的有效手段是确定使用 uSNChanged 属性（特定域控制器上的最高 uSNChanged 值表示 High-Watermark USN）更改的对象。

针对显示事件 8477 的域控制器运行 repadmin /showreps /verbose 将显示当前的高水印，后跟 /OU：

DC=Contoso,DC=com
Default-First-Site-Name\DomainController via RPC  
    DSA object GUID: <source DCs ntds settings object object guid>  
    Address: <source DCs ntds settings object object guid>._msdcs.Contoso.Com  
    DSA invocationID: <source DCs NTDS DB invocation id>  
    DO_SCHEDULED_SYNCS WRITEABLE COMPRESS_CHANGES NO_CHANGE_NOTIFICATIONS PREEMPTED  
    USNs: 1158544/OU, 111052/PU  
    Last attempt @ <Date Time> was delayed for a normal reason, result 8477 (0x211d):  
The replication request has been posted; waiting for reply.  
    Last success @ <Date Time>

根据发生的更改数，域控制器上存在的最高 USN 可能会快速递增，以确定要更新的对象，建议在源复制合作伙伴上，以下命令针对相关的命名上下文运行：

Repadmin /showattr DomainControllerName DC=Contoso,DC=com /subtree /filter:"(uSNChanged>=highestcommitedusn)" /atts:objectclass

特定应用程序或服务（如 Exchange 收件人更新服务可能会对 Active Directory 属性进行常规更改，如果生成的复制流量不可管理，可能需要对其进行优化。

可能会妨碍或延迟正常复制功能的第三方实用工具

应针对性能和可支持性最佳做法配置和优化第三方应用程序。某些应用程序（如果未针对 Active Directory 性能的最佳做法进行配置）可能会导致正常Active Directory 域控制器功能受到影响。

注意的应用程序包括（但不限于）：

病毒扫描软件
监视代理
标识同步和管理应用程序
备份软件和代理

针对当前受支持的 Windows 版本的企业计算机病毒扫描建议

未启用链接值复制的大型组（大于 5000 个成员）

链接值复制在 Windows 2000 Server 林中不可用。由于原始更新必须在单一数据库事务中写入，并且由于单个事务的实际限制为 5,000 个值，因此 Windows 2000 Server Active Directory 不支持超过 5,000 个值的成员身份。此大小的组表示对数据库写入操作的限制，该操作需要记录对该大小属性的更改，以及通过网络传输该大量数据。这在 Windows 2003 或更高功能级别的林中不同，其中启用了组成员身份的链接值复制（LVR）。

从 2000 功能级别升级域时，携带的任何组的成员身份都被视为旧版，仍可能导致复制问题：

2003 功能级别的林可以删除并恢复组成员，使其启用 LVR。随着时间的推移，随着安全主体的添加和从组中删除，成员将慢慢为 LVR 启用。

注意

大型组导致复制问题和延迟时，通常还会在目录服务事件日志中记录事件 1479 和 1519。

使用 repadmin /showobjmeta时，可以确定组中的旧成员并将其转换为支持 LVR 的成员（如有必要）才能解决问题。这些用户用值 LEGACY“Type”表示：

repadmin /showobjmeta DomainControllerName "CN=Administrators,CN=Builtin,DC=Contoso,DC=Com"

3 entries.  
 Type    Attribute     Last Mod Time                            Originating DSA  Loc.USN Org.USN Ver  
======= ============  =============                           ================= ======= ======= ===  
 Distinguished Name  
        =============================  
PRESENT       member <Date Time>                    Default-First-Site-Name\DomainController    8203    8203   1  
        CN=Administrator,CN=Users,DC=Contoso,DC=Com  
PRESENT       member <Date Time>                    Default-First-Site-Name\DomainController   12398   12398   1  
        CN=Enterprise Admins,CN=Users,DC=Contoso,DC=Com  
PRESENT       member <Date Time>                    Default-First-Site-Name\DomainController   12378   12378   1  
        CN=Domain Admins,CN=Users,DC=Contoso,DC=Com  
LEGACY       member <Date Time>                    Default-First-Site-Name\DomainController   198458   198458   1
        CN=mjordan,CN=Users,DC=Contoso,DC=Com

最近对 Active Directory 架构的修改，其中修改或编制了大量架构属性

属性定义存储在架构目录分区中的 attributeSchema 对象中。对 attributeSchema 对象的更改会阻止其他复制，直到架构更改完成。在复制架构目录分区以外的任何目录分区期间，复制系统首先检查源和目标域控制器的架构版本是否达成一致。如果版本不同，则会重新计划其他目录分区的复制，直到架构目录分区同步。

通过使用 LDIFDE 或应用程序随附的自定义二进制文件（即，Microsoft Exchange、Operations Manager 等）修改架构可能会将索引属性添加到架构目录分区。根据更新的大小，复制延迟可能会导致大型数据库。

在这种情况下，8477 状态可能显示为暂时性问题，应在成功复制高优先级架构更新后自行解决，所有其他复制都会赶上目录中积压的更改。

数据收集

如果需要Microsoft支持方面的帮助，建议按照使用 TSS 收集 Active Directory 复制问题的信息中所述的步骤收集信息。

详细信息

Active Directory 复制模型的工作原理

现象