做域控运维的这些年“同步域控中的所有内容”这句话我几乎每隔几天就会听到一次。有人想的是在新加的域控上把全公司用户和组一次性拉齐有人是发现同事改了组策略在某台域控上死活不生效还有人干脆把同步当成万能药以为敲一条命令就能让整片森林立刻数据一致。但同样是这句话背后对应的动作完全不同。以我的经验“同步域控中的所有内容”至少包含四块AD目录自身的副本、SYSVOL里的组策略与脚本、AD集成DNS区域以及域内时间源的对齐。这几块的同步机制、排查方法和命令都不一样。下面我按实操顺序把这件事摊开讲涉及的命令都是我现在仍在用的适合负责域控环境运维、开发和排障的同学参考。1. 同步对象先摆正域控里到底有哪几份数据很多人一提到域控同步脑袋里只有一个模糊的“把A服务器上的数据复制到B服务器”。这个说法不是全错但域控环境里的“数据”分了好几种每种数据的复制逻辑和传播范围都不一样。如果在动手之前没摆正对象后面很容易出现“用户是同步了但组策略没有对象是同步了但DNS解析还是旧的”这样的半吊子状态。1.1 AD目录副本三个命名上下文复制范围各不相同AD数据库本质上是目录服务它内部按照“命名上下文”组织数据。最常见的是三个架构Schema、配置Configuration和域Domain。架构分区保存对象类定义和属性定义配置分区保存站点、域、命名上下文这些逻辑结构域分区保存用户、组、计算机等实际业务对象。复制的范围取决于分区类型。架构和配置分区是全森林级别的也就是说森林里任何一个域控制器上的改动会复制到其他所有域控制器。而域分区只在同一个域的域控制器之间复制。一个森林里如果有多个域A域的域分区并不会自动复制到B域的域控制器上除非你启用了全局编录。这个容易被忽略的点现在想起来还是很值得强调。某项目环境里接入了一个多域森林操作人员在新域的域控上找不到老域的某些用户第一反应是“同步坏了”实际上是因为这台域控根本没有启用全局编录。想要全局搜索所有域的对象要把对应域控的角色里勾上全局编录让所有域的域分区以只读副本的形式定向拉过来。1.2 SYSVOL与AD集成DNS对象关联却走不同通道除了AD数据库本身域控还有两个对外服务的“实体数据”SYSVOL共享和DNS区域。SYSVOL是域控上的一个共享目录默认路径通常是C:\Windows\SYSVOL\domain里面装着组策略模板GPT、登录脚本、脚本启动文件这些实实在在的文件夹内容。GPO可以拆成两部分一部分是AD数据库里的组策略容器GPC记录GPO的GUID、版本号另一部分是SYSVOL里的组策略模板GPT存放实际的策略文件。两个部分必须同时复制到位GPO才能真正生效。早期环境用FRS复制SYSVOL后来的环境普遍迁移到DFSR这一点后面单独说。AD集成DNS区域则是把DNS记录放进AD数据库分区里优点是避免每台DNS服务器单独维护一份区域文件记录跟着AD复制走。如果你把域内DNS区域的动态更新和同步问题也归进“同步域控中的所有内容”那要记住DNS记录的复制并不是实时的它会依赖AD复制的节拍查询旧记录的时候照样可能返回过期结果。1.3 别忘了时钟同步之上还有一层“时间血液”时钟和时间同步平时不起眼但它才是整个同步体系的“地基线”。Kerberos 认证要求客户端和服务端时间偏差不能太大通常默认容忍5分钟AD复制本身也要靠时间戳来处理冲突和最后写入者获胜如果两台域控的时间差得离谱复制通信会被直接拒绝日志里出现各种“拒绝”“不支持”的报错。我处理过一起典型的案例新部署的第二台域控怎么同步都报RPC服务器不可用端口通、账号对、网络通查到最后发现新域控的系统时间比现有域控慢了将近10分钟。用w32tm /resync /rediscover校准后复制瞬间恢复正常。所以我在任何同步排查开始前都会先看一眼时间而不是急着敲同步命令。2. 域控同步的引擎是“对账”不是简单拷贝理解同步的对象之后下一个要搞懂的是后台机制。域控同步绝对不是把一份数据整体覆盖到别的机器上它的核心是“增量对账”每台域控都记录自己当前知道哪些变化伙伴之间互相拉取对方比自己新的部分。这个机制决定了你日常能用的操作命令也决定了哪些问题能用同步解决、哪些不能。2.1 USN与高水位标记增量数据怎么追认AD复制用的核心计数器叫做更新序列号USNUpdate Sequence Number由每台域控自己维护。只要本地发生一次写操作无论改的是用户密码还是部门属性本机都会给这次修改分配一个递增的USN并记录下这个变更的元数据。每台接收复制的目标域控也会为每一个复制源伙伴维护一个“高水位标记”。这个标记说白了就是“上次我成功拿到了你到哪个USN为止的全部改动”。下次复制时目标域控对源伙伴说我的高水位停在这里你把这之后的新增USN数据发给我。两边一核对只传需要传的增量。这套对账机制的好处很明显复制流量小带宽占用低即便每天有几百条用户变更同步也只是一小口一小口地追认差异而不是把整个目录来回搬运。这也是为什么你手动发起同步看到的输出往往是“同步完成无待复制对象”而不是全量刷一遍。2.2 冲突仲裁多主复制凭什么不乱套AD是多主复制任何一台域控都可以修改同一批用户对象。如果是单机数据库一个管理员直接改总数多点并发写就是灾难所以AD必须有一套管用的冲突仲裁规则。它的处理原则是“属性级最后写入者获胜”。两个域控在短时间里分别修改了同一个用户的不同属性复制发生时这些属性变更可以各自保留互不影响。如果改的是同一个属性则看时间戳时间新的版本胜出。为了处理时钟接近时的情况还有额外的版本号字段兜底确保仲裁结果是确定性的。理解这个机制后你就不会去干“为了同步而同步”的傻事。比如某台域控离线很久重新上线后复制过来的“旧数据”覆盖了另一台目前在线域控上的新改动。这类问题的管理靠的是“权威还原”或者提前评估哪台域控的数据才是真实源而不是盲目触发一次全量同步一旦方向拉反可能把正确数据盖掉。2.3 KCC的拓扑自动布线别手捅拓扑同步如果不讲究那企业里N台域控互相拉取就是全连接乱联网线不够用。AD的设计思路是让知识一致性检查器KCC自动生成复制拓扑。KCC会定期评估当前每个站点里的域控数量、复制伙伴关系、站点间链接自动产生一套有环冗余的拓扑。站点内默认保证任意两台域控之间最多经过几跳就能同步站点间则通过桥头堡服务器交换数据而不是每台域控都直接建立跨地域连接。这就像快递中心先收件到分拨站再统一转运比每件个人包裹直飞另一个城市要省得多。实际运维中你不需要手工修改KCC生成的连接对象。偶尔有人会为了强制某台DC立即同步而手动新建连接但这类手工连接在KCC下一次重算时有可能会被自动处理反而留下一种“看起来配置了就是好的”错觉。重点是保证KCC正常运行然后根据你的站点和子网定义把网络侧的地图画正确。3. 同步出问题的排查顺序时间、DNS、复制拓扑、积压队列域控同步报错的时候最忌一上来就敲命令拉数据。我踩过太多次“敲了十来分钟命令结果发现根因是时间偏差”的经验也见过同事在DNS记录缺失时反复重启复制服务最终只是把问题变得更乱。现在我的排查顺序非常固定基本能够覆盖大部分同步故障。3.1 第一锤确认时钟源时间偏了同步全停先在一台域控上执行w32tm /query /source w32tm /query /status如果输出的源不是“本地时钟”或另一台上级域控就要留意了。域控之间时间同步的推荐做法是林根域的主域控角色持有者同步外部时间源其余所有域控默认从域层次上游获取时间。最简单的校准命令是w32tm /resync /rediscover在Windows环境中同步服务的客户端模式默认开启网域内的成员域控会自动跟随时间源。如果你的环境里有防火墙拦了UDP 123那即使复制端口全通时间也可能长期漂移。时间偏差一旦超过Kerberos默认阈值所有依赖认证的同步都会报“拒绝访问”或“RPC不可用”非常迷惑人。3.2 第二锤repadmin/replsummary 与 dcdiag 快速定位失败对时间正常后用repadmin做全局面扫描。最容易读的就是复制汇总repadmin /replsummary这条命令会把整个森林的同步状态按域控拉成表格列出成功、失败、失败百分比和积压数量。看到某个目标域控失败率飙高再去把范围缩小到这一台。进一步看复制伙伴关系repadmin /showrepl它会输出当前域控的复制伙伴列表、最近尝试时间、失败时间、失败次数和错误码。我通常把repadmin /showrepl的结果作为定位问题的第二现场因为它能直接告诉我是谁向谁复制最后一次失败是几秒钟前报了什么错误码。如果repadmin /replsummary的输出比较漂亮但你在实际业务里仍觉得不同步再跑一次域控综合诊断dcdiag /test:replications它会对复制相关的关键项做结论性检查明确指出“无法复制”“复制被拒绝”“长时间未复制”等问题。3.3 第三锤事件日志与常见信号归类命令工具给出现象事件日志才给出原因。进入“事件查看器 → 应用程序和服务日志 → Directory Service”集中看Error和Warning级别的事件。常见的复制问题信号可以归类为三类。第一类是拓扑生成类。如果日志中出现KCC无法为某个命名上下文生成完整生成树的事件常见编号比如1311说明KCC计算拓扑失败原因通常是站点配置不完整、桥头堡服务器不可用或子网覆盖缺失这时候需要先解决站点拓扑而不是手动同步。第二类是解析和连接类。日志中反复提示某个域控名称或IP无法解析大概率是AD集成DNS区域里缺少NTDS设置对象的DNS记录。直接用DNS管理工具确认伙伴域控的A记录、CNAME记录和SRV记录是否存在缺失的注册或重新注册。第三类是安全拒绝类。错误提示“复制访问被拒绝”一般指向复制所使用的连接账号被禁用、密码过期、或在系统账户域策略里被限制了从属关系。这类错误尤其容易发生在重装域控或恢复旧虚拟机之后因为机器账户和NTDS设置的安全标识符对不上。3.4 深水区长期脱机导致的残留对象与墓碑风险还有一类问题不在常规排查顺序里但一旦遇上就是大坑。某台域控长时间离线超过墓碑生存期后再重新上线它数据库里仍然保存着一些已经被AD标记为删除并剪除的对象。这些对象在同步时会被当作“残留对象”导致复制行为异常或报错。这类情况用普通同步命令是修不好的。思路是联系在线域控把这台离线段上存在的残留对象清理干净。微软也提供类似移除残留对象的工具性能力可以通过repadmin /removelingeringobjects处理但执行前要谨慎评估参数方向避免误删正常对象。说句实在话遇到这种情况最稳妥的方案往往是直接退域、重建这台域控再做元数据清理成本往往比在旧机器上反复抢救要低。4. 手动触发同步的操作清单repadmin 参数逐项拆解正常情况下AD复制是自动进行的不需要人为干预。但“一切正常”不等于“永远不需要手动”。新建域控进入生产环境后为了尽快让它在短时间内拿到全量数据我们会主动触发一次同步排查过程中为了验证网络和账号连通性也会手动拉一次。手动同步的入口几乎都集中在repadmin上。4.1 第一板斧 repadmin /syncall /AdeP到底做了什么域控同步圈里最广为人知的命令大概就是这一条repadmin /syncall /AdeP我一般在当前域控上执行它会做几件事/A 表示同步所有目录分区/d 配合 /A 表示只同步目录分区/e 把同步范围扩展到整个企业森林/P 表示由当前域控向所有复制伙伴主动推送数据。如果只想安静地等结果加上 /q。这条命令跑完后屏幕会逐条列出向哪些伙伴、哪个分区进行了同步。输出的初衷是让你看到每一条连接的状态所以信息量偏大看重点不是“输出越长越好”而是末尾有没有“成功完成的同步请求”以及有没有伴随错误码。需要提醒的是/AdeP并不是“重新复制整个AD数据库”它仍然基于现有的高水位机制拉增量。只是在拓扑变大、连接很多时它能把这些增量请求一次性全部发出去提高同步效率。4.2 分区级与伙伴级同步从全局到单点的粒度控制有时候全量同步太吵而且会惊动一大堆不需要连接的伙伴。这时可以把操作缩小到“某个分区”或“某个伙伴”。用repadmin /syncall加上指定分区名可以只同步域分区此时命令的大致形式是先把视图罗列出来再针对分区执行同步请求。如果要对着某一个具体伙伴来同步可以先看repadmin /showrepl输出里的伙伴标识再同步指定目标。实际场景中用的较多的反而是“域控间两两同步”repadmin /syncall DC2 /AdeP这个写法指的是“当前这台域控以DC2为同步目标把相关分区同步过去”。理解这一点很重要因为AD里的方向是有语义的。你总是希望“源持最新数据的一方把数据拉向需要补数据的一方”如果拉反方向相当于用旧的增量尝试覆盖新的数据轻则无变化重则把版本向量搞得一团糟。4.3 脚本化触发同步与失败重试手动命令适合排障但要想让同步可靠还是要让命令能编排、能量化。我习惯把同步触发做成一个小脚本先探测所有域控再逐个执行同步。比如用 PowerShell 拿到域内所有域控制器列表$dcs Get-ADDomainController -Filter * foreach ($dc in $dcs) { repadmin /syncall $dc.HostName /AdeP /q }这只是最简版实际项目里建议把日志重定向到文件同时在命令完成后读取$LASTEXITCODE判断成功与否再将结果写入统一的日志目录。这样第二天巡检翻日志时一眼就能看到哪台域控曾经出现过同步失败。4.4 “全量同步”的边界别把增量复制神话成重置键我要专门泼一盆冷水很多人在“同步不了”的时候期望用强制同步来解决一切但强制同步不是万能重置键。AD复制的底层是增量对账如果源端数据本身已经损坏、伙伴关系被破坏、或者长时间未复制的状态已经越过墓碑周期单纯触发同步并不能让目标域控“重新认识”一台源域控。真正意义上的全量初始化通常出现在“重新加入域控”“删除并重建复制伙伴关系”“恢复系统状态备份”这些场景里。普通在线域控之间的“全量同步”更多只是“把所有分区的待复制对象一次性请求完成”而不是把整本数据库推倒重铺。因此在遇到深层次异常之前不要迷信命令先把根因查清楚。5. SYSVOL的同步坑位最密集组策略和登录脚本在这里如果要在域控同步的维护主题里挑一个最容易出幺蛾子的点我会选SYSVOL。原因很现实AD数据库部分一旦出问题报错往往非常显眼日志会明确指出来而SYSVOL出了问题表现可能只是“这台域控的组策略不生效”“登录脚本时有时没有”让人很难第一眼联想到同步。5.1 先判断SYSVOL是否同步成功共享、日志、DFSR状态三件套我接到SYSVOL相关的同步问题第一件事永远是看三样东西。第一共享是否发布成功。在域控上执行net share正常情况下应该能看到SYSVOL共享路径指向C:\Windows\SYSVOL\sysvol下的域名目录。如果共享不存在说明这台域控的SYSVOL初始化还没有完成自然不可能参与同步。第二DFSR服务是否在运行。用Get-Service DFRSDFSR是当前Windows Server主流环境里负责复制SYSVOL组策略模板副本的服务。如果服务停止同步一定中断。第三看事件日志中有关DFSR的记录。DFSR 在运行到某个稳定状态后会周期产生同步健康相关事件。如果事件日志一直反复提示伙伴不可达、接入失败或初始同步未完成就要对状态进行深挖。5.2 常见的SYSVOL滞后根因与修复路径从经验看SYSVOL不同步的根因集中在三个方向。第一个是Dc整体复制链路故障。SYSVOL依赖AD整体的连接对象和站点拓扑如果主复制链路本身有问题SYSVOL的DFSR同样走不通。因此排查SYSVOL之前我仍然会先跑一遍repadmin /showrepl确保AD复制没有大问题。第二个是DNS解析异常。DFSR复制伙伴之间靠DNS解析对方全名如果某台域控的DNS记录没注册DFSR可能一直找不到目标。处理办法是确认该域控的网络并重置其DNS注册。第三个是老环境迁移不彻底。历史遗留环境中有的域控还在用早期文件复制服务FRS有的已经迁移到DFSR两套机制之间的状态就会出现“每个域控各自为政”。这时候不要自己手忙脚乱去操作建议基于可靠环境下检查功能级别确认同域所有域控是否都进入同一套复制机制。5.3 GPO的“面”与“里”容器对象和模板文件要一条心GPO是AD对象与SYSVOL文件的“混合体”这也是同步时最隐蔽的坑。组策略容器GPC在AD域分区里复制组策略模板GPT在SYSVOL目录里复制两边都有版本号字段。域控在应用组策略时会同时读取这两个副本的信息比较内部版本号。如果两边不一致客户端往往会取到不完整的策略呈现为“策略未更新”“某条设置未生效”等模糊现象。验证方法并不复杂。在新建或修改GPO之后等复制周期完成到另一台域控上打开组策略管理确认GPO状态正常再打开SYSVOL里对应的策略文件夹看版本文件中的版本号与AD侧是否递增一致。跨域控验证GPO版本的时候可以借助此方法确认“面”和“里”都同步到位。6. 同步完成后的自证验证顺序和常态化巡检同步动作做完之后不能凭感觉“应该是OK了”就收工。域控同步这件事结果必须可验证而且要能长期验证。我自己在做完任何一次主动同步后至少会完成三个层次的检查。6.1 复制延迟、队列长度与失败计数的三张报告第一层看的是“复制本身是否健康”。用以下命令组合快速拉出结论repadmin /replsummary repadmin /showqueue/replsummary看宏观失败率/showqueue看某一台域控当前复制队列里还堆积着多少条待复制对象。如果队列长度长时间不为零说明它一直在努力追但追不上要顺着源伙伴往下细查。repadmin /showrepl则能看每一个伙伴连接的最后成功与最后失败时间这个输出是我最常留档的证据。6.2 对象级一致性抽查用一个小脚本做跨DC对比报告级检查只能说明复制链路本身是通的不能直接证明“某个对象已经出现在所有域控上”。因此真正要自证“同步域控中的所有内容”我会做一次对象计数对比。简单脚本示例$dcs Get-ADDomainController -Filter * foreach ($dc in $dcs) { $count (Get-ADObject -Filter * -Server $dc.HostName -SearchBase (Get-ADDomain).DistinguishedName).Count [PSCustomObject]{ DC $dc.Name; ObjectCount $count } }这个脚本的效率不算高只适合做抽样验证而非高频任务。我一般是在做重大项目变更或者新域控上线后用它做一次“全量对象数量对齐”各域控之间的总数差异在个位数以内就可以接受。如果差异很大再按对象类型细分比如用户、计算机、组别单独对比。6.3 我的日常巡检习惯固化“同步健康”为周任务同步故障最怕的不是出问题而是出了问题没人知道。AD复制通常是静默的一旦队列持续积压往往是在用户开始抱怨“策略不生效、账号不统一、地址解析不对”时才被发现。为了避免这种被动我把同步健康检查固化成了每周任务。每周固定时间跑一次repadmin /replsummary把结果追加到一个日志文件里再跑一次dcdiag /test:replications无错误则通过。脚本发现失败记录时自动把前一天的事件日志摘要写入额外告警目录。这个动作本身并不重几分钟搞定但能把很多“还没变成故障”的异常提前暴露出来。最后再分享一个小习惯。每次做手动同步前我都把时间和DNS状态先拍一张“快照”w32tm /query /status ipconfig /displaydns同步结束后再对照一次。如果同步前后连时间和解析都变了那说明底层地基本来就没稳。先把这两个干净再来谈“同步域控中的所有内容”事半而功倍。
