做企业网络这块的兄弟应该都有体会公司规模一大总部加分支机构的模式就特别常见。前阵子接到一个项目总部在北京上海有个规模不小的研发中心两边都有独立的办公室和网络环境但业务系统、域账号必须要统一管理不能搞成两套独立的域。客户提的需求很明确用 Windows Server 2012 R2 搭一套 Active Directory 单域环境然后把上海站点通过站点拓扑纳入同一个域最后还要保证两边客户端登录认证时能自动优先找到本地的域控制器不能被 DNS 排序问题带到“千里之外”去认证。这个项目整体不算复杂但细节特别折磨人。尤其是“DNS 各站点的子网掩码排序调整”这一块属于那种不踩坑根本意识不到有问题的环节。我把整个搭建过程和排查思路整理出来给准备做单域多站点的朋友一个参考特别是 DNS 子网掩码排序这部分建议仔细看一下。1. 项目背景与全网拓扑规划1.1 需求拆解为什么非要做单域多站点客户原来的网络环境是总部和上海各自独立的工作组模式没有统一的域管理。问题很明显账号体系不能互通文件服务器权限要靠本地账号凑合组策略完全没法统一下发。后来上了 ERP 系统需要统一的身份认证这才决定正式做域环境。做单域还是多域我一开始也纠结过。单域的好处是管理成本低、组策略统一、账号全局唯一用户在任何站点登录都能用同一套身份多域虽然隔离性更好但信任关系、GC全局编录、复制拓扑都更复杂对客户这种规模属于过度设计。所以最终方案定为单域多站点。在北京总部部署两台域控制器做冗余上海部署一台域控制器服务于本地三个站点之间通过 AD 站点拓扑控制复制流量让客户端通过站点自动知识能力定位最近的 DC。1.2 网络拓扑与 IP/子网规划这个环节直接决定了多站点能不能正常工作。规划时我画了一张拓扑表核心思路是“先有网络规划再谈 AD 角色”。站点名称物理位置网段子网掩码域控制器角色Site-A北京总部10.10.0.0/24255.255.255.0DC01、DC02主域控 GCSite-B上海研发中心10.20.0.0/24255.255.255.0DC03额外域控 GC很多人在规划阶段容易忽略一个细节AD 站点里支持的“子网”对象必须和 VLAN/三层网段一一对应且掩码要精确。比如上海是 10.20.0.0/24你如果用 10.20.0.0/16 去关联站点DNS 排序和站点定位都会出问题。这个后面在第五章专门说。另外站点链接成本我一开始设置的是默认 100但后来考虑到北京到上海链路用的是运营商专线延迟低所以把成本调成了 50让 KCC 能基于物理链路质量生成合理的复制链接。2. 基础环境准备与部署前置检查2.1 服务器硬件与系统版本要求客户这边的服务器是 DELL PowerEdge R740配置完全够用。2012 R2 这个版本对硬件要求不算高2 核 4GB 起步就能跑但生产环境我建议至少 4 核 8GB尤其是全局编录服务器。注意一点2012 R2 标准版和数据中心版在 AD DS、DNS 角色上没有功能差异都可以当域控。但如果后面要做 Hyper-V 虚拟化数据中心版会更合适。客户这边全是物理机直接标准版就行。系统补丁记得打全特别是 2014 年之后的累积更新里面有大量针对 2012 R2 AD 和 DNS 的稳定性修复。我第一次部署时偷懒没打补丁结果 DC03 加域后复制一直报错后来发现是 KB2919355 缺失导致的非常冤。2.2 主机名、静态 IP、DNS 指向的关键细节服务器装好后我习惯先做“三件事”改主机名、配静态 IP、把 DNS 指向自己。主机名建议带有业务含义比如 DC01-BJ、DC02-BJ、DC03-SH这样后面看日志和拓扑时一眼就能认出来。主机名一旦加入域后不要随意改虽然 2012 R2 支持改名但会影响 SPN、DNS 注册等一堆东西生产环境别折腾。IP 配置方面DC0110.10.0.11/24DNS 指向 127.0.0.1DC0210.10.0.12/24DNS 指向 10.10.0.11DC0310.20.0.13/24DNS 指向 10.20.0.13自指DC 的 DNS 指向是很多人踩坑的重灾区。多站点环境下DC 的首选 DNS 一定要指向自己或同站点内的另一台 DC绝对不能指向公网 DNS 或其它站点的 DC。DC03 我把 DNS 指回了自己是因为它本身就要承载上海站点的 DNS 解析如果指向北京 DC一旦专线断开上海站点连 DNS 解析都会瘫痪。2.3 时间同步NTP 配置与公共服务器的选型AD 对时间同步非常敏感Kerberos 认证默认允许最大 5 分钟偏差超过就认证失败。在单域多站点环境下时间源建议统一避免各站点各调各的。我的做法是北京 DC01 作为林根域控默认就是 PDC 模拟器让它从外部 NTP 服务器同步其它所有 DC 和成员服务器都向 DC01 同步时间。# 在 DC01 上执行外部 NTP 源 w32tm /config /manualpeerlist:ntp.aliyun.com,0x8 ntp.tencent.com,0x8 /syncfromflags:manual /reliable:yes /update restart-service w32time # 其它 DC 上执行向 DC01 同步 w32tm /config /syncfromflags:domhier /reliable:no /update restart-service w32time这个配置我建议在搭建 DC 的第一时间就做别等全部装完了再补免得中间认证失败找不到原因。3. AD DS 角色安装与初次提升3.1 使用服务器管理器安装 AD DS 和 DNS 角色2012 R2 的 AD DS 部署比 Server 2008 方便很多不再需要运行 dc prom 命令直接在服务器管理器里通过“添加角色和功能向导”就能完成。安装 AD DS 角色时向导会同步推荐安装 DNS 服务器角色。这里我建议直接勾选AD 域环境离不开 DNS而且 Windows 集成的 DNS 区域可以配合 AD 复制省去单独维护 DNS 主从的麻烦。多站点环境生成以后其实还有一个更隐蔽的好处每个 DC 的 DNS 服务都会承载所在站点的解析客户端直接把 DNS 指向本地 DC 就行不需要额外部署 DNS 服务器。3.2 提升为域控制器域功能级别与 DNS 集成区域选项AD DS 角色装完后需要点击通知栏的“将此服务器提升为域控制器”。这里有两个关键选项域功能级别2012 R2 环境建议直接选 Windows Server 2012 R2除非你还有 2008 R2 的老 DC 需要兼容。客户这边全是新服务器直接选最高即可。DNS 选项勾选“DNS 服务器”和“全局编录”DNS 区域类型保持“与 AD 集成”默认即可。额外提一个点安全里有个“DCPromo 后期弃用”的说法其实在 2012 R2 上旧版的 dcpromo.exe /unattend 仍然可用于无人值守部署但生产环境建议老老实实用图形界面出问题好排查。DC03 的部署我用了 PowerShell 的方式命令如下Install-ADDSDomainController -DomainName corp.local -SiteName Site-B -InstallDns:$true -GlobalCatalog:$true -DatabasePath C:\Windows\NTDS -LogPath C:\Windows\NTDS -SysvolPath C:\Windows\SYSVOL -SafeModeAdministratorPassword (ConvertTo-SecureString Pssw0rd! -AsPlainText -Force) -NoRebootOnCompletion关于 SYSVOL 和 NTDS 路径如果有独立的数据盘或者 SSD建议把路径指过去日志和数据库分开性能会好一些。我这次因为客户服务器只有一块系统盘所以用了默认路径也不影响功能。3.3 部署后基线检查dcdiag、net share、DNS 记录确认DC 提升完成后别急着做下一步先跑一遍基线检查。我习惯依次执行以下几条命令dcdiag /s:DC01 /v /f:C:\dcdiag.log repadmin /replsum net share nslookup corp.local 127.0.0.1dcdiag 是最重要的。如果看到 “passed test Advertising”、“passed test Replications” 这类输出说明域控功能基本正常。net share 检查 SYSVOL 和 NETLOGON 共享是否存在这是组策略正常下发的核心。DNS 记录方面重点确认_msdcs.corp.local区域下的 SRV 记录是否完整。多站点环境常用这条命令nltest /dsgetdc:corp.local /gc如果返回“DC: \DC01.corp.local”说明定位正常。之后加第二台 DC 时同样跑一遍确认 DC 能发现已有域控。4. 单域多站点架构的落地配置4.1 理解站点Site、子网Subnet与站点链接Site Link的作用很多刚接触 AD 的朋友容易把 AD 站点理解成“物理位置”其实并不准确。AD 站点是一组 IP 子网的集合它的设计目的是控制两方面行为一是复制二是客户端登录定位。打个比方一个公司在北京总部有 10.10.0.0/24在上海有 10.20.0.0/24如果 AD 不建站点所有客户端都会被归到默认站点 Default-First-Site-Name登录时它们会随机或者按 AD 站点覆盖规则去找 DC而不会优先考虑“谁离我近”。AD 站点的本质是“按网络可达性分组”不是按行政区域分组。多站点架构下Site Link 是连接多个站点的逻辑线路KCC知识一致性检查器会根据 Site Link 的成本、计划、间隔自动生成复制拓扑。成本越低复制越频繁。4.2 在“Active Directory 站点和服务”中创建站点和站点链接这一步我使用“Active Directory 站点和服务”管理工具操作。步骤如下在 Sites 节点下右键新建 Site命名为 Site-B上海站点选择 DEFAULTIPSITELINK 作为站点链接。展开 Subnets 节点右键新建 Subnet输入 10.20.0.0/24关联到 Site-B。再新建 10.10.0.0/24关联到 Site-A默认站点可以改名为 Site-A。到 Inter-Site Transports IP 下打开 DEFAULTIPSITELINK设置成本为 50复制间隔默认 180 分钟可以改短到 60 分钟。子网关联时务必注意掩码精度问题。10.20.0.0/16 和 10.20.0.0/24 是两个完全不同的 AD 子网对象只有关注 /16 时才会导致上海 10.20.10.x、10.20.20.x 等不同 VLAN 全被塞进一个站点DNS 子网排序时你根本控制不了返回顺序。如果每个 VLAN 都有独立 DC/服务这种粗粒度定义会让定位逻辑彻底乱掉。4.3 将第二台 DC 添加到分支站点并移动站点归属DC03 在上海加入域时我特意指定了站点参数。PowerShell 命令里的-SiteName Site-B就是干这个的。如果加域的向导里没有指定站点也可以等加域完成后在“Active Directory 站点和服务”里找到 DC03 所在 NTDS Settings 对象右键属性修改“查询站点”把它挪到 Site-B。这一步的操作逻辑是DC03 加入域时虽然它本身在上海但如果 AD 站点里没有对应子网或者没指定站点KCC 会把它默认放进 DEFAULTIPSITELINK 连接的站点里复制链路可能就直接跨了专线把宝贵的链路带宽浪费在复制上。等到 DC03 加域完成可以在站点和服务的 DC03 下看到“自动生成的复制连接”NTDS Settings 里会有从 DC01/DC02 入站的连接对象。如果连接拓扑不符合预期可以在 KCC 完成下一次计算前手动触发repadmin /kcc4.4 验证跨站点复制repadmin /replsum 与 KCC 自动生成连接跨站点部署最怕复制链路有问题登录认证和组策略同步都会受影响。我部署完成后立即在 DC01 上跑了一遍repadmin /replsum /bysrc /bydest理想情况下所有 DC 的状态都是“成功”最后一个数字为 0延迟时间表示 RPC 通信耗时。遇到状态失败时先检查网络端口RPC 动态端口、TCP 135、UDP 389 等。这里分享一个很容易被忽视的情况DC03 加入域后我原以为它会在 Site-B 自动与 DC01 建立复制链接但第一次检查时发现 DC03 的入站连接完全没生成。后来排查发现我在创建 Site-B 时没有先把 DC03 的计算机对象移动过去它虽然-SiteName指定了但 NTDS Settings 的站点归属还是默认站点。把 NTDS Settings 属性改到 Site-B 后repadmin /kcc手动触发复制连接才正常建立。5. DNS 子网掩码排序调整多站点定位 DC 的隐形开关5.1 DNS 子网掩码排序的基本原理这部分我觉得是整个项目中最绕的地方也是标题里“DNS 各站点的子网掩码排序调整”的核心内容。DNS 服务器在返回多条匹配的 A 记录时默认会启用“子网掩码排序”功能。简单说就是当客户端解析某个主机名有多个 IP 地址时DNS 服务器会拿客户端源 IP 和这些候选 IP 做子网匹配优先返回“与客户端所在子网最接近”的地址。举个例子客户端在 10.20.0.0/24 网段请求解析 dc.corp.localDNS 区域里有 10.10.0.11 和 10.20.0.13 两条记录。如果 DNS 服务器启用了子网掩码排序会优先返回 10.20.0.13。如果没启用或掩码配置不精确返回顺序可能随机客户端可能拿到跨站点的 10.10.0.11导致认证流量跨专线。需要注意DNS 子网排序是基于“A 记录里的 IP 地址与客户端 IP 的按位与结果”不是基于 AD 站点。AD 站点只是影响 DC 的 SRV 记录注册和定位算法但客户端最终解析 DC 的 A 记录时走的还是 DNS 排序逻辑。两套机制要配合好才算真正把“最近 DC”这件事做对。5.2 多站点环境下“子网/掩码”与 AD 站点的关联策略很多员工落在这里AD 站点里创建了一个子网对象 10.20.0.0/16但实际网络划分是 10.20.10.0/24、10.20.20.0/24、10.20.30.0/24 等多个 VLAN。这种情况下所有上海客户端都会被识别为 Site-B 的成员从 AD 站点角度没问题但从 DNS 子网掩码排序角度看掩码 16 比掩码 24 要宽得多可能导致不同 VLAN 的客户端解析同一个 DC 时DNS 服务器无法区分“更精确”的子网返回结果变成多条记录的随机顺序。调整策略是站点内子网对象必须按实际 VLAN 精确创建比如 10.20.10.0/24、10.20.20.0/24、10.20.30.0/24 各自建一个子网对象全部关联到 Site-B。不要为了省事用一个大的超网掩码。AD 站点支持子网对象集合多建几条没有性能负担但能极大提升定位精确度。DNS 子网掩码排序是针对 IP 地址“前缀长度”自动计算的AD 站点子网的精确度越高客户端解析 DC 的 A 记录时越容易匹配到同网段地址。5.3 实操喀呑子网掩码排序调整与多宿主 DC 的 A 记录管理要调整 DNS 子网掩码排序需要打开 DNS 管理器定位到对应的 DNS 服务器右键属性切到“高级”选项卡。这里可以看到“启用子网掩码排序”选项默认是勾选状态。这个功能建议保持开启因为多站点环境下它反而能帮你把客户端引导到最近 DC。真正需要“手动干预”的地方往往不是在 DNS 服务器属性里关掉它而是要去检查区域内到底注册了哪些 A 记录。像 DC03 这种有多个 IP 的服务器如果启用了多宿主网卡注册它可能会把多个网卡的 IP 全部注册到 DNS 区域导致排序混乱。实操中我建议做几个操作对 DC 服务器网卡的 DNS 高级设置里关掉“在 DNS 中注册此连接的地址”的多余网卡注册只保留业务网卡。如果历史遗留下了多余 A 记录直接在 DNS 管理器中“删除过时记录”或者用 dnscmd 清理dnscmd DC01 /enumrecords corp.local dc dnscmd DC01 /recorddelete corp.local dc03 /A /f确保域控的当前站点与自身 IP 子网匹配可以用以下命令查看客户端视角nltest /dsgetsite如果返回“DsGetSiteName failed”或站点名不正确说明子网对象和客户端 IP 的映射出了问题优先去“Active Directory 站点和服务”里核对子网。5.4 客户端站点识别验证nltest /dsgetsite /sc_verify所有配置完成后需要在客户端测试站点识别是否正常。先找一台北京和上海的客户端分别执行nltest /dsgetsite北京客户端应该返回 Site-A上海客户端返回 Site-B。如果上海客户端返回的是 Site-A说明 AD 子网没映射好。再看下 DNS 解析结果nslookup corp.local 10.20.0.13如果客户端配置的 DNS 指向上海 DC03但解析结果返回了北京 DC01 的 10.10.0.11而上海 DC03 的 A 记录也存在那就是 DNS 子网排序没有正确把它放在前面。这时优先检查 DNS 区域里 DC01/DC03 的 A 记录是否都存在于各自站点并确认“启用子网掩码排序”为勾选。我实际调试时遇到过一种情况客户端 DNS 指向上海 DC03但 nslookup corp.local 时返回了两个 IP第一个是北京地址。后来发现是 DC03 本地 DNS 区域里一条“父域的 DC 定位记录”恰好把北京地址排在了前面并且“启用子网掩码排序”不知道被哪个管理员关掉了。勾选回来后上海客户端五分钟内恢复优先解析 DC03。6. 常见故障与排查经验6.1 客户端跨站点登录慢的排查思路多站点环境最典型的故障现象是上海用户登录域时感觉很慢甚至有时候会卡在“正在加载用户配置文件”需要十几秒才进桌面。排查顺序我建议先看客户端定位到哪台 DCnltest /dsgetdc:corp.local如果返回的 DC 是北京地址那就是站点定位出了问题。常见原因有几个可能原因判断方法解决方法AD 站点子网未精确匹配客户端 IP 和 AD 子网对象不一致在站点和服务里新建/调整子网对象DNS 子网排序被关闭DNS 服务器属性-高级里未勾选勾选“启用子网掩码排序”DC 的 SRV 记录站点属性不对dcdiag /test:ridmanager /test:replications修改 NTDS Settings 的站点归属客户端缓存了错误的 DCcmd /c ipconfig /flushdns nltest /sc_reset:corp.local清缓存并重置安全通道6.2 站点内 DC 修复后 SRV 记录不更新一次重启 DC03 后发现上海客户端开始报“找不到域控制器”的错。检查 nslookup 里_ldap._tcp.dc._msdcs.corp.local的记录发现 DC03 的 SRV 记录不见了。这种问题一般是 Netlogon 服务未正常注册 SRV 记录导致的。解决办法是重启 Netlogon 或手动触发注册net stop netlogon net start netlogon如果还不行就把区域里对应的 SRV 记录手动删掉重建。但注意 SRV 记录有站点特定版本比如_ldap._tcp.Site-B._sites.dc._msdcs.corp.local这种带站点名的记录是客户端做站点定位的核心如果缺失客户端可能无法发现上海 DC 属于 Site-B。6.3 多宿主 DC 的 A 记录混乱与清理多次加域/退域、多网卡服务器最容易留下 A 记录垃圾。比如 DC03 之前配置临时 IP 注册过 10.20.0.100后来又改成 10.20.0.13DNS 区域里还残留 100 的地址导致客户端网络里偶尔解析出一个不可达 IP。清理时不要单独删 A 记录要连同对应的反向查找区域记录一起清理。检查反向区域 20.10.in-addr.arpa 下有没有多余的 PTRdnscmd DC03 /enumrecords 20.10.in-addr.arpa . 100 dnscmd DC03 /recorddelete 20.10.in-addr.arpa 100 /PTR /f清理完后建议重启一下 DNS 和 Netlogon 服务让所有记录按当前真实状态重新注册。我还要特别提醒一个经验多站点环境里不要轻易“整站删除”再重建站点尤其当某些用户计算机对象已经被分配到站点下时删站会导致客户端的定位信息失效。如果一定要调整先确认所有站点内服务器已迁移或下线再操作删除。写在最后的一些实操体会这套配置做完之后我最想强调的还是“子网掩码的精确度”这件事。很多人做单域多站点站点拓扑、复制链路都搭得很顺利最后却败在子网掩码定义太粗糙上导致客户端总被 DNS 排序导到远端的 DC登录慢不说专线流量也被白白消耗。我个人已经养成一个习惯任何多站点项目开始搭建前先在实验环境里把所有 VLAN 子网对象精确建好再逐项对照客户端 IP 做一遍nltest /dsgetsite验证确认每个站点都返回预期结果后再进生产环境操作。DNS 子网掩码排序这个默认开启的选项看起来不起眼其实是整个多站点定位逻辑里最关键的一个开关出了问题优先检查它。另外最后一个小技巧如果客户端已经产生 DC 定位缓存改完 DNS 或站点配置后可以通过nltest /sc_reset:域名称强制刷新安全通道能明显缩短“配置生效”的等待时间。这个命令排查问题时几乎必用建议记住。