当企业应用虚拟化平台之后，很多系统管理员希望能将原有的域控物理机通过ESX或SCVMM等平台直接在OS层面进行迁移，而这种方法从我们的“IT经验”来看，通常认为是一种很正常很普遍的方法，但事实是往往在迁移完成之后才发现突然组策略不能用了、DNS区域不见了、AD复制很多错误、甚至AD互相无法识别对方。

         我们的客户当中很多遇到这种问题，部分客户直接进行操作之后，可能在开始一个月左右的时间，AD功能均正常，但在后面的时间里则发现AD复制及其功能均已出现严重的问题，整个AD系统濒临奔溃。而我今天所讨论的就是如何识别P2V迁移对AD的影响，以及我们推荐的AD迁移方法。

         关于域控通过P2V的方式直接迁移到虚拟机的操作，我们不推荐使用这种方法，因为迁移之后，可能导致USN（更新序列号）回滚，从而在未来一段时间内影响域控的复制和功能：

         1.什么是USN（更新序列号）：

         Windows Server 2003 域控制器将 USN 与调用 ID 结合使用来跟踪必须在 Active Directory 林中的复制伙伴之间复制的更新，源域控制器使用 USN 来确定请求更改的目标域控制器已经收到了哪些更改。目标域控制器使用 USN 来确定应从源域控制器请求哪些更改；

         2.可能导致USN回滚的软件或方法：

         a.启动某域控，而此域控的AD数据库文件是通过Ghost还原，或其他域控数据库文件复制得到；

         b.通过之前保存的AD虚拟硬盘镜像启动域控，创建虚拟宿主环境的快照或替代版本，或直接从镜像还原虚拟机；

         c.使用以前保存的操作系统映像；

         3.正常AD内容回滚支持方法：

        唯一支持用于回滚 Active Directory 内容或 Active Directory 域控制器状态的方法是：使用 Active Directory 感知备份和还原实用程序来还原系统状态备份，该备份来源于相同的操作系统安装，并来源于正在还原的相同物理或虚拟计算机；

         4.USN号回滚影响：

         如果发生了USN回滚，之前看到过该USN的目标域控制器将不会以入站方式复制对象和属性的修改内容，由于这些目标域控制器认为它们是最新的，同时Directory Service 事件日志中或监控和诊断工具不会报告任何复制错误，USN 回滚可能会影响任何分区中任何对象或属性的复制，最常见的副作用是：在回滚域控制器上创建的用户帐户和计算机帐户在一个或多个复制伙伴上不存在，或者，在回滚域控制器上更新的密码在复制伙伴上不存在；

         5.USN号回滚检测：

         可通过如下方式进行USN变化的查询，分别在DC（已进行P2V迁移的域控）和其复制对象上执行如下命令：repadmin /showutdvec “DCName”“partition-dn”，可查看DC本身存储到所有复制对象的USN值，在已完成复制的DC上，其他DC的USN值会保持不变，表示林内此AD的数据库更新状态，而对于发生USN回滚的DC，其本身标识的USN值和其复制对象查看到的USN值会产生差异，会导致其本身在林内复制出现问题；

         6.USN号回滚恢复方法：

         将此DC降级为成员服务器，确保林内没有DC的信息且此DC的任何操作主机角色已经转移，再将此DC进行升级并配置对应的站点，也可将回滚前的系统状态（不能为整个系统映像）进行还原，然后检查林内DC复制状态，此过程一定要确保DC进行降级之前已经完成系统状态备份；更详细的内容可参考KB：http://support.microsoft.com/?scid=kb;en-us;875495&x=1&y=17。

         而对于一般性AD迁移的需求，如AD硬件替换、AD升级、AD系统替换、平台迁移等，我们一般推荐使用域控升级降级的替换方法：

         假设将某名称为DC3的域控迁移到虚拟化平台为例：

         1.通过Ntbackup备份已有域控的系统状态，确认DC3上无其他数据与应用，如有其它应用和数据，建议提前做好备份，若有其他服务器需要指定到DC3的DNS服务器，建议暂时更改服务器的首选DNS指向；

         2.若域控上有DHCP，则建议进行DHCP迁移，步骤可参考：http://gnaw0725.blogbus.com/logs/29078557.html，若有其他相关应用则建议计划好迁移方案；

         3.在虚拟化平台中准备一台干净的操作系统，网络配置与计算机名配置保持与DC3相同，安装最新的补丁，配置时间等设置正确，但是暂时不接入网络；

         4.在另一台域控上通过如下命令确认操作主机角色不在DC3上：netdom query fsmo，若有相关的操作主机角色在DC3上，则需要进行操作主机角色转移，此时可参考KB：http://support.microsoft.com/kb/324801/zh-cn；

         5.将DC3的GC取消：在另一台域控上打开AD站点和服务管理器，选择到DC3下Ntds Setting，右键属性，将全局编录勾选去掉，然后子域内部进行手动复制，等大概十分钟确保GC取消已生效，其他域控复制正常；

         6.确认DC3不是本站点的桥头服务器，可在AD站点和服务管理器右键DC3属性查看，若为本站点桥头服务器，则建议进行更换后开始下面的操作；

         7.在DC3上运行Dcpromo，将此域控正常降级，然后退出域，若无法正常降级则需要进行强制离线然后清理垃圾对象，可参考KB：http://support.microsoft.com/kb/216498/zh-cn，若出现此情况，则需谨慎操作；

         8.正常降级后在AD中确认无DC3计算机对象，并手动复制域控；

         9.将已准备好的系统接入网络，确保配置与DC3相同，然后通过Dcpromo提升为域控；

         10.再将DC3设置为GC，打开AD站点和服务管理器，选择到DC3下Ntds Setting，右键属性，将全局编录勾选，然后子域内部进行手动复制，等大概十分钟确保GC已生效；

         11.再次将域内域控手动复制，确认复制已恢复正常，并测试域控功能是否正常，是否有应用受影响；