企业如何搭建 AD 域？Windows Server 2022 从域控到加域的部署攻略

搭建企业 AD 域，要按“准备域名与固定地址 → 建第一台域控及 DNS → 验证解析 → 加第二台域控 → 建测试账户并加域 → 核验策略、备份和告警”的顺序做。第一台域控安装结束只是起点；两台域控复制正常、终端能使用普通域账户登录且策略生效，才具备继续上线的基础。

AD DS（Active Directory Domain Services，Active Directory 域服务）集中保存用户、计算机和组；域控制器（DC）负责目录与身份服务；DNS 让终端找到域控。本攻略建立一个全新的本地域环境。已有域升级、跨域迁移、Microsoft Entra ID 和证书服务需另行规划。以下命令依据微软官方资料整理，是操作示例，本轮未在 Windows 服务器环境执行。

开始前：把这张部署表填好

准备两台已安装更新的 Microsoft Windows Server 2022 Standard 或 Datacenter，使用桌面体验安装；另准备一台 Windows 11 Pro 或 Enterprise 测试终端、服务器控制台入口、固定 IP 和可写的独立备份存储。Home 版不能按本文方式加入本地 AD 域。服务器许可及客户端访问许可按企业实际授权核实。

不要用单标签名称 CORP 代替完整 DNS 域名。Windows Server 2022 的新林和域功能级别最高是 Windows Server 2016，不能因为操作系统是 2022 就寻找“2022 功能级别”。参见微软功能级别矩阵。

第一步：命名服务器，设置固定 IP 和第一阶段 DNS

在 DC1 控制台打开“服务器管理器 → 本地服务器”，将计算机名设为 DC1 并重启。打开网卡 IPv4 属性，填入 10.20.10.10、掩码 255.255.255.0、实际网关；DNS 首选填 DC1 自身 10.20.10.10，暂不填写备用 DNS。首台域控的 DNS 角色尚未安装时，自身地址不能解析是阶段状态，先完成角色安装，再检查解析。

DC2 同样设名并重启，固定地址为 10.20.10.11；提升前只指向 DC1 的 DNS 10.20.10.10。两台机器均在管理员 PowerShell 中检查实际网卡与地址，不凭界面填写记录判断成功：

Get-NetAdapter | Select-Object Name, Status, InterfaceDescription
Get-NetIPConfiguration
Get-DnsClientServerAddress -AddressFamily IPv4
Get-CimInstance Win32_ComputerSystem | Select-Object Name, Domain, PartOfDomain

预期：名称与部署表一致，业务网卡处于 Up，固定地址、网关和 DNS 正确，没有另一块网卡把错误地址注册到 DNS。多网卡、VPN 或虚拟交换机的管理地址必须单独确认。不要为追求连通把域控网卡 DNS 填成公网 DNS；外网查询由 DNS 服务器转发。配置原则见微软域控 DNS 客户端建议。

如果跨 VLAN 部署，先按微软 AD 防火墙说明批准对应方向和端口。DNS 53/TCP 与 UDP、Kerberos 88/TCP 与 UDP、LDAP 389/TCP 与 UDP、SMB 445/TCP、RPC 135/TCP 及默认动态 RPC 49152–65535/TCP 都可能参与，时间同步另需 NTP 123/UDP；具体规则按成员到域控、域控到域控分别设计。单次 ping 成功不足以验收，不要关闭防火墙代替放行。

第二步：安装 AD DS 角色，确认“已安装”与“已提升”是两个阶段

DC1 打开“服务器管理器 → 管理 → 添加角色和功能”，选择基于角色或功能的安装、本机服务器、Active Directory 域服务，接受关联管理工具并安装。需要命令部署时，在本机管理员 PowerShell 中执行：

Install-WindowsFeature AD-Domain-Services -IncludeManagementTools
Get-WindowsFeature AD-Domain-Services

检查 Success、Restart Needed 与角色状态；若提示需要重启，完成后再继续。显示 Installed 只证明角色安装完成。回到服务器管理器，通知旗标中的“将此服务器提升为域控制器”才进入新林配置。官方流程见微软 AD DS 安装说明。

第三步：在 DC1 创建新林，逐页核对再安装

进入提升向导后，按下表操作。本文新建独立林，不能选择“向现有林添加新域”。

点击图片查看原图。

点击图片查看原图。

偏好命令部署时，以下是在 DC1 创建同一配置的替代路线；不要在已经完成向导提升的服务器再次执行。WinThreshold 对应 Windows Server 2016 功能级别。先测试，阅读返回结果，确认没有阻断问题后再在同一 PowerShell 会话中手动执行安装命令，保留 $forest 与 $dsrm 变量：

Import-Module ADDSDeployment
$dsrm = Read-Host 'Enter a new DSRM password' -AsSecureString
$forest = @{
    DomainName = 'ad.example.com'
    DomainNetbiosName = 'CORP'
    InstallDns = $true
    CreateDnsDelegation = $false
    ForestMode = 'WinThreshold'
    DomainMode = 'WinThreshold'
    SafeModeAdministratorPassword = $dsrm
}
Test-ADDSForestInstallation @forest

Install-ADDSForest @forest

安装会提示确认并在结束时重启。参数依据Install-ADDSForest与Test-ADDSForestInstallation；不要复制不明来源脚本中的 -SkipPreChecks 或禁止重启参数。

点击图片查看原图。

本例内部子域不依赖公网父域把查询委派到私网域控；终端直接使用内部 DNS 时，可记录相应的无法创建委派提示并继续。若企业已有父区、跨区域解析或混合 DNS 体系要求委派，则先处理相应委派/条件转发设计。密码、权限、地址或存储错误不能按这一条件处理。

重启后用 CORP\Administrator 登录，检查以下输出，而不是只看欢迎界面：

Get-ADDomain | Select-Object DNSRoot, NetBIOSName, DomainMode, PDCEmulator
Get-ADForest | Select-Object RootDomain, ForestMode
Get-Service NTDS, DNS, Netlogon, DFSR
Get-SmbShare -Name SYSVOL, NETLOGON

预期：域名及 NetBIOS 正确，功能级别为 2016，服务 Running，SYSVOL 与 NETLOGON 都存在。若共享未出现或服务启动失败，检查 Directory Service、DNS Server、DFS Replication 及 System 事件日志；保留 %windir%\debug\dcpromo.log 和 dcpromoui.log，暂停加域和批量建账号。

第四步：检查 AD 集成 DNS，配置外部解析

打开“服务器管理器 → 工具 → DNS”。在“正向查找区域”确认内部域区域及 _msdcs 森林定位记录；检查区域是 AD 集成区、动态更新使用“仅安全”。森林级 _msdcs 可能显示为独立区域，不要凭树形位置判断缺失。

DC1 管理员 PowerShell 检查本例区域及 SRV 服务记录：

Get-DnsServerZone | Select-Object ZoneName, ZoneType, IsDsIntegrated, DynamicUpdate
Resolve-DnsName '_ldap._tcp.dc._msdcs.ad.example.com' -Type SRV -Server 10.20.10.10
Resolve-DnsName 'dc1.ad.example.com' -Type A -Server 10.20.10.10

预期：内部域为 AD 集成区且仅安全更新，SRV 返回 DC1 的全名及 LDAP 服务端口，A 记录对应 10.20.10.10。没有 SRV、主机指向旧 IP 或解析来自公网 DNS，都先停止后续步骤。详细诊断接加域前 DNS 检查攻略。

外网解析在 DNS 管理器中右键 DC1 → 属性 → 转发器 → 编辑，填写企业批准且从域控可达的递归 DNS 地址；DC2 安装后也单独检查转发器。服务器级转发器不能默认视为随 AD 区域自动复制。参考微软 DNS 服务器配置。

Get-DnsServerForwarder
Resolve-DnsName 'www.microsoft.com' -Server 10.20.10.10

第二条应得到符合企业网络策略的解析响应。受出口限制的环境需按企业允许的外部域名验收；失败时检查转发器、DNS 出口和递归策略，不把公网 DNS 添加到终端作为“备用”。反向区可按运维规范补建；它有助于诊断，不代替上述 SRV、A 与加域检查。

第五步：部署 DC2，先验复制再配置双 DNS

确认 DC1 健康后，在 DC2 完成第二步的角色安装。提升向导这次选“向现有域添加域控制器”，域名填 ad.example.com，提供获准的域管理员凭据，保留 DNS 与全局编录，设置独立保管的 DSRM 密码。站点按本例单站点填写默认站点；多站点环境应先定义子网与站点，不能照搬默认站点。

点击图片查看原图。

本机管理员 PowerShell 的替代操作示例；不要与已完成的向导重复执行：

$cred = Get-Credential 'CORP\Administrator'
$dsrm = Read-Host 'Enter DC2 DSRM password' -AsSecureString
Install-ADDSDomainController -DomainName 'ad.example.com' -InstallDns -Credential $cred -SafeModeAdministratorPassword $dsrm

根据微软第二台域控安装命令检查先决条件、确认并重启。DC2 提升前仍只使用 DC1 DNS；在双向复制确认正常之前，不自行切换为只查自身 DNS。

在管理员终端检查复制，分别检查两台 DNS 是否能返回域定位与对方地址：复制状态字段按微软复制排障说明与Repadmin 汇总参考核验。

repadmin /replsummary
repadmin /showrepl DC1
repadmin /showrepl DC2
Resolve-DnsName '_ldap._tcp.dc._msdcs.ad.example.com' -Type SRV -Server 10.20.10.10
Resolve-DnsName '_ldap._tcp.dc._msdcs.ad.example.com' -Type SRV -Server 10.20.10.11
Resolve-DnsName 'dc1.ad.example.com' -Type A -Server 10.20.10.10
Resolve-DnsName 'dc2.ad.example.com' -Type A -Server 10.20.10.10
Resolve-DnsName 'dc1.ad.example.com' -Type A -Server 10.20.10.11
Resolve-DnsName 'dc2.ad.example.com' -Type A -Server 10.20.10.11

还要在 DC2 本机管理员 PowerShell 检查角色服务与共享：

Get-Service NTDS, DNS, Netlogon, DFSR
Get-SmbShare -Name SYSVOL, NETLOGON

预期：两台可写域控均参与，复制失败数为 0，各命名上下文的最近复制成功且符合预定复制周期；两台 DNS 都能定位域控，且查询两台 A 记录分别返回 .10 和 .11；DC2 的服务 Running，SYSVOL/NETLOGON 共享存在。新提升需要初始复制时间，短时等待应有日志依据；不能无限等待仍报告通过。

确认后，本例设置 DC1 首选 DNS 为 DC2 .11、备用为自身 .10；DC2 首选为 DC1 .10、备用为自身 .11。测试终端和 DHCP 选项仅下发这两台内部 DNS。再次检查实际网卡 DNS、两台 A/SRV 记录与复制；“交叉首选”是本文单站点示例，其他拓扑按企业设计调整。

第六步：建立试点 OU、普通用户和测试策略

OU（组织单位）用于组织对象和绑定组策略；先建试点，避免把实验策略链接到整个域。DC1 打开“工具 → Active Directory 用户和计算机”，右键域 → 新建 → 组织单位，分别建 Pilot-Users 和 Pilot-Computers，保留防止意外删除保护。

在 Pilot-Users 下新建普通用户 pilot.user，使用企业密码规则下的初始密码，勾选下次登录更改密码；不要加入 Domain Admins。检查用户已启用且登录名为 pilot.user@ad.example.com。

打开“工具 → 组策略管理”，在 Pilot-Computers 上新建并链接 Pilot-Logon-Banner；编辑“计算机配置 → 策略 → Windows 设置 → 安全设置 → 本地策略 → 安全选项”，设置“交互式登录：试图登录的用户的消息标题/消息文本”。这是一项用于验证策略通路的试点设置，不是完整安全基线。保持试点计算机拥有读取和应用策略权限，不把链接误放到 Domain Controllers OU。

第七步：让一台测试终端加入域，再验证真实域登录

测试 PC 使用 Windows 11 Pro/Enterprise，检查名称无冲突，当前在工作组、本地管理员可用。网卡 DNS 只使用 .10 与 .11，域名与地址按第一张表替换。先在终端 PowerShell 查询：

Resolve-DnsName '_ldap._tcp.dc._msdcs.ad.example.com' -Type SRV
nltest /dsgetdc:ad.example.com

应找到本次部署的域控；若 SRV 查询成功但 nltest 失败，继续检查服务、端口和时间，不认定 DNS 已覆盖所有问题。

打开“设置 → 账户 → 访问工作或学校 → 连接 → 将此设备加入本地 Active Directory 域”，输入域名和具有加域权限的凭据。向导提示成功后重启。也可在管理员 PowerShell 使用微软加域命令：

Add-Computer -DomainName 'ad.example.com' -Credential (Get-Credential)
Restart-Computer

仅在第一条确实成功后执行重启；不要把错误结果当成成功继续。试点可使用授权的管理员进行一次加入，批量部署应采用 OU 委派的加域账户；不要长期把域管理员凭据交给员工。

回到 AD 用户和计算机，找到刚加入的 PC-ADTEST 计算机对象，将它移动到 Pilot-Computers。重启/刷新策略后，在终端首次用 CORP\pilot.user 登录，按要求修改初始密码。首次成功联系域控的域登录，比已经存在的离线缓存登录更能说明此次流程工作。

whoami
Get-CimInstance Win32_ComputerSystem | Select-Object Name, Domain, PartOfDomain

先在普通用户会话确认 whoami 为 corp\pilot.user，Domain 为内部域、PartOfDomain 为 True。随后另开获准管理员提升权限的 PowerShell，使用本地管理员或授权管理账户核验安全通道，不授予试点用户管理员权：

Test-ComputerSecureChannel -Verbose

预期返回 True；该检查仅用于成员终端，不用它判断域控健康。提升后的管理员会话身份与普通用户登录检查分开记录。无法加域时先查 %windir%\debug\NetSetup.log；有同名历史计算机对象时核验所有者及加域加固策略，不通过关闭保护绕过问题。

第八步：检查组策略与时间同步

在测试终端管理员 PowerShell 运行下列示例；先确认目录 C:\Temp 可写：

New-Item -ItemType Directory -Path 'C:\Temp' -Force

gpupdate /force

gpresult /scope computer /h C:\Temp\gpresult-computer.html /f

报告应列出试点 GPO 为已应用；按系统提示重启并退出/再次登录，确认登录提示实际出现。若未应用，检查计算机 OU、GPO 链接和安全筛选；域级密码策略不是把策略链接到用户 OU 就会生效的设置，不能用上述登录提示代替验证密码策略。

森林根域持有 PDC Emulator（主域控制器模拟器）角色的域控应使用可信时间源，其余机器沿域层次同步。依据微软 PDC 时间配置，先查询角色，不预设一直由 DC1 持有：

Get-ADDomain | Select-Object PDCEmulator
w32tm /query /source
w32tm /query /status

仅在角色持有者上，替换下例 10.20.10.2 为企业批准且可达的 NTP 时间源，确认 UDP 123 可达后执行：

w32tm /config /manualpeerlist:"10.20.10.2,0x8" /syncfromflags:manual /reliable:yes /update
w32tm /resync /rediscover
w32tm /query /source
w32tm /query /status

应显示预期时间源和最近同步时间；失败时检查时间策略覆盖、网络与服务，不将 Local CMOS Clock 当作已接入可信 NTP。虚拟化时间提供程序另按宿主机平台核验，避免多个来源争用。默认 Kerberos 对明显时差敏感；本例运维目标为时差小于 1 分钟，这是一项建议验收目标，不是更改默认 Kerberos 策略。

在测试终端管理员命令提示符采样与两台域控的偏差，按微软 w32tm 工具说明阅读每条 offset，并记录正负号与绝对值：

w32tm /stripchart /computer:dc1.ad.example.com /samples:5 /dataonly
w32tm /stripchart /computer:dc2.ad.example.com /samples:5 /dataonly

每条采样应符合本例小于 60 秒的目标；请求超时需检查 NTP 服务和 UDP 123，不把未返回的 offset 当作零偏差。

第九步：补齐备份和可行动告警

复制提供第二份在线目录，但误删除和部分错误也会复制；至少建立 AD 感知的系统状态备份及隔离恢复流程。每台域控部署 Windows Server Backup 后，示例把系统状态写到已准备的独立目标卷 E:；先确认容量、权限和该卷不是唯一副本所在宿主机的同一故障存储：

Install-WindowsFeature Windows-Server-Backup

wbadmin start systemstatebackup -backupTarget:E:
wbadmin get versions -backupTarget:E:

上面的 wbadmin 必须在获准管理员提升权限的命令提示符中运行。参考系统状态备份命令。交付检查必须包含作业完成、版本可列举、备份对象与时间正确、独立/隔离副本以及 DSRM 密码可按权限取用。频率与保留期按企业 RPO/RTO 决定；初次交付应执行一次隔离恢复演练，不能只看备份任务变绿。可结合企业备份恢复验收制定记录。

不要把虚拟机快照回滚当作域恢复流程，参见微软虚拟域控备份边界。域控已有真实用户和业务依赖时，错误处理必须考虑目录复制、FSMO 角色及恢复方案，不能删虚拟机再“从头来过”。

将以下检查接到企业现有监控系统；本文只定义检查对象与建议阈值，不声称已安装 Zabbix 或其他监控平台：

监控应有真实负责人、通知通道与处置记录，阈值须按业务确认。能 ping 域控不代表 DNS、复制、策略或备份健康。

最后验收：这些证据齐了，才移交给运维

在有授权的管理员终端分别执行以下检查，保留完整输出和时间；DCDiag 官方说明强调 DNS 测试需显式调用：

dcdiag /s:DC1 /v
dcdiag /s:DC2 /v
dcdiag /test:DNS /s:DC1 /v
dcdiag /test:DNS /s:DC2 /v
repadmin /replsummary

单台不可用测试要逐台进行，必须保留另一台、控制台与恢复路径，不能同时停止两台。用只指向存活 DC 的测试终端 DNS、刷新解析并触发新的域定位及受控认证，记录命中的域控；已有会话或缓存登录不能证明切换成功。FSMO 角色相关操作不承诺在持有者停机时全部正常。若无法完成，报告对应范围未验证，而不是用截图上的绿色通过替代结果。

若提升失败发生在全新隔离试验林、尚无任何真实用户或应用依赖，可在保存日志并确认清理范围后重新部署；一旦投入业务，停止批量操作，按受支持的降级或恢复程序处理，不能随意回滚快照或删除域控。

FAQ

安装 AD DS 时会自动装 DNS 吗？

角色安装与域控提升分开。本文在提升阶段勾选 DNS/使用 -InstallDns，由提升流程安装配置所需 DNS。结束后仍须验证区域、记录、转发器与客户端配置。

只搭一台域控能用吗？

试验环境可以先建一台。本文企业交付目标是双域控且处在不同故障域，并补备份与恢复；两台机器不等于消除了交换机、存储和供电的共同故障。

备用 DNS 能填公网 DNS 吗？

域成员只使用能解析 AD 内部区域的 DNS。外部域名由内部 DNS 转发；公网 DNS 不知道内部 SRV 记录，会使发现过程不稳定。

第二台域控是重新添加一个新林吗？

不是。选择“向现有域添加域控制器”，使用原域名与授权凭据，并确认复制；重新新建林将得到另一套独立目录。

这篇中的微软截图能当作我的安装结果吗？

不能。它们用于识别界面和操作选项，源自官方文档，保留官方示例名称及画面。企业现场必须另存本次配置、日志、命令输出和验收记录。

相关解决方案

企业数据中心基础架构：结合服务器、虚拟化、网络与存储检查域服务承载环境。

业务连续性规划：明确域服务的可用性、恢复目标与交付责任。

相关阅读

Windows 加域前的 DNS 检查

企业备份与恢复测试

如需评估企业域服务部署，可先整理现有域名、网段、服务器与恢复目标，再与煜企讨论实施范围。