自动迁移时需要注意的要点

适用于：✔️ Windows VM ✔️ Linux VM ✔️ 本地环境 ✔️ 已启用 Azure Arc 的服务器

本文列出了在使用门户迁移工具或迁移脚本进行迁移时必须注意的重要详细信息。

重要提醒

• 不会迁移非 Azure 保存的搜索结果查询。

• 迁移和取消加入 Runbook 需要更新 Az.Modules 才能正常工作。

• 先决条件脚本将 Az.Modules 更新到最新版本 8.0.0。

• MRP 计划的 StartTime 等于软件更新配置的 nextRunTime。

• Log Analytics 中的数据不会迁移。

• 用户托管标识不支持跨租户方案。

• RebootOnly 设置在 Azure 更新管理器中不可用。 不会迁移具有 RebootOnly 设置的计划。

• 对于定期维护，自动化计划对每小时/每日/每周/每月计划支持 1 到 100 的值，而 Azure 更新管理器的维护配置对每小时计划支持和 6 到 35 的值，对每日/每周/每月计划支持 1 到 35 的值。 请看以下示例：

  自动化计划重复周期	维护配置计划定期计算
  100 小时	100/24 = 4.16（舍入到最接近的值）-> 每四天
  1 小时	每 6 小时一次，因为它是最小值
  100 天	100/7 = 14.28（舍入到最接近的值）-> 每 14 周
  100 周	100/4.34 = 23.04（舍入到最接近的值）-> 每 23 个月
  每 100 周一次，必须在星期五执行	23 个月 (100/4.34)。 但是，Azure 更新管理器无法指示该月的所有星期五每 23 个月执行一次，因此不会迁移计划。
  35 个多月前	35 个月定期

• SUC（软件更新配置）支持 30 分钟到 6 小时的维护时段。 MRP（维护资源提供程序）支持 1 小时 30 分钟到 4 小时。

  自动化更新管理中的维护时段	Azure 更新管理器中的维护时段
  30 分钟	1 小时 30 分钟
  6 小时	四小时

• 多次执行迁移 runbook 时，假设你执行了“迁移所有”自动化计划，然后再次尝试迁移所有计划，则迁移 runbook 会运行相同的逻辑。 如果 SUC 中有任何新的更改，再次执行此操作将更新 MRP 计划。 它不会进行重复的配置分配。 此外，仅针对启用了计划的自动化计划执行操作。 如果 SUC 之前已迁移，则会在下一轮跳过，因为它的基础计划将禁用。

• 最后，可以像在 Azure 更新管理器中一样从 Azure Resource Graph 解析更多计算机。 无法检查混合 Runbook 辅助角色是否报告，与自动化更新管理中不同，它是动态查询和混合 Runbook 辅助角色的交集。

• Azure 更新管理器中不支持的计算机不会迁移。 将部分迁移具有此类计算机的计划，并且仅将软件更新配置的受支持计算机移动到 Azure 更新管理器。 若要防止自动化更新管理和 Azure 更新管理器进行修补，请从自动化更新管理中的部署计划中删除迁移的计算机。

• 取消加入后：

  • 确保执行将完成以下操作的脚本：
    • 删除为迁移创建的自动化帐户变量 AzureAutomationAccountEnvironment。
    • 移除为从自动化帐户迁移而创建的用户托管标识。
    • 删除为迁移创建的用户托管标识的分配角色。
    • 删除为迁移创建的用户托管标识。
  • 若要运行上述脚本，你必须对包含自动化更新管理资源（如计算机、计划、日志分析工作区和自动化帐户）的所有订阅拥有 Microsoft.Authorization/roleAssignments/write 权限。 有关详细信息，请参阅如何分配 Azure 角色。
  • 此脚本应以与先决条件脚本相同的方式执行。

迁移后，软件更新配置可以具有以下四种迁移状态中的任何一种：

• 迁移失败
• 部分迁移
• 未迁移
• 已迁移

下表显示了与每个迁移状态关联的方案。

后续步骤

• 迁移概述
• 使用 Azure 门户进行迁移
• 使用 runbook 脚本进行迁移
• 手动迁移指南