简介：面向Windows Server 2022 AD域控部署与高可用运维人员的一份完整图解指南，聚焦主域控和备域控的搭建、配置与同步机制，适合有一定Windows Server基础、负责企业内网认证与DNS架构的IT技术人员。内容以Hyper-V虚拟机环境为基准，依次讲解服务器主机名修改、静态IP配置、AD域服务角色安装、DNS指向设置，并解释AD域服务、全局编录、DSRM密码、NetBIOS名称等核心概念。备域控部分涵盖加入主域、角色安装与同步配置，通过主备切换测试验证主域中断时用户仍可正常访问域控服务，确保认证、DNS与组策略等核心服务不中断。资源为单个PDF文档，共15.25MB，内含详细截图和配置提示，图文结合，便于按章节对照实操。已有893人学习下载，适合需要从零搭建企业AD域控、做高可用改造或排查域控故障的技术人员参考。
1. AD域控不是装完就算完：Windows Server 2022主备域控落地前先想清楚这几件事
在Windows Server 2022上安装AD域控，单台主域控的搭建其实是一个标准流程：加角色、升域、配DNS，半小时就能走完。但真正让运维头疼的从来不是那台“主”域控，而是备域控加进来之后，同步机制能不能稳定跑住。DNS解析顺序错一位、时间偏差超过5分钟、甚至网卡上多勾了一个IPv6，都可能让备域控成为一台“只入域、不同步”的黑匣子。这篇笔记面向的是正在用Windows Server 2022搭建主备域控的运维和基础设施工程师，目标是让你照着做出一套能通过dcdiag健康检查的域环境，并理解同步背后的USN和复制拓扑，知道出故障时看哪个计数器。适合不想把生产环境当试验田、想一次把主备域控搭规矩的人。
2. 主域控安装：从服务器角色到DNS的一次拉起
2.1 装机前的三项硬性检查和两项玄学准备
在动命令之前，先花十分钟做硬性检查。第一项是主机名，域控的主机名一旦确定就别轻易改，Windows Server 2022里重命名域控后会触发一系列复制问题，不如一开始就按“DC01、DC02”这样的规范命名。第二项是静态IP，域控的IP必须是固定的，我一般会在安装前把IPv4地址、子网掩码、网关、DNS都设好，DNS先指向自己，备域控的DNS指向主域控。第三项是时间同步，域控的时间源要指向一台可靠的NTP服务器，主域控最好能直接同步外部时间源，备域控则默认从主域控同步。
两项玄学准备，其实是经验教训。第一，关闭IPv6的随机标识符，虽然IPv6不是不能用，但在纯IPv4环境中，域控的DNS注册会多出不少干扰记录，不如直接禁用不需要的IPv6绑定，只保留IPv4。第二，确认防火墙的“域配置文件”没有禁止ICMPv4回显，虽然AD复制走的是TCP动态端口，但ping不通会让很多同事误以为域控宕机了，排查时自己被自己人的工单烦死。我一般还会顺手把两台服务器的时区都设置为UTC+8，避免备域控和主域控因时区不同导致日志时间错乱。
2.2 用PowerShell安装AD DS并完成域控提升的完整命令
Windows Server 2022的安装方式很直接，服务器管理器图形界面能搞定，但我在生产环境里更习惯用PowerShell，理由有两个：一是输出信息完整，报错时能直接看到是哪个组件失败；二是可以写成脚本复用，下次装第三台域控时只改参数。下面是主域控的安装命令序列。
# 以管理员身份运行 # 第一步：安装AD DS角色和DNS管理工具 Install-WindowsFeature AD-Domain-Services -IncludeManagementTools # 第二步：将服务器提升为新域的第一台域控 # 域名按你的内部域名修改，例如 vsphere.lan Import-Module ADDSDeployment Install-ADDSForest ` -DomainName "corp.example.com" ` -DomainNetbiosName "CORP" ` -ForestMode "WinThreshold" ` -DomainMode "WinThreshold" ` -InstallDns:$true ` -SafeModeAdministratorPassword (ConvertTo-SecureString "P@ssw0rd_2024" -AsPlainText -Force) ` -NoRebootOnCompletion:$false ` -Force:$trueInstall-WindowsFeature AD-Domain-Services这条命令把AD DS角色装进系统，但它只是个空角色，真正让这台服务器变成域控的是Install-ADDSForest。参数里-DomainName是你要创建的根域名，这里注意内部域最好用 .lan 或 .local 之类的非公网后缀，避免和公网域名产生解析歧义。-ForestMode和-DomainMode我一般直接用WinThreshold，在Windows Server 2022上就等价于Windows Server 2016级别，功能集完整，兼容性也不差。-InstallDns:$true会顺带把DNS服务器角色装好，主域控必须同时是DNS服务器。-SafeModeAdministratorPassword是目录服务恢复模式（DSRM）的密码，忘了它等于失去域控的后悔药，一定要单独记在密码库里。最后-NoRebootOnCompletion:$false让它提升完成后自动重启。
2.3 主域控安装后必须验证的四个点
重启完别急着把备域控拉进来，先确认主域控本身是健康的。我一般会依次做四件事。第一条命令验证AD数据库是否可用，dcdiag /test:promotions能看到域控提升过程的完整记录，如果这里报错，后面加备域控肯定会出幺蛾子。第二条命令查DNS区域是否已创建，Get-DnsServerZone应能看到你的域名正向查找区域，且区域类型是Active Directory集成区域。第三条命令确认NetBIOS名称已注册，nltest /dsgetdc:corp.example.com能定位到当前域控，输出里应该有“DC”字样。第四条是检查SYSVOL共享，net share里能看到SYSVOL文件夹，没有它，组策略就无从谈起。
做完这四项，主域控才算真正可对外服务。这时候再给服务器打上最新补丁，重启一次，等系统稳定后再开始备域控的搭建。我见过有人跳过补丁直接加备域控，结果备域控加进来后复制时报错，一查是主域控缺了个安全更新，白白折腾了一个晚上。
3. 备域控搭建：加域、提升、把同步链路拉起来的两种方式
3.1 为什么需要备域控：单点故障与同步机制的关系
备域控的核心价值不是“多一台机器”，而是当主域控宕机时，认证请求还能被其他域控处理，也就是把单点故障变成可恢复的故障。Windows Server 2022的域控之间通过多主复制来同步数据，任何一台域控上的账号变更、密码修改、组策略编辑，都会通过复制机制传到其他域控。如果没有备域控，主域控硬盘坏了，整个域就瘫痪了，只能用DSRM模式慢慢恢复。而备域控加进来后，即使主域控完全挂了，客户端把DNS指向备域控，认证和授权依然能继续，这就是“业务连续性”的底层逻辑。
但这里有个关键认知：备域控不是主域控的“克隆”，它是一台拥有完整AD数据库副本的独立域控，可以接受写请求，也可以作为DNS服务器提供服务。在同步机制里，主域控和备域控之间是平等关系，唯一的“主”只是FSMO角色持有者，平时固定在主域控上，必要时可以转移或抢占。所以搭建备域控时，你要做的不是“备份主域控”，而是“在第二台服务器上创建一个同域的额外域控”。
3.2 备域控加域并提升为额外域控的两种方法
备域控的搭建路径比主域控多两步：先把服务器加入到现有域，再提升为额外域控。这里有两种常见做法，图形界面和PowerShell各有适用场景。图形界面适合新手，能看到每一步的向导提示；脚本方式适合重复部署多台备域控或需要远程操作的情况。下面是我经常用的PowerShell方式。
# 在准备成为备域控的服务器上运行，管理员权限 # 第一步：把服务器加入域，需要域管理员凭据 $cred = Get-Credential CORP\Administrator Add-Computer -DomainName "corp.example.com" -Credential $cred -Restart -Force # 重启后登录，继续执行第二步：安装AD DS角色 Install-WindowsFeature AD-Domain-Services -IncludeManagementTools # 第三步：提升为额外域控 Import-Module ADDSDeployment Install-ADDSDomainController ` -DomainName "corp.example.com" ` -InstallDns:$true ` -ReplicationSourceDC "DC01.corp.example.com" ` -SiteName "Default-First-Site-Name" ` -SafeModeAdministratorPassword (ConvertTo-SecureString "P@ssw0rd_2024" -AsPlainText -Force) ` -NoRebootOnCompletion:$false ` -Force:$true这段脚本里的关键参数是-ReplicationSourceDC，它指定备域控从哪台主域控拉取初始复制数据。如果你不显式指定，系统会自动选择一个可用域控，但在跨网段环境下，自选可能选到一台网络路径很差的域控，复制极慢。-SiteName参数在多站点部署中很重要，如果单站点则保持默认的Default-First-Site-Name。备域控提升完成后会自动重启，然后开始从主域控复制整个AD数据库、SYSVOL和DNS区域。这个过程会持续几分钟到几十分钟，取决于AD数据量大小，期间你可以登录备域控查看事件日志，关注Directory Service日志里ID为1931的事件，它表示复制已经完成。
3.3 备域控搭建完后的健康检查命令
备域控重启回来后，先别急着收工。登录备域控，运行dcdiag /c进行全项检查，重点看Advertising、Replications、Services这三个测试结果。Advertising报错表示备域控没有把自己广播到DNS里，客户端找不到它；Replications报错表示复制链路中断，备域控的数据停留在某个时间点；Services报错则可能是关键服务没启动，比如NTDS或KDC。
紧接着用repadmin /showrepl DC02查看复制拓扑显示结果，正常的输出会列出“DC01”的入站伙伴，并显示“Consecutive failures = 0”。看到这句话，说明备域控已经成功接入了同步链路。然后回到主域控上，用Get-ADDomainController -Filter *查看所有域控列表，确认DC02处于“Enabled”状态。最后，在一台测试客户端上把DNS改指向DC02，执行nltest /dsgetdc:corp.example.com，如果能返回DC02的名称，说明备域控已经能承载认证请求了。
4. 主备域控同步机制：DFS-R、USN、复制拓扑到底在同步什么
4.1 同步机制的三层底细：USN、复制拓扑和有状态同步
很多人把AD同步想得太玄妙，其实底层就是三层结构。最底层的是USN（Update Sequence Number），每个域控上的每个对象属性都有一个更新序列号，当你在主域控上修改一个用户密码，这条变更会被记录一个USN。第二层是复制拓扑，Windows Server 2022默认使用KCC（知识一致性检查器）自动生成复制伙伴关系，同一站点内通常形成环状拓扑，比如三台域控会形成一个单向环。第三层是复制引擎，Windows Server 2008之后的AD使用DFS-R复制SYSVOL内容，而AD数据库本身通过RPC协议在复制伙伴间传递变更。
同步机制的精髓是“有状态同步”：每台域控都会记录自己发送到对方的USN向量，以及从对方接收到的USN上限。复制伙伴之间互相请求“从上次的USN之后有哪些更新”，而不是每次全量复制。这样一来，增量更新非常高效，但也带来一个隐患——如果一台域控宕机时间过长，它的USN向量会落后得太多，重新上线后可能需要一次大同步，甚至进入“僵局”状态，此时必须手动干预。
4.2 用repadmin和dcdiag查看同步状态的常用命令
同步机制出了问题，最怕的就是“猜”。好在Windows Server 2022自带了一套诊断工具，用repadmin和dcdiag就能看清同步链路的状态。下面是我每次排查同步问题都会先跑的几条命令：
# 查看本机的复制伙伴和入站/出站状态 repadmin /showrepl # 比较两台域控的元数据版本，确认对象是否已复制到所有域控 repadmin /showvector "CN=Schema,CN=Configuration,DC=corp,DC=example,DC=com" # 查看所有域控的复制状态摘要，输出当前告警 repadmin /replsummary # 检查域控健康状态，重点看复制和DNS测试 dcdiag /test:replications /test:dnsrepadmin /showrepl的输出是排查的首选入口，每台入站伙伴的“Last replication attempt”和“Last success”时间会直接告诉你复制是否卡住。repadmin /showvector有点类似版本号对比，能看到某个对象在每台域控上的USN值，如果某台域控的值明显落后，说明那台域控的复制更新有问题。repadmin /replsummary输出里“Failing”那一列数字如果大于0，就顺着源域控名称一个个查。dcdiag /test:replications是最权威的复制检验，它会在当前域控和其他所有域控之间尝试复制并验证结果。
4.3 备份与恢复中的同步陷阱
同步机制在备份恢复场景里有个特别容易翻车的点：如果你用快照或备份软件恢复了一台域控，而它在宕机期间产生了未被复制的变更，那么恢复后的域控状态就会和真实域环境产生冲突。更严重的是，如果恢复的是一台“旧”的域控，它的USN向量会比当前其他域控低，恢复后会把一些已经删除的对象回滚，形成“墓碑对象复活”。Windows Server 2022的AD为了避免这种情况，引入了基于备份的恢复判断机制，系统会检查恢复后的数据库是否比现有复制伙伴“更旧”，如果旧太多，会拒绝启动NTDS服务。
所以我的经验是：备份域控之前，先确认repadmin /showrepl已经没有任何失败记录；恢复后第一时间运行dcdiag /test:replications，确认它在复制拓扑里没有制造环回复制。如果恢复操作不可避免，先在测试环境验证一遍，别在生产环境里去赌“应该能同步回来”。
5. AD域控搭建与同步的7个避坑记录：现象、原因和解决
5.1 备域控加域失败，报错“找不到域控制器”
现象：执行Add-Computer加域时提示“找不到域控制器”，或者卡在定位域名的阶段十几分钟没响应。
原因：备域控的DNS没有指向主域控，它的首选DNS服务器还是公网DNS或路由器IP。加域动作第一步是向DNS查询SRV记录，_ldap._tcp.corp.example.com，找不到SRV记录自然无法联系域控。
解决：把备域控的IPv4首选DNS改为DC01的IP地址，辅DNS暂时留空或填入DC02自身。改完后用nslookup -type=SRV _ldap._tcp.corp.example.com验证，能返回DC01的A记录后再执行加域。
5.2 备域控提升后同步失败，事件ID 578
现象：Directory Service日志频繁出现ID 578事件，复制失败提示“拒绝访问”或“抽样错误”。
原因：两台域控的系统时间差距超过5分钟，Kerberos认证直接拒绝复制请求。Windows Server 2022域控之间默认的时间容差是5分钟，超过这个值，任何RPC复制调用都会被安全机制拦下。
解决：把主域控和备域控的时间源都统一到同一台NTP服务器。主域控上执行w32tm /config /manualpeerlist:"pool.ntp.org" /syncfromflags:manual /update，备域控执行w32tm /config /syncfromflags:domhier /update，然后再用w32tm /query /status确认最后同步的源。
5.3 被动同步慢：repadmin /showrepl显示last success很久以前
现象：备域控已经入域并提升成功，但repadmin /showrepl显示入站复制的“Last success”是十几小时前，且“Consecutive failures = 5”。
原因：最常见的是复制端口被防火墙拦截。AD复制依赖RPC动态端口（默认在49152-65535），如果防火墙策略只开放了ICMP和137-139端口，复制请求会一直失败。另一种可能是备域控上开启了第三方安全软件，拦截了lsass进程的网络流量。
解决：在防火墙里放行“Active Directory Domain Services”的程序规则，或者在入站规则中开放TCP动态端口范围。然后执行repadmin /syncall /AdeP强制触发一次复制，再观察事件日志。
5.4 重装备域控之前忘了做元数据清理
现象：一台失败的备域控被重装后，再次加入现有域并提升，提示“目录服务已存在”或“无法复制”，dcdiag报“cache/locality”错误。
原因：旧域控的计算机账号和NTDS设置对象还残留在AD数据库中，新服务器使用了相同主机名，系统认为这台域控还活着，导致元数据冲突。
解决：重装前务必执行元数据清理。在主域控上打开“AD站点和服务”，找到旧DC的NTDS Settings对象并删除，或者用命令行更彻底：ntdsutil的“metadata cleanup”命令。如果已经重装并加域失败，可以先从域中退出，清理干净后再加域。
5.5 主域控降级后旧DNS记录残留
现象：主域控降级后，DNS区域里还留着它的NS记录、A记录和SRV记录，客户端偶尔还能解析到已下线的IP，导致认证间歇性失败。
原因：降级过程没有正确触发DNS记录的清理，或者DNS区域启用了“旧记录保留”策略。
解决：降级完成后的静默期，手动检查_msdcs.corp.example.com区域里的DC记录，删除旧主机名的A记录和CNAME。然后用dnscmd /zoneresetsecondaries强制更新NS记录，最后执行dcdiag /test:dns确认区域数据干净。
6. 域控验证和恢复演练的进阶技巧：把“能用”变成“敢切”
前面几章讲完了搭建和同步的原理与坑，最后这部分我想把重点放到“如何验证这套主备域控真的敢切换”。很多团队搭完域控，备份也做了，但从来没演练过主域控宕机场景。真出事的时候，才发现备域控的DNS没有正确向客户端广播，或者备域控上没有全局编录角色。下面这套验证和恢复演练的技巧，能让你在平时就把这些雷排掉。
先做角色持有者的体检。打开“AD用户和计算机”，右键域名选择“操作主机”，确认5个FSMO角色都在主域控上。然后用netdom query fsmo命令快速查看所有角色持有者名称。如果某个角色意外跑到了已下线的域控上，用ntdsutil的“roles”命令强行转移到可用域控。域控宕机后，如果确定原主域控无法恢复，就只能“抢占”FSMO角色，而不是“转移”，这是唯一能让你把域续命的手段。
再做一次“停止主域控”的切换演练。找一台测试客户端，把首选DNS改为DC02的IP，然后在一台临时虚拟机上搭建一台备份主域控，将5个FSMO角色全部转移过去，确认客户端认证全部走向备份主域控。演练过程里重点看一眼事件日志，有没有大量ID 1126或IDE 1136的报错，它们通常意味着DNS还是指到了旧主域控。演练结束后，再把角色转回原主域控，并跑一轮dcdiag /c和repadmin /replsummary，确认数据一致。
关于“全局编录”有个我踩过的坑：备域控默认在同一个域内，不会自动启用全局编录（GC），跨域认证和跨域查找依赖GC。在备域控的“NTDS设置”属性里勾选“全局编录”，它才能处理跨域的登录请求。如果你只有单域和单站点，这个不会立刻暴露问题，但一旦以后扩展子域，没启用GC的备域控就是摆设。
过滤掉筛选日志的经验也很重要。别看到repadmin /showrepl里一两行失败就慌，先看失败计数是不是持续增长。如果失败次数短时间归零，说明复制链路自愈了，不用重启服务。真正该警惕的是dcdiag里“Replications”测试连续多次失败，加上事件ID 1988持续刷屏，这时再考虑重启KCC或做repadmin /replsinglepack的手工同步。
我现在的习惯是每个月定时跑一次备域控切换演练，哪怕只是把DNS指过去观察半小时，也会让心里踏实很多。每次踩坑都记在团队wiki里，慢慢就把这套环境的脾气摸透了。希望这些从实际摸爬滚打里总结出来的过程，能帮你在搭建Windows Server 2022主备域控的时候少走几段弯路。
本文还有配套的精品资源，点击获取
