ad-replication

诊断 Active Directory 域控之间的复制拓扑、延迟与失败原因。

补充说明

AD 复制按命名上下文进行：架构、配置、域分区，以及全局编录承载的部分属性。站点内复制通常更频繁，站点间复制受站点链接的开销、计划和桥头服务器影响。KCC 自动生成连接对象，ISTG 负责站点间拓扑；只有确认自动拓扑无法满足需求时，才考虑手工连接对象。复制健康不能只看一台域控，入站正常也不代表出站正常，必须覆盖全林。

复制元数据依赖 USN（更新序列号）和调用 ID。域控恢复自旧备份、虚拟机快照或复制的虚拟磁盘时，可能出现 USN 回滚：本机认为新的更新已被其他域控见过，复制因此静默跳过或报错。典型信号是目录服务事件日志中的 2095，以及注册表 Dsa Not Writable 值为 0x4。此时不要强行触发复制，更不要改注册表把 DC 变成可写；应先隔离该域控，再评估从有效备份恢复、降级重建或清理元数据，过程中可能丢失回滚点之后的更新。

排障顺序建议：先用 repadmin /replsummary 看全林最大延迟和失败数，再用 /showrepl 定位到具体源、目标和分区，然后用 repadmin /queue、/failcache 判断是积压还是持续失败，最后回到 DNS、RPC、时间同步和站点拓扑找根因。dcdiag 的只读测试用于单机健康和广告检查；带 /fix 的测试会改配置，必须单独评估。只读诊断先行，/syncall、/replicate 和清理 lingering object 都属于变更操作。

时间同步与 DNS 是复制故障的两大常见根因。域内时间应遵循域层次：成员和普通域控向域层次同步，PDC 模拟器对接可靠时间源；不要把每台域控都指向外部时间源。时间偏差过大会让 Kerberos 认证失败，表现为复制访问被拒。DNS 方面要确认域控的 A 记录、SRV 记录和站点子网正确，客户端能定位到可用的域控。

站点间复制慢还要看站点链接的开销、复制计划和桥头服务器负载。所有站点都通过同一个桥头时，它可能成为瓶颈；跨站点链路中断时，KCC 不一定能立刻自动改道。用 repadmin /bridgeheads 和 /istg 确认角色，再结合 /showrepl 的失败计数判断是链路问题还是单台域控问题。

PowerShell 的 Get-ADReplicationPartnerMetadata 和 Get-ADReplicationFailure 能得到对象化结果，适合批量导出和定期巡检；repadmin 的摘要更适合现场快速定位。无论用哪种工具，都要记录时间点、源和目标，避免拿不同时刻的输出直接比较。目录服务日志、DFS Replication 日志和 DNS 日志要一起看，复制错误往往只是底层网络或解析问题的表象。巡检结果要保留历史基线，才能区分偶发失败和持续恶化。

常用示例

# 1. 全林摘要：先看最大延迟、失败数和错误
C:\> repadmin /replsummary

# 2. 单台 DC 的入站伙伴、最后成功时间和失败
C:\> repadmin /showrepl DC01 /verbose

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

# 4. 查看队列与 KCC 失败缓存
C:\> repadmin /queue DC01
C:\> repadmin /failcache DC01

# 5. 站点、桥头和 ISTG
C:\> repadmin /bridgeheads
C:\> repadmin /istg

# 6. 只读健康检查；每次只带一个 /test
C:\> dcdiag /test:replications /v
C:\> dcdiag /test:advertising /v
C:\> dcdiag /test:services /v

# 7. 对象级元数据，确认最后修改来自哪台 DC
C:\> repadmin /showobjmeta DC01 "CN=Administrator,CN=Users,DC=contoso,DC=com"

# 8. 时间状态
C:\> w32tm /query /status
C:\> w32tm /monitor

# 9. 变更操作：仅在根因排除且变更窗口内，对单台 DC 定向触发
# 影响范围：立即产生复制流量，可能扩散已有异常；复制本身没有数据回滚
# 备份/回滚：先确认系统状态备份和事件记录；失败时停止继续触发，回到根因处理
C:\> repadmin /syncall DC01

易错点与排错

• /replsummary 失败数为 0 就判定全林健康 → 摘要只反映链路和最近结果，不代表对象一致 → 继续用 /showrepl、/showchanges 和事件日志抽查关键分区。
• 只检查一台 DC 就下结论 → 入站正常不代表其他域控的出站正常 → 用 * 或逐台覆盖，比较每台的最后成功时间和失败计数。
• 报错 1722（RPC 服务器不可用）→ DNS 解析错误、RPC 端口被防火墙拦截或目标离线 → 先 nltest /dsgetdc、nslookup 和端口连通性，再考虑复制本身。
• 报错 8524（DSA 操作不可用）→ 目标域控的 DNS 记录或网络不可达 → 在源端解析目标 FQDN，验证目录服务端口和路由。
• 报错 5（拒绝访问）→ Kerberos 认证失败、时间偏差或权限不足 → 检查时间同步、服务账户和复制权限，不要直接提升账号权限。
• 延迟持续增大但失败数为 0 → 站点间计划、桥头拥塞或队列积压 → 看 /queue、站点链接开销和桥头负载，先判断容量问题。
• 新 DC 或恢复的 DC 复制异常并出现 2095 → 可能发生 USN 回滚 → 立即隔离，保留证据，禁止强制复制和修改 Dsa Not Writable；评估备份恢复或降级重建。
• 出现 lingering object 就直接清理 → 清理不可逆，且可能删掉仍有效的数据 → 先确认严格复制一致性、影响范围和备份，按官方流程在审核模式下评估。
• dcdiag /fix 被当成普通诊断 → 它会修改配置，例如 MachineAccount 测试涉及的 SPN → 只读排障阶段只用不带 /fix 的测试，变更需单独审批和回滚。
• 复制显示健康但组策略仍旧 → SYSVOL 复制与 AD 复制是两条链路 → 转查 gpo-diagnostics 中的 DFSR 和 SYSVOL 版本。
• 域控从虚拟机快照恢复后直接上线 → 可能造成 USN 回滚或 lingering object → 恢复前确认虚拟化代际 ID 支持情况，按备份恢复流程验证，不要直接接入生产网络。
• 用 PowerShell 批量采集却得到空结果 → 跨域、权限不足或分区参数不对 → 明确目标林、域和分区，必要时使用只读委派账号，别把空结果当成健康。

相关命令

• repadmin — 复制摘要、伙伴、队列和元数据
• dcdiag — 域控健康、广告与复制测试
• w32tm — 时间同步状态与域层次
• nltest — 域控定位与安全通道
• nslookup — 核对 SRV/A 记录
• netdom — 域信任与计算机账户检查
• gpo-diagnostics — 区分 AD 复制与 SYSVOL 复制
• windows-firewall — RPC 与目录服务端口排查

参考链接

• Microsoft Learn: Active Directory replication concepts
• Microsoft Learn: Detect and recover from USN rollback

读完自测

1. repadmin /replsummary 显示零失败，能否说明所有域控的对象完全一致？
2. 发现事件 2095 和 Dsa Not Writable = 0x4 时，为什么不能强制复制或改注册表？
3. 站点内复制正常但跨站点复制持续延迟，应优先检查什么？