上周朋友咨询了一个问题，他们总公司 A.com 收购子公司 B.com，需要将 B.com 域下约 500 台已加入域的电脑迁移到 A.com 域，问如何操作比较好？他追求风险可控，我推荐了传统迁移方案
1. 场景概述
总公司 A.com 收购子公司 B.com，需要将 B.com 域下约 500 台已加入域的电脑迁移到 A.com 域。迁移有两种主要方式：
2. ADMT 迁移方案
优点
- 保留 SIDHistory，用户和计算机仍能访问原有资源。
- 批量自动化迁移，效率高。
- 用户密码、组成员关系可保持。
- 业务中断时间短，用户无感知。
缺点
- 需要建立域信任关系，配置复杂。
- 需要部署 ADMT 工具和代理。
- 对网络和权限依赖较高。
适用场景
- 用户和权限复杂，资源依赖多。
- 需要大规模迁移，减少人工操作。
3. 传统退域再加域方案
优点
- 简单直观，操作可控。
- 不依赖复杂工具，网络独立性强。
- 在子公司部署 A.com DC 后，迁移过程更稳定。
缺点
- 工作量大，需逐台操作或脚本辅助。
- 用户配置文件可能丢失，需要重新映射。
- 权限需重新分配，无法保留 SIDHistory。
- 业务中断时间长。
适用场景
- 用户数较少，权限不复杂。
- 网络隔离严重，无法建立信任关系。
4. 对比表格
| 方案 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|
| ADMT迁移方案 | 保留SIDHistory，批量自动化，业务中断短 | 配置复杂，需工具和信任关系 | 大规模迁移，权限复杂 |
| 传统退域再加域方案 | 简单直观，网络独立，风险可控 | 工作量大，权限需重建，业务中断长 | 用户少，权限简单，网络隔离 |
5. 总结
- ADMT迁移方案 更适合大规模、权限复杂的场景，能保证迁移后资源访问不丢失。
- 传统退域再加域方案 更适合用户少、权限简单、网络隔离严重的场景，操作直观但工作量大。
- 最佳实践：在子公司部署 A.com DC，结合 ADMT 分批迁移用户和计算机，执行 ACL 安全翻译，最终退役 B.com 域。
ADMT 迁移方案介绍
1. 场景概述
总公司 A.com 收购子公司 B.com，需要将 B.com 域下约 500 台已加入域的电脑迁移到 A.com 域。迁移涉及用户账号、计算机对象、组策略、权限、应用兼容性等多个层面。
2. 迁移总体思路
- 建立 A.com 与 B.com 的双向信任关系。
- 使用 ADMT 或第三方工具迁移用户、组和计算机对象。
- 分批迁移计算机，避免业务全停。
- 保留 SIDHistory，确保权限不丢失。
- 分阶段迁移，逐步退役 B.com 域。
3. 操作步骤
3.1 准备阶段
- 在子公司部署 A.com 的域控制器，保证本地认证。
- 建立双向信任关系。
- 权限审计，确认 SIDHistory 需求。
- 搭建测试 OU，验证迁移工具和脚本。
3.2 用户与组迁移
- 使用 ADMT 迁移用户账号和组对象。
- 保留密码、组成员关系。
- 启用 SIDHistory，保证访问原有资源。
3.3 计算机迁移
PowerShell 脚本示例
$NewDomain = "A.com"
$OUPath = "OU=MigratedComputers,DC=A,DC=com"
$Cred = Get-Credential -Message "请输入 A.com 域管理员账号"
$ComputerList = Get-Content "C:\Temp\computers.txt"
foreach ($Computer in $ComputerList) {
Invoke-Command -ComputerName $Computer -ScriptBlock {
param($NewDomain, $OUPath, $Cred)
Add-Computer -DomainName $NewDomain -OUPath $OUPath -Credential $Cred -Force -Restart
} -ArgumentList $NewDomain, $OUPath, $Cred
}
3.4 组策略迁移
3.5 ACL 安全翻译
- 使用 ADMT Security Translation Wizard 或 PowerShell 脚本替换 ACL。
- 将资源权限从 B.com SID 替换为 A.com SID。
- 确保文件服务器、共享目录、应用权限正常。
3.6 应用与服务账号迁移
3.7 分阶段退役 B.com
- 阶段 1：迁移用户和计算机，启用 SIDHistory。
- 阶段 2：执行 ACL 安全翻译。
- 阶段 3：验证资源访问。
- 阶段 4：逐步下线 B.com 域控制器。
4. 对象迁移前后对比表格
| 对象类型 | 迁移前 (B.com 域) | 迁移后 (A.com 域) | 备注 |
|---|---|---|---|
| 用户账号 | 存在于 B.com 域，SID 属于 B.com | 在 A.com 域生成新账号，保留属性并启用 SIDHistory | 保证访问原有资源 |
| 用户组 | 存在于 B.com 域 | 在 A.com 域生成对应组对象 | 确认嵌套组关系 |
| 计算机对象 | 加入 B.com 域 | 在 A.com 域生成新对象并加入域 | 迁移后重启 |
| 组策略 | 应用 B.com 策略 | 在 A.com 域重建或迁移策略 | 需验证兼容性 |
| 文件/共享权限 | ACL 基于 B.com SID | ACL 替换为 A.com SID | 使用 Security Translation |
| 域控制器 | B.com DC 提供认证 | A.com DC 提供认证 | 逐步退役 B.com DC |
5. 风险与备份
- 风险点：用户权限丢失、应用依赖旧域、批量迁移导致业务停顿。
备份建议：
- AD 数据库备份（System State）。
- 文件服务器 ACL 导出。
- 回滚脚本（重新加入 B.com 域）。
6. 总结
- SIDHistory 是过渡方案，保证迁移过程中访问正常。
- 废除 B.com 前必须完成 ACL 安全翻译，确保权限完全迁移到 A.com SID。
- 最佳实践：在子公司部署 A.com DC，结合 ADMT 分批迁移用户和计算机，执行 ACL 安全翻译，最终退役 B.com 域。
传统退域再加域迁移介绍
1. 场景概述
在子公司搭建一台 A.com 域的域控制器，然后逐台将 B.com 域下的计算机退域，再加入到 A.com 域。这是一种传统的、人工可控的迁移方式。
2. 迁移总体思路
3. 操作步骤
3.1 准备阶段
3.2 逐台退域与加域
PowerShell 脚本示例（单机）
Add-Computer -DomainName "A.com" -OUPath "OU=MigratedComputers,DC=A,DC=com" -Credential (Get-Credential) -Force -Restart
3.3 分批迁移
- 每次迁移 20~50 台，避免大规模同时重启。
- 迁移完成后，验证用户登录和应用访问。
3.4 用户与权限处理
- 在 A.com 域中重新创建用户账号。
- 手动分配文件服务器、共享目录、应用权限。
- 用户配置文件可能需要重新映射或迁移。
3.5 组策略迁移
- 在 A.com 域中重新创建或导入组策略。
- 在测试 OU 验证策略兼容性。
3.6 分阶段退役 B.com
- 阶段 1：完成计算机迁移。
- 阶段 2：完成用户账号和权限重建。
- 阶段 3：验证所有资源访问正常。
- 阶段 4：逐步下线 B.com 域控制器。
4. 对象迁移前后对比表格
| 对象类型 | 迁移前 (B.com 域) | 迁移后 (A.com 域) | 备注 |
|---|---|---|---|
| 用户账号 | 存在于 B.com 域 | 在 A.com 域重新创建 | 权限需重新分配 |
| 计算机对象 | 加入 B.com 域 | 手动退域再加入 A.com 域 | 每台需重启 |
| 组策略 | 应用 B.com 策略 | 在 A.com 域重建策略 | 需验证兼容性 |
| 文件/共享权限 | ACL 基于 B.com SID | 需重新分配给 A.com 用户 | 无 SIDHistory 保留 |
| 域控制器 | B.com DC 提供认证 | A.com DC 提供认证 | 逐步退役 B.com DC |
5. 风险与备份
- 风险点：用户配置丢失、权限需重建、工作量大、业务中断时间长。
备份建议：
- AD 数据库备份（System State）。
- 文件服务器 ACL 导出。
- 用户配置文件备份。
6. 总结
- 传统退域再加域迁移方式简单直观，网络独立，风险可控。
- 缺点是工作量大、权限和配置需重新分配，业务中断时间长。
- 适用于用户数较少、权限不复杂、网络隔离严重的场景。