通过

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

  • 项目

适用于：✔️ 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 更新管理器进行修补，请从自动化更新管理中的部署计划中删除迁移的计算机。

  • 取消加入后：

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

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

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

迁移失败 部分迁移 未迁移 已迁移
未能为软件更新配置创建维护配置 未应用补丁设置的计算机数非零。
例如，如果 Azure 更新管理器不支持计算机，则软件更新配置的状态将部分迁移。		 由于某些客户端/服务器错误（例如内部服务错误），无法从 API 获取软件更新配置。 补丁设置应用失败的机器数量为零
以及
配置分配失败的机器数量为零。
以及
无法解析未能对 Azure Resource Graph 执行查询的动态查询为零。
以及
零动态范围配置分配失败
以及
软件更新配置没有保存搜索查询。
配置分配失败的计算机数非零。 软件更新配置的重新启动设置为仅重启。 Azure 更新管理器目前不支持此功能。
无法解析未能对 Azure Resource Graph 执行查询的动态查询数非零。 软件更新配置在 DB 中没有成功的预配状态。
动态范围配置分配失败数非零。 软件更新配置在 DB 中处于错误状态。
软件更新配置具有保存的搜索查询。 与软件更新配置关联的计划在迁移时已过期。
软件更新配置具有尚未成功迁移的预/后任务 已禁用与软件更新配置关联的计划。
迁移软件更新配置时未经处理的异常。

后续步骤