Windows Server 2022域控部署与主备DC同步机制详解

简介：面向Windows Server管理员与AD域控运维人员的实操型PDF文档，系统讲解Windows Server 2022主域控与备域控的完整搭建流程，适用于企业内网高可用域控环境建设及故障接管场景。资源为单个PDF文件，大小15.25MB，内含图文步骤详解，目前已有893人学习下载。文档覆盖主机名修改、静态IP与DNS配置、AD域服务角色安装、域控制器提升、全局编录、DSRM密码与NetBIOS名称等核心知识点，并专门演示了备域控加入主域及主备数据同步测试过程，可帮助读者理解主域控中断时备域控无缝接管、保障业务连续性的实现机制。其中还对比了公网域名与内部域名的适用场景，分析了安装DNS服务的必然性，并给出实验验证建议，适合在Hyper-V实验环境中按图索骥、逐步实操，快速掌握企业级AD域控的高可用部署技巧。

1. AD域控不是装完就算完：两台 DC 的复制机制才是关键

把一台 Windows Server 2022 从工作组提升成 AD 域控，半小时内就能办到；真正让人睡不着的，往往是备域控加进来之后那一堆同步报错。这个标题说到底就两件事：一是把 Windows Server 2022 AD域控安装与配置这件事走完，二是把主域控和备域控之间的同步机制讲透，让你知道“两台 DC 对不齐”时到底发生了什么。适合刚接触域控的运维、正打算从单域控迁到多域控的工程师，也适合准备 AD 岗位面试、需要把复制机制说清楚的人。先把主域控装对，后面的备域控和同步才有得聊。

2. 主域控搭建：环境基线、AD DS 角色安装与提升命令

2.1 装域控前两三个小时最该定下来的基线参数

我见过太多“域控装完了再改 IP、改主机名、补 DNS”的案例，最后 SRV 记录全乱，备域控死活找不到主域控。Windows Server 2022 的 AD 域服务对网络参数非常敏感，装之前必须把下面这张表定下来，并写进变更记录。

一个容易翻车的点：服务器如果有多块网卡，域控会把每块网卡的地址都注册进 DNS，客户端随机解析到一个内网不通的地址，登录就会卡到怀疑人生。我的做法是：装域控之前，把不用的网卡直接禁用，只保留一块做静态 IP。这个决定会影响后面所有复制与验证，别到装完再后悔。

2.2 用 PowerShell 装 AD DS 并提升为第一台 DC

图形界面在 Server Manager 里点“添加角色和功能”，选 Active Directory 域服务，装完再点“将此服务器提升为域控制器”，路径很直白，但新手容易漏掉“自动安装 DNS”的勾选。我一般更推荐 PowerShell，因为参数清清楚楚，以后要复现环境直接翻脚本就行，不用重新点一遍界面。

先把主机名、IP、DNS 固定下来：

Rename-Computer -NewName DC01 -Restart Set-DnsClientServerAddress -InterfaceAlias "Ethernet0" ` -ServerAddresses 192.168.10.10,192.168.10.11

第一行改名后重启，第二行把网卡 Ethernet0 的首选 DNS 和备用 DNS 都设置好。这里要注意 InterfaceAlias 必须和实际网卡名一致，可以用Get-NetAdapter查出来再填。DNS 指向自己这件事看着反直觉，但域控必须能在没有外部 DNS 的情况下解析自己的域，这是 AD 的基础。

接着安装 AD DS 角色：

Install-WindowsFeature AD-Domain-Services -IncludeManagementTools

-IncludeManagementTools会把 AD 用户和计算机、AD 站点和服务等管理工具一并装上。不加这个参数后面很多图形管理入口会缺失，命令行能干活但排查效率低不少。

角色装完后，用下面的命令直接提升为第一台域控，同时创建新林：

Import-Module ADDSDeployment Install-ADDSForest ` -DomainName "corp.example.com" ` -DomainNetbiosName "CORP" ` -InstallDns:$true ` -ForestMode "WinThreshold" ` -DomainMode "WinThreshold" ` -SafeModeAdministratorPassword (ConvertTo-SecureString "N1ce$trongPass" -AsPlainText -Force) ` -NoRebootOnCompletion:$false ` -Force:$true

DomainName是你要创建的完整域名，这里用 corp.example.com 做示例；DomainNetbiosName是旧 NetBIOS 名，客户端有时会用CORP\user这种格式登录，提前想好；InstallDns:$true表示同时装 DNS 并创建对应区域。两个功能级别都写WinThreshold，因为 Windows Server 2022 没有比 2016 更高的域功能级别，新老 2022 DC 混用时这个值完全够用。SafeModeAdministratorPassword是目录服务还原模式密码，丢了以后做灾难恢复会很被动，务必备份到一个只有你能访问的地方。

有一个常见误解：提升完成后重启一下，主域控就“大功告成”了。其实还有几个必须立刻确认的动作，见下一节。

2.3 第一台 DC 的验证清单：SRV 记录、FSMO 与 DNS

重启登录以后，先别急着装第二台，按下面三步验证第一台 DC 是不是真的“立住”了。

netdom query fsmo dcdiag /v /q nslookup -type=SRV _ldap._tcp.corp.example.com

netdom query fsmo会列出五类 FSMO 角色，第一台 DC 上应该全部显示为 DC01。dcdiag /v /q是全量测试，只输出失败项，正常情况下几乎看不到红字。最后一条 nslookup 用来确认 DNS 里已经出现_ldap._tcp.corp.example.com的 SRV 记录，返回的地址必须是 DC01 的 IP。

如果 SRV 记录没出现，常见原因是域控的 DNS 客户端地址配置成了外部 DNS，导致它不知道往哪里注册。这时候检查Get-DnsServer的区域复制和接口绑定，把 DNS 监听地址固定到 192.168.10.10。另外还要看一眼 C:\Windows\System32\config\netlogon.dns 文件，里面应该有完整的 SRV 记录列表，这个文件是 Netlogon 服务的“成绩单”，对不上就要去查网卡绑定。

这套验证通过，主域控才算真正可用。下一步才是把备域控拉进来。

3. 备域控加入：DNS 指向、依次提升与复制闭环检查

3.1 备域控入域前的四项网络预检

备域控的搭建在概念上比主域控少一步“建林”，但更容易翻车，因为它所有的操作都依赖和主域控之间的连通性。我在装第二台之前，固定按下面四步做预检，任何一步不过就不往下走。

nslookup corp.example.com nslookup -type=SRV _ldap._tcp.corp.example.com w32tm /query /source Test-NetConnection 192.168.10.10 -Port 389

第一、二条命令验证备控能不能正确解析到主域控的地址和 LDAP SRV 记录。如果解析出来是网关或外部 DNS 的返回值，说明这台机器的 DNS 指向还没改过来。第三条看时间源：备控当前的时间源应该能追溯到主控，偏差超过 5 分钟，后续 Kerberos 会直接拒绝认证，报“目标主体名称不正确”，很迷惑。第四条用 Test-NetConnection 测 389 端口，确认主域控的 LDAP 服务在监听。

还有一个非常容易忽略的点：入域之前，备域控的本地管理员密码和入域账号要确认好，不要临时翻邮箱找密码。我曾经因为拿错凭据连续失败三次，把主域控默认的“账户锁定阈值”策略触发了，administrator 直接被锁，只好物理去机房解锁域控，狼狈至极。

3.2 备域控提升命令与参数取舍

预检通过后，先把备控加进域。

Add-Computer -DomainName "corp.example.com" -Credential CORP\administrator -Restart -Force

这里的-Credential用CORP\administrator的格式传域管理员，-Restart会在加域成功后自动重启。加域成功后这台机器已经被域管理了，但它还不是域控，这时候它的角色更多像一台“域内成员服务器”，需要继续安装 AD DS 角色并提升为额外域控制器。

重启之后执行：

Install-WindowsFeature AD-Domain-Services -IncludeManagementTools Import-Module ADDSDeployment Install-ADDSDomainController ` -DomainName "corp.example.com" ` -SiteName "Default-First-Site-Name" ` -InstallDns:$true ` -GlobalCatalog:$true ` -SafeModeAdministratorPassword (ConvertTo-SecureString "Another$trongPass" -AsPlainText -Force) ` -CriticalReplicationOnly:$false ` -Force:$true

和建林命令最明显的区别是：这里用Install-ADDSDomainController，而不是Install-ADDSForest。-SiteName "Default-First-Site-Name"必须和主控所在的 AD 站点名一致，写错了 KCC 会把两台 DC 划到不同站点，复制频率从近实时降成 180 分钟一次，到时候排查起来非常痛苦。好奇的话可以用Get-ADReplicationSite看当前站点名，再填进去。-GlobalCatalog:$true让备控同时做全局编录，默认就是启用，但显式写出来能防止某些版本在特殊网络环境下被跳过。

这里有个细节：备控提升时，PowerShell 会去做一次初始同步，把主控上的分区数据复制过来。此时如果主控上正有大体积数据在迁移，命令可能长时间没有响应，很多新人看到这一步就以为“卡死了”。其实把-CriticalReplicationOnly:$true设为仅复制关键分区可以减少等待时间，但代价是首次复制不完整，不推荐生产环境这么干。耐心等，日志会告诉你进度。

3.3 两台 DC 的复制状态检查与 GC 确认

提升完成并重启后，用下面几条命令确认两台 DC 已经形成复制闭环。

repadmin /replsummary repadmin /showrepl DC02 Get-ADDomainController -Filter * | Select-Object Name, Site, GlobalCatalog netdom query fsmo

repadmin /replsummary会列出每台 DC 的最小/最大复制延迟，正常情况所有行都是 0 或很小的数字，超过几十分钟就要警惕。repadmin /showrepl DC02能逐条看 DC02 的入站复制伙伴、上次成功时间和失败信息，是定位复制故障最直接的命令。第三条命令确认 DC02 的 GlobalCatalog 为 True，GC 缺失会导致大量客户端对象查找失败。最后再用netdom query fsmo对比一下角色位置，五类角色仍留在 DC01 上是正常的。

如果repadmin /replsummary里出现“401”错误或“撞车”状态，先别怀疑算法，回到 3.1 的预检，看看是不是 DNS 记录里有旧地址。我就是这样被坑过一次：备控加入后，DNS 里残留了它以前当普通服务器时的旧 A 记录，复制伙伴一直连到旧 IP 上，查了一天才发现是条过期记录。

4. 同步机制拆解：多主复制、USN、KCC 怎么把两台 DC 对齐

4.1 “主/备”印象来自老 PDC，实际是每台 DC 都可读写的多主模型

很多人从字面理解“主域控和备域控”，以为主控能写、备控只能读，这其实是 Windows NT 时代 PDC/BDC 的旧概念。AD 从 Windows 2000 开始就采用多主复制模型：域内每一台 DC 都可以接受用户的更改，不管用户改的是密码、组策略还是新用户对象，落在哪台 DC 上，哪台 DC 就有责任把它复制给其他 DC。

所以在 Windows Server 2022 里，“主域控”更准确的说法是“林中第一台 DC”，它特殊在默认持有全部 FSMO 角色，而不特殊在它是唯一可写点。“备域控”则是额外 DC，和主控之间是双向复制关系。搭建备域控时如果还抱着“备控只是冷备”的心态，就会忽视 GC 配置、站点归属和复制健康度，出了问题往往措手不及。

多主复制的好处很明显：任何一台 DC 宕了，用户认证和修改还能通过另一台 DC 完成。代价是系统必须有一套冲突消解逻辑，否则两个人同时改同一条用户属性，谁知道谁说了算。这套逻辑就是接下来要讲的 USN 和冲突裁决规则。

4.2 USN、高水位标记与冲突解决的三个裁判

Active Directory 里每个对象、甚至对象的每个属性，都有自己的一份“更新序号”，叫 USN。DC 上每发生一次修改，本机就给这条修改分配一个新的 USN，并记下“发起写入的 DC 是谁、发起时的 USN 是多少”。当两台 DC 做复制时，接收方会记录一个高水位标记，也就是“从某个源 DC 那儿已经收到了最大 USN 是多少”。下次再复制，源 DC 只需要把大于这个高水位的更新发过来，不用把整个目录搬一遍。

还有一个容易被误解的点：高水位标记是按“DC 伙伴”记的，不是全域统一的。DC01 从 DC02 同步数据时，DC01 记录的是“DC02 给我的最新 USN”；DC02 从 DC01 同步数据时，记录的是另一个方向的高水位。两者互不干扰，所以复制是真正双向的。

至于冲突裁决，AD 使用三个裁判：属性版本号、时间戳、以及缓冲区（缓冲非美国？）的取舍。简单说就是“最后写入的赢”，术语叫 Last Writer Wins。两个管理员几乎同时改一条 Description 属性，系统会选那个带更大版本号或更新时间戳的写入。看到这里你应该明白，DC 之间并不是靠“全量覆盖”来同步的，而是靠这些元数据判断谁该出货、谁该收货。这也是为什么回滚快照会让域控直接“翻车”——它把 USN 的进度倒退了，破坏了这套信任机制。

4.3 KCC 与连接对象：复制路径不是手动配出来的

前面几节讲的是“怎么同步”，还有一个问题是“和谁同步”。Windows 用 KCC 自动计算出复制拓扑。KCC 每隔 15 分钟运行一次，检查当前有哪些 DC、在哪些站点，然后自动生成连接对象，每对 DC 之间的复制路径不需要管理员手工画。

站点内复制默认是通知驱动的：DC01 有了新写入，会通知站点内的复制伙伴来拉取，普通对象变更一般几十秒内就能传过去。站点间复制则走站点链路，默认复制间隔 180 分钟，可以通过 AD 站点和服务调整到 15 分钟到 1440 分钟之间。链路还有一个“开销”参数，默认 100，值越小越优先。如果你发现备控和主控在同一机房，但复制要等半天，多半是站点或链路配置错了，把两台 DC 划成了“跨站点”，触发了慢速复制策略。

KCC 自动生成连接对象的设计让普通运维省心，但也带来一个隐性要求：域控的 IP 和网络位置不能乱改。你把 DC01 的 IP 改了，旧连接对象指向的地址就失效了，KCC 要等下一轮计算才能收敛，这期间复制会报找不到伙伴。

4.4 SYSVOL 走 DFSR，密码变更走 PDC Emulator：同步里的“特殊通道”

不是所有东西都走普通的 AD 分区复制。最典型的是 SYSVOL，它用来存放组策略模板和脚本，在 Windows Server 2022 上由 DFSR 服务负责复制，和用户/计算机对象的复制是两条独立管线。所以有时repadmin /showrepl看着一切正常，但 GPO 就是在新 DC 上不生效，问题很可能出在 DFSR 这边，后面的避坑章节会再展开。

同样特殊的还有密码变更。用户改密码一般只会落到当前认证的 DC 上，但密码需要尽快全域生效，否则用户换台 DC 认证就会用旧密码失败。AD 的做法是：密码修改会被标记为“紧急复制”，优先推到 PDC Emulator 这台 DC，再由它通知其他 DC。账号锁定和解锁也有类似行为。这就解释了为什么 FSMO 角色中的 PDC Emulator 通常被建议放在网络质量最好、性能最高的 DC 上——它承担了很多“紧急消息枢纽”的活儿。备域控可以在日常接管认证，但那些“秒级生效”的操作最终还是要找 PDC Emulator。

4.5 五种 FSMO 角色的默认位置与迁移时机

同步机制看懂了，再看 FSMO 就不会觉得它神秘。FSMO 只是五个需要“单点持有”的权威角色，默认都在主域控上。

迁移角色的命令是Move-ADDirectoryServerOperationMasterRole，比如把 PDC Emulator 挪到 DC02：

Move-ADDirectoryServerOperationMasterRole ` -Identity "DC02" ` -OperationMasterRole PDCEmulator ` -Force

什么情况下值得动手迁移？最常见的是主域控要退役、硬件维护时间很长，或者主域控已经彻底宕机且备份不可用时。我一般会明确区分“转移”和“夺取”：主控还活着用转移，干干净净；主控确定救不回来才用-Force夺取。夺取命令执行后，原主控如果又上线，两台 DC 会因为角色冲突闹出很大的动静，属于高危动作，务必确认物理上已经把原主控断电再操作。

5. 备域控同步常见的 5 个坑：报错现象、原因与处置顺序

5.1 备域控联系不上主域控，八成是 DNS 与防火墙

现象：备控执行Install-ADDSDomainController时报“无法联系域控制器”，或者加域时提示找不到域，卡在一个错误上来回打转。

原因：最普遍的是备控没把首选 DNS 指到主域控，系统还在用网关或外部 DNS 解析域名，自然找不到_ldap._tcp记录。其次是 Windows 防火墙或主机安全软件拦截了域控端口，加域流量被静默丢弃。

解决：先把 DNS 字段改掉，用Set-DnsClientServerAddress指向主控 IP；再用nslookup -type=SRV _ldap._tcp.corp.example.com确认返回的是 DC01 地址。如果解析正常还连不上，用Test-NetConnection 192.168.10.10 -Port 389逐端口测，域控至少要放行 TCP 135、389、445、464、636、3268 以及 49152-65535 的 RPC 动态端口，UDP 389 和 53 也不能漏。这块最磨人，建议提前在主机安全策略里对“域控之间的流量”放开白名单。

5.2 长期“目标主体名称不正确”：时间偏差超过 5 分钟

现象：备控加域成功、复制也正常，但客户端从备控认证时反复报“时钟偏差太大”或“目标主体名称不正确”，有时候过几小时又自己恢复，毫无规律。

原因：Kerberos 协议默认容忍 5 分钟时间差。虚拟机 DC 每次暂停、休眠、快照恢复都会导致系统时间漂移，备控时间源没对齐主控，就会间歇性触发认证失败。

解决：把域内时间源收敛到一个方向。主控 DC 自己可以指向可靠外部时间源，其余 DC 全部指向主控，不要每一台都去抓外部 NTP，否则它们会互相打架。检查命令是w32tm /query /source和w32tm /query /status，需要补救时用w32tm /resync /rediscover。这类问题有个特点：看 AD 部件测试全绿，但只要用户时间一到就冒头，排查时先看时间，别急着翻组策略。

提示：域控的时间源配置最好在部署时一次到位，并在巡检脚本里加一条时间源检查，能省掉大量认证类工单。

5.3 快照回滚把 DC 拉进 USN 回滚隔离区

现象：一台 DC 是虚拟机，管理员图方便做了快照，后来把系统回滚到几天前。结果这台 DC 的复制伙伴开始报复制错误，事件日志里出现 USN 回滚相关警告，dcdiag 里这台 DC 被标记为隔离状态，拒绝接受新复制。

原因：快照回滚让 DC 的本地 USN 倒退回旧值，其他 DC 之前已经接收过比这更新的变更。当这台 DC 再次发起复制时，在伙伴看来它是在“把旧数据当成新数据”往外推，安全机制直接暂停了它的复制资格。

解决：不要拿快照当后悔药。域控必须用 Windows Server Backup 的“系统状态备份”或其他受支持的 AD 备份方案保护，快照仅适合作为短期临时的“撤销操作”，不能用于常规恢复。已经发生 USN 回滚时，不要手工改 USN 数据库，那会污染整个域；正确出路是从备份恢复这台 DC，或者干脆退域重装再提升为额外 DC，并确认 FSMO、GC、SYSVOL 三项都已还原到目标状态。这一条是很多人用血泪换来的。

5.4 SYSVOL 不共享、组策略不生效，复制状态却正常

现象：在主域控上修改了默认域策略，客户端客户端（若干）一直没有生效；登录 DC02 一看，\DC02\SYSVOL 共享要么不存在，要么里面 Policies 文件夹是空的。但跑repadmin /showrepl时 AD 分区复制显示全部成功。

原因：SYSVOL 根本不在普通 AD 复制管线里，它由 DFSR 负责。repadmin查的是目录分区，与 DFSR 的状态不互通，所以出现“AD 同步正常，SYSVOL 还是空”的割裂现象。

解决：检查事件查看器里的 DFS 复制日志，筛选错误事件；再用dfsrdiag /poll或 DFS 管理控制台确认复制组状态。如果 DFSR 初始化没完成，SYSVOL 就不会有内容。常见补救是等 DFSR 完成首次初始化，或者通过DfsrAdmin相关命令查看积压（backlog）。注意不到万不得已不要用“非权威还原”这种偏门招，那是在单 DC 环境下才能慎用的操作，多 DC 环境做错会清掉整份策略数据。

5.5 成员机“找不到域”与信任关系失败

现象：某台文件服务器在加域备域控后运行了几个月，某天突然报“此计算机与域之间的信任关系失败”，用户全部无法登录，重启也无法恢复。

原因：域内机器账户的密码默认每 30 天轮换一次。如果这台成员机近期从备份恢复过，或者它联络的 DC 上的机器账户信息是旧的，Kerberos 就会因为新旧口令不匹配踢掉信任关系。

解决：用本地管理员登录，执行：

Reset-ComputerMachinePassword -Server DC02 -Credential (Get-Credential)

-Server指定一台健康 DC，命令会重新同步机器账户密码。这一步失败的话，只能把机器从域中退出再重新加域。这类问题看起来吓人，其实原理就是“机器账户密码没同步”，先重置，不要急着重装系统。

6. 30 秒健康巡检：三条命令加上备份习惯，把域控故障挡在发生前

每次登录域控，我做的第一件事不是打开事件查看器，而是跑一组固定命令，把它们输出到一个统一目录，然后扫一眼有没有非零数值。

$log = "D:\ADHealth\$(Get-Date -Format yyyyMMdd)" New-Item -ItemType Directory -Force -Path $log dcdiag /q /v *> "$log\dcdiag.txt" repadmin /replsummary *> "$log\repl.txt" repadmin /showrepl * /csv *> "$log\showrepl.csv" w32tm /query /status *> "$log\time.txt"

dcdiag /q /v只显示故障，正常项目不刷屏；repadmin /replsummary看复制延迟，任何一栏从“0”变成几千秒就要当回事；repadmin /showrepl * /csv把每台 DC 的入站伙伴落盘，出了问题能立刻看出是哪条链路断了；w32tm确认时间源一致。把这些命令放进任务计划，每周跑一次，再让监控系统盯住结果文件里的非空输出，很多“半夜域控癫了”的工单根本不会发生。

我自己的习惯还有一个补充：任何结构性操作之前，比如转移 FSMO、加装新 DC、升级功能级别，先做一次系统状态备份，并导出一份repadmin /showrepl的基线。如果操作把域搞坏了，系统状态备份就是真正的后悔药，基线数据则能告诉你“坏之前复制是正常的，所以问题一定出在这次变更里”。这套思路帮我排除过无数次“灵异故障”，也让我慢慢意识到：AD 域控的稳定不是靠神操作，而是靠每台 DC 的 DNS、时间、端口、备份这四件事都不掉链子。备域控看起来是“多一台机器”，它真正的价值是让域有了冗余，但冗余的前提是同步健康。希望这篇笔记能帮你在搭完主域控和备域控之后，睡得安稳一点。

本文还有配套的精品资源，点击获取