排查域控制器同步延迟需分四步：先用repadmin /replsummary概览健康度，关注标红错误及超15分钟延迟；再用repadmin /showrepl逐台检查复制链路状态与错误码；接着用repadmin /showobjmeta比对对象元数据确认变更传播情况；最后用repadmin /replicate手动触发复制并验证响应。
排查域控制器间同步延迟，核心是快速定位复制是否卡住、卡在哪一环、以及延迟程度。repadmin 是最直接有效的工具，不需要额外安装，所有域控制器自带。
确认当前复制整体健康度
运行 repadmin /replsummary，这是第一步也是最关键的概览命令。它会列出所有域控制器，显示每台 DC 的入站复制失败次数、最近一次失败时间、以及延迟估算（如“0 mins”或“124 mins”）。重点关注标红的“* IN ERROR *”项和延迟超过 15 分钟的条目——这通常已超出常规复制窗口，属于异常延迟。
逐台检查具体复制链路状态
对疑似问题 DC 运行 repadmin /showrepl <DC名称>（例如 repadmin /showrepl DC02）。输出中重点看每个复制伙伴的“Last Attempt”和“Last Success”时间戳，以及“Result”列的数值：
- 结果为 0 表示成功；
- 结果为 1722（RPC 服务器不可用）说明网络或服务中断；
- 结果为 5（拒绝访问）常见于凭据失效、Kerberos 票据异常或 SID 冲突；
- 结果为 1256 或 1908 多与 DNS 解析失败或目标 DC 不响应 LDAP 绑定有关。
验证变更是否真正传播到位
同步延迟不等于没同步，有时是元数据版本未更新。用 repadmin /showobjmeta 查看关键对象（如一个刚修改的用户）在不同 DC 上的复制元数据：
- 对比各 DC 上该对象的 Version 和 Originating DSA Guid；
- 若某台 DC 的 Version 明显落后，且 Originating DSA Guid 指向另一台 DC，说明该变更尚未到达；
- 再结合 Last Replication Success 时间，就能判断是复制停滞，还是只是尚未触发下一轮同步。
强制触发并观察即时响应
如果确认链路通畅但延迟持续，可主动推动一次复制：
- 用 repadmin /replicate <目标DC> <源DC> "dc=contoso,dc=com" 手动拉取指定分区；
- 再立刻执行 repadmin /showrepl <目标DC>，看“Last Attempt”是否更新、结果是否变为 0；
- 若仍失败，错误码会更明确指向底层原因（如防火墙拦截 389/445 端口、NTDS Settings 中连接被禁用等）。
