企业官网建设流程全解析

简介：针对 Windows Server 2022 环境下 AD 域控的高可用部署，这份 PDF 文档详细拆解了主域控与备域控的搭建流程及同步机制。内容面向负责企业网络管理和维护的 IT 技术人员，尤其适合需要独立完成域控部署、熟悉域环境运行原理的运维工程师。文档从 Hyper-V 创建虚拟机开始，依次讲解主机名修改、静态 IP 与 DNS 指向、AD 域服务角色安装、服务器提升为域控制器，并深入说明全局编录、DSRM 密码、NetBIOS 名称等核心概念的作用；备域控部分则覆盖角色添加、配置加入现有域，以及主备之间的数据复制与故障切换测试，帮助读者在实验环境中验证业务连续性。资源为单份 PDF 文件，压缩包共 1 个文件，大小 15.25MB，以图文步骤为主，便于边看边做。已有 893 人学习，适合具备一定 Windows Server 基础、希望系统掌握域控高可用方案的技术人员。

1. 主备域控不是装完角色就完事：先搞懂三件事再动手

某公司内部要搭一套高可用域环境，拿到 Windows Server 2022，用 Hyper-V 开了两台虚机，以为装好 AD DS 角色、点一下“提升为域控制器”就收工。结果客户端加域时不是提示找不到域控制器，就是 DNS 解析不了域控，最后查了半天发现是前置规划出了问题。AD 域控部署的坑通常不在“安装”这一步，而在主机名、静态 IP、DNS 自指、功能级别、备域控同步这几个环节里。任何一个错位，都会让后面的验证变成玄学。这篇文章按我自己的部署顺序，把主域控和备域控从零到同步验证完整拆开讲，包括参数怎么设、命令输出怎么看、出问题先查哪里。适合正在做企业内网域控高可用改造的工程师照着操作。

2. 主域控的“地基”：主机名、静态IP与DNS自指

2.1 主机名重命名：sysdm.cpl 里的两个决定项

很多人做域控时，第一反应是直接打开“添加角色和功能”，但 AD DS 部署失败一半以上是前置没做好。我习惯按下面顺序来，第一步永远是重命名计算机。

Win+R 输入sysdm.cpl，打开系统属性，点“更改”，把计算机名改成规划好的主机名。这里有两个决定项：

• 主机名不要超过 15 个字符，因为 NetBIOS 名称长度有硬限制；
• 不要用中文、下划线或特殊符号，避免旧协议解析时翻车。

我一般把主域控命名为 DC01，备域控命名为 DC02，直观好认。确定后系统会提示重启，别想着“不重启也能继续”，AD 角色安装对主机名是强依赖，重启必须做。

注意一个细节：如果你用的是 Hyper-V 虚拟机，重命名之前先给虚拟机拍个快照。命名错了可以随时退回去，比装完角色再改主机名轻松得多。

2.2 静态IP与DNS指向：为什么两种方式最后都会变成127.0.0.1

重命名完成后，配置静态 IP。Win+R 输入ncpa.cpl，打开网络连接，找到对应的 Hyper-V 虚拟网卡，右键属性，双击“Internet 协议版本 4 (TCP/IPv4)”，把 IP 设为规划好的内网地址。

以我自己的环境为例，主域控 IP 设为192.168.10.230/24，网关填公司路由器地址。DNS 的配置有两种常见填法：

• 首选 DNS 填127.0.0.1；
• 首选 DNS 填自己的 IP 地址，也就是192.168.10.230。

这两种方式在刚开始都一样，网页是打不开的，因为当前系统里还没有 DNS 服务。很多兄弟在这会怀疑自己配错了，其实没有。等 AD 域服务角色安装完成并提升为域控后，系统会自动把 DNS 服务器绑定到127.0.0.1这个回环地址，这是一个正常行为，不用慌。

那么，为什么域控必须依赖 DNS？因为域控在域内是靠 DNS 的 SRV 记录来定位的。客户端加域时，会去查询_ldap._tcp.dc._msdcs.你的域名这类记录，才能找到当前可用的域控。域控本身也会把自己的服务记录动态注册到 DNS 里。没有 DNS，域就等于没有通讯录，谁也不知道该找谁完成身份验证和资源访问。

另外还要明白一点，AD 域控服务器本身就是 DNS 服务器。主域控扮演两种角色很正常。所以我在配置静态 IP 时，首选 DNS 一定指向域控自身，而不是公司现有的普通 DNS。原因很简单：如果指向了其他 DNS，加域的计算机就查不到域控的 SRV 记录，自然无法入域。

2.3 补丁更新和虚拟快照：给安装上一道后悔药

接下来更新系统补丁。这一步经常被大家省略，但我不建议跳过去。AD DS 角色安装完成后，如果系统存在已知问题，可能会导致域控服务无法启动，或者组策略处理异常。

我通常在“设置 -> Windows 更新”里手动检查更新，把所有重要更新装完，重启，再做下一步。这一步不要嫌慢，Windows Server 2022 刚装完时补丁量不少，但耐心等它更新完，比后面域控出现莫名其妙问题再排查要省时得多。

在 Hyper-V 里，这一步是最佳的快照时机。AD 角色安装本质上会改变系统状态，装坏了想卸载、回滚是非常痛苦的。我会在补丁装完、系统干净的这个时间点，把虚拟机状态设为“关闭”，然后创建一个标准检查点。如果条件允许，直接复制一份 VHDX 文件做冷备份也行。

这样后面就算把域控配置搞得一团乱麻，也能恢复到干净状态重来。这个习惯救过我很多次，尤其是当你同时调了好几个配置项、已经分不清哪一个破坏了服务时，直接回滚到快照是最快的后悔药。

到这里，主域控的“地基”已经打好。接下来才是安装 AD DS 角色和正式提升为域控。

3. 安装AD域服务并把服务器提升为域控

3.1 添加AD DS角色：勾选组策略管理

打开服务器管理器，在“管理”菜单点“添加角色和功能”，安装类型保持默认的“基于角色或基于功能的安装”，下一步，选中当前这台服务器。

在角色列表里勾选“Active Directory 域服务”，系统会立刻弹出“添加 Active Directory 域服务所需的功能”窗口，里面包括 AD DS 和 AD LDS 工具、Active Directory 模块，以及组策略管理工具。直接点“添加功能”即可。

这里有个关键点：角色列表里我没有手动勾选“DNS服务器”，但系统会提示“AD DS 要求将 DNS 服务器安装在网络上”，并且在后续提升过程中自动把 DNS 角色装到这台域控上。所以不用提前单独装 DNS，照着默认流程走就行。

装完 AD 角色和功能后，系统提示“安装成功”，我建议手动把服务器重启一次。这样做能确保 AD 角色状态完全刷新，避免配置域控时出现“角色未就绪”的诡异提示。重启后重新打开服务器管理器，点右上角的小旗子图标，这时候才能看到“将此服务器提升为域控制器”的连接。

这里要提醒一句：只安装了 AD DS 角色，不等于这台服务器就已经是域控。必须完成“提升”这个动作，把服务器初始化为域控制器，AD 域服务才会真正运行起来。

3.2 提升为域控：新林、根域名和功能级别的选择

点击小旗子里的“将此服务器提升为域控制器”，进入部署配置。

在“部署操作”里，因为这台是公司第一台域控，所以选“添加新林”。根域名按你的规划填，我习惯用内部域名，比如demo.local。这里建议区分两种命名：

• xxx.com这类公网域名：适合生产环境，如果这个域名在公网上已经被注册使用，内部 DNS 和外部 DNS 解析容易出现割裂，运维时还要小心域名归属问题；
• xxx.local这类内部域名：适合纯内网环境，不会和公网域名冲突，也无需向公网 DNS 注册，绝大多数中小企业用这种最省心。

我在实验环境里常用demo.local，生产环境则推荐用公司已有公网域名的子域，比如corp.demo.com，这样以后如果要做联合认证或租户同步，内外域名可以统一规划。

再看“功能级别”。这里最高能选的是“Windows Server 2016”，很多新手会困惑：我装的可是 2022，为什么没有 2022 选项？注意，功能级别不是系统版本，它代表的是 AD 架构能够兼容的最低域控版本。Windows Server 2022 的域控完全可以在 Windows Server 2016 功能级别下运行，普通加域、组策略、DNS 解析都不受影响，最多只是少数新特性不可用。新林默认选 2016 即可，没必要纠结。

接下来“DNS 选项”里，DNS 服务器是默认勾选的，全局编录也是默认勾选。这时有可能会出现一条黄色警告：“无法创建该 DNS 服务器委派”。这是新林根域没有父级 DNS 区域的正常提示，直接跳过，不会影响域内正常使用。

3.3 DSRM密码和NetBIOS名称：关键时刻的钥匙和门牌

在配置过程中，有两个选项很容易被随手带过，但真到出问题那天，你会发现它们比想象中重要得多。

第一个是“目录服务还原模式(DSRM)密码”。这个密码不是普通管理员密码，它是将来域控遇到严重故障、无法正常启动时，用来进入目录服务还原模式的凭据。在 DSRM 模式下，你可以做数据库修复、系统状态还原，甚至重置域管理员密码。

我习惯把 DSRM 密码单独记录到密码本里，并且和域管理员密码区分开，因为它的使用场景很特殊。如果不小心忘了这个密码，虽然可以用ntdsutil重置，但前提是你还有域管理员权限，如果整个域都瘫痪了，处理起来会相当被动。

第二个是 NetBIOS 域名。系统默认会把根域名中“.”之前的部分作为 NetBIOS 名称，比如demo.local的 NetBIOS 名就是demo。NetBIOS 是局域网内计算机通信的传统协议，负责名称解析、文件共享、打印机共享等。客户端加域时，直接输入 NetBIOS 名也能定位域控。

如果在同一个网络里，已经存在同名的计算机组或设备，就需要改成不冲突的名称。否则客户端加域时，可能被解析到错误的设备，报出莫名奇妙的网络错误。这个名称的检查，其实比大多数功能级别的选择都更影响实际使用。

确认完所有配置后，系统会列出安装选项，直接点“安装”。整个提升过程会持续几分钟，完成后自动重启。重启后，主域控就正式上线了。

4. 避坑：主域控搭建中最常见的五个翻车点

4.1 加域时报“找不到网络路径”

现象：客户端在加域对话框里填好域名和账号后，弹窗提示“找不到网络路径”，或者“域控制器不存在”。

原因：最常见的是客户端 DNS 没有指向域控 IP。大家在公司里习惯了自动获取 DNS，路由器给的是一个普通 DNS，根本查不到企业内网的 SRV 记录。客户端连域控都找不到，自然走不到身份验证那一步。

解决：手动把客户端的首选 DNS 改成主域控的 IP，比如192.168.10.230，然后在客户端执行nslookup -type=SRV _ldap._tcp.dc._msdcs.demo.local，能看到域控主机名和 IP 返回，再重新加域。如果查不到记录，回域控上检查 DNS 管理器中域区域是否允许安全动态更新。

4.2 配了DNS但还是打不开网页

现象：给域控配置静态 IP 时，首选 DNS 填了自己的 IP 或者127.0.0.1，然后打开浏览器访问公网网站，全部超时。

原因：此时 DNS 服务还没有安装。你只是把流量指向了一台没有监听 53 端口的主机，它根本不知道如何递归解析；域控自己也没有完成提升，自然不会有任何 DNS 区域。

解决：不用急着改回公网 DNS。按正常顺序完成 AD DS 角色安装和域控提升，DNS 服务会自动装上，区域会自动生成，之后域控就能正常解析内外部域名了。这个现象在安装过程中出现是正常的，别因此打断节奏。

4.3 提升时报“无法创建该DNS服务器委派”

现象：在提升域控的 DNS 选项页，出现黄条提示“无法创建该 DNS 服务器委派”，有些兄弟当场就有点慌，担心 DNS 装不上。

原因：当前环境没有父级 DNS 区域，新建的根域也没有上游区域来接受委派记录。对于新林第一台域控，这个提示几乎是必然出现的，属于“看起来是错误，实际不是错误”的情况。

解决：直接忽略，点击下一步继续。域控安装完成后，DNS 区域会正常创建，本域内的解析不受影响。唯一需要注意的是，如果你将来要在这个域下再建子域或做 DNS 委派，才需要回过来规划父区域。

4.4 DNS被改成127.0.0.1后，客户端依然解析不了域控

现象：域控安装完成后，DNS 设置自动变成了127.0.0.1，在域控本机解析域内主机名、查 SRV 记录都正常，但其他客户端把 DNS 指向域控后，却查询不到任何记录。

原因：客户端到域控的 53 端口网络不通，或者域控的 Windows 防火墙阻止了来自其他网段的 DNS 请求。另一种可能是 DNS 区域没有开启“安全动态更新”，导致域控自己的 SRV 记录没有注册进去。

解决：先在客户端执行Test-NetConnection 192.168.10.230 -Port 53，确认 TCP/UDP 53 端口通不通。如果不同，在域控防火墙里放行“域名服务(DNS)”入站规则。如果端口通但还是查不到记录，打开 DNS 管理器，检查正向查找区域demo.local的属性，把动态更新改为“仅安全”。然后重启 Netlogon 服务，或者直接重启域控，让服务记录重新注册。

4.5 忘记DSRM密码，紧急修复时进不了目录服务还原模式

现象：域控因为异常断电或数据库损坏，重启时需要进入目录服务还原模式来修复 AD 数据库，结果发现 DSRM 密码怎么输都是错误。

原因：安装域控时设置完 DSRM 密码，再也没用过。几个月后故障来了，密码本里没记，或者根本就没认真设置，脑补了一个自己以为的密码。

解决：如果域内还有一台正常的域控或还有域管理员权限，可以使用ntdsutil在普通模式下重置域控本机的 DSRM 密码：

ntdsutil set dsrm password reset password on server DC01.demo.local quit quit

如果整个域已经只剩这一台域控且系统无法正常启动，那只能从系统备份或虚拟机快照恢复，这也是我前面强调必须先打快照的原因。从那以后，我每装完一台域控，都会把 DSRM 密码明确存档，并在交接文档里单独标注。

5. 备域控搭建：从零到接管，同步验证

5.1 备域控的角色：为什么至少要两台

主域控再稳，也架不住断电、硬件故障或系统崩溃。AD DS 部署的最佳实践是至少要两台域控，目的就是确保在其中一台域控中断的情况下，用户仍然可以通过另一台完成身份验证和登录。

备域控不是简单在另一台机器上装一个 AD DS 角色，而是要让它成为同域中的第二台域控制器，并同步整个 AD 数据库。这台备域控需要包含域内所有用户、计算机、组、GPO 等对象，并且承担域名解析和身份验证的工作。

在默认配置下，备域控也会被设置为全局编录（GC）。全局编录里存储了域中所有对象的查询信息，用户登录时，需要 GC 来提供通用组成员身份，如果没有 GC，普通域用户可能会在登录时遇到“服务器不愿意处理请求”这类错误。所以，备域控建好后，一定要确认 GC 已经在运行。

5.2 备域控部署步骤：加域而不是建新林

备域控的部署流程和主域控有些区别，关键动作是“加入现有域”，而不是“添加新林”。

在另一台 Windows Server 2022 虚拟机上，先执行和主域控一样的准备工作：

1. 用sysdm.cpl修改主机名，比如 DC02；
2. 配置静态 IP，DNS 指向主域控 IP192.168.10.230；
3. 安装补丁并创建快照；
4. 把 DC02 加入demo.local域。操作路径是“系统属性 -> 更改 -> 隶属于域”，输入demo.local和管理员凭据，重启生效。

接下来打开服务器管理器，同样安装 Active Directory 域服务角色。安装完成后，点击通知小旗子里的“将此服务器提升为域控制器”。

关键一步来了：部署操作选择“将域控制器添加到现有域”，域信息里输入demo.local，并输入有权限添加域控的域管理员账号。之后的功能级别、DNS 选项、DSRM 密码配置和主域控一致。系统会从主域控复制 AD 数据，这个过程需要等待一段时间，取决于目录数据库的大小。

不要图省事直接在备域控上再创建一个新林，那样只会得到两个毫不相干的独立域，客户端加域进哪个都不对，完全达不到高可用目的。

5.3 验证主备同步：dcdiag、repadmin和nltest

备域控部署完成后，不能只看角色状态就收工，必须验证主备之间的复制是否正常。

在备域控上，用管理员身份打开 PowerShell 或 CMD，执行以下命令：

dcdiag /q

/q表示只显示错误信息。如果返回结果为空，说明 AD 基本状态正常；如果有错误，会给出对应测试名称，例如Replications、Services、DNS。再执行：

repadmin /showrepl

这条命令会列出当前域控的复制伙伴以及每个分区上一次复制是否成功。看到Successful字样，说明复制正常。

我还会用repadmin /syncall /AdeP强制触发一次全量同步，虽然日常不需要，但初次搭建后做一次，能确保所有新增对象都落到备域控上：

repadmin /syncall /AdeP

最后用nltest确认客户端能否发现域控：

nltest /dsgetdc:demo.local

这条命令返回域控的可用地址，如果同时能列出 DC01 和 DC02，说明 DNS 中已经注册了两台域控的 SRV 记录，客户端会按照自己的优先级选择可用的域控进行验证。

5.4 主域控宕机演练：模拟故障看用户能否登录

验证主备同步不是终点，真正的目标是“主域控没了，用户还能登录”。我每次做完备域控，都会强制自己走一遍宕机演练。

先把主域控 DC01 虚拟机正常关机或者直接断开网络，然后在一台已经加域的客户端上，用域账号重新锁定并登录。如果客户端 DNS 只配置了 DC01 的 IP，这一步就会失败。正确做法是客户端的 DNS 至少配上主备两个地址：首选192.168.10.230，备用192.168.10.231。这样即使 DC01 下线，客户端也会自动向 DC02 发起 DNS 查询和身份验证。

演练时会发现，域账号登录成功，但共享文件夹、组策略等依赖于特定域控服务的功能可能会有一段时间的延迟。这是正常的，因为服务记录需要重新选择可用域控。深呼吸等半分钟到一分钟，再打开组策略结果工具，就能看到策略从 DC02 下发。

在演练结束后，把 DC01 重新开机，等它和 DC02 完成差值复制，再执行一次repadmin /showrepl确认两边数据一致。这样整个高可用环才算闭环。

6. 一个小技巧：用PowerShell脚本批量检查域控健康状态

两台域控都上线后，日常巡检如果还靠一台一台登录服务器，点鼠标看事件日志，效率太低。我把常用检查命令封装成一个简单的 PowerShell 脚本，每次巡检跑一遍，结果按域控分开输出。

$DCs = Get-ADDomainController -Filter * foreach ($dc in $DCs) { Write-Host "===== $($dc.Name) =====" -ForegroundColor Cyan dcdiag /s:$($dc.Name) /q repadmin /showrepl $dc.Name | Select-String -Pattern "failed|error|success" $svc = Get-Service -ComputerName $dc.Name -Name NTDS,Kdc,DNS $svc | Format-Table MachineName, Name, Status -AutoSize }

脚本的逻辑很简单：先通过Get-ADDomainController -Filter *自动发现域内所有域控，然后对每台执行三个动作——跑一次精简版dcdiag，检查是否有真实错误；用repadmin查看复制状态，把包含 failed 或 error 的行筛出来；最后检查 NTDS（目录服务）、KDC（身份验证）、DNS 三个关键服务的运行状态。

用脚本有个好处，巡检结果里没有输出才是最好的情况。一旦看到红色错误行，再单独针对那台域控深挖，不用每台都从头看。我习惯把脚本存成一个DCHealthCheck.ps1，放在一台装有 RSAT 工具的跳板机上，配合计划任务每周自动跑一次，输出结果写到文件里，方便追溯。

最后分享我的一个习惯：每次部署完域控环境，不管当时有多忙，我都强制自己把dcdiag和repadmin的完整输出跑一遍，并且把主备切换演练做一次，再确认结果正常。这套动作救过我不少次，尤其是备域控同步异常时，能第一时间发现并修复，而不是等真出故障时才发现“备域控根本接管不了”。希望这份主备域控搭建笔记也能帮你少踩几个坑，顺利把企业内网的域控高可用落到位。

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