问题背景

公司 AD 域环境由两台 Windows Server 2012 R2 域控承载（DC01 为主、DC02 为辅），域中约 1500 个用户账号，下游挂着组策略（GPO）、文件服务器鉴权、Exchange 邮件、基于 802.1x 的 WiFi 认证（NPS 依赖域控）以及多个内部业务系统的 LDAP 登录。2012 R2 已临近停止支持，我们计划在变更窗口内把域控升级到 Windows Server 2022，采用业界标准的「加新域控 → 迁移 FSMO → 降级旧域控」路线。原本以为只是常规的加机器、传角色、退旧机，没想到第一步就踩进了 SYSVOL 复制引擎的兼容性深坑，还因为一次仓促的 FSMO seize 差点酿成 USN 回滚事故。

故障现象

新装一台 Windows Server 2022 并提升为域控 DC03 后，问题接踵而至：

• repadmin /showrepl 持续报 SYSVOL 相关复制失败；dcdiag 提示 The DFS Replication service is not running 或 SYSVOL 未处于共享状态。
• 组策略大面积失效：部分 PC 的 GPO 版本停留在旧值，新上线的密码策略、软件分发、登录脚本都没推下去；个别旧域控重启后卡在「Applying Group Policy」很久，用户登录极慢。
• 更危险的一幕：现场同事在 DC03 上手动执行了 netdom /seize 试图抢夺 FSMO，结果 Schema、Naming、RID、PDC、Infrastructure 角色在两台 DC 上的「归属视角」出现不一致，dcdiag 报 FSMO Role Owner 异常，日志里出现 InvocationID 改变但 USN 未正确重置的征兆——典型的 USN 回滚风险信号。
• 部分 WiFi 用户认证失败（NPS 回源域控取不到最新信息），偶发无法联网；内部一个依赖 LDAP 登录的工单系统间歇性报错。

排查过程

1. 定位复制失败对象：先跑 repadmin /showrepl，确认失败的是跨 DC 的 SYSVOL 复制而非普通目录分区。再用 dfsrmig /getmigrationstate 查看 SYSVOL 复制引擎状态，结果直接显示 Start——意味着整个林从未把 SYSVOL 从 FRS 迁移到 DFSR。2012 R2 默认仍允许 FRS SYSVOL，而 Windows Server 2022 域控只支持 DFSR SYSVOL，旧的 FRS 复制链路在新旧混合时直接断裂。

2. 确认 FRS 残留：在旧 DC 上 net share 查看，SYSVOL 仍由 File Replication Service（NtFrs）托管；注册表 HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\SysVol 也未切到 DFSR。这就解释了为什么新 DC 死活拉不到 SYSVOL 的组策略模板（GPT）。

3. 排查 FSMO 分裂：用 netdom query fsmo 看各 DC 视角的角色持有者，再用 repadmin /showattr "<DC>" cn=ntdsdsa,cn=<site>,cn=sites,cn=configuration,dc=... "msDS-Behaviour-Version" 与 fSMORoleOwner 比对，发现 seize 之后 RID、Infrastructure 角色在两台 DC 上不一致；DC03 强行 seize 导致其 InvocationID 改变，而 USN 序列未做权威重置，dcdiag /test:fsmo 已亮黄灯——一旦该 DC 继续向外复制，会污染其他域控的更新序列号，后果是对象被静默丢弃。

4. 客户端 GPO 失效根因：SYSVOL 本身不复制，客户端从 DC03 取不到新 GPT；同时 Netlogon 的 SYSVOL 共享在部分 DC 上处于非权威/权威同步的中间态，表现为 \\domain\SYSVOL\domain\Policies 各 DC 内容不一致。配合 dcdiag /test:sysvolcheck 与 dfsrdiag，确认复制状态卡在起始阶段。

解决方案

1. 立即止血，撤销错误 seize：DC03 因强行 seize 已不再干净，直接将其强制降级为成员服务器（dcpromo /forceremoval），从林中摘除，避免 USN 回滚向外扩散。FSMO 角色仍由原始 DC01/DC02 持有，先恢复单点真相。

2. 先迁 SYSVOL，再谈升级：在旧 DC 上按官方三阶段把 SYSVOL 从 FRS 迁到 DFSR——dfsrmig /setglobalstate 1（Prepared）、2（Redirected）、3（Eliminated），每阶段待 dfsrmig /getmigrationstate 全部返回 Eliminated 再进下一步；期间用 dfsrdiag replicationstate 确认 SYSVOL 经 DFSR 正常同步。

3. 稳妥加新域控：SYSVOL 已是 DFSR 后，重新提升 DC03 为 2022 域控，等 repadmin /showrepl 全 0 错误、dcdiag 全 passed，再继续后续动作。

4. 用 transfer 而非 seize 迁移 FSMO：通过 Move-ADDirectoryServerOperationMasterRole -Identity DC03 -OperationMasterRole Schema,Naming,RIDMaster,PDCEmulator,InfrastructureMaster（或 netdom transfer）逐一标准转移五个角色，绝不在线域控健在时 seize。

5. 优雅降级旧域控：确认 FSMO 全部落到新 DC 后，再用 dcpromo 把 DC01/DC02 降级为成员服务器，再次跑 dcdiag、repadmin 验收全绿。

6. 修复 GPO 与客户端：核对 \\domain\SYSVOL\domain\Policies 各 DC 一致；对卡在 Applying Policy 的 PC 执行 gpupdate /force 并 klist purge，WiFi/NPS 认证随即恢复。

根因分析

根因有两个叠加：其一是复制引擎代差——旧环境停留在 FRS SYSVOL，而 Windows Server 2022 域控只支持 DFSR，FRS 复制链路在混合版本下必然断裂；其二是变更顺序错误——没有先完成 SYSVOL 迁移就加新 DC，且在旧角色持有者仍在线时仓促 seize FSMO，触发 USN 回滚风险。两者都是「升级前未做兼容性体检」与「未遵循标准操作顺序」导致的。

预防措施

1. 升级前体检：用 dfsrmig /getmigrationstate 确认 SYSVOL 已是 DFSR，FRS 残留一律先迁再升。
2. 严守顺序：SYSVOL 迁移 → 加新 DC（等复制完成）→ transfer FSMO → 降级旧 DC，任何一步不过验收不进下一步。
3. 禁用随意 seize：仅当旧角色持有者确认永久离线才考虑 seize；seize 后应立即 repadmin /regkey 防 USN 回滚，或直接重装该域控。
4. 保留回退能力：变更窗口内旧 DC 全程在线，直到新 DC 跑满观察期再降级，确保一键回退。
5. 常态化巡检：定时调度 dcdiag / repadmin /showrepl 并对接告警，SYSVOL 复制异常第一时间发现。

总结

AD 域控升级是高风险的「牵一发而动全身」变更，最大的两个暗坑是 SYSVOL 复制引擎（FRS → DFSR）的兼容性，以及 FSMO 迁移的顺序与方式。记住三句话：先迁移后升级、用 transfer 不用 seize、永远保留回退能力——把这三件事做在变更窗口之前，域控升级就能从「踩雷现场」变成「标准作业」。