
简介面向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 域服务对网络参数非常敏感装之前必须把下面这张表定下来并写进变更记录。参数项主域控建议值备域控建议值说明主机名DC01DC02简短、语义明确避免带下划线IP 地址192.168.10.10/24192.168.10.11/24必须静态不能 DHCP首选 DNS192.168.10.10192.168.10.10备控在入域阶段优先指向主控备用 DNS192.168.10.11192.168.10.11主控装完后把两个地址都写上默认网关192.168.10.1192.168.10.1有路由需求才需要时间源本机为权威同步主控偏差超过 5 分钟会直接认证失败域功能级别WinThresholdWinThreshold2022 没有单独的 2022 功能级别一个容易翻车的点服务器如果有多块网卡域控会把每块网卡的地址都注册进 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:$trueDomainName是你要创建的完整域名这里用 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 -typeSRV _ldap._tcp.corp.example.comnetdom 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 -typeSRV _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 fsmorepadmin /replsummary会列出每台 DC 的最小/最大复制延迟正常情况所有行都是 0 或很小的数字超过几十分钟就要警惕。repadmin /showrepl DC02能逐条看 DC02 的入站复制伙伴、上次成功时间和失败信息是定位复制故障最直接的命令。第三条命令确认 DC02 的 GlobalCatalog 为 TrueGC 缺失会导致大量客户端对象查找失败。最后再用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 只是五个需要“单点持有”的权威角色默认都在主域控上。角色级别作用Schema Master林级掌控 AD 架构扩展装 Exchange 等应用时要先找它Domain Naming Master林级管理域的添加和重命名RID Master域级给各 DC 分配 RID 池DC 靠它生成对象 SIDPDC Emulator域级密码/锁定的紧急复制枢纽域时间权威Infrastructure Master域级维护跨域对象引用若全是 GC 则作用很小迁移角色的命令是Move-ADDirectoryServerOperationMasterRole比如把 PDC Emulator 挪到 DC02Move-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 -typeSRV _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.txtdcdiag /q /v只显示故障正常项目不刷屏repadmin /replsummary看复制延迟任何一栏从“0”变成几千秒就要当回事repadmin /showrepl * /csv把每台 DC 的入站伙伴落盘出了问题能立刻看出是哪条链路断了w32tm确认时间源一致。把这些命令放进任务计划每周跑一次再让监控系统盯住结果文件里的非空输出很多“半夜域控癫了”的工单根本不会发生。我自己的习惯还有一个补充任何结构性操作之前比如转移 FSMO、加装新 DC、升级功能级别先做一次系统状态备份并导出一份repadmin /showrepl的基线。如果操作把域搞坏了系统状态备份就是真正的后悔药基线数据则能告诉你“坏之前复制是正常的所以问题一定出在这次变更里”。这套思路帮我排除过无数次“灵异故障”也让我慢慢意识到AD 域控的稳定不是靠神操作而是靠每台 DC 的 DNS、时间、端口、备份这四件事都不掉链子。备域控看起来是“多一台机器”它真正的价值是让域有了冗余但冗余的前提是同步健康。希望这篇笔记能帮你在搭完主域控和备域控之后睡得安稳一点。本文还有配套的精品资源点击获取