---
sourceDocument: Yokohama IT Operations Management
sourceDocumentLink: https://servicenow-prod.fluidtopics.net/r/yokohama/it-operations-management

 Release :

    - yokohama

ft:locale :

    - en-US

ft:publication_title :

    - Yokohama IT Operations Management

ft:clusterId :

    - itom

bundleId :

    - itom

workflow :

    - Technology


---

# Microsoft Azure Alert driven discovery

# Microsoft Azure Alert driven discovery {#ariaid-title1}

* Release version: Yokohama
* 
* Updated January 30, 2025
* 
* ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 6 minutes to read

The Microsoft Azure Alert service can raise alerts for any changes in the
life-cycle state or the configuration of a cloud resource. You can configure the service to
auto-update the latest resource information in the Configuration Management Database (CMDB)
without waiting for the next scheduled Cloud Discovery to run.  
Important:  
The Azure change processing offers an optimal performance when compared to the Microsoft Azure alert-driven discovery that uses a legacy form of authentication and should no longer be used. Starting with the Discovery and Service Mapping Patterns app version 1.1.0, the Azure change processing has replaced the Microsoft Azure alert-driven discovery. Use the new secure webhook or migrate to [Azure change processing](https://servicenow-prod.fluidtopics.net/48qJRqeZTZOuHhnAAtJDrA "The Azure change processing feature collects information about Microsoft Azure resources that have undergone a life-cycle state change or configuration change near real time. Then, it uses the collected information to update the Configuration Management Database (CMDB).") for additional performance gains. For more information, see on the secure webhook, see the knowledge base article [Azure Alert service to auto-update the CMDB has webhook url without credentials in the azure portal](https://support.servicenow.com/kb?id=kb_article_view&sys_kb_id=1bf707c5938fe550d9743f986cba10b9).

During event processing, the Cloud Event Scheduler identifies the domain of the service account and assigns to the event. If an error occurs in identifying the domain before processing, the event can
sometimes stay unassigned and become visible to all domains. To prevent the failed events visibility to all domains, you can set the sn_cmp.error_events.default_domain property to sys_id of the
service-provider domain so that the failed events appears only to the service-provider domain administrator.

You can configure the Cloud Event Scripted REST API to receive alerts from the Microsoft Azure Alert service. For each alert---also called an event---the API
creates a record in the Cloud Events \[sn_cmp_cloud_event\] table. The Cloud Event Scheduler
reads the events from the \[sn_cmp_cloud_event\] table for batch processing. The scheduler
invokes the pattern to process the events that are in ready state. The patterns discover the
affected resource and add or update its details in the CMDB. This method helps to update the CMDB Configuration
Item (CI) data and view the latest data in the Cloud User portal.  
Important:  
If you're using domain separation for Cloud Discovery, the events are also domain-separated. Therefore, you can view the details of a processed event only if it belongs to your domain. If an event is not associated with any service account, then it is associated with the global domain.  
For each event, the Cloud Event Scripted REST API stores the following information \[sn_cmp_cloud_event\] table:

* Source: This field is always set to `azure activity
  log`.
* Event Name: Name of the event received from the Microsoft Azure console.
* Resource ID: ID of the affected resource. If there are VM events, Cloud Discovery uses this information to identify the VM.
* Resource Type: Resource type of the affected resource.
{#microsoft-azure-alert-driven-discovery__ul_nwc_rgt_rrb}

## Configure the Microsoft Azure Alert service to auto-update the CMDB {#azure-alert-service-cloud-mgt__title-azure-cmdb-update}


Configure the Microsoft Azure Alert service to auto-update the Configuration Management Database (CMDB) without waiting for the next scheduled Cloud Discovery to run.{#azure-alert-service-cloud-mgt__shortdesc-azure-cmdb-update}

### Before you begin

* Ensure that either Discovery or Cloud Provisioning and Governance is activated in the instance.
*
  * An active MID Server with Microsoft Azure discovery capability is available.  
    Note:  
    The alert configuration continues to ping alerts even when the MID Server is down. Which in turn leads to a high number of errors in the ECC queue. If no MID Server is available, you must manually deactivate the Microsoft Azure alert rule. The Azure Alert Rules \[azure_alert_rule\] table contains all the Microsoft Azure alert rules.
  {#azure-alert-service-cloud-mgt__ul_plc_ll2_c5b}
{#azure-alert-service-cloud-mgt__ul_hmh_kl2_c5b}  
Role required:

* ServiceNow role: sn_cmp.cloud_event_integration
* Microsoft Azure roles:
  * Microsoft Azure credentials with the Reader role
  * Microsoft Azure custom role with the following permissions:

        "permissions": [
                    {
                        "actions": [
                            "Microsoft.Insights/ActionGroups/Write",
                            "Microsoft.Insights/ActionGroups/Delete",
                            "Microsoft.Insights/ActionGroups/Read",
                            "Microsoft.Insights/ActivityLogAlerts/Write",
                            "Microsoft.Insights/ActivityLogAlerts/Delete",
                            "Microsoft.Insights/ActivityLogAlerts/Read",
                            "Microsoft.Insights/ActivityLogAlerts/Activated/Action",
                            "Microsoft.Insights/AlertRules/Write",
                            "Microsoft.Insights/AlertRules/Delete",
                            "Microsoft.Insights/AlertRules/Read",
                            "Microsoft.Resources/deployments/write",
                            "Microsoft.Resources/deployments/delete",
                            "Microsoft.Resources/deployments/read"
                        ],

  {#azure-alert-service-cloud-mgt__ul_vdm_14f_15b}  
  Note:  
  To set up the alert-driven discovery, you can use a Microsoft Azure service principal with the reader role only. For more information, see the community article [Azure alert driven discovery with
  reader privileges](https://community.servicenow.com/community?id=community_article&sys_id=32edaa41db2fa090679499ead39619a1).
{#azure-alert-service-cloud-mgt__ul_tkn_pqn_prb}

### About this task

After you configure the alert service, it facilitates tracking of the life-cycle
state and configuration of the Microsoft Azure cloud resources.  
Important:  
You can use a secure webhook to forward the Microsoft Azure alerts to the ServiceNow AI Platform. For more information, see [Use a secure webhook to forward the Microsoft Azure alerts to the ServiceNow AI Platform
\[KB1208357\]](https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB1208357).

### Procedure

1. Disable authentication for the Cloud Event Scripted REST API, because the Microsoft Azure Alert doesn't support basic authentication.
   1. As an administrator, navigate to Scripted Web ServicesScripted REST APIs.
   2. Open the Cloud Event record.
   3. From the Resources tab, open the Cloud Config Event Post record.
   4. Set the application scope to Global.
   5. On the Security tab, clear the Requires Authentication check box.  
      Important:  
      The ServiceNow instance uses a webhook URL for the alert-driven discovery. However, the Microsoft Azure alert configuration of the ServiceNow instance doesn't support authentication for creating the webhook. You can enable authentication by providing the user name and password in the webhook URL. For more information, see [KB0963526](https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0963526).
   {#azure-alert-service-cloud-mgt__substeps_cbx_hkg_rrb}
2. Navigate to DiscoveryCloud AlertsAzure Alert Configurations.  
   Note:  
   If you have Discovery activated in the instance, you can navigate directly to Alert Configurations using your instance URL. For example,

       https://{instancename}.service-now.com/sn_cmp_azure_alert_configuration_list.do

3. On the Azure tab, select New.
4. On the form, fill in the fields.  
   {#azure-alert-service-cloud-mgt__table_dw1_vs1_qz__entry__2}

   | Field | Description |
   |-|-|
   | Service Account | Microsoft Azure service account for which you want to create the Azure alert configuration. Make sure that Cloud Discovery has discovered all the Logical Datacenters (LDC) associated with the cloud account. |
   | Resource Group | Resource group that contains the alert rules. Select the Microsoft Azure service account. For more information on adding a Microsoft Azure service account, see [Add an Azure service account](https://servicenow-prod.fluidtopics.net/OZXNSryGjVt9Xw~aObzRqw "During Cloud Provisioning Day 1 setup, you added one service account to the cloud account. To compartmentalize your infrastructure or to include different datacenters, you can add another service account. A particular datacenter, however, cannot be selected in more than one service account in a cloud account."). The instance creates the alert rules for all the resources that are available in the service account. |
   | Activate | Option to indicate the status of the alert configuration. This option is selected by default. |
   | User | User name of a ServiceNow user having the sn_cmp.cloud_event_integration role. |
   | Password | ServiceNow user account password. |
   [Table 1. Azure Alert Configuration form]

   {#azure-alert-service-cloud-mgt__table_dw1_vs1_qz}
5. Select Submit.  
   On successfully configuring the Microsoft Azure Alert service, the status of the alert configuration changes from None to Activated.
{#azure-alert-service-cloud-mgt__azure-steps}

## Add a Microsoft Azure alert rule {#ariaid-title3}

Enable alert-driven discovery for a new Microsoft Azure alert type by
adding it to the Azure Alert Rules \[azure_alert_rule\] table.

### Before you begin

Role required: admin

### About this task

The Azure Alert Rules \[azure_alert_rule\] table contains all the supported alert
types. For more information, see [Supported Microsoft Azure alert types](https://servicenow-prod.fluidtopics.net/lHXJClXQGbinwpoNOhYIqw#supported-microsoft-azure-alert-types "The base system Cloud Discovery supports alert driven discovery for several Microsoft Azure alert types. The Azure Alert Rules [azure_alert_rule] table contains the supported alert types."). The Microsoft Azure Alert service uses the information stored in the
Azure Alert Rules \[azure_alert_rule\] table to raise the alerts. Cloud Discovery also supports all the alerts generated for the
members of the resource group specified in the Microsoft Azure alert
configuration.

### Procedure

1. Navigate to the Azure Alert Rules \[azure_alert_rule\] table by entering the following URL in the navigation bar of the browser:  
   https://\<instance name\>.service-now.com/azure_alert_rule_list.do
2. Select New.
3. On the form, fill in the fields.  
   {#add-microsoft-azure-alert-rule__table_rgb_cff_15b__entry__2}

   | Field | Description |
   |-|-|
   | Rule name | Name of the Microsoft Azure alert type. |
   | Action | Microsoft Azure resource operation API path. For more information on the Microsoft Azure resources for which you can raise alerts, go to the [Microsoft Azure](https://docs.microsoft.com/en-us/azure/?product=popular) documentation and see "Azure resource provider operations". |
   | Active | Option to indicate the status of the Microsoft Azure alert type. This option is selected by default. |
   [Table 2. Azure Alert Rule form]

   {#add-microsoft-azure-alert-rule__table_rgb_cff_15b}
4. Select Submit.

## Supported Microsoft Azure alert types {#ariaid-title4}

The base system Cloud Discovery supports alert driven discovery for
several Microsoft Azure alert types. The Azure Alert Rules \[azure_alert_rule\]
table contains the supported alert types.
The base system Cloud Discovery supports the following Microsoft Azure alert types:

    Microsoft.Compute/virtualMachines/deallocate/action 
    Microsoft.Network/privateDnsZones/delete 
    Microsoft.Compute/availabilitySets/write 
    Microsoft.Network/loadBalancers/write 
    Microsoft.Network/connections/delete 
    Microsoft.Network/publicIPAddresses/delete 
    Microsoft.Storage/storageAccounts/write 
    Microsoft.Network/virtualNetworks/delete 
    Microsoft.Sql/servers/databases/delete 
    Microsoft.Network/expressRouteCircuits/write 
    Microsoft.Network/localnetworkgateways/delete 
    Microsoft.Network/networkInterfaces/delete 
    Microsoft.Compute/virtualmachines/write 
    Microsoft.Network/expressRouteCircuits/delete 
    Microsoft.Network/natGateways/write 
    Microsoft.Network/loadBalancers/delete 
    Microsoft.Compute/virtualMachineScaleSets/delete 
    Microsoft.Network/virtualNetworks/virtualNetworkPeerings/delete 
    Microsoft.Storage/storageAccounts/delete 
    Microsoft.Compute/availabilitySets/delete 
    Microsoft.Network/connections/write 
    Microsoft.Compute/virtualMachines/start/action 
    Microsoft.Compute/virtualMachines/restart/action 
    Microsoft.Sql/servers/databases/write 
    Microsoft.Compute/virtualMachines/delete 
    Microsoft.Network/networkInterfaces/write 
    Microsoft.Network/privateDnsZones/write 
    Microsoft.Network/localnetworkgateways/write 
    Microsoft.Network/natGateways/delete 
    Microsoft.Compute/virtualMachines/stop/action 
    Microsoft.Network/publicIPAddresses/write 
    Microsoft.Compute/virtualMachineScaleSets/write 
    Microsoft.Network/virtualNetworks/virtualNetworkPeerings/write 
    Microsoft.Network/virtualNetworks/write 
    Microsoft.Sql/servers/delete 
    Microsoft.Sql/servers/write 

*[\>]: and then