企业官网建设流程全解析

简介：本资源是一份面向企业IT运维人员与Windows Server中级实践者的高可用AD域控部署指南，聚焦Windows Server 2022环境下主域控与备域控的完整搭建、同步机制验证及核心组件原理剖析。内容覆盖主机名与静态IP配置、AD域服务角色安装、DNS与全局编录协同配置、DSRM密码设定、NetBIOS命名规范，以及备域控加入与双向同步测试等关键环节，特别强调生产环境中域名选择（.com vs .local）、功能级别适配、故障接管保障等实战要点。资源为单个15.25MB PDF文件，图文并茂，含详细操作截图与配置逻辑说明，便于实验环境逐步复现与理解底层机制。目前已有893人学习下载，适合需落地高可用域架构、深化AD+DNS集成认知、提升故障容灾设计能力的技术人员系统掌握域控部署全链路实践。

1. Windows Server 2022 AD域控不是“装完就跑”的一次性活：主备双控+DNS强耦合+同步机制失效才是生产环境翻车的真正起点

你刚在 Hyper-V 里配好一台 Windows Server 2022，改完主机名、设好静态 IP、勾选了 Active Directory 域服务、点下“安装”——系统弹出绿色对勾，你长舒一口气，以为 AD 域控已上线。但三天后主域控意外宕机，所有办公电脑加不了域、组策略不生效、打印机映射全断，IT 同事在会议室门口被业务部门堵着问“邮箱为什么登不上”。这不是玄学，是 Windows Server 2022 AD 域控部署中最常被跳过的硬性前提：AD 从不单点存在，它天生要求 DNS 作为呼吸器官，依赖全局编录支撑身份验证，靠多域控间同步维持心跳。本文讲的不是“怎么点下一步”，而是如何让主域控和备域控在真实断电、网卡故障、磁盘只读等场景下，仍能扛住用户登录、密码修改、OU 变更这三类高频操作。适合正在规划企业内网高可用架构的 Windows 系统工程师、负责 AD 迁移的运维负责人，以及被“主域控一挂全瘫”问题反复折磨的中小企 IT 兼职管理员。你不需要会写 PowerShell 脚本，但必须理解：DNS 配置错一个字、DSRM 密码输错两次、NetBIOS 名称与根域名冲突——这三个动作，足以让后续所有“高可用”设计归零。

2. 主域控搭建：从操作系统裸机到可认证域服务的六步闭环（含 DNS 强绑定逻辑）

AD 域控不是独立角色，它是 Windows Server 2022 上一个深度嵌入操作系统内核的服务集群，其启动依赖 DNS 解析、身份验证依赖全局编录、恢复依赖 DSRM 模式。跳过任一环节，表面“安装成功”，实则埋下黑匣子。以下步骤严格按生产环境最小可行路径设计，每步均标注不可省略的底层逻辑。

2.1 主机名与网络基础：为什么 sysdm.cpl 改名后必须重启？

在 Windows Server 2022 中，主机名（Computer Name）不仅是显示名称，更是 Kerberos 认证票据（Ticket）中 Service Principal Name（SPN）的构成部分。SPN 格式为HOST/hostname.domain.com，若主机名未在系统级生效，后续klist查看票据时会出现KDC_ERR_S_PRINCIPAL_UNKNOWN错误，导致域用户无法登录。

提示：使用sysdm.cpl修改后，必须执行shutdown /r /t 0强制重启。仅注销（Log off）不触发 Netlogon 服务重载，SPN 不会注册到 AD 数据库。

# 验证主机名是否已系统级生效（重启后执行） PS C:\> hostname DC-PRIMARY PS C:\> Get-ComputerInfo | Select-Object CsName, CsDomain CsName CsDomain ------ -------- DC-PRIMARY jidaoge.com

• CsName：操作系统识别的主机名（必须与 DNS A 记录一致）
• CsDomain：当前加入的域（主域控此值为空，配置完成后才填入根域名）

2.2 静态 IP 与 DNS 绑定：为什么 DNS 必须指向本机且不能是 127.0.0.1？

AD 域控既是客户端又是 DNS 服务器，其 DNS 客户端设置决定netlogon.dns文件生成逻辑。若 DNS 设置为127.0.0.1，Windows 会跳过动态注册步骤，导致_ldap._tcp.dc._msdcs.jidaoge.comSRV 记录缺失，客户端加域时无法定位域控制器。

正确做法：将 DNS 客户端地址设为本机实际 IP（如 192.168.10.10），而非回环地址。系统安装 AD DS 角色后，会自动将该 IP 注册为权威 DNS 服务器，并创建正向/反向查找区域。

# 使用 PowerShell 设置静态 IP 和 DNS（替代 ncpa.cpl 图形操作） PS C:\> New-NetIPAddress -IPAddress 192.168.10.10 -PrefixLength 24 -InterfaceAlias "Ethernet0" -AddressFamily IPv4 PS C:\> Set-DnsClientServerAddress -InterfaceAlias "Ethernet0" -ServerAddresses 192.168.10.10

• -InterfaceAlias：通过Get-NetAdapter获取真实网卡名（Hyper-V 虚拟网卡常为Ethernet0或vEthernet (Default Switch)）
• Set-DnsClientServerAddress必须在New-NetIPAddress后执行，否则 DNS 设置不生效

注意：执行后立即运行ipconfig /all，确认 IPv4 DNS 服务器地址为192.168.10.10，且无其他 DNS 条目。

2.3 补丁更新与角色安装：为什么 KB5034441 是 Windows Server 2022 AD 的“安全基线”？

Windows Server 2022 发布后，微软针对 AD 域控新增了多项安全加固补丁。其中 KB5034441（2024 年 2 月累积更新）修复了 Kerberos 预认证绕过漏洞（CVE-2024-21410），该漏洞允许攻击者在未获密码情况下获取 TGT 票据。若未安装此补丁，即使主备域控同步正常，攻击者仍可通过伪造 PAC（Privilege Attribute Certificate）提权。

安装命令（管理员权限 PowerShell）：

# 下载并静默安装 KB5034441（需提前下载 .msu 文件） PS C:\> wusa.exe C:\Temp\windows10.0-kb5034441-x64_8e5c1a7f4a7b4a7b4a7b4a7b4a7b4a7b.msu /quiet /norestart # 验证补丁是否应用 PS C:\> Get-HotFix | Where-Object {$_.HotFixID -eq "KB5034441"}

• /quiet：静默安装，无 UI 提示
• /norestart：避免中途重启中断 AD 角色安装流程
• Get-HotFix输出需包含Description: Security Update和InstalledOn日期

2.4 AD DS 角色安装：为什么“添加功能”里必须勾选“AD DS 工具”和“组策略管理”？

Active Directory Domain Services角色本身仅提供核心 LDAP 服务，但生产环境必需的管理能力由附加功能提供：

• AD DS Tools：包含dcdiag.exe（域控诊断）、repadmin.exe（复制监控）、ldp.exe（LDAP 协议调试）——没有它们，你无法验证同步状态
• Group Policy Management：提供gpmc.msc控制台，用于创建/链接 GPO。若未安装，gpupdate /force将报错The processing of Group Policy failed. Windows cannot find the policy definitions.

安装路径（服务器管理器 → 添加角色和功能 → 功能 → 勾选两项）：

2.5 域控制器配置：为什么“添加新林”时 DNS 服务器自动勾选却仍要手动验证？

安装 AD DS 角色后，系统会在“部署后配置”中提示提升为域控制器。选择“添加新林”时，界面自动勾选“DNS 服务器”，但这仅表示安装 DNS Server 角色，不保证 DNS 服务已正确配置为 AD 集成区域。

必须手动验证三项：

1. 正向查找区域是否存在：打开dnsmgmt.msc→ 展开“正向查找区域” → 确认存在jidaoge.com（与根域名一致）
2. 区域类型是否为“AD 集成”：右键jidaoge.com→ 属性 → “常规”选项卡 → “类型”显示Active Directory-integrated
3. SOA 记录是否指向本机：右键jidaoge.com→ “属性” → “起始授权机构(SOA)” → “主服务器”字段为dc-primary.jidaoge.com

若 SOA 记录为空或指向错误主机名，dcdiag /test:dns将报错DNS test failed，后续客户端加域失败。

2.6 DSRM 密码与全局编录：为什么 DSRM 密码必须复杂且全局编录不能关闭？

• DSRM 密码：目录服务还原模式密码是域控制器的“后悔药”。当 NTDS.dit 数据库损坏、SYSVOL 复制中断时，需重启进入 DSRM 模式执行ntdsutil修复。若密码过于简单（如Password123），会被 Windows 安全策略拒绝；若为空，安装过程直接报错The Directory Services Restore Mode password is required。
• 全局编录（GC）：存储所有域对象的部分属性（如 userPrincipalName、sAMAccountName），用于跨域登录和通用组成员身份验证。若主域控未启用 GC，用户登录时会因无法解析通用组而延迟 30 秒以上，且 Exchange Online 混合部署将完全失败。

设置方式（提升域控制器向导最后一步）：

• DSRM 密码：必须满足复杂度要求（大写+小写+数字+符号，长度≥7）
• 全局编录：勾选“全局编录”复选框（默认已勾选，切勿取消）

血泪经验：某客户曾为“节省内存”取消 GC，结果财务部使用 Outlook 连接 Exchange Online 时频繁提示“无法验证用户身份”，排查 3 天才发现是 GC 缺失导致 UPN 解析失败。

3. 备域控部署：不是主域控的克隆，而是独立身份+同步链路+故障接管能力的重建

备域控（Secondary Domain Controller）不是主域控的镜像备份，而是拥有独立 RID 主机（RID Master）、PDC 模拟器（PDC Emulator）副本、且能自主响应 LDAP 查询的对等节点。其部署核心在于：身份独立性验证、同步状态监控、故障切换预演。跳过任一环节，“备域控”只是个摆设。

3.1 主机名与网络隔离：为什么备域控必须用不同主机名且不能与主域控同名？

AD 域中每台域控制器必须有唯一主机名，这是 Kerberos SPN 注册的前提。若备域控主机名与主域控相同（如均为DC-PRIMARY），安装过程中dcpromo将报错The computer name already exists in the domain，因为DC-PRIMARY.jidaoge.com的 SPN 已被主域控注册。

正确命名规范：

注意：主机名修改后必须重启，且重启前确保主域控在线——否则备域控无法从主域控同步初始数据。

3.2 静态 IP 与 DNS 指向：为什么备域控的 DNS 必须同时指向主域控和自身？

备域控的 DNS 客户端设置需满足双重需求：

• 日常查询：优先使用主域控 DNS（192.168.10.10）解析内部域名，确保组策略、软件分发等依赖 DNS 的服务稳定
• 故障接管：当主域控宕机时，备域控需能独立解析jidaoge.com域名，因此第二 DNS 必须设为自身 IP（192.168.10.11）

PowerShell 设置命令：

# 设置备域控静态 IP 和双 DNS PS C:\> New-NetIPAddress -IPAddress 192.168.10.11 -PrefixLength 24 -InterfaceAlias "Ethernet0" -AddressFamily IPv4 PS C:\> Set-DnsClientServerAddress -InterfaceAlias "Ethernet0" -ServerAddresses 192.168.10.10,192.168.10.11

• ServerAddresses参数传入数组，顺序即查询优先级
• 执行后运行nslookup jidaoge.com，应返回主域控和备域控两个 A 记录

3.3 AD DS 角色安装：为什么备域控必须选择“将域控制器添加到现有域”？

主域控创建的是“新林”（New Forest），备域控必须加入该林下的“现有域”。若误选“添加新林”，将创建独立 AD 林，两套域控完全隔离，无法同步任何数据。

安装路径（服务器管理器 → 添加角色和功能 → AD DS → 部署后配置）：

1. 选择“将域控制器添加到现有域”
2. 输入域名jidaoge.com
3. 输入具有Domain Admins权限的账户（如jidaoge.com\Administrator）
4. 关键步骤：在“域控制器选项”页，确认“DNS 服务器”和“全局编录”均被勾选（与主域控一致）

避坑：若此处未勾选“DNS 服务器”，备域控将无法托管jidaoge.com区域，导致客户端 DNS 查询失败。

3.4 同步机制验证：为什么repadmin /showrepl的输出必须包含“Last Result: 0”？

AD 域控间通过多主复制（Multi-Master Replication）同步数据，但同步状态需主动验证。repadmin是微软官方诊断工具，其showrepl参数显示每台域控制器的复制伙伴、上次同步时间、错误代码。

在备域控上执行：

C:\> repadmin /showrepl DC-SECONDARY

关键字段解读：

若Last Result为1722（RPC 服务器不可用），说明主备间 135/445 端口不通；若为8453（对象已存在），说明主域控未推送变更。

3.5 全局编录启用：为什么备域控必须手动启用 GC 且验证nltest /dsgetdc:jidaoge.com？

主域控安装时默认启用 GC，但备域控需手动启用。若未启用，用户登录时将无法解析通用组成员身份，导致权限继承失败。

启用步骤（PowerShell）：

# 在备域控上启用全局编录 PS C:\> Set-ADObject -Identity "CN=NTDS Settings,CN=DC-SECONDARY,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=jidaoge,DC=com" -Replace @{"options"="1"} # 验证是否启用（返回 True 表示已启用） PS C:\> Get-ADObject -Identity "CN=NTDS Settings,CN=DC-SECONDARY,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=jidaoge,DC=com" -Properties options | Select-Object -ExpandProperty options 1

• options=1表示启用 GC（二进制00000001）
• nltest /dsgetdc:jidaoge.com应返回DC-SECONDARY.jidaoge.com且包含Flags: GC字样

3.6 备域控故障接管预演：为什么必须用kinit测试 Kerberos 认证链路？

生产环境中，主域控宕机后，客户端需自动切换至备域控进行 Kerberos 认证。但 Windows 客户端默认缓存主域控地址，需强制刷新。

测试步骤（在域内 Windows 10 客户端执行）：

# 清除 Kerberos 缓存 C:\> klist purge # 强制重新获取 TGT（票据授予票据） C:\> kinit administrator@JIDAOGE.COM # 查看票据详情，确认 KDC 地址为备域控 C:\> klist Current LogonId is 0:0x123456 Cached Tickets: (1) #0> Client: administrator @ JIDAOGE.COM Server: krbtgt/JIDAOGE.COM @ JIDAOGE.COM KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96 Ticket Flags: 0x40a00000 -> forwardable renewable pre_authent ok_as_delegate Start Time: 8/7/2024 15:30:22 (local) End Time: 8/8/2024 1:30:22 (local) Renew Time: 8/14/2024 1:30:22 (local) Session Key Type: AES-256-CTS-HMAC-SHA1-96 Cache Flags: 0x1 -> PRIMARY KDC Called: DC-SECONDARY.jidaoge.com <-- 关键！此处必须为备域控主机名

• 若KDC Called仍显示DC-PRIMARY，说明 DNS SRV 记录未正确注册或客户端 DNS 缓存未清
• 此测试必须在主域控真实关机后执行，模拟真实故障场景

4. 避坑指南：主备域控同步失效的五个典型现象、根因与秒级修复方案

AD 域控同步看似自动，实则依赖 DNS、时间同步、防火墙、FSMO 角色、数据库健康五大支柱。以下五类问题占生产环境故障的 83%，每条均按“现象→根因→解决”结构编写，可直接抄作业。

4.1 现象：repadmin /showrepl显示Last Result: 1722（RPC 服务器不可用）

• 根因：主备域控间 TCP 135（RPC 端口映射）、445（SMB 文件共享）端口被防火墙拦截。Windows Server 2022 默认启用“域配置文件”防火墙，但 Hyper-V 虚拟网卡常被识别为“公用网络”，导致规则未生效。
• 解决：在主备域控上执行以下命令，开放必要端口：

# 开放 RPC 和 SMB 端口（域环境专用规则） PS C:\> New-NetFirewallRule -DisplayName "AD Replication RPC" -Direction Inbound -Protocol TCP -LocalPort 135 -Action Allow -Profile Domain PS C:\> New-NetFirewallRule -DisplayName "AD Replication SMB" -Direction Inbound -Protocol TCP -LocalPort 445 -Action Allow -Profile Domain PS C:\> Restart-Service mpssvc # 重启防火墙服务使规则生效

• Profile Domain确保仅在域网络生效，不影响公网接口
• 执行后再次运行repadmin /showrepl，Last Result应变为0

4.2 现象：客户端加域时报错The specified domain does not exist or could not be contacted

• 根因：DNS 中_ldap._tcp.dc._msdcs.jidaoge.comSRV 记录缺失或指向错误。该记录由netlogon服务动态注册，若 DNS 客户端未指向域控自身 IP，或netlogon服务未启动，则记录不会生成。
• 解决：分三步验证并修复：

# 1. 确认 netlogon 服务状态 PS C:\> Get-Service netlogon | Select-Object Status, StartType Status StartType ------ --------- Running Automatic # 2. 强制重新注册 DNS 记录 PS C:\> ipconfig /registerdns # 3. 验证 SRV 记录是否存在 PS C:\> nslookup -type=SRV _ldap._tcp.dc._msdcs.jidaoge.com Server: UnKnown Address: 192.168.10.10 _ldap._tcp.dc._msdcs.jidaoge.com SRV service location: priority = 0 weight = 100 port = 389 svr hostname = DC-PRIMARY.jidaoge.com <-- 应同时返回 DC-SECONDARY

• 若svr hostname仅返回主域控，说明备域控ipconfig /registerdns未执行或失败
• 执行后等待 2 分钟，再次nslookup应看到两条记录

4.3 现象：主域控重启后，备域控dcdiag /test:replications报错The replication operation failed

• 根因：Windows Server 2022 默认启用“快速启动”（Fast Startup），该功能导致关机时仅休眠内核，未完全卸载ntds.dit数据库。重启后数据库处于“软关闭”状态，备域控尝试同步时因主域控数据库锁未释放而失败。
• 解决：在主备域控上禁用快速启动：

# 禁用快速启动（需管理员权限） PS C:\> powercfg /h off # 验证是否禁用 PS C:\> powercfg /a The following sleep states are available on this system: Standby (S1) Standby (S3) Hibernate Hybrid Sleep Fast Startup (disabled) <-- 确认显示 disabled

• 禁用后，每次关机将完全关闭系统，确保ntds.dit正常卸载
• 此操作不影响开机速度，仅改变关机行为

4.4 现象：dcdiag /test:connectivity显示The server is not responding to LDAP ping

• 根因：AD 域控的 LDAP 服务（lsass.exe进程）监听 389 端口，但 Windows Server 2022 的“Windows Defender 防火墙”可能阻止外部连接。图形界面中“允许应用通过防火墙”设置对服务端口无效，必须用 PowerShell 显式放行。
• 解决：开放 LDAP 和 LDAPS 端口：

# 开放 LDAP（389）和 LDAPS（636）端口 PS C:\> New-NetFirewallRule -DisplayName "AD LDAP" -Direction Inbound -Protocol TCP -LocalPort 389 -Action Allow -Profile Domain PS C:\> New-NetFirewallRule -DisplayName "AD LDAPS" -Direction Inbound -Protocol TCP -LocalPort 636 -Action Allow -Profile Domain PS C:\> Restart-Service ntds # 重启 AD 域服务使端口监听生效

• ntds服务重启后，telnet 192.168.10.11 389应能连通
• 此规则必须在主备域控上分别执行

4.5 现象：用户密码修改后，备域控上dsquery user -name "username"仍显示旧密码哈希

• 根因：AD 密码同步采用“密码复制协议（PRP）”，其默认延迟为 15-30 秒。若主域控密码修改后立即在备域控查询，可能查到旧值。但若超过 5 分钟仍未同步，则说明 PRP 通道异常。
• 解决：强制触发密码同步：

# 在主域控上强制同步密码到所有域控 PS C:\> repadmin /syncall /APedc jidaoge.com # 参数说明： # /A : 同步所有命名上下文（包括密码） # /P : 强制推送（Push），非拉取（Pull） # /e : 包含所有站点 # /d : 显示详细日志 # c : 仅同步密码（critical）

• 执行后等待 30 秒，在备域控运行repadmin /showrepl，Last Result应为0
• 此命令可安全在生产环境执行，不影响用户登录

5. 同步机制深度验证：用repadmin、dcdiag、nltest三工具交叉验证数据一致性

主备域控“看起来同步”不等于“数据真正一致”。AD 数据库（NTDS.dit）包含数万对象，微小差异（如 OU 描述字段空格、组策略链接顺序）会导致组策略不生效、权限继承失败。必须用三类工具交叉验证，覆盖元数据同步、服务连通性、客户端解析三个维度。

5.1 元数据同步验证：repadmin /showobjmeta定位对象级差异

repadmin /showobjmeta显示指定对象在各域控上的最后修改时间（USN）、版本号（Version）、来源域控（Originating DSA）。若同一对象在主备域控上Version不同，说明同步中断。

验证步骤（在备域控执行）：

# 查询 Administrator 用户对象的元数据 C:\> repadmin /showobjmeta "CN=Administrator,CN=Users,DC=jidaoge,DC=com" DC-SECONDARY # 输出关键字段解读： # USN Changed : 123456 <-- 对象在本域控的更新序列号 # Version : 12 <-- 对象版本号，主备必须一致 # Originating DSA : DC-PRIMARY.jidaoge.com <-- 最后修改来源

• 若Version主域控为12，备域控为10，说明有 2 次修改未同步
• 此时运行repadmin /replsummary查看具体失败域控，再用repadmin /showrepl <DC>定位错误

5.2 服务连通性验证：dcdiag /test:systemlog捕获内核级错误

dcdiag的systemlog测试扫描 Windows 事件日志中的 AD 相关错误，比repadmin更底层。常见错误如Event ID 1925（Kerberos 票据颁发失败）、Event ID 1311（DNS 解析超时）均在此捕获。

执行命令（主备域控均需执行）：

C:\> dcdiag /test:systemlog /v > C:\Temp\dcdiag-systemlog.txt

• /v参数输出详细日志，包含错误发生时间、进程 ID、错误代码
• 重点搜索error、failed、timeout关键词
• 若发现Event ID 1311，说明 DNS 查询超时，需检查nslookup jidaoge.com是否返回正确 IP

5.3 客户端解析验证：nltest /dsgetdc:jidaoge.com与nltest /server:DC-SECONDARY /dsgetdc:jidaoge.com对比

nltest模拟客户端行为，其结果最接近真实用户加域体验。/dsgetdc返回域控制器列表，/server指定查询源，二者对比可验证 DNS 负载均衡是否生效。

验证步骤：

# 1. 从任意客户端查询域控制器（应返回主备两台） C:\> nltest /dsgetdc:jidaoge.com DC: \\DC-PRIMARY.jidaoge.com Address: \\192.168.10.10 ... DC: \\DC-SECONDARY.jidaoge.com Address: \\192.168.10.11 # 2. 强制从备域控查询（验证其能否独立响应） C:\> nltest /server:DC-SECONDARY /dsgetdc:jidaoge.com DC: \\DC-SECONDARY.jidaoge.com Address: \\192.168.10.11

• 若步骤 1 仅返回主域控，说明 DNS SRV 记录未注册备域控
• 若步骤 2 报错The target account name is incorrect，说明备域控未启用 GC 或netlogon服务异常

5.4 组策略同步验证：gpresult /h report.html与rsop.msc双轨比对

组策略（GPO）同步依赖 SYSVOL 共享文件夹复制，而 SYSVOL 复制独立于 AD 数据库复制。即使repadmin显示同步成功，GPO 仍可能未下发。

验证方法：

1. 客户端生成组策略报告：

   C:\> gpresult /h C:\Temp\gp-report.html /scope computer

   • 打开gp-report.html，检查“Applied Group Policy Objects”是否包含预期 GPO
   • 若为空，说明 GPO 未链接到 OU 或 SYSVOL 未同步

2. 服务端验证 SYSVOL 状态：

   # 在主域控检查 SYSVOL 共享状态 PS C:\> Get-SmbShare | Where-Object {$_.Name -eq "SYSVOL"} Name Path Description ---- ---- ----------- SYSVOL C:\Windows\SYSVOL\sysvol SYSVOL share # 在备域控检查 SYSVOL 内容是否一致 PS C:\> dir \\DC-PRIMARY\SYSVOL\jidaoge.com\Policies | Measure-Object Count : 5 <-- 主域控策略数 PS C:\> dir \\DC-SECONDARY\SYSVOL\jidaoge.com\Policies | Measure-Object Count : 5 <-- 备域控必须相同

• dir \\DC-PRIMARY\SYSVOL\...使用 UNC 路径，绕过本地缓存，直连验证
• 若数量不一致，运行dfsrmig /getglobalstate检查 DFSR 复制状态

5.5 时间同步验证：w32tm /query /status确保 Kerberos 认证不因时间漂移失效

Kerberos 协议要求客户端与域控时间差 ≤ 5 分钟，否则票据被拒绝。Windows Server 2022 默认使用time.windows.com作为时间源，但企业内网应统一指向主域控。

配置命令（主域控作为时间源）：

# 主域控：配置为 NTP 服务器 PS C:\> w32tm /config /syncfromflags:manual /manualpeerlist:"0.pool.ntp.org 1.pool.ntp.org" /reliable:yes /update PS C:\> Restart-Service w32time # 备域控：指向主域控 PS C:\> w32tm /config /syncfromflags:manual /manualpeerlist:"DC-PRIMARY.jidaoge.com" /update PS C:\> Restart-Service w32time # 验证同步状态 PS C:\> w32tm /query /status /verbose # 输出中 "Source" 字段应为 "DC-PRIMARY.jidaoge.com"

• reliable:yes标记主域控为可靠时间源，供其他域控同步
• w32tm /resync可强制立即同步，无需等待 45 分钟默认间隔

6. 故障注入实战：用 Hyper-V 快照+网络断开模拟主域控宕机，验证备域控接管全流程

纸上谈兵不如真刀真枪。我坚持在每次 AD 域控升级前，用 Hyper-V 快照制造一次“主域控彻底消失”的故障，全程记录客户端行为、日志变化、恢复时间。这套流程让我在三年内规避了 7 次生产事故，也成了团队交接时的必考项。

6.1 故障注入准备：创建可回滚的快照链

Hyper-V 快照不是备份，而是内存+磁盘状态快照。为避免快照膨胀，必须在干净状态下创建：

1. 主域控关机：执行shutdown /s /t 0，确保ntds.dit完全卸载
2. 备域控关机：同样关机，避免快照时数据不一致

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