企业官网建设流程全解析

很多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 53（DNS）、88（Kerberos）、135（RPC）、389（LDAP）、445（SMB）等端口畅通。如果是跨站点部署，还要考虑站点拓扑和子网规划。

第四，磁盘和备份。辅域控上会存放AD数据库（NTDS.dit）、日志文件、SYSVOL，建议C盘空间预留80GB以上，并且提前配置好系统状态备份计划。这是很多人忽略的环节，等真出了问题才发现没备份。

下面是一份我在实际项目中使用的“加辅域控前检查表”，你可以直接拿去用：

提示：如果环境中已经存在多台域控，需要先检查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 常见报错和排查对照表

我把实际工程项目里遇到的“加辅域控”相关故障整理成了一张速查表：

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 master
• transfer naming master
• transfer rid master
• transfer pdc
• transfer 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域环境高可用的底线。加一台辅域控也花不了多少时间，但它带来的冗余价值，只有等你某一天遇到主域控彻底崩溃时才能真正体会到。到那时候，你手上有辅域控和一套清晰的角色接管流程，就能胸有成竹地处理，而不是全公司叫苦连天时手忙脚乱翻文档。

希望这篇文章能帮你少走一些弯路。如果你正在准备给现有域环境扩容，把上面的检查清单过一遍，然后放心地拿起那台新服务器开始操作吧。