企业官网建设流程全解析

办公室分了两地，网络也隔开了，但域控还是老一套单站点架构，结果分公司那头的员工登录慢、访问文件服务器经常卡顿，安全策略下发也时好时坏。这个问题折腾了一周，最后落在两件事上：把 AD 从单站点调整为单域多站点，以及把 DNS 各站点的子网掩码排序规则理清楚。这篇文章就围绕这次的 WinServer 2012 R2 环境，完整记录一下整个搭建过程和排坑细节，适合正在折腾多办公室、多网段统一域管理的运维同行参考。

1. 项目背景与方案设计思路

1.1 单域多站点到底解决什么问题

先说一个典型的场景：总部在上海，分公司在苏州，两边各有一个网段，服务器和设备各自独立。如果只建一个域、把所有域控都塞在默认的 Default-First-Site-Name 里，客户端登录、GPO 下发、DNS 解析根本不会区分“你在哪个物理位置”，全凭运气找域控。运气好找到本地 DC，响应很快；运气不好跨了专线去找另一头的 DC，登录直接卡在半分钟以上。

AD 站点的核心作用就是把“物理网络拓扑”和“逻辑域结构”对应起来。每个站点对应一个或多个连续 IP 子网，客户端根据自己 IP 归属自动套用站点身份，然后优先从本站点的域控做认证、拿组策略、解析 DNS。这样既保留了单域统一管理的便利，又让每个分支的访问体验接近本地。

1.2 方案选型：单域多站点 vs 多域多林

有些人会问：既然两边网络都独立了，何不干脆分别建两个域，甚至两个林？我明确建议不要这么干，除非有法律合规或管理隔离上的硬性要求。多域意味着 Schema、配置分区、GC（全局编录）都要跨域处理，权限模型复杂了，GPO 也难统一，Exchange、SharePoint 这类依赖域的组件会变得更加难伺候。单域多站点在多分支场景下是最务实的选择。

单域多站点的优点很直接：

• 一套域账号、一套组策略管全部站点。
• 所有 DC 都是全局编录（默认就是），跨站点认证不需要额外处理 GC 放置。
• DNS 区域作为 AD 集成区域自动复制，每个 DC 都能承担解析。
• 管理复杂度只增加“站点、子网、站点链接”这几个概念，好理解也好排障。

具体到这次环境，域内计划放两台 DC：总部一台、分公司一台。域名沿用内部规划好的 corp.local，站点分成两个：HQ（总部）和 Branch（分公司），对应子网分别是 192.168.10.0/24 和 192.168.20.0/24。

1.3 本次项目的网络规划

动手之前先把 IP 规划表定下来，后面所有配置都围绕这个表展开，避免现场临时拍脑袋。

两个站点的客户端 DNS 设置建议主指向本站点 DC，辅指向对端 DC。比如 Branch 客户端主 DNS 填 192.168.20.10，辅 DNS 填 192.168.10.10。这样本站点 DC 挂掉时还能通过远端 DNS 完成解析，但正常状态下靠排序规则保证优先走本地。这个“排序”正是后面第四节的重点。

2. 前置准备与第一台域控搭建

2.1 服务器与 IP 规划要点

两台服务器先装好 Windows Server 2012 R2，系统盘和数据盘分开。装系统时不要用中文计算机名，因为 AD 对 NetBIOS 名称兼容性虽然还行，但中文名在部分旧协议和工具下会出幺蛾子，老老实实用 DC01、DC02 这种命名。

每台服务器的 IP 必须是静态的，这个是前提。虚拟机网卡、物理机网卡都要确认没有勾选“Internet 协议版本 6 (TCP/IPv6)”的一些随机临时地址干扰，直接按规划表填好 IPv4。DNS 设置这里有个细节：DC01 的 DNS 指向自己 127.0.0.1 或者 192.168.10.10 都行，DC02 在提升为域控之前，DNS 必须指向 DC01（192.168.10.10），否则加域和提升都会出问题。

另外建议先同步系统时间。Windows Server 默认时间源是 time.windows.com，不过内网最好统一走域同步机制。DC01 提升后默认就是林根域的 PDC 模拟器，后续让它是权威时间源，DC02 和客户端从域内同步时间。

2.2 第一台域控（DC01）搭建实操

打开服务器管理器，点击“添加角色和功能”，安装类型选择“基于角色或基于功能的安装”，服务器选择 DC01。在角色列表里勾选“Active Directory 域服务”，系统会弹出依赖功能提示，直接确认添加，一路下一步安装。

装完角色后，右上角会出现一个黄色感叹号通知，提示“将此服务器提升为域控制器”，点击进入部署配置。这里选择“添加新林”，根域名为 corp.local，林功能级别和域功能级别都选 Windows Server 2012 R2，因为整个环境最低版本就是这个。如果有更老的系统，功能级别要相应降低，但 2012 R2 环境没必要留历史包袱。

下一步设置域控制器选项，勾选“DNS 服务器”和“全局编录 (GC)”，填入目录服务还原模式（DSRM）密码。接下来会提示 DNS 委派，第一次建林直接跳过，因为还没有下级区域需要委派。NetBIOS 域名默认是 CORP，保持默认即可。

后面的数据库、日志、SYSVOL 路径建议保持默认的 C:\Windows 下，除非 C 盘空间捉襟见肘。到了“先决条件检查”这一步，如果之前 DNS 没装或者静态 IP 没配对，会直接卡在这。确认所有检查通过后点击“安装”，系统会自动重启完成提升。

用 PowerShell 也能完成同样的事，批量部署时效率更高：

Install-WindowsFeature AD-Domain-Services -IncludeManagementTools Install-ADDSForest ` -DomainName "corp.local" ` -DomainNetbiosName "CORP" ` -ForestMode "Win2012R2" ` -DomainMode "Win2012R2" ` -InstallDns:$true ` -SafeModeAdministratorPassword (ConvertTo-SecureString "你的DSRM密码" -AsPlainText -Force)

2.3 安装后的基础验证

DC01 重启完，第一件事不是急着搭第二台，而是确认域和 DNS 都健康。

在 DC01 上打开 DNS 管理器，应该能看到 corp.local、_msdcs.corp.local 等区域已经自动创建。重点检查 _msdcs.corp.local 区域下的 SRV 记录，比如 _ldap._tcp.dc._msdcs.corp.local 有没有指向 DC01。DNS 区域如果能被 AD 正确复制，GC 记录也会自动注册。

命令行验证更直接：

dcdiag / /test:dns

如果 DNS 测试全部通过，说明第一台 DC 基础没问题。顺手再用 repadmin 看下复制状态：

repadmin /replsummary

这时候只有一个 DC，复制列表是空的，但命令本身要能正常执行，不能报错。

3. 第二台域控与 AD 站点子网绑定

3.1 把第二台服务器提升为额外域控

DC02 加入域之前，先确认它可以和 DC01 互通，DNS 指向 192.168.10.10。打开系统属性，在“计算机名”标签页点击“更改”，把计算机名改为 DC02，然后选择“隶属于域”，输入 corp.local，弹出凭据窗口后填入域管理员账号。

加入域成功后会提示重启。重启后登录时注意选择“登录到: CORP”或用 CORP\administrator 登录，不要登录到本地。

第二步同样在服务器管理器安装 AD 域服务角色，然后点击黄色感叹号中的“将此服务器提升为域控制器”，但这回部署配置选“将域控制器添加到现有域”，域名填 corp.local。指定域凭据时，需要提供对端 DC 的管理员权限，比如 CORP\administrator。

域控制器选项里继续勾选“DNS 服务器”和“全局编录 (GC)”，DSRM 密码最好和 DC01 的保持一致，避免以后恢复目录时记混。先决条件检查时会出现 DNS 委派相关警告，属于正常情况，因为 _msdcs 区域已经存在，点击安装即可。

提升完成后，在 AD 站点和服务管理工具里，DC02 最初会被放进默认站点 Default-First-Site-Name，这一步后面会调整到 Branch 站点。

3.2 在 AD 站点和服务中划分站点与子网

打开“Active Directory 站点和服务”（dssite.msc），左侧会看到 Default-First-Site-Name。我习惯先把它重命名为 HQ，毕竟是总部站点。

然后点开 Sites -> Subnets，右键“新建子网”。这里输入 192.168.10.0/24，并在站点下拉列表里选 HQ。同样再建一条 192.168.20.0/24，站点里选 Branch。新建完两条子网，AD 内部就建立起了“网段 → 站点”的映射表，这直接影响客户端归属识别。

用 PowerShell 也能做：

Rename-ADObject -Identity "CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=corp,DC=local" -NewName "HQ" New-ADReplicationSubnet -Name "192.168.10.0/24" -Site "HQ" New-ADReplicationSubnet -Name "192.168.20.0/24" -Site "Branch"

创建完子网后，把 DC02 从默认站点拖到 Branch 站点。在 AD 站点和服务里展开 HQ -> Servers，可以看到 DC02 挂在下面，右键 DC02 -> 移动到站点，选择 Branch。如果这里不移动，DC02 仍会被 HQ 客户端和 Branch 客户端当作 HQ 站点对象，复制拓扑会误判。

3.3 站点链接（Site Link）的配置细节

默认有个站点链接叫 DEFAULTIPSITELINK，它把 HQ 和 Branch 都包含进去了。为了可读性，我建议重命名成 HQ-Branch-Link，然后设置两个关键参数：开销和复制间隔。

开销（Cost）默认是 100，表示两个站点之间走这条路径的优先级。如果以后有两条专线、一个贵一个便宜，就把便宜那条开销设小，AD 复制自动选开销小的路径。这里只有一条链路，100 就行，不用改。

复制间隔默认 180 分钟，这个值偏长。举个例子：总部管理员给某个用户重置了密码，如果复制间隔是 180 分钟，分公司的 DC 要等 3 小时才拿到这个新密码，用户在分公司登录旧密码还能过，但新密码要等很久才生效，体验很割裂。我在生产环境一般调到 15 到 30 分钟。勾选“更改通知”选项，还能在站点之间启用类似站点内复制的通知机制，更及时。设置完后可以用 repadmin 验证：

repadmin /showrepl repadmin /replsummary

看到 DC02 和 DC01 之间有复制连接且状态正常，就说明站点间复制拓扑已经建立。

4. DNS 子网掩码排序调整

4.1 网络掩码排序（Netmask Ordering）的工作原理

这是本次项目里最容易踩坑的环节，也是标题里“DNS各站点的子网掩码排序调整”所指的核心。Windows Server 自带的 DNS 服务默认开启“网络掩码排序”功能：当客户端查询一条有多条 A 记录的主机名时，DNS 服务器会根据查询来源 IP 所在的子网，把和客户端同一子网（或者最接近的那条子网）的 A 记录排在响应列表最前面。

正常逻辑下，分支客户端查询 FS01 时，如果 FS01 同时有 192.168.10.20 和 192.168.20.20 两条记录，DNS 会优先返回 192.168.20.20，让流量尽量留在本地。没有这个排序，客户端拿到的记录顺序是轮询的，可能一半请求跑到总部去，专线带宽白费，延迟还高。

但这一切的前提是：“DNS 服务器知道客户端属于哪个子网”。这个信息从哪里来？两个地方：一是客户端请求本身的来源 IP；二是 DNS 服务器从 AD 配置分区里读取的“子网→站点”映射表。如果 AD 站点和子网没配置，或者配置错乱，DNS 的排序就会失真，甚至退化成随机轮询。

4.2 为什么多站点下排序会乱

常见三种情况：

第一种，AD 站点子网没有创建，所有客户端都归属于默认站点，DNS 无法区分来源站点，只能把所有记录当成“同一站点”处理，排序无从谈起。

第二种，站点链接配置有误，DNS 认为两个站点之间开销过大，即使客户端就在本地，也不一定把本地记录排最前。

第三种，DNS 区域属性里“启用网络掩码排序”被关闭了。有些教程为了让单站点下多个 Web 服务器负载均衡，会让运维手动关掉这个选项，结果多站点环境忘了重新打开，所有解析全变轮询。

还有一种隐蔽情况：DNS 缓存里残留了旧子网信息。站点子网改过之后，DNS 服务器不会立即感知，重启 DNS 服务或者清缓存之前，排序规则依然按旧表走。

4.3 调整与验证 DNS 排序

先确认区域的 netmask ordering 是开启状态。打开 DNS 管理器，展开“正向查找区域”，右键 corp.local 区域，进入“属性”，切到“高级”标签页，找到“启用网络掩码排序”并勾选。如果之前在单站点场景为了负载均衡关掉过，这里要重新打开。

下一步检查 AD 站点子网，确认 192.168.10.0/24 和 192.168.20.0/24 都绑定了正确的站点。如果刚才第四节已经按步骤做完了，这里问题不大。

最关键的验证动作是：在两个站点各找一台客户端，分别执行 nslookup，看解析结果的顺序。

Branch 客户端执行：

nslookup FS01 192.168.20.10

如果返回结果里第一条是 192.168.20.20，说明排序已经生效。如果第一条是 192.168.10.20，说明哪里还不对，按下面的思路排查。

先看 DNS 缓存：

dnscmd /clearcache

同时在被测客户端执行：

ipconfig /flushdns

再重新 nslookup 一次。如果还不行，检查 DNS 服务器是否还在用旧拓扑缓存，重启 DNS 服务：

net stop dns net start dns

如果希望从注册表层面控制这个行为，可以打开：

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNS\Parameters

新建 DWORD 值 DisableNetmaskOrdering，0 表示启用排序，1 表示禁用。默认就是 0，所以一般不用动。

4.4 让 DNS 排序在故障切换时仍然可靠

排序生效后还有一个隐患：如果本地 FS02 宕机了，DNS 依然会优先返回 192.168.20.20，客户端的资源访问会直接失败。要解决这个问题，不能靠 DNS 排序本身，而是靠“客户端故障切换机制”。

对于 SMB 文件共享场景，客户端会尝试连接第一条记录，失败后不会自动切换到第二条，这会很难受。所以要么在资源侧做高可用（比如 DFS-N + DFS-R，或者 Windows 故障转移集群），要么在文件共享访问时使用 DFS 命名空间，由 DFS 客户端根据站点信息自动选择最近且可用的目标。

在纯 DNS 层面能做的优化是：确保两条 A 记录都真实有效，并且使用运行状况检查。2012 R2 的 DNS 本身不带健康检查，但配合 NLB 或者持续监控就能提高可用性。如果预算和版本允许，2016 以后的 DNS 策略可以做更细粒度的问题规避，但对这次 2012 R2 改造来说，把站点子网和排序弄对就已经解决了大部分问题。

5. 常见问题与排查技巧实录

5.1 跨站点登录慢排查

项目上线后最容易收到的反馈就是“分公司登录还是一卡一卡的”。先说结论：八成是客户端归属站点判断错了。在 AD 站点和服务里创建了子网映射，但客户端登录时依据的是 DC 返回的站点对象。如果网段划分和 AD 子网映射不匹配，客户端会落到错误的站点里。

排查命令很直接：

nltest /dsgetsite

Branch 的客户端执行后，如果返回结果不是 Branch，而是 HQ 或 ERROR，说明子网映射有问题。这时打开 AD 站点和服务检查 192.168.20.0/24 是否真的关联到了 Branch 站点。另一个可能因素是本站点 DC 不可用，客户端自动 failover 到了远端 DC，这种情况 nltest 会显示实际提供登录的 DC 名称，方便定位。

5.2 时间同步与 Kerberos 失败

第二个高频坑是跨站点 DC 互相同步时提示“拒绝访问”或者“时钟偏差过大”。Kerberos 默认允许的最大时钟偏差是 5 分钟，超过这个值认证直接失败。多站点环境下，如果 DC 各自从不同时间源同步且时间源漂移严重，就会出这个问题。

建议把根域 PDC 模拟器（通常是 DC01）配置为内网权威时间源，让它从外部可靠 NTP 服务器同步，其他 DC 和客户端全部从域内同步。DC02 上执行：

w32tm /config /syncfromflags:domhier /update net stop w32time net start w32time w32tm /resync

这样可以保证整条时间链统一。千万别图省事让每台 DC 都直连外网时间源。

5.3 复制不走的排查

站点建好、DC02 提升完，复制却一直不成功，很多情况下是防火墙问题。Windows 防火墙默认放行 AD 所需端口，但如果之前套用了第三方防火墙策略，可能挡掉站点间的 RPC 动态端口。最稳妥的办法是在组策略的“安全设置 -> 本地策略 -> 安全选项”中启用“允许网络中所依赖的网络服务之间发生通信”策略。这个策略开启后，Windows 会自动为域控创建防火墙规则，放行复制所需的端口和协议。如果没有启用，就算看着一切正常，复制流量也可能被拦得干干净净。

排查复制用这几条命令：

repadmin /showrepl repadmin /replsummary dcdiag /test:intersite

看到报错为“RPC 服务器不可用”时，优先检查防火墙和 DNS 解析，因为复制需要能解析到对端 DC 的 IP，DNS 记录不对一样会失败。

5.4 运维建议与经验总结

整个项目做完，留下几条运维经验供参考。

第一，别动“启用网络掩码排序”的默认选项，除非你很清楚后果。多站点场景下这个选项能极大改善客户端就近访问的能力，关掉只会让问题更严重。

第二，AD 站点子网是“本", 映射表也是一个需要持续维护的资产。以后新增网段，第一时间去 AD 站点和服务里补子网映射，否则那些网段客户端会全部归属到默认站点，所有优化全部白费。

第三，站点链接的复制间隔不要设太短，比如 5 分钟。站点间复制是压缩传输，频繁同步会增加 DC 负载和专线流量。15 到 30 分钟是大多数场景的平衡点，密码等紧急变更可以手动用 repadmin /syncall 强制同步。

第四，GC 在单域多站点环境下不需要特别处理，所有 DC 默认都是 GC，但如果你以后在同一域里加了很多子域，就需要注意 GC 覆盖策略，避免跨站点认证时去远端 GC 查询组成员身份。

就我个人经验来说，这次改造中最值得反复确认的环节就是“DNS 排序是否真的按预期工作了”，它不像复制同步有 repadmin 那种非常显眼的验证命令，nslookup 看列表顺序这种细节很容易被跳过。建议做成上线检查清单的一条，逐站点逐客户端抽测，才能保证整个方案真正落地生效。后续如果还要优化跨站点文件访问体验，可以在 DFS 命名空间和站点拓扑配合上继续深挖。