<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
    <channel>
        <title>Dcdiag on Zero Day Notes</title>
        <link>https://blog.5772447.xyz/tags/dcdiag/</link>
        <description>Recent content in Dcdiag on Zero Day Notes</description>
        <generator>Hugo -- gohugo.io</generator>
        <language>zh</language>
        <lastBuildDate>Tue, 14 Jul 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://blog.5772447.xyz/tags/dcdiag/index.xml" rel="self" type="application/rss+xml" /><item>
            <title>迁移 AD 域控：SYSVOL 复制断裂与 FSMO 抢占风险的定位与回退复盘</title>
            <link>https://blog.5772447.xyz/posts/0f35911f/</link>
            <pubDate>Tue, 14 Jul 2026 00:00:00 +0000</pubDate>
            <guid>https://blog.5772447.xyz/posts/0f35911f/</guid>
            <description>&lt;h2 id=&#34;问题背景&#34;&gt;&lt;a href=&#34;#%e9%97%ae%e9%a2%98%e8%83%8c%e6%99%af&#34; class=&#34;header-anchor&#34;&gt;&lt;/a&gt;问题背景&#xD;&#xA;&lt;/h2&gt;&lt;p&gt;公司 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 回滚事故。&lt;/p&gt;&#xA;&lt;h2 id=&#34;故障现象&#34;&gt;&lt;a href=&#34;#%e6%95%85%e9%9a%9c%e7%8e%b0%e8%b1%a1&#34; class=&#34;header-anchor&#34;&gt;&lt;/a&gt;故障现象&#xD;&#xA;&lt;/h2&gt;&lt;p&gt;新装一台 Windows Server 2022 并提升为域控 DC03 后，问题接踵而至：&lt;/p&gt;&#xA;&lt;ul&gt;&#xA;&lt;li&gt;&lt;code&gt;repadmin /showrepl&lt;/code&gt; 持续报 SYSVOL 相关复制失败；&lt;code&gt;dcdiag&lt;/code&gt; 提示 &lt;code&gt;The DFS Replication service is not running&lt;/code&gt; 或 SYSVOL 未处于共享状态。&lt;/li&gt;&#xA;&lt;li&gt;组策略大面积失效：部分 PC 的 GPO 版本停留在旧值，新上线的密码策略、软件分发、登录脚本都没推下去；个别旧域控重启后卡在「Applying Group Policy」很久，用户登录极慢。&lt;/li&gt;&#xA;&lt;li&gt;更危险的一幕：现场同事在 DC03 上手动执行了 &lt;code&gt;netdom /seize&lt;/code&gt; 试图抢夺 FSMO，结果 Schema、Naming、RID、PDC、Infrastructure 角色在两台 DC 上的「归属视角」出现不一致，&lt;code&gt;dcdiag&lt;/code&gt; 报 &lt;code&gt;FSMO Role Owner&lt;/code&gt; 异常，日志里出现 InvocationID 改变但 USN 未正确重置的征兆——典型的 USN 回滚风险信号。&lt;/li&gt;&#xA;&lt;li&gt;部分 WiFi 用户认证失败（NPS 回源域控取不到最新信息），偶发无法联网；内部一个依赖 LDAP 登录的工单系统间歇性报错。&lt;/li&gt;&#xA;&lt;/ul&gt;&#xA;&lt;h2 id=&#34;排查过程&#34;&gt;&lt;a href=&#34;#%e6%8e%92%e6%9f%a5%e8%bf%87%e7%a8%8b&#34; class=&#34;header-anchor&#34;&gt;&lt;/a&gt;排查过程&#xD;&#xA;&lt;/h2&gt;&lt;ol&gt;&#xA;&lt;li&gt;&#xA;&lt;p&gt;&lt;strong&gt;定位复制失败对象&lt;/strong&gt;：先跑 &lt;code&gt;repadmin /showrepl&lt;/code&gt;，确认失败的是跨 DC 的 SYSVOL 复制而非普通目录分区。再用 &lt;code&gt;dfsrmig /getmigrationstate&lt;/code&gt; 查看 SYSVOL 复制引擎状态，结果直接显示 &lt;code&gt;Start&lt;/code&gt;——意味着整个林从未把 SYSVOL 从 FRS 迁移到 DFSR。2012 R2 默认仍允许 FRS SYSVOL，而 Windows Server 2022 域控&lt;strong&gt;只支持 DFSR SYSVOL&lt;/strong&gt;，旧的 FRS 复制链路在新旧混合时直接断裂。&lt;/p&gt;&#xA;&lt;/li&gt;&#xA;&lt;li&gt;&#xA;&lt;p&gt;&lt;strong&gt;确认 FRS 残留&lt;/strong&gt;：在旧 DC 上 &lt;code&gt;net share&lt;/code&gt; 查看，SYSVOL 仍由 File Replication Service（NtFrs）托管；注册表 &lt;code&gt;HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\SysVol&lt;/code&gt; 也未切到 DFSR。这就解释了为什么新 DC 死活拉不到 SYSVOL 的组策略模板（GPT）。&lt;/p&gt;&#xA;&lt;/li&gt;&#xA;&lt;li&gt;&#xA;&lt;p&gt;&lt;strong&gt;排查 FSMO 分裂&lt;/strong&gt;：用 &lt;code&gt;netdom query fsmo&lt;/code&gt; 看各 DC 视角的角色持有者，再用 &lt;code&gt;repadmin /showattr &amp;quot;&amp;lt;DC&amp;gt;&amp;quot; cn=ntdsdsa,cn=&amp;lt;site&amp;gt;,cn=sites,cn=configuration,dc=... &amp;quot;msDS-Behaviour-Version&amp;quot;&lt;/code&gt; 与 fSMORoleOwner 比对，发现 seize 之后 RID、Infrastructure 角色在两台 DC 上不一致；DC03 强行 seize 导致其 InvocationID 改变，而 USN 序列未做权威重置，&lt;code&gt;dcdiag /test:fsmo&lt;/code&gt; 已亮黄灯——一旦该 DC 继续向外复制，会污染其他域控的更新序列号，后果是对象被静默丢弃。&lt;/p&gt;&#xA;&lt;/li&gt;&#xA;&lt;li&gt;&#xA;&lt;p&gt;&lt;strong&gt;客户端 GPO 失效根因&lt;/strong&gt;：SYSVOL 本身不复制，客户端从 DC03 取不到新 GPT；同时 Netlogon 的 SYSVOL 共享在部分 DC 上处于非权威/权威同步的中间态，表现为 &lt;code&gt;\\domain\SYSVOL\domain\Policies&lt;/code&gt; 各 DC 内容不一致。配合 &lt;code&gt;dcdiag /test:sysvolcheck&lt;/code&gt; 与 &lt;code&gt;dfsrdiag&lt;/code&gt;，确认复制状态卡在起始阶段。&lt;/p&gt;&#xA;&lt;/li&gt;&#xA;&lt;/ol&gt;&#xA;&lt;h2 id=&#34;解决方案&#34;&gt;&lt;a href=&#34;#%e8%a7%a3%e5%86%b3%e6%96%b9%e6%a1%88&#34; class=&#34;header-anchor&#34;&gt;&lt;/a&gt;解决方案&#xD;&#xA;&lt;/h2&gt;&lt;ol&gt;&#xA;&lt;li&gt;&#xA;&lt;p&gt;&lt;strong&gt;立即止血，撤销错误 seize&lt;/strong&gt;：DC03 因强行 seize 已不再干净，直接将其强制降级为成员服务器（&lt;code&gt;dcpromo /forceremoval&lt;/code&gt;），从林中摘除，避免 USN 回滚向外扩散。FSMO 角色仍由原始 DC01/DC02 持有，先恢复单点真相。&lt;/p&gt;&#xA;&lt;/li&gt;&#xA;&lt;li&gt;&#xA;&lt;p&gt;&lt;strong&gt;先迁 SYSVOL，再谈升级&lt;/strong&gt;：在旧 DC 上按官方三阶段把 SYSVOL 从 FRS 迁到 DFSR——&lt;code&gt;dfsrmig /setglobalstate 1&lt;/code&gt;（Prepared）、&lt;code&gt;2&lt;/code&gt;（Redirected）、&lt;code&gt;3&lt;/code&gt;（Eliminated），每阶段待 &lt;code&gt;dfsrmig /getmigrationstate&lt;/code&gt; 全部返回 &lt;code&gt;Eliminated&lt;/code&gt; 再进下一步；期间用 &lt;code&gt;dfsrdiag replicationstate&lt;/code&gt; 确认 SYSVOL 经 DFSR 正常同步。&lt;/p&gt;&#xA;&lt;/li&gt;&#xA;&lt;li&gt;&#xA;&lt;p&gt;&lt;strong&gt;稳妥加新域控&lt;/strong&gt;：SYSVOL 已是 DFSR 后，重新提升 DC03 为 2022 域控，等 &lt;code&gt;repadmin /showrepl&lt;/code&gt; 全 0 错误、&lt;code&gt;dcdiag&lt;/code&gt; 全 passed，再继续后续动作。&lt;/p&gt;&#xA;&lt;/li&gt;&#xA;&lt;li&gt;&#xA;&lt;p&gt;&lt;strong&gt;用 transfer 而非 seize 迁移 FSMO&lt;/strong&gt;：通过 &lt;code&gt;Move-ADDirectoryServerOperationMasterRole -Identity DC03 -OperationMasterRole Schema,Naming,RIDMaster,PDCEmulator,InfrastructureMaster&lt;/code&gt;（或 &lt;code&gt;netdom transfer&lt;/code&gt;）逐一&lt;strong&gt;标准转移&lt;/strong&gt;五个角色，绝不在线域控健在时 seize。&lt;/p&gt;&#xA;&lt;/li&gt;&#xA;&lt;li&gt;&#xA;&lt;p&gt;&lt;strong&gt;优雅降级旧域控&lt;/strong&gt;：确认 FSMO 全部落到新 DC 后，再用 &lt;code&gt;dcpromo&lt;/code&gt; 把 DC01/DC02 降级为成员服务器，再次跑 &lt;code&gt;dcdiag&lt;/code&gt;、&lt;code&gt;repadmin&lt;/code&gt; 验收全绿。&lt;/p&gt;&#xA;&lt;/li&gt;&#xA;&lt;li&gt;&#xA;&lt;p&gt;&lt;strong&gt;修复 GPO 与客户端&lt;/strong&gt;：核对 &lt;code&gt;\\domain\SYSVOL\domain\Policies&lt;/code&gt; 各 DC 一致；对卡在 Applying Policy 的 PC 执行 &lt;code&gt;gpupdate /force&lt;/code&gt; 并 &lt;code&gt;klist purge&lt;/code&gt;，WiFi/NPS 认证随即恢复。&lt;/p&gt;&#xA;&lt;/li&gt;&#xA;&lt;/ol&gt;&#xA;&lt;h2 id=&#34;根因分析&#34;&gt;&lt;a href=&#34;#%e6%a0%b9%e5%9b%a0%e5%88%86%e6%9e%90&#34; class=&#34;header-anchor&#34;&gt;&lt;/a&gt;根因分析&#xD;&#xA;&lt;/h2&gt;&lt;p&gt;根因有两个叠加：其一是&lt;strong&gt;复制引擎代差&lt;/strong&gt;——旧环境停留在 FRS SYSVOL，而 Windows Server 2022 域控只支持 DFSR，FRS 复制链路在混合版本下必然断裂；其二是&lt;strong&gt;变更顺序错误&lt;/strong&gt;——没有先完成 SYSVOL 迁移就加新 DC，且在旧角色持有者仍在线时仓促 seize FSMO，触发 USN 回滚风险。两者都是「升级前未做兼容性体检」与「未遵循标准操作顺序」导致的。&lt;/p&gt;&#xA;&lt;h2 id=&#34;预防措施&#34;&gt;&lt;a href=&#34;#%e9%a2%84%e9%98%b2%e6%8e%aa%e6%96%bd&#34; class=&#34;header-anchor&#34;&gt;&lt;/a&gt;预防措施&#xD;&#xA;&lt;/h2&gt;&lt;ol&gt;&#xA;&lt;li&gt;&lt;strong&gt;升级前体检&lt;/strong&gt;：用 &lt;code&gt;dfsrmig /getmigrationstate&lt;/code&gt; 确认 SYSVOL 已是 DFSR，FRS 残留一律先迁再升。&lt;/li&gt;&#xA;&lt;li&gt;&lt;strong&gt;严守顺序&lt;/strong&gt;：SYSVOL 迁移 → 加新 DC（等复制完成）→ transfer FSMO → 降级旧 DC，任何一步不过验收不进下一步。&lt;/li&gt;&#xA;&lt;li&gt;&lt;strong&gt;禁用随意 seize&lt;/strong&gt;：仅当旧角色持有者确认永久离线才考虑 seize；seize 后应立即 &lt;code&gt;repadmin /regkey&lt;/code&gt; 防 USN 回滚，或直接重装该域控。&lt;/li&gt;&#xA;&lt;li&gt;&lt;strong&gt;保留回退能力&lt;/strong&gt;：变更窗口内旧 DC 全程在线，直到新 DC 跑满观察期再降级，确保一键回退。&lt;/li&gt;&#xA;&lt;li&gt;&lt;strong&gt;常态化巡检&lt;/strong&gt;：定时调度 &lt;code&gt;dcdiag&lt;/code&gt; / &lt;code&gt;repadmin /showrepl&lt;/code&gt; 并对接告警，SYSVOL 复制异常第一时间发现。&lt;/li&gt;&#xA;&lt;/ol&gt;&#xA;&lt;h2 id=&#34;总结&#34;&gt;&lt;a href=&#34;#%e6%80%bb%e7%bb%93&#34; class=&#34;header-anchor&#34;&gt;&lt;/a&gt;总结&#xD;&#xA;&lt;/h2&gt;&lt;p&gt;AD 域控升级是高风险的「牵一发而动全身」变更，最大的两个暗坑是 SYSVOL 复制引擎（FRS → DFSR）的兼容性，以及 FSMO 迁移的顺序与方式。记住三句话：&lt;strong&gt;先迁移后升级、用 transfer 不用 seize、永远保留回退能力&lt;/strong&gt;——把这三件事做在变更窗口之前，域控升级就能从「踩雷现场」变成「标准作业」。&lt;/p&gt;&#xA;&lt;hr&gt;&#xA;&lt;h2 id=&#34;延伸阅读&#34;&gt;&lt;a href=&#34;#%e5%bb%b6%e4%bc%b8%e9%98%85%e8%af%bb&#34; class=&#34;header-anchor&#34;&gt;&lt;/a&gt;延伸阅读&#xD;&#xA;&lt;/h2&gt;&lt;p&gt;&lt;strong&gt;域控与组策略&lt;/strong&gt;&lt;/p&gt;&#xA;&lt;ul&gt;&#xA;&lt;li&gt;&lt;a class=&#34;link&#34; href=&#34;https://blog.5772447.xyz/posts/75336643/&#34; &gt;记一次 AD 域中黄金票据攻击导致域控权限持久化的检测与清除&lt;/a&gt;&lt;/li&gt;&#xA;&lt;li&gt;&lt;a class=&#34;link&#34; href=&#34;https://blog.5772447.xyz/posts/3c75e975/&#34; &gt;域控 GPO 推送失败，终端安全基线为何不生效？&lt;/a&gt;&lt;/li&gt;&#xA;&lt;li&gt;&lt;a class=&#34;link&#34; href=&#34;https://blog.5772447.xyz/posts/f78d7f76/&#34; &gt;域控 NTP 时间源失效，全公司 Kerberos 为何大面积失败？&lt;/a&gt;&lt;/li&gt;&#xA;&lt;li&gt;&lt;a class=&#34;link&#34; href=&#34;https://blog.5772447.xyz/posts/3a307caa/&#34; &gt;域电脑重启后为何登不上？一次工作站与主域信任关系失败的排查记录&lt;/a&gt;&lt;/li&gt;&#xA;&lt;li&gt;&lt;a class=&#34;link&#34; href=&#34;https://blog.5772447.xyz/posts/903f5f9d/&#34; &gt;LAPS 部署后终端本地管理员密码为何未更新？一次策略应用与事件日志的排查记录&lt;/a&gt;&lt;/li&gt;&#xA;&lt;li&gt;&lt;a class=&#34;link&#34; href=&#34;https://blog.5772447.xyz/posts/8c4b1183/&#34; &gt;Windows 域策略推送失败致新电脑无法登录的处理&lt;/a&gt;&lt;/li&gt;&#xA;&lt;/ul&gt;&#xA;</description>
        </item></channel>
</rss>
