上周朋友咨询了一个问题，他们总公司 A.com 收购子公司 B.com，需要将 B.com 域下约 500 台已加入域的电脑迁移到 A.com 域，问如何操作比较好？他追求风险可控，我推荐了传统迁移方案

1. 场景概述

总公司 A.com 收购子公司 B.com，需要将 B.com 域下约 500 台已加入域的电脑迁移到 A.com 域。迁移有两种主要方式：

• 使用 ADMT 工具迁移（保留 SIDHistory）。
• 传统退域再加域方式（逐台退出 B.com 域再加入 A.com 域）。

2. ADMT 迁移方案

优点

• 保留 SIDHistory，用户和计算机仍能访问原有资源。
• 批量自动化迁移，效率高。
• 用户密码、组成员关系可保持。
• 业务中断时间短，用户无感知。

缺点

• 需要建立域信任关系，配置复杂。
• 需要部署 ADMT 工具和代理。
• 对网络和权限依赖较高。

适用场景

• 用户和权限复杂，资源依赖多。
• 需要大规模迁移，减少人工操作。

3. 传统退域再加域方案

优点

• 简单直观，操作可控。
• 不依赖复杂工具，网络独立性强。
• 在子公司部署 A.com DC 后，迁移过程更稳定。

缺点

• 工作量大，需逐台操作或脚本辅助。
• 用户配置文件可能丢失，需要重新映射。
• 权限需重新分配，无法保留 SIDHistory。
• 业务中断时间长。

适用场景

• 用户数较少，权限不复杂。
• 网络隔离严重，无法建立信任关系。

4. 对比表格

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 计算机迁移

• 使用 ADMT Agent 或 PowerShell 脚本批量迁移计算机对象。
• 迁移后计算机自动退出 B.com 域并加入 A.com 域。
• 每台计算机迁移完成后会重启。

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 组策略迁移

• 分析 B.com 的 GPO。
• 在 A.com 域中逐步迁移或重建策略。
• 在测试 OU 验证兼容性。

3.5 ACL 安全翻译

• 使用 ADMT Security Translation Wizard 或 PowerShell 脚本替换 ACL。
• 将资源权限从 B.com SID 替换为 A.com SID。
• 确保文件服务器、共享目录、应用权限正常。

3.6 应用与服务账号迁移

• 检查应用是否绑定 B.com 用户或组。
• 在 A.com 域中重新创建服务账号并更新配置。

3.7 分阶段退役 B.com

• 阶段 1：迁移用户和计算机，启用 SIDHistory。
• 阶段 2：执行 ACL 安全翻译。
• 阶段 3：验证资源访问。
• 阶段 4：逐步下线 B.com 域控制器。

4. 对象迁移前后对比表格

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. 迁移总体思路

• 在子公司部署 A.com 的域控制器，保证本地认证。
• 每台计算机逐步退出 B.com 域，再加入 A.com 域。
• 分批次执行，避免大规模业务中断。
• 手动或脚本辅助迁移，人工确认结果。

3. 操作步骤

3.1 准备阶段

• 在子公司部署 A.com 的域控制器。
• 确保网络、DNS、时间同步正常。
• 创建目标 OU，用于存放迁移后的计算机对象。
• 准备 A.com 域管理员账号。

3.2 逐台退域与加域

• 登录 B.com 域的计算机。
• 执行退域操作：将计算机退出 B.com 域，加入工作组。
• 执行加域操作：将计算机加入 A.com 域，指定 OU。
• 重启计算机，验证能正常登录 A.com 域。

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. 对象迁移前后对比表格

5. 风险与备份

• 风险点：用户配置丢失、权限需重建、工作量大、业务中断时间长。

• 备份建议：

  • AD 数据库备份（System State）。
  • 文件服务器 ACL 导出。
  • 用户配置文件备份。

6. 总结

• 传统退域再加域迁移方式简单直观，网络独立，风险可控。
• 缺点是工作量大、权限和配置需重新分配，业务中断时间长。
• 适用于用户数较少、权限不复杂、网络隔离严重的场景。