/replsummary 显示失败数为 0，能否直接判定所有对象一致？

不能，它只是摘要；对象级差异要看 /showrepl、/showchanges 与事件日志。

看到 1722 错误时，下一步应先查什么？

先查 DNS 解析、RPC 端口与目标 DC 可达性，而不是重复触发复制。

为什么不应在生产全林随意执行 /syncall？

它会立即产生复制流量并扩散已有异常，应在变更窗口内对单台 DC 定向执行。

系统学习 Windows 学习路径：从 CMD 到 PowerShell、系统网络，再到 WSL 与 Server

repadmin

查看 AD 域控间复制状态、队列和失败原因的诊断工具。

补充说明

repadmin 读取域控的复制元数据，能显示每个命名上下文的复制伙伴、最后成功时间、失败计数和待处理队列。排障顺序通常是先 /replsummary 看全林，再 /showrepl 定位到具体 DC 与分区。

它依赖 AD DS 角色或 RSAT 的 AD DS 工具，需在域控或管理机上以管理员身份运行，并具备域管理员或委派权限。只读子命令可以放心使用；/syncall 会主动触发复制，/removelingeringobjects 会删除对象，属于变更操作。

Windows Server 2016+ 仍保留完整工具集。PowerShell 可用 Get-ADReplicationPartnerMetadata、Get-ADReplicationFailure 获取对象化结果，但现场排障时 repadmin 的摘要更直观。

常用示例

# 全林复制健康总览，先看最大延迟和失败数
C:\> repadmin /replsummary

# 查看单台 DC 每个分区的复制伙伴与最后成功时间
C:\> repadmin /showrepl DC01 /verbose

# 导出所有 DC 的复制状态，便于横向对比
C:\> repadmin /showrepl * /csv > C:\Temp\repl.csv

# 查看入站复制队列是否积压
C:\> repadmin /queue DC01

# 影响范围：/syncall 会立即触发复制，可能造成带宽与 CPU 峰值，并扩散已有异常
# 备份/回滚：先确认无 DNS/RPC 根因；在变更窗口内对单台 DC 定向同步，复制本身无法回滚数据
C:\> repadmin /syncall DC01 /AeD

# 查看对象属性元数据，判断最后一次修改来自哪台 DC
C:\> repadmin /showobjmeta DC01 "CN=Administrator,CN=Users,DC=contoso,DC=com"

易错点与排错

只看一台 DC 的 /showrepl 就下结论 → 入站正常不代表出站正常 → 用 /replsummary 加 * 覆盖全林，再对比失败计数。
报错 1722（RPC 服务器不可用）→ DNS 解析错误、防火墙拦截或目标 DC 离线 → 先 nltest /dsgetdc:contoso.com，再检查 135/TCP 与动态 RPC 端口。
报错 8524（DSA 操作不可用）→ 目标 DC 的 DNS 记录或网络不可达 → 在源 DC 上 nslookup DC01，并验证 389/3268 端口。
复制延迟大但无失败 → 站点间复制计划或桥头服务器拥塞 → 查站点链接开销与 /queue，不要盲目 /syncall。
/syncall 后仍然失败 → 根因未解决，只是重复触发 → 回到 DNS、时间同步（w32tm /query /status）与事件日志。
清理 lingering object 不可逆 → 对象会被删除且不随备份自动恢复 → 必须先做系统状态备份，并在 /advisory_mode 下确认范围。

参考链接

读完自测

/replsummary 显示失败数为 0，能否直接判定所有对象一致？
看到 1722 错误时，下一步应先查什么？
为什么不应在生产全林随意执行 /syncall？

答案

不能，它只是摘要；对象级差异要看 /showrepl、/showchanges 与事件日志。
先查 DNS 解析、RPC 端口与目标 DC 可达性，而不是重复触发复制。
它会立即产生复制流量并扩散已有异常，应在变更窗口内对单台 DC 定向执行。