很多IT运维第一次接触AD域都是从单台域控制器开始的。装一台Windows Server跑一遍dcpromo建好域把办公电脑一股脑加进来域用户正常登录、访问共享、下发组策略一切都挺顺手。等这套环境跑了大半年突然有一天这台服务器硬件报警或者系统分区被日志塞满你才发现一个问题全公司几百号人的身份验证、DNS解析、文件共享权限全系在这一台机器上。这个时候再想加一台辅域控制器心里是没底的因为已经完全依赖单点了。我最近就帮一个客户处理过这个事。他们的情况很典型一台主域控跑了两三年还兼职DNS和DHCP内网所有终端都指定它做DNS服务器。客户想趁周末低峰期加一台辅域控制器给现有环境做个冗余。整个过程走下来踩了几个不小的坑也把很多细节重新梳理了一遍。这篇文章就把“给AD域添加辅域控制器”这件事从头到尾讲清楚包括部署前的规划、具体操作步骤、部署后的验证方法以及主域信息怎么通过AD内置机制自动同步到辅域。这篇文章适合刚接手AD域运维的新手也适合准备给现有域环境增加冗余的工程师。内容基于Windows Server 2016/2019/2022环境命令和步骤基本通用。1. 部署前规划先把思路理顺1.1 为什么需要辅域控制器先说一个容易被忽略的事实AD域环境中的主域控和辅域控并不是传统意义上的“主从复制”。AD使用多主复制模型除了少数FSMO角色外大部分数据用户账号、组策略、DNS区域、SYSVOL脚本等在所有域控之间是双向同步的。所以严格来说并没有“主域控”和“备域控”的文件系统之分但我们习惯上仍然把持有FSMO角色的那台称为主域控另一台作为辅域控制器在它故障时接管角色。辅域控制器的价值体现在几个层面身份验证冗余。用户登录时域控负责校验账号和密码。如果只有一台域控它一宕机所有域用户连登录本机都会受影响。DNS和GC冗余。域控往往也承担AD集成DNS区域和全局编录GC。多一台域控就意味着DNS解析和跨域查询多一个可用节点。SYSVOL和组策略的容灾。组策略模板存储在SYSVOL共享中域控之间会自动复制。辅域控可以作为文件复制的备用副本。分担负载。人多的时候身份验证请求可以分散到不同域控上。我经常给客户打一个比方域控就像公司大门的门禁系统。原来只有一台刷卡机坏了整栋楼都进不去。辅域控就是在另一个门口加装了一台刷卡机同时和原来的那台共享同一套人员名单。这个“名单同步”就是AD复制机制在做的事。1.2 部署前的硬性条件和规划清单加辅域控制器不是装好系统直接跑个向导这么简单前面有几个硬性条件必须满足否则大概率会中途失败或复制异常。第一时间同步。域环境内所有机器的时间偏差不能太大默认Kerberos认证允许的最大偏差是5分钟。辅域控在部署前就应该把时间源指向主域控或者统一指向同一台可靠的时间服务器。我有一次没注意这个结果域内时间差到30多秒身份验证各种报错。第二DNS解析。辅域控必须能够通过DNS找到主域控。这是加域和复制的基础。最稳妥的做法是把辅域控的DNS服务器地址指向主域控的IP或者指向另一个AD集成DNS服务器的IP。千万别把DNS指向路由器甚至公网DNS否则你会发现“找不到域控”的错误一个接一个。第三网络互通。确认辅域控和主域控之间TCP/UDP 53DNS、88Kerberos、135RPC、389LDAP、445SMB等端口畅通。如果是跨站点部署还要考虑站点拓扑和子网规划。第四磁盘和备份。辅域控上会存放AD数据库NTDS.dit、日志文件、SYSVOL建议C盘空间预留80GB以上并且提前配置好系统状态备份计划。这是很多人忽略的环节等真出了问题才发现没备份。下面是一份我在实际项目中使用的“加辅域控前检查表”你可以直接拿去用检查项要求说明主机名不重复且符合命名规范例如DC02避免使用中文或特殊字符静态IP固定不变且可路由不要使用DHCP分配给服务器DNS指向指向主域控或AD集成DNS这是能否发现域环境的关键时间同步与主域控偏差小于5分钟建议统一指向PDC模拟器补丁版本系统补丁已更新完毕防止复制所用的RPC接口因补丁问题报错系统状态备份部署前已执行一次备份用于误操作回滚防火墙策略域控之间所需端口已放行可临时关闭防火墙测试但不建议长期这样提示如果环境中已经存在多台域控需要先检查AD健康状态确保现有复制正常再添加新域控。在一个本身就有复制故障的环境里强行加域控只会让问题更复杂。1.3 网络热词背后的“主备”概念怎么理解很多人都搜过“本地两台AD域控分主备”这类话题。这里要澄清一个概念AD架构本身没有主备之分所有域控地位平等数据多主复制。但生产环境中我们通常只让一台域控持有FSMO角色平时所有高权限操作、时间同步都走这台于是它成了事实上的“主”。另一台域控持有GC平时接受身份验证请求但它的GC优先级更低域控定位时DC Locator会优先返回角色更全的机器。这种做法主要是为了操作可控。如果两台域控都持有同样的角色出现网络分区两台机器互相ping不通时两边都可能修改数据会导致更新冲突和复制冲突。所以传统做法是主域控拿全部FSMO角色辅域控平时只做验证和冗余。当主域控出问题时再把FSMO角色“夺”到辅域控上。这个“夺”的过程在Windows Server里叫“FSMO角色夺取”后面章节我会详细说。2. 辅域控制器部署全程拆解2.1 准备操作系统和基础配置辅域控推荐使用和主域控相同版本或更高版本的Windows Server。举个例子如果主域控是Windows Server 2016辅域控装Windows Server 2019或2022也没问题但域功能级别会受最低版本限制。如果你打算以后提升域功能级别最好统一版本。操作系统装完之后有四个基础配置必须先做设置准确的计算机名比如DC02。建议不要用“TESTSERVER”这类看不出用途的名字域控多了之后会非常混乱。设置静态IP地址并确保子网掩码、网关、DNS配置正确。我在实验环境看到很多人IP没改直接用了DHCP这种环境下一旦IP变化域控复制就会出现各种奇怪的问题。将辅域控加入现有的AD域。这一步可以通过“系统属性”-“更改设置”来操作输入域管理员凭据即可。注意在加域完成之后、提升为域控之前需要重启一次。执行Windows Update把系统补丁打齐。尤其要注意的是部分旧补丁组合在域控提升过程中会引发SYSVOL复制问题。我建议加域之前就完成补丁更新避免提升过程中自动重启。注意很多人问“加辅域控之前要不要先把服务器加域”答案是要。Windows Server在提升为附加域控制器时会要求本地计算机已经是域的成员或者直接输入域凭据也能完成加域并提升。但分两步走更稳妥便于问题定位。这里有一个容易被忽略的细节DNS指向。辅域控的网卡DNS应该指向主域控的IP并且是首选DNS。如果主域控同时兼任DHCP服务器记得在DHCP地址池的DNS选项里更新把辅域控IP也填进去。这样新接入的终端才能自动获取到新的DNS地址辅助解析。两个域控的IP都作为DNS服务器这在多域控环境里是标准做法。2.2 安装AD DS角色并提升域控基础配置完成后正式开始部署。以Windows Server 2019为例操作为打开“服务器管理器”点击“添加角色和功能”选择“基于角色或基于功能的安装”勾选“Active Directory域服务”一路下一步完成安装。这一步只是装角色还没有真正把它变成域控。装完角色后服务器管理器右上角会弹出一个感叹号提示点击“将此服务器提升为域控制器”。这里会出现三个选项“添加新林”只在从零搭建全新域环境时才选。“将域控制器添加到现有域”适合添加辅域控。填上主域控所在的域名比如corp.example.com输入域管理员凭据。“添加新域”用于在现有林中新建子域或树域本次不涉及。选第二项后点击“更改”选择目标域。这一步系统会验证凭据和网络连通性如果DNS指向错了这里就会开始报错。常见的一个报错是“找不到域控制器”十有八九是DNS配置有问题。接下来是域控制器选项设置需要注意站点名称保持默认也就是“Default-First-Site-Name”除非你已经规划了多站点。目录服务还原模式DSRM密码一定要记住。这个密码用于域控修复和还原场景忘了会非常麻烦。建议用独立的密码管理工具记录不要和域管理员密码混用。勾选“全局编录(GC)”默认是勾选状态务必不要去掉。GC不仅在跨域查询时有用在多域环境的登录验证中也承担了重要角色。即便是单域环境也建议保留GC。DNS选项会出现“DNS服务器”的提示建议勾选“从现有DNS区域创建DNS委派”相关的选项。有些环境因为DNS区域权限设置问题会在这一步报“DNS委派无法创建”的警告。如果只是警告通常可直接忽略提升完成后在DNS管理器中手动检查。再往后是“其他选项”页面会要求指定“从介质安装(IFM)”这一步如果网络复制条件良好就直接留空。下一步的“路径”页面有三个目录AD数据库、日志文件、SYSVOL。最佳实践是把数据库和日志放到非系统盘比如D盘SYSVOL则放在系统盘。这样万一系统盘故障AD库和日志还有可能抢救出来。确认无误后系统会进行先决条件检查。如果出现红叉逐个看说明。最常见的提示是“无法创建DNS委派”这个多为警告不影响安装。还有一种是“本地计算机上的DNS服务需要配置静态IP”这是因为服务器网卡设置了自动获取DNS改成静态就好了。检查通过后点击“安装”之后服务器会自动重启。服务器重启后辅域控的角色就已经生效了。你可以从主域控上打开“Active Directory用户和计算机”在域名节点下找到“Domain Controllers”正常情况下应该能看到两台域控。2.3 主AD域信息如何同步到辅域辅域控提升完成后AD数据并不会瞬间全部复制过来。复制依赖AD的多主复制机制和KCC知识一致性检查器自动生成的拓扑数据的同步需要一段时间。在复制期间新加的域控会自动从现有的域控获取以下关键数据NTDS.DIT数据库包含域内所有用户和计算机账号以及AD架构、配置分区的数据。SYSVOL包含组策略模板和脚本通过DFSR分布式文件系统复制进行同步。DNS区域如果DNS区域是AD集成的会自动复制到所有域控。你可以打开“事件查看器”关注Directory Service日志会看到类似“已从源DC完成第一次复制”的信息。也可以使用命令repadmin /replsummary来查看复制状态这个命令会列出每台域控的复制失败情况和最近成功时间。正常情况下“失败数”应为0“最大延迟”应该在几十秒到几百秒之间。这里有个非常容易让新手焦虑的点辅域控提升完后的前10到20分钟用dcdiag检查可能会显示各种警告比如“服务尚未就绪”或“复制尚未完成”。这是因为系统正在做数据初始化很多服务还没完全启动。如果过半小时还报错才需要深入排查。提示SYSVOL的复制有单独的日志。如果你发现用户登录后组策略应用不完整或脚本没有执行优先查DFSR事件日志并确认文件和文件夹复制服务已启动。在早期Windows Server 2008时代经常需要手动执行dfsrmig /getglobalstate来检查SYSVOL迁移状态。很多人在网上搜索“主ad域信息怎么同步备ad域”其实答案就是你不需要手动同步AD域控之间会自动通过复制机制保持数据一致。你真正需要关心的是复制是否健康。文章后面我给出了具体的验证命令。3. 部署后的验证工作与用户登录临时配置文件问题3.1 用命令确认复制和角色状态辅域控重启完成后第一件事不是马上把客户端的DNS切过去而是先把所有检查项过一遍。我习惯按下面这个顺序来验证使用repadmin /replsummary查看整体复制情况。这是所有检查里最直观的一条命令。输出结果会告诉你每台域控向源域控复制是否有失败的增量同步。看到“失败的增量同步 0”就不用担心复制问题了。再使用repadmin /showrepl查看详细的复制伙伴和最近一次成功时间。如果最近一次成功时间是今天的日期说明复制在正常流动。然后使用dcdiag做一次全面的健康检查。dcdiag会检查DNS、AD数据库、复制、服务启动状态等。有一个比较常用的组合是dcdiag /v /c /e虽然日志长了些但覆盖面很全。你也可以单独跑dcdiag /test:dns来验证域控的DNS注册是否正常。第三个关键命令是netdom query fsmo用于查看五个FSMO角色当前由谁持有。刚搭建完辅域控时正常输出应该显示所有角色仍然落在原主域控上。这是正常的因为我们还没做角色转移。很多人会忽略一个细节新装的辅域控需要一定时间才能获得GC服务。你可以打开“Active Directory站点和服务”在“NTDS Settings”属性里查看“全局编录”是否已勾选。虽然默认会勾上但有时因为复制延迟GC状态可能处于“不完整”状态。在这种情况下如果客户端访问了这台域控但拿不到GC响应就可能出现登录缓慢或查询失败的问题。等复制完成后这个状态会自动修正。3.2 AD域用户登录出现temp临时账户的排查思路部署完辅域控后部分用户可能会遇到一个非常恼人的现象登录Windows时提示“Windows已加载临时配置文件”桌面路径变成临时目录以前的数据和设置全部消失。很多人在网上搜“ad域用户登录temp临时账户问题”踩过这个坑的人应该都懂那种抓狂的感觉。这个问题的根源是用户配置文件在登录时加载失败系统只能用临时配置文件替代。为什么会加载失败常见原因有以下几种一是用户配置文件目录损坏。比如不当关机、磁盘空间满、杀毒软件误删了配置文件夹里的文件导致注册表中ProfileImagePath指向的文件夹不存在或不可访问。二是注册表中ProfileList项损坏。AD域用户的配置文件在注册表的位置是HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList以用户SID命名。如果这个项下出现了一个以.bak结尾的损坏条目同时正常的SID条目又不在系统就会创建临时配置文件。三是组策略或文件夹重定向冲突。某些环境配置了漫游配置文件或文件夹重定向但文件服务器连接失败也会导致本地无法正常加载配置文件。排查步骤我简单梳理一下首先让用户正常通过域账号登录在登录界面时观察是否有报错。登录进去后打开注册表编辑器定位到ProfileList看该用户SID对应的条目是否存在且正常。如果看到两条同样开头的记录其中一条带有.bak后缀说明配置文件损坏了。解决方法是备份注册表和用户原来的配置文件夹一般在C:\Users下可能名为用户名.域名或用户名.001然后删除损坏的注册表项重新登录。有时候还要手动把原来的配置文件夹权限重置一下右键属性-安全-高级替换所有子对象的权限确保当前用户有完全控制权。我这里给一个经验性的建议很多临时配置文件问题并不是辅域控本身导致的而是用户原来登录的就是故障域控上的配置文件或者文件服务器上的漫游配置目录权限被搞乱了。辅域控上线后用户首次通过新域控认证如果配置文件的网络路径访问失败也会触发临时配置文件。所以排查时不仅要看客户端本地还要看文件服务器上的共享权限和网络连通性。注意临时配置文件问题如果只是偶发一次重启后能恢复正常通常不用过度处理。但如果同一用户机器上反复出现一定要检查配置文件注册表项和目录权限避免用户误以为数据丢失。3.3 日常运维建议多域控环境下的正确打开方式辅域控上线后运维方式也要跟着变。我把这几个“日常动作”的习惯改一下能省去后面很多麻烦一是定期查看复制健康。不建议只在出问题时才跑repadmin。可以建一个计划任务每周自动执行repadmin /replsummary把输出结果发到告警邮箱或用简单的脚本记录日志。复制健康是个“温水煮青蛙”的事问题通常不是一天爆发的。二是备份策略调整。每台域控都要做系统状态备份但要注意备份最好在非高峰时段进行并且备份软件要支持AD增量备份。Windows Server自带的Windows Server Backup就能做系统状态备份不需要额外采购商业软件。三是对主辅域控的角色分配要心中有数。建议做一张表格标明哪台机器持有FSMO角色、哪台是GC、DNS配置如何。一旦主域控故障你能在5分钟内判断出要夺取哪些角色而不是临时翻文档。另外还要注意高权限管理操作尽量只在主域控上做减少冲突风险。四是补丁和重启要错峰。多域控环境打补丁时要先辅后主避免所有域控同时重启。同时注意Windows Server补丁有时会影响复制特别是涉及RPC接口的补丁。打补丁前建议先看复制状态是否正常。4. 常见故障与主备切换实战4.1 常见报错和排查对照表我把实际工程项目里遇到的“加辅域控”相关故障整理成了一张速查表现象可能原因排查解决思路提升时提示“找不到域控制器”DNS指向错误或网络不通确认辅域控的DNS指向主域控IP使用nslookup 域名测试解析提升后复制失败防火墙端口未放行检查TCP/UDP 53、88、135、389、445端口可用Test-NetConnection测试FSMO角色无法查看缺少权限或RPC服务异常用域管理员执行netdom query fsmo确认RPC服务同步正常客户端登录缓慢GC尚未就绪或DNS解析顺序问题检查GC状态调整网卡DNS顺序优先使用主域控组策略不生效SYSVOL复制未完成查看DFSR事件日志用dfsrdiag /poll手动触发轮询时间不同步导致登录失败未配置NTP或偏差大在辅域控上执行w32tm /resync /force并配置NTP源为主域控USN回滚虚拟机快照回滚导致不要对域控做快照回滚操作这是AD域环境的大忌事件ID 1988/2042时间戳过大或复制架构问题参考微软文档通常需要强制对特定对象进行一次性初始同步4.2 主域控故障时如何让辅域控接管很多人搜索“本地两台AD域控分主备”真实关心的其实是主域控挂了以后怎么把辅域控转正先说清楚即使主域控宕机域内的用户账号验证、DNS解析通常依然可用因为辅域控上有这些数据的副本。但FSMO角色相关的操作会暂时不可用。比如无法新建用户账号RID Master和PDC Emulator相关、无法修改组策略PDC Emulator承担主要的时间同步和策略变更入口、无法添加新的子域Domain Naming Master等。“转正”的操作就是把FSMO角色从主域控转移到辅域控。操作步骤如下在辅域控上打开“命令提示符”以管理员身份运行ntdsutil。进入角色管理工具。输入roles再输入connections然后输入connect to server 辅域控名称意思是让ntdsutil连接到当前这台辅域控。接着退回到fsmo maintenance菜单然后逐个输入转移角色对应命令。角色英文命令如下transfer schema mastertransfer naming mastertransfer rid mastertransfer pdctransfer infrastructure master如果主域控彻底离线系统会询问“是否尝试连接到主域控并转移”这时不要选择连接否则命令会卡住。你应该使用“夺取”命令语法是把transfer换成seize例如seize pdc。seize会强制夺取角色忽略主域控的响应状态。全部执行完成后再用netdom query fsmo确认角色已经转移。这里有一个很重要的坑角色虽然夺取到辅域控了但原来的主域控硬盘如果还保留着并且有一天它又能开机联网了就会出现“AD脑裂”。两台机器都认为自己持有很多角色复制冲突随之而来。正确处理是原来这台主域控在故障后不要再直接加回生产环境。如果必须恢复数据也要离线方式通过元数据清理Metadata Cleanup将它的残留信息从AD中删除再重装系统重新加域。4.3 我踩过的一些坑与建议最后分享几个我实际操作中踩过的坑希望你能绕开。第一个坑辅域控的系统版本比主域控低。曾有环境主域控是Windows Server 2019辅域控却拿了一台Windows Server 2012 R2来充数。虽然2012 R2能加入2019的域但后续很多新功能、新策略无法生效而且域功能级别无法提升到2016以上。这相当于把整条路的上限拉低了。所以建议至少用和主域控相同版本的系统。第二个坑DNS服务器指向了自身。很多教程说“DNS指向自己”但这句话只适用在安装AD集成DNS的域控上。辅域控安装初期的DNS必须指向主域控。你想想辅域控这时候还没有AD数据库和DNS区域如果DNS指向自己它去哪问“域控在哪”根本找不到家。第三个坑虚拟机快照引发USN回滚。这个学问很大简单说就是域控在虚拟机上跑如果运维人员对域控虚拟机做了快照一段时间后又回滚到快照点会将USN回滚到过去复制伙伴会检测到时间倒退并拒绝继续复制导致AD复制彻底中断。这件事一旦发生恢复的成本很高。所以域控虚拟机绝对不建议做快照回滚备份要走正常系统状态备份。第四个坑防火墙和安全软件的干扰。域控上最好不要装乱七八糟的安全软件和“优化工具”。一些国内杀软或安全卫士会把域控的关键服务当垃圾清理掉轻则复制异常重则AD数据库损坏。域控就是一台专职服务器越“干净”越安全。我见过因为安全软件拦截了SAMR接口导致域控无法正常响应管理员账号枚举的案例排查了好几天。第五个坑补丁没打齐导致的复制异常。Windows Server 2016早期版本有一个已知问题如果域控补丁差异过大RPC加密算法可能不兼容造成复制失败。所以加辅域控之前把补丁更新到位这不是可选项而是必选项。5. 最后一件事养成“复制优先”的运维习惯如果你问我加辅域控这个项目里最值得沉淀的经验是什么我会说不是在向导里点“下一步”那十分钟而是你是否有能力持续保证两台域控之间的复制链路健康。辅域控部署完成后五分钟的验证就能结束操作但真正的运维才刚开始。建议每位运维都给自己定一个规矩任何对AD域结构的调整打补丁、修改组策略、新增子网、迁移角色前后都要看一眼复制状态。你可以在计划任务里加一行简单的repadmin /replsummary每天记录下来。这个动作看起来不起眼但能帮你逃过很多隐蔽的大坑。还有一个细节可以分享辅域控上线后的第一个月留意主域控的安全日志响应时间。有些环境里辅域控加进来后所有终端的DNS和身份验证请求会逐步分流主域控的负载会降下来。但如果你发现主域控的CPU或内存反而升高很可能是网络拓扑出了问题导致部分客户端开始频繁向域控请求服务。这时候需要检查站点的子网关联配置以及在“Active Directory站点和服务”里确认两台域控是否都被正确归入站点。说回辅域控本身它不是一个锦上添花的组件而是AD域环境高可用的底线。加一台辅域控也花不了多少时间但它带来的冗余价值只有等你某一天遇到主域控彻底崩溃时才能真正体会到。到那时候你手上有辅域控和一套清晰的角色接管流程就能胸有成竹地处理而不是全公司叫苦连天时手忙脚乱翻文档。希望这篇文章能帮你少走一些弯路。如果你正在准备给现有域环境扩容把上面的检查清单过一遍然后放心地拿起那台新服务器开始操作吧。