企业官网建设流程全解析

简介：面向Windows Server管理员及企业IT运维人员，这份资源围绕主域控、辅助域控的搭建与主域控制器迁移，提供基于Windows Server 2003环境的完整操作指南。内容从环境准备与域名规划讲起，明确主辅机IP与DNS指向，再逐步说明dcpromo安装活动目录、域控制器类型选择、DNS全名与NETBIOS名称设置、添加现有域额外域控制器等关键步骤；同时覆盖RID、PDC、基础结构、域命名、架构五类FSMO角色的图形界面及ntdsutil命令行迁移方式，并补充域控损坏时使用seize强制夺取角色的恢复思路，以及全局编录的调整方法。文档结构清晰，便于按步骤对照操作，可帮助读者理解主辅域控协作机制，避开角色转移中的常见误区。资源包共1个docx文档，大小566KB，单文件却分量十足，适合作为域控迁移、排错与日常维护的速查手册。目前已有2060人学习下载，可供网络管理员直接参考。

1. 主域控和辅助域控：一套能直接照抄的AD迁移方案

公司里那台跑着Windows Server 2003的主域控已经连续运行了快一年，没有人敢重启它，因为整个域的账号、组策略、DNS记录全绑在这台机器上。主域控、辅助域控的搭建以及主域控制器的迁移这件事，听起来是教科书里的标准章节，真到自己动手时才发现坑都在细节里。这份笔记拆的就是一套完整方案：先拿dcpromo装出主域控，再加一台辅助域控做复制，最后把五大FSMO角色和全局编录迁过去。全程用两台虚拟机就能复现，适合刚接手AD域环境的运维照着敲，也能当迁移前的检查清单用。

2. dcpromo装出第一台主域控：七个向导选项与系统状态备份

2.1 环境清单：两台Server 2003的命名与IP规划

搭域控之前先把环境钉死，后面出问题才好排查。原文用的是Microsoft Windows Server 2003 Enterprise Edition，主计算机名叫A，辅助计算机名叫B，域名叫Jiajie.com，NetBIOS名JIAJIE。注意主机名A和B是短名，不是FQDN，这在dcpromo向导里会直接用到。

生产环境里我一般会把DNS指向写清楚，域名解析是域控能不能正常工作的前提。2003对DNS的要求是必须支持SRV记录，Windows自带的DNS服务就行。搭建前确认两台机器在同一网段能互通，主机名不要带下划线，不然后面注册SRV记录时会翻车。

2.2 dcpromo向导：从域控制器类型到DNS注册诊断

主域控安装的核心入口是“开始→运行→输入dcpromo”。这个命令会拉起Active Directory安装向导，整个过程中有七个选项值得单独说明，因为它们决定了域的结构和后续维护方式。

第一个选项是“域控制器类型”，这里选“新域的域控制器”。第二个是“创建一个新域”，选“在新林中的域”，意思是这是一个全新的AD森林根域，不是子域也不是树域。第三个是输入DNS全名Jiajie.com，这是AD域的完整域名，DNS区域会自动创建。第四个是NetBIOS名JIAJIE，这是老协议下客户端访问用的短名，2003时代很多老旧应用依赖这个短名做认证，不建议随便改。

第五个选项是活动目录数据库和日志文件的存储位置，默认在C:\WINDOWS\NTDS。生产环境建议放到非系统盘，数据库和日志最好分盘放，日志写满会导致AD数据库无法写入。第六个是SYSVOL共享卷的位置，默认C:\WINDOWS\SYSVOL，这个目录会被DFS复制到其他域控，迁移时整个目录结构要一起迁移。第七个是DNS注册诊断选项，向导执行到最后会做一次DNS注册测试，选第二项“在这台计算机上安装并配置DNS服务器，并将这台DNS服务器设为首选DNS服务器”，这样向导会顺手把DNS服务装好。如果不选这一项，后面就要手动建DNS区域和SRV记录，很折腾。

权限兼容级别选“Windows 2000或Windows Server 2003兼容”，这个选项影响匿名用户对域信息的读取权限，选兼容模式能照顾老客户端，安全性靠密码策略和防火墙兜底。目录服务还原密码adchina要记住，这个密码不是登录域用的，是以后进目录服务还原模式修复AD数据库时用的，忘了就只能重置。

安装完成后重启，主域控A就算立起来了。重启后可以在“管理工具”里看到Active Directory相关的三个管理单元：AD用户和计算机、AD域和信任关系、AD站点和服务。这三个工具后面迁移FSMO角色时都要用到。

注意：dcpromo不是光下一步下一步就行。中间有一个步骤要选择是否把DNS服务器装在本机，生产环境如果域内已经有DNS服务器，可以选“否”，然后在DNS服务器上手动创建_jldap、_kerberos这些SRV记录。测试环境直接选第二项最省事。

2.3 用ntbackup备份系统状态：迁移前的后悔药

主域控搭好后，第一件该做的事情不是急着加辅助域控，而是做一次系统状态备份。原文在迁移章节里也提到了，运行里输入ntbackup，选中System State备份。系统状态里包含AD数据库、SYSVOL、注册表、Com+数据库、启动文件，这一整套是域控的完整快照。

备份命令可以写成这样：

ntbackup backup systemstate /J "AD Backup" /F "D:\backup\ad.bkf"

参数说明：backup systemstate是备份系统状态；/J后面跟作业名，方便区分备份集；/F指定备份文件的完整路径。备份文件是.bkf格式，恢复时还是用ntbackup，选“还原向导”把备份文件指过去就行。

这个备份文件就是迁移的后悔药。FSMO角色迁移过程中如果某个角色转移失败，或者辅助域控接替后AD数据库损坏，可以靠系统状态备份把原域控恢复到迁移前的状态。2003的AD数据库有事务日志机制，备份必须完整，不能中途断电。备份完成后到D盘确认.bkf文件大小，一般几十MB到几百MB都正常，小于10MB就要怀疑备份是否完整。

3. 辅助域控搭建：IP指向、额外域控制器与复制验证

3.1 辅助域控的IP与DNS：先让两台机器能互相找到

辅助域控B的搭建和主域控A有一个关键区别：A是白手起家，B是加入一个已经存在的域。B的IP地址1.1.1.2，子网掩码255.0.0.0，DNS服务器指向主域控的IP 1.1.1.1。这一条很关键，DNS必须指向主域控，因为B要通过DNS查找到A的SRV记录，才能定位域的LDAP服务和Kerberos服务。

配置完IP后，先做连通性验证。ping 1.1.1.1通了只说明网络通，还要验证DNS解析能正常工作。在生产环境里我一般会顺手跑一下nslookup jiajie.com，能看到DNS服务器地址和域的SOA记录，说明DNS区域已经从A同步到了B的DNS缓存视角，起码证明B能用DNS找到域。

原文只提了检查主辅是否相通，实际操作时还要确认时间同步。域认证对时间敏感，Kerberos票据的有效期默认5分钟，两台机器时间差超过5分钟认证就会失败。2003默认用W32Time服务，B加入域后会自动和A同步时间，这一步不需要手动设置，但如果A本身时间不准，整个域的时间都会跟着偏。

3.2 现有域的额外域控制器：dcpromo的第二种玩法

B的域控安装同样是dcpromo，区别在第4步的选项。此时域控制器类型不用选“新域的域控制器”，而是选“现有域的额外域控制器”，这一步等同于告诉向导：域Jiajie.com已经存在，我这是加一台冗余机器，不是新建一个域。

后续向导会要求输入有权限的用户名、密码和域，这是用来验证是否有权限向现有域添加域控的账号，常见的做法是直接用域管理员账号，原文用的就是这个方式。然后输入要加入的域名Jiajie.com，向导会通过DNS查找到主域控A，并连接它完成复制初始化。

目录服务还原密码这里设置为adchina，和主域控保持一样。这个密码和域的认证体系无关，纯粹是每台域控本地的DSRM密码，两台域控可以不一样，但运维习惯上我建议设成同一个，避免以后重启进恢复模式时记混。

安装完成后重启B。此时B已经变成Jiajie.com域的额外域控制器，AD数据库从A完整复制了一份过来，SYSVOL也会通过文件复制服务初始化。如果步骤中报错“找不到域控制器”，八成是DNS指向不对或者SRV记录没注册成功，回到A上检查DNS区域的记录有效性。

注意：辅助域控的计算机名B在安装前不能已经加入域，否则dcpromo会疑惑你要做的是“额外域控制器”还是“域成员服务器降级”。干净的系统是最省心的。

3.3 验证主辅复制：数据能不能及时同步到辅助域控

主辅域控搭好后，要验证AD数据能不能从A复制到B。原文说“经测试，主域控制器的数据能及时复制到辅助域控上面”，这个验证动作在2003下有几个标准操作。

第一种是在A上用AD用户和计算机新建一个测试用户，然后到B上打开AD用户和计算机，看这个用户有没有同步过来。AD复制默认是15秒间隔，多站点会调整间隔，单站点下基本几秒到几十秒内就能看到。如果等了1分钟还看不到，考虑强制复制。

第二种是主动触发一次复制，不干等：

repadmin /syncall /AdeP

repadmin是AD复制诊断工具，2003自带。/syncall表示同步所有复制伙伴，/A指所有目录分区，/e是enterprise模式，/P是push模式。这条命令在任意一台域控上执行，会把所有目录分区强制同步一遍。

复制验证通过后，辅助域控B才真正具备接替主域控的资格。如果这一步复制不完整，后边做FSMO迁移时，B上会缺数据，用户密码改了B那边不生效，登录验证还打到A上，问题非常隐蔽。

4. FSMO角色迁移：五大主机与全局编录的图形化转移

4.1 迁移前提：备份域控、夺取角色、设置全局编录三步走

迁移主域控制器不是把A关机然后让B顶上这么简单。AD域里有五个FSMO角色，它们分别是架构主机、域命名主机、PDC仿真主机、RID主机和基础结构主机。这五个角色决定了谁有权限修改AD架构、谁分配RID池、谁做密码主控。A作为主域控，这五个角色全部挂在A上，B上面一个都没有。

原文的迁移思路很明确：第一步先做系统状态备份，第二步把FSMO角色迁移到B，第三步设置全局编录。全局编录不是FSMO角色，它是林内对象查询的目录数据库，A默认自己就是GC，B在默认安装时不是GC，需要手动勾选。

顺序上我建议先迁移RID、PDC、基础结构这三个域级别的角色，再迁移树级别的域命名主机，最后迁移林级别的架构主机。这样做的原因是架构主机和域命名主机一迁移，就代表整个林的“管理权”正式交棒，最后再动它比较稳妥。

4.2 RID、PDC、基础结构主机：在AD用户和计算机里一次搞定

RID、PDC、基础结构主机这三个角色的迁移都在同一个工具里完成，就是“Active Directory用户和计算机”。在B上打开这个管理单元，左侧域名Jiajie.com上右击，选择“连接到域控制器”，弹窗里选中B，确定。这一步保证当前控制台连接的是B而不是A，后续“操作主机”按钮点出来才是B的视角。

然后还是在域名上右击，点“操作主机”，弹出的窗口有RID、PDC、基础结构三个标签页。先切到RID标签页，点击“更改”，系统会弹确认框，询问是否将角色迁移到B，点确定。PDC和基础结构标签页操作一模一样，依次切换并更改。

这三个角色迁移完成后，B已经能响应密码修改请求、分配RID池、维护对象引用。验证方式很简单，在B上打开AD用户和计算机，新建一个用户，能正常创建说明RID分配正常。如果把A关机，B上依然能改密码，说明PDC仿真主机角色已经生效。

4.3 域命名主机迁移：AD域和信任关系的连接与更改

域命名主机负责林内域的添加、删除和信任关系变更。它的迁移工具是“Active Directory域和信任关系”，在B上打开后，右击根节点“Active Directory域和信任关系”，选择“连接到域控制器”，选中B，确定。这一步和前面操作思路一致，先把控制台指向B。

接着右击同一个根节点，点“操作主机”，弹窗里点击“更改”，确认后域命名主机角色就从A转移到了B。整个操作只有两步，但很多人在第一步就翻车——没有先“连接到域控制器”，导致操作主机窗口点开后里面显示的还是A，角色根本迁不走。

域命名主机迁移完成后，可以在B上执行下面的验证命令，确认角色归属：

netdom query fsmo

netdom query fsmo会列出当前五个FSMO角色分别归属哪台机器。2003自带netdom，这条命令比在图形界面里点来点去直观得多，我每次迁移完都会跑一遍确认五个角色和预期完全一致。

4.4 架构主机迁移：先注册schmmgmt.dll再改操作主机

架构主机是最容易卡住的一步，因为“Active Directory架构”这个管理单元默认不显示，需要手动注册。原文档的做法是先用命令注册组件：运行cmd，然后执行下面的命令：

regsvr32 schmmgmt.dll

regsvr32是Windows的组件注册工具，schmmgmt.dll是AD架构管理单元的动态链接库。注册成功后回显“DllRegisterServer in schmmgmt.dll succeeded”。这一步不做，后面MMC里就找不到“Active Directory架构”选项。

架构管理单元注册完，打开MMC控制台，按Ctrl+M打开“添加/删除管理单元”，点“添加”，选中“Active Directory架构”，依次点“添加”、“关闭”、“确定”。此时MMC里出现AD架构节点。右击这个节点，选择“更改域控制器”，再选“指定名称”，输入辅助域控B的计算机名，确定。最后右击“Active Directory架构”，点“操作主机”，点击“更改”，按提示确认。

这里的坑在于“更改域控制器”这一步很容易被跳过。如果直接点“操作主机”，弹出的窗口里显示的当前架构主机还是A，更改按钮是灰的。必须先切换，再更改，顺序不能反。架构主机迁移完后，整个林的架构操作权限都归B管，理论上可以在B上扩展Schema、升级AD版本。

4.5 全局编录迁移：站点和服务里的一个勾选开关

全局编录本身不是FSMO角色，但它决定了域控能不能响应林范围内的对象查询。A默认是GC，B要手动设置。工具是“Active Directory站点和服务”，打开后右击根节点，选择“连接到域控制器”，选中B，确定。

然后依次展开Sites、Default-First-Site-Name、Servers、DCA，右击NTDS Settings，选择“属性”，把“全局编录”前面的勾去掉。这一步是在告诉A：你不再承担全局编录职责。接着展开B节点，同样右击NTDS Settings，属性里把“全局编录”勾上，确定。

这一取消一勾选之间，全局编录就完成了从A到B的迁移。注意顺序不能反，如果先给B勾上再取消A，中间会有两台GC并存；如果先取消A再勾B，整个域在同步完成前会出现一个没有GC的空窗期，用户登录和查询都会受影响。迁移完成后到B上用端口检查工具验证一下，GC监听3268端口，能连上说明服务正常。可以这样确认：

netstat -an | findstr 3268

netstat -an列出所有监听端口，findstr 3268过滤出全局编录服务的端口。能查到3268端口在监听，说明B的全局编录已经生效。五个FSMO角色加全局编录至此全部迁移完毕，旧主域控A从理论上讲已经可以降级退役了。

5. ntdsutil命令行迁移：transfer与seize的实操边界

5.1 正常转移RID主机角色的七条命令

图形界面迁移角色适合一台台点，如果手上只有命令行通道——比如机器远程连接断了桌面、或者想写成脚本定时执行，命令行方式更可靠。原文档用的是ntdsutil，这套命令是Windows AD域控运维必须掌握的工具。

以转移RID主机为例，完整命令序列如下：

ntdsutil roles connection connect to server B.jiajie.com quit transfer RID master quit

逐条解释：ntdsutil进入交互式环境；roles进入FSMO角色维护子命令；connection进入服务器连接；connect to server B.jiajie.com指定目标服务器为B的FQDN；quit返回角色维护层；transfer RID master执行RID主机角色转移；最后的quit退出ntdsutil。

每条命令执行后都有反馈。connect to server成功后回显“绑定到 B.jiajie.com... 已连接”，transfer RID master执行后会有角色转移确认，提示“传送 RID 主机的角色...”并等待完成。如果连接失败，常见报错是无法解析目标服务器名。这时候检查B的FQDN能不能ping通、DNS能不能解析。生产环境里我一般直接用IP连接，格式是connect to server 1.1.1.2，少一层DNS解析，排查起来更直接。

转移其他角色只是最后一条命令不同，完整命令对照如下：

5.2 原DC宕机时强行夺取角色：seize命令序列

如果原DC已经无法启动，transfer是执行不了的。原文档给了一套完全不同的命令序列，核心是seize命令。以RID主机为例：

ntdsutil roles connection connect to server B.jiajie.com quit seize RID master quit

命令的结构和transfer一致，区别只在于最后一条。seize的中文意思是“占用”，它会跳过与原DC的协商过程，直接把角色从合法FSMO持有者手里强夺过来。

强夺角色过程中ntdsutil会弹出一个确认对话框，提示“尝试传送并占用...的角色”。此时原DC离线，传输必定失败，ntdsutil会询问是否继续执行占用，选“是”即可。这个过程的工作原理是：先尝试在主DC在线的情况下优雅传输，失败后直接把角色记录写入被占用DC的AD数据库中。原DC如果只是网络隔离而没关机，后续恢复联网后会形成角色冲突，这是seize操作最大的风险。

所有可用的seize命令：

5.3 transfer和seize怎么选：正常迁移与故障恢复的分界线

transfer和seize是两种完全不同的操作，决策依据就是一条：原DC还在不在线。原DC在线、网络通畅，用transfer，角色是堂堂正正交接过去的，不会有历史遗留问题。原DC已经物理损坏、系统崩溃、或者网络彻底失联，用seize。

两者的风险差异在旧DC复活时会集中爆发。transfer后旧DC如果再启动，它会通过复制机制发现FSMO角色已经归属B，然后自动放弃自己的角色。seize后旧DC如果再启动，它依然认为自己是合法FSMO持有者，会尝试向B抢回角色，导致AD数据库出现级别冲突，甚至目录分区复制直接中断。

被seize的旧DC重新上线前，必须先把它的AD数据做非授权还原，或者直接强制降级再重新提升成普通域成员。生产环境里，我对被seize的机器一律建议拿系统状态备份做一次authoritative恢复，或者干脆放弃那台机器，新建一台干净系统再提升为辅助域控。

注意：seize操作要在业务低谷期执行，因为强夺角色后整个域的复制拓扑要重新收敛，期间用户认证可能受影响。执行完seize后，立刻在B上运行repadmin /showrepl检查复制是否恢复正常，发现复制失败要马上处理，不能拖。

6. 避坑与验证：五个最容易翻车的AD域控迁移细节

6.1 现象：IP用了1.1.1.1网段，DNS解析时好时坏

原文档里主域控和辅助域控都用的是1.1.1.1/255.0.0.0这个地址段。这个段属于公网地址，在真机上会和其他公网设备冲突，部分内网防火墙也会拦截公网IP的内网流量。原因：示例环境用了非私有地址段当内网IP。解决：复现时按私有地址段改，例如主域控192.168.10.10、辅助192.168.10.20，DNS指向保持不变。地址段变了不影响dcpromo和迁移流程。

6.2 现象：dcpromo向导里DNS注册诊断报错

搭建主域控时向导执行到DNS注册诊断，报“无法注册SRV记录”或者“DNS服务器不响应”。原因：本机DNS指到了自己但DNS服务还没装好，或者防火墙挡了UDP 53端口。解决：选第二项让向导自动配置DNS，确认防火墙放行UDP 53和TCP 53，跑nslookup -type=srv _ldap._tcp.jiajie.com验证SRV记录是否注册成功。

6.3 现象：迁移没做系统状态备份，出问题只能从头搭

迁移过程中架构主机转移失败，AD数据库损坏，想恢复到迁移前没有可用的系统状态备份，只能重装系统和AD环境。原因：把迁移顺序当成了唯一保障，忽略了备份恢复这条后路。解决：每次迁移前先执行ntbackup系统状态备份，备份文件存到另一台机器或移动硬盘，恢复演练至少做一次，确认.bkf文件能正常读取。

6.4 现象：seize之后旧DC复活，域里出现两个主域控

新迁移的DCB正常服务了一段时间，旧主域控A被修复后重新开机，域内用户开始间歇性认证失败。原因：A还认为自己是FSMO角色持有者，和B抢角色。解决：A重新开机前必须做降级处理，用dcpromo把A降为成员服务器；如果A已经开机，立刻断网隔离，然后强制降级；改A为普通域成员后，再开B验证所有角色归属netdom query fsmo都指向B。

6.5 现象：全局编录没勾上，域用户登录越来越慢

迁移完FSMO后，域用户登录工作站时等待时间变长，有时超过1分钟。原因：A的全局编录被取消，B又没有勾选，域内暂时没有GC响应林范围查询。解决：回到AD站点和服务，确认B的NTDS Settings属性里全局编录处于勾选状态，用netstat -an | findstr 3268确认GC端口监听正常，之后用户登录速度恢复。

从那以后我每次做域控迁移都强制走一遍固定的验证清单：迁移前确认系统状态备份存在且可恢复，迁移中按域级角色到林级角色顺序操作，迁移完用netdom查询角色归属，用repadmin确认复制正常，用netstat确认GC端口在听。这套习惯帮我挡下了至少两次能让人加班到凌晨的故障。希望帮到你。

本文还有配套的精品资源，点击获取