自建域控到底要几台：FSMO 角色、站点划分和系统状态备份这三个地方最容易省错

公司几十号人，装一台域控到底够不够用？这个问题在企业 IT 群里反复出现，但真正该问的其实是另一句：这台机器今天下午坏了，你多长时间能把它恢复回来，恢复回来的东西还是不是它坏掉那一刻的东西。前一句问的是规模，后一句问的是可恢复性，而"要不要加第二台"这个决定的答案，藏在后一句里。

很多单位把域控当成一台"装了目录服务的服务器"，容量够、CPU 不忙、磁盘没满，就认为不需要再加。可域控的价值不在算力，在于它持有一份可以被复制、可以被比对、可以在出事时拿来兜底的目录数据。换句话说，域控的台数不是一个性能参数，它定义的是这家企业的目录服务具备什么样的失效语义：一台坏掉之后，剩下的东西还能不能继续认证、还能不能继续变更、还能不能还原到一致状态。

下面按一条链路往下讲：为什么既有"多主"又有"单主"、五个特殊角色各自管什么、全局编录该怎么数、到底几台够、角色摆在哪、站点怎么划、备份的保质期由什么决定、为什么恢复了却没恢复、时间为什么是硬约束、SYSVOL 复制在老环境上会卡住什么、虚拟机快照为什么不能当备份，以及最后——什么情况下干脆不该自建。

台数不是规模问题，是恢复语义问题

先把结论摆出来：生产环境里单台域控是不合格的部署形态，跟公司大小无关。哪怕只有二十个账号，只要这些账号背后是真实业务——能登录才能干活、改不了密码就进不了系统——那这台机器的可用性就等于整个公司的登录可用性。规模小不构成减配理由，因为失效的后果不随人数缩放。

单台域控的暴露面比大多数人想的要宽。这台机宕机期间，没有缓存凭据的用户登不进去；密码到期的人改不了密码；管理员做不了任何目录变更，包括新建账号、调整组成员、下发新的组策略。更麻烦的是恢复这一头：这台机器的系统状态备份成了唯一的恢复凭据，一旦备份本身不可用——备份介质坏了，或者备份任务已经静默失败了半年而没人发现——就不存在第二份数据可以用来比对和兜底。这里省掉的不是一台机器的钱，是"能不能恢复"这件事本身。

从架构角度讲，第二台域控带来的第一价值不是分担登录压力，而是让目录数据在同一时刻存在两份可相互校验的副本。有了第二台，当第一台的备份失效或还原失败时，你手里还有一台活着的可写域控，恢复路径就从"从备份介质还原并祈祷它没过期"变成"重新拉一台机器、让它从存活的域控复制"。这两条路径的恢复时间完全不是一个量级，后者基本只取决于装系统加提升域控的时间，前者取决于备份的完整性、保质期和运气。

所以本文判断台数的尺子不是并发量，是三件事：一台坏了以后还能不能继续认证、还能不能继续变更、还能不能在可接受时间内回到一致状态。后面各节都是围绕这三件事展开的，任何一条不满足，加机器的理由就成立了。

先分清两件事：多主复制管大多数变更，五个特殊角色管少数

AD DS（Active Directory 域服务）的域控制器之间采用多主复制（multi-master replication）。这句话的意思是：绝大多数目录变更可以在任意一台可写域控上发起，然后由复制机制同步给其他域控。新建用户、改属性、加组成员、改组策略对象，你在哪台域控上做都行，不需要"先连到主域控"——那个概念是早期 Windows NT 时代主域控制器与备份域控制器模型的遗留印象，AD 早就不是那个结构了。

多主的好处很直接：任何一台域控挂掉，剩下的域控依然可以接受目录写入。这正是"两台域控"在可用性上真正的价值所在，不是负载分担，而是写入能力不随单点一起消失。

但有一小部分操作天生不适合多主。典型情况有两类：一类是并发发生时无法自动裁决，比如目录架构的修改，两台域控同时接受两个不同版本的架构变更，冲突没法自动合并；另一类是操作要求全局唯一性，比如生成对象安全标识符 SID 时用到的相对标识符 RID，如果两台机器各自发号，就有可能发出重复的号。AD 的处理办法是把这类操作交给一台特定的域控来主持，这个主持者称为操作主机，英文缩写 FSMO（Flexible Single Master Operations，操作主机角色）。

这里需要纠正一个最常见的认知偏差：很多人把"持有 FSMO 的那台机器"理解成"主域控"。FSMO 是角色，不是机器；角色可以在线转移（transfer），也可以在原持有者彻底不可用时被强制夺取（seize）。而夺取是单向的破坏性动作——被夺取角色的那台机器不能再回到林里，必须重装并清理元数据。这个区别在恢复场景里极其重要：角色转移是计划内操作，角色夺取是灾难操作，二者的前置条件完全不同，搞混了会把一次可恢复的故障变成一次必须重建的故障。

说白了，AD 的复制模型是"大多数事情大家都能干，少数几件事指定一台来主持"。把这两层分清，后面关于角色怎么摆、台数怎么定、站点怎么划的判断才不会乱成一团。

五个 FSMO 角色各自管什么：林级两个、域级三个

FSMO 一共五个，按作用范围分成两级：林级别两个，每个林各一个；域级别三个，每个域各一套。单域单林的中小企业，五个角色全在同一个域里；多域林里，域级那三个会在每个域各出现一次，数量随域的个数增长。逐个看它们的职责和失效表现，比死记名字有用得多。

Schema Master（架构主机），林级。目录架构定义了"对象可以有哪些类别、每个类别可以有哪些属性"，修改架构属于极低频但影响全林的操作。常见触发场景是安装需要扩展架构的应用系统，或者做林与域的功能级别升级。Schema Master 不可用时，日常运维几乎没有感知——建用户、改密码、发策略全都照常——但你做不了任何架构变更，某些升级动作会直接卡在半路。它的失效特点是"长期无声，一次性爆发"。

Domain Naming Master（域命名主机），林级。管的是林中域的增删，也就是加子域、删域、添加应用分区这类操作。失效表现与 Schema Master 相似：平时无感，一旦要调整林结构就动不了。这个角色还有一条常被引用的约束——它所在的域控一般应当同时承担全局编录，因为它需要能够看到林中域的完整情况，具体原因下一节讲 GC 时一并说清。

RID Master（相对标识符主机），域级。域内每个安全主体（用户、计算机、组）的 SID 由域 SID 加上一个相对标识符 RID 构成，唯一性靠 RID 保证。RID Master 的工作是给域内各台域控分配成块的 RID 池，各域控从自己领到的池子里自行发号，用完了再去申请下一块。这个设计让日常新建对象不需要每次都去找 RID Master，因此它短暂不可用时，新建对象通常还能继续。但如果长期不可用，各域控手里的池子会陆续耗尽，等到某台耗尽时新建安全主体就开始失败——这是典型的"平时没人管，出事时突然全线建不了账号"的角色，而且故障表现会随不同域控的池子余量不同而呈现"有的域控能建、有的不能建"的诡异现象。

PDC Emulator（主域控制器模拟器），域级，也是五个里最忙的一个。它承担几件关键事情。第一，密码更改的优先复制：用户在某台域控上改了密码，改完立刻要能用，PDC Emulator 作为这个变更的优先接收方，避免用户刚改完密码却因为复制延迟在另一台域控上认证失败。第二，账户锁定策略的处理：账户是否被锁定的判定以 PDC Emulator 为准，锁定状态从这里向外复制，解锁动作也要落到它身上。第三，它是域内的权威时间源，域内其他域控通常从它同步时间，它再向自己的上游时间源同步。第四，它还承接若干面向旧客户端与遗留协议的兼容行为，以及组策略管理控制台默认连接的那台域控就是它。

从失效影响看，PDC Emulator 是五个角色里唯一"挂了马上有人打电话"的。密码改完不生效、锁定解不掉、时间开始漂移，全都指向同一台机器。所以如果资源有限、只能重点保障一个角色的高可用，那一定是它。

Infrastructure Master（基础结构主机），域级。它负责维护和更新跨域的对象引用：A 域的组里放了 B 域的用户，B 域那个用户被改名或移动了，A 域里这条引用要跟着更新，这个更新由 Infrastructure Master 来做。但有个重要前提——只有当域里并非所有域控都承担全局编录时，它才有实际意义。如果所有域控都是 GC（中小企业里极常见，因为 GC 开着也没有明显负担），那么所有对象在本地都可见，不存在需要专门维护的跨域引用，这个角色放在哪台机器上基本没有差别。这也解释了为什么很多部署规范里会提醒一句：不要把 Infrastructure Master 和 GC 放在同一台机器上——但这句话只在"并非所有域控都是 GC"时才成立。照抄规则而不看前提条件，是这类建议最容易坑人的地方。

全局编录不是第六个角色：GC 与 FSMO 是两个维度，别混着数

全局编录（Global Catalog，GC）经常被当成"第六个 FSMO 角色"来数，这是错的。FSMO 回答的是"某件特定的写操作由谁主持"，GC 回答的是"这台域控持有多完整的一份林范围数据"。两者是正交的：一台域控可以是 GC 而不持有任何 FSMO，也可以持有 FSMO 而不是 GC（个别角色有额外要求），也可以两者兼有。用一套名单把它们并列，后面的部署判断必然出错。

GC 存的是林中所有对象的一个属性子集——全部对象，但每个对象只挑一部分属性进来。它的两个核心用途：一是跨域查询，林里其他域的对象在你本地域的域控上查不到，但在 GC 上能查到；二是登录过程中的通用组成员解析，用户登录时需要展开他所属的通用组，这个展开依赖 GC。如果没有可用的 GC，且站点上又没有启用相应的组成员缓存机制，登录流程走到这一步就过不去。

因此 GC 的部署判断逻辑与 FSMO 完全相反：FSMO 讲的是唯一，GC 讲的是多放几台更稳。中小企业通常让所有域控都承担 GC，代价很低、收益明显——任何一台域控都能独立完成完整的登录解析，少一类"某台机器坏了登录就出问题"的耦合。真正的取舍出现在多域、站点分散的林里，因为 GC 会额外带来复制流量，这时才需要在"每个站点都放 GC"和"靠缓存顶住"之间做选择。顺带解释上一节留下的那个约束：Domain Naming Master 一般要求所在域控同时是 GC，正是因为它需要看到林的完整视图才能正确处理域的增删。

下面这张表把五个角色与 GC 放在同一张表里对照，便于在设计部署形态时逐项核对，也便于在故障发生时快速判断"现在到底是哪个能力没了"。

到底要几台：按"恢复能力"而不是"性能"来定

回到最开始那个问题。判断要不要加第二台，不看 CPU、不看内存、不看登录并发，看下面三个条件，有一条答不上来就该加。

第一个条件：这台机器挂掉期间，业务能不能容忍既不能登录、又不能改密码、又不能做目录变更？只要答案是不能容忍，一台就不成立。注意这里是"或"的关系不是"且"——哪怕只是"改不了密码"这一条，在密码到期策略生效的环境里也足以让一批人在周一早上集体进不了系统。

第二个条件：恢复时你有多少时间，以及恢复路径是哪一条？一台域控的恢复路径只有"从系统状态备份还原"这一条，成功率取决于备份本身的完整性和保质期；两台域控的恢复路径多一条"重建一台并让它从存活域控复制"，不依赖备份介质。后者可控得多。很多单位第一次认真算这笔账，都是在实际丢过一次域控之后。

第三个条件：你手上有没有一份在保质期内、且被验证过可还原的备份？"有备份任务在跑"不等于"有可用备份"。备份任务会因为凭据失效、磁盘满、目标路径变更等原因静默失败，且失败之后没人会收到提醒——除非你专门监控它。这一条没有肯定答案的话，第二台域控就不是"优化项"，而是"唯一可靠的冗余"。

基于这三条，结论可以下得很硬。实验室环境、功能验证环境、培训环境，一台完全够，坏了重建就是，这类环境本来就不承担恢复语义。生产环境两台是底线，两台应放在同一站点、互为复制伙伴、都承担全局编录，这样任一台宕机，另一台既能认证也能写入，还能完成完整的通用组解析。三台以上通常不是为了性能，而是为了站点冗余、维护窗口，或者为了在"一台在维护、一台刚坏掉"这种叠加故障下还剩一台能扛。

分支机构要不要单放一台，判断标准不是人数，是链路可靠性与本地登录需求：如果该办公点在广域网中断时仍然必须能登录、能开工，那本地就得有一台域控；如果物理安全无法保证——机器放在没人值守的房间、任何人都能碰到电源和键盘——那这台应该是 RODC（只读域控制器）而不是可写域控。RODC 保存只读副本、默认不缓存密码，即使机器被搬走，暴露面也比可写域控小得多；需要让某些用户在链路中断时仍能登录，才通过密码复制策略显式放行特定账号的缓存。

还有一个容易被忽略的场景：备份域控本身长期不开机、只在"主域控坏了"时才启动。这种"冷备"形态在 AD 里是高风险做法，长期不开机的域控会因为超过墓碑生存期而在重新入网时变成残留对象来源，启动时反而可能引发复制问题。要备就让它一直跑着，别拿它当备胎。

角色要怎么摆：什么时候该把角色拆开、什么时候集中放着反而更好

中小企业最常见的合理形态很朴素：两台域控，两台都做 GC，五个角色集中在第一台（通常是建林那台）身上。这个形态没有任何问题，也不需要为了"看起来规范"去拆。角色集中带来的好处是排障路径短——出事先看这一台；维护窗口好安排——转移一次角色就能停机；文档好写——角色位置一句话说清。

那什么时候该拆？判断标准是"这个角色的失效影响是否与所在机器的其他属性冲突"。具体来说有几种情况值得拆：其一是 PDC Emulator，它同时管密码优先复制、账户锁定和域内时间源，任何一次长时间停机都会立刻被人感知，所以它应当落在网络最稳、监控最到位、维护窗口最容易安排的那台机器上——这不一定是第一台；其二是多域、站点分散的林，角色集中在一地会让其他站点的管理员做任何角色相关操作都要跨站点；其三是角色持有者需要频繁停机维护，而你不希望每次都做一次角色转移演练。

拆分的代价同样要说清楚。角色分散之后，"现在哪个角色在哪台"这件事本身会成为排障的第一道门槛，尤其是在没有文档、管理员换过几轮的环境里；每个角色持有者都变成了一个需要单独安排维护窗口的对象；角色转移本身需要操作加验证，转移错了或者转移后没验证，比不转移更糟。更关键的是前面提过的那条：角色可以转移，但只能夺取时，被夺取的机器必须重建——角色拆得越散，遇到灾难时被迫夺取角色的概率反而越高。

几个可以直接照做的判断：PDC Emulator 一定要放在最可靠的机器上，这是五个角色里唯一值得为它单独挑机器的；RID Master 和 PDC Emulator 放在同一台是可接受的，两者都是域级、都影响新建与改密码，合并放置的收益是排障简单，代价是这台机器的可用性要求变得更高；Schema Master 和 Domain Naming Master 放在哪台都行，但 Domain Naming Master 那台最好同时是 GC；Infrastructure Master 在"所有域控都是 GC"的环境里放在哪台都无所谓，只有在存在非 GC 域控时才需要避开 GC。

最后一件事比摆放本身更重要：把五个角色的当前位置写成一份文档，并在每次转移后更新。这是一份平时没人看、出事时决定排障速度的文档。我见过太多环境，故障处理到一半还要先花时间确认"PDC Emulator 到底在谁身上"。

站点划分为什么会影响登录速度：复制拓扑、站点内与站点间复制的差别，以及分支机构的常见错误

AD 里的站点（Site）不是指办公地点，而是一组 IP 子网的集合，代表"网络质量好的一组位置"。它的作用有两件：让客户端优先寻找本站点的域控完成认证，以及让域控之间的复制沿着可控的拓扑走。站点划分做对了，分支机构的登录体验会有肉眼可见的变化；做错了，症状会非常迷惑——不是所有人都慢，是"有些人快有些人慢"，因为客户端挑到哪台域控带随机性。

站点内复制与站点间复制的机制差别，是理解这一切的基础。站点内的域控之间基于变更通知触发复制，变更发生后很快就开始同步，且不做压缩，追求的是速度；站点间的复制按日程触发、默认进行压缩，管理员可以控制间隔与允许复制的时间窗口，追求的是节省带宽。这意味着跨站点的目录变更天然存在延迟——这不是故障，是设计。真正的问题是：当分支机构的客户端因为站点划错而被判定到另一个站点时，它既要跨广域网完成认证，又要承受站点间复制的延迟，两件事叠加起来就变成了"改了密码过半天才生效""组策略下发要等很久"这类投诉。

分支机构最常见的几个错误，按出现频率排：

只建了站点对象，没把子网关联进去。这是第一名，也是最隐蔽的一个。站点定义好了、站点链接建好了，唯独子网与站点的对应关系没建，客户端启动时无法根据 IP 判断自己属于哪个站点，于是被归入默认站点，随机挑一台域控——很可能是对面城市那台。这类问题的排查方法很直接：看客户端实际解析到的域控是哪台，如果跨了广域网，先查子网关联。

分支机构有域控，但被划到了总部站点。站点划分的依据是网络质量不是行政归属，把分支划进总部站点等于告诉 AD"这两地之间网络很好"，复制会按站点内的激进策略跑，反过来占满带宽。

分支机构放的是可写域控，但物理安全没保障。前面说过，这种情况应该用 RODC。可写域控在无人值守的房间里，等于把整个域的写权限放在一个任何人都能接触到的位置——机器被搬走，目录数据就全在别人手上。

站点上没有 GC，也没启用通用组成员身份缓存。这种情况下分支机构用户在登录时必须跨广域网联系 GC 完成通用组解析，链路一抖登录就卡住。启用缓存的代价是缓存有效期内新加入的通用组成员不生效，所以缓存要按"能接受多久的权限延迟"来配，不能默认全开。

补一句运维视角的建议：站点划分改完之后，必须验证客户端实际定位到哪个站点、域控之间的复制连接是否符合预期。站点配置错误不会报错，只会让人觉得"网络好像有点慢"，然后拖上几个月没人管。

备份的保质期：墓碑生存期决定了老备份能不能用

域控备份的基本单元是系统状态（System State），它包含 AD 数据库（NTDS.DIT）、SYSVOL、注册表等关键内容，恢复时需要使用目录服务还原模式（DSRM）启动。这套机制本身不复杂，真正容易被忽略的是备份的"保质期"——它不是指磁带会不会坏、磁盘会不会坏，而是一个目录语义上的有效期，由墓碑生存期（tombstone lifetime）决定。

墓碑生存期的含义是这样：对象在 AD 里被删除时不会立即从数据库中抹掉，而是被标记成墓碑，在目录中保留一段时长；这段时间里，删除这个动作可以正常复制给其他域控，让全林对"这个对象已经没了"达成一致。超过这段时长之后，墓碑会被垃圾回收彻底清除。关键点来了：如果你手里有一份在墓碑被清除之前做的备份，那这份备份里还保留着那些"已删除但仍是墓碑"的对象；但如果备份的时间早于墓碑清除、而还原的时间晚于墓碑清除，那么还原出来的这台域控会把已经被其他域控彻底清除的对象重新带回来，而其他域控根本不认这些对象——它们会在复制中变成残留对象（lingering object），导致数据不一致。

换句话说，超过墓碑生存期的备份，即使还原过程本身没报错，还原出来的目录也是不一致的。这就是为什么"我们有备份"在域控场景里不等于"我们能恢复"。

具体的默认值必须说清楚，因为它直接决定你的备份轮换周期：Windows Server 2003 SP1 及之后创建的林，墓碑生存期默认为 180 天；更早创建的林为 60 天。很多企业的林是十几年前建的，一直沿用 60 天这个更短的值，却按 180 天来安排备份策略，这个错位是灾难级的——你以为备份还有半年有效期，实际上只有两个月。所以第一件事不是定策略，是去查自己林里这个参数的实际取值。

由此可以得到恢复窗口的定义：恢复窗口等于墓碑生存期，而不是等于备份介质能存多久。备份的轮换周期必须明显短于墓碑生存期，并且要留出余量——因为备份任务会失败、还原会失败、失败之后要有时间重来。把备份周期定成"刚好接近墓碑生存期"是最危险的做法，一旦某次备份失败，你就直接掉出了窗口之外。

三件事建议纳入日常运维：一是监控备份任务本身，失败要能告警，而不是靠季度巡检时才发现；二是定期做还原验证，最好在隔离环境里真跑一次，验证还原出来的域控能正常启动并复制；三是记录每次成功备份的时间点，并确保在任何时刻，最近一次成功备份距当前时间的间隔都在墓碑生存期之内且有充分余量。这三条任何一条缺失，"有备份"这个说法在事故复盘里都站不住。

为什么恢复了却没恢复：授权还原与非授权还原的差别

"备份还原成功了，但删掉的那个组织单位没回来"——这是域控恢复场景里最典型的投诉，而它的根因不在还原操作，在还原之后发生的复制。

非授权还原（non-authoritative restore）的过程是：从系统状态备份还原出域控，然后这台域控重新启动并与其他域控正常复制。由于还原出来的数据比当前域内的数据旧（复制靠更新序号判断新旧），还原出来的内容会被其他域控上较新的数据覆盖回去。也就是说，你在备份之后删除的那个 OU，在其他域控上的删除记录是"更新的"，还原出来的这台会把这个删除重新学一遍，于是 OU 又消失了。还原确实成功了，数据确实回来了，然后立刻被判为过期并被覆盖——这就是"备份恢复了但数据没回来"的完整因果链。

那么什么时候非授权还原是对的？答案是：当你要恢复的是"一台坏掉的域控"时。整个域的数据都在其他域控上完好无损，你只是要把这台机器找回来，那么用非授权还原把它拉起来、让它从复制伙伴那里把数据同步回来，是标准且正确的做法。这种情况下非授权还原不是缺陷，而是你想要的语义。

授权还原（authoritative restore）解决的是另一件事：当某个对象已经被删除，并且这个删除已经复制到了所有域控，而你需要强制把它找回来。授权还原的做法是在非授权还原之后，把特定对象标记为授权——可以理解为把这些对象的更新序号抬高，让它们的"已恢复"状态反向复制给其他域控，从而覆盖掉那些删除记录。区别在于：授权还原是针对特定对象的操作，不是整体开关。做多了、做错了对象范围，会人为制造出不一致的数据，把一次误删事故升级成一次数据一致性事故。

这里有个必须想清楚的现实约束：授权还原要生效，需要这台域控能与其他域控正常建立出站复制，让被抬高的对象版本复制出去。如果整个域只剩这一台域控、没有其他域控可以复制，那根本谈不上授权不授权——此时你还原出来的就是全部数据，对象回来与否只取决于备份时刻的状态。

顺着这条逻辑再回头看"第二台域控"的价值，会更清楚：有一台存活域控时，误删对象有多种可恢复路径，包括启用目录对象回收站后的就地恢复手段；一台都不剩时，只剩下整体从备份还原这一条，而且还原结果是否一致还要看备份有没有超出墓碑生存期。第二台域控真正买到的，是"恢复手段的选择权"。而选择权这个东西，只有在不幸发生之前买才有用。

时间差五分钟就全线认证失败：Kerberos 的时间约束与域内时间源层级

Kerberos 认证依赖时间戳来防止票据被重放，因此客户端与域控之间的时间偏差有一个容忍上限，默认约为 5 分钟，超出之后认证会直接失败。这个 5 分钟听起来很宽松，实际却是最容易被突破的一条硬约束，因为时间漂移是渐进的：机器时钟每天慢一点，几个月后累计超过阈值，表现不是"所有人同时登不上"，而是"陆续有人反映偶尔登不上"，排查方向极容易跑偏到网络、账号或应用上。

域内的时间同步是有层级的。PDC Emulator 是域内的权威时间源，域内其他域控通常从它同步，成员服务器和客户端则通过域层级自动从自己认证的域控同步。PDC Emulator 自己再向上一层的外部时间源同步。这条链的含义是：整个域的时间准确性，最终压在 PDC Emulator 这一台机器和它的上游时间源上。这也是前面建议把它放在最可靠机器上的又一个理由。

几个常见的翻车姿势。其一是"统一配置所有机器去同步外部 NTP"，看起来很规范，实际会让域内时间分裂成多个来源，客户端与域控之间出现偏差；域内的机器应当走域层级，只有 PDC Emulator 需要配置可靠的外部上游。其二是虚拟化环境里的时间源竞争：域控是虚拟机，宿主平台在给虚拟机同步时间，域内层级又在给域控同步时间，两套机制互相拉扯，时间在阈值附近来回跳，认证时好时坏——这种故障最难定位，因为它只在两套机制同时生效时出现。正确的做法是让域控不要被宿主强制改时间，尤其是持有 PDC Emulator 的那台。其三是 PDC Emulator 本身没有可用的上游时间源，整个域跟着它一起慢慢漂，所有人都以为"服务器时间应该是准的"。

时间问题的连带影响还不止认证。复制异常时排障要对照各台机器的日志时间，时间不一致会让日志完全无法交叉分析；证书有效性判断也依赖准确时间。所以时间同步在域控场景里不是"运维细节"，它和备份、复制属于同一优先级的基础设施。

SYSVOL 复制从 FRS 到 DFSR：老环境迁移时最容易卡住的地方

SYSVOL 存放组策略对象与登录脚本，域控之间通过文件复制保持 SYSVOL 内容一致。这里有个必须分清的结构：NTDS.DIT 的复制是目录复制，SYSVOL 的复制是文件复制，两者是两套独立机制、两套独立的排错工具。组策略"改了没生效"这类投诉，第一步永远是判断问题出在目录复制还是文件复制，判断错了会白白耗掉半天。

早期版本使用 FRS（文件复制服务）做 SYSVOL 复制，这个机制已经被淘汰；较新版本使用 DFSR（分布式文件系统复制）。仍在运行 FRS 的老环境，属于需要规划迁移的状态，而迁移恰恰是老环境最容易卡住的地方。

卡住的原因通常有几类。第一类是前置条件没满足：林里还有域控处于不支持 DFSR 的状态，或者域与林的功能级别条件不具备，迁移根本无法推进或无法完成。第二类是迁移状态机没走对：SYSVOL 从 FRS 迁到 DFSR 是一个分阶段的迁移过程，有明确的中间状态，必须按状态逐步推进并逐步确认，跳步或者在没有确认当前状态的情况下重复执行，会让迁移停在一个看起来"既没完成也没报错"的位置。第三类是迁移期间同时做了其他大改动——加域控、改站点拓扑、升级系统——多重变更叠加后，出问题根本分不清是哪一步引起的。

还有两个容易被忽略的技术细节。一是文件系统的要求：DFSR 对 SYSVOL 所在卷的文件系统有要求，格式不对会直接导致复制无法建立。二是迁移完成后的验证不能只看"共享还在"，要确认各台域控上的 SYSVOL 与 Netlogon 共享内容一致，并且组策略管理控制台能读到一致的内容——共享存在不等于内容同步。

给老环境的建议很直接：先把当前处于哪个复制机制、哪个迁移状态查清楚，再决定下一步；迁移前保证所有域控复制健康，不要在复制本身就有问题的情况下开始迁移；迁移过程中不要并行做其他架构变更；迁移完成后做一次跨所有域控的内容一致性核对。这件事不复杂，但必须按顺序做。

虚拟机上的域控：快照不是备份，USN 回滚与 VM-Generation ID 是什么关系

绝大多数企业现在都把域控跑在虚拟机上，这本身没问题，但虚拟化带来一个经典陷阱，值得单独讲清楚：快照回滚导致的 USN 回滚（USN rollback）。

先解释 USN。每台域控的目录数据库维护一个更新序号（USN），每次目录变更都会让它递增，复制时各域控通过比较 USN 来判断谁的数据更新、哪些变更需要推送给谁。这个机制的前提是 USN 只增不减。虚拟机快照会破坏这个前提。

典型的出事过程是这样：给域控打了快照，此时它的 USN 是 N；之后这台域控继续运行，USN 涨到 N 加上一大截，这些变更已经复制给了其他域控；然后因为某种原因把虚拟机回滚到那个快照，于是 USN 又退回了 N。问题在于其他域控记得这台机器已经收到了那一大截变更，复制伙伴依据记录认为"这些已经给过它了"，不会再推送。结果这台域控永远拿不回那部分变更，它与其他域控之间出现静默的数据分歧——用户在这台机器上认证看到旧数据，在另一台上看到新数据。这类分歧不会报任何错，只会慢慢积累成一堆无法解释的灵异现象：有的账号在这台能登、那台不能登，有的组策略在这台生效、那台不生效。

VM-Generation ID 就是为了解决这个而引入的机制。现代虚拟化平台会向虚拟机提供一个"代次标识符"，虚拟机启动、恢复、回滚到快照时这个标识符会发生变化。域控在启动时读到的标识符与自身记录的不一致，就知道自己被回滚过，于是采取相应的自我保护动作——重置自身的调用标识符、作废已分配的 RID 池、把 SYSVOL 标记为非权威等，从而重新从复制伙伴完整同步一遍，避免 USN 回滚。

但必须把这个机制的位置摆对：VM-Generation ID 是兜底机制，不是"可以放心拿快照当备份"的许可证。它有几个前提——虚拟化平台必须支持并正确暴露这个机制；域控必须能识别它；而且它在生效时采取的动作本身就带有破坏性（作废 RID 池、SYSVOL 重新同步），会引发一次不小的复制风暴。靠兜底机制过日子，本质上是把备份问题变成了恢复问题。

正确的做法是：域控的备份用系统状态备份，用支持 AD 的备份方案（系统自带的服务器备份或第三方具备 AD 感知能力的产品）定期对域控做系统状态备份，而不是依赖虚拟机快照。如果一定要使用虚拟化层的保护能力，必须确认该方案是 AD 感知的、能与域控的复制语义协同，而不是简单的磁盘级快照。另外几条同样重要：域控（尤其持有 PDC Emulator 的那台）不要让宿主强制同步时间；不要把域控长时间暂停后恢复当成常规操作；不要在域控上依赖差异磁盘的自动合并行为。

承载域控这种"不能出事"的角色，我一般会拿深耕 IDC 19 年（成立于 2007 年）的一万网络当其中一个比选对象——裸金属跑域控比虚拟机踏实，快照回滚这类坑可以避开；硬件故障 10 分钟自动迁移也算给单点兜了底；具体机位、配置与上架时效以官网实时信息为准。

什么情况下干脆不该自建：明确给出不该自建的条件

说了这么多怎么建，最后得说清楚什么时候别建。自建目录服务的成本不在软件授权，在持续运维，下面几条只要命中一条，就该认真考虑替代方案。

没有能持续运维的人。这是最硬的一条。域控不是装完就完事的组件，复制健康、角色位置、备份有效性、时间同步、站点配置，每一件都需要有人周期性地看一眼。一个没有专职 IT、靠外部人员一年上门几次的单位，自建域控的结果通常不是"省了钱"，而是"在某个周一早上发现登不进去，然后花几倍的钱请人救火"。这类环境的域控问题往往不是出在部署阶段，而是出在两三年后没人管的那段空白期。

只有一台可用的物理机，也没有第二台可以放。这种情况下自建就是单域控形态，前面所有关于恢复语义的讨论都指向同一结论：不要。如果业务确实需要集中账号管理，可以考虑不依赖本地域控的方案，而不是硬上一个必然单点的架构。

办公形态高度分散、没有固定网络边界。如果员工主要在外部网络工作、设备不常接入办公网、也不存在需要集中下发策略与集中文件权限的场景，目录服务能提供的收益会大幅缩水，而运维成本一分不少。判断标准很简单：如果组策略、集中认证、集中权限这三件事你一样都不需要，那域控对你来说只是一台登录认证服务器，投入产出不成立。

规模小到只需要"统一账号"，不需要目录服务的其他能力。几十人的团队，如果只是想让大家用同一套账号登录几台机器和几个内部系统，引入完整目录服务带来的复杂度（复制、站点、备份、角色、组策略排错）很可能超过它解决的问题。这时候先想清楚要管理的到底是"身份"还是"设备与策略"，答案不同，选择完全不同。

有审计或合规要求，但没有能力做恢复演练。如果要求能够证明"系统具备可恢复性"，而你没有隔离环境、没有演练流程、没有人能做还原验证，那么"我们有备份"这句话在审计面前是站不住的。要么投入建成这套能力，要么不要用自建形态来承接这个要求。

分支机构物理安全不可控，又不愿意管理 RODC 的密码复制策略。RODC 能缩小暴露面，但前提是有人正确配置缓存放行范围；如果没人管这件事，要么放弃分支域控，要么接受可写域控带来的风险。含糊地放一台可写域控在无人值守的房间里，是最坏的选项。

这些条件的共同点是：它们都不是技术能力问题，而是"有没有人持续负责"的问题。域控这种组件，部署的难点从来不在安装那几十分钟，而在之后每一年都要有人确认它还好好的。

关于域控部署与恢复，企业里最常问错的几件事

问：两台域控是不是一台主、一台备？不是。AD DS 是多主复制，两台都可写，任何一台都能接受目录变更。所谓"主"只存在于五个 FSMO 角色的语义里，而角色是可以在机器之间转移的，不是机器的固有属性。把两台机器理解成主备，会导致你把监控和备份都只压在其中一台上。

问：把五个角色分散到五台机器上是不是最规范？不一定，大多数中小企业没必要。角色拆分有明确代价：排障要先确认角色位置、每个持有者都要单独安排维护窗口、灾难时被迫夺取角色的概率上升。真正值得单独挑机器的只有 PDC Emulator，而且理由不是"规范"，是它挂了立刻有人打电话。

问：全局编录是不是五个角色之外的第六个？不是。FSMO 回答"谁主持这件写操作"，GC 回答"这台域控存了多少林范围数据"，是两个维度。角色讲唯一，GC 讲多放几台更稳，判断逻辑正好相反。

问：有备份是不是就安全了？不一定，要看保质期。备份能否用于恢复，取决于它是否还在墓碑生存期之内——Windows Server 2003 SP1 及之后创建的林默认 180 天，更早的林默认 60 天。先查自己林的实际取值，再定备份轮换周期，并且周期要明显短于它、留出余量。

问：备份还原成功了，为什么删掉的对象没回来？因为你做的是非授权还原，还原出来后被其他域控上更新的删除记录覆盖回去了。要强制找回已删除对象，需要在非授权还原之后对特定对象做授权还原，让恢复状态反向复制出去。注意授权还原是针对特定对象的操作，不是整体开关。

问：虚拟机的快照能不能当域控备份？不能。快照回滚会造成 USN 回滚，导致域控与其他域控之间出现不报错的静默数据分歧。现代虚拟化平台通过 VM-Generation ID 让域控识别自己被回滚并采取保护措施，但这是兜底，不是备份手段。域控备份应当使用系统状态备份。

问：时间差个几分钟有什么关系？关系很大。Kerberos 依赖时间戳，客户端与域控的时间偏差默认容忍约 5 分钟，超出即认证失败。而且漂移是渐进的，故障表现是"陆续有人偶尔登不上"，很难往时间上想。域内时间应当走域层级，只有 PDC Emulator 配可靠的外部上游。

问：分支机构是不是都要放一台可写域控？看两件事：链路中断时是否必须能本地登录，以及机房物理安全有没有保障。前者决定要不要放，后者决定放可写域控还是 RODC。物理安全没保障的地方放可写域控，等于把整个域的写权限交给任何一个能碰到机器的人。

域控角色与恢复语义这一篇的参考来源说明

本文围绕 Active Directory 域服务的部署形态展开，涉及多主复制模型、五个 FSMO 操作主机角色、全局编录、站点与复制拓扑、系统状态备份与目录服务还原模式、墓碑生存期与恢复窗口、授权还原与非授权还原、Kerberos 时间约束、SYSVOL 从 FRS 到 DFSR 的复制机制、只读域控制器以及虚拟化环境下 USN 回滚与 VM-Generation ID 等内容，均为 Windows Server 域服务方向的通用技术知识梳理，用于架构设计与恢复方案讨论，不构成针对某一具体版本或某一具体环境的实施步骤。

文中提到的服务器承载形态、裸金属与虚拟机取舍、硬件故障自动迁移等，均为行业技术层面的分析，不代表任何特定服务商的承诺。本文为行业技术分析，涉及产品、配置与价格以签约时最新报价与合同为准，参考来源 https://www.idc10000.net/ 相关页面。