从自动化更新管理移动到 Azure 更新管理器

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

本文提供将虚拟机从自动化更新管理迁移到 Azure 更新管理器的指导。

Azure 更新管理器提供 SaaS 解决方案，用于管理和治理跨 Azure、本地及多云环境的 Windows 和 Linux 计算机的软件更新。 它是 Azure 自动化更新管理解决方案的演变，具有新的特色和功能，用于在单台计算机或多台计算机上大规模评估和部署软件更新。

对于 Azure 更新管理器，AMA 和 MMA 都不是管理软件更新工作流的要求，因为它依赖于适用于 Azure VM 的 Azure VM 代理和适用于已启用 Arc 的服务器的 Azure 连接计算机代理。 首次在计算机上执行更新操作时，会将扩展推送到计算机，并与代理交互以评估缺少的更新并安装更新。

Azure 门户体验

本部分介绍如何使用门户体验将计划和计算机从自动化更新管理移动到 Azure 更新管理器。 只需最少的单击和自动化方式移动资源，如果没有基于自动化更新管理解决方案构建的自定义项，这就是最简单的移动方式。

若要访问门户迁移体验，可以使用多个入口点。

选择以下入口点上存在的“立即迁移”按钮。 选择后，将指导你完成将计划和计算机移动到 Azure 更新管理器的过程。 此过程设计为用户友好型，且操作直截了当，使你能够轻松完成迁移。

可以从以下任一入口点迁移：

迁移脚本

使用迁移 runbook，可以将所有工作负载（计算机和计划）从自动化更新管理自动迁移到 Azure 更新管理器。 本部分详细介绍如何运行脚本、脚本在后端执行的操作、预期行为以及任何限制（如果适用）。 该脚本可以一次性迁移一个自动化帐户中的所有计算机和计划。 如果有多个自动化帐户，则必须为所有自动化帐户运行 runbook。

概括而言，需要执行以下步骤，将计算机和计划从自动化更新管理迁移到 Azure 更新管理器。

先决条件摘要

1. 将非 Azure 计算机加入 Azure Arc。
2. 下载并运行 PowerShell 脚本，以便在系统上本地创建用户标识和角色分配。 请参阅分步指南中的详细说明，因为它也有某些先决条件。

步骤摘要

1. 运行迁移自动化 runbook，以便将计算机和计划从自动化更新管理迁移到 Azure 更新管理器。 请参阅分步指南中的详细说明。
2. 运行清理脚本以从自动化更新管理注销。 请参阅分步指南中的详细说明。

不支持的方案

• 不会迁移非 Azure 保存的搜索查询；必须手动迁移这些内容。

有关要注意的限制和事项的完整列表，请参阅本文的最后部分。

分步指南

下面详细介绍上述每个步骤中提到的信息。

先决条件 1：将非 Azure 计算机加入 Arc

如何操作

迁移自动化 runbook 会忽略未加入 Arc 的资源。因此，在运行迁移 runbook 之前，必须先将所有非 Azure 计算机加入 Azure Arc。 按照步骤将计算机加入 Azure Arc。

先决条件 2：通过运行 PowerShell 脚本创建用户标识和角色分配

A. 运行脚本的先决条件

• 在 PowerShell 中 Install-Module -Name Az -Repository PSGallery -Force 运行命令。 先决条件脚本取决于 Az.Modules。 如果 Az.Modules 不存在或已更新，则需要执行此步骤。
• 若要运行此先决条件脚本，必须对包含自动化更新管理资源（如计算机、计划、日志分析工作区和自动化帐户）的所有订阅拥有 Microsoft.Authorization/roleAssignments/write 权限。 请参阅如何分配 Azure 角色。
• 你必须具有更新管理权限。

B. 运行脚本

在本地下载并运行 PowerShell 脚本 MigrationPrerequisiteScript。 此脚本采用自动化帐户的 AutomationAccountResourceId 作为输入进行迁移。

可以通过自动化帐户>属性来提取 AutomationAccountResourceId。

°C 验证

运行脚本后，验证是否已在自动化帐户中创建用户托管标识。 自动化帐户>标识>用户分配。

D. 脚本的后端操作

1. 更新自动化帐户的 Az.Modules，这是运行迁移和卸载脚本所必需的操作。

2. 在与自动化帐户相同的订阅和资源组中创建用户标识。 用户标识的名称类似于 AutomationAccount_aummig_umsi。

3. 将用户标识附加到自动化帐户。

4. 脚本将以下权限分配给用户托管标识：需要更新管理权限。

   1. 为此，脚本会提取在此自动化帐户下加入自动化更新管理的所有计算机，并分析其订阅 ID，以便将所需的 RBAC 提供给用户标识。
   2. 脚本为自动化帐户所属的订阅上的用户标识提供适当的 RBAC，以便可以在此处创建 MRP 配置。
   3. 脚本会为 Log Analytics 工作区和解决方案分配所需的角色。

5. 注册 Microsoft.Maintenance 和 Microsoft.EventGrid 资源提供程序所需的订阅。

步骤 1：迁移计算机和计划

此步骤涉及使用自动化 runbook 将所有计算机和计划从自动化帐户迁移到 Azure 更新管理器。

请按照这些步骤进行操作：

1. 从 runbook 库导入迁移 runbook 并发布。 从浏览库搜索 azure 自动化更新，导入名为“从 Azure 自动化更新管理迁移到 Azure 更新管理器”的迁移 runbook 并发布该 runbook。

   

   Runbook 支持 PowerShell 5.1。

   

2. 将 runbook 的详细日志记录设置为 True。

   

3. 运行 runbook 并传递所需的参数，例如 AutomationAccountResourceId、UserManagedServiceIdentityClientId 等。

   

   1. 可以从自动化帐户>属性提取 AutomationAccountResourceId。

      

   2. 可以从自动化帐户>标识>用户分配>标识>属性>客户端 ID提取 UserManagedServiceIdentityClientId。

      

   3. 将 EnablePeriodicAssessmentForMachinesOnboardedToUpdateManagement 设置为 TRUE 将在加入自动化更新管理的所有计算机上启用定期评估属性。

   4. 将 MigrateUpdateSchedulesAndEnablePeriodicAssessmentonLinkedMachines 设置为 TRUE会将自动化更新管理中的所有更新计划迁移到 Azure 更新管理器，同时在链接到这些计划的所有计算机上将定期评估属性设为 True。

   5. 需要指定 ResourceGroupForMaintenanceConfigurations，其中将创建 Azure 更新管理器中的所有维护配置。 如果提供新名称，则会创建资源组，其中将创建所有维护配置。 但是，如果提供资源组已存在的名称，则会在现有资源组中创建所有维护配置。

4. 检查 Azure Runbook 日志，了解 SUC 的执行状态和迁移状态。

   

后端的 Runbook 操作

Runbook 的迁移执行以下任务：

• 在所有计算机上启用定期评估。
• 自动化帐户中的所有计划都将迁移到 Azure 更新管理器，并为每个计划创建相应的维护配置，每个计划都具有相同的属性。

关于脚本

下面是迁移脚本的行为：

• 检查使用输入的名称的资源组是否已存在于自动化帐户订阅中。 如果没有，请使用客户指定的名称创建资源组。 此资源组将用于为 V2 创建 MRP 配置。

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

• 筛选掉处于错误/已过期/提供失败/禁用状态的 SUC，并将其标记为“未迁移”，然后输出指示不会迁移此类 SUC 的相应日志。

• 配置分配名称是一个字符串，格式为 AUMMig_AAName_SUCName

• 了解此动态作用域是否已通过检查 Azure Resource Graph 分配给维护配置。 如果未分配，则仅以 AUMMig_ AAName_SUCName_SomeGUID格式分配名称。

• 对于配置了预/后任务的计划，脚本将为预/后任务中的 Runbook 创建自动化 Webhook，并为预/后维护事件创建事件网格订阅。 有关详细信息，请参阅 Azure 更新管理器中的预/后工作原理

• 汇总的一组日志将输出到输出流，以便提供计算机和 SUC 的总体状态。

• 详细日志将输出到详细流。

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

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

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

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

若要从上表中找出哪些方案对应于软件更新配置具有特定状态的原因，请查看详细/失败/警告日志以获取错误代码和错误消息。

还可以使用更新计划的名称进行搜索，以获取其特定日志进行调试。

步骤 2：从自动化更新管理解决方案取消加入

请按照这些步骤进行操作：

1. 从 runbook 库导入迁移 runbook。 从浏览库搜索 azure 自动化更新，导入名为“从 Azure 自动化更新管理取消加入”的迁移 runbook 并发布该 runbook。

   

   Runbook 支持 PowerShell 5.1。

   

2. 将 Runbook 的详细日志记录设置为 True。

   

3. 启动 runbook 并传递自动化 Automation AccountResourceId、UserManagedServiceIdentityClientId 等参数。

   

   可以从自动化帐户>属性提取 AutomationAccountResourceId。

   

   可以从自动化帐户>标识>用户分配>标识>属性>客户端 ID提取 UserManagedServiceIdentityClientId。

   

4. 检查 Azure runbook 日志，了解计算机和计划的取消加入状态。

   

后端的取消加入脚本操作

• 禁用此自动化帐户中存在的所有软件更新配置的所有基础计划。 这样做是为了确保不会对部分迁移到 V2 的 SUC 触发 Patch-MicrosoftOMSComputers Runbook。
• 为从 V1 中的自动化更新管理取消加入的自动化帐户从链接的 Log Analytics 工作区中删除更新解决方案。
• 所有 SUC 已禁用的汇总日志以及从链接的 Log Analytics 工作区中删除更新解决方案的状态也会输出到输出流。
• 详细日志将输出到详细流。

迁移过程的标注：

• 不会迁移非 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 小时。
    • 例如，如果 SUC 的维护时段为 30 分钟，则等效的 MRP 计划执行时间为 1 小时 30 分钟。
    • 例如，如果 SUC 的维护时段为 6 小时，则等效的 MRP 计划执行时间为 4 小时。
• 多次执行迁移 runbook 时，假设你执行了“迁移所有”自动化计划，然后再次尝试迁移所有计划，则迁移 runbook 将运行相同的逻辑。 如果 SUC 中有任何新的更改，再次执行此操作将更新 MRP 计划。 它不会进行重复的配置分配。 此外，仅针对启用了计划的自动化计划执行操作。 如果 SUC 之前已迁移，则会在下一轮跳过，因为它的基础计划将禁用。
• 最后，可以像在 Azure 更新管理器中一样从 Azure Resource Graph 解析更多计算机；无法检查混合 Runbook 辅助角色是否报告，与自动化更新管理中不同，它是动态查询和混合 Runbook 辅助角色的相交。

手动迁移指南

下表提供了迁移各种功能的指南：

序号	功能	自动化更新管理	Azure 更新管理器	使用 Azure 门户的步骤	使用 API/脚本的步骤
1	适用于非 Azure 计算机的补丁管理。	可以使用或不使用 Arc 连接来运行。	Azure Arc 为非 Azure 计算机的先决条件。	1.创建服务主体 2. 生成安装脚本 3. 安装代理并连接到 Azure	1.创建服务主体 2.生成安装脚本 3. 安装代理并连接到 Azure
2	启用定期评估以每隔几个小时自动检查最新更新。	计算机自动接收最新更新，Windows 每 12 小时接收一次，Linux 每 3 小时接收一次。	定期评估是计算机上的更新设置。 如果启用了此设置，则更新管理器每隔 24 小时提取一次计算机更新，并显示最新的更新状态。	1.单一计算机 2. 大规模 3. 使用策略大规模	1.面向 Azure VM 2.面向已启用 Arc 的 VM
3	从 Azure 自动化更新管理注销。	完成步骤 1、2 和 3 后，需要清理 Azure 更新管理对象。		移除更新管理解决方案	NA
4	正在报告	使用 Log Analytics 查询自定义更新报告。	更新数据存储在 Azure Resource Graph (ARG) 中。 客户可以查询 ARG 数据以构建自定义仪表板、工作簿等。	可以访问 Log Analytics 中存储的旧自动化更新管理数据，但无法将数据移动到 ARG。 可以编写 ARG 查询，以访问通过 Azure 更新管理器修补虚拟机后将要存储到 ARG 的数据。 使用 ARG 查询，可以使用以下说明构建仪表板和工作簿： 1. Azure Resource graph 日志结构更新数据 2. 示例 ARG 查询 3. 创建工作簿	NA
5	使用前脚本和后脚本自定义工作流。	作为自动化 runbook 提供。	建议在非生产计算机上试用前脚本和后脚本的公共预览版，并在功能进入正式发布后，在生产工作负载上使用该功能。	管理预和后事件（预览版）和教程：通过自动化使用 Webhook 创建预和后事件

后续步骤

• 有关将 Azure VM 从 Microsoft Configuration Manager 迁移到 Azure 更新管理器的指南