1. SYSVOL复制失败到底是怎么回事如果你管理的是一套以Windows Server 2012为核心的域环境你一定经历过这种让人抓狂的故障dcdiag跑完AD复制显示正常域控之间也能互相解析但某台域控上的组策略就是不刷新登录脚本时灵时不灵客户端登录后GPO应用一半就报错。折腾半天最后发现问题出在SYSVOL复制上。SYSVOL是域控上一个非常特殊又非常脆弱的目录它承载着组策略模板、登录脚本、脚本策略等基础数据。客户端登录时能不能拿到正确的策略完全取决于每台域控上的SYSVOL是否一致。Windows Server 2012默认使用DFSR分布式文件系统复制来复制SYSVOL但如果环境是从2003或2008升级过来的或者中间有人做过不规范的还原操作SYSVOL复制失败的概率会明显上升。这篇文章我尽量把排查思路和恢复手段讲透新手能照着做老手也可以当一份速查手册用。1.1 SYSVOL里装的是什么很多人一提SYSVOL就只知道“组策略”但里面其实不止GPO。一个典型的Windows Server 2012域控SYSVOL目录结构大概是这样的C:\Windows\SYSVOL\domain ├─ Policies按GUID命名的组策略对象 ├─ Scripts登录脚本、开机脚本 └─ DO_NOT_REMOVE_NtFrs_Prevent_Move占位标记文件Policies目录是重灾区。每个GPO一个子目录里面是GPT.INI、Machine、User等配置文件。客户端通过“域控上的SYSVOL共享”读取这些文件路径一般是\域\SYSVOL\域\Policies{GUID}\Machine\registry.pol。一旦SYSVOL复制失败不同DC上的GPO版本就会不一致客户端刚好连到落后DC就会应用旧策略或者报“找不到文件”。Scripts目录存放登录脚本、启动脚本、组策略首选项引用的脚本文件。这个目录如果复制失败表现更隐蔽——Admin中心改完脚本保存了但客户端执行的还是旧版本因为连到了没同步到新脚本的那台DC。DO_NOT_REMOVE_NtFrs_Prevent_Move这个占位文件是迁移残留的痕迹说明这台机器曾经使用过FRS复制。正常情况下这个文件不应该被删除我见过有人“清理”它导致SYSVOL复制直接停摆。1.2 从FRS到DFSR2012默认走哪条路Windows 2000和2003时代SYSVOL复制靠的是NTFRS服务也就是FRS文件复制服务。FRS对大量小文件的复制效率很低而且容易出“JRNL_WRAP_ERROR”这类日志包装故障一卡就是几天。从Windows Server 2008开始微软引入了DFSR用于SYSVOL复制但为了兼容老环境默认并不强制启用。真正把DFSR设为SYSVOL首选复制引擎是在Windows Server 2008 R2和2012时代逐步推开的。Windows Server 2012全新安装的域控SYSVOL复制直接走DFSR已经看不到NTFRS服务在跑。但如果你是老版本域升级上来的SYSVOL复制可能还在FRS状态或者正处于“迁移中间态”。这种混合状态特别容易复制失败。出现故障时第一件事不是急着删数据而是确认当前SYSVOL复制到底用的哪套引擎。DFS Replication服务就是DFSR的执行体NTFRS服务是FRS的执行体。两台服务可以同时存在但SYSVOL同一时间只能挂在一个复制引擎下。如果一台DC还在FRS另一台已经迁移到DFSR两边根本无法正常同步。1.3 复制失败会带来什么后果SYSVOL复制失败的典型表现是“AD健康但GPO乱”。因为AD复制和SYSVOL复制是两套独立机制AD数据库由NTDS服务负责SYSVOL由FRS或DFSR负责。AD复制正常不代表SYSVOL正常。很多时候你查dcdiag只能看到AD层面没问题于是下意识排除域控故障转而去查客户端、网络、权限绕一大圈才回来。复制失败时间短的话客户端可能只是偶尔应用旧策略。时间长了某台DC上的SYSVOL内容越来越旧甚至为空。更严重的是如果盲目在一台“没有完整策略”的DC上做权威同步会把这个不完整的SYSVOL推给所有DC导致全公司组策略大面积丢失。这个风险一定要提前知道。另外SYSVOL一旦有大面积不一致域控之间的信任关系、DFS命名空间、某些依赖GPO的安全设置都会出问题。比如域内密码策略、账户锁定策略、防火墙规则等全是靠GPO下发到客户端的客户端连到落后DC就拿到了旧规则。所以SYSVOL复制失败不只是“技术问题”而是直接影响业务安全的问题。2. 先确认症状哪些现象说明SYSVOL复制出了问题2.1 现象清单不能只看“日志红色”我处理过的SYSVOL故障里最常见的现场是“事件查看器里有大量错误但所有服务都在运行”。所以别一看服务启动就认为没事。下面这些现象只要中了两条以上就该把SYSVOL复制列为头号嫌疑同一台DC上dcdiag /test:replications通过但系统日志里有DFS Replication或NtFrs错误。客户端登录后组策略应用报错事件ID指向“无法访问策略目录”或“未能找到文件”。在DC本机打开组策略管理发现某些GPO“状态为空”或“访问被拒绝”。不同DC上执行gpresult /r同一个用户的策略结果差异很大。登录脚本在部分客户端正常在另一部分客户端完全不生效。SYSVOL共享目录无法访问或者访问后目录列表是空的。事件查看器中反复出现“SYSVOL has not been replicated”或“DFSR is waiting to perform initial replication”。这些信号叠加在一起基本可以断定SYSVOL复制已经不正常了。接下来要用工具把状态量化出来。2.2 用三条命令快速摸清复制状态我习惯在可疑DC上先跑三条命令信息量最大速度也最快。第一条是看服务状态net start | findstr /i DFS NtFrs正常情况下应该能看到“DFS Replication”在运行。如果同时看到“File Replication Service”说明这台机器还在使用FRS复制SYSVOL也可能是FRS服务残留且被启动这时候要赶紧确认迁移状态。第二条是看AD复制摘要repadmin /replsummary这条命令会列出所有复制邻居的失败情况。如果AD复制有大量失败SYSVOL复制大概率也不稳因为SYSVOL的数据源毕竟是每台DC。不过这里要强调repadmin正常不代表SYSVOL正常它只是排查的起点。第三条是看DFSR复制状态dfsrdiag /replstate /v这条命令会输出复制组和复制文件夹的状态能看到“Initialized”是否成功、是否有积压、复制方向是否健康。如果状态里出现“JRNL_WRAP_ERROR”或者“ERROR”那基本可以确定复制引擎已经卡死。如果你的域控还在用FRS对应的命令是“ntfrsutl ds”和“ntfrsutl inlog”能看到FRS的数据库和日志状态。2.3 事件ID速查DFSR和NTFRS都要看事件查看器是最直接的线索来源。Windows Server 2012上DFSR的事件日志叫“DFS Replication”FRS的事件日志叫“File Replication Service”。我整理了几个高频事件ID遇到它们基本可以快速定位方向。日志源事件ID含义处理方向DFS Replication4002DFSR服务停止或无法启动检查服务、依赖、磁盘权限DFS Replication4012USN日志回滚或包装非权威同步/权威同步DFS Replication2213暂存区空间不足清理暂存区、调整大小DFS Replication5002复制组配置错误检查AD中的复制组对象DFS Replication5012与AD的连接中断检查AD复制File Replication Service13508/13509FRS无法与伙伴通信检查FRS是否已停止使用File Replication Service13562日志包装非权威恢复FRS或在迁移前提下强制转DFSRNTDS Replication2042太久未复制USN回滚联系AD恢复可能需要清理元数据其中DFS Replication 4012这个事件最要命。它通常提示“日志已回滚”或“USN日志已被删除”说明这台DC的NTFS USN日志出了问题。出现4012后DFSR往往无法继续复制SYSVOL必须人工介入做恢复。3. 定位底层原因USN回滚、日志包装还是迁移残留3.1 区别三类故障方向SYSVOL复制失败不是单一原因常见的有三类处理方法完全不同第一类是“USN回滚”通常因为域控被恢复到旧快照或旧备份导致AD和NTFS日志回退DFSR无法判断增量。第二类是“日志包装”也就是JRNL_WRAP_ERRORNTFS USN日志被覆盖DFSR丢掉了增量变化的记录只能做非权威同步。第三类是“迁移残留”SYSVOL还在用FRS复制状态已经坏掉或者FRS/DFSR配置混杂两边都不干活。这三类问题表面症状很像都是“复制不成功”但解决路径南辕北辙。如果看到4012就盲目执行权威同步很容易把整条复制链打崩。所以先要花几分钟区分类型。3.2 USN回滚的判定与成因USN回滚这个名词听起来很硬核其实原理不复杂。NTFS每个卷上维护了一个USN日志用来记录文件变动DFSR靠它判断“哪些文件需要复制”。一旦域控被恢复到旧快照USN日志里的序号比AD数据库里的序号小AD和DFSR都会认为“本身数据比域内新”从而拒绝接受其他DC的数据。判定USN回滚最直接的方法是看事件日志。DFS Replication日志里出现4012同时NTDS Replication日志里出现2095或2042基本上就可以锁定USN回滚。再用repadmin /showrepl看复制状态通常会看到“too recently attempted”或“waiting to replicate”这类提示。USN回滚的成因基本都是人为恢复操作导致的比如虚拟化平台直接把域控虚拟机回滚到几天前的快照或者物理机用旧备份做过还原。Windows Server 2012虽然支持虚拟机快照但对域控来讲快照回滚永远是高风险操作。正常备份域控应该用系统状态备份而不是快照回滚。3.3 JRNL_WRAP_ERROR为什么会把DFSR卡死JRNL_WRAP_ERROR翻译成“日志包装错误”确实不太好懂。打个比方USN日志就像一个循环录像带如果写入太快或者日志设置太小新数据会把旧数据覆盖掉。DFSR还在按旧序号找增量记录结果发现记录已经被覆盖就会报JRNL_WRAP_ERROR。这个错误在FRS时代非常出名DFSR下相对少见但一旦出现表现比FRS还难缠。dfsr状态会停留在“Initialized: False”复制组显示错误事件日志频繁报4012或4010。磁盘I/O压力大、卷上文件数量特别多、防病毒软件频繁扫描都可能诱发这个问题。处理办法只有一个放弃当前增量状态做非权威同步。3.4 迁移残留FRS和DFSR同时存在怎么查Windows Server 2012域控如果是从2003/2008升级来的SYSVOL可能还在FRS复制状态。这种情况下你可能看到NTFRS服务在运行同时DFSR事件日志里又空荡荡的。要查看SYSVOL复制引擎的迁移状态用微软提供的FRS迁移工具最省事dfsrmig /getglobalstate dfsrmig /getlocalstate全局状态和本地状态的结果有0到3四个值0开始状态SYSVOL使用FRS1准备状态FRS开始为迁移做准备2重定向状态SYSVOL已经重定向到DFSR3已消除状态FRS彻底退出SYSVOL完全由DFSR管理如果全局状态是2本地状态却是0或1说明这台DC的迁移没跟上。这时候SYSVOL复制很可能卡死域内部分DC用DFSR部分DC还在FRS两边互不通信。怎么办最简单的方案是把迁移状态推进到3命令是dfsrmig /setglobalstate 3但注意执行前必须确认所有DC都已准备好至少本地状态都到了2。如果有DC一直卡在0或1要先检查那台DC的FRS服务是否正常、事件日志里有没有复制错误。强行拉状态可能把其他DC也弄坏。4. 恢复操作从非权威同步到权威同步4.1 恢复前必须搞清的两个概念处理SYSVOL复制失败绕不开两个词权威和非权威。很多新手一听到“权威”就以为是好东西实际恰恰相反权威恢复是高风险操作用错方向会毁掉整个SYSVOL。非权威同步的意思是这台DC上的SYSVOL数据不信任启动后从别的DC拉取完整数据。绝大多数故障场景都适合先做非权威同步。权威同步的意思是把某台DC上的SYSVOL数据当成“标准答案”强制推送给其他所有DC。除非你能百分之百确认这台DC的数据是完整且正确的否则不要轻易做权威同步。我见过最惨的案例是有人在故障DC上顺手做了个“权威恢复”结果把一份只有三个GPO的空SYSVOL推给整个域全网组策略全部丢失最后只能靠备份恢复AD重新生成GPO。所以下面所有操作我都建议优先走非权威方向。4.2 非权威同步实操故障DC拉取数据这里给出我实际用过的、比较稳妥的非权威同步流程。假设故障DC是DC02健康DC是DC01所有命令在DC02上以管理员身份执行。第一步停止DFSR服务net stop dfsr如果服务已经卡死用强制参数net stop dfsr /y第二步把当前SYSVOL里的Policies和Scripts目录改名备份。注意不是删除是改名万一后面要回滚还能用cd C:\Windows\SYSVOL\domain ren Policies Policies.old ren Scripts Scripts.old这里要特别提醒只改Policies和Scripts不要动DO_NOT_REMOVE_NtFrs_Prevent_Move也不要去改sysvol下的目录连接。整个SYSVOL共享依赖目录结构改多了容易出现共享丢失。第三步清理DFSR本地数据库。DFSR的数据库位于“C:\System Volume Information\DFSR”目录下里面有以database_XXX命名的子目录。执行dir C:\System Volume Information\DFSR确认后把整个DFSR目录改名备份cd C:\System Volume Information ren DFSR DFSR.old这个目录里存放的是DFSR的本地复制状态和数据库改名后DFSR会认为这是一台“从未初始化”的机器启动后必然从伙伴拉数据。第四步启动DFSR服务net start dfsr启动后DFSR会进入初始同步状态从配置的入站连接伙伴拉取SYSVOL数据。这个过程中Policies和Scripts目录会自动生成内容逐步补齐。查看状态用dfsrdiag /replstate /v第五步验证SYSVOL共享是否正常net share正常情况下能看到SYSVOL和NETLOGON共享。如果没有检查C:\Windows\SYSVOL\sysvol下是否有域名文件夹或重启一下NetLogon服务net stop netlogon net start netlogon4.3 等效权威同步用健康DC向外推送如果故障DC执行非权威同步后数据能拉过来但发现数据本身是旧的或者健康DC上的内容才是最新最全的就需要把健康DC的数据推给其他DC。这时候我不建议直接改注册表做“官方权威恢复”因为注册表路径涉及复制组GUID操作错了很难收拾。我更推荐下面这种“等效权威同步”的思路安全性高很多。假设DC01数据完整DC02是故障机。先把DC01的DFSR服务停掉做一个短暂的“只推不拉”让DC01只作为来源net stop dfsr在DC01上确认SYSVOL数据完整同时检查C:\Windows\SYSVOL\domain\Policies和Scripts目录都在。然后启动DFSRnet start dfsr回到DC02按4.2的流程把Policies和Scripts改名为.old再把DFSR数据库目录改名最后启动DFSR。这样DC02会强制从DC01拉取完整SYSVOL。等DC02同步完成SYSVOL内容就和DC01一致了。这本质上就是“以DC01为权威DC02做非权威”的恢复路径绕开了注册表操作对新手更友好。如果域内有多台DC记得等这台恢复完成后再逐台处理下一台。4.4 恢复后的验证步骤恢复操作做完不能只看服务启动了就算完事。我建议至少做四项验证第一项看复制状态dfsrdiag /replstate /v确认输出里没有“ERROR”字样初始化状态为“Initialized”。第二项看是否有事件错误。清空DFS Replication日志后等10到20分钟再看看是否有新错误。正常情况下只有信息级别的事件。第三项对比DC01和DC02上的Policies目录数量和文件robocopy C:\Windows\SYSVOL\domain\Policies \DC02\SYSVOL\域\Policies /L /R:0 /W:0用robocopy的“仅列表”模式对比或者直接在文件管理器里看GPO数量。不要求文件顺序一致但GUID目录数量和关键文件必须一致。第四项在客户端上强制刷新组策略gpupdate /force登录一台测试机确认组策略能正常应用登录脚本能执行。这一步才是最终验收。5. 多台DC同时异常时的处理套路5.1 先找一台“相对健康”的DC多台DC同时出问题最忌讳的就是慌。我的经验是先不要碰任何DC停下手来从所有域控里挑出一台“最可信”的DC。判断标准很简单谁的事件日志里错误最少谁的SYSVOL目录内容看上去最完整谁和客户端交互正常就选谁。选定后在这台DC上先做数据备份。最简单的方式是把SYSVOL\domain\Policies和Scripts目录复制一份到本地其他磁盘robocopy C:\Windows\SYSVOL\domain\Policies D:\SYSVOL_Backup\Policies /E robocopy C:\Windows\SYSVOL\domain\Scripts D:\SYSVOL_Backup\Scripts /E如果这台DC本身也有复制错误也不用担心先把它定为“主要参考源”后面逐台恢复时以它为准。备份完成之前绝对不要动其他DC。5.2 逐台恢复而不是同时强拉多台故障DC的情况下很多人会想着“我给所有DC同时做非权威同步让它们互相拉数据”这是大忌。多台DC同时处于初始同步状态时它们会互相竞争权威源甚至因为时间戳不一致导致数据互相覆盖越同步越乱。正确做法是主从式恢复。以5.1选出的DC为“主”先把其他故障DC逐台按非权威同步流程恢复每恢复一台就验证一台的复制状态。恢复顺序上优先处理SYSVOL数据相对最新、和业务关联最紧密的DC。最后再回头看主DC是否需要重新初始化。如果主DC本身也有USN回滚但SYSVOL目录内容完整可以尝试先做主DC的DFSR数据库清理让它以“本地数据为基准”重新初始化。操作和4.2类似只是不需要改名Policies和Scripts只改名DFSR数据库目录。这样主DC会保留本地完整数据重新生成复制状态然后其他DC再从它这里同步。5.3 灾难场景所有DC都脏了怎么办最麻烦的情况是所有DC的SYSVOL都是残缺的连一份完整数据都找不到。这时候只能靠备份了。Windows Server 2012的系统状态备份里包含SYSVOL和AD数据库如果有最近的系统状态备份优先还原一台DC然后让它作为权威源推给其他DC。如果没有备份也不是完全没救。还有一个思路从客户端角度反推。找一台长时间正常应用组策略、且本地缓存里有完整GPO的客户端把%SystemRoot%\System32\GroupPolicy目录下的数据提取出来结合域内实际使用的GPO清单手工重建一套相对完整的SYSVOL。这个方法工作量很大而且容易遗漏关键GPO只建议作为最后一个保命手段。我在实际运维中见过一次没有备份的灾难场景最后是靠“域内所有客户端登录脚本的历史版本”和“组策略管理控制台中的GPO列表”一点一点拼回大部分策略的。业务影响非常大整个恢复过程持续了两天。所以平时一定提醒你域控的备份优先级要高于普通服务器而且备份要定期做恢复演练。6. 避坑清单与日常防护6.1 我踩过的几个坑处理SYSVOL复制失败这几年我自己踩过不少坑也帮别人收拾过不少烂摊子。第一个坑是“把FRS和DFSR搞混”。有一台2012域控升级后SYSVOL还在FRS状态我一直按DFSR的方式查白白浪费了半天。现在我会先跑一条dfsrmig /getglobalstate确认当前复制引擎。第二个坑是“恢复前不做备份”。有一次我直接清理了故障DC的SYSVOL数据结果发现健康DC的数据也不完整想回滚都没得回。从那以后我做任何SYSVOL操作前都会先把故障DC的现有数据备份到独立磁盘成本很低但关键时刻能救命。第三个坑是“做完非权威同步就忘了检查NetLogon共享”。DFSR把数据同步过来了但NetLogon共享没有自动恢复客户端还是无法执行登录脚本。这是因为NetLogon服务需要额外触发。现在我的收尾清单里一定包含“net share检查”和“重启NetLogon服务”这两步。第四个坑是“权威和备份方向搞反”。有人从备份软件里恢复了某台DC的SYSVOL恢复完成后又顺手做了“权威同步”结果把恢复出来的旧GPO推给了所有DC。正确做法是从备份恢复的DC先做一次非权威同步确认数据比伙伴新时再考虑是否做权威推送。6.2 日常巡检与备份建议SYSVOL复制这种问题最好的处理方式是在它还只是“日志里一条警告”的时候就发现。我给客户做的日常巡检清单里主要有这几项每周检查所有域控的“DFS Replication”事件日志重点看4012、2213、5012。每月跑一次dfsrdiag /replstate /v确认所有DC的复制状态为“Initialized”。每季度检查一次DFS复制暂存区空间和数据库大小避免日志包装。域控虚拟机的快照策略必须慎用。非域控可以随便快照回滚域控最好只用“备份软件的系统状态备份”不要依赖虚拟机快照作为恢复手段。SYSVOL里的Policies和Scripts目录建议纳入文件服务器备份保留最近90天版本。定期做恢复演练从备份还原一台DC的SYSVOL确认能正常初始化、非权威同步、客户端GPO下发。演练过一次后你心里才有底。最后再分享一个小习惯。每次处理完SYSVOL故障我都会把关键事件ID、执行过的命令、恢复耗时记录在案形成一份“SYSVOL故障处理单”。下次再遇到类似问题直接翻出来照着走能省不少时间。域控这东西稳定运行的时候没人注意一旦出问题就是全局性故障平时多留一手总没错。
Windows Server 2012 SYSVOL复制失败排查与恢复实战指南
1. SYSVOL复制失败到底是怎么回事如果你管理的是一套以Windows Server 2012为核心的域环境你一定经历过这种让人抓狂的故障dcdiag跑完AD复制显示正常域控之间也能互相解析但某台域控上的组策略就是不刷新登录脚本时灵时不灵客户端登录后GPO应用一半就报错。折腾半天最后发现问题出在SYSVOL复制上。SYSVOL是域控上一个非常特殊又非常脆弱的目录它承载着组策略模板、登录脚本、脚本策略等基础数据。客户端登录时能不能拿到正确的策略完全取决于每台域控上的SYSVOL是否一致。Windows Server 2012默认使用DFSR分布式文件系统复制来复制SYSVOL但如果环境是从2003或2008升级过来的或者中间有人做过不规范的还原操作SYSVOL复制失败的概率会明显上升。这篇文章我尽量把排查思路和恢复手段讲透新手能照着做老手也可以当一份速查手册用。1.1 SYSVOL里装的是什么很多人一提SYSVOL就只知道“组策略”但里面其实不止GPO。一个典型的Windows Server 2012域控SYSVOL目录结构大概是这样的C:\Windows\SYSVOL\domain ├─ Policies按GUID命名的组策略对象 ├─ Scripts登录脚本、开机脚本 └─ DO_NOT_REMOVE_NtFrs_Prevent_Move占位标记文件Policies目录是重灾区。每个GPO一个子目录里面是GPT.INI、Machine、User等配置文件。客户端通过“域控上的SYSVOL共享”读取这些文件路径一般是\域\SYSVOL\域\Policies{GUID}\Machine\registry.pol。一旦SYSVOL复制失败不同DC上的GPO版本就会不一致客户端刚好连到落后DC就会应用旧策略或者报“找不到文件”。Scripts目录存放登录脚本、启动脚本、组策略首选项引用的脚本文件。这个目录如果复制失败表现更隐蔽——Admin中心改完脚本保存了但客户端执行的还是旧版本因为连到了没同步到新脚本的那台DC。DO_NOT_REMOVE_NtFrs_Prevent_Move这个占位文件是迁移残留的痕迹说明这台机器曾经使用过FRS复制。正常情况下这个文件不应该被删除我见过有人“清理”它导致SYSVOL复制直接停摆。1.2 从FRS到DFSR2012默认走哪条路Windows 2000和2003时代SYSVOL复制靠的是NTFRS服务也就是FRS文件复制服务。FRS对大量小文件的复制效率很低而且容易出“JRNL_WRAP_ERROR”这类日志包装故障一卡就是几天。从Windows Server 2008开始微软引入了DFSR用于SYSVOL复制但为了兼容老环境默认并不强制启用。真正把DFSR设为SYSVOL首选复制引擎是在Windows Server 2008 R2和2012时代逐步推开的。Windows Server 2012全新安装的域控SYSVOL复制直接走DFSR已经看不到NTFRS服务在跑。但如果你是老版本域升级上来的SYSVOL复制可能还在FRS状态或者正处于“迁移中间态”。这种混合状态特别容易复制失败。出现故障时第一件事不是急着删数据而是确认当前SYSVOL复制到底用的哪套引擎。DFS Replication服务就是DFSR的执行体NTFRS服务是FRS的执行体。两台服务可以同时存在但SYSVOL同一时间只能挂在一个复制引擎下。如果一台DC还在FRS另一台已经迁移到DFSR两边根本无法正常同步。1.3 复制失败会带来什么后果SYSVOL复制失败的典型表现是“AD健康但GPO乱”。因为AD复制和SYSVOL复制是两套独立机制AD数据库由NTDS服务负责SYSVOL由FRS或DFSR负责。AD复制正常不代表SYSVOL正常。很多时候你查dcdiag只能看到AD层面没问题于是下意识排除域控故障转而去查客户端、网络、权限绕一大圈才回来。复制失败时间短的话客户端可能只是偶尔应用旧策略。时间长了某台DC上的SYSVOL内容越来越旧甚至为空。更严重的是如果盲目在一台“没有完整策略”的DC上做权威同步会把这个不完整的SYSVOL推给所有DC导致全公司组策略大面积丢失。这个风险一定要提前知道。另外SYSVOL一旦有大面积不一致域控之间的信任关系、DFS命名空间、某些依赖GPO的安全设置都会出问题。比如域内密码策略、账户锁定策略、防火墙规则等全是靠GPO下发到客户端的客户端连到落后DC就拿到了旧规则。所以SYSVOL复制失败不只是“技术问题”而是直接影响业务安全的问题。2. 先确认症状哪些现象说明SYSVOL复制出了问题2.1 现象清单不能只看“日志红色”我处理过的SYSVOL故障里最常见的现场是“事件查看器里有大量错误但所有服务都在运行”。所以别一看服务启动就认为没事。下面这些现象只要中了两条以上就该把SYSVOL复制列为头号嫌疑同一台DC上dcdiag /test:replications通过但系统日志里有DFS Replication或NtFrs错误。客户端登录后组策略应用报错事件ID指向“无法访问策略目录”或“未能找到文件”。在DC本机打开组策略管理发现某些GPO“状态为空”或“访问被拒绝”。不同DC上执行gpresult /r同一个用户的策略结果差异很大。登录脚本在部分客户端正常在另一部分客户端完全不生效。SYSVOL共享目录无法访问或者访问后目录列表是空的。事件查看器中反复出现“SYSVOL has not been replicated”或“DFSR is waiting to perform initial replication”。这些信号叠加在一起基本可以断定SYSVOL复制已经不正常了。接下来要用工具把状态量化出来。2.2 用三条命令快速摸清复制状态我习惯在可疑DC上先跑三条命令信息量最大速度也最快。第一条是看服务状态net start | findstr /i DFS NtFrs正常情况下应该能看到“DFS Replication”在运行。如果同时看到“File Replication Service”说明这台机器还在使用FRS复制SYSVOL也可能是FRS服务残留且被启动这时候要赶紧确认迁移状态。第二条是看AD复制摘要repadmin /replsummary这条命令会列出所有复制邻居的失败情况。如果AD复制有大量失败SYSVOL复制大概率也不稳因为SYSVOL的数据源毕竟是每台DC。不过这里要强调repadmin正常不代表SYSVOL正常它只是排查的起点。第三条是看DFSR复制状态dfsrdiag /replstate /v这条命令会输出复制组和复制文件夹的状态能看到“Initialized”是否成功、是否有积压、复制方向是否健康。如果状态里出现“JRNL_WRAP_ERROR”或者“ERROR”那基本可以确定复制引擎已经卡死。如果你的域控还在用FRS对应的命令是“ntfrsutl ds”和“ntfrsutl inlog”能看到FRS的数据库和日志状态。2.3 事件ID速查DFSR和NTFRS都要看事件查看器是最直接的线索来源。Windows Server 2012上DFSR的事件日志叫“DFS Replication”FRS的事件日志叫“File Replication Service”。我整理了几个高频事件ID遇到它们基本可以快速定位方向。日志源事件ID含义处理方向DFS Replication4002DFSR服务停止或无法启动检查服务、依赖、磁盘权限DFS Replication4012USN日志回滚或包装非权威同步/权威同步DFS Replication2213暂存区空间不足清理暂存区、调整大小DFS Replication5002复制组配置错误检查AD中的复制组对象DFS Replication5012与AD的连接中断检查AD复制File Replication Service13508/13509FRS无法与伙伴通信检查FRS是否已停止使用File Replication Service13562日志包装非权威恢复FRS或在迁移前提下强制转DFSRNTDS Replication2042太久未复制USN回滚联系AD恢复可能需要清理元数据其中DFS Replication 4012这个事件最要命。它通常提示“日志已回滚”或“USN日志已被删除”说明这台DC的NTFS USN日志出了问题。出现4012后DFSR往往无法继续复制SYSVOL必须人工介入做恢复。3. 定位底层原因USN回滚、日志包装还是迁移残留3.1 区别三类故障方向SYSVOL复制失败不是单一原因常见的有三类处理方法完全不同第一类是“USN回滚”通常因为域控被恢复到旧快照或旧备份导致AD和NTFS日志回退DFSR无法判断增量。第二类是“日志包装”也就是JRNL_WRAP_ERRORNTFS USN日志被覆盖DFSR丢掉了增量变化的记录只能做非权威同步。第三类是“迁移残留”SYSVOL还在用FRS复制状态已经坏掉或者FRS/DFSR配置混杂两边都不干活。这三类问题表面症状很像都是“复制不成功”但解决路径南辕北辙。如果看到4012就盲目执行权威同步很容易把整条复制链打崩。所以先要花几分钟区分类型。3.2 USN回滚的判定与成因USN回滚这个名词听起来很硬核其实原理不复杂。NTFS每个卷上维护了一个USN日志用来记录文件变动DFSR靠它判断“哪些文件需要复制”。一旦域控被恢复到旧快照USN日志里的序号比AD数据库里的序号小AD和DFSR都会认为“本身数据比域内新”从而拒绝接受其他DC的数据。判定USN回滚最直接的方法是看事件日志。DFS Replication日志里出现4012同时NTDS Replication日志里出现2095或2042基本上就可以锁定USN回滚。再用repadmin /showrepl看复制状态通常会看到“too recently attempted”或“waiting to replicate”这类提示。USN回滚的成因基本都是人为恢复操作导致的比如虚拟化平台直接把域控虚拟机回滚到几天前的快照或者物理机用旧备份做过还原。Windows Server 2012虽然支持虚拟机快照但对域控来讲快照回滚永远是高风险操作。正常备份域控应该用系统状态备份而不是快照回滚。3.3 JRNL_WRAP_ERROR为什么会把DFSR卡死JRNL_WRAP_ERROR翻译成“日志包装错误”确实不太好懂。打个比方USN日志就像一个循环录像带如果写入太快或者日志设置太小新数据会把旧数据覆盖掉。DFSR还在按旧序号找增量记录结果发现记录已经被覆盖就会报JRNL_WRAP_ERROR。这个错误在FRS时代非常出名DFSR下相对少见但一旦出现表现比FRS还难缠。dfsr状态会停留在“Initialized: False”复制组显示错误事件日志频繁报4012或4010。磁盘I/O压力大、卷上文件数量特别多、防病毒软件频繁扫描都可能诱发这个问题。处理办法只有一个放弃当前增量状态做非权威同步。3.4 迁移残留FRS和DFSR同时存在怎么查Windows Server 2012域控如果是从2003/2008升级来的SYSVOL可能还在FRS复制状态。这种情况下你可能看到NTFRS服务在运行同时DFSR事件日志里又空荡荡的。要查看SYSVOL复制引擎的迁移状态用微软提供的FRS迁移工具最省事dfsrmig /getglobalstate dfsrmig /getlocalstate全局状态和本地状态的结果有0到3四个值0开始状态SYSVOL使用FRS1准备状态FRS开始为迁移做准备2重定向状态SYSVOL已经重定向到DFSR3已消除状态FRS彻底退出SYSVOL完全由DFSR管理如果全局状态是2本地状态却是0或1说明这台DC的迁移没跟上。这时候SYSVOL复制很可能卡死域内部分DC用DFSR部分DC还在FRS两边互不通信。怎么办最简单的方案是把迁移状态推进到3命令是dfsrmig /setglobalstate 3但注意执行前必须确认所有DC都已准备好至少本地状态都到了2。如果有DC一直卡在0或1要先检查那台DC的FRS服务是否正常、事件日志里有没有复制错误。强行拉状态可能把其他DC也弄坏。4. 恢复操作从非权威同步到权威同步4.1 恢复前必须搞清的两个概念处理SYSVOL复制失败绕不开两个词权威和非权威。很多新手一听到“权威”就以为是好东西实际恰恰相反权威恢复是高风险操作用错方向会毁掉整个SYSVOL。非权威同步的意思是这台DC上的SYSVOL数据不信任启动后从别的DC拉取完整数据。绝大多数故障场景都适合先做非权威同步。权威同步的意思是把某台DC上的SYSVOL数据当成“标准答案”强制推送给其他所有DC。除非你能百分之百确认这台DC的数据是完整且正确的否则不要轻易做权威同步。我见过最惨的案例是有人在故障DC上顺手做了个“权威恢复”结果把一份只有三个GPO的空SYSVOL推给整个域全网组策略全部丢失最后只能靠备份恢复AD重新生成GPO。所以下面所有操作我都建议优先走非权威方向。4.2 非权威同步实操故障DC拉取数据这里给出我实际用过的、比较稳妥的非权威同步流程。假设故障DC是DC02健康DC是DC01所有命令在DC02上以管理员身份执行。第一步停止DFSR服务net stop dfsr如果服务已经卡死用强制参数net stop dfsr /y第二步把当前SYSVOL里的Policies和Scripts目录改名备份。注意不是删除是改名万一后面要回滚还能用cd C:\Windows\SYSVOL\domain ren Policies Policies.old ren Scripts Scripts.old这里要特别提醒只改Policies和Scripts不要动DO_NOT_REMOVE_NtFrs_Prevent_Move也不要去改sysvol下的目录连接。整个SYSVOL共享依赖目录结构改多了容易出现共享丢失。第三步清理DFSR本地数据库。DFSR的数据库位于“C:\System Volume Information\DFSR”目录下里面有以database_XXX命名的子目录。执行dir C:\System Volume Information\DFSR确认后把整个DFSR目录改名备份cd C:\System Volume Information ren DFSR DFSR.old这个目录里存放的是DFSR的本地复制状态和数据库改名后DFSR会认为这是一台“从未初始化”的机器启动后必然从伙伴拉数据。第四步启动DFSR服务net start dfsr启动后DFSR会进入初始同步状态从配置的入站连接伙伴拉取SYSVOL数据。这个过程中Policies和Scripts目录会自动生成内容逐步补齐。查看状态用dfsrdiag /replstate /v第五步验证SYSVOL共享是否正常net share正常情况下能看到SYSVOL和NETLOGON共享。如果没有检查C:\Windows\SYSVOL\sysvol下是否有域名文件夹或重启一下NetLogon服务net stop netlogon net start netlogon4.3 等效权威同步用健康DC向外推送如果故障DC执行非权威同步后数据能拉过来但发现数据本身是旧的或者健康DC上的内容才是最新最全的就需要把健康DC的数据推给其他DC。这时候我不建议直接改注册表做“官方权威恢复”因为注册表路径涉及复制组GUID操作错了很难收拾。我更推荐下面这种“等效权威同步”的思路安全性高很多。假设DC01数据完整DC02是故障机。先把DC01的DFSR服务停掉做一个短暂的“只推不拉”让DC01只作为来源net stop dfsr在DC01上确认SYSVOL数据完整同时检查C:\Windows\SYSVOL\domain\Policies和Scripts目录都在。然后启动DFSRnet start dfsr回到DC02按4.2的流程把Policies和Scripts改名为.old再把DFSR数据库目录改名最后启动DFSR。这样DC02会强制从DC01拉取完整SYSVOL。等DC02同步完成SYSVOL内容就和DC01一致了。这本质上就是“以DC01为权威DC02做非权威”的恢复路径绕开了注册表操作对新手更友好。如果域内有多台DC记得等这台恢复完成后再逐台处理下一台。4.4 恢复后的验证步骤恢复操作做完不能只看服务启动了就算完事。我建议至少做四项验证第一项看复制状态dfsrdiag /replstate /v确认输出里没有“ERROR”字样初始化状态为“Initialized”。第二项看是否有事件错误。清空DFS Replication日志后等10到20分钟再看看是否有新错误。正常情况下只有信息级别的事件。第三项对比DC01和DC02上的Policies目录数量和文件robocopy C:\Windows\SYSVOL\domain\Policies \DC02\SYSVOL\域\Policies /L /R:0 /W:0用robocopy的“仅列表”模式对比或者直接在文件管理器里看GPO数量。不要求文件顺序一致但GUID目录数量和关键文件必须一致。第四项在客户端上强制刷新组策略gpupdate /force登录一台测试机确认组策略能正常应用登录脚本能执行。这一步才是最终验收。5. 多台DC同时异常时的处理套路5.1 先找一台“相对健康”的DC多台DC同时出问题最忌讳的就是慌。我的经验是先不要碰任何DC停下手来从所有域控里挑出一台“最可信”的DC。判断标准很简单谁的事件日志里错误最少谁的SYSVOL目录内容看上去最完整谁和客户端交互正常就选谁。选定后在这台DC上先做数据备份。最简单的方式是把SYSVOL\domain\Policies和Scripts目录复制一份到本地其他磁盘robocopy C:\Windows\SYSVOL\domain\Policies D:\SYSVOL_Backup\Policies /E robocopy C:\Windows\SYSVOL\domain\Scripts D:\SYSVOL_Backup\Scripts /E如果这台DC本身也有复制错误也不用担心先把它定为“主要参考源”后面逐台恢复时以它为准。备份完成之前绝对不要动其他DC。5.2 逐台恢复而不是同时强拉多台故障DC的情况下很多人会想着“我给所有DC同时做非权威同步让它们互相拉数据”这是大忌。多台DC同时处于初始同步状态时它们会互相竞争权威源甚至因为时间戳不一致导致数据互相覆盖越同步越乱。正确做法是主从式恢复。以5.1选出的DC为“主”先把其他故障DC逐台按非权威同步流程恢复每恢复一台就验证一台的复制状态。恢复顺序上优先处理SYSVOL数据相对最新、和业务关联最紧密的DC。最后再回头看主DC是否需要重新初始化。如果主DC本身也有USN回滚但SYSVOL目录内容完整可以尝试先做主DC的DFSR数据库清理让它以“本地数据为基准”重新初始化。操作和4.2类似只是不需要改名Policies和Scripts只改名DFSR数据库目录。这样主DC会保留本地完整数据重新生成复制状态然后其他DC再从它这里同步。5.3 灾难场景所有DC都脏了怎么办最麻烦的情况是所有DC的SYSVOL都是残缺的连一份完整数据都找不到。这时候只能靠备份了。Windows Server 2012的系统状态备份里包含SYSVOL和AD数据库如果有最近的系统状态备份优先还原一台DC然后让它作为权威源推给其他DC。如果没有备份也不是完全没救。还有一个思路从客户端角度反推。找一台长时间正常应用组策略、且本地缓存里有完整GPO的客户端把%SystemRoot%\System32\GroupPolicy目录下的数据提取出来结合域内实际使用的GPO清单手工重建一套相对完整的SYSVOL。这个方法工作量很大而且容易遗漏关键GPO只建议作为最后一个保命手段。我在实际运维中见过一次没有备份的灾难场景最后是靠“域内所有客户端登录脚本的历史版本”和“组策略管理控制台中的GPO列表”一点一点拼回大部分策略的。业务影响非常大整个恢复过程持续了两天。所以平时一定提醒你域控的备份优先级要高于普通服务器而且备份要定期做恢复演练。6. 避坑清单与日常防护6.1 我踩过的几个坑处理SYSVOL复制失败这几年我自己踩过不少坑也帮别人收拾过不少烂摊子。第一个坑是“把FRS和DFSR搞混”。有一台2012域控升级后SYSVOL还在FRS状态我一直按DFSR的方式查白白浪费了半天。现在我会先跑一条dfsrmig /getglobalstate确认当前复制引擎。第二个坑是“恢复前不做备份”。有一次我直接清理了故障DC的SYSVOL数据结果发现健康DC的数据也不完整想回滚都没得回。从那以后我做任何SYSVOL操作前都会先把故障DC的现有数据备份到独立磁盘成本很低但关键时刻能救命。第三个坑是“做完非权威同步就忘了检查NetLogon共享”。DFSR把数据同步过来了但NetLogon共享没有自动恢复客户端还是无法执行登录脚本。这是因为NetLogon服务需要额外触发。现在我的收尾清单里一定包含“net share检查”和“重启NetLogon服务”这两步。第四个坑是“权威和备份方向搞反”。有人从备份软件里恢复了某台DC的SYSVOL恢复完成后又顺手做了“权威同步”结果把恢复出来的旧GPO推给了所有DC。正确做法是从备份恢复的DC先做一次非权威同步确认数据比伙伴新时再考虑是否做权威推送。6.2 日常巡检与备份建议SYSVOL复制这种问题最好的处理方式是在它还只是“日志里一条警告”的时候就发现。我给客户做的日常巡检清单里主要有这几项每周检查所有域控的“DFS Replication”事件日志重点看4012、2213、5012。每月跑一次dfsrdiag /replstate /v确认所有DC的复制状态为“Initialized”。每季度检查一次DFS复制暂存区空间和数据库大小避免日志包装。域控虚拟机的快照策略必须慎用。非域控可以随便快照回滚域控最好只用“备份软件的系统状态备份”不要依赖虚拟机快照作为恢复手段。SYSVOL里的Policies和Scripts目录建议纳入文件服务器备份保留最近90天版本。定期做恢复演练从备份还原一台DC的SYSVOL确认能正常初始化、非权威同步、客户端GPO下发。演练过一次后你心里才有底。最后再分享一个小习惯。每次处理完SYSVOL故障我都会把关键事件ID、执行过的命令、恢复耗时记录在案形成一份“SYSVOL故障处理单”。下次再遇到类似问题直接翻出来照着走能省不少时间。域控这东西稳定运行的时候没人注意一旦出问题就是全局性故障平时多留一手总没错。