操作组

Artículo
09/11/2024

当 Azure Monitor 数据指示基础结构或应用程序可能存在问题时，将触发警报。除了警报本身之外，还可以使用操作组在触发警报时发送通知，例如短信或电子邮件。操作组是通知首选项和操作的集合。 Azure Monitor、Azure 服务运行状况和 Azure 顾问将使用操作组通知用户有关警报事项并采取措施。本文介绍了如何创建和管理操作组。

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

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

通常，操作组是一种全局服务。目前正在开发方案，以提高这些操作组的区域可用性。

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

最多可以将五个操作组添加到警报规则。
操作组是并发执行的，不按特定顺序执行。
多个警报规则可以使用相同的操作组。
操作组由唯一的操作集和要通知的用户定义。例如，如果要针对两个不同的警报规则通过电子邮件通知 User1、User2 和 User3，则只需创建一个可应用于这两个警报规则的操作组。

在 Azure 门户中创建操作组

转到 Azure 门户。
搜索并选择“Monitor”。 “监视”窗格将所有监视设置和数据合并到一个视图中。
选择“警报”，然后选择“操作组”。
选择“创建”。
配置基本操作组设置。在“项目详细信息”部分中：
- 为“订阅”和“资源组”选择值。
- 选择区域。

选项	行为
全球	操作组服务决定操作组的存储位置。操作组至少保留在两个区域中，以确保区域复原能力。可以在任何地理区域中处理操作。因服务健康状况警报而执行的语音、短信和电子邮件操作在出现 Azure 实时站点事件时可复原。
区域	操作组存储在所选区域中。操作组是区域冗余的。如果希望确保在特定的地理边界内执行操作组的处理，则使用此选项。

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

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

配置通知。选择“下一步: 通知”或页面顶部的“通知”选项卡。
定义触发警报时要发送的通知的列表。

对于每个通知：

选择“通知类型”，然后填写该通知的相应字段。可用选项是：

通知类型	描述	字段
向 Azure 资源管理器角色发送电子邮件	根据订阅成员的角色向其发送电子邮件。请参阅电子邮件。	输入为 Microsoft Entra 用户配置的主电子邮件地址。请参阅电子邮件。
电子邮件	确保正确配置电子邮件筛选和任何恶意软件/垃圾邮件防护服务。电子邮件从以下电子邮件地址发送： * azure-noreply@oe.21vianet.com * azureemail-noreply@oe.21vianet.com * alerts-noreply@mail.windowsazure.cn	输入应在其中发送通知的电子邮件。
SMS	短信通知支持双向通信。短信包含以下信息： * 此警报发送到的操作组的短名称 * 警报的标题。用户可以回复短信，以： * 为所有操作组或单个操作组取消订阅所有短信警报。 * 重新订阅警报 * 请求帮助。有关支持的短信回复的详细信息，请参阅短信回复。	输入短信收件人的国家/地区代码和电话号码。如果无法在 Azure 门户中选择国家/地区代码，则你所在的国家/地区不支持短信。如果你的国家/地区代码不可用，则可以在分享看法中投票以请求添加你的国家/地区。在支持你的国家/地区之前，作为一种解决方案，可配置操作组以向支持你所在国家/地区的第三方短信提供商调用 Webhook。

选择是否要启用通用警报架构。通用警报架构的优点是一种单一可扩展且的警报有效负载，可用于 Azure Monitor 中的所有警报服务。有关此通用架构的详细信息，请参阅通用警报架构。
选择“确定”。

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

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

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

显示“创建操作组”对话框“操作”选项卡的屏幕截图。“操作类型”列表中的多个选项可见。

（可选。）如果要将键值对分配给操作组来对 Azure 资源进行分类，请选择“下一步：标记”或“标记”选项卡。否则，可跳过此步骤。
选择“查看 + 创建”以查看设置。此步骤会快速检查输入，以确保已输入所有必需信息。如果有问题，将在此处报告。查看设置后，选择“创建”以创建操作组。

注意

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

在 Azure 门户中测试操作组

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

在 Azure 门户中创建操作组。

注意

在测试之前，必须创建和保存操作组。如果要编辑已存在的操作组，则先保存对操作组进行的更改，然后再进行测试。
在“操作组”页上，选择“测试操作组”。
选择示例类型以及要测试的通知和操作类型。然后选择“测试”。
如果关闭窗口或选择“返回到测试设置”，而此时测试正在运行，则测试将停止，你不会获得测试结果。
测试完成后，将显示“成功”或“失败”测试状态。如果测试失败，而你想要获取详细信息，请选择“查看详细信息”。

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

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

测试操作组的角色要求

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

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

¹ 自定义角色必须具有 Microsoft.Insights/createNotifications/* 权限。

注意

如果用户不是上述角色成员资格的成员，不具有生成此通知的正确权限，则测试操作组所需的最低权限为“Microsoft.Insights/createNotifications/*”
可以按时间段运行有限数量的测试。要检查哪些限制适用于你的情况，请参阅 Azure Monitor 服务限制。
在门户中配置操作组时，可以选择加入或退出常见警报架构。
- 若要查找所有示例类型的常见架构示例，请参阅测试操作组的常见警报架构定义。
- 若要查找非常见架构警报定义，请参阅测试操作组的非常见警报架构定义。

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

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

基本步骤如下：

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

操作组资源管理器模板

若要使用资源管理器模板创建操作组，需要创建 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'))]"
      }
  }
}

管理操作组

创建操作组后，可以在门户中查看它：

转到 Azure 门户。
在“监视器”页中选择“警报”。
选择“操作组”。
选择要管理的操作组。方法：
- 添加、编辑或删除操作。
- 删除操作组。

通知的服务限制

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

速率限制适用于短信和电子邮件通知。所有其他通知操作不受速率限制。速率限制应用于所有订阅。达到阈值后就会应用速率限制，即使消息发送自多个订阅也是如此。当电子邮件地址受速率限制时，将会发送一条通知，以告知已应用速率限制以及速率限制的过期时间。

有关速率限制的信息，请参阅 Azure Monitor 服务限制。

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

使用 Azure 资源管理器发出电子邮件通知时，可以向订阅角色的成员发送电子邮件。电子邮件将发送给该角色的 Microsoft Entra ID 用户或组成员。这包括对通过 Azure Lighthouse 分配的角色的支持。

注意

操作组仅支持向以下角色发送电子邮件：所有者、参与者、读取者、监视参与者、监视读取者。

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

在 Azure 门户中，转到 Microsoft Entra ID。
在左侧，选择“所有用户”。在右侧会显示用户列表。
选择要查看其主要电子邮件的用户。
在用户配置文件中的“联系人信息”下查找“电子邮件”值。如果该值为空，请执行以下操作：
1. 在页面顶部，选择“编辑”。
2. 输入电子邮件地址。
3. 在页面顶部，选择“保存”。

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

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

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

如果用户不是上述角色成员资格的成员，不具有生成此通知的正确权限，则测试操作组所需的最低权限为“Microsoft.Insights/createNotifications/*”

可以按时间段运行有限数量的测试。若要检查哪些限制适用于你的情况，请参阅 Azure Monitor 服务限制。

在门户中配置操作组时，可以选择加入或退出常见警报架构。

若要查找所有示例类型的常见架构示例，请参阅测试操作组的常见警报架构定义。

若要查找非常见架构警报定义，请参阅测试操作组的非常见警报架构定义。

注意

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

SMS

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

有关速率限制的信息，请参阅 Azure Monitor 服务限制。
有关在操作组中使用短信通知的重要信息，请参阅操作组中的短信警报行为。

注意

如果无法在 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	美国

Webhook

注意

如果使用 Webhook 操作，则目标 Webhook 终结点必须能够处理不同警报源发出的各种 JSON 有效负载。 Webhook 终结点还必须可公开访问。无法通过 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 的预期。

注意

我们计划在 2024 年 3 月 30 日弃用 Azure AD PowerShell。若要了解详细信息，请阅读有关弃用的更新。

我们建议迁移到 Microsoft Graph PowerShell，以便与 Microsoft Entra ID（以前称为 Azure AD）进行交互。 Microsoft Graph PowerShell 在 PowerShell 7 上提供，支持访问所有 Microsoft Graph API。有关常见迁移查询的解答，请参阅迁移常见问题解答。

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

注意

将受保护的 Web API 配置为接受 V2.0 访问令牌。有关此设置的详细信息，请参阅Microsoft Entra 应用清单。
要使操作组能够使用 Microsoft Entra 应用程序，请使用遵循此过程的 PowerShell 脚本。

注意

必须被分配Microsoft Entra 应用程序管理员角色才能运行此脚本。
1. 修改 PowerShell 脚本的Connect-AzureAD调用，以便使用 Microsoft Entra 租户 ID。
2. 修改 PowerShell 脚本的$myAzureADApplicationObjectId变量，以使用 Microsoft Entra 应用程序的对象 ID。
3. 运行修改的脚本。
注意

服务主体必须分配有 Microsoft Entra 应用程序的所有者角色，才能在操作组中创建或修改安全 Webhook 操作。
配置安全 Webhook 操作。
1. 复制脚本中的 $myApp.ObjectId 值。
2. 在 Webhook 操作定义的“对象 ID”框中，输入复制的值。

安全 Webhook PowerShell 脚本

注意

先决条件：安装 Microsoft Graph PowerShell SDK

如何运行？

将以下脚本复制并粘贴到你的计算机
替换 tenantId 和应用注册中的 ObjectID
另存为 *.ps1
从计算机中打开 PowerShell 命令，然后运行 *.ps1 脚本

Write-Host "================================================================================================="
$scopes = "Application.ReadWrite.All"
$myTenantId = "<<Customer's tenant id>>"
$myMicrosoftEntraAppRegistrationObjectId = "<<Customer's object id from the app registration>>"
$actionGroupRoleName = "ActionGroupsSecureWebhook"
$azureMonitorActionGroupsAppId = "461e8683-5575-4561-ac7f-899cc907d62a" # Required. Do not change.

Connect-MgGraph -Scopes $scopes -TenantId $myTenantId

Function CreateAppRole([string] $Name, [string] $Description)
{
    $appRole = @{
        AllowedMemberTypes = @("Application")
        DisplayName = $Name
        Id = New-Guid
        IsEnabled = $true
        Description = $Description
        Value = $Name
    }
    return $appRole
}

$myApp = Get-MgApplication -ApplicationId $myMicrosoftEntraAppRegistrationObjectId
$myAppRoles = $myApp.AppRoles
$myActionGroupServicePrincipal = Get-MgServicePrincipal -Filter "appId eq '$azureMonitorActionGroupsAppId'"

Write-Host "App Roles before addition of new role.."
foreach ($role in $myAppRoles) { Write-Host $role.Value }

if ($myAppRoles.Value -contains $actionGroupRoleName)
{
    Write-Host "The Action Group role is already defined. No need to redefine.`n"
    # Retrieve the application again to get the updated roles
    $myApp = Get-MgApplication -ApplicationId $myMicrosoftEntraAppRegistrationObjectId
    $myAppRoles = $myApp.AppRoles
}
else
{
    Write-Host "The Action Group role is not defined. Defining the role and adding it."
    $newRole = CreateAppRole -Name $actionGroupRoleName -Description "This is a role for Action Group to join"
    $myAppRoles += $newRole
    Update-MgApplication -ApplicationId $myApp.Id -AppRole $myAppRoles

    # Retrieve the application again to get the updated roles
    $myApp = Get-MgApplication -ApplicationId $myMicrosoftEntraAppRegistrationObjectId
    $myAppRoles = $myApp.AppRoles
}

$myServicePrincipal = Get-MgServicePrincipal -Filter "appId eq '$($myApp.AppId)'"

if ($myActionGroupServicePrincipal.DisplayName -contains "AzNS AAD Webhook")
{
    Write-Host "The Service principal is already defined.`n"
    Write-Host "The action group Service Principal is: " + $myActionGroupServicePrincipal.DisplayName + " and the id is: " + $myActionGroupServicePrincipal.Id
}
else
{
    Write-Host "The Service principal has NOT been defined/created in the tenant.`n"
    $myActionGroupServicePrincipal = New-MgServicePrincipal -AppId $azureMonitorActionGroupsAppId
    Write-Host "The Service Principal is been created successfully, and the id is: " + $myActionGroupServicePrincipal.Id
}

# Check if $myActionGroupServicePrincipal is not $null before trying to access its Id property
# Check if the role assignment already exists
$existingRoleAssignment = Get-MgServicePrincipalAppRoleAssignment -ServicePrincipalId $myActionGroupServicePrincipal.Id | Where-Object { $_.AppRoleId -eq $myApp.AppRoles[0].Id -and $_.PrincipalId -eq $myActionGroupServicePrincipal.Id -and $_.ResourceId -eq $myServicePrincipal.Id }

# If the role assignment does not exist, create it
if ($null -eq $existingRoleAssignment) {
    Write-Host "Doing app role assignment to the new action group Service Principal`n"
    New-MgServicePrincipalAppRoleAssignment -ServicePrincipalId $myActionGroupServicePrincipal.Id -AppRoleId $myApp.AppRoles[0].Id -PrincipalId $myActionGroupServicePrincipal.Id -ResourceId $myServicePrincipal.Id
} else {
    Write-Host "Skip assigning because the role already existed."
}

Write-Host "myServicePrincipalId: " $myServicePrincipal.Id
Write-Host "My Azure AD Application (ObjectId): " $myApp.Id
Write-Host "My Azure AD Application's Roles"
foreach ($role in $myAppRoles) { Write-Host $role.Value }

Write-Host "================================================================================================="

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

注意

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

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

后续步骤

获取警报概述，并了解如何接收警报。
了解活动日志警报 webhook 架构。

Compartir a través de

操作组