你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站,请访问 https://docs.azure.cn

操作组

当 Azure Monitor 数据指示基础结构或应用程序可能存在问题时,将触发警报。 警报可以包含操作组,这些组是通知首选项的集合。 Azure Monitor、Azure 服务运行状况和 Azure 顾问将使用操作组通知用户有关警报事项并采取措施。

本文介绍了如何创建和管理操作组。

每个操作由以下部分组成:

  • 类型:发送的通知或执行的操作。 示例包括发送语音呼叫、短信或电子邮件。 还可以触发各种类型的自动化操作。
  • Name:操作组中的唯一标识符。
  • 详细信息:因类型而异的相应详细信息。

通常,操作组是一种全局服务。 目前正在开发方案,以提高这些操作组的区域可用性。 任何区域中的操作组服务都可以处理来自客户端的全局请求。 如果操作组服务的一个区域关闭,则流量会自动在其他区域中路由和处理。 作为全局服务,操作组有助于提供灾难恢复解决方案。 区域请求依赖于可用性区域冗余来满足隐私要求,并提供类似的灾难恢复解决方案。

  • 最多可以将五个操作组添加到警报规则。
  • 操作组是并发执行的,不按特定顺序执行。
  • 多个警报规则可以使用相同的操作组。

在 Azure 门户中创建操作组

  1. 转到 Azure 门户

  2. 搜索并选择“Monitor”。 “监视”窗格将所有监视设置和数据合并到一个视图中。

  3. 选择“警报”,然后选择“操作组”。

    Screenshot of the Alerts page in the Azure portal with the action groups button highlighter.

  4. 选择创建

    Screenshot that shows the Action groups page in the Azure portal. The Create button is called out.

  5. 配置基本操作组设置。 在“项目详细信息”部分中:

    • 为“订阅”和“资源组”选择值。

    • 选择区域。

      选项 行为
      全球 操作组服务决定操作组的存储位置。 操作组至少保留在两个区域中,以确保区域复原能力。 可以在任何地理区域中处理操作。

      服务健康状况警报而执行的语音、短信和电子邮件操作在出现 Azure 实时站点事件时可复原。
      区域 操作组存储在所选区域中。 操作组是区域冗余的。 如果希望确保在特定的地理边界内执行操作组的处理,则使用此选项。 可以选择以下区域之一对操作组进行区域处理:
      - 美国中南部
      - 美国中北部
      - 瑞典中部
      - 德国中西部
      我们将继续添加更多区域,以进行操作组的区域数据处理。

    操作组保存在你选择的订阅、区域和资源组中。

  6. 在“实例详细信息”部分中,输入“操作组名称”和“显示名称”的值。 使用此组发送通知时,显示名称用于代替完整的操作组名称。

    Screenshot that shows the Create action group dialog. Values are visible in the Subscription, Resource group, Action group name, and Display name boxes.

  7. 配置通知。 选择“下一步: 通知”或页面顶部的“通知”选项卡。

  8. 定义触发警报时要发送的通知的列表。

  9. 对于每个通知:

    1. 选择“通知类型”,然后填写该通知的相应字段。 可用选项是:

      通知类型 描述 字段
      向 Azure 资源管理器角色发送电子邮件 根据订阅成员的角色向其发送电子邮件。
      通知电子邮件仅发送给为 Microsoft Entra 用户配置的主电子邮件地址。
      电子邮件仅发送给所选角色的 Microsoft Entra ID 用户成员,而不会发送给 Microsoft Entra 组或服务主体。
      请参阅电子邮件
      输入为 Microsoft Entra 用户配置的主电子邮件地址。 请参阅电子邮件
      电子邮件 确保正确配置电子邮件筛选和任何恶意软件/垃圾邮件防护服务。 电子邮件从以下电子邮件地址发送:
      *azure-noreply@microsoft.com
      *azureemail-noreply@microsoft.com
      *alerts-noreply@mail.windowsazure.com
      输入应在其中发送通知的电子邮件。
      SMS 短信通知支持双向通信。 短信包含以下信息:
      * 此警报发送到的操作组的短名称
      * 警报的标题。
      用户可以回复短信,以:
      * 为所有操作组或单个操作组取消订阅所有短信警报。
      * 重新订阅警报
      * 请求帮助。
      有关支持的短信回复的详细信息,请参阅短信回复
      输入短信收件人的国家/地区代码电话号码。 如果无法在 Azure 门户中选择国家/地区代码,则你所在的国家/地区不支持短信。 如果你的国家/地区代码不可用,则可以在分享看法中投票以请求添加你的国家/地区。 在支持你的国家/地区之前,作为一种解决方案,可配置操作组以向支持你所在国家/地区的第三方短信提供商调用 Webhook。
      Azure 应用推送通知 将通知发送到 Azure 移动应用。 要启用 Azure 移动应用的推送通知,请提供有关 Azure 移动应用的详细信息(请参阅 Azure 移动应用)。 在“Azure 帐户电子邮件”字段中,输入配置 Azure 移动应用时用作帐户 ID 的电子邮件地址。
      语音 语音通知。 输入通知收件人的国家/地区代码电话号码。 如果无法在 Azure 门户中选择国家/地区代码,则你所在国家/地区不支持语音通知。 如果你的国家/地区代码不可用,则可以在分享看法中投票以请求添加你的国家/地区。 在支持你的国家/地区之前,作为一种解决方案,可配置操作组以向支持你所在国家/地区的第三方语音呼叫提供商调用 Webhook。
    2. 选择是否要启用通用警报架构。 通用警报架构的优点是一种单一可扩展且的警报有效负载,可用于 Azure Monitor 中的所有警报服务。 有关此通用架构的详细信息,请参阅通用警报架构

      Screenshot that shows the Notifications tab of the Create action group dialog. Configuration information for an email notification is visible.

    3. 选择“确定”

  10. 配置操作。 选择“下一步:操作”。 或选择页面顶部的“操作”选项卡。

  11. 定义触发警报时要触发的操作的列表。 选择一个操作类型,并输入每个操作的名称。

    操作类型 详细信息
    自动化 Runbook 有关自动化 runbook 有效负载的信息,请参阅自动化限制
    事件中心 事件中心操作会将通知发布到事件中心。 有关事件中心的详细信息,请参阅 Azure 事件中心 - 大数据流式处理平台和事件引入服务。 你可以订阅来自事件接收器的警报通知流。
    函数 调用函数中的现有 HTTP 触发器终结点。 有关详细信息,请参阅 Azure Functions
    定义函数操作时,函数的 HTTP 触发器终结点和访问密钥保存在操作定义中,例如 https://azfunctionurl.azurewebsites.net/api/httptrigger?code=<access_key>。 如果更改函数的访问密钥,则必须在操作组中移除并重新创建函数操作。
    终结点必须支持 HTTP POST 方法。
    函数必须有权访问存储帐户。 如果它没有访问权限,则密钥不可用,并且无法访问函数 URI。
    了解如何还原对存储帐户的访问权限
    ITSM ITSM 操作需要 ITSM 连接。 若要了解如何创建 ITSM 连接,请参阅 ITSM 集成
    逻辑应用 可以使用 Azure 逻辑应用来生成和自定义集成工作流,以及自定义警报通知。
    安全 Webhook 使用安全 Webhook 操作时,必须使用 Microsoft Entra ID 来保护操作组与终结点(即受保护的 Web API)之间的连接。 请参阅为安全 Webhook 配置身份验证。 安全 Webhook 不支持基本身份验证。 如果使用的是基本身份验证,请使用 Webhook 操作。
    Webhook 如果使用 Webhook 操作,则目标 Webhook 终结点必须能够处理不同警报源发出的各种 JSON 有效负载。
    无法通过 Webhook 操作传递安全证书。 若要使用基本身份验证,必须通过 URI 传递凭据。
    如果 Webhook 终结点需要特定的架构(例如 Microsoft Teams 架构),请使用逻辑应用操作类型来控制警报架构以满足目标 Webhook 的预期。
    有关用于重试 Webhook 操作的规则的信息,请参阅 Webhook

    Screenshot that shows the Actions tab of the Create action group dialog. Several options are visible in the Action type list.

  12. (可选。)如果要将键值对分配给操作组来对 Azure 资源进行分类,请选择“下一步:标记”或“标记”选项卡。否则,可跳过此步骤。

    Screenshot that shows the Tags tab of the Create action group dialog. Values are visible in the Name and Value boxes.

  13. 选择“查看 + 创建”以查看设置。 此步骤会快速检查输入,以确保已输入所有必需信息。 如果有问题,将在此处报告。 查看设置后,选择“创建”以创建操作组。

    Screenshot that shows the Review + create tab of the Create action group dialog. All configured values are visible.

注意

当配置操作来通过电子邮件或短信通知某个人员时,该人员将收到确认,指出已将其添加到操作组。

在 Azure 门户中测试操作组

在 Azure 门户中创建或更新操作组时,可以测试操作组。

  1. 在 Azure 门户中创建操作组

    注意

    如果要编辑已存在的操作组,则先保存对操作组进行的更改,然后再进行测试。

  2. 在“操作组”页上,选择“测试操作组”。

    Screenshot that shows the test action group page with the Test option.

  3. 选择示例类型以及要测试的通知和操作类型。 然后选择“测试”。

    Screenshot that shows the Test sample action group page with an email notification type and a webhook action type.

  4. 如果关闭窗口或选择“返回到测试设置”,而此时测试正在运行,则测试将停止,你不会获得测试结果。

    Screenshot that shows the Test Sample action group page. A dialog contains a Stop button and asks the user about stopping the test.

  5. 测试完成后,将显示“成功”或“失败”测试状态。 如果测试失败,而你想要获取详细信息,请选择“查看详细信息”。

    Screenshot that shows the Test sample action group page showing a test that failed.

你可以使用“错误详细信息”部分的信息来了解问题。 然后,可以再次编辑、保存更改和测试操作组。

运行测试并选择通知类型时,会收到主题中带有“测试”字样的消息。 这些测试提供了一种方法,用于在生产环境中启用操作组之前检查操作组是否按预期工作。 测试电子邮件通知中的所有详细信息和链接都来自示例参考集。

测试操作组的角色要求

下表描述了“测试操作”功能所需的角色成员身份要求:

角色成员身份 现有操作组 现有资源组和新操作组 新资源组和新操作组
订阅参阅者 支持 受支持 支持
资源组参与者 支持 支持 不适用
操作组资源参与者 支持 不适用 不适用
Azure Monitor 参与者 支持 支持 不适用
自定义角色 支持 支持 不适用

备注

使用资源管理器模板创建操作组

可以使用 Azure 资源管理器模板配置操作组。 使用模板,可以自动设置可以在某些类型的警报中重复使用的操作组。 这些操作组可确保警报触发时所有相应的当事方可以收到通知。

基本步骤如下:

  1. 以 JSON 文件的形式创建一个描述如何创建操作组的模板。
  2. 使用任意部署方法部署模板。

操作组资源管理器模板

若要使用资源管理器模板创建操作组,需要创建 Microsoft.Insights/actionGroups 类型的资源。 然后,填充所有相关属性。 以下是两个用于创建操作组的示例模板。

第一个模板介绍如何为操作组(其中操作定义在模板中进行了硬编码)创建资源管理器模板。 第二个模板介绍如何创建在部署模板时创建接受 Webhook 配置信息作为输入参数的模板。

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {
    "actionGroupName": {
      "type": "string",
      "metadata": {
        "description": "Unique name (within the Resource Group) for the Action group."
      }
    },
    "actionGroupShortName": {
      "type": "string",
      "metadata": {
        "description": "Short name (maximum 12 characters) for the Action group."
      }
    }
  },
  "resources": [
    {
      "type": "Microsoft.Insights/actionGroups",
      "apiVersion": "2021-09-01",
      "name": "[parameters('actionGroupName')]",
      "location": "Global",
      "properties": {
        "groupShortName": "[parameters('actionGroupShortName')]",
        "enabled": true,
        "smsReceivers": [
          {
            "name": "contosoSMS",
            "countryCode": "1",
            "phoneNumber": "5555551212"
          },
          {
            "name": "contosoSMS2",
            "countryCode": "1",
            "phoneNumber": "5555552121"
          }
        ],
        "emailReceivers": [
          {
            "name": "contosoEmail",
            "emailAddress": "devops@contoso.com",
            "useCommonAlertSchema": true

          },
          {
            "name": "contosoEmail2",
            "emailAddress": "devops2@contoso.com",
            "useCommonAlertSchema": true
          }
        ],
        "webhookReceivers": [
          {
            "name": "contosoHook",
            "serviceUri": "http://requestb.in/1bq62iu1",
            "useCommonAlertSchema": true
          },
          {
            "name": "contosoHook2",
            "serviceUri": "http://requestb.in/1bq62iu2",
            "useCommonAlertSchema": true
          }
        ],
         "SecurewebhookReceivers": [
          {
            "name": "contososecureHook",
            "serviceUri": "http://requestb.in/1bq63iu1",
            "useCommonAlertSchema": false
          },
          {
            "name": "contososecureHook2",
            "serviceUri": "http://requestb.in/1bq63iu2",
            "useCommonAlertSchema": false
          }
        ],
        "eventHubReceivers": [
          {
            "name": "contosoeventhub1",
            "subscriptionId": "replace with subscription id GUID",
            "eventHubNameSpace": "contosoeventHubNameSpace",
            "eventHubName": "contosoeventHub",
            "useCommonAlertSchema": true
          }
        ]
      }
    }
  ],
  "outputs":{
      "actionGroupId":{
          "type":"string",
          "value":"[resourceId('Microsoft.Insights/actionGroups',parameters('actionGroupName'))]"
      }
  }
}
{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {
    "actionGroupName": {
      "type": "string",
      "metadata": {
        "description": "Unique name (within the Resource Group) for the Action group."
      }
    },
    "actionGroupShortName": {
      "type": "string",
      "metadata": {
        "description": "Short name (maximum 12 characters) for the Action group."
      }
    },
    "webhookReceiverName": {
      "type": "string",
      "metadata": {
        "description": "Webhook receiver service Name."
      }
    },    
    "webhookServiceUri": {
      "type": "string",
      "metadata": {
        "description": "Webhook receiver service URI."
      }
    }    
  },
  "resources": [
    {
      "type": "Microsoft.Insights/actionGroups",
      "apiVersion": "2021-09-01",
      "name": "[parameters('actionGroupName')]",
      "location": "Global",
      "properties": {
        "groupShortName": "[parameters('actionGroupShortName')]",
        "enabled": true,
        "smsReceivers": [
        ],
        "emailReceivers": [
        ],
        "webhookReceivers": [
          {
            "name": "[parameters('webhookReceiverName')]",
            "serviceUri": "[parameters('webhookServiceUri')]",
            "useCommonAlertSchema": true
          }
        ]
      }
    }
  ],
  "outputs":{
      "actionGroupResourceId":{
          "type":"string",
          "value":"[resourceId('Microsoft.Insights/actionGroups',parameters('actionGroupName'))]"
      }
  }
}

管理操作组

创建操作组后,可以在门户中查看它:

  1. 转到 Azure 门户

  2. 在“监视器”页中选择“警报”。

  3. 选择“操作组”。

  4. 选择要管理的操作组。 方法:

    • 添加、编辑或删除操作。
    • 删除操作组。

通知的服务限制

电话号码或电子邮件可以包含在许多订阅的操作组中。 如果向特定电话号码、电子邮件地址或设备发送了过多的通知,Azure Monitor 会使用速率限制来暂停通知。 通过速率限制,确保警报处于管理且可操作状态。

速率限制适用于短信、语音和电子邮件通知。 所有其他通知操作不受速率限制。 有关速率限制的信息,请参阅 Azure Monitor 服务限制

速率限制应用于所有订阅。 达到阈值后就会应用速率限制,即使消息发送自多个订阅也是如此。

当电子邮件地址受速率限制时,将会发送一条通知,以告知已应用速率限制以及速率限制的过期时间。

向 Azure 资源管理器发送电子邮件

使用 Azure 资源管理器发出电子邮件通知时,可以向订阅角色的成员发送电子邮件。 电子邮件仅发送到该角色的 Microsoft Entra ID 用户成员。 电子邮件不发送给 Microsoft Entra 组或服务主体。

通知电子邮件将只发送到主电子邮件地址。

如果主电子邮件未收到通知,请配置 Email Azure 资源管理器角色的电子邮件地址:

  1. 在 Azure 门户中,转到 Microsoft Entra ID

  2. 在左侧,选择“所有用户”。 在右侧会显示用户列表。

  3. 选择要查看其主要电子邮件的用户。

    Screenshot that shows the Azure portal All users page. Information about one user is visible but is indecipherable.

  4. 在用户配置文件中的“联系人信息”下查找“电子邮件”值。 如果该值为空,请执行以下操作:

    1. 在页面顶部,选择“编辑”。
    2. 输入电子邮件地址。
    3. 在页面顶部,选择“保存”。

    Screenshot that shows a user profile page in the Azure portal. The Edit button and the Email box are called out.

每个操作组的电子邮件操作数可能有限。 要检查哪些限制适用于你的情况,请参阅 Azure Monitor 服务限制

设置 Azure 资源管理器角色时,请执行以下操作:

  1. 将类型为“用户”的实体分配给角色。
  2. 在“订阅”级别进行分配。
  3. 请确保为其Microsoft Entra 配置文件中的用户配置电子邮件地址。

注意

客户在向其订阅添加新的 Azure 资源管理器角色后,可能需要等待长达 24 小时的时间才能开始接收通知。

SMS

有关速率限制的信息,请参阅语音、短信、电子邮件、Azure 应用服务推送通知和 Webhook 帖子的速率限制

有关在操作组中使用短信通知的重要信息,请参阅操作组中的短信警报行为

每个操作组的短信操作数可能有限。

注意

如果无法在 Azure 门户中选择国家/地区代码,则你所在的国家/地区不支持短信。 如果你的国家/地区代码不可用,则可以在分享看法中投票以请求添加你的国家/地区。 此时,一个解决办法是将操作组配置为向某个在你所在的国家/地区提供支持的第三方短信提供商调用 Webhook。

短信回复

短信通知支持这些回复。 短信收件人可以使用以下值回复短信:

回复 说明
DISABLE <Action Group Short name> 禁用来自操作组的进一步短信
ENABLE <Action Group Short name> 重新启用来自操作组的短信
STOP 禁用来自所有操作组的进一步短信
START 重新启用来自所有操作组的短信
HELP 将向用户发送带本文链接的回复信息。

注意

如果用户已取消订阅短信警报,但随后被添加到新的操作组,将接收新操作组的短信警报,但对于所有以前的操作组均保持取消订阅状态。

每个操作组的 Azure 应用操作数可能有限。

提供短信通知支持的国家/地区

国家/地区代码 国家/地区
61 澳大利亚
43 奥地利
32 比利时
55 巴西
1 加拿大
56 智利
86 中国
420 捷克共和国
45 丹麦
372 爱沙尼亚
358 芬兰
33 法国
49 德国
852 香港特别行政区
91 印度
353 爱尔兰
972 以色列
39 意大利
81 日本
352 卢森堡
60 马来西亚
52 墨西哥
31 荷兰
64 新西兰
47 挪威
351 葡萄牙
1 波多黎各
40 罗马尼亚
7 俄罗斯
65 新加坡
27 南非
82 韩国
34 西班牙
41 瑞士
886 台湾
971 阿拉伯联合酋长国
44 英国
1 美国

语音

有关速率限制的重要信息,请参阅语音、短信、电子邮件、Azure 应用服务推送通知和 Webhook 帖子的速率限制

每个操作组的语音操作数可能有限。

注意

如果无法在 Azure 门户中选择国家/地区代码,则你所在的国家/地区不支持语音呼叫。 如果你的国家/地区代码不可用,则可以在分享看法中投票以请求添加你的国家/地区。 此时,一个解决办法是将操作组配置为向某个在你所在的国家/地区提供支持的第三方语音呼叫提供商调用 Webhook。

提供语音通知支持的国家/地区

国家/地区代码 国家/地区
61 澳大利亚
43 奥地利
32 比利时
55 巴西
1 加拿大
56 智利
420 捷克共和国
45 丹麦
358 芬兰
353 爱尔兰
972 以色列
352 卢森堡
60 马来西亚
52 墨西哥
31 荷兰
64 新西兰
47 挪威
351 葡萄牙
65 新加坡
27 南非
46 瑞典
44 英国
1 美国

有关受支持国家/地区的定价的信息,请参阅 Azure Monitor 定价

Webhook

注意

如果使用 Webhook 操作,则目标 Webhook 终结点必须能够处理不同警报源发出的各种 JSON 有效负载。 无法通过 Webhook 操作传递安全证书。 若要使用基本身份验证,必须通过 URI 传递凭据。 如果 Webhook 终结点需要特定的架构(例如 Microsoft Teams 架构),请使用逻辑应用操作来转换警报架构以满足目标 Webhook 的预期。

调用 Webhook 操作组时通常遵循以下规则:

  • 当调用 Webhook 时,如果第一次调用失败,它将至少再重试 1 次,并且会以不同延迟间隔(5、20、40 秒)最多重试 5 次(5 次重试)。
    • 第 1 次尝试和第 2 次尝试之间的延迟为 5 秒
    • 第 2 次尝试和第 3 次尝试之间的延迟为 20 秒
    • 第 3 次尝试和第 4 次尝试之间的延迟为 5 秒
    • 第 4 次尝试和第 5 次尝试之间的延迟为 40 秒
    • 第 5 次尝试和第 6 次尝试之间的延迟为 5 秒
  • 在尝试调用 Webhook 的重试都失败之后,在 15 分钟的时间内,没有操作组会调用该终结点。
  • 重试逻辑假定可以重试调用。 状态代码:408、429、503、504 或 HttpRequestException、WebException TaskCancellationException 允许重试调用”。

为安全 Webhook 配置身份验证

安全 webhook 操作通过“AZNS Microsoft Entra Webhook”Microsoft Entra 应用程序的 Microsoft Entra 租户中的服务主体实例向受保护的 API 进行身份验证。 要使操作组正常工作,必须将此 Microsoft Entra Webhook 服务主体添加为授权访问目标终结点的目标 Microsoft Entra 应用程序上的角色成员。

有关 Microsoft Entra 应用程序和服务主体的概述,请参阅Microsoft 标识平台 (v2.0) 概述。 按照以下步骤来利用安全 Webhook 功能。

注意

SecureWebhook 不支持基本身份验证。 要使用基本身份验证,必须使用 Webhook

如果使用 Webhook 操作,则目标 Webhook 终结点必须能够处理不同警报源发出的各种 JSON 有效负载。 如果 Webhook 终结点需要特定的架构(例如 Microsoft Teams 架构),请使用逻辑应用操作来转换警报架构以满足目标 Webhook 的预期。

  1. 为受保护的 Web API 创建 Microsoft Entra 应用程序。 有关详细信息,请参阅受保护的 Web API:应用注册。 将受保护的 API 配置为由守护程序应用调用,并公开应用程序权限,而不是委托的权限。 有关这些权限的详细信息,请参阅如果 Web API 由服务或守护程序应用调用

    注意

    将受保护的 Web API 配置为接受 V2.0 访问令牌。 有关此设置的详细信息,请参阅Microsoft Entra 应用清单

  2. 要使操作组能够使用 Microsoft Entra 应用程序,请使用遵循此过程的 PowerShell 脚本。

    注意

    必须被分配Microsoft Entra 应用程序管理员角色才能运行此脚本。

    1. 修改 PowerShell 脚本的Connect-AzureAD调用,以便使用 Microsoft Entra 租户 ID。
    2. 修改 PowerShell 脚本的$myAzureADApplicationObjectId变量,以使用 Microsoft Entra 应用程序的对象 ID。
    3. 运行修改的脚本。

    注意

    服务主体必须分配有 Microsoft Entra 应用程序的所有者角色,才能在操作组中创建或修改安全 Webhook 操作。

  3. 配置安全 Webhook 操作。

    1. 复制脚本中的 $myApp.ObjectId 值。
    2. 在 Webhook 操作定义的“对象 ID”框中,输入复制的值。

    Screenshot that shows the Secured Webhook dialog in the Azure portal with the Object ID box.

安全 Webhook PowerShell 脚本

Connect-AzureAD -TenantId "<provide your Azure AD tenant ID here>"

# Define your Azure AD application's ObjectId.
$myAzureADApplicationObjectId = "<the Object ID of your Azure AD Application>"

# Define the action group Azure AD AppId.
$actionGroupsAppId = "461e8683-5575-4561-ac7f-899cc907d62a"

# Define the name of the new role that gets added to your Azure AD application.
$actionGroupRoleName = "ActionGroupsSecureWebhook"

# Create an application role with the given name and description.
Function CreateAppRole([string] $Name, [string] $Description)
{
    $appRole = New-Object Microsoft.Open.AzureAD.Model.AppRole
    $appRole.AllowedMemberTypes = New-Object System.Collections.Generic.List[string]
    $appRole.AllowedMemberTypes.Add("Application");
    $appRole.DisplayName = $Name
    $appRole.Id = New-Guid
    $appRole.IsEnabled = $true
    $appRole.Description = $Description
    $appRole.Value = $Name;
    return $appRole
}

# Get your Azure AD application, its roles, and its service principal.
$myApp = Get-AzureADApplication -ObjectId $myAzureADApplicationObjectId
$myAppRoles = $myApp.AppRoles
$actionGroupsSP = Get-AzureADServicePrincipal -Filter ("appId eq '" + $actionGroupsAppId + "'")

Write-Host "App Roles before addition of new role.."
Write-Host $myAppRoles

# Create the role if it doesn't exist.
if ($myAppRoles -match "ActionGroupsSecureWebhook")
{
    Write-Host "The Action Group role is already defined.`n"
}
else
{
    $myServicePrincipal = Get-AzureADServicePrincipal -Filter ("appId eq '" + $myApp.AppId + "'")

    # Add the new role to the Azure AD application.
    $newRole = CreateAppRole -Name $actionGroupRoleName -Description "This is a role for Action Group to join"
    $myAppRoles.Add($newRole)
    Set-AzureADApplication -ObjectId $myApp.ObjectId -AppRoles $myAppRoles
}

# Create the service principal if it doesn't exist.
if ($actionGroupsSP -match "AzNS AAD Webhook")
{
    Write-Host "The Service principal is already defined.`n"
}
else
{
    # Create a service principal for the action group Azure AD application and add it to the role.
    $actionGroupsSP = New-AzureADServicePrincipal -AppId $actionGroupsAppId
}

New-AzureADServiceAppRoleAssignment -Id $myApp.AppRoles[0].Id -ResourceId $myServicePrincipal.ObjectId -ObjectId $actionGroupsSP.ObjectId -PrincipalId $actionGroupsSP.ObjectId

Write-Host "My Azure AD Application (ObjectId): " + $myApp.ObjectId
Write-Host "My Azure AD Application's Roles"
Write-Host $myApp.AppRoles

将 Runbook 操作从“运行方式帐户”迁移到“运行方式托管标识”

注意

Azure 自动化“运行方式帐户”已于 2023 年 9 月 30 日停用,这会影响使用操作类型“自动化 Runbook”创建的操作。 停用后,不支持链接到“运行方式帐户”Runbook 的现有操作。 但是,这些 Runbook 将继续执行,直到自动化帐户的“运行方式”证书过期。

若要确保可以继续使用 Runbook 操作,需要:

  1. 通过添加操作类型为“自动化 Runbook”的新操作来编辑操作组,并从下拉列表中选择相同的 Runbook。 (下拉列表中的所有 5 个 Runbook 都已在后端重新配置,以使用托管标识而不是运行方式帐户进行身份验证。将在自动化帐户中启用系统分配的托管标识,并在订阅级别自动分配 VM 参与者角色。)

    Screenshot of adding a runbook action to an action group.

    Screenshot of configuring the runbook action.

  2. 删除链接到“运行方式帐户”Runbook 的旧 Runbook 操作。

  3. 保存操作组。

后续步骤