-To force reset the password on next login, update the account password profile using MS Graph [Update user](/graph/api/user-update) operation. The following example updates the password profile [forceChangePasswordNextSignIn](user-profile-attributes.md#password-profile-property) attribute to `true`, which forces the user to reset the password on next login.

-"passwordProfile": {

- "forceChangePasswordNextSignIn": true

-[guest configuration](../governance/policy/concepts/guest-configuration.md)

-| [Azure AD Connect](../hybrid/how-to-connect-install-roadmap.md#install-azure-ad-connect) version 1.4.32.0 or later | | X |

-```http

-az rest --method POST --uri 'https://graph.microsoft.com/beta/applications/41be38fd-caac-4354-aa1e-1fdb20e43bfa/federatedIdentityCredentials' --body '{"name":"GcpFederation","issuer":"https://accounts.google.com","subject":"112633961854638529490","description":"Testing","audiences":["api://AzureADTokenExchange"]}'

-HereΓÇÖs an example in TypeScript of how to request an ID token from the Google metadata server:

-description: Set up a trust relationship between an app in Azure AD and a GitHub repo. This allows a GitHub Actions workflow to access Azure AD protected resources without using secrets or certificates.

-#Customer intent: As an application developer, I want to configure a federated credential on an app registration so I can create a trust relationship with a GitHub repo and use workload identity federation to access Azure AD protected resources without managing secrets.

-# Configure an app to trust a GitHub repo (preview)

-This article describes how to create a trust relationship between an application in Azure Active Directory (Azure AD) and a GitHub repo. You can then configure a GitHub Actions workflow to exchange a token from GitHub for an access token from Microsoft identity platform and access Azure AD protected resources without needing to manage secrets. To learn more about the token exchange workflow, read about [workload identity federation](workload-identity-federation.md). You establish the trust relationship by configuring a federated identity credential on your app registration in the Azure portal or by using Microsoft Graph.

-Anyone with permissions to create an app registration and add a secret or certificate can add a federated identity credential. If the **Users can register applications** switch in the [User Settings](https://portal.azure.com/#blade/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/UserSettings) blade is set to **No**, however, you won't be able to create an app registration or configure the federated identity credential. Find an admin to configure the federated identity credential on your behalf. Anyone in the Application Administrator or Application Owner roles can do this.

-After you configure your app to trust a GitHub repo, [configure your GitHub Actions workflow](/azure/developer/github/connect-from-azure) to get an access token from Microsoft identity provider and access Azure AD protected resources.

-## Prerequisites

-[Create an app registration](quickstart-register-app.md) in Azure AD. [Grant your app access to the Azure resources](howto-create-service-principal-portal.md) targeted by your GitHub workflow.

-Find the object ID of the app (not the application (client) ID), which you need in the following steps. You can find the object ID of the app in the Azure portal. Go to the list of [registered applications](https://portal.azure.com/#blade/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/RegisteredApps) in the Azure portal and select your app registration. In **Overview**->**Essentials**, find the **Object ID**.

-Get the organization, repository, and environment information for your GitHub repo, which you need in the following steps.

-## Configure a federated identity credential

-# [Azure portal](#tab/azure-portal)

-Sign into the [Azure portal](https://portal.azure.com/). Go to **App registrations** and open the app you want to configure.

-Go to **Certificates and secrets**. In the **Federated credentials** tab, select **Add credential**. The **Add a credential** blade opens.

-In the **Federated credential scenario** drop-down box select **GitHub actions deploying Azure resources**.

-Specify the **Organization** and **Repository** for your GitHub Actions workflow.

-For **Entity type**, select **Environment**, **Branch**, **Pull request**, or **Tag** and specify the value. The values must exactly match the configuration in the [GitHub workflow](https://docs.github.com/actions/using-workflows/workflow-syntax-for-github-actions#on). For more info, read the [examples](#entity-type-examples).

-Add a **Name** for the federated credential.

-The **Issuer**, **Audiences**, and **Subject identifier** fields autopopulate based on the values you entered.

-Click **Add** to configure the federated credential.

-> [!NOTE]

-> If you accidentally configure someone else's GitHub repo in the *subject* setting (enter a typo that matches someone elses repo) you can successfully create the federated identity credential. But in the GitHub configuration, however, you would get an error because you aren't able to access another person's repo.

-> [!IMPORTANT]

-> The **Organization**, **Repository**, and **Entity type** values must exactly match the configuration on the GitHub workflow configuration. Otherwise, Microsoft identity platform will look at the incoming external token and reject the exchange for an access token. You won't get an error, the exchange fails without error.

-### Entity type examples

-#### Branch example

-For a workflow triggered by a push or pull request event on the main branch:

-```yml

-on:

- push:

- branches: [ main ]

- pull_request:

- branches: [ main ]

-```

-Specify an **Entity type** of **Branch** and a **GitHub branch name** of "main".

-#### Environment example

-For Jobs tied to an environment named "production":

-```yml

-on:

- push:

- branches:

- - main

-jobs:

- deployment:

- runs-on: ubuntu-latest

- environment: production

- steps:

- - name: deploy

- # ...deployment-specific steps

-```

-Specify an **Entity type** of **Environment** and a **GitHub environment name** of "production".

-#### Tag example

-For example, for a workflow triggered by a push to the tag named "v2":

-```yml

-on:

- push:

- # Sequence of patterns matched against refs/heads

- branches:

- - main

- - 'mona/octocat'

- - 'releases/**'

- # Sequence of patterns matched against refs/tags

- tags:

- - v2

- - v1.*

-```

-Specify an **Entity type** of **Tag** and a **GitHub tag name** of "v2".

-#### Pull request example

-For a workflow triggered by a pull request event, specify an **Entity type** of **Pull request**.

-# [Microsoft Graph](#tab/microsoft-graph)

-Launch [Azure Cloud Shell](https://portal.azure.com/#cloudshell/) and sign in to your tenant.

-### Create a federated identity credential

-Run the following command to [create a new federated identity credential](/graph/api/application-post-federatedidentitycredentials?view=graph-rest-beta&preserve-view=true) on your app (specified by the object ID of the app). The *issuer* identifies GitHub as the external token issuer. *subject* identifies the GitHub organization, repo, and environment for your GitHub Actions workflow. When the GitHub Actions workflow requests Microsoft identity platform to exchange a GitHub token for an access token, the values in the federated identity credential are checked against the provided GitHub token.

-```azurecli

-az rest --method POST --uri 'https://graph.microsoft.com/beta/applications/f6475511-fd81-4965-a00e-41e7792b7b9c/federatedIdentityCredentials' --body '{"name":"Testing","issuer":"https://token.actions.githubusercontent.com/","subject":"repo:octo-org/octo-repo:environment:Production","description":"Testing","audiences":["api://AzureADTokenExchange"]}'

-```

-And you get the response:

-```azurecli

-{

- "@odata.context": "https://graph.microsoft.com/beta/$metadata#applications('f6475511-fd81-4965-a00e-41e7792b7b9c')/federatedIdentityCredentials/$entity",

- "audiences": [

- "api://AzureADTokenExchange"

- ],

- "description": "Testing",

- "id": "1aa3e6a7-464c-4cd2-88d3-90db98132755",

- "issuer": "https://token.actions.githubusercontent.com/",

- "name": "Testing",

- "subject": "repo:octo-org/octo-repo:environment:Production"

-}

-```

-*name*: The name of your Azure application.

-*issuer*: The path to the GitHub OIDC provider: `https://token.actions.githubusercontent.com/`. This issuer will become trusted by your Azure application.

-*subject*: Before Azure will grant an access token, the request must match the conditions defined here.

-*audiences*: `api://AzureADTokenExchange` is the required value.

-> [!NOTE]

-> If you accidentally configure someone else's GitHub repo in the *subject* setting (enter a typo that matches someone elses repo) you can successfully create the federated identity credential. But in the GitHub configuration, however, you would get an error because you aren't able to access another person's repo.

-> [!IMPORTANT]

-> The *subject* setting values must exactly match the configuration on the GitHub workflow configuration. Otherwise, Microsoft identity platform will look at the incoming external token and reject the exchange for an access token. You won't get an error, the exchange fails without error.

-### List federated identity credentials on an app

-Run the following command to [list the federated identity credential(s)](/graph/api/application-list-federatedidentitycredentials?view=graph-rest-beta&preserve-view=true) for an app (specified by the object ID of the app):

-```azurecli

-az rest -m GET -u 'https://graph.microsoft.com/beta/applications/f6475511-fd81-4965-a00e-41e7792b7b9c/federatedIdentityCredentials'

-```

-And you get a response similar to:

-```azurecli

-{

- "@odata.context": "https://graph.microsoft.com/beta/$metadata#applications('f6475511-fd81-4965-a00e-41e7792b7b9c')/federatedIdentityCredentials",

- "value": [

- {

- "audiences": [

- "api://AzureADTokenExchange"

- ],

- "description": "Testing",

- "id": "1aa3e6a7-464c-4cd2-88d3-90db98132755",

- "issuer": "https://token.actions.githubusercontent.com/",

- "name": "Testing",

- "subject": "repo:octo-org/octo-repo:environment:Production"

- }

- ]

-}

-```

-### Delete a federated identity credential

-Run the following command to [delete a federated identity credential](/graph/api/application-list-federatedidentitycredentials?view=graph-rest-beta&preserve-view=true) from an app (specified by the object ID of the app):

-```azurecli

-az rest -m DELETE -u 'https://graph.microsoft.com/beta/applications/f6475511-fd81-4965-a00e-41e7792b7b9c/federatedIdentityCredentials/1aa3e6a7-464c-4cd2-88d3-90db98132755'

-```

-## Get the application (client) ID and tenant ID from the Azure portal

-Before configuring your GitHub Actions workflow, get the *tenant-id* and *client-id* values of your app registration. You can find these values in the Azure portal. Go to the list of [registered applications](https://portal.azure.com/#blade/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/RegisteredApps) and select your app registration. In **Overview**->**Essentials**, find the **Application (client) ID** and **Directory (tenant) ID**. Set these values in your GitHub environment to use in the Azure login action for your workflow.

-## Next steps

-For an end-to-end example, read [Deploy to App Service using GitHub Actions](../../app-service/deploy-github-actions.md?tabs=openid).

-Read the [GitHub Actions documentation](https://docs.github.com/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-azure) to learn more about configuring your GitHub Actions workflow to get an access token from Microsoft identity provider and access Azure resources.

-# Configure an app to trust an external identity provider (preview)

-This article describes how to create a trust relationship between an application in Azure Active Directory (Azure AD) and an external identity provider (IdP). You can then configure an external software workload to exchange a token from the external IdP for an access token from Microsoft identity platform. The external workload can access Azure AD protected resources without needing to manage secrets (in supported scenarios). To learn more about the token exchange workflow, read about [workload identity federation](workload-identity-federation.md). You establish the trust relationship by configuring a federated identity credential on your app registration by using Microsoft Graph or the Azure portal.

-Anyone with permissions to create an app registration and add a secret or certificate can add a federated identity credential. If the **Users can register applications** switch in the [User Settings](https://portal.azure.com/#blade/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/UserSettings) blade is set to **No**, however, you won't be able to create an app registration or configure the federated identity credential. Find an admin to configure the federated identity credential on your behalf. Anyone in the Application Administrator or Application Owner roles can do this.

-After you configure your app to trust an external IdP, configure your software workload to get an access token from Microsoft identity provider and access Azure AD protected resources.

-Get the information for your external IdP and software workload, which you need in the following steps.

-The Microsoft Graph beta endpoint (`https://graph.microsoft.com/beta`) exposes REST APIs to create, update, delete [federatedIdentityCredentials](/graph/api/resources/federatedidentitycredential?view=graph-rest-beta&preserve-view=true) on applications. Launch [Azure Cloud Shell](https://portal.azure.com/#cloudshell/) and sign in to your tenant in order to run Microsoft Graph commands from AZ CLI.

-When you configure a federated identity credential on an app, there are several important pieces of information to provide.

-*issuer* and *subject* are the key pieces of information needed to set up the trust relationship. *issuer* is the URL of the external identity provider and must match the `issuer` claim of the external token being exchanged. *subject* is the identifier of the external software workload and must match the `sub` (`subject`) claim of the external token being exchanged. *subject* has no fixed format, as each IdP uses their own - sometimes a GUID, sometimes a colon delimited identifier, sometimes arbitrary strings. The combination of `issuer` and `subject` must be unique on the app. When the external software workload requests Microsoft identity platform to exchange the external token for an access token, the *issuer* and *subject* values of the federated identity credential are checked against the `issuer` and `subject` claims provided in the external token. If that validation check passes, Microsoft identity platform issues an access token to the external software workload.

-> [!IMPORTANT]

-> If you accidentally add the incorrect external workload information in the *subject* setting the federated identity credential is created successfully without error. The error does not become apparent until the token exchange fails.

-*audiences* lists the audiences that can appear in the external token. This field is mandatory, and defaults to "api://AzureADTokenExchange". It says what Microsoft identity platform must accept in the `aud` claim in the incoming token. This value represents Azure AD in your external identity provider and has no fixed value across identity providers - you may need to create a new application registration in your IdP to serve as the audience of this token.

-*name* is the unique identifier for the federated identity credential, which has a character limit of 120 characters and must be URL friendly. It is immutable once created.

-*description* is the un-validated, user-provided description of the federated identity credential.

-### GitHub Actions example

-# [Azure CLI](#tab/azure-cli)

-Run the [create a new federated identity credential](/graph/api/application-post-federatedidentitycredentials?view=graph-rest-beta&preserve-view=true) command on your app (specified by the object ID of the app). Specify the *name*, *issuer*, *subject*, and other parameters.

-For examples, see [Configure an app to trust a GitHub repo](workload-identity-federation-create-trust-github.md?tabs=microsoft-graph).

-# [Portal](#tab/azure-portal)

-Select the **GitHub Actions deploying Azure resources** scenario from the dropdown menu. Fill in the **Organization**, **Repository**, **Entity type**, and other fields.

-For examples, see [Configure an app to trust a GitHub repo](workload-identity-federation-create-trust-github.md?tabs=azure-portal).

-# [Azure CLI](#tab/azure-cli)

-Run the following command to configure a federated identity credential on an app and create a trust relationship with a Kubernetes service account. Specify the following parameters:

-az rest --method POST --uri 'https://graph.microsoft.com/beta/applications/f6475511-fd81-4965-a00e-41e7792b7b9c/federatedIdentityCredentials' --body '{"name":"Kubernetes-federated-credential","issuer":"https://aksoicwesteurope.blob.core.windows.net/9d80a3e1-2a87-46ea-ab16-e629589c541c/","subject":"system:serviceaccount:erp8asle:pod-identity-sa","description":"Kubernetes service account federated credential","audiences":["api://AzureADTokenExchange"]}'

- "@odata.context": "https://graph.microsoft.com/beta/$metadata#applications('f6475511-fd81-4965-a00e-41e7792b7b9c')/federatedIdentityCredentials/$entity",

-# [Portal](#tab/azure-portal)

-Find your app registration in the [App Registrations](https://aka.ms/appregistrations) experience of the Azure portal. Select **Certificates & secrets** in the left nav pane, select the **Federated credentials** tab, and select **Add credential**.

-Select the **Kubernetes accessing Azure resources** scenario from the dropdown menu.

-Fill in the **Cluster issuer URL**, **Namespace**, **Service account name**, and **Name** fields:

-# [Azure CLI](#tab/azure-cli)

-Run the following command to configure a federated identity credential on an app and create a trust relationship with an external identity provider. Specify the following parameters (using a software workload running in Google Cloud as an example):

-az rest --method POST --uri 'https://graph.microsoft.com/beta/applications/<ObjectID>/federatedIdentityCredentials' --body '{"name":"GcpFederation","issuer":"https://accounts.google.com","subject":"112633961854638529490","description":"Testing","audiences":["api://AzureADTokenExchange"]}'

- "@odata.context": "https://graph.microsoft.com/beta/$metadata#applications('f6475511-fd81-4965-a00e-41e7792b7b9c')/federatedIdentityCredentials/$entity",

-# [Portal](#tab/azure-portal)

-Find your app registration in the [App Registrations](https://aka.ms/appregistrations) experience of the Azure portal. Select **Certificates & secrets** in the left nav pane, select the **Federated credentials** tab, and select **Add credential**.

-Select the **Other issuer** scenario from the dropdown menu.

-Specify the following fields (using a software workload running in Google Cloud as an example):

-# [Azure CLI](#tab/azure-cli)

-Run the following command to [list the federated identity credential(s)](/graph/api/application-list-federatedidentitycredentials?view=graph-rest-beta&preserve-view=true) for an app (specified by the object ID of the app):

-az rest -m GET -u 'https://graph.microsoft.com/beta/applications/f6475511-fd81-4965-a00e-41e7792b7b9c/federatedIdentityCredentials'

- "@odata.context": "https://graph.microsoft.com/beta/$metadata#applications('f6475511-fd81-4965-a00e-41e7792b7b9c')/federatedIdentityCredentials",

-# [Portal](#tab/azure-portal)

-Find your app registration in the [App Registrations](https://aka.ms/appregistrations) experience of the Azure portal. Select **Certificates & secrets** in the left nav pane and select the **Federated credentials** tab. The federated credentials that are configured on your app are listed.

-## Delete a federated identity credential

-# [Azure CLI](#tab/azure-cli)

-Run the following command to [delete a federated identity credential](/graph/api/application-list-federatedidentitycredentials?view=graph-rest-beta&preserve-view=true) from an app (specified by the object ID of the app):

-az rest -m DELETE -u 'https://graph.microsoft.com/beta/applications/f6475511-fd81-4965-a00e-41e7792b7b9c/federatedIdentityCredentials/51ecf9c3-35fc-4519-a28a-8c27c6178bca'

-# [Portal](#tab/azure-portal)

-Find your app registration in the [App Registrations](https://aka.ms/appregistrations) experience of the Azure portal. Select **Certificates & secrets** in the left nav pane and select the **Federated credentials** tab. The federated credentials that are configured on your app are listed.

-To delete a federated identity credential, select the **Delete** icon for the credential.

-# Workload identity federation (preview)

-You can use workload identity federation in scenarios such as GitHub Actions and workloads running on Kubernetes.

-* [Azure Arc](https://azure.microsoft.com/services/azure-arc/) enables above Azure features to non-Azure VMs. For example, Windows Server when used on-premises

-* or on AWS.

-The assignment process starts by assign roles to members. To grant access to a resource, the administrator assigns roles to users, groups, service principals, or managed identities. The assignment includes the following data:

-| May | 99.999% | |

-| June | 99.999% | |

-> | microsoft.directory/deletedItems.users/delete | Permanently delete users, which can no longer be restored |

-> | microsoft.directory/deletedItems.users/delete | Permanently delete users, which can no longer be restored |

-> | microsoft.directory/cloudAppSecurity/allProperties/allTasks | Create and delete all resources, and read and update standard properties in Microsoft Cloud App Security |

-2. **[Configure ADP SSO](#configure-adp-sso)** - to configure the Single Sign-On settings on application side.

-To configure single sign-on on **ADP** side, you need to upload the downloaded **Metadata XML** on the [ADP website](https://adpfedsso.adp.com/public/login/index.fcc).

-> [!NOTE]

-> This process may take a few days.

- A: No, turning on single sign-on immediately requires all your Google Cloud / G Suite Connector by Microsoft users to authenticate with their Azure AD credentials. Because Google Cloud / G Suite Connector by Microsoft doesn't support having multiple identity providers, the identity provider for your Google Cloud / G Suite Connector by Microsoft environment can either be Azure AD or Google -- but not both at the same time.

-In addition, `command invoke` runs the commands from your cluster so any commands run in this manner are subject to networking and other restrictions you have configured on your cluster.

-To test the OpenFaaS system, browse to the external IP address on port 8080, `http://52.186.64.52:8080` in this example. You will be prompted to log in. To fetch your password, enter `echo $PASSWORD`.

-# Bring your own Container Network Interface (CNI) plugin with Azure Kubernetes Service (AKS) (PREVIEW)

- retry-after-header-name="header name"

-| retry-after-header-name | The name of a response header whose value is the recommended retry interval in seconds after the specified call rate is exceeded. | No | N/A |

- retry-after-header-name="header name" retry-after-variable-name="policy expression variable name"

- remaining-calls-header-name="header name" remaining-calls-variable-name="policy expression variable name"

-| retry-after-header-name | The name of a response header whose value is the recommended retry interval in seconds after the specified call rate is exceeded. | No | N/A |

-The `quota` policy enforces a renewable or lifetime call volume and/or bandwidth quota, on a per subscription basis.

-The `quota-by-key` policy enforces a renewable or lifetime call volume and/or bandwidth quota, on a per key basis. The key can have an arbitrary string value and is typically provided using a policy expression. Optional increment condition can be added to specify which requests should be counted towards the quota. If multiple policies would increment the same key value, it is incremented only once per request. When the call rate is exceeded, the caller receives a `403 Forbidden` response status code.

-<set-body>new body value as text</set-body>

-|template|Used to change the templating mode that the set body policy will run in. Currently the only supported value is:<br /><br />- liquid - the set body policy will use the liquid templating engine |No||

- az rest --method POST --uri 'https://graph.microsoft.com/beta/applications/<APPLICATION-OBJECT-ID>/federatedIdentityCredentials' --body '{"name":"<CREDENTIAL-NAME>","issuer":"https://token.actions.githubusercontent.com","subject":"repo:organization/repository:ref:refs/heads/main","description":"Testing","audiences":["api://AzureADTokenExchange"]}'

-|[Azure Guest Configuration](../governance/policy/concepts/guest-configuration.md) | Guest Configuration policy is used to monitor the configuration and report on the compliance of the machine. The Automanage service will install the Azure security baseline using the Guest Configuration extension. For Arc machines, the guest configuration service will install the baseline in audit-only mode. You will be able to see where your VM is out of compliance with the baseline, but noncompliance won't be automatically remediated. |Production, Dev/Test |

-|[Guest configuration](../governance/policy/concepts/guest-configuration.md) | Guest configuration is used to monitor the configuration and report on the compliance of the machine. The Automanage service will install the Azure Linux baseline using the guest configuration extension. For Linux machines, the guest configuration service will install the baseline in audit-only mode. You will be able to see where your VM is out of compliance with the baseline, but noncompliance won't be automatically remediated. Learn [more](../governance/policy/concepts/guest-configuration.md). |Production, Dev/Test |

-|[Guest configuration](../governance/policy/concepts/guest-configuration.md) | Guest configuration policy is used to monitor the configuration and report on the compliance of the machine. The Automanage service will install the [Windows security baselines](/windows/security/threat-protection/windows-security-baselines) using the guest configuration extension. For Windows machines, the guest configuration service will install the baseline in audit-only mode. You will be able to see where your VM is out of compliance with the baseline, but noncompliance won't be automatically remediated. Learn [more](../governance/policy/concepts/guest-configuration.md). To modify the audit mode for Windows machines, use a custom profile to choose your audit mode setting. [Learn more](virtual-machines-custom-profile.md) |Production, Dev/Test |

-|Guest configuration | Guest configuration is used to monitor the configuration and report on the compliance of the machine. The Automanage service will install the [Windows security baselines](/windows/security/threat-protection/windows-security-baselines) using the guest configuration extension. Learn [more](../governance/policy/concepts/guest-configuration.md). |Azure VM Best Practices ΓÇô Production, Azure VM Best Practices ΓÇô Dev/Test |No |

-Azure Automanage for machine best practices has default best practice profiles that cannot be edited. However, if you need more flexibility, you can pick and choose the set of services and settings by creating a custom profile.

-Automanage supports toggling services ON and OFF. It also currently supports customizing settings on [Azure Backup](..\backup\backup-azure-arm-vms-prepare.md#create-a-custom-policy) and [Microsoft Antimalware](../security/fundamentals/antimalware.md#default-and-custom-antimalware-configuration). You can also specify an existing log analytics workspace. Also, for Windows machines only, you can modify the audit modes for the [Azure security baselines in Guest Configuration](../governance/policy/concepts/guest-configuration.md).

-Automanage allows you to tag the following resources in the custom profile:

-This ARM template will create a custom configuration profile that you can assign to your specified machine.

-The `location` value is the region where you would like to store this custom configuration profile. Note, you can assign this profile to any supported machines in any region.

-The `azureSecurityBaselineAssignmentType` is the audit mode that you can choose for the Azure server security baseline. Your options are

-* ApplyAndAutoCorrect : This will apply the Azure security baseline through the Guest Configuration extention, and if any setting within the baseline drifts, we will auto-remediate the setting so it stays compliant.

-* ApplyAndMonitor : This will apply the Azure security baseline through the Guest Configuration extention when you first assign this profile to each machine. After it is applied, the Guest Configuration service will monitor the sever baseline and report any drift from the desired state. However, it will not auto-remdiate.

-* Audit : This will install the Azure security baseline using the Guest Configuration extension. You will be able to see where your machine is out of compliance with the baseline, but noncompliance won't be automatically remediated.

-You can also specify an existing log analytics workspace by adding this setting to the configuration section of properties below:

-Specify your existing workspace in the `LogAnalytics/Workspace` line. Set the `LogAnalytics/Reprovision` setting to true if you would like this log analytics workspace to be used in all cases. This means that any machine with this custom profile will use this workspace, even it is already connected to one. By default, the `LogAnalytics/Reprovision` is set to false. If your machine is already connected to a workspace, then that workspace will continue to be used. If it is not connected to a workspace, then the workspace specified in `LogAnalytics\Workspace` will be used.

-The `Tags/Behavior` can either be set to Preserve or Replace. If the resource you are tagging already has the same tag key in the key/value pair, you can choose if you would like to replace that key with the specified value in the configuration profile by using the *Replace* behavior. By default, the behavior is set to *Preserve*, meaning that the tag key that is already associated with that resource will be kept and not overwritten by the key/value pair specified in the configuration profile.

-1. Run this ARM template deployment with `az deployment group create --resource-group myResourceGroup --template-file azuredeploy.json`

-1. Provide the values for customProfileName, location, and azureSecurityBaselineAssignmentType when prompted

-1. You're ready to deploy

-## Next steps

-Get the most frequently asked questions answered in our FAQ.

-> Before you enable the DSC extension, we would like you to know that a newer version of DSC is now available in preview, managed by a feature of Azure Policy named [guest configuration](../governance/policy/concepts/guest-configuration.md). The guest configuration service combines features of DSC Extension, Azure Automation State Configuration, and the most commonly requested features from customer feedback. Guest configuration also includes hybrid machine support through [Arc-enabled servers](../azure-arc/servers/overview.md).

-> Before you enable Automation State Configuration, we would like you to know that a newer version of DSC is now available in preview, managed by a feature of Azure Policy named [guest configuration](../governance/policy/concepts/guest-configuration.md). The guest configuration service combines features of DSC Extension, Azure Automation State Configuration, and the most commonly requested features from customer feedback. Guest configuration also includes hybrid machine support through [Arc-enabled servers](../azure-arc/servers/overview.md).

-> Before you enable Automation State Configuration, we would like you to know that a newer version of DSC is now available in preview, managed by a feature of Azure Policy named [guest configuration](../governance/policy/concepts/guest-configuration.md). The guest configuration service combines features of DSC Extension, Azure Automation State Configuration, and the most commonly requested features from customer feedback. Guest configuration also includes hybrid machine support through [Arc-enabled servers](../azure-arc/servers/overview.md).

-> Before you enable Automation State Configuration, we would like you to know that a newer version of DSC is now available in preview, managed by a feature of Azure Policy named [guest configuration](../governance/policy/concepts/guest-configuration.md). The guest configuration service combines features of DSC Extension, Azure Automation State Configuration, and the most commonly requested features from customer feedback. Guest configuration also includes hybrid machine support through [Arc-enabled servers](../azure-arc/servers/overview.md).

-Multiple Azure services can fulfill the above requirements. Each service has its benefits and limitations, and customers can use multiple services to meet their automation requirements.

-**Responding to external events**

-**Complex orchestration and integration with 1st or 3rd party products**

-

- | Allows to write an [Automation PowerShell runbook](./learn/powershell-runbook-managed-identity.md) that deploys an Azure resource by using an [Azure Resource Manager template](../azure-resource-manager/templates/quickstart-create-templates-use-the-portal.md).</br> </br> Schedule tasks, for example ΓÇô Stop dev/test VMs or services at night and turn on during the day. </br> </br> Response to alerts such as system alerts, service alerts, high CPU/memory alerts, create ServiceNow tickets, and so on. </br> </br> Hybrid automation where you can manage to automate on-premises servers such as SQL Server, Active Directory and so on. </br> </br> Azure resource life-cycle management and governance include resource provisioning, de-provisioning, adding correct tags, locks, NSGs and so on. | IT administrators, System administrators, IT operations administrators who are skilled at using PowerShell or Python based scripting. </br> </br> Infrastructure administrators manage the on-premises infrastructure using scripts or executing long-running jobs such as month-end operations on servers running on-premises.

- **Linux and Windows support**

- - It provides a simple experience (point, select, set, and forget).

- | Automatically configures guest operating system per Microsoft baseline configuration. </br> </br> Automatically detects for drift and corrects it across a VMΓÇÖs entire lifecycle. </br> </br> Aims at a hands-free management of machines. | The IT Administrators, Infra Administrators, IT Operations Administrators are responsible for managing server workload, day to day admin tasks such as backup, disaster recovery, security updates, responding to security threats, and so on across Azure and on-premise. </br> </br> Developers who do not wish to manage servers or spend the time on fewer priority tasks.

-Azure Policy based Guest configuration is the next iteration of Azure Automation State configuration. [Learn more](../governance/policy/concepts/guest-configuration-policy-effects.md).

- - For customer-authored content.

- | Obtain compliance data that may include: The configuration of the operating system ΓÇô files, registry, and services, Application configuration or presence, Check environment settings. </br> </br> Audit or deploy settings to all machines (Set) in scope either reactively to existing machines or proactively to new machines as they are deployed. </br> </br> Respond to policy events to provide [remediation on demand or continuous remediation.](../governance/policy/concepts/guest-configuration-policy-effects.md#remediation-on-demand-applyandmonitor) | The Central IT, Infrastructure Administrators, Auditors (Cloud custodians) are working towards the regulatory requirements at scale and ensuring that servers' end state looks as desired. </br> </br> The application teams validate compliance before releasing change.

-Orchestrates repetitive processes using graphical, PowerShell, and Python runbooks in the cloud or hybrid environment. [Learn more](./automation-runbook-types.md).

- - It provides persistent shared assets, including variables, connections, objects, that allows orchestration of complex jobs.

- - You can invoke a runbook on the basis of [Azure Monitor alert](./automation-create-alert-triggered-runbook.md) or through a [webhook](./automation-webhooks.md).

- - When you write Powershell scripts within the Function Apps, you must tweak the scripts to define how the function behaves such as - how it's triggered, its input and output parameters. [Learn more](../azure-functions/functions-reference-powershell.md?tabs=portal).

- | Respond to events on resources: such as add tags to resource group basis cost center, when VM is deleted etc. </br> </br> Set scheduled tasks such as setting a pattern to stop and start a VM at a specific time, reading blob storage content at regular intervals etc. </br> </br> Process Azure alerts to send the teamΓÇÖs event when the CPU activity spikes to 90%. </br> </br> Orchestrate with external systems such as Microsoft 365. </br> </br> Respond to database changes. | The Application developers who are skilled in coding languages such as C#, F#, PHP, Java, JavaScript, PowerShell, or Python. </br> </br> Cloud Architects who build serverless Micro-services based applications where a single or mutiple Azure Functions could be part of larger application workflow.

- - Flexibility to visually create and edit workflows - Low Code\no code approach

- | Azure resource life-cycle management and governance which includes Resource provisioning, de-provisioning, adding correct tags, locks, NSGs and so on through runbooks that are triggered from ITSM alerts. </br></br> Use hybrid worker as a bridge from cloud to on-premises enabling resource\user management on-premise. </br></br> Execute complex disaster recovery workflows through Automation runbooks. </br></br> Execute automation runbooks as part of Logic apps workflow through Azure Automation Connector. | IT administrators, System administrators, IT operations administrators who are skilled at using PowerShell or Python based scripting. </br> </br> Infrastructure Administrators managing on-premises infrastructure using scripts or executing long running jobs such as month-end operations on servers running on-premises.

- - When you write Powershell scripts within the Function Apps, you must tweak the scripts to define how the function behaves such as - how it's triggered, its input and output parameters. [Learn more](../azure-functions/functions-reference-powershell.md?tabs=portal).

- | Respond to events on resources : such as add tags to resource group basis cost center, when VM is deleted etc. </br> </br> Set scheduled tasks such as setting a pattern to stop and start a VM at a specific time, reading blob storage content at regular intervals etc. </br> </br> Process Azure alerts where you can send teamΓÇÖs event when the CPU activity spikes to 90%. </br> </br> Orchestrate with external systems such as Microsoft 365. </br> </br>Executes Azure Function as part of Logic apps workflow through Azure Function Connector. | Application Developers who are skilled in coding languages such as C#, F#, PHP, Java, JavaScript, PowerShell, or Python. </br> </br> Cloud Architects who build serverless Micro-services based applications where a single or mutiple Azure Functions could be part of larger application workflow.

-

-

-To re-enable local authentication, execute the PowerShell cmdlet `Set-AzAutomationAccount` with the parameter `-DisableLocalAuth false`.  Allow a few minutes for the service to accept the change to allow local authentication requests.

-|Using Automation Desired State Configuration.| Use [Azure Policy Guest configuration](../governance/policy/concepts/guest-configuration.md).  |

-### Restore deleted Automation Accounts

-**Type:** New change

-## November 2021

-### General Availability of Managed Identity for Azure Automation

-### Preview support for PowerShell 7.1

-Customers should evaluate and plan for migration from Azure Automation State Configuration to Azure Policy guest configuration. For more information, see [Azure Policy guest configuration](../governance/policy/concepts/guest-configuration.md).

-Because zonal VMs are created across the availability zones, all migration options mentioned in this article require downtime during deployment because zonal VMs are created across the availability zones.

-> [Azure Services that support Availability Zones](az-region.md)

-Azure Arc-enabled Kubernetes provides both automatic and manual upgrade capabilities for its agents. If you disable automatic upgrade and instead rely on manual upgrade, a [version support policy](#version-support-policy) applies for Arc agents and the underlying Kubernetes clusters.

-description: "This article provides an architectural overview of Azure Arc-enabled Kubernetes agents"

-[Kubernetes](https://kubernetes.io/) can deploy containerized workloads consistently on hybrid and multi-cloud environments. Azure Arc-enabled Kubernetes provides a centralized, consistent control plane to manage policy, governance, and security across Kubernetes clusters on these heterogenous environments. This article provides an overview of the Azure Arc agents deployed on the Kubernetes clusters as part of connecting the cluster to Azure Arc.

-Most on-prem datacenters enforce strict network rules that prevent inbound communication on the network boundary firewall. Azure Arc-enabled Kubernetes works with these restrictions by not requiring inbound ports on the firewall. Azure Arc agents only require outbound communication to a prerequisite list of network endpoints.

-[  ](./media/architectural-overview.png#lightbox)

-The following steps are involved in connecting a Kubernetes cluster to Azure Arc:

- > Since Azure Arc-enabled Kubernetes currently only supports attaching existing Kubernetes clusters to Azure Arc, customers are required to create and manage the lifecycle of the Kubernetes cluster themselves.

-1. Start the Azure Arc registration for your cluster using Azure CLI.

- * Azure CLI uses Helm to deploy the agent Helm chart on the cluster.

- * The cluster nodes initiate an outbound communication to the [Microsoft Container Registry](https://github.com/microsoft/containerregistry) and pull the images needed to create the following agents in the `azure-arc` namespace:

- | `deployment.apps/controller-manager` | An operator of operators that orchestrates interactions between Azure Arc components. |

- | `deployment.apps/kube-aad-proxy` | Used for authentication of requests sent to the cluster using Cluster Connect |

- | `deployment.apps/clusterconnect-agent` | Reverse proxy agent that enables Cluster Connect feature to provide access to `apiserver` of cluster. Optional component deployed only if `cluster-connect` feature is enabled on the cluster |

- | `deployment.apps/guard` | Authentication and authorization webhook server used for Azure Active Directory (Azure AD) RBAC. Optional component deployed only if `azure-rbac` feature is enabled on the cluster |

-1. Once all the Azure Arc-enabled Kubernetes agent pods are in `Running` state, verify that your cluster connected to Azure Arc. You should see:

- * Cluster metadata (like Kubernetes version, agent version, and number of nodes) appears on the Azure Arc-enabled Kubernetes resource as metadata.

- > [!IMPORTANT]

- > While the **Az.ConnectedKubernetes** PowerShell module is in preview, you must install it separately using

- > the `Install-Module` cmdlet.

-| RedHat | [OpenShift Container Platform](https://www.openshift.com/products/container-platform) | [4.7.18+](https://docs.openshift.com/container-platform/4.7/release_notes/ocp-4-7-release-notes.html), [4.9.17+](https://docs.openshift.com/container-platform/4.9/release_notes/ocp-4-9-release-notes.html), [4.10.0+](https://docs.openshift.com/container-platform/4.10/release_notes/ocp-4-10-release-notes.html) |

-| Cisco | [Intersight Kubernetes Service (IKS)](https://www.cisco.com/c/en/us/products/cloud-systems-management/cloud-operations/intersight-kubernetes-service.html) Distribution | Upstream K8s version: 1.19.5 |

- Note the following behavior with Azure Policy [guest configuration](../../governance/policy/concepts/guest-configuration.md) for a disconnected machine:

-[Azure Monitor](../../../azure-monitor/overview.md) can collect data directly from your hybrid machines into a Log Analytics workspace for detailed analysis and correlation. Typically, this would require installing the [Log Analytics agent](../../../azure-monitor/agents/agents-overview.md#log-analytics-agent) on the machine using a script, manually, or an automated method following your configuration management standards. Now, Azure Arc-enabled servers can install the Log Analytics and Dependency agent [VM extension](../manage-vm-extensions.md) for Windows and Linux, enabling [VM insights](../../../azure-monitor/vm/vminsights-overview.md) to collect data from your non-Azure VMs.

- Disconnecting the machine from Azure Arc-enabled servers doesn't remove the Connected Machine agent, and you do not need to remove the agent as part of this process.

-| AAD | `login.windows.net`, `login.microsoftonline.com`, `pas.windows.net` |

-* Learn how to manage your machine using [Azure Policy](../../governance/policy/overview.md), for such things as VM [guest configuration](../../governance/policy/concepts/guest-configuration.md), verifying the machine is reporting to the expected Log Analytics workspace, enable monitoring with [VM insights](../../azure-monitor/vm/vminsights-enable-policy.md), and much more.

- Disconnecting the machine from Azure Arc-enabled servers does not remove the Connected Machine agent, and you don't need to remove the agent as part of this process.

-4. Redeploy the VM extensions that were originally deployed to the machine from Azure Arc-enabled servers.

-

-* Learn how to manage your machine using [Azure Policy](../../governance/policy/overview.md), for such things as VM [guest configuration](../../governance/policy/concepts/guest-configuration.md), verifying the machine is reporting to the expected Log Analytics workspace, enable monitoring with [VM insights](../../azure-monitor/vm/vminsights-enable-policy.md) policy, and much more.

-> The Desired State Configuration VM extension is no longer available for Azure Arc-enabled servers. Alternatively, we recommend [migrating to guest configuration](../../governance/policy/how-to/guest-configuration-azure-automation-migration.md) or using the Custom Script Extension to manage the post-deployment configuration of your server.

-The Log Analytics agent VM extension for Linux requires Python 2.x is installed on the target machine.

-description: In this article, you learn how to connect machines to Azure using Azure Arc-enabled servers using Ansible playbooks.

-Before you get started, be sure to review the [prerequisites](prerequisites.md) and verify that your subscription and resources meet the requirements. For information about supported regions and other related considerations, see [supported Azure regions](overview.md#supported-regions). Also review our [at-scale planning guide](plan-at-scale-deployment.md) to understand the design and deployment criteria, as well as our management and monitoring recommendations.

- when: (ansible_system == 'Linux') and (azcmagent_lnx_downloaded.stat.exists == false)

- when: (ansible_system == 'Linux') and (not azcmagent_lnx_downloaded.stat.exists)

- when: (ansible_os_family == 'Windows') and (not azcmagent_win_downloaded.stat.exists)

- become: true

- when: (ansible_os_family == 'Windows') and (azcmagent_win_connected.rc is defined and azcmagent_win_connected.rc != 0)

-After you have successfully installed the agent and configured it to connect to Azure Arc-enabled servers, go to the Azure portal to verify that the servers in your target hosts have successfully connected. View your machines in the [Azure portal](https://aka.ms/hybridmachineportal).

-description: You can use a custom task sequence that can deploy the Connected Machine Agent to onboard a collection of devices to Azure Arc-enabled servers.

-Microsoft Endpoint Configuration Manager facilitates comprehensive management of servers supporting the secure and scalable deployment of applications, software updates, and operating systems. Configuration Manager offers the custom task sequence as a flexible paradigm for application deployment.

-Before you get started, be sure to review the [prerequisites](prerequisites.md) and verify that your subscription and resources meet the requirements. For information about supported regions and other related considerations, see [supported Azure regions](overview.md#supported-regions). Also review our [at-scale planning guide](plan-at-scale-deployment.md) to understand the design and deployment criteria, as well as our management and monitoring recommendations.

-description: You can use Configuration Manager to run a PowerShell script that automates at-scale onboarding to Azure Arc-enabled servers.

-Microsoft Endpoint Configuration Manager facilitates comprehensive management of servers supporting the secure and scalable deployment of applications, software updates, and operating systems. Configuration Manager has an integrated ability to run PowerShell scripts.

-Before you get started, be sure to review the [prerequisites](prerequisites.md) and verify that your subscription and resources meet the requirements. For information about supported regions and other related considerations, see [supported Azure regions](overview.md#supported-regions). Also review our [at-scale planning guide](plan-at-scale-deployment.md) to understand the design and deployment criteria, as well as our management and monitoring recommendations.

-* Learn how to manage your machine using [Azure Policy](../../governance/policy/overview.md), for such things as VM [guest configuration](../../governance/policy/concepts/guest-configuration.md), verifying the machine is reporting to the expected Log Analytics workspace, enable monitoring with [VM insights](../../azure-monitor/vm/vminsights-enable-policy.md), and much more.

-description: In this article, you learn how to create a Group Policy Object to onboard Active Directory-joined Windows machines to Azure Arc-enabled servers.

-Before you get started, be sure to review the [prerequisites](prerequisites.md) and verify that your subscription and resources meet the requirements. For information about supported regions and other related considerations, see [supported Azure regions](overview.md#supported-regions). Also review our [at-scale planning guide](plan-at-scale-deployment.md) to understand the design and deployment criteria, as well as our management and monitoring recommendations.

- > [!NOTE]

-1. Download the latest version of the [Windows agent Windows Installer package](https://aka.ms/AzureConnectedMachineAgent) from the Microsoft Download Center and save it to the remote share.

-On the Group Policy Management Console (GPMC), right-click on the desired Organizational Unit and link the GPO named **[MSFT] Azure Arc Servers (datetime)**. This is the Group Policy Object which has the Scheduled Task to onboard the machines. After 10 or 20 minutes, the Group Policy Object will be replicated to the respective domain controllers. Learn more about [creating and managing group policy in Azure AD Domain Services](../../active-directory-domain-services/manage-group-policy.md).

-After you have successfully installed the agent and configured it to connect to Azure Arc-enabled servers, go to the Azure portal to verify that the servers in your Organizational Unit have successfully connected. View your machines in the [Azure portal](https://aka.ms/hybridmachineportal).

-* Learn how to manage your machine using [Azure Policy](../../governance/policy/overview.md) for such things as VM [guest configuration](../../governance/policy/concepts/guest-configuration.md), verifying that the machine is reporting to the expected Log Analytics workspace, enabling monitoring with [VM insights](../../azure-monitor/vm/vminsights-enable-policy.md), and much more.

-description: In this article, you learn how to connect machines to Azure using Azure Arc-enabled servers using group policy.

-Before you get started, be sure to review the [prerequisites](prerequisites.md) and verify that your subscription and resources meet the requirements. For information about supported regions and other related considerations, see [supported Azure regions](overview.md#supported-regions). Also review our [at-scale planning guide](plan-at-scale-deployment.md) to understand the design and deployment criteria, as well as our management and monitoring recommendations.

-1. Download the latest version of the [Windows agent Windows Installer package](https://aka.ms/AzureConnectedMachineAgent) from the Microsoft Download Center and save it to the remote share.

-{

- "tenant-id": "INSERT AZURE TENANTID",

- "subscription-id": "INSERT AZURE SUBSCRIPTION ID",

- "resource-group": "INSERT RESOURCE GROUP NAME",

- "location": "INSERT REGION",

- "service-principal-id": "INSERT SPN ID",

- "service-principal-secret": "INSERT SPN Secret"

- }

-# This script is used to install and configure the Azure Connected Machine Agent

-}

-"@ >> $logPath

- throw "Could not read installation data from registry, a problem may have occurred during installation"

-}

-Create a new Group Policy Object (GPO) to run the onboarding script using the configuration file details:

-1. Open the Group Policy Management Console (GPMC).

-1. Navigate to the Organization Unit (OU), Domain, or Security Group in your AD forest that contains the machines you want to onboard to Azure Arc-enabled servers.

-1. Right-click on this set of resources and select **Create a GPO in this domain, and Link it here.**

-The newly created GPO needs to be modified to run the onboarding script at the appropriate cadence. Use Group PolicyΓÇÖs built-in Scheduled Task capabilities to do so:

-1. Right-click in the blank area and select **New > Scheduled Task**.

-Your workstation must be running Windows 7 or higher to be able to create a Scheduled Task from Group Policy Management Console.

-1. In the field **When running the task, use the following user account:**, enter "NT AUTHORITY\System".

-1. Select **Run whether user is logged on or not**.

-1. Check the box for **Run with highest privileges**.

-1. In the field **Configure for**, select **Windows Vista or Window 2008**.

-1. In the field **Begin the task**, select **On a schedule**.

-1. Under **Advanced Settings**, check the box for **Enabled**.

-1. Once you've set the trigger parameters, select **OK**.

-In the **Actions** tab, select **New**, then enter the follow parameters in the **New Action** window:

-1. For **Action**, select **Start a program** from the dropdown.

-1. For **Add arguments (optional)**, enter `-ExecutionPolicy Bypass -command <INSERT UNC-path to PowerShell script> -remotePath <INSERT path to your Remote Share>`.

-1. For **Start In (Optional)**, enter `C:\`.

-## Apply the Group Policy Object

-On the Group Policy Management Console, right-click on the desired Organizational Unit and select the option to link an existent GPO. Choose the Group Policy Object defined in the Scheduled Task. After 10 or 20 minutes, the Group Policy Object will be replicated to the respective domain controllers. Learn more about [creating and managing group policy in Azure AD Domain Services](../../active-directory-domain-services/manage-group-policy.md).

-After you have successfully installed the agent and configured it to connect to Azure Arc-enabled servers, go to the Azure portal to verify that the servers in your Organizational Unit have successfully connected. View your machines in the [Azure portal](https://aka.ms/hybridmachineportal).

-1. To download and install the agent, run the following commands. If your machine needs to communicate through a proxy server to connect to the internet, include the `--proxy` parameter.

-

-

-

-

-

-

-* Learn how to manage your machine by using [Azure Policy](../../governance/policy/overview.md). You can use VM [guest configuration](../../governance/policy/concepts/guest-configuration.md), verify that the machine is reporting to the expected Log Analytics workspace, and enable monitoring with [VM insights](../../azure-monitor/vm/vminsights-enable-policy.md).

-One method to connect the machines to Azure Arc-enabled servers is to use an Azure Active Directory [service principal](../../active-directory/develop/app-objects-and-service-principals.md). This service principal method can be used instead of your privileged identity to [interactively connect the machine](onboard-portal.md). This service principal is a special limited management identity that has only the minimum permission necessary to connect machines to Azure using the `azcmagent` command. This method is safer than using a higher privileged account like a Tenant Administrator and follows our access control security best practices. **The service principal is used only during onboarding; it is not used for any other purpose.**

-Before you get started, be sure to review the [prerequisites](prerequisites.md) and verify that your subscription and resources meet the requirements. For information about supported regions and other related considerations, see [supported Azure regions](overview.md#supported-regions). Also review our [at-scale planning guide](plan-at-scale-deployment.md) to understand the design and deployment criteria, as well as our management and monitoring recommendations.-->

-4. Assign the **Azure Connected Machine Onboarding** role to the service principal for the designated resource group or subscription. This role contains only the permissions required to onboard a machine. Note that your account must be a member of the **Owner** or **User Access Administrator** role for the subscription to which the service principal will have access. For information on how to add role assignments, see [Assign Azure roles using the Azure portal](../../role-based-access-control/role-assignments-portal.md) or [Assign Azure roles using Azure CLI](../../role-based-access-control/role-assignments-cli.md).

-When the onboarding process is launched, an Active Directory [service principal](../../active-directory/fundamentals/service-accounts-principal.md) is created in the tenant.

-This method requires that you are a member of the [Automation Job Operator](../../automation/automation-role-based-access-control.md#automation-job-operator) role or higher so you can create runbook jobs in the Automation account.

-If you have enabled Azure Policy to [manage runbook execution](../../automation/enforce-job-execution-hybrid-worker.md) and enforce targeting of runbook execution against a Hybrid Runbook Worker group, this policy must be disabled. Otherwise, the runbook jobs that onboard the machine(s) to Arc-enabled servers will fail.

- You can review your selection by selecting **Review selection** and if you want to remove a machine select **remove** from under the **Action** column.

-* Learn how to manage your machine using [Azure Policy](../../governance/policy/overview.md), for such things as VM [guest configuration](../../governance/policy/concepts/guest-configuration.md), verifying the machine is reporting to the expected Log Analytics workspace, enable monitoring with [VM insights](../../azure-monitor/vm/vminsights-enable-policy.md), and much more.

- * Assign [Azure Policy guest configurations](../../governance/policy/concepts/guest-configuration.md) to audit settings inside the machine. To understand the cost of using Azure Policy Guest Configuration policies with Arc-enabled servers, see Azure Policy [pricing guide](https://azure.microsoft.com/pricing/details/azure-policy/).

- * Collect other log data, such as performance data and events, from the operating system or workloads running on the machine with the [Log Analytics agent](../../azure-monitor/agents/agents-overview.md#log-analytics-agent). This data is stored in a [Log Analytics workspace](../../azure-monitor/logs/log-analytics-workspace-overview.md).

-The Connected Machine agent sends a regular heartbeat message to the service every five minutes. If the service stops receiving these heartbeat messages from a machine, that machine is considered offline, and its status will automatically be changed to **Disconnected** within 15 to 30 minutes. Upon receiving a subsequent heartbeat message from the Connected Machine agent, its status will automatically be changed back to **Connected**.

-* Review Azure role-based access control (Azure RBAC) access rights granted to the Azure Arc-enabled server resource to maintain who has access to the resource after it has been migrated to an Azure VM.

-A system-managed identity is also used when Azure Policy is used to audit or configure settings inside a machine or server. With Azure Arc-enabled servers, the guest configuration agent service is included, and performs validation of audit settings. After you migrate, see [Deploy requirements for Azure virtual machines](../../governance/policy/concepts/guest-configuration.md#deploy-requirements-for-azure-virtual-machines) for information on how to configure your Azure VM manually or with policy with the guest configuration extension.

-After migration and completion of all post-migration configuration steps, you can now deploy the Azure VM extensions based on the VM extensions originally installed on your Azure Arc-enabled server. Review [Azure virtual machine extensions and features](../../virtual-machines/extensions/overview.md) to help plan your extension deployment.

-To resume using audit settings inside a machine with guest configuration policy definitions, see [Enable guest configuration](../../governance/policy/concepts/guest-configuration.md#enable-guest-configuration).

-If the Log Analytics VM extension or Dependency agent VM extension was deployed using Azure Policy and the [VM insights initiative](../../azure-monitor/vm/vminsights-enable-policy.md), remove the [exclusion](../../governance/policy/tutorials/create-and-manage.md#remove-a-non-compliant-or-denied-resource-from-the-scope-with-an-exclusion) you created earlier. To use Azure Policy to enable Azure virtual machines, see [Deploy Azure Monitor at scale using Azure Policy](../../azure-monitor/best-practices.md).

-| [Azure Policy's guest configuration](../../governance/policy/concepts/guest-configuration.md) | &#x2705; | &#x2705; |

-| [Azure Policy's guest configuration](../../governance/policy/concepts/guest-configuration.md) | &#x2705; | &#x2705; | &#x2705; | &#x2705; | |

-description: This article provides a detailed overview of the Azure agents that are available and support monitoring virtual machines hosted in an Azure or hybrid environment.

-# Overview of Azure Monitor agents

-Virtual machines and other compute resources require an agent to collect monitoring data required to measure the performance and availability of their guest operating system and workloads. Many legacy agents exist today for this purpose. Eventually, they'll all be replaced by the new consolidated [Azure Monitor agent](./azure-monitor-agent-overview.md). This article describes the legacy agents and the new Azure Monitor agent.

-The general recommendation is to use the Azure Monitor agent if you aren't bound by [these limitations](./azure-monitor-agent-overview.md#current-limitations) because it consolidates the features of all the legacy agents listed here and provides [other benefits](#azure-monitor-agent).

-If you do require the limitations today, you may continue to use the other legacy agents listed here until **August 2024**. [Learn more](./azure-monitor-agent-overview.md).

-## Summary of agents

-The following tables provide a quick comparison of the telemetry agents for Windows and Linux. More information on each agent is provided in the following sections.

-### Windows agents

-| | Azure Monitor agent | Diagnostics<br>extension (WAD) | Log Analytics<br>agent |

-|:|:-|:|:|

-| **Environments supported** | Azure<br>Other cloud (Azure Arc)<br>On-premises (Azure Arc)<br>[Windows Client OS (preview)](./azure-monitor-agent-windows-client.md) | Azure | Azure<br>Other cloud<br>On-premises |

-| **Agent requirements** | None | None | None |

-| **Data collected** | Event Logs<br>Performance<br>File based logs (preview)<br> | Event Logs<br>ETW events<br>Performance<br>File based logs<br>IIS logs<br>.NET app logs<br>Crash dumps<br>Agent diagnostics logs | Event Logs<br>Performance<br>File based logs<br>IIS logs<br>Insights and solutions<br>Other services |

-| **Data sent to** | Azure Monitor Logs<br>Azure Monitor Metrics¹ | Azure Storage<br>Azure Monitor Metrics<br>Event Hub | Azure Monitor Logs |

-| **Services and**<br>**features**<br>**supported** | Log Analytics<br>Metrics explorer<br>Microsoft Sentinel ([view scope](./azure-monitor-agent-overview.md#supported-services-and-features)) | Metrics explorer | VM insights<br>Log Analytics<br>Azure Automation<br>Microsoft Defender for Cloud<br>Microsoft Sentinel |

-### Linux agents

-| | Azure Monitor agent | Diagnostics<br>extension (LAD) | Telegraf<br>agent | Log Analytics<br>agent |

-| : | :- | :-- | :- | :-- |

-| **Environments supported** | Azure<br>Other cloud (Azure Arc)<br>On-premises (Azure Arc) | Azure | Azure<br>Other cloud<br>On-premises | Azure<br>Other cloud<br>On-premises |

-| **Agent requirements** | None | None | None | None |

-| **Data collected** | Syslog<br>Performance<br>File based logs (preview)<br> | Syslog<br>Performance | Performance | Syslog<br>Performance |

-| **Data sent to** | Azure Monitor Logs<br>Azure Monitor Metrics¹ | Azure Storage<br>Event Hub | Azure Monitor Metrics | Azure Monitor Logs |

-| **Services and**<br>**features**<br>**supported** | Log Analytics<br>Metrics explorer<br>Microsoft Sentinel ([view scope](./azure-monitor-agent-overview.md#supported-services-and-features)) | | Metrics explorer | VM insights<br>Log Analytics<br>Azure Automation<br>Microsoft Defender for Cloud<br>Microsoft Sentinel |

-¹ To review other limitations of using Azure Monitor Metrics, see [quotas and limits](../essentials/metrics-custom-overview.md#quotas-and-limits). On Linux, using Azure Monitor Metrics as the only destination is supported in v.1.10.9.0 or higher.

-## Azure Monitor agent

-The [Azure Monitor agent](azure-monitor-agent-overview.md) is meant to replace the Log Analytics agent, Azure Diagnostics extension, and Telegraf agent for Windows and Linux machines. It can send data to Azure Monitor Logs and Azure Monitor Metrics and uses [data collection rules (DCRs)](../essentials/data-collection-rule-overview.md). DCRs provide a more scalable method of configuring data collection and destinations for each agent.

-Use the Azure Monitor agent to gain these benefits:

-<! Send data to Azure Storage for archiving.

-When compared with the legacy agents, the Azure Monitor agent has [these limitations currently](./azure-monitor-agent-overview.md#current-limitations).

-## Log Analytics agent

-> [!WARNING]

-> The Log Analytics agents are on a deprecation path and will no longer be supported after August 31, 2024.

-The legacy [Log Analytics agent](./log-analytics-agent.md) collects monitoring data from the guest operating system and workloads of virtual machines in Azure, other cloud providers, and on-premises machines. It sends data to a Log Analytics workspace. The Log Analytics agent is the same agent used by System Center Operations Manager. You can multihome agent computers to communicate with your management group and Azure Monitor simultaneously. This agent is also required by certain insights in Azure Monitor and other services in Azure.

-> [!NOTE]

-> The Log Analytics agent for Windows is often referred to as Microsoft Monitoring Agent (MMA). The Log Analytics agent for Linux is often referred to as OMS agent.

-Use the Log Analytics agent if you need to:

-* Collect logs and performance data from Azure virtual machines or hybrid machines hosted outside of Azure.

-* Send data to a Log Analytics workspace to take advantage of features supported by [Azure Monitor Logs](../logs/data-platform-logs.md), such as [log queries](../logs/log-query-overview.md).

-* Use [VM insights](../vm/vminsights-overview.md), which allows you to monitor your machines at scale and monitor their processes and dependencies on other resources and external processes.

-* Manage the security of your machines by using [Microsoft Defender for Cloud](../../security-center/security-center-introduction.md) or [Microsoft Sentinel](../../sentinel/overview.md).

-* Use [Azure Automation Update Management](../../automation/update-management/overview.md), [Azure Automation State Configuration](../../automation/automation-dsc-overview.md), or [Azure Automation Change Tracking and Inventory](../../automation/change-tracking/overview.md) to deliver comprehensive management of your Azure and non-Azure machines.

-* Use different [solutions](../monitor-reference.md#insights-and-curated-visualizations) to monitor a particular service or application.

-Limitations of the Log Analytics agent:

-## Azure Diagnostics extension

-The [Azure Diagnostics extension](./diagnostics-extension-overview.md) collects monitoring data from the guest operating system and workloads of Azure virtual machines and other compute resources. It primarily collects data into Azure Storage. It also allows you to define data sinks to send data to other destinations, such as Azure Monitor Metrics and Azure Event Hubs.

-Use the Azure Diagnostics extension if you need to:

-Limitations of the Azure Diagnostics extension:

-## Telegraf agent

-The [InfluxData Telegraf agent](../essentials/collect-custom-metrics-linux-telegraf.md) is used to collect performance data from Linux computers to send to Azure Monitor Metrics.

-Use the Telegraf agent if you need to:

-* Send data to [Azure Monitor Metrics](../essentials/data-platform-metrics.md) to analyze it with [Metrics Explorer](../essentials/metrics-getting-started.md) and to take advantage of features such as near-real-time [metric alerts](../alerts/alerts-metric-overview.md) and [autoscale](../autoscale/autoscale-overview.md) (Linux only).

-## Virtual machine extensions

-The [Azure Monitor agent](./azure-monitor-agent-manage.md#virtual-machine-extension-details) is only available as a virtual machine extension. The Log Analytics extension for [Windows](../../virtual-machines/extensions/oms-windows.md) and [Linux](../../virtual-machines/extensions/oms-linux.md) install the Log Analytics agent on Azure virtual machines. These are the same agents described above but allow you to manage them through [virtual machine extensions](../../virtual-machines/extensions/overview.md). You should use extensions to install and manage the agents whenever possible.

-On hybrid machines, use [Azure Arc-enabled servers](../../azure-arc/servers/manage-vm-extensions.md) to deploy the Azure Monitor agent, Log Analytics, and Azure Monitor Dependency VM extensions.

-## Supported operating systems

-The following tables list the operating systems that are supported by the Azure Monitor agents. See the documentation for each agent for unique considerations and for the installation process. See Telegraf documentation for its supported operating systems. All operating systems are assumed to be x64. x86 is not supported for any operating system.

-### Windows

-### Linux

-| AlmaLinux 8.* | X | X | |

-| Rocky Linux 8.* | X | X | |

-| Ubuntu 20.04 LTS | X | X | X ⁴ |

-## Next steps

-For more information on each of the agents, see the following articles:

-description: This article provides guidance for migrating from the existing legacy agents to the new Azure Monitor agent (AMA) and data collection rules (DCR).

-# Customer intent: As an Azure account administrator, I want to use the available Azure Monitor tools to migrate from Log Analytics agent to Azure Monitor Agent and track the status of the migration in my account.

-# Migrate to Azure Monitor agent from Log Analytics agent

-The [Azure Monitor agent (AMA)](azure-monitor-agent-overview.md) collects monitoring data from the guest operating system of Azure and hybrid virtual machines and delivers it to Azure Monitor where it can be used by different features, insights, and other services such as [Microsoft Sentinel](../../sentintel/../sentinel/overview.md) and [Microsoft Defender for Cloud](../../defender-for-cloud/defender-for-cloud-introduction.md). All of the data collection configuration is handled via [Data Collection Rules](../essentials/data-collection-rule-overview.md). The Azure Monitor agent is meant to replace the Log Analytics agent (also known as MMA and OMS) for both Windows and Linux machines. This article provides high-level guidance on when and how to migrate to the new Azure Monitor agent (AMA) and the data collection rules (DCR) that define the data the agent should collect.

-## Why should I migrate to the Azure Monitor agent?

- - AMA uses Managed Identity or Azure Active Directory (Azure AD) tokens (for clients) which are much more secure than the legacy authentication methods.

- - AMA can provide higher events per second (EPS) upload rate compared to legacy agents

- - DCRs allow granular targeting of machines connected to a workspace to collect data from as compared to the ΓÇ£all or nothingΓÇ¥ mode that legacy agents have.

- - Using DCRs, you can filter out data to remove unused events and save additional costs.

- - **Multihoming** on both Windows and Linux is possible easily

- - Every action across the data collection lifecycle, from onboarding/setup to deployment to updates and changes over time, is significantly easier and scalable thanks to agent configuration becoming centralized and ΓÇÿin the cloudΓÇÖ as compared to configuring things on every machine.

- - Enabling/disabling of additional capabilities or services (Sentinel, Defender for Cloud, VM Insights, etc.) is more transparent and controlled, using the extensibility architecture of AMA.

-## When should I migrate to the Azure Monitor agent?

-Your migration plan to the Azure Monitor agent should include the following considerations:

-|Consideration |Description |

-|||

-|**Environment requirements** | Verify that your environment is currently supported by the AMA. For more information, see [Supported operating systems](./agents-overview.md#supported-operating-systems). |

-|**Current and new feature requirements** | While the AMA provides [several new features](#current-capabilities), such as filtering, scoping, and multihoming, it is not yet at parity with the legacy Log Analytics agent.As you plan your migration, make sure that the features your organization requires are already supported by the AMA. You may decide to continue using the Log Analytics agent for now, and migrate at a later date. See [Supported services and features](./azure-monitor-agent-overview.md#supported-services-and-features) for a current status of features that are supported and that may be in preview. |

-> [!IMPORTANT]

-> The Log Analytics agent will be [retired on **31 August, 2024**](https://azure.microsoft.com/updates/were-retiring-the-log-analytics-agent-in-azure-monitor-on-31-august-2024/). If you are currently using the Log Analytics agent with Azure Monitor or other supported features and services, you should start planning your migration to the Azure Monitor agent using the information in this article.

-## Current capabilities

-Azure Monitor agent currently supports the following core functionality:

-> [!NOTE]

-> Windows and Linux machines that reside on cloud platforms other than Azure, or are on-premises machines, must be Azure Arc-enabled so that the AMA can send logs to the Log Analytics workspace. For more information, see:

->

-> - [What are Azure ArcΓÇôenabled servers?](../../azure-arc/servers/overview.md)

-> - [Overview of Azure Arc ΓÇô enabled servers agent](../../azure-arc/servers/agent-overview.md)

-> - [Plan and deploy Azure Arc ΓÇô enabled servers at scale](../../azure-arc/servers/plan-at-scale-deployment.md)

-## Gap analysis between agents

-The following tables show gap analyses for the **log types** that are currently collected by each agent. This will be updated as support for AMA grows towards parity with the Log Analytics agent. For a general comparison of Azure Monitor agents, see [Overview of Azure Monitor agents](../agents/azure-monitor-agent-overview.md).

-> If you use Microsoft Sentinel, see [Gap analysis for Microsoft Sentinel](../../sentinel/ama-migrate.md#gap-analysis-between-agents) for a comparison of the additional data collected by Microsoft Sentinel.

-### Windows logs

-|Log type / Support |Azure Monitor agent support |Log Analytics agent support |

-||||

-| **Security Events** | Yes | No |

-| **Performance counters** | Yes | Yes |

-| **Windows Event Logs** | Yes | Yes |

-| **Filtering by event ID** | Yes | No |

-| **Text logs** | Yes | Yes |

-| **IIS logs** | Yes | Yes |

-| **Application and service logs** | Yes | Yes |

-| **Multi-homing** | Yes | Yes |

-### Linux logs

-|Log type / Support |Azure Monitor agent support |Log Analytics agent support |

-||||

-| **Syslog** | Yes | Yes |

-| **Performance counters** | Yes | Yes |

-| **Text logs** | Yes | Yes |

-| **Multi-homing** | Yes | No |

-## Test migration by using the Azure portal

-To ensure safe deployment during migration, you should begin testing with a few resources in your nonproduction environment that are running the existing Log Analytics agent. After you can validate the data collected on these test resources, roll out to production by following the same steps.

-See [create new data collection rules](./data-collection-rule-azure-monitor-agent.md#create-data-collection-rule-and-association) to start collecting some of the existing data types. Once you validate data is flowing as expected with the Azure Monitor agent, check the `Category` column in the [Heartbeat](/azure/azure-monitor/reference/tables/heartbeat) table for the value *Azure Monitor Agent* for AMA collected data. Ensure it matches data flowing through the existing Log Analytics agent.

-See [Using Azure Policy](azure-monitor-agent-manage.md#using-azure-policy) for details on deploying Azure Monitor agent across a set of virtual machines. Associate the agents to the data collection rules developed during your [testing](#test-migration-by-using-the-azure-portal).

-Validate that data is flowing as expected with the Azure Monitor agent and that all downstream dependencies like dashboards, alerts, and runbook workers. Workbooks should all continue to function using data from the new agent.

-When you confirm that data is being collected properly, [uninstall the Log Analytics agent](./agent-manage.md#uninstall-agent) from the resources. Don't uninstall it if you need to use it for System Center Operations Manager scenarios or others solutions not yet available on the Azure Monitor agent. Clean up any configuration files, workspace keys, or certificates that were used previously by the Log Analytics agent.

-description: Overview of the Azure Monitor agent, which collects monitoring data from the guest operating system of virtual machines.

-# Azure Monitor agent overview

-The Azure Monitor agent collects monitoring data from the guest operating system of [supported infrastructure](#supported-resource-types) and delivers it to Azure Monitor. This article provides an overview of the Azure Monitor agent and includes information on how to install it and configure data collection.

-If you're new to Azure Monitor, the recommendation is to use the Azure Monitor agent.

-For an introductory video that explains this new agent and includes a quick demo of how to set things up by using the Azure portal, see [ITOps Talk: Azure Monitor Agent](https://www.youtube.com/watch?v=f8bIrFU8tCs).

-## Relationship to other agents

-Eventually, the Azure Monitor agent will replace the following legacy monitoring agents that are currently used by Azure Monitor:

-Currently, the Azure Monitor agent consolidates features from the Telegraf agent and Log Analytics agent, with [a few limitations](#current-limitations). See migration guidance [here](azure-monitor-agent-migration.md).

-In the future, it will also consolidate features from the Diagnostic extensions.

-In addition to consolidating this functionality into a single agent, the Azure Monitor agent provides the following benefits over the existing agents:

- - Granular targeting via [data collection rules](../essentials/data-collection-rule-overview.md) to collect specific data types from specific machines, as compared to the "all or nothing" mode that Log Analytics agent supports.

- - XPath queries to filter Windows events get collected to help further reduce ingestion and storage costs.

-### Current limitations

- Not all Log Analytics solutions are supported yet. [View supported features and services](#supported-services-and-features).

-### Changes in data collection

-The methods for defining data collection for the existing agents are distinctly different from each other. Each method has challenges that are addressed with the Azure Monitor agent:

-The Azure Monitor agent uses [data collection rules](../essentials/data-collection-rule-overview.md) to configure data to collect from each agent. Data collection rules enable manageability of collection settings at scale while still enabling unique, scoped configurations for subsets of machines. They're independent of the workspace and independent of the virtual machine, which allows them to be defined once and reused across machines and environments.

-For more information, see [Configure data collection for the Azure Monitor agent](data-collection-rule-azure-monitor-agent.md).

-## Coexistence with other agents

-The Azure Monitor agent can coexist (run side by side on the same machine) with the legacy Log Analytics agents so that you can continue to use their existing functionality during evaluation or migration. For this reason, you can begin transition even with the limitations, but you must review the following points carefully:

- If you install the Azure Monitor agent and create a data collection rule for these same events and performance data, it will result in duplicate data. As a result, ensure you're not collecting the same data from both agents. If you are, ensure they're *collecting from different machines* or *going to separate destinations*.

-> [!NOTE]

-> When you use both agents during evaluation or migration, you can use the **Category** column of the [Heartbeat](/azure/azure-monitor/reference/tables/Heartbeat) table in your Log Analytics workspace, and filter for **Azure Monitor Agent**.

-## Supported resource types

-| Resource type | Installation method | More information |

-|:|:|:|

-| Virtual machines, scale sets | [Virtual machine extension](./azure-monitor-agent-manage.md#virtual-machine-extension-details) | Installs the agent by using Azure extension framework. |

-| On-premises servers (Azure Arc-enabled servers) | [Virtual machine extension](./azure-monitor-agent-manage.md#virtual-machine-extension-details) (after installing the [Azure Arc agent](../../azure-arc/servers/deployment-options.md)) | Installs the agent by using Azure extension framework, provided for on-premises by first installing [Azure Arc agent](../../azure-arc/servers/deployment-options.md). |

-| Windows 10, 11 desktops, workstations | [Client installer (preview)](./azure-monitor-agent-windows-client.md) | Installs the agent by using a Windows MSI installer. |

-| Windows 10, 11 laptops | [Client installer (preview)](./azure-monitor-agent-windows-client.md) | Installs the agent by using a Windows MSI installer. The installer works on laptops, but the agent is *not optimized yet* for battery or network consumption. |

-## Supported regions

-Azure Monitor agent is available in all public regions and Azure Government clouds. It's not yet supported in air-gapped clouds. For more information, see [Product availability by region](https://azure.microsoft.com/global-infrastructure/services/?products=monitor&rar=true&regions=all).

-## Supported operating systems

-For a list of the Windows and Linux operating system versions that are currently supported by the Azure Monitor agent, see [Supported operating systems](agents-overview.md#supported-operating-systems).

-## Data sources and destinations

-The following table lists the types of data you can currently collect with the Azure Monitor agent by using data collection rules and where you can send that data. For a list of insights, solutions, and other solutions that use the Azure Monitor agent to collect other kinds of data, see [What is monitored by Azure Monitor?](../monitor-reference.md).

-The Azure Monitor agent sends data to Azure Monitor Metrics (preview) or a Log Analytics workspace supporting Azure Monitor Logs.

-| Data source | Destinations | Description |

-|:|:|:|

-| Performance | Azure Monitor Metrics (preview)¹ - Insights.virtualmachine namespace<br>Log Analytics workspace - [Perf](/azure/azure-monitor/reference/tables/perf) table | Numerical values measuring performance of different aspects of operating system and workloads |

-| Windows event logs | Log Analytics workspace - [Event](/azure/azure-monitor/reference/tables/Event) table | Information sent to the Windows event logging system |

-| Syslog | Log Analytics workspace - [Syslog](/azure/azure-monitor/reference/tables/syslog)² table | Information sent to the Linux event logging system |

-| Text logs | Log Analytics workspace - custom table | Events sent to log file on agent machine |

-¹ To review other limitations of using Azure Monitor Metrics, see [Quotas and limits](../essentials/metrics-custom-overview.md#quotas-and-limits). On Linux, using Azure Monitor Metrics as the only destination is supported in v1.10.9.0 or higher.<br>

-² Azure Monitor Linux Agent v1.15.2 or higher supports syslog RFC formats including Cisco Meraki, Cisco ASA, Cisco FTD, Sophos XG, Juniper Networks, Corelight Zeek, CipherTrust, NXLog, McAfee, and Common Event Format (CEF).

-## Supported services and features

-The following table shows the current support for the Azure Monitor agent with other Azure services.

-| Azure service | Current support | More information |

-|:|:|:|

-| [Microsoft Defender for Cloud](../../security-center/security-center-introduction.md) | Private preview | [Sign-up link](https://aka.ms/AMAgent) |

-| [Microsoft Sentinel](../../sentinel/overview.md) | <ul><li>Windows DNS logs: Private preview</li><li>Linux Syslog CEF: Private preview</li><li>Windows Forwarding Event (WEF): [Public preview](../../sentinel/data-connectors-reference.md#windows-forwarded-events-preview)</li><li>Windows Security Events: [Generally available](../../sentinel/connect-windows-security-events.md?tabs=AMA)</li></ul> | <ul><li>[Sign-up link](https://aka.ms/AMAgent)</li><li>[Sign-up link](https://aka.ms/AMAgent)</li><li>No sign-up needed </li><li>No sign-up needed</li></ul> |

-The following table shows the current support for the Azure Monitor agent with Azure Monitor features.

-| Azure Monitor feature | Current support | More information |

-|:|:|:|

-| Text logs and Windows IIS logs | Public preview | [Collect text logs with Azure Monitor agent (preview)](data-collection-text-log.md) |

-| Windows client installer | Public preview | [Set up Azure Monitor agent on Windows client devices](azure-monitor-agent-windows-client.md) |

-| [VM insights](../vm/vminsights-overview.md) | Private preview | [Sign-up link](https://aka.ms/amadcr-privatepreviews) |

-The following table shows the current support for the Azure Monitor agent with Azure solutions.

-| Solution | Current support | More information |

-|:|:|:|

-| [Change Tracking](../../automation/change-tracking/overview.md) | Supported as File Integrity Monitoring in the Microsoft Defender for Cloud Private Preview. | [Sign-up link](https://aka.ms/AMAgent) |

-| [Update Management](../../automation/update-management/overview.md) | Use Update Management v2 - Public preview | [Update management center (preview) documentation](/azure/update-center/) |

-## Costs

-There's no cost for the Azure Monitor agent, but you might incur charges for the data ingested. For information on Log Analytics data collection and retention and for customer metrics, see [Azure Monitor pricing](https://azure.microsoft.com/pricing/details/monitor/).

-## Security

-The Azure Monitor agent doesn't require any keys but instead requires a [system-assigned managed identity](../../active-directory/managed-identities-azure-resources/qs-configure-portal-windows-vm.md#system-assigned-managed-identity). You must have a system-assigned managed identity enabled on each virtual machine before you deploy the agent.

-## Networking

-The Azure Monitor agent supports Azure service tags. Both *AzureMonitor* and *AzureResourceManager* tags are required. It supports connecting via *direct proxies, Log Analytics gateway, and private links* as described in the following sections.

-### Firewall requirements

-| Cloud |Endpoint |Purpose |Port |Direction |Bypass HTTPS inspection|

-|||||--|--|

-| Azure Commercial |global.handler.control.monitor.azure.com |Access control service|Port 443 |Outbound|Yes |

-| Azure Commercial |`<virtual-machine-region-name>`.handler.control.monitor.azure.com |Fetch data collection rules for specific machine |Port 443 |Outbound|Yes |

-| Azure Commercial |`<log-analytics-workspace-id>`.ods.opinsights.azure.com |Ingest logs data |Port 443 |Outbound|Yes |

-| Azure Commercial | management.azure.com | Only needed if sending timeseries data (metrics) to Azure Monitor [Custom metrics](../essentials/metrics-custom-overview.md) database | Port 443 | Outbound | Yes |

-| Azure Government | Replace '.com' above with '.us' | Same as above | Same as above | Same as above| Same as above |

-| Azure China | Replace '.com' above with '.cn' | Same as above | Same as above | Same as above| Same as above |

-If you use private links on the agent, you must also add the [DCE endpoints](../essentials/data-collection-endpoint-overview.md#components-of-a-data-collection-endpoint).

-### Proxy configuration

-If the machine connects through a proxy server to communicate over the internet, review the following requirements to understand the network configuration required.

-The Azure Monitor agent extensions for Windows and Linux can communicate either through a proxy server or a [Log Analytics gateway](./gateway.md) to Azure Monitor by using the HTTPS protocol. Use it for Azure virtual machines, Azure virtual machine scale sets, and Azure Arc for servers. Use the extensions settings for configuration as described in the following steps. Both anonymous and basic authentication by using a username and password are supported.

-> [!IMPORTANT]

-> Proxy configuration is not supported for [Azure Monitor Metrics (preview)](../essentials/metrics-custom-overview.md) as a destination. If you're sending metrics to this destination, it will use the public internet without any proxy.

-1. Use this flowchart to determine the values of the *settings* and *protectedSettings* parameters first.

- 

-1. After the values for the *settings* and *protectedSettings* parameters are determined, *provide these additional parameters* when you deploy the Azure Monitor agent by using PowerShell commands. Refer to the following examples.

-# [Windows VM](#tab/PowerShellWindows)

-```powershell

-$settingsString = '{"proxy":{"mode":"application","address":"http://[address]:[port]","auth": true}}';

-$protectedSettingsString = '{"proxy":{"username":"[username]","password": "[password]"}}';

-Set-AzVMExtension -ExtensionName AzureMonitorWindowsAgent -ExtensionType AzureMonitorWindowsAgent -Publisher Microsoft.Azure.Monitor -ResourceGroupName <resource-group-name> -VMName <virtual-machine-name> -Location <location> -TypeHandlerVersion 1.0 -SettingString $settingsString -ProtectedSettingString $protectedSettingsString

-```

-# [Linux VM](#tab/PowerShellLinux)

-```powershell

-$settingsString = '{"proxy":{"mode":"application","address":"http://[address]:[port]","auth": true}}';

-$protectedSettingsString = '{"proxy":{"username":"[username]","password": "[password]"}}';

-Set-AzVMExtension -ExtensionName AzureMonitorLinuxAgent -ExtensionType AzureMonitorLinuxAgent -Publisher Microsoft.Azure.Monitor -ResourceGroupName <resource-group-name> -VMName <virtual-machine-name> -Location <location> -TypeHandlerVersion 1.5 -SettingString $settingsString -ProtectedSettingString $protectedSettingsString

-```

-# [Windows Arc-enabled server](#tab/PowerShellWindowsArc)

-```powershell

-$settingsString = '{"proxy":{"mode":"application","address":"http://[address]:[port]","auth": true}}';

-$protectedSettingsString = '{"proxy":{"username":"[username]","password": "[password]"}}';

-New-AzConnectedMachineExtension -Name AzureMonitorWindowsAgent -ExtensionType AzureMonitorWindowsAgent -Publisher Microsoft.Azure.Monitor -ResourceGroupName <resource-group-name> -MachineName <arc-server-name> -Location <arc-server-location> -Setting $settingsString -ProtectedSetting $protectedSettingsString

-```

-# [Linux Arc-enabled server](#tab/PowerShellLinuxArc)

-```powershell

-$settingsString = '{"proxy":{"mode":"application","address":"http://[address]:[port]","auth": true}}';

-$protectedSettingsString = '{"proxy":{"username":"[username]","password": "[password]"}}';

-New-AzConnectedMachineExtension -Name AzureMonitorLinuxAgent -ExtensionType AzureMonitorLinuxAgent -Publisher Microsoft.Azure.Monitor -ResourceGroupName <resource-group-name> -MachineName <arc-server-name> -Location <arc-server-location> -Setting $settingsString -ProtectedSetting $protectedSettingsString

-```

-### Log Analytics gateway configuration

-1. Follow the preceding instructions to configure proxy settings on the agent and provide the IP address and port number that corresponds to the gateway server. If you've deployed multiple gateway servers behind a load balancer, the agent proxy configuration is the virtual IP address of the load balancer instead.

-1. Add the **configuration endpoint URL** to fetch data collection rules to the allowlist for the gateway

- `Add-OMSGatewayAllowedHost -Host global.handler.control.monitor.azure.com`

- `Add-OMSGatewayAllowedHost -Host <gateway-server-region-name>.handler.control.monitor.azure.com`.

- (If you're using private links on the agent, you must also add the [data collection endpoints](../essentials/data-collection-endpoint-overview.md#components-of-a-data-collection-endpoint).)

-1. Add the **data ingestion endpoint URL** to the allowlist for the gateway

- `Add-OMSGatewayAllowedHost -Host <log-analytics-workspace-id>.ods.opinsights.azure.com`.

-1. Restart the **OMS Gateway** service to apply the changes

- `Stop-Service -Name <gateway-name>`

- `Start-Service -Name <gateway-name>`.

-### Private link configuration

-To configure the agent to use private links for network communications with Azure Monitor, follow instructions to [enable network isolation](./azure-monitor-agent-data-collection-endpoint.md#enable-network-isolation-for-the-azure-monitor-agent) by using [data collection endpoints](azure-monitor-agent-data-collection-endpoint.md).

-## Next steps

-You can associate virtual machines to multiple data collection rules. This allows you to define each data collection rule to address a particular requirement, and associate the data collection rules to virtual machines based on the specific data you want to collect from each machine.

-In the **Monitor** menu in the Azure portal, select **Data Collection Rules** from the **Settings** section. Click **Create** to create a new Data Collection Rule and assignment.

-[](media/data-collection-rule-azure-monitor-agent/data-collection-rules-updated.png#lightbox)

-Click **Create** to create a new rule and set of associations. Provide a **Rule name** and specify a **Subscription**, **Resource Group** and **Region**. This specifies where the DCR will be created. The virtual machines and their associations can be in any subscription or resource group in the tenant.

-Additionally, choose the appropriate **Platform Type** which specifies the type of resources this rule can apply to. Custom will allow for both Windows and Linux types. This allows for pre-curated creation experiences with options scoped to the selected platform type.

-[](media/data-collection-rule-azure-monitor-agent/data-collection-rule-basics-updated.png#lightbox)

-In the **Resources** tab, add the resources (virtual machines, virtual machine scale sets, Arc for servers) that should have the Data Collection Rule applied. The Azure Monitor Agent will be installed on resources that don't already have it installed, and will enable Azure Managed Identity as well.

-> [!IMPORTANT]

-> If you need network isolation using private links for collecting data using agents from your resources, then select **Enable Data Collection Endpoints** and select a DCE for each virtual machine. See [Enable network isolation for the Azure Monitor Agent](azure-monitor-agent-data-collection-endpoint.md) for details.

-On the **Collect and deliver** tab, click **Add data source** to add a data source and destination set. Select a **Data source type**, and the corresponding details to select will be displayed. For performance counters, you can select from a predefined set of objects and their sampling rate. For events, you can select from a set of logs or facilities and the severity level.

-[](media/data-collection-rule-azure-monitor-agent/data-collection-rule-data-source-basic-updated.png#lightbox)

-To specify other logs and performance counters from the [currently supported data sources](azure-monitor-agent-overview.md#data-sources-and-destinations) or to filter events using XPath queries, select **Custom**. You can then specify an [XPath ](https://www.w3schools.com/xml/xpath_syntax.asp) for any specific values to collect. See [Sample DCR](data-collection-rule-sample-agent.md) for an example.

-[](media/data-collection-rule-azure-monitor-agent/data-collection-rule-data-source-custom-updated.png#lightbox)

-On the **Destination** tab, add one or more destinations for the data source. You can select multiple destinations of same of different types, for instance multiple Log Analytics workspaces (i.e. "multi-homing"). Windows event and Syslog data sources can only send to Azure Monitor Logs. Performance counters can send to both Azure Monitor Metrics and Azure Monitor Logs.

-[](media/data-collection-rule-azure-monitor-agent/data-collection-rule-destination.png#lightbox)

-Click **Add Data Source** and then **Review + create** to review the details of the data collection rule and association with the set of VMs. Click **Create** to create it.

-> After the data collection rule and associations have been created, it might take up to 5 minutes for data to be sent to the destinations.

-## Create rule and association in Azure portal

-You can use the Azure portal to create a data collection rule and associate virtual machines in your subscription to that rule. The Azure Monitor agent will be automatically installed and a managed identity created for any virtual machines that don't already have it installed.

-> [!IMPORTANT]

-> Creating a data collection rule using the portal also enables System-Assigned managed identity on the target resources, in addition to existing User-Assigned Identities (if any). For existing applications unless they specify the User-Assigned identity in the request, the machine will default to using System-Assigned Identity instead. [Learn More](../../active-directory/managed-identities-azure-resources/managed-identities-faq.md#what-identity-will-imds-default-to-if-dont-specify-the-identity-in-the-request)

-> [!NOTE]

-> If you wish to send data to Log Analytics, you must create the data collection rule in the **same region** where your Log Analytics workspace resides. The rule can be associated to machines in other supported region(s).

-## Limit data collection with custom XPath queries

-Since you're charged for any data collected in a Log Analytics workspace, you should collect only the data that you require. Using basic configuration in the Azure portal, you only have limited ability to filter events to collect. For Application and System logs, this is all logs with a particular severity. For Security logs, this is all audit success or all audit failure logs.

-To specify additional filters, you must use Custom configuration and specify an XPath that filters out the events you don't. XPath entries are written in the form `LogName!XPathQuery`. For example, you may want to return only events from the Application event log with an event ID of 1035. The XPathQuery for these events would be `*[System[EventID=1035]]`. Since you want to retrieve the events from the Application event log, the XPath would be `Application!*[System[EventID=1035]]`

-### Extracting XPath queries from Windows Event Viewer

-One of the ways to create XPath queries is to use Windows Event Viewer to extract XPath queries as shown below.

-* In step 5 when pasting over the 'Select Path' parameter value, you must append the log type category followed by '!' and then paste the copied value.

-[](media/data-collection-rule-azure-monitor-agent/data-collection-rule-extract-xpath.png#lightbox)

-See [XPath 1.0 limitations](/windows/win32/wes/consuming-events#xpath-10-limitations) for a list of limitations in the XPath supported by Windows event log.

-> [!TIP]

-> You can use the PowerShell cmdlet `Get-WinEvent` with the `FilterXPath` parameter to test the validity of an XPathQuery locally on your machine first. The following script shows an example.

->

-> ```powershell

-> $XPath = '*[System[EventID=1035]]'

-> Get-WinEvent -LogName 'Application' -FilterXPath $XPath

-> ```

->

-> - **In the cmdlet above, the value for '-LogName' parameter is the initial part of the XPath query until the '!', while only the rest of the XPath query goes into the $XPath parameter.**

-> - If events are returned, the query is valid.

-> - If you receive the message *No events were found that match the specified selection criteria.*, the query may be valid, but there are no matching events on the local machine.

-> - If you receive the message *The specified query is invalid* , the query syntax is invalid.

-The following table shows examples for filtering events using a custom XPath.

-| Description | XPath |

-|:|:|

-| Collect only System events with Event ID = 4648 | `System!*[System[EventID=4648]]`

-| Collect Security Log events with Event ID = 4648 and a process name of consent.exe | `Security!*[System[(EventID=4648)]] and *[EventData[Data[@Name='ProcessName']='C:\Windows\System32\consent.exe']]` |

-| Collect all Critical, Error, Warning, and Information events from the System event log except for Event ID = 6 (Driver loaded) | `System!*[System[(Level=1 or Level=2 or Level=3) and (EventID != 6)]]` |

-| Collect all success and failure Security events except for Event ID 4624 (Successful logon) | `Security!*[System[(band(Keywords,13510798882111488)) and (EventID != 4624)]]` |

-## Create rule and association using REST API

-Follow the steps below to create a data collection rule and associations using the REST API.

-> [!NOTE]

-> If you wish to send data to Log Analytics, you must create the data collection rule in the **same region** where your Log Analytics workspace resides. The rule can be associated to machines in other supported region(s).

-1. Create a DCR file using the JSON format shown in [Sample DCR](data-collection-rule-sample-agent.md).

-2. Create the rule using the [REST API](/rest/api/monitor/datacollectionrules/create#examples).

-3. Create an association for each virtual machine to the data collection rule using the [REST API](/rest/api/monitor/datacollectionruleassociations/create#examples).

-[](media/data-collection-rule-azure-monitor-agent/data-collection-rule-extract-xpath.png#lightbox)

-The Azure Log Analytics agent collects telemetry from Windows and Linux virtual machines in any cloud, on-premises machines, and machines monitored by [System Center Operations Manager](/system-center/scom/). Collected data is sent to your Log Analytics workspace in Azure Monitor.

-The Log Analytics agent also supports insights and other services in Azure Monitor, such as [VM insights](../vm/vminsights-enable-overview.md), [Microsoft Defender for Cloud](../../security-center/index.yml), and [Azure Automation](../../automation/automation-intro.md). This article provides a detailed overview of the agent, system and network requirements, and deployment methods.

-description: Create activity log alerts by using the Azure portal, an Azure Resource Manager template, and Azure PowerShell.

-# Create, view, and manage activity log alerts by using Azure Monitor

-*Activity log alerts* are the alerts that get activated when a new activity log event occurs that matches the conditions specified in the alert. You create these alerts for Azure resources by using an Azure Resource Manager template. You can also create, update, or delete these alerts in the Azure portal.

-Typically, you create activity log alerts to receive notifications when specific changes occur to resources in your Azure subscription. Alerts are often scoped to particular resource groups or resources. For example, you might want to be notified when any virtual machine in the sample resource group `myProductionResourceGroup` is deleted. Or, you might want to get notified if any new roles are assigned to a user in your subscription.

-> [!IMPORTANT]

-> You can't create alerts on service health notifications by using the interface for creating activity log alerts. To learn more about how to create and use service health notifications, see [Receive activity log alerts on service health notifications](../../service-health/alerts-activity-log-service-notifications-portal.md).

-When you create alert rules, make sure that:

-## Azure portal

-You can use the Azure portal to create and modify activity log alert rules. The experience is integrated with an Azure activity log to ensure seamless alert creation for specific events of interest. On the Azure portal, you can create a new activity log alert rule, either from the Azure Monitor alerts pane, or from the Azure Monitor activity log pane.

-### Create an alert rule from the Azure Monitor alerts pane

-Here's how to create an activity log alert rule in the Azure portal:

-1. In the [Azure portal](https://portal.azure.com), select **Monitor**. The Monitor pane consolidates all your monitoring settings and data in one view.

-2. Select **Alerts** > **+ Create** > **Alert rule**.

- > [!TIP]

- > Most resource panes also have **Alerts** in their resource menu, under **Monitoring**. You can also create alert rules from there.

-3. In the **Scope** tab, click **Select scope**. Then, in the context pane that loads, select the target resource(s) that you want to alert on. Use **Filter by subscription**, **Filter by resource type**, and **Filter by location** drop-downs to find the resource you want to monitor. You can also use the search bar to find your resource.

-

- > [!NOTE]

- > As a target, you can select an entire subscription, a resource group, or one or more a specific resources from the same subscription. If you choose a subscription or a resource group as a target, and you also select a resource type, the rule will apply to all resources of that type within the selected subscription or a resource group. If you choose a specific target resource, the rule will apply only to that resource. You can't select multiple subscriptions, or multiple resources from different subscriptions.

-4. If the selected resource has activity log operations that you can create alert rules on, you'll see that **Available signal types** lists **Activity Log**. You can view the full list of resource types supported for activity log alerts in [Azure resource provider operations](../../role-based-access-control/resource-provider-operations.md).

- :::image type="content" source="media/alerts-activity-log/select-target-new.png" alt-text="Screenshot of the target selection pane." lightbox="media/alerts-activity-log/select-target-new.png":::

-5. Once you have selected a target resource, click **Done**.

-6. Proceed to the **Condition** tab. Then, in the context pane that loads, you will see a list of signals supported for the resource, which includes those from various categories of **Activity Log**. Select the activity log signal or operation you want to create an alert rule on.

-7. You will see a chart for the activity log operation for the last six hours. Use the **Chart period** dropdown list to see a longer history for the operation.

-8. Under **Alert logic**, you can optionally define more filtering criteria:

- - **Event level**: The severity level of the event: _Verbose_, _Informational_, _Warning_, _Error_, or _Critical_.

- - **Status**: The status of the event: _Started_, _Failed_, or _Succeeded_.

- - **Event initiated by**: Also known as the caller. The email address or Azure Active Directory identifier of the user who performed the operation.

- > [!NOTE]

- > Defining at least one of these criteria helps you achieve more effective rules. For example, if the alert scope is an entire subscription, and the selected signal is `All Administrative Operations`, your rule will be more specific if you provide the event level, status, or initiation information.

- :::image type="content" source="media/alerts-activity-log/condition-selected-new.png" alt-text="Screenshot of the condition selection pane." lightbox="media/alerts-activity-log/condition-selected-new.png":::

-9. Proceed to the **Actions** tab, where you can define what actions and notifications are triggered when the alert rule generates an alert. You can add an action group to the alert rule either by selecting an existing action group or by creating a new action group.

-10. Proceed to the **Details** tab. Under **Project details**, select the resource group in which the alert rule resource will be saved. Under **Alert rule details**, specify the **Alert rule name**. You can also provide an **Alert rule description**.

- > [!NOTE]

- > The alert severity for activity log alerts can't currently be configured by the user. The severity level always defaults to **Sev4**.

-11. Proceed to the **Tags**, where you can set tags on the alert rule you're creating.

-12. Proceed to the **Review + create** tab, where you can review your selections before creating the alert rule. A quick automatic validation will also be performed, notifying you in case any information or missing or needs to be correct. Once you're ready to create the alert rule, Click **Create**.

-

-

-### Create an alert rule from the Azure Monitor activity log pane

-An alternative way to create an activity log alert is to start with an activity log event that already occurred, via the [activity log in the Azure portal](../essentials/activity-log.md#view-the-activity-log).

-1. On the **Azure Monitor - Activity log** pane, you can filter or find the desired event, and then create an alert on future similar events by selecting **Add activity log alert**.

- :::image type="content" source="media/alerts-activity-log/create-alert-rule-from-activity-log-event-new.png" alt-text="Screenshot of alert rule creation from an activity log event." lightbox="media/alerts-activity-log/create-alert-rule-from-activity-log-event-new.png":::

-2. The **Create alert rule** wizard opens, with the scope and condition already provided according to the previously selected activity log event. If necessary, you can edit and modify the scope and condition at this stage. Note that by default, the exact scope and condition for the new rule are copied from the original event attributes. For example, the exact resource on which the event occurred, and the specific user or service name who initiated the event, are both included by default in the new alert rule. If you want to make the alert rule more general, modify the scope and condition accordingly (see steps 3-9 in the section "Create an alert rule from the Azure Monitor alerts pane").

-3. Then follow steps 9-12 from the section, "Create an alert rule from the Azure Monitor alerts pane."

-

-### View and manage in the Azure portal

-1. In the Azure portal, select **Monitor** > **Alerts**. Then select **Alert rules**.

-

- The list of available alert rules appears.

-2. Filter or search for the activity log rule to modify.

- :::image type="content" source="media/alerts-activity-log/manage-alert-rules-new.png" alt-text="Screenshot of the alert rules management pane." lightbox="media/alerts-activity-log/manage-alert-rules-new.png":::

- You can use the available filters, _Subscription_, _Resource group_, _Resource_, _Signal type_, or _Status_, to find the activity rule that you want to edit.

-

-3. Select the alert rule to open it for editing. Make the required changes, and then select **Save**.

-## Azure Resource Manager template

-To create an activity log alert rule by using an Azure Resource Manager template, you create a resource of the type `microsoft.insights/activityLogAlerts`. Then you fill in all related properties. Here's a template that creates an activity log alert rule:

-```json

-{

- "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",

- "contentVersion": "1.0.0.0",

- "parameters": {

- "activityLogAlertName": {

- "type": "string",

- "metadata": {

- "description": "Unique name (within the Resource Group) for the Activity log alert."

- }

- },

- "activityLogAlertEnabled": {

- "type": "bool",

- "defaultValue": true,

- "metadata": {

- "description": "Indicates whether or not the alert is enabled."

- }

- },

- "actionGroupResourceId": {

- "type": "string",

- "metadata": {

- "description": "Resource Id for the Action group."

- }

- }

- },

- "resources": [

- {

- "type": "Microsoft.Insights/activityLogAlerts",

- "apiVersion": "2017-04-01",

- "name": "[parameters('activityLogAlertName')]",

- "location": "Global",

- "properties": {

- "enabled": "[parameters('activityLogAlertEnabled')]",

- "scopes": [

- "[subscription().id]"

- ],

- "condition": {

- "allOf": [

- {

- "field": "category",

- "equals": "Administrative"

- },

- {

- "field": "operationName",

- "equals": "Microsoft.Resources/deployments/write"

- },

- {

- "field": "resourceType",

- "equals": "Microsoft.Resources/deployments"

- }

- ]

- },

- "actions": {

- "actionGroups":

- [

- {

- "actionGroupId": "[parameters('actionGroupResourceId')]"

- }

- ]

- }

- }

- }

- ]

-}

-```

-The previous sample JSON can be saved as, for example, *sampleActivityLogAlert.json*. You can deploy the sample by using [Azure Resource Manager in the Azure portal](../../azure-resource-manager/templates/deploy-portal.md).

-> [!NOTE]

-> Notice that the highest level that activity log alerts can be defined is the subscription level. There is no option to define an alert on two subscriptions. The definition should be to alert per subscription.

-The following fields are the options that you can use in the Azure Resource Manager template for the conditions fields. (Notice that **Resource Health**, **Advisor** and **Service Health** have extra properties fields for their special fields.)

-1. `resourceId`: The resource ID of the impacted resource in the activity log event that the alert should be generated on.

-1. `category`: The category of the activity log event. For example: `Administrative`, `ServiceHealth`, `ResourceHealth`, `Autoscale`, `Security`, `Recommendation`, or `Policy`.

-1. `caller`: The email address or Azure Active Directory identifier of the user who performed the operation of the activity log event.

-1. `level`: Level of the activity in the activity log event that the alert should be generated on. For example: `Critical`, `Error`, `Warning`, `Informational`, or `Verbose`.

-1. `operationName`: The name of the operation in the activity log event. For example: `Microsoft.Resources/deployments/write`.

-1. `resourceGroup`: Name of the resource group for the impacted resource in the activity log event.

-1. `resourceProvider`: For more information, see [Azure resource providers and types](../../azure-resource-manager/management/resource-providers-and-types.md). For a list that maps resource providers to Azure services, see [Resource providers for Azure services](../../azure-resource-manager/management/resource-providers-and-types.md).

-1. `status`: String describing the status of the operation in the activity event. For example: `Started`, `In Progress`, `Succeeded`, `Failed`, `Active`, or `Resolved`.

-1. `subStatus`: Usually, this field is the HTTP status code of the corresponding REST call. But it can also include other strings describing a substatus. Examples of HTTP status codes include `OK` (HTTP Status Code: 200), `No Content` (HTTP Status Code: 204), and `Service Unavailable` (HTTP Status Code: 503), among many others.

-1. `resourceType`: The type of the resource that was affected by the event. For example: `Microsoft.Resources/deployments`.

-For example:

-```json

-"condition": {

- "allOf": [

- {

- "field": "category",

- "equals": "Administrative"

- },

- {

- "field": "resourceType",

- "equals": "Microsoft.Resources/deployments"

- }

- ]

- }

-```

-For more information about the activity log fields, see [Azure activity log event schema](../essentials/activity-log-schema.md).

-> [!NOTE]

-> It might take up to 5 minutes for the new activity log alert rule to become active.

-## REST API

-The Azure Monitor Activity Log Alerts API is a REST API. It's fully compatible with the Azure Resource Manager REST API. You can use it with PowerShell, by using the Resource Manager cmdlet or the Azure CLI.

-### Deploy the Resource Manager template with PowerShell

-To use PowerShell to deploy the sample Resource Manager template shown in the previous [Azure Resource Manager template](#azure-resource-manager-template) section, use the following command:

-```powershell

-New-AzResourceGroupDeployment -ResourceGroupName "myRG" -TemplateFile sampleActivityLogAlert.json -TemplateParameterFile sampleActivityLogAlert.parameters.json

-```

-The *sampleActivityLogAlert.parameters.json* file contains the values provided for the parameters needed for alert rule creation.

-### Use activity log PowerShell cmdlets

-Activity log alerts have dedicated PowerShell cmdlets available:

-### Azure CLI

-You can manage activity log alert rules by using dedicated Azure CLI commands under the set [az monitor activity-log alert](/cli/azure/monitor/activity-log/alert).

-To create a new activity log alert rule, use the following commands:

-1. [az monitor activity-log alert create](/cli/azure/monitor/activity-log/alert#az-monitor-activity-log-alert-create): Create a new activity log alert rule resource.

-2. [az monitor activity-log alert scope](/cli/azure/monitor/activity-log/alert/scope): Add scope for the created activity log alert rule.

-3. [az monitor activity-log alert action-group](/cli/azure/monitor/activity-log/alert/action-group): Add an action group to the activity log alert rule.

-To retrieve one activity log alert rule resource, use the Azure CLI command [az monitor activity-log alert show](/cli/azure/monitor/activity-log/alert#az-monitor-activity-log-alert-show

-). To view all activity log alert rule resources in a resource group, use [az monitor activity-log alert list](/cli/azure/monitor/activity-log/alert#az-monitor-activity-log-alert-list).

-You can remove activity log alert rule resources by using the Azure CLI command [az monitor activity-log alert delete](/cli/azure/monitor/activity-log/alert#az-monitor-activity-log-alert-delete).

-## Next steps

-# Metric Alerts with Dynamic Thresholds in Azure Monitor

-Metric Alert with Dynamic Thresholds detection leverages advanced machine learning (ML) to learn metrics' historical behavior, identify patterns and anomalies that indicate possible service issues. It provides support of both a simple UI and operations at scale by allowing users to configure alert rules through the Azure Resource Manager API, in a fully automated manner.

-Once an alert rule is created, it will fire only when the monitored metric doesnΓÇÖt behave as expected, based on its tailored thresholds.

-## Why and when is using dynamic condition type recommended?

-1. **Scalable Alerting** ΓÇô Dynamic threshold alert rules can create tailored thresholds for hundreds of metric series at a time, yet providing the same ease of defining an alert rule on a single metric. They give you fewer alerts to create and manage. You can use either Azure portal or the Azure Resource Manager API to create them. The scalable approach is especially useful when dealing with metric dimensions or when applying to multiple resources, such as to all subscription resources. [Learn more about how to configure Metric Alerts with Dynamic Thresholds using templates](./alerts-metric-create-templates.md).

-1. **Smart Metric Pattern Recognition** ΓÇô Using our ML technology, weΓÇÖre able to automatically detect metric patterns and adapt to metric changes over time, which may often include seasonality (hourly / daily / weekly). Adapting to the metricsΓÇÖ behavior over time and alerting based on deviations from its pattern relieves the burden of knowing the "right" threshold for each metric. The ML algorithm used in Dynamic Thresholds is designed to prevent noisy (low precision) or wide (low recall) thresholds that donΓÇÖt have an expected pattern.

-1. **Intuitive Configuration** ΓÇô Dynamic Thresholds allows setting up metric alerts using high-level concepts, alleviating the need to have extensive domain knowledge about the metric.

-## How to configure alerts rules with Dynamic Thresholds?

-Alerts with Dynamic Thresholds can be configured through Metric Alerts in Azure Monitor. [Learn more about how to configure Metric Alerts](alerts-metric.md).

-## What does 'Sensitivity' setting in Dynamic Thresholds mean?

-**Failing Periods** - Dynamic Thresholds also allows you to configure "Number violations to trigger the alert", a minimum number of deviations required within a certain time window for the system to raise an alert (the default time window is four deviations in 20 minutes). The user can configure failing periods and choose what to be alerted on by changing the failing periods and time window. This ability reduces alert noise generated by transient spikes. For example:

-**Ignore data before** - Users may also optionally define a start date from which the system should begin calculating the thresholds from. A typical use case may occur when a resource was a running in a testing mode and is now promoted to serve a production workload, and therefore the behavior of any metric during the testing phase should be disregarded.

-## How do you find out why a Dynamic Thresholds alert was triggered?

-### Dynamic Thresholds on virtual machine CPU percentage metrics

-1. In [Azure portal](https://portal.azure.com), click on **Monitor**. The Monitor view consolidates all your monitoring settings and data in one view.

-2. Click **Alerts** then click **+ New alert rule**.

-3. Click **Select target**, in the context pane that loads, select a target resource that you want to alert on. Use **Subscription** and **'Virtual Machines' Resource type** drop-downs to find the resource you want to monitor. You can also use the search bar to find your resource.

-4. Once you have selected a target resource, click on **Add condition**.

-6. Optionally, refine the metric by adjusting **Period** and **Aggregation**. It is discouraged to use 'Maximum' aggregation type for this metric type as it is less representative of behavior. For 'Maximum' aggregation type static threshold maybe more appropriate.

-7. You will see a chart for the metric for the last 6 hours. Define the alert parameters:

- 1. **Frequency** - Consider lowering based on business impact of the alert.

-8. The metric chart will display the calculated thresholds based on recent data.

-9. Click **Done**.

-12. Click **Done** to save the metric alert rule.

-### Dynamic Thresholds on Application Insights HTTP request execution time

-1. In [Azure portal](https://portal.azure.com), click on **Monitor**. The Monitor view consolidates all your monitoring settings and data in one view.

-2. Click **Alerts** then click **+ New alert rule**.

-3. Click **Select target**, in the context pane that loads, select a target resource that you want to alert on. Use **Subscription** and **'Application Insights' Resource type** drop-downs to find the resource you want to monitor. You can also use the search bar to find your resource.

-4. Once you have selected a target resource, click on **Add condition**.

-6. Optionally, refine the metric by adjusting **Period** and **Aggregation**. It is discouraged to use 'Maximum' aggregation type for this metric type as it is less representative of behavior. For 'Maximum' aggregation type static threshold maybe more appropriate.

-7. You will see a chart for the metric for the last 6 hours. Define the alert parameters:

-9. Click **Done**.

-12. Click **Done** to save the metric alert rule.

-## Interpreting Dynamic Threshold charts

-description: Create Azure Monitor log alert rules and manage your alert instances.

-# Create Azure Monitor log alert rules and manage alert instances

-This article shows you how to create log alert rules and manage your alert instances. Azure Monitor log alerts allow users to use a [Log Analytics](../logs/log-analytics-tutorial.md) query to evaluate resource logs at a set frequency and fire an alert based on the results. Rules can trigger one or more actions using [alert processing rules](alerts-action-rules.md) and [action groups](./action-groups.md). Learn the concepts behind log alerts [here](alerts-types.md#log-alerts).

-You create an alert rule by combining:

-And then defining these elements of the triggered alert:

-You can also [create log alert rules using Azure Resource Manager templates](../alerts/alerts-log-create-templates.md).

-## Create a new log alert rule in the Azure portal

-1. In the [portal](https://portal.azure.com/), select the relevant resource. We recommend monitoring at scale by using a subscription or resource group.

-1. In the Resource menu, select **Logs**.

-1. Write a query that will find the log events for which you want to create an alert. You can use the [alert query examples article](../logs/queries.md) to understand what you can discover or [get started on writing your own query](../logs/log-analytics-tutorial.md). Also, [learn how to create optimized alert queries](alerts-log-query.md).

-1. From the top command bar, Select **+ New Alert rule**.

- :::image type="content" source="media/alerts-log/alerts-create-new-alert-rule.png" alt-text="Create new alert rule." lightbox="media/alerts-log/alerts-create-new-alert-rule-expanded.png":::

-1. The **Condition** tab opens, populated with your log query.

-

- By default, the rule counts the number of results in the last 5 minutes.

-

- If the system detects summarized query results, the rule is automatically updated with that information.

-

- :::image type="content" source="media/alerts-log/alerts-logs-conditions-tab.png" alt-text="Conditions Tab.":::

-1. In the **Measurement** section, select values for these fields:

-

- |Field |Description |

- |||

- |Measure|Log alerts can measure two different things, which can be used for different monitoring scenarios:<br> **Table rows**: The number of rows returned can be used to work with events such as Windows event logs, syslog, application exceptions. <br>**Calculation of a numeric column**: Calculations based on any numeric column can be used to include any number of resources. For example, CPU percentage. |

- |Aggregation type| The calculation performed on multiple records to aggregate them to one numeric value using the aggregation granularity. For example: Total, Average, Minimum, or Maximum. |

- |Aggregation granularity| The interval for aggregating multiple records to one numeric value.|

-

- :::image type="content" source="media/alerts-log/alerts-log-measurements.png" alt-text="Measurements.":::

-1. (Optional) In the **Split by dimensions** section, you can create resource-centric alerts at scale for a subscription or resource group. Splitting by dimensions groups combinations of numerical or string columns to monitor for the same condition on multiple Azure resources.

- If you select more than one dimension value, each time series that results from the combination triggers its own alert and is charged separately. The alert payload includes the combination that triggered the alert.

- You can select up to six more splittings for any number or text columns types.

-

- You can also decide **not** to split when you want a condition applied to multiple resources in the scope. For example, if you want to fire an alert if at least five machines in the resource group scope have CPU usage over 80%.

- Select values for these fields:

- |Field |Description |

- |||

- |Dimension name|Dimensions can be either number or string columns. Dimensions are used to monitor specific time series and provide context to a fired alert.<br>Splitting on the Azure Resource ID column makes the specified resource into the alert target. If a Resource ID column is detected, it is selected automatically and changes the context of the fired alert to the record's resource. |

- |Operator|The operator used on the dimension name and value. |

- |Dimension values|The dimension values are based on data from the last 48 hours. Select **Add custom value** to add custom dimension values. |

- :::image type="content" source="media/alerts-log/alerts-create-log-rule-dimensions.png" alt-text="Screenshot of the splitting by dimensions section of a new log alert rule.":::

-

-1. In the **Alert logic** section, select values for these fields:

- |Field |Description |

- |||

- |Operator| The query results are transformed into a number. In this field, select the operator to use to compare the number against the threshold.|

- |Threshold value| A number value for the threshold. |

- |Frequency of evaluation|The interval in which the query is run. Can be set from a minute to a day. |

- :::image type="content" source="media/alerts-log/alerts-create-log-rule-logic.png" alt-text="Screenshot of alert logic section of a new log alert rule.":::

-1. (Optional) In the **Advanced options** section, you can specify the number of failures and the alert evaluation period required to trigger an alert. For example, if you set the **Aggregation granularity** to 5 minutes, you can specify that you only want to trigger an alert if there were three failures (15 minutes) in the last hour. This setting is defined by your application business policy.

-

- Select values for these fields under **Number of violations to trigger the alert**:

-

- |Field |Description |

- |||

- |Number of violations|The number of violations that have to occur to trigger the alert.|

- |Evaluation period|The amount of time within which those violations have to occur. |

- |Override query time range| Enter a value in this field if the alert evaluation period is different than the query time range.<br> The alert time range is limited to a maximum of two days. Even if the query contains an **ago** command with a time range of longer than 2 days, the 2 day maximum time range is applied. For example, even if the query text contains **ago(7d)**, the query only scans up to 2 days of data.<br> If the query requires more data than the alert evaluation, and there is no **ago** command in the query, you can change the time range manually.|

- :::image type="content" source="media/alerts-log/alerts-rule-preview-advanced-options.png" alt-text="Screenshot of the advanced options section of a new log alert rule.":::

-1. The **Preview** chart shows query evaluations results over time. You can change the chart period or select different time series that resulted from unique alert splitting by dimensions.

- :::image type="content" source="media/alerts-log/alerts-create-alert-rule-preview.png" alt-text="Screenshot of a preview of a new alert rule.":::

-1. From this point on, you can select the **Review + create** button at any time.

-1. In the **Actions** tab, select or create the required [action groups](./action-groups.md).

- :::image type="content" source="media/alerts-log/alerts-rule-actions-tab.png" alt-text="Actions tab.":::

-1. In the **Details** tab, define the **Project details** and the **Alert rule details**.

-1. (Optional) In the **Advanced options** section, you can set several options, including whether to **Enable upon creation**, or to **Mute actions** for a period of time after the alert rule fires.

-

- :::image type="content" source="media/alerts-log/alerts-rule-details-tab.png" alt-text="Details tab.":::

- > [!NOTE]

- > If you, or your administrator assigned the Azure Policy **Azure Log Search Alerts over Log Analytics workspaces should use customer-managed keys**, you must select **Check workspace linked storage** option in **Advanced options**, or the rule creation will fail as it will not meet the policy requirements.

-1. In the **Tags** tab, set any required tags on the alert rule resource.

- :::image type="content" source="media/alerts-log/alerts-rule-tags-tab.png" alt-text="Tags tab.":::

-1. In the **Review + create** tab, a validation will run and inform you of any issues.

-1. When validation passes and you have reviewed the settings, select the **Create** button.

-

- :::image type="content" source="media/alerts-log/alerts-rule-review-create.png" alt-text="Review and create tab.":::

-> [!NOTE]

-> This section above describes creating alert rules using the new alert rule wizard.

-> The new alert rule experience is a little different than the old experience. Please note these changes:

-> - Previously, search results were included in the payloads of the triggered alert and its associated notifications. This was a limited solution, since the email included only 10 rows from the unfiltered results while the webhook payload contained 1000 unfiltered results.

-> To get detailed context information about the alert so that you can decide on the appropriate action :

-> - We recommend using [Dimensions](alerts-unified-log.md#split-by-alert-dimensions). Dimensions provide the column value that fired the alert, giving you context for why the alert fired and how to fix the issue.

-> - When you need to investigate in the logs, use the link in the alert to the search results in Logs.

-> - If you need the raw search results or for any other advanced customizations, use Logic Apps.

-> - The new alert rule wizard does not support customization of the JSON payload.

-> - Use custom properties in the [new API](/rest/api/monitor/scheduledqueryrule-2021-08-01/scheduled-query-rules/create-or-update#actions) to add static parameters and associated values to the webhook actions triggered by the alert.

-> - For more advanced customizations, use Logic Apps.

-> - The new alert rule wizard does not support customization of the email subject.

-> - Customers often use the custom email subject to indicate the resource on which the alert fired, instead of using the Log Analytics workspace. Use the [new API](alerts-unified-log.md#split-by-alert-dimensions) to trigger an alert of the desired resource using the resource id column.

-> - For more advanced customizations, use Logic Apps.

-## Manage alert rules in the Alerts portal

-> [!NOTE]

-> This section describes how to manage alert rules created in the latest UI or using an API version later than `2018-04-16`. See [View and manage alert rules created in previous versions](alerts-manage-alerts-previous-version.md) for information about how to view and manage alert rules created in the previous UI.

-1. In the [portal](https://portal.azure.com/), select the relevant resource.

-1. Under **Monitoring**, select **Alerts**.

-1. From the top command bar, select **Alert rules**.

-1. Select the alert rule that you want to edit.

-1. Edit any fields necessary, then select **Save** on the top command bar.

-## Manage log alerts using CLI

-This section describes how to manage log alerts using the cross-platform [Azure CLI](/cli/azure/get-started-with-azure-cli). Quickest way to start using Azure CLI is through [Azure Cloud Shell](../../cloud-shell/overview.md). For this article, we'll use Cloud Shell.

-> [!NOTE]

-> Azure CLI support is only available for the scheduledQueryRules API version `2021-08-01` and later. Previous API versions can use the Azure Resource Manager CLI with templates as described below. If you use the legacy [Log Analytics Alert API](./api-alerts.md), you will need to switch to use CLI. [Learn more about switching](./alerts-log-api-switch.md).

-1. In the [portal](https://portal.azure.com/), select **Cloud Shell**.

-1. At the prompt, you can use commands with ``--help`` option to learn more about the command and how to use it. For example, the following command shows you the list of commands available for creating, viewing, and managing log alerts:

- ```azurecli

- az monitor scheduled-query --help

- ```

-1. You can create a log alert rule that monitors count of system event errors:

- ```azurecli

- az monitor scheduled-query create -g {ResourceGroup} -n {nameofthealert} --scopes {vm_id} --condition "count \'union Event, Syslog | where TimeGenerated > ago(1h) | where EventLevelName == \"Error\" or SeverityLevel== \"err\"\' > 2" --description {descriptionofthealert}

- ```

-1. You can view all the log alerts in a resource group using the following command:

- ```azurecli

- az monitor scheduled-query list -g {ResourceGroup}

- ```

-1. You can see the details of a particular log alert rule using the name or the resource ID of the rule:

- ```azurecli

- az monitor scheduled-query show -g {ResourceGroup} -n {AlertRuleName}

- ```

- ```azurecli

- az monitor scheduled-query show --ids {RuleResourceId}

- ```

-1. You can disable a log alert rule using the following command:

- ```azurecli

- az monitor scheduled-query update -g {ResourceGroup} -n {AlertRuleName} --disabled false

- ```

-1. You can delete a log alert rule using the following command:

- ```azurecli

- az monitor scheduled-query delete -g {ResourceGroup} -n {AlertRuleName}

- ```

-You can also use Azure Resource Manager CLI with [templates](./alerts-log-create-templates.md) files:

-```azurecli

-az login

-az deployment group create \

- --name AlertDeployment \

- --resource-group ResourceGroupofTargetResource \

- --template-file mylogalerttemplate.json \

- --parameters @mylogalerttemplate.parameters.json

-```

-On success for creation, 201 is returned. On success for update, 200 is returned.

-## Next steps

-* Learn about [Log alerts](alerts-types.md#log-alerts).

-* Create log alerts using [Azure Resource Manager Templates](./alerts-log-create-templates.md).

-* Understand [webhook actions for log alerts](./alerts-log-webhook.md).

-* Learn more about [log queries](../logs/log-query-overview.md).

-description: Learn how to use Azure portal or CLI to create, view, and manage metric alert rules.

-# Create, view, and manage metric alerts using Azure Monitor

-Metric alerts in Azure Monitor provide a way to get notified when one of your metrics crosses a threshold. Metric alerts work on a range of multi-dimensional platform metrics, custom metrics, Application Insights standard and custom metrics. In this article, we will describe how to create, view, and manage metric alert rules through Azure portal and Azure CLI. You can also create metric alert rules using Azure Resource Manager templates, which are described in [a separate article](./alerts-metric-create-templates.md).

-You can learn more about how metric alerts work from [metric alerts overview](./alerts-metric-overview.md).

-## Create with Azure portal

-The following procedure describes how to create a metric alert rule in Azure portal:

-1. In [Azure portal](https://portal.azure.com), click on **All Services -> Monitor**. The Monitor blade consolidates all your monitoring settings and data in one view.

-2. Click **Alerts**, then expand the **+ Create** menu and select **Alert rule**.

- > [!TIP]

- > Most resource blades also have **Alerts** in their resource menu under **Monitoring**, you could create alert rules from there as well.

-3. In the **Scope** tab, click **Select scope**. Then, in the context pane that loads, select the target resource(s) that you want to alert on. Use **Filter by subscription**, **Filter by resource type**, and **Filter by location** drop-downs to find the resourcevirtual you want to monitor. You can also use the search bar to find your resource.

-4. If the selected resource has metrics you can create alert rules on, **Available signal types** on the bottom right will include metrics. You can view the full list of resource types supported for metric alerts in this [article](./alerts-metric-near-real-time.md#metrics-and-dimensions-supported).

-5. Once you have selected a target resource, click **Done**.

-6. Proceed to the **Condition** tab. Then, in the context pane that loads, you will see a list of signals supported for the resource. Select the metric you want to create an alert on.

-7. You will see a chart showing the metric's behavior for the last six hours. Use the **Chart period** dropdown to select to see longer history for the metric.

-8. If the metric has dimensions, you will see a dimensions table presented. Optionally, select one or more values per dimension.

- - The displayed dimension values are based on metric data from the last day.

- - If the dimension value you're looking for isn't displayed, click "Add custom value" to add a custom dimension value.

- - You can also choose **Select all current and future values** for any of the dimensions. This will dynamically scale the selection to all current and future values for the dimension.

- The metric alert rule will evaluate the condition for all combinations of values selected. [Learn more about how alerting on multi-dimensional metrics works](./alerts-metric-overview.md).

-

- > [!NOTE]

- > Using "All" as a dimension value is equivalent to choosing "Select all current and future values".

-9. Select the **Threshold** type, **Operator**, and **Aggregation type**. This will determine the logic that the metric alert rule will evaluate.

- - If you are using a **Static** threshold, continue to define a **Threshold value**. The metric chart can help determine what might be a reasonable threshold.

- - If you are using a **Dynamic** threshold, continue to define the **Threshold sensitivity**. The metric chart will display the calculated thresholds based on recent data. [Learn more about Dynamic Thresholds condition type and sensitivity options](../alerts/alerts-dynamic-thresholds.md).

-10. Optionally, refine the condition by adjusting **Aggregation granularity** and **Frequency of evaluation**.

-11. Click **Done**.

-12. Optionally, add another criteria if you want to monitor a complex alert rule. Currently users can have alert rules with Dynamic Thresholds criteria as a single criterion.

-13. Proceed to the **Actions** tab, where you can define what actions and notifications are triggered when the alert rule generates an alert. You can add an action group to the alert rule either by selecting an existing action group or by creating a new action group.

-14. Proceed to the **Details** tab. Under **Project details**, select the subscription and resource group in which the alert rule resource will be saved. Under **Alert rule details**, specify the **Severity** and **Alert rule name**. You can also provide an **Alert rule description**, select if the alert rule should be enabled when created, and if it should **Automatically resolve alerts** (instructs the alert rule to maintain a state, and not fire continuously if there's already a fired alert on the same condition).

-15. Proceed to the **Tags**, where you can set tags on the alert rule you're creating.

-16. Proceed to the **Review + create** tab, where you can review your selections before creating the alert rule. A quick automatic validation will also be performed, notifying you in case any information or missing or needs to be correct. Once you're ready to create the alert rule, Click **Create**.

-## View and manage with Azure portal

-You can view and manage metric alert rules using the Manage Rules blade under Alerts. The procedure below shows you how to view your metric alert rules and edit one of them.

-1. In Azure portal, navigate to **Monitor**.

-2. Click on **Alerts**, and then on **Alert rules**.

-3. In the **Alert rules** blade, you can view all your alert rules across subscriptions. You can further filter the rules using **Resource group**, **Resource type**, and **Resource**. If you want to see only metric alerts, select **Signal type** as *Metrics*.

- > [!TIP]

- > In the **Alert rules** blade, you can select multiple alert rules and enable/disable them. This might be useful when certain target resources need to be put under maintenance.

-4. Click on the name of the metric alert rule you want to edit.

-5. In this page, you can change various settingd of the alert rule.

- > [!NOTE]

- > You can't edit the **Alert Rule Name** after the metric alert rule is created.

-6. Click **Save** to save your edits.

-## With Azure CLI

-The previous sections described how to create, view, and manage metric alert rules using Azure portal. This section will describe how to do the same using cross-platform [Azure CLI](/cli/azure/get-started-with-azure-cli). Quickest way to start using Azure CLI is through [Azure Cloud Shell](../../cloud-shell/overview.md). For this article, we will use Cloud Shell.

-1. Go to Azure portal, click on **Cloud Shell**.

-2. At the prompt, you can use commands with ``--help`` option to learn more about the command and how to use it. For example, the following command shows you the list of commands available for creating, viewing, and managing metric alerts

- ```azurecli

- az monitor metrics alert --help

- ```

-3. You can create a simple metric alert rule that monitors if average Percentage CPU on a VM is greater than 90

- ```azurecli

- az monitor metrics alert create -n {nameofthealert} -g {ResourceGroup} --scopes {VirtualMachineResourceID} --condition "avg Percentage CPU > 90" --description {descriptionofthealert}

- ```

-4. You can view all the metric alerts in a resource group using the following command

- ```azurecli

- az monitor metrics alert list -g {ResourceGroup}

- ```

-5. You can see the details of a particular metric alert rule using the name or the resource ID of the rule.

- ```azurecli

- az monitor metrics alert show -g {ResourceGroup} -n {AlertRuleName}

- ```

- ```azurecli

- az monitor metrics alert show --ids {RuleResourceId}

- ```

-6. You can disable a metric alert rule using the following command.

- ```azurecli

- az monitor metrics alert update -g {ResourceGroup} -n {AlertRuleName} --enabled false

- ```

-7. You can delete a metric alert rule using the following command.

- ```azurecli

- az monitor metrics alert delete -g {ResourceGroup} -n {AlertRuleName}

- ```

-## With PowerShell

-Metric alert rules have dedicated PowerShell cmdlets available:

-## With REST API

-## Next steps

-An **alert rule** monitors your telemetry and captures a signal that indicates that something is happening on a specified target. The alert rule captures the signal and checks to see if the signal meets the criteria of the condition. If the conditions are met, an alert is triggered, which initiates the associated action group and updates the state of the alert.

-You create an alert rule by combining:

-description: The alerts page summarizes all alert instances in all your Azure resources generated in the last 30 days.

-# View and manage your alert instances

-The alerts page summarizes all alert instances in all your Azure resources generated in the last 30 days. You can see all your different types of alerts from multiple subscriptions in a single pane, and you can find specific alert instances for troubleshooting purposes.

-You can get to the alerts page in any of the following ways:

- :::image type="content" source="media/alerts-managing-alert-instances/alerts-monitor-menu.png" alt-text="Screenshot of alerts link on monitor menu. ":::

-

- :::image type="content" source="media/alerts-managing-alert-instances/alerts-resource-menu.png" alt-text="Screenshot of alerts link on a resource's menu.":::

-## Alert rule recommendations (preview)

-> [!NOTE]

-> The alert rule recommendations feature is currently in preview and is only enabled for VMs.

-If you don't have alert rules defined for the selected resource, either individually or as part of a resource group or subscription, you can [create a new alert rule](alerts-log.md#create-a-new-log-alert-rule-in-the-azure-portal), or enable recommended out-of-the-box alert rules in the Azure portal.

-The system compiles a list of recommended alert rules based on:

-To enable recommended alert rules:

-1. On the **Alerts** page, select **Enable recommended alert rules**. The **Enable recommended alert rules** pane opens with a list of recommended alert rules based on your type of resource.

-1. In the **Alert me if** section, select all of the rules you want to enable. The rules are populated with the default values for the rule condition, such as the percentage of CPU usage that you want to trigger an alert. You can change the default values if you would like.

-1. In the **Notify me by** section, select the way you want to be notified if an alert is fired.

-1. Select **Enable**.

-## The alerts summary pane

-If you have alerts configured for this resource, the alerts summary pane summarizes the alerts fired in the last 24 hours. You can modify the list of alert instances by selecting filters such as **time range**, **subscription**, **alert condition**, **severity**, and more. Select an alert instance.

-To see more details about a specific alert instance, select the alerts instance to open the **Alert Details** page.

-> [!NOTE]

-> If you navigated to the alerts page by selecting a specific alert severity, the list is pre-filtered for that severity.

-

-## The alerts details page

- The **Alerts details** page provides details about the selected alert. Select **Change user response** to change the user response to the alert. You can see all closed alerts in the **History** tab.

-## Next steps

-Dimensions are name-value pairs that contain additional data about the metric value. Using dimensions allows you to filter the metrics and monitor specific time-series, instead of monitoring the aggregate of all the dimensional values.

-For example, the Transactions metric of a storage account can have an API name dimension that contains the name of the API called by each transaction (for example, GetBlob, DeleteBlob, PutPage). You can choose to have an alert fired when there is a high number of transactions in any API name (which is the aggregated data), or you can use dimensions to further break it down to alert only when the number of transactions is high for specific API names.

-A log alert rule monitors a resource by using a Log Analytics query to evaluate resource logs at a set frequency. If the conditions are met, an alert is fired. Because you can use Log Analytics queries, log alerts allow you to perform advanced logic operations on your data and to use the robust features of KQL for data manipulation of log data.

-As data comes into Application Insights from your web app, Smart Detection compares the current behavior with the patterns seen over the past few days. If there is an abnormal rise in failure rate compared to previous performance, an analysis is triggered. To help you triage and diagnose the problem, an analysis of the characteristics of the failures and related application data is provided in the alert details. There are also links to the Application Insights portal for further diagnosis. The feature needs no set-up nor configuration, as it uses machine learning algorithms to predict the normal failure rate.

-Smart detection works for any web app, hosted in the cloud or on your own servers, that generate application request or dependency data.

-> The Azure Application Insights connector has been replaced with the [Azure Monitor connector](../logs/logicapp-flow-connector.md) that is integrated with Azure Active Directory instead of requiring an API key and also allows you to retrieve data from a Log Analytics workspace.

-You can add additional actions as well. The Logic Apps feature of Azure App Service makes hundreds of actions available. For example, by using a logic app, you can automatically send an email notification or create a bug in Azure DevOps. You can also use one of the many available [templates](../../logic-apps/logic-apps-create-logic-apps-from-templates.md) to help speed up the process of creating your logic app.

-1. Click **Create a resource**, select **Web + Mobile**, and then select **Logic App**.

- 

-1. In the **Logic App Designer** window, under **Start with a common trigger**, select **Recurrence**.

- 

- 

-1. Click **New step**.

-1. Under **Actions**, click **Azure Application Insights - Visualize Analytics query**.

- 

-To complete this step, you need an application ID and an API key for your resource. You can retrieve them from the Azure portal, as shown in the following diagram:

-

-

-Provide a name for your connection, the application ID, and the API key.

-

-When you create your own queries, verify that they are working properly in Analytics before you add it to your flow.

- 

-1. Click **New step**.

-1. Click **Office 365 Outlook - Send an email**.

- 

-1. In the **Send an email** window, do the following:

- c. Click anywhere in the **Body** box and then, on the dynamic content menu that opens at the right, select **Body**.

- d. Click the **Add new parameter** drop down and select Attachments and Is HTML.

- 

- 

-1. On the dynamic content menu, do the following:

- 

-* Click **Save** to save your changes.

-You can wait for the trigger to run the logic app, or you can run the logic app immediately by selecting **Run**.

-

-When your logic app runs, the recipients you specified in the email list will receive an email that looks like the following:

-

-<!--Link references-->

-By using Azure Monitor, you can collect custom metrics via your application telemetry, an agent running on your Azure resources, or even outside-in monitoring systems. Then you can submit them directly to Azure Monitor. This article provides instructions on how to deploy the [InfluxData](https://www.influxdata.com/) Telegraf agent on a Linux VM in Azure and configure the agent to publish metrics to Azure Monitor.

- > You cannot use [Log Analytics agent](../agents/agents-overview.md#log-analytics-agent) (also referred to as the Microsoft Monitoring Agent, or "MMA") to send **Guest (classic)** into a storage account.

-[Azure Logic Apps](../../logic-apps/index.yml) and [Power Automate](https://flow.microsoft.com) allow you to create automated workflows using hundreds of actions for a variety of services. The Azure Monitor Logs connector allows you to build workflows that retrieve data from a Log Analytics workspace or an Application Insights application in Azure Monitor. This article describes the actions included with the connector and provides a walkthrough to build a workflow using this data.

-* Max query response size: ~16.7 MB (16 MiB). The connector infrastructure dictates that size limit is set lower than query API limit

-* Max number of records: 500,000

-* Max connector timeout: 110 second

-* Max query timeout: 100 second

-* Visualization in Logs page and the connector are using different charting libraries and some functionality isn't available in the connector currently

-| [Run query and and visualize results](/connectors/azuremonitorlogs/#run-query-and-visualize-results) | Returns all rows in the result set as a single formatted object. Use this action when you want to use the result set together in the rest of the workflow, such as sending the results in a mail. |

-The following tutorials illustrate the use of the Azure Monitor connectors in Azure Logic Apps. You can perform these same example with Power Automate, the only difference being how to you create the initial workflow and run it when complete. Configuration of the workflow and actions is the same between both. See [Create a flow from a template in Power Automate](/power-automate/get-started-logic-template) to get started.

-Go to **Logic Apps** in the Azure portal and click **Add**. Select a **Subscription**, **Resource group**, and **Region** to store the new logic app and then give it a unique name. You can turn on **Log Analytics** setting to collect information about runtime data and events as described in [Set up Azure Monitor logs and collect diagnostics data for Azure Logic Apps](../../logic-apps/monitor-logic-apps-log-analytics.md). This setting isn't required for using the Azure Monitor Logs connector.

-

-Click **Review + create** and then **Create**. When the deployment is complete, click **Go to resource** to open the **Logic Apps Designer**.

-Under **Start with a common trigger**, select **Recurrence**. This creates a logic app that automatically runs at a regular interval. In the **Frequency** box of the action, select **Day** and in the **Interval** box, enter **1** to run the workflow once per day.

-

-The following tutorial shows you how to create a logic app that sends the results of an Azure Monitor log query by email.

-Click **+ New step** to add an action that runs after the recurrence action. Under **Choose an action**, type **azure monitor** and then select **Azure Monitor Logs**.

-

-Click **Azure Log Analytics ΓÇô Run query and visualize results**.

-

-Select the **Subscription** and **Resource Group** for your Log Analytics workspace. Select *Log Analytics Workspace* for the **Resource Type** and then select the workspace's name under **Resource Name**.

-Add the following log query to the **Query** window.

-```Kusto

-Event

-| where EventLevelName == "Error"

-| where TimeGenerated > ago(1day)

-| summarize TotalErrors=count() by Computer

-| sort by Computer asc

-```

-Select *Set in query* for the **Time Range** and **HTML Table** for the **Chart Type**.

-

-The mail will be sent by the account associated with the current connection. You can specify another account by clicking on **Change connection**.

-Click **+ New step**, and then click **+ Add an action**. Under **Choose an action**, type **outlook** and then select **Office 365 Outlook**.

-

-Select **Send an email (V2)**.

-

-Click anywhere in the **Body** box to open a **Dynamic content** window opens with values from the previous actions in the logic app. Select **See more** and then **Body** which is the results of the query in the Log Analytics action.

-

-Specify the email address of a recipient in the **To** window and a subject for the email in **Subject**.

-

-Click **Save** and then **Run** to perform a test run of the logic app.

-

-When the logic app completes, check the mail of the recipient that you specified. You should have received a mail with a body similar to the following:

-

-If you're unfamiliar with the process for creating alert rules in Azure Monitor, see the following articles for guidance:

- 1. (Optional) In the **Advanced options** section, set the [Number of violations to trigger alert](../alerts/alerts-unified-log.md#number-of-violations-to-trigger-alert).

- :::image type="content" source="../alerts/media/alerts-log/alerts-rule-preview-advanced-options.png" alt-text="Screenshot of alerts rule preview advanced options.":::

- :::image type="content" source="../alerts/media/alerts-log/alerts-create-alert-rule-preview.png" alt-text="Screenshot of alerts rule preview.":::

- :::image type="content" source="../alerts/media/alerts-log/alerts-rule-actions-tab.png" alt-text="Screenshot of alerts rule preview actions tab.":::

- 1. (Optional) In the **Advanced options** section, you can set several options, including whether to **Enable upon creation**, or to [**mute actions**](../alerts/alerts-unified-log.md#state-and-resolving-alerts) for a period after the alert rule fires.

- :::image type="content" source="../alerts/media/alerts-log/alerts-rule-details-tab.png" alt-text="Screenshot of alerts rule preview details tab.":::

- :::image type="content" source="../alerts/media/alerts-log/alerts-rule-tags-tab.png" alt-text="Screenshot of alerts rule preview tags tab.":::

- :::image type="content" source="../alerts/media/alerts-log/alerts-rule-review-create.png" alt-text="Screenshot of alerts rule preview review and create tab.":::

-## Azure CLI task

-The Azure CLI task takes the following inputs:

-* `azureSubscription`, provide the name of the service connection that you created. See [Prerequisites](#prerequisites).

-* `scriptType`, use **bash**.

-* `scriptLocation`, use **inlineScript**, or **scriptPath**. If you specify **scriptPath**, you'll also need to specify a `scriptPath` parameter.

-* `inlineScript`, specify your script lines. The script provided in the sample deploys a Bicep file called *main.bicep*.

-description: Describes the concepts for Azure Managed Applications, which provides cloud solutions that are easy for consumers to deploy and operate.

-# Azure managed applications overview

-Azure managed applications enable you to offer cloud solutions that are easy for consumers to deploy and operate. You implement the infrastructure and provide ongoing support. To make a managed application available to all customers, publish it in the Azure marketplace. To make it available to only users in your organization, publish it to an internal catalog.

-A managed application is similar to a solution template in the Marketplace, with one key difference. In a managed application, the resources are deployed to a resource group that's managed by the publisher of the app. The resource group is present in the consumer's subscription, but an identity in the publisher's tenant has access to the resource group. As the publisher, you specify the cost for ongoing support of the solution.

-> Formerly, the documentation for Azure Custom Providers was included with the documentation for Managed Applications. That documentation has been moved. Now, see [Azure Custom Providers](../custom-providers/overview.md).

-Managed applications reduce barriers to consumers using your solutions. They don't need expertise in cloud infrastructure to use your solution. Consumers have limited access to the critical resources, don't need to worry about making a mistake when managing it.

-Managed applications enable you to establish an ongoing relationship with your consumers. You define terms for managing the application, and all charges are handled through Azure billing.

-Although customers deploy these managed applications in their subscriptions, they don't have to maintain, update, or service them. You can make sure that all customers are using approved versions. Customers don't have to develop application-specific domain knowledge to manage these applications. Customers automatically acquire application updates without the need to worry about troubleshooting and diagnosing issues with the applications.

-You can publish your managed application either externally or internally.

-

-The service catalog is an internal catalog of approved solutions for users in an organization. You use the catalog to meet organizational standards while they offering solutions for the organizations. Employees use the catalog to easily find applications that are recommended and approved by their IT departments. They see the managed applications that other people in their organization share with them.

-For information about publishing a Service Catalog managed application, see [Create service catalog application](publish-service-catalog-app.md).

-### Marketplace

-Vendors wishing to bill for their services can make a managed application available through the Azure marketplace. After the vendor publishes an application, it's available to users outside the organization. With this approach, managed service providers (MSPs), independent software vendors (ISVs), and system integrators (SIs) can offer their solutions to all Azure customers.

-For information about publishing a managed application to the Marketplace, see [Create marketplace application](../../marketplace/azure-app-offer-setup.md).

-Typically, the resources for a managed application are in two resource groups. The consumer manages one resource group, and the publisher manages the other resource group. When defining the managed application, the publisher specifies the levels of access. The publisher can request either a permanent role assignment, or [just-in-time access](request-just-in-time-access.md) for an assignment that is constrained to a time period.

-

-This resource group holds the managed application instance. This resource group may only contain one resource. The resource type of the managed application is **Microsoft.Solutions/applications**.

-When publishing the [managed application to the marketplace](../../marketplace/azure-app-offer-setup.md), the publisher can grant consumers the ability to perform specific actions on resources in the managed resource group. For example, the publisher can specify that consumers can restart virtual machines. All other actions beyond read actions are still denied. Changes to resources in a managed resource group by a consumer with granted actions are subject to the [Azure Policy](../../governance/policy/overview.md) assignments within the consumers tenant scoped to include the managed resource group.

-> [Quickstart: Publish an Azure managed application definition](publish-service-catalog-app.md)

-# Use portal to create private link for managing Azure resources (preview)

-Http request logs provide detailed information for the http requests received by Azure Web PubSub. For example, status code and URL of the request. Http request log is helpful to troubleshoot request-related issues.

-The tracing ID will be generated in SignalR service once the message arrives at SignalR service in **Path 1**. SignalR service will generate a log `Received a message <MessageTracingId> from client connection <ConnectionId>.` for each message in diagnostic client. Once the message leaves from the SignalR to server, SignalR service will generate a log message `Sent a message <MessageTracingId> to server connection <ConnectionId> successfully.` If you see these two logs, you can be sure that the message passes through SignalR service successfully.

-Once the message invokes the hub method in server, a new service message will be generated with a *new tracing ID*. Once the service message is generated, server will generate a sign in template `Start to broadcast/send message <MessageTracingId> ...`, the actual log will be based on your scenario. Then the message will be delivered to SignalR service in **Path 3**, once the service message leaves from server, a log called `Succeeded to send message <MessageTracingId>` will be generated.

-Azure SignalR Service is an Azure service that helps developers easily build web applications with real-time features. This service was originally based on [SignalR for ASP.NET Core 2.1](/aspnet/core/signalr/introduction?preserve-view=true&view=aspnetcore-2.1), but now supports later versions.

-This article shows you how to get started with the Azure SignalR Service. In this quickstart, you'll create a chat application by using an ASP.NET Core MVC web app. This app will make a connection with your Azure SignalR Service resource to enable real-time content updates. You'll host the web application locally and connect with multiple browser clients. Each client will be able to push content updates to all other clients.

-The code for this tutorial is available for download in the [AzureSignalR-samples GitHub repository](https://github.com/aspnet/AzureSignalR-samples/tree/master/samples/ChatRoom). Also, you can create the Azure resources used in this quickstart by following [Create a SignalR Service script](scripts/signalr-cli-create-service.md).

-Having issues? Try the [troubleshooting guide](signalr-howto-troubleshoot-guide.md) or [let us know](https://aka.ms/asrs/qsnetcore).

-Having issues? Try the [troubleshooting guide](signalr-howto-troubleshoot-guide.md) or [let us know](https://aka.ms/asrs/qsnetcore).

-1. Open your *.csproj* file. Add a `DotNetCliToolReference` element to include *Microsoft.Extensions.SecretManager.Tools*. Also add a `UserSecretsId` element as shown in the following code for *chattest.csproj*, and save the file.

-Having issues? Try the [troubleshooting guide](signalr-howto-troubleshoot-guide.md) or [let us know](https://aka.ms/asrs/qsnetcore).

-3. Add a secret named *Azure:SignalR:ConnectionString* to Secret Manager.

- You must run this command in the same directory as the *.csproj* file.

- By not passing a parameter to `AddAzureSignalR()`, this code uses the default configuration key for the SignalR Service resource connection string. The default configuration key is *Azure:SignalR:ConnectionString*.

-In SignalR, a hub is a core component that exposes a set of methods that can be called from the client. In this section, you define a hub class with two methods:

-Here's the main code of *https://docsupdatetracker.net/index.html*:

-Create a new file in the *wwwroot* directory named *https://docsupdatetracker.net/index.html*, copy, and paste the following HTML into the newly created file:

-Having issues? Try the [troubleshooting guide](signalr-howto-troubleshoot-guide.md) or [let us know](https://aka.ms/asrs/qsnetcore).

-Having issues? Try the [troubleshooting guide](signalr-howto-troubleshoot-guide.md) or [let us know](https://aka.ms/asrs/qsnetcore).

-> Deleting a resource group is irreversible and includes all the resources in that group. Make sure that you don't accidentally delete the wrong resource group or resources. If you created the resources for hosting this sample in an existing resource group that contains resources you want to keep, you can delete each resource individually from its blade instead of deleting the resource group.

-In this article you'll learn how to access the HCX over a Public IP address using Azure VMware Solution. You'll also learn how to pair HCX sites, and create service mesh from on-premises to Azure VMware Solutions private cloud using Public IP. The service mesh allows you to migrate a workload from an on-premises datacenter to Azure VMware Solutions private cloud over the public internet. This solution is useful where the customer isn't using Express Route or VPN connectivity with the Azure cloud.

-> The on-premises HCX appliance should be reachable from the internet to establish HCX communication from on-premises to Azure VMware Solution private cloud.

-Configure a Public IP block through portal by using the Public IP feature of the Azure VMware Solution private cloud.

-1. Browse the NSX-T Manger, paste the admin password in the password field, and select **Login**.

-1. Under the **Networking** section, select **Connectivity** and **Segments**, and then select **ADD SEGMENT**.

-1. Provide Segment name, select Tier-1 router as connected gateway, and provide the public segment under subnets.

-1. Sign in to NSX-T manager and select **Networking**.

-

-1. Sign in to NSX-T Manager and select **Networking**.

-1. Create T1 Gateway Firewall rules to allow only expected traffic to the Public IP for HCX Manager and drop everything else.

-If you find that you can't establish client connections to Azure Web PubSub service, check your resource logs. If you see `Connection count reaches limit` in the resource log, you established too many connections to Azure Web PubSub service and reached the connection count limit. Consider scaling up your Azure Web PubSub service instance. If you see `Message count reaches limit` in the resource log and you're using the Free tier, it means you used up the quota of messages. If you want to send more messages, consider changing your Azure Web PubSub service instance to Standard tier. For more information, see [Azure Web PubSub service Pricing](https://azure.microsoft.com/pricing/details/web-pubsub/).

-You can use [Azure Data Box](../databox/data-box-overview.md) to seed your large initial DPM/MABS backups offline (without using the network) to a Recovery Services vault. This process saves time and network bandwidth that would otherwise be consumed moving large amounts of backup data online over a high-latency network. This feature is currently in preview.

- >[!NOTE]

- > The option to select **Transfer using Microsoft Owned disks** isn't available for MABS v3 since the feature is in preview. Reach out to us at [systemcenterfeedback@microsoft.com](mailto:systemcenterfeedback@microsoft.com) if you want to use this feature for MABS v3.

-## <a name="prereq"></a>Prerequisites

-## <a name="vnet"></a>Update VNet DNS servers

- :::image type="content" source="./media/kerberos-authentication-portal/dns-servers.png" alt-text="Screenshot of DNS servers page." lightbox="./media/kerberos-authentication-portal/dns-servers.png":::

-## <a name="deploy"></a>Deploy Bastion

-In this section, the following steps help you deploy Bastion to your virtual network.

-1. Deploy Bastion to your VNet using the steps in [Tutorial: Deploy Bastion using manual configuration settings](tutorial-create-host-portal.md). Configure the settings on the **Basics** tab. Then, select the **Advanced** tab.

-1. On the **Advanced** tab, select **Kerberos**. Then select the **Review + create** and **Create** to deploy Bastion to your virtual network.

- :::image type="content" source="./media/kerberos-authentication-portal/select-kerberos.png" alt-text="Screenshot of Advanced tab." lightbox="./media/kerberos-authentication-portal/select-kerberos.png":::

-## <a name="modify"></a>To modify an existing Bastion deployment

-1. [Update the DNS settings](#vnet) for your virtual network.

-## <a name="verify"></a>To verify Bastion is using Kerberos

-description: Learn how to deploy Bastion using manual settings using the Azure portal.

-# Tutorial: Deploy Bastion using manual settings

-This tutorial helps you deploy Azure Bastion from the Azure portal using manual settings. When you use manual settings, you can specify configuration values such as instance counts and the SKU at the time of deployment. After Bastion is deployed, you can connect (SSH/RDP) to virtual machines in the virtual network via Bastion using the private IP address of the VM. When you connect to a VM, it doesn't need a public IP address, client software, agent, or a special configuration.

-1. Go to your VNet.

-1. Select **Bastion** in the left pane to open the **Bastion** page.

-1. On the Bastion page, select **Configure manually**. This lets you configure specific additional settings before deploying Bastion to your VNet.

- :::image type="content" source="./media/tutorial-create-host-portal/configure-manually.png" alt-text="Screenshot of Bastion page showing configure manually button." lightbox="./media/tutorial-create-host-portal/configure-manually.png":::

-1. The public IP address section is where you configure the public IP address of the Bastion host resource on which RDP/SSH will be accessed (over port 443). The public IP address must be in the same region as the Bastion resource you're creating. This IP address doesn't have anything to do with any of the VMs that you want to connect to. Create a new IP address. You can leave the default naming suggestion.

-> If you have existing private endpoints created with previous private DNS zone `privatelink.<region>.batch.azure.com`, please follow [Migration with existing Batch account private endpoints](#migration-with-existing-batch-account-private-endpoints).

-> [!NOTE]

-> If [public network access](public-network-access.md) is disabled with Batch account, performing account operations (for example pools, jobs) outside of the virtual network where the private endpoint is provisioned will result in an "AuthorizationFailure" message for Batch account in the Azure Portal.

-With the introduction of the new private endpoint sub-resource `nodeManagement` for Batch node management endpoint, the default private DNS zone for Batch account is simplified from `privatelink.<region>.batch.azure.com` to `privatelink.batch.azure.com`. The existing private endpoints for sub-resource `batchAccount` will continue to work, and no action is needed.

-However, if you have existing `batchAccount` private endpoints that are enabled with automatic private DNS integration using previous private DNS zone, extra configuration is needed for the new `batchAccount` private endpoint to create in the same virtual network:

-> This manual mitigation is only needed when you create a new **batchAccount** private endpoint with private DNS integration in the same virtual network which has existing private endpoints.

- - Use `nodeManagement` [private endpoint with Batch accounts](private-connectivity.md). This is the preferred method.

-1. Select a virtual network and subnet you wish to use. This virtual network must be in the same location as the pool you are creating.

-Custom Neural Voice is a text-to-speech feature that lets you create a one-of-a-kind, customized, synthetic voice for your applications. With Custom Neural Voice, you can build a highly natural-sounding voice by providing your audio samples as training data.

-> [!NOTE]

-Speech Studio provides two Custom Neural Voice (CNV) project types: CNV Pro and CNV Lite.

-The following table summarizes key differences between the CNV Pro and CNV Lite project types.

-> [Get started with Custom Neural Voice](how-to-custom-voice.md)

-## Prerequisites

-* [Create a custom voice project](how-to-custom-voice.md)

-* [Prepare training data](how-to-custom-voice-prepare-data.md)

-

-> [!NOTE]

-> Custom Neural Voice is available with limited access. Make sure you understand the [responsible AI requirements](/legal/cognitive-services/speech-service/custom-neural-voice/limited-access-custom-neural-voice?context=%2fazure%2fcognitive-services%2fspeech-service%2fcontext%2fcontext), and then [apply for access](https://aka.ms/customneural).

-1. Next, to define voice characteristics, select **Target scenario**. Then describe your **Voice characteristics**.

- >[!NOTE]

- >The scenarios you provide must be consistent with what you've applied for in the application form.

-1. Then, go to **Upload voice talent statement**, and follow the instruction to upload the voice talent statement you've prepared beforehand.

- >[!NOTE]

- >Make sure the verbal statement is recorded in the same settings as your training data, including the recording environment and speaking style.

->- If you've created data files in the previous version of Speech Studio, you must specify a training set for your data in advance to use them. If you haven't, an exclamation mark is appended to the data name, and the data can't be used.

-> - The maximum number of data files allowed to be imported per subscription is 500 .zip files for standard subscription (S0) users.

- >- To train a neural voice, you must specify a voice talent profile. This profile must provide the audio consent file of the voice talent, acknowledging to use his or her speech data to train a custom neural voice model. Custom Neural Voice is available with limited access. Make sure you understand the [responsible AI requirements](/legal/cognitive-services/speech-service/custom-neural-voice/limited-access-custom-neural-voice?context=%2fazure%2fcognitive-services%2fspeech-service%2fcontext%2fcontext) and [apply the access](https://aka.ms/customneural).

- > [!NOTE]

- > Duplicate audio names will be removed from the training. Make sure the data you select don't contain the same audio names across multiple .zip files.

-> See [Custom Neural Voice project types](custom-neural-voice.md#custom-neural-voice-project-types) for information about capabilities, requirements, and differences between Custom Neural Voice Pro and Custom Neural Voice Lite projects. This article focuses on the creation of a professional Custom Neural Voice using the Pro project.

-Before you can train your own Text-to-Speech voice model, you'll need audio recordings and the associated text transcriptions. On this page, we'll review data types, how they're used, and how to manage each.

-

-In some cases, you may not have the right dataset ready and will want to test the custom neural voice training with available audio files, short or long, with or without transcripts. We provide tools (beta) to help you segment your audio into utterances and prepare transcripts using the [Batch Transcription API](batch-transcription.md).

-| | -- | -- | |

-You can prepare recordings of individual utterances and the matching transcript in two ways. Either write a script and have it read by a voice talent or use publicly available audio and transcribe it to text. If you do the latter, edit disfluencies from the audio files, such as "um" and other filler sounds, stutters, mumbled words, or mispronunciations.

-## Long audio + transcript (beta)

-# Get started with Custom Neural Voice

-> [!NOTE]

-> Custom Neural Voice Pro can be used to create higher-quality models that are indistinguishable from human recordings. For access you must commit to using it in alignment with our responsible AI principles. Learn more about our [policy on the limited access](/legal/cognitive-services/speech-service/custom-neural-voice/limited-access-custom-neural-voice?context=%2fazure%2fcognitive-services%2fspeech-service%2fcontext%2fcontext) and [apply here](https://aka.ms/customneural).

-> [!NOTE]

- See [Custom Neural Voice project types](custom-neural-voice.md#custom-neural-voice-project-types) for information about capabilities, requirements, and differences between Custom Neural Voice Pro and Custom Neural Voice Lite projects.

-1. After you've created a CNV Pro project, you'll see four tabs: **Set up voice talent**, **Prepare training data**, **Train model**, and **Deploy model**. See [Prepare data for Custom Neural Voice](how-to-custom-voice-prepare-data.md) to set up the voice talent, and proceed to training data.

-## Tips for creating a professional custom neural voice

-Creating a great custom neural voice requires careful quality control in each step, from voice design and data preparation, to the deployment of the voice model to your system. The following sections discuss some key steps to take when you're creating a custom neural voice for your organization.

-### Persona design

-First, design a persona of the voice that represents your brand by using a persona brief document. This document defines elements such as the features of the voice, and the character behind the voice. This helps to guide the process of creating a custom neural voice model, including defining the scripts, selecting your voice talent, training, and voice tuning.

-### Script selection

-

-Carefully select the recording script to represent the user scenarios for your voice. For example, you can use the phrases from bot conversations as your recording script if you're creating a customer service bot. Include different sentence types in your scripts, including statements, questions, and exclamations.

-### Preparing training data

-It's a good idea to capture the audio recordings in a professional quality recording studio to achieve a high signal-to-noise ratio. The quality of the voice model depends heavily on your training data. Consistent volume, speaking rate, pitch, and consistency in expressive mannerisms of speech are required.

-After the recordings are ready, follow [Prepare training data](how-to-custom-voice-prepare-data.md) to prepare the training data in the right format.

-### Training

-After you've prepared the training data, go to [Speech Studio](https://aka.ms/speechstudio/customvoice) to create your custom neural voice. Select at least 300 utterances to create a custom neural voice. A series of data quality checks are automatically performed when you upload them. To build high-quality voice models, you should fix any errors and submit again.

-### Testing

-Prepare test scripts for your voice model that cover the different use cases for your apps. ItΓÇÖs a good idea to use scripts within and outside the training dataset, so you can test the quality more broadly for different content.

-### Tuning and adjustment

-The style and the characteristics of the trained voice model depend on the style and the quality of the recordings from the voice talent used for training. However, you can make several adjustments by using [SSML (Speech Synthesis Markup Language)](./speech-synthesis-markup.md?tabs=csharp) when you make the API calls to your voice model to generate synthetic speech.

-SSML is the markup language used to communicate with the text-to-speech service to convert text into audio. The adjustments you can make include change of pitch, rate, intonation, and pronunciation correction. If the voice model is built with multiple styles, you can also use SSML to switch the styles.

-# Get facial pose events for lip-sync

-> At this time, viseme events are available only for [neural voices](language-support.md#text-to-speech).

-A _viseme_ is the visual description of a phoneme in spoken language. It defines the position of the face and mouth when a person speaks a word. Each viseme depicts the key facial poses for a specific set of phonemes.

-You can use visemes to control the movement of 2D and 3D avatar models, so that the mouth movements are perfectly matched to synthetic speech. For example, you can:

-## Azure Neural TTS can produce visemes with speech

-Neural Text-to-SpeechΓÇ»(Neural TTS) turns input text or SSML (Speech Synthesis Markup Language) into lifelike synthesized speech. Speech audio output can be accompanied by viseme IDs and their offset timestamps. Each viseme ID specifies a specific pose in observed speech, such as the position of the lips, jaw, and tongue when producing a particular phoneme. Using a 2D or 3D rendering engine, you can use these viseme events to animate your avatar.

-*Viseme ID* and *audio offset output* are described in the following table:

-| Visme&nbsp;element | Description |

-|--|-|

-| Viseme ID | An integer number that specifies a viseme.<br>For English (US), we offer 22 different visemes, each depicting the mouth shape for a specific set of phonemes. There is no one-to-one correspondence between visemes and phonemes. Often, several phonemes correspond to a single viseme, because they look the same on the speaker's face when they're produced, such as `s` and `z`. For more specific information, see the table for [mapping phonemes to viseme IDs](#map-phonemes-to-visemes). |

-| Audio offset | The start time of each viseme, in ticks (100 nanoseconds). |

- var result = await synthesizer.SpeakSsmlAsync(ssml));

-speech_synthesizer.viseme_received.connect(lambda evt: print(

- "Viseme event received: audio offset: {}ms, viseme id: {}.".format(evt.audio_offset / 10000, evt.viseme_id)))

-Here is an example of the viseme output.

-After you obtain the viseme output, you can use these events to drive character animation. You can build your own characters and automatically animate them.

-For 2D characters, you can design a character that suits your scenario and use Scalable Vector Graphics (SVG) for each viseme ID to get a time-based face position. With temporal tags that are provided in a viseme event, these well-designed SVGs will be processed with smoothing modifications, and provide robust animation to the users. For example, the following illustration shows a red-lipped character that's designed for language learning.

-

-For 3D characters, think of the characters as string puppets. The puppet master pulls the strings from one state to another and the laws of physics do the rest and drive the puppet to move fluidly. The viseme output acts as a puppet master to provide an action timeline. The animation engine defines the physical laws of action. By interpolating frames with easing algorithms, the engine can further generate high-quality animations.

-## Map phonemes to visemes

-Visemes vary by language and locale. Each locale has a set of visemes that correspond to its specific phonemes. The [SSML phonetic alphabets](speech-ssml-phonetic-sets.md) documentation maps viseme IDs to the corresponding International Phonetic Alphabet (IPA) phonemes.

-> [!div class="nextstepaction"]

-> [SSML phonetic alphabets](speech-ssml-phonetic-sets.md)

-|zh-CN-YunxiaNeural ^{Public preview}|`angry`, `calm`, `cheerful`, `fearful`, `narration-relaxed`, `sad`|Supported||

-# Record voice samples to create a professional custom neural voice

-An individual may fill more than one role. This guide assumes that you'll be primarily filling the director role and hiring both a voice talent and a recording engineer. If you want to make the recordings yourself, this article includes some information about the recording engineer role. The editor role isn't needed until after the session, so can be performed by the director or the recording engineer.

-Actors with experience in voiceover or voice character work make good custom neural voice talent. You can also often find suitable talent among announcers and newsreaders. Choose voice talent whose natural voice you like. It's possible to create unique "character" voices, but it's much harder for most talent to perform them consistently, and the effort can cause voice strain. The single most important factor for choosing voice talent is consistency. Your recordings for the same voice style should all sound like they were made on the same day in the same room. You can approach this ideal through good recording practices and engineering.

-Your voice talent is the other half of the equation. They must be able to speak with consistent rate, volume level, pitch, and tone. Clear diction is a must. The talent also needs to be able to strictly control their pitch variation, emotional affect, and speech mannerisms. Recording voice samples can be more fatiguing than other kinds of voice work. Most voice talent can record for two or three hours a day. Limit sessions to three or four a week, with a day off in-between if possible.

-Work with your voice talent to develop a "persona" that defines the overall sound and emotional tone of the custom neural voice. In the process, you'll pinpoint what "neutral" sounds like for that persona. Using the Custom Neural Voice capability, you can train a model that speaks with emotions. Define the "speaking styles" and ask your voice talent to read the script in a way that resonates the styles you want.

-A persona might have, for example, a naturally upbeat personality. So "their" voice might carry a note of optimism even when they speak neutrally. However, such a personality trait should be subtle and consistent. Listen to readings by existing voices to get an idea of what you're aiming for.

-The utterances in your script can come from anywhere: fiction, non-fiction, transcripts of speeches, news reports, and anything else available in printed form. For a brief discussion of potential legal issues, see the ["Legalities"](#legalities) section. You can also write your own text.

-Your utterances don't need to come from the same source, or the same kind of source. They don't even need to have anything to do with each other. However, if you'll use set phrases (for example, "You have successfully logged in") in your speech application, make sure to include them in your script. It will give your custom neural voice a better chance of pronouncing those phrases well.

-We recommend the recording scripts include both general sentences and your domain-specific sentences. For example, if you plan to record 2,000 sentences, 1,000 of them could be general sentences, another 1,000 of them could be sentences from your target domain or the use case of your application.

-We provide [sample scripts in the 'General', 'Chat' and 'Customer Service' domains for each language](https://github.com/Azure-Samples/Cognitive-Speech-TTS/tree/master/CustomVoice/script) to help you prepare your recording scripts. You can use these Microsoft shared scripts for your recordings directly or use them as a reference to create your own.

-You can select your domain-specific scripts from the sentences that your custom neural voice will be used to read.

- In general, each sentence should contain 4 words to 30 words. It's required that no duplicate sentences are included in your script.<br>

- For how to balance the different sentence types, refer to the following table.

- | Statement sentences | Statement sentences are the major part of the script, taking about 70-80% of all. |

- | Question sentences | Question sentences should take about 10%-20% of your domain script, including 5%-10% of rising and 5%-10% of falling tones. |

- | Exclamation sentences| Exclamation sentences should take about 10%-20% of your scripts.|

- | Short word/phrase| Short word/phrase scripts should also take about 10% cases of the total utterances, with 5 to 7 words per case. |

- > Regarding short word/phrase, actually it means that single words or phrases should be included and separated with a comma. It helps a voice talent pause briefly at the comma when reading the scripts.

- - Balanced coverage for Part of Speech, like verb, noun, adjective, and so on.

- - Balanced coverage for pronunciations. Include all letters from A to Z so the Text-to-Speech engine learns how to pronounce each letter in your defined style.

- - Readable, understandable, common-sense for speaker to read out.

- - Avoid too much similar pattern for word/phrase, like "easy" and "easier".

- - Include different format of numbers: address, unit, phone, quantity, date, and so on, in all sentence types.

- - Include spelling sentences if it's something your custom neural voice will be used to read. For example, "Spell of Apple is A P P L E".

- - For lines with abbreviations, instead of "BTW", you have "by the way".

- - For lines with digits, instead of "911", you have "nine one one".

- - For lines with acronyms, instead of "ABC", you have "A B C".

- With that, make sure your voice talent pronounces these words in the expected way. Keep your script and recordings match consistently during the training process.

-The training script can differ from the voice talent script, especially for scripts that contain digits, symbols, abbreviations, date, and time. Scripts prepared for the voice talent must follow the native reading conventions, such as 50% and $45. The scripts used for training must be normalized to match the audio recording, such as *fifty percent* and *forty-five dollars*.

-| Digits |123| one hundred and twenty-three |

-The script's poor quality can adversely affect the training results. To achieve high-quality training results, it's crucial to avoid the defects.

-The script defects generally fall into the following categories:

-| Have a meaningless content in a common way. | |

-|Uncommon foreign words: only the commonly used foreign word is acceptable in our script. | |

-|Emoji or any other uncommon symbols. | |

-You can write your script in Microsoft Word. The script is for use during the recording session, so you can set it up any way you find easy to work with. Create the text file that's required by Speech Studio separately.

-> Most studios record in short segments known as *takes*. Each take typically contains 10 to 24 utterances. Just noting the take number is sufficient to find an utterance later. If you're recording in a studio that prefers to make longer recordings, you'll want to note the time code instead. The studio will have a prominent time display.

-Print three copies of the script: one for the talent, one for the engineer, and one for the director (you). Use a paper clip instead of staples: an experienced voice artist will separate the pages to avoid making noise as the pages are turned.

-Under copyright law, an actor's reading of copyrighted text might be a performance for which the author of the work should be compensated. This performance won't be recognizable in the final product, the custom neural voice. Even so, the legality of using a copyrighted work for this purpose isn't well established. Microsoft can't provide legal advice on this issue; consult your own counsel.

-For high-quality training results, avoiding audio errors is highly recommended. The errors of audio normally involve the following categories:

- Below sample contains noises of DC offset or echo.

-If you want to make the recording yourself, rather than going into a recording studio, here's a short primer. Thanks to the rise of home recording and podcasting, it's easier than ever to find good recording advice and resources online.

-You may also use an analog microphone. Many rental houses offer "vintage" microphones renowned for their voice character. Note that professional analog gear uses balanced XLR connectors, rather than the 1/4-inch plug that's used in consumer equipment. If you go analog, you'll also need a preamp and a computer audio interface with these connectors.

-The person operating the recording equipmentΓÇöthe engineerΓÇöshould be in a separate room from the talent, with some way to talk to the talent in the recording booth (a *talkback circuit).*

-Record at 44.1 KHz 16 bit monophonic (CD quality) or better. Current state-of-the-art is 48 KHz 24 bit, if your equipment supports it. You'll down-sample your audio to 24 KHz 16-bit before you submit it to Speech Studio. Still, it pays to have a high-quality original recording in the event edits are needed.

-> All you really need to capture is the voice talent, so you can make a monophonic (single-channel) recording of just their lines. However, if you record in stereo, you can use the second channel to record the chatter in the control room to capture discussion of particular lines or takes. Remove this track from the version that's uploaded to Speech Studio.

-Finally, create the *transcript* that associates each WAV file with a text version of the corresponding utterance. [Train your voice model](./how-to-custom-voice-create-voice.md) includes details of the required format. You can copy the text directly from your script. Then create a Zip file of the WAV files and the text transcript.

-| Attribute | Description | Required or optional |

-|--|-||

-| `version` | Indicates the version of the SSML specification used to interpret the document markup. The current version is 1.0. | Required |

-| `xml:lang` | Specifies the language of the root document. The value can contain a lowercase, two-letter language code, for example, `en`. Or the value can contain the language code and uppercase country/region, for example, `en-US`. | Required |

-| `xmlns` | Specifies the URI to the document that defines the markup vocabulary (the element types and attribute names) of the SSML document. The current URI is http://www.w3.org/2001/10/synthesis. | Required |

-| Attribute | Description | Required or optional |

-|--|-||

-| `name` | Identifies the voice used for text-to-speech output. For a complete list of supported voices, see [Language support](language-support.md#text-to-speech). | Required |

-| Attribute | Description | Required or optional |

-|--|-||

-| `name` | Identifies the voice used for text-to-speech output. For a complete list of supported voices, see [Language support](language-support.md#text-to-speech). | Required |

-| Attribute | Description | Required or optional |

-|--|-||

-| `style` | Specifies the speaking style. Speaking styles are voice specific. | Required if adjusting the speaking style for a neural voice. If you're using `mstts:express-as`, the style must be provided. If an invalid value is provided, this element is ignored. |

-| `styledegree` | Specifies the intensity of the speaking style. **Accepted values**: 0.01 to 2 inclusive. The default value is 1, which means the predefined style intensity. The minimum unit is 0.01, which results in a slight tendency for the target style. A value of 2 results in a doubling of the default style intensity. | Optional. If you don't set the `style` attribute, the `styledegree` attribute is ignored. Speaking style degree adjustments are supported for Chinese (Mandarin, Simplified) neural voices.|

-| `role` | Specifies the speaking role-play. The voice acts as a different age and gender, but the voice name isn't changed. | Optional. Role adjustments are supported for these Chinese (Mandarin, Simplified) neural voices: `zh-CN-XiaomoNeural`, `zh-CN-XiaoxuanNeural`, `zh-CN-YunxiNeural`, and `zh-CN-YunyeNeural`.|

-|Role | Description |

-|-|-|

-|`role="Girl"` | The voice imitates to a girl. |

-|`role="Boy"` | The voice imitates to a boy. |

-|`role="YoungAdultFemale"`| The voice imitates to a young adult female.|

-|`role="YoungAdultMale"` | The voice imitates to a young adult male.|

-|`role="OlderAdultFemale"`| The voice imitates to an older adult female.|

-|`role="OlderAdultMale"` | The voice imitates to an older adult male.|

-|`role="SeniorFemale"` | The voice imitates to a senior female.|

-|`role="SeniorMale"` | The voice imitates to a senior male.|

-| Attribute | Description | Required or optional |

-|--|-||

-| `lang` | Specifies the language that you want the neural voice to speak. | Required to adjust the speaking language for the neural voice. If you're using `lang xml:lang`, the locale must be provided. |

-Use this table to determine which speaking languages are supported for each neural voice. If the voice does not speak the language of the input text, the Speech service won't output synthesized audio.

-| Voice | Primary and default locale | Additional locales |

-|-||-|

-| `en-US-JennyMultilingualNeural` | `en-US` | `de-DE`, `en-AU`, `en-CA`, `en-GB`, `es-ES`, `es-MX`, `fr-CA`, `fr-FR`, `it-IT`, `ja-JP`, `ko-KR`, `pt-BR`, `zh-CN` |

-The primary language for `en-US-JennyMultilingualNeural` is `en-US`. You must specify `en-US` as the default language within the `speak` element, whether or not the language is adjusted elsewhere. This SSML snippet shows how speak `de-DE` with the `en-US-JennyMultilingualNeural` neural voice.

-| Attribute | Description | Required or optional |

-|--|-||

-| `strength` | Specifies the relative duration of a pause by using one of the following values:<ul><li>none</li><li>x-weak</li><li>weak</li><li>medium (default)</li><li>strong</li><li>x-strong</li></ul> | Optional |

-| `time` | Specifies the absolute duration of a pause in seconds or milliseconds (ms). This value should be set less than 5,000 ms. Examples of valid values are `2s` and `500ms`. | Optional |

-|-|-|

-| Strong | 1,000 ms |

-| X-strong | 1,250 ms |

-| Attribute | Description | Required or optional |

-|--|-||

-| `type` | Specifies the location of silence to be added: <ul><li>`Leading` ΓÇô At the beginning of text </li><li>`Tailing` ΓÇô At the end of text </li><li>`Sentenceboundary` ΓÇô Between adjacent sentences </li></ul> | Required |

-| `Value` | Specifies the absolute duration of a pause in seconds or milliseconds. This value should be set less than 5,000 ms. Examples of valid values are `2s` and `500ms`. | Required |

-| Attribute | Description | Required or optional |

-|--|-||

-| `alphabet` | Specifies the phonetic alphabet to use when you synthesize the pronunciation of the string in the `ph` attribute. The string that specifies the alphabet must be specified in lowercase letters. The following options are the possible alphabets that you can specify:<ul><li>`ipa` &ndash; See [SSML phonetic alphabets](speech-ssml-phonetic-sets.md)</li><li>`sapi` &ndash; See [SSML phonetic alphabets](speech-ssml-phonetic-sets.md)</li><li>`ups` &ndash; See [Universal Phone Set](https://documentation.help/Microsoft-Speech-Platform-SDK-11/17509a49-cae7-41f5-b61d-07beaae872ea.htm)</li></ul><br>The alphabet applies only to the `phoneme` in the element.| Optional |

-| `ph` | A string containing phones that specify the pronunciation of the word in the `phoneme` element. If the specified string contains unrecognized phones, text-to-speech rejects the entire SSML document and produces none of the speech output specified in the document. | Required if using phonemes |

-| Attribute | Description | Required or optional |

-|--|-||

-| `uri` | The address of the external PLS document | Required |

-| Attribute | Description | Required or optional |

-|--|-||

-| `pitch` | Indicates the baseline pitch for the text. You can express the pitch as:<ul><li>An absolute value, expressed as a number followed by "Hz" (Hertz). For example, `<prosody pitch="600Hz">some text</prosody>`.</li><li>A relative value, expressed as a number preceded by "+" or "-" and followed by "Hz" or "st" that specifies an amount to change the pitch. For example: `<prosody pitch="+80Hz">some text</prosody>` or `<prosody pitch="-2st">some text</prosody>`. The "st" indicates the change unit is semitone, which is half of a tone (a half step) on the standard diatonic scale.</li><li>A constant value:<ul><li>x-low</li><li>low</li><li>medium</li><li>high</li><li>x-high</li><li>default</li></ul></li></ul> | Optional |

-| `contour` |Contour now supports neural voice. Contour represents changes in pitch. These changes are represented as an array of targets at specified time positions in the speech output. Each target is defined by sets of parameter pairs. For example: <br/><br/>`<prosody contour="(0%,+20Hz) (10%,-2st) (40%,+10Hz)">`<br/><br/>The first value in each set of parameters specifies the location of the pitch change as a percentage of the duration of the text. The second value specifies the amount to raise or lower the pitch by using a relative value or an enumeration value for pitch (see `pitch`). | Optional |

-| `range` | A value that represents the range of pitch for the text. You can express `range` by using the same absolute values, relative values, or enumeration values used to describe `pitch`. | Optional |

-| `rate` | Indicates the speaking rate of the text. You can express `rate` as:<ul><li>A relative value, expressed as a number that acts as a multiplier of the default. For example, a value of *1* results in no change in the rate. A value of *0.5* results in a halving of the rate. A value of *3* results in a tripling of the rate.</li><li>A constant value:<ul><li>x-slow</li><li>slow</li><li>medium</li><li>fast</li><li>x-fast</li><li>default</li></ul></li></ul> | Optional |

-| `volume` | Indicates the volume level of the speaking voice. You can express the volume as:<ul><li>An absolute value, expressed as a number in the range of 0.0 to 100.0, from *quietest* to *loudest*. An example is 75. The default is 100.0.</li><li>A relative value, expressed as a number preceded by "+" or "-" that specifies an amount to change the volume. Examples are +10 or -5.5.</li><li>A constant value:<ul><li>silent</li><li>x-soft</li><li>soft</li><li>medium</li><li>loud</li><li>x-loud</li><li>default</li></ul></li></ul> | Optional |

-| Attribute | Description | Required or optional |

-|--|-||

-| `level` | Indicates the strength of emphasis to be applied:<ul><li>`reduced`</li><li>`none`</li><li>`moderate`</li><li>`strong`</li></ul><br>When the `level` attribute is not specified, the default level is `moderate`. For details on each attribute, see [emphasis element](https://www.w3.org/TR/speech-synthesis11/#S3.2.2)| Optional|

-| Attribute | Description | Required or optional |

-|--|-||

-| `interpret-as` | Indicates the content type of an element's text. For a list of types, see the following table. | Required |

-| `format` | Provides additional information about the precise formatting of the element's text for content types that might have ambiguous formats. SSML defines formats for content types that use them. See the following table. | Optional |

-| `detail` | Indicates the level of detail to be spoken. For example, this attribute might request that the speech synthesis engine pronounce punctuation marks. There are no standard values defined for `detail`. | Optional |

-The following content types are supported for the `interpret-as` and `format` attributes. Include the `format` attribute only if `format` column is not empty in the table below.

-| interpret-as | format | Interpretation |

-|--|--|-|

-| `address` | | The text is spoken as an address. The speech synthesis engine pronounces:<br /><br />`I'm at <say-as interpret-as="address">150th CT NE, Redmond, WA</say-as>`<br /><br />As "I'm at 150th Court Northeast Redmond Washington." |

-| `cardinal`, `number` | | The text is spoken as a cardinal number. The speech synthesis engine pronounces:<br /><br />`There are <say-as interpret-as="cardinal">3</say-as> alternatives`<br /><br />As "There are three alternatives." |

-| `characters`, `spell-out` | | The text is spoken as individual letters (spelled out). The speech synthesis engine pronounces:<br /><br />`<say-as interpret-as="characters">test</say-as>`<br /><br />As "T E S T." |

-| `date` | dmy, mdy, ymd, ydm, ym, my, md, dm, d, m, y | The text is spoken as a date. The `format` attribute specifies the date's format (*d=day, m=month, and y=year*). The speech synthesis engine pronounces:<br /><br />`Today is <say-as interpret-as="date" format="mdy">10-19-2016</say-as>`<br /><br />As "Today is October nineteenth two thousand sixteen." |

-| `digits`, `number_digit` | | The text is spoken as a sequence of individual digits. The speech synthesis engine pronounces:<br /><br />`<say-as interpret-as="number_digit">123456789</say-as>`<br /><br />As "1 2 3 4 5 6 7 8 9." |

-| `fraction` | | The text is spoken as a fractional number. The speech synthesis engine pronounces:<br /><br /> `<say-as interpret-as="fraction">3/8</say-as> of an inch`<br /><br />As "three eighths of an inch." |

-| `ordinal` | | The text is spoken as an ordinal number. The speech synthesis engine pronounces:<br /><br />`Select the <say-as interpret-as="ordinal">3rd</say-as> option`<br /><br />As "Select the third option." |

-| `telephone` | | The text is spoken as a telephone number. The `format` attribute can contain digits that represent a country code. Examples are "1" for the United States or "39" for Italy. The speech synthesis engine can use this information to guide its pronunciation of a phone number. The phone number might also include the country code, and if so, takes precedence over the country code in the `format` attribute. The speech synthesis engine pronounces:<br /><br />`The number is <say-as interpret-as="telephone" format="1">(888) 555-1212</say-as>`<br /><br />As "My number is area code eight eight eight five five five one two one two." |

-| `time` | hms12, hms24 | The text is spoken as a time. The `format` attribute specifies whether the time is specified by using a 12-hour clock (hms12) or a 24-hour clock (hms24). Use a colon to separate numbers representing hours, minutes, and seconds. Here are some valid time examples: 12:35, 1:14:32, 08:15, and 02:50:45. The speech synthesis engine pronounces:<br /><br />`The train departs at <say-as interpret-as="time" format="hms12">4:00am</say-as>`<br /><br />As "The train departs at four A M." |

-| `duration` | hms, hm, ms | The text is spoken as a duration. The `format` attribute specifies the duration's format (*h=hour, m=minute, and s=second*). The speech synthesis engine pronounces:<br /><br />`<say-as interpret-as="duration">01:18:30</say-as>`<br /><br /> As "one hour eighteen minutes and thirty seconds".<br />Pronounces:<br /><br />`<say-as interpret-as="duration" format="ms">01:18</say-as>`<br /><br /> As "one minute and eighteen seconds".<br />This tag is only supported on English and Spanish.|

-| `name` | | The text is spoken as a person's name. The speech synthesis engine pronounces:<br /><br />`<say-as interpret-as="name">ED</say-as>`<br /><br />As [æd]. <br />In Chinese names, some characters pronounce differently when they appear in a family name. For example, the speech synthesis engine says 仇 in <br /><br />`<say-as interpret-as="name">仇先生</say-as>`<br /><br /> As [qiú] instead of [chóu]. |

-| Attribute | Description | Required or optional |

-|--|--||

-| Attribute | Description | Required or optional |

-|--|-||

-| `src` | Specifies the location/URL of the background audio file. | Required if using background audio in your SSML document |

-| `volume` | Specifies the volume of the background audio file. **Accepted values**: `0` to `100` inclusive. The default value is `1`. | Optional |

-| `fadein` | Specifies the duration of the background audio fade-in as milliseconds. The default value is `0`, which is the equivalent to no fade in. **Accepted values**: `0` to `10000` inclusive. | Optional |

-| `fadeout` | Specifies the duration of the background audio fade-out in milliseconds. The default value is `0`, which is the equivalent to no fade out. **Accepted values**: `0` to `10000` inclusive. | Optional |

-| Attribute | Description | Required or optional |

-|--|--||

-| `mark` | Specifies the reference text of the `bookmark` element. | Required |

-Inbound PSTN calling is currently supported in GA for Dynamics Omnichannel with phone numbers [provided by Microsoft](./telephony-concept.md#voice-calling-pstn) and phone numbers that supplied by [direct routing](./telephony-concept.md#azure-direct-routing).

- Supported in General Availability, to setup inbound PSTN or direct routing with Dynamics 365 OC, follow the [instructions here](/dynamics365/customer-service/voice-channel-inbound-calling)

-```

- layout: {

- type: ΓÇÿpresenterΓÇÖ,

- presenter: {

- supportPosition: ΓÇÿrightΓÇÖ,

- primarySource: ΓÇÿ1ΓÇÖ, // source id

- },

- sources: [

- { id: ΓÇÿ1ΓÇÖ }, { id: ΓÇÿ2ΓÇÖ }

- ]

-The presenter layout is one of several layouts available through the media composition capability:

-description: Automate tasks and workflows that create, monitor, and manage files on an FTP server by using Azure Logic Apps.

-# Create, monitor, and manage FTP files by using Azure Logic Apps

-With Azure Logic Apps and the FTP connector, you can create automated tasks and workflows that create, monitor, send, and receive files through your account on an FTP server, along with other actions, for example:

-* Get, create, copy, update, list, and delete files.

-* Get file content and metadata.

-* Extract archives to folders.

-You can use triggers that get responses from your FTP server and make the output available to other actions. You can use run actions in your logic apps for managing files on your FTP server. You can also have other actions use the output from FTP actions. For example, if you regularly get files from your FTP server, you can send email about those files and their content by using the Office 365 Outlook connector or Outlook.com connector. If you're new to logic apps, review [What is Azure Logic Apps](../logic-apps/logic-apps-overview.md).

-## Limitations

-* The FTP connector supports only explicit FTP over TLS/SSL (FTPS) and isn't compatible with implicit FTPS.

-* By default, FTP actions can read or write files that are *50 MB or smaller*. To handle files larger than 50 MB, FTP actions support [message chunking](../logic-apps/logic-apps-handle-large-messages.md). The **Get file content** action implicitly uses chunking.

-* FTP triggers don't support chunking. When requesting file content, triggers select only files that are 50 MB or smaller. To get files larger than 50 MB, follow this pattern:

- * Use an FTP trigger that returns file properties, such as **When a file is added or modified (properties only)**.

- * Follow the trigger with the FTP **Get file content** action, which reads the complete file and implicitly uses chunking.

-* If you have an on-premises FTP server, consider creating an [integration service environment (ISE)](../logic-apps/connect-virtual-network-vnet-isolated-environment-overview.md) or using [Azure App Service Hybrid connections](../app-service/app-service-hybrid-connections.md), which both let you access on-premises data sources without using an on-premises data gateway.

-## How FTP triggers work

-FTP triggers work by polling the FTP file system and looking for any file that was changed since the last poll. Some tools let you preserve the timestamp when the files change. In these cases, you have to disable this feature so your trigger can work. Here are some common settings:

-| SFTP client | Action |

-|-|--|

-| Winscp | Go to **Options** > **Preferences** > **Transfer** > **Edit** > **Preserve timestamp** > **Disable** |

-| FileZilla | Go to **Transfer** > **Preserve timestamps of transferred files** > **Disable** |

-|||

-When a trigger finds a new file, the trigger checks that the new file is complete, and not partially written. For example, a file might have changes in progress when the trigger checks the file server. To avoid returning a partially written file, the trigger notes the timestamp for the file that has recent changes, but doesn't immediately return that file. The trigger returns the file only when polling the server again. Sometimes, this behavior might cause a delay that is up to twice the trigger's polling interval.

-* Your FTP host server address and account credentials

- The FTP connector requires that your FTP server is accessible from the internet and set up to operate in *passive* mode. Your credentials let your logic app create a connection and access your FTP account.

-* Basic knowledge about [how to create logic apps](../logic-apps/quickstart-create-first-logic-app-workflow.md)

-* The logic app where you want to access your FTP account. To start with an FTP trigger, [create a blank logic app](../logic-apps/quickstart-create-first-logic-app-workflow.md). To use an FTP action, start your logic app with another trigger, for example, the **Recurrence** trigger.

-## Connect to FTP

-1. Sign in to the [Azure portal](https://portal.azure.com), and open your logic app in Logic App Designer.

-1. For blank logic apps, in the search box, enter `ftp` as your filter. From the **Triggers** list, select the trigger that you want.

- -or-

- For existing logic apps, under the last step where you want to add an action, select **New step**, and then select **Add an action**. In the search box, enter `ftp` as your filter. From the **Actions** list, select the action that you want.

- To add an action between steps, move your pointer over the arrow between steps. Select the plus sign (**+**) that appears, and then select **Add an action**.

-1. Provide your connection information, and select **Create**.

-1. Provide the information for your selected trigger or action and continue building your logic app's workflow.

-## Examples

-<a name="file-added-modified"></a>

-### Add FTP trigger

-The **When a file is added or modified (properties only)** trigger starts a logic app workflow when the trigger detects that a file is added or changed on an FTP server. For example, you can add a condition that checks the file's content and decides whether to get that content, based on whether that content meets a specified condition. Finally, you can add an action that gets the file's content, and put that content into a different folder on the SFTP server.

-For example, you can use this trigger to monitor an FTP folder for new files that describe customer orders. You can then use an FTP action such as **Get file metadata** to get the properties for that new file, and then use **Get file content** to get the content from that file for further processing and store that order in an orders database.

-Here is an example that shows how to use the **When a file is added or modified (properties only)** trigger.

-1. Sign in to the [Azure portal](https://portal.azure.com), and open your logic app in Logic App Designer, if not open already.

-1. For blank logic apps, in the search box, enter `ftp` as your filter. Under the triggers list, select this trigger: **When a filed is added or modified (properties only)**

- 

-1. Provide the necessary details for your connection, and then select **Create**.

- By default, this connector transfers files in text format. To transfer files in binary format, for example, where and when encoding is used, select **Binary Transport**.

- 

-1. In the **Folder** box, select the folder icon so that a list appears. To find the folder you want to monitor for new or edited files, select the right angle arrow (**>**), browse to that folder, and then select the folder.

- 

- 

-1. Save your logic app. On the designer toolbar, select **Save**.

-Now that your logic app has a trigger, add the actions you want to run when your logic app finds a new or edited file. For this example, you can add an FTP action that gets the new or updated content.

-<a name="get-content"></a>

-### Add FTP action

-The **Get file metadata** action gets the properties for a file that's on your FTP server and the **Get file content** action gets the file content based on the information about that file on your FTP server. For example, you can add the trigger from the previous example and these actions to get the file's content after that file is added or edited.

-1. Under the trigger or any other actions, select **New step**.

-1. In the search box, enter `ftp` as your filter. Under the actions list, select this action: **Get file metadata**

- 

-1. If you already have a connection to your FTP server and account, go to the next step. Otherwise, provide the necessary details for that connection, and then select **Create**.

- 

-1. After the **Get file metadata** action appears, click inside the **File** box so that the dynamic content list appears. You can now select properties for the outputs from previous steps. In the dynamic content list, under **Get file metadata**, select the **List of Files Id** property, which references the collection where the file was added or updated.

- 

- The **List of Files Id** property now appears in the **File** box.

- 

-1. Now add this FTP action: **Get file content**

- 

-1. After the **Get file content** action appears, click inside the **File** box so that the dynamic content list appears. You can now select properties for the outputs from previous steps. In the dynamic content list, under **Get file metadata**, select the **Id** property, which references the file that was added or updated.

- 

- The **Id** property now appears in the **File** box.

- 

-1. Save your logic app.

-## Test your logic app

-To check that your workflow returns the content that you expect, add another action that sends you the content from the uploaded or updated file.

-1. Under the **Get file content** action, add an action that can send you the file's contents. This example adds the **Send an email** action for the Office 365 Outlook.

- 

-1. After the action appears, provide the information and include the properties that you want to test. For example, include the **File content** property, which appears in the dynamic content list after you select **See more** in the **Get file content** section.

- 

-1. Save your logic app. To run and trigger the logic app, on the toolbar, select **Run**, and then add a file to the FTP folder that your logic app now monitors.

-## Connector reference

-For more technical details about this connector, such as triggers, actions, and limits as described by the connector's Swagger file, see the [connector's reference page](/connectors/ftpconnector/).

-> [!NOTE]

-> For logic apps in an [integration service environment (ISE)](../logic-apps/connect-virtual-network-vnet-isolated-environment-overview.md),

-> this connector's ISE-labeled version uses the [ISE message limits](../logic-apps/logic-apps-limits-and-config.md#message-size-limits) instead.

-## Next steps

-* Learn about other [Logic Apps connectors](../connectors/apis-list.md)

-## Elements in an Azure Cosmos account

-## Azure Cosmos databases

-## Azure Cosmos containers

-### Properties of an Azure Cosmos container

-### Operations on an Azure Cosmos container

-## Azure Cosmos items

-| Maximum RUs per container ([dedicated throughput provisioned mode](account-databases-containers-items.md#azure-cosmos-containers)) | 1,000,000 ¹ |

-| Maximum RUs per database ([shared throughput provisioned mode](account-databases-containers-items.md#azure-cosmos-containers)) | 1,000,000 ¹ |

-| Minimum RUs per container ([dedicated throughput provisioned mode with manual throughput](./account-databases-containers-items.md#azure-cosmos-containers)) | 400 |

-| Minimum RUs per database ([shared throughput provisioned mode with manual throughput](./account-databases-containers-items.md#azure-cosmos-containers)) | 400 RU/s for first 25 containers. |

-Azure Cosmos DB is a schema-agnostic database that allows you to iterate on your application without having to deal with schema or index management. By default, Azure Cosmos DB automatically indexes every property for all items in your [container](account-databases-containers-items.md#azure-cosmos-containers) without having to define any schema or configure secondary indexes.

-As you build event-based serverless flows using the [Azure Functions trigger for Cosmos DB](./change-feed-functions.md), you'll run into the scenario where you want to do multiple things whenever there is a new event in a particular [Azure Cosmos container](../account-databases-containers-items.md#azure-cosmos-containers). If actions you want to trigger, are independent from one another, the ideal solution would be to **create one Azure Functions triggers for Cosmos DB per action** you want to do, all listening for changes on the same Azure Cosmos container.

-* Granular Role-based Access (RBAC)s isn't supported when querying from Synapse. Users that have access to your Synapse workspace and have access to the Cosmos DB account can access all containers within that account. We currently don't support more granular access to the containers.

-description: This article provides an overview about migrating from EA Reporting to Azure Resource Manager APIs.

-# Migrate from EA Reporting to Azure Resource Manager APIs overview

-This article helps developers that have built custom solutions using the [Azure Reporting APIs for Enterprise Customers](../manage/enterprise-api.md) to migrate to Azure Resource Manager APIs for Cost Management. Service principal support for the newer Azure Resource Manager APIs. Azure Resource Manager APIs are still in active development. Consider migrating to them instead of using the older Azure Reporting APIs for Enterprise customers. The older APIs are being deprecated. This article helps you understand the differences between the Reporting APIs and the Azure Resource Manager APIs, what to expect when you migrate to the Azure Resource Manager APIs, and the new capabilities that are available with the new Azure Resource Manager APIs.

-The following information describes the differences between the older Reporting APIs for Enterprise Customers and the newer Azure Resource Manager APIs.

-| Use | Enterprise Agreement APIs | Azure Resource Manager APIs |

- - Azure Resource Manager APIs have a timeout period of 60 seconds.

- - Azure Resource Manager APIs have rate limiting in place. This results in a `429 throttling error` if rates are exceeded. Build your solutions so that you don't make too many API calls in a short time period.

-## EA API mapping to new Azure Resource Manager APIs

-Use the following information to identify the EA APIs that you currently use and the replacement Azure Resource Manager API to use instead.

-| Scenario | EA APIs | Azure Resource Manager APIs |

-After you've migrated to Azure Resource Manager APIs for your existing reporting scenarios, you can use many other APIs, too. The APIs are also available through Azure Resource Manager and can be automated using service principal-based authentication. Here's a quick summary of the new capabilities that you can use.

-description: Learn about the Reporting APIs that enable Enterprise Azure customers to pull consumption data programmatically.

-# Overview of Reporting APIs for Enterprise customers

-> Microsoft no longer updates the Azure Billing - Enterprise Reporting APIs. Instead, you should use [Azure Consumption](/rest/api/consumption) APIs.

-The Reporting APIs enable Enterprise Azure customers to programmatically pull consumption and billing data into preferred data analysis tools. Enterprise customers have signed an [Enterprise Agreement (EA)](https://azure.microsoft.com/pricing/enterprise-agreement/) with Azure to make negotiated Azure Prepayment (previously called monetary commitment) and gain access to custom pricing for Azure resources.

-> Support for complex data type casting from the Cast transformation is currently unavailable. Use a Derived Column transformation instead.

-The release notes are continuously updated, and as critical issues requiring a workaround are discovered, they are added. Before you deploy your device, carefully review the information contained in the release notes.

-This article applies to the **Azure Stack Edge 2203** release, which maps to software version number **2.2.1902.4561**. This software can be applied to your device if you are running at least Azure Stack Edge 2106 (2.2.1636.3457) software.

-| No. | Feature | Issue | Workaround/comments |

-|**2.**|HPN VMs |For this release, the Standard_F12_HPN can only support one network interface and cannot be used for Multi-Access Edge Computing (MEC) deployments. | |

-|**5.**|Tiered storage accounts|The following apply when using tiered storage accounts:<br> - Only block blobs are supported. Page blobs are not supported.<br> - There is no snapshot or copy API support.<br> - Hadoop workload ingestion through `distcp` is not supported as it uses the copy operation heavily.||

-|**7.**|Kubernetes cluster|When applying an update on your device that is running a Kubernetes cluster, the Kubernetes virtual machines will restart and reboot. In this instance, only pods that are deployed with replicas specified are automatically restored after an update. |If you have created individual pods outside a replication controller without specifying a replica set, these pods won't be restored automatically after the device update. You will need to restore these pods.<br>A replica set replaces pods that are deleted or terminated for any reason, such as node failure or disruptive node upgrade. For this reason, we recommend that you use a replica set even if your application requires only a single pod.|

-|**9.**|Kubernetes |Port 31000 is reserved for Kubernetes Dashboard. Port 31001 is reserved for Edge container registry. Similarly, in the default configuration, the IP addresses 172.28.0.1 and 172.28.0.10, are reserved for Kubernetes service and Core DNS service respectively.|Do not use reserved IPs.|

-|**10.**|Kubernetes |Kubernetes does not currently allow multi-protocol LoadBalancer services. For example, a DNS service that would have to listen on both TCP and UDP. |To work around this limitation of Kubernetes with MetalLB, two services (one for TCP, one for UDP) can be created on the same pod selector. These services use the same sharing key and spec.loadBalancerIP to share the same IP address. IPs can also be shared if you have more services than available IP addresses. <br> For more information, see [IP address sharing](https://metallb.universe.tf/usage/#ip-address-sharing).|

-|**12.**|Kubernetes |File-based bind mounts aren't supported with Azure IoT Edge on Kubernetes on Azure Stack Edge device.|IoT Edge uses a translation layer to translate `ContainerCreate` options to Kubernetes constructs. Creating `Binds` maps to `hostpath` directory and thus file-based bind mounts cannot be bound to paths in IoT Edge containers. If possible, map the parent directory.|

-|**13.**|Kubernetes |If you bring your own certificates for IoT Edge and add those certificates on your Azure Stack Edge device after the compute is configured on the device, the new certificates are not picked up.|To work around this problem, you should upload the certificates before you configure compute on the device. If the compute is already configured, [Connect to the PowerShell interface of the device and run IoT Edge commands](azure-stack-edge-gpu-connect-powershell-interface.md#use-iotedge-commands). Restart `iotedged` and `edgehub` pods.|

-|**16.**|Web proxy |NTLM authentication-based web proxy is not supported. ||

-|**19.** |Azure Arc + Kubernetes cluster |By default, when resource `yamls` are deleted from the Git repository, the corresponding resources are not deleted from the Kubernetes cluster. |To allow the deletion of resources when they're deleted from the git repository, set `--sync-garbage-collection` in Arc OperatorParams. For more information, see [Delete a configuration](../azure-arc/kubernetes/tutorial-use-gitops-connected-cluster.md#additional-parameters). |

-|**21.**|Compute configuration |Compute configuration fails in network configurations where gateways or switches or routers respond to Address Resolution Protocol (ARP) requests for systems that do not exist on the network.| |

-|**22.**|Compute and Kubernetes |If Kubernetes is set up first on your device, it claims all the available GPUs. Hence, it is not possible to create Azure Resource Manager VMs using GPUs after setting up the Kubernetes. |If your device has 2 GPUs, then you can create 1 VM that uses the GPU and then configure Kubernetes. In this case, Kubernetes will use the remaining available 1 GPU. |

-|**23.**|Custom script VM extension |There is a known issue in the Windows VMs that were created in an earlier release and the device was updated to 2103. <br> If you add a custom script extension on these VMs, the Windows VM Guest Agent (Version 2.7.41491.901 only) gets stuck in the update causing the extension deployment to time out. | To work around this issue: <br> - Connect to the Windows VM using remote desktop protocol (RDP). <br> - Make sure that the `waappagent.exe` is running on the machine: `Get-Process WaAppAgent`. <br> - If the `waappagent.exe` is not running, restart the `rdagent` service: `Get-Service RdAgent` \| `Restart-Service`. Wait for 5 minutes.<br> - While the `waappagent.exe` is running, kill the `WindowsAzureGuest.exe` process. <br> - After you kill the process, the process starts running again with the newer version. <br> - Verify that the Windows VM Guest Agent version is 2.7.41491.971 using this command: `Get-Process WindowsAzureGuestAgent` \| `fl ProductVersion`.<br> - [Set up custom script extension on Windows VM](azure-stack-edge-gpu-deploy-virtual-machine-custom-script-extension.md). |

-|**24.**|GPU VMs |Prior to this release, GPU VM lifecycle was not managed in the update flow. Hence, when updating to 2103 release, GPU VMs are not stopped automatically during the update. You will need to manually stop the GPU VMs using a `stop-stayProvisioned` flag before you update your device. For more information, see [Suspend or shut down the VM](azure-stack-edge-gpu-deploy-virtual-machine-powershell.md#suspend-or-shut-down-the-vm).<br> All the GPU VMs that are kept running before the update, are started after the update. In these instances, the workloads running on the VMs aren't terminated gracefully. And the VMs could potentially end up in an undesirable state after the update. <br>All the GPU VMs that are stopped via the `stop-stayProvisioned` before the update, are automatically started after the update. <br>If you stop the GPU VMs via the Azure portal, you'll need to manually start the VM after the device update.| If running GPU VMs with Kubernetes, stop the GPU VMs right before the update. <br>When the GPU VMs are stopped, Kubernetes will take over the GPUs that were used originally by VMs. <br>The longer the GPU VMs are in stopped state, higher the chances that Kubernetes will take over the GPUs. |

-|**25.**|Multi-Process Service (MPS) |When the device software and the Kubernetes cluster are updated, the MPS setting is not retained for the workloads. |[Re-enable MPS](azure-stack-edge-gpu-connect-powershell-interface.md#connect-to-the-powershell-interface) and redeploy the workloads that were using MPS. |

-|**26.**|Wi-Fi |Wi-Fi does not work on Azure Stack Edge Pro 2 in this release. | This functionality may be available in a future release. |

-| No. | Feature | Issue | Workaround/comments |

- For an *n*-node device, a contiguous range of a minimum of *n+1* IPv4 addresses (or more) are provided for the compute VM using the start and end IP addresses. For a 1-node device, provide a minimum of 2 contiguous IPv4 addresses.

-1. Assign **Kubernetes external service IPs**. These are also the load-balancing IP addresses. These contiguous IP addresses are for services that you want to expose outside of the Kubernetes cluster and you specify the static IP range depending on the number of services exposed.

- For an *n*-node device, a contiguous range of a minimum of *n+1* IPv4 addresses (or more) are provided for the compute VM using the start and end IP addresses. For a 1-node device, provide a minimum of 2 contiguous IPv4 addresses. For a two-node cluster, provide a minimum of 3 contiguous IPv4 addresses.

-

- .

-1. After the settings are applied, select **Next: Device**.

- On your physical device, there are four network interfaces. Port 1 and Port 2 are 1-Gbps network interfaces that can also serve as 10-Gbps network interfaces. Port 3 and Port 4 are 100-Gbps network interfaces. Port 1 is used for the intial configuration of the device. For a new device, the **Network** page is as shown below.

- For an *n*-node device, a contiguous range of a minimum of *n+1* IPv4 addresses (or more) are provided for the compute VM using the start and end IP addresses. For a 1-node device, provide a minimum of 2 contiguous IPv4 addresses.

- For an *n*-node device, a contiguous range of a minimum of *n+1* IPv4 addresses (or more) are provided for the compute VM using the start and end IP addresses. For a 1-node device, provide a minimum of 2 contiguous IPv4 addresses. For a two-node cluster, provide a minimum of 3 contiguous IPv4 addresses.

-2. After the settings are applied, select **Next: Device**.

-Defender for Cloud depends on the [Log Analytics agent](../azure-monitor/agents/agents-overview.md#log-analytics-agent). Ensure your machines are running one of the supported operating systems for this agent as described on the following pages:

-The 'System updates should be installed on your machines' recommendation is now available on all government clouds.

-Azure Policy can audit settings inside a machine, both for machines running in Azure and Arc connected machines. The validation is performed by the Guest Configuration extension and client. Learn more in [Understand Azure Policy's Guest Configuration](../governance/policy/concepts/guest-configuration.md).

-Azure's [Guest Configuration extension](../governance/policy/concepts/guest-configuration.md) reports to Security Center to help ensure your virtual machines' in-guest settings are hardened. The extension isn't required for Arc-enabled servers because it's included in the Arc Connected Machine agent. The extension requires a system-managed identity on the machine.

-Learn more in [Understand Azure Policy's Guest Configuration](../governance/policy/concepts/guest-configuration.md).

-You can safely ignore these policies and there will be no impact on your environment. If you'd like to enable them, sign up for the preview via the [Microsoft Cloud Security

-description: Defender for IoT security agents collects data and system events from your local device, and sends the data to the Azure cloud for processing, and analytics.

-Defender for IoT security agents collects data, and system events from your local device, and sends the data to the Azure cloud for processing.

-The Defender for IoT micro agent collects many types of device events including new processes, and all new connection events. Both the new process, and new connection events may occur frequently on a device. This capability is important for comprehensive security, however, the number of messages the security agents send may quickly meet, or exceed your IoT Hub quota, and cost limits. These messages, and events contain highly valuable security information that is crucial to protecting your device.

-To reduce the number of messages, and costs while maintaining your device's security, Defender for IoT agents aggregate the following types of events:

-Event-based collectors are collectors that are triggered based on corresponding activity from within the device. For example, ``a process was started in the device``.

-Triggered based collectors are collectors that are triggered in a scheduled manner based on the customer's configurations.

-## How does event aggregation work?

-Defender for IoT agents aggregate events for the interval period, or time window. Once the interval period has passed, the agent sends the aggregated events to the Azure cloud for further analysis. The aggregated events are stored in memory until being sent to the Azure cloud.

-The agent collects identical events to the ones that are already stored in memory. This collection causes the agent to increase the hit count of this specific event to reduce the memory footprint of the agent. When the aggregation time window passes, the agent sends the hit count of each type of event that occurred. Event aggregation is simply the aggregation of the hit counts of each collected type of event.

-## Process events (event based)

-Process events are considered identical when the *command line*, and *userid* are identical.

-## Network Connection events (event-based collector)

-Network Connection events are considered identical when the local port, remote port, transport protocol, local address, and remote address are identical.

-The default buffer for a network connection event is 256. For situations where the cache is full:

-The Login collector, collects user sign-ins, sign-outs, and failed sign-in attempts.

-## System information (trigger based collector)

-|**type** | one of the following values: `UNKNOWN`, `ETH`, `WIFI`, `MOBILE`, or `SATELLITE`. |

-## Baseline (trigger based)

-### Data collection

-## SBoM (trigger based)

-|**Name** | The package name |

-|**Version** | The package version |

-|**Vendor** | The package's vendor, which is the **Maintainer** field in deb packages |

-Check your [Defender for IoT security alerts](concept-security-alerts.md).

-The micro agent's behavior is configured by a set of module twin properties. You can configure the micro agent to best suit your needs. For example, you can exclude events automatically, minimize power consumption, and reduce network bandwidth.

-After any change in configuration, the collector will immediately send all unsent event data. After the data is sent, the changes will be applied, and all the collectors will restart.

-To reduce the number of messages sent to cloud, each priority should be set as a multiple of the one below it. For example, High: 60 minutes, Medium: 120 minutes, Low: 480 minutes.

-## Baseline collector-specific settings

-| **Baseline_GroupsDisabled** | A list of Baseline group names, separated by a comma. <br><br>For example: `Time Synchronization, Network Parameters Host` | Defines the full list of Baseline group names that should be disabled. | Null |

-| **Baseline_ChecksDisabled** |A list of Baseline check IDs, separated by a comma. <br><br>For example: `3.3.5,2.2.1.1` | Defines the full list of Baseline check IDs that should be disabled. | Null |

-## Event-based collector configurations

-These configurations include process, and network activity collectors.

-| **Interval** | `High` <br>`Medium`<br>`Low` | Determines the sending frequency. | `Medium` |

-| **Aggregation mode** | `True` <br>`False` | Determines whether to process event aggregation for an identical event. | `True` |

-| **Cache size** | cycle FIFO | Defines the number of events collected in between the times that data is sent. | `256` |

-| **Disable collector** | `True` <br> `False` | Determines whether or not the collector is operational. | `False` |

-## IoT Hub Module-specific settings

-| **IothubModule_MessageTimeout** | Positive integer, including limits | Defines the number of minutes to retain messages in the outbound queue to the IoT Hub, after which point the messages are dropped. | `2880` (=2 days) |

-## Network activity collector-specific settings

-| **Devices** | A list of the network devices separated by a comma. <br><br>For example `eth0,eth1` | Defines the list of network devices (interfaces) that the agent will use to monitor the traffic. <br><br>If a network device isn't listed, the Network Raw events won't be recorded for the missing device.| `eth0` |

-| | | | |

-## Process collector specific-settings

-| **Process_Mode** | `1` = Auto <br>`2` = Netlink <br>`3`= Polling | Determines the process collector mode. In `Auto` mode, the agent first tries to enable the Netlink mode. <br><br>If that fails, it will automatically fall back / switch to the Polling mode.| `1` |

-|**Process_PollingInterval** |Integer |Defines the polling interval in microseconds. This value is used when the **Process_Mode** is in `Polling` mode. | `100000` (=0.1 second) |

-## Trigger-based collector configurations

-These configurations include system information, and baseline collectors.

-| **Interval** | `High` <br>`Medium`<br>`Low` | The frequency in which data is sent. | `Low` |

-| **Disable collector** | `True` <br> `False` | Whether or not the collector is operational. | `False` |

-For more information, see [Configure a micro agent twin](how-to-configure-micro-agent-twin.md).

-1. Change the value of any field by adding the field to the `"desired"` section with the new value.

- The agent successfully set the new configuration if the value of `"latest_state"`, under the `"reported"` section will show `"success"`.

-You learned how to configure a micro agent twin. Continue on to learn about other [Micro agent configurations (Preview)](concept-micro-agent-configuration.md).

- For more information, see [Network Connection events (event-based collector)](concept-event-aggregation.md#network-connection-events-event-based-collector).

-1. Sign in to the sensor's CLI using a terminal, such as PUTTY, or MobaXterm.

-description: Learn about the processes for exporting and deleting personal data in Azure Digital Twins.

-# Azure Digital Twins customer data request featuresΓÇï

-Azure Digital Twins is a developer platform for creating secure digital representations of a business environment. Representations are driven by live state data from data sources selected by users. This article shows processes for exporting and deleting personal data in Azure Digital Twins.

-The digital representations called *digital twins* in Azure Digital Twins represent entities in real-world environments, and are associated with identifiers. Microsoft maintains no information and has no access to data that would allow identifiers to be correlated to users.

-Many of the digital twins in Azure Digital Twins don't directly represent personal entitiesΓÇötypical objects represented might be an office meeting room, or a factory floor. However, users may consider some entities to be personally identifiable, and at their discretion may maintain their own asset or inventory tracking methods that tie digital twins to individuals. Azure Digital Twins manages and stores all data associated with digital twins as if it were personal data.

-To view, export, and delete personal data that may be referenced in a data subject request, an Azure Digital Twins administrator can use the [Azure portal](https://portal.azure.com/) for users and roles, or the [Azure Digital Twins REST APIs](/rest/api/azure-digitaltwins/) for digital twins. The Azure portal and REST APIs provide different methods for users to service such data subject requests.

-## Identifying customer data

-## Deleting customer data

-Azure Digital Twins administrators can use the Azure portal to delete data related to users. It's also possible to perform delete operations on individual digital twins using the Azure Digital Twins REST APIs. For more information about the APIs available, see [Azure Digital Twins REST APIs documentation](/rest/api/azure-digitaltwins/).

-## Exporting customer data

-Azure Digital Twins stores data related to digital twins. Users can retrieve and view this data through REST APIs, and export this data using copy and paste.

-Customer data, including user roles and role assignments, can be selected, copied, and pasted from the Azure portal.

-Event Grid supports automatic geo-disaster recovery of event subscription configuration data (metadata) for topics, system topics, domains, and partner topics. Event Grid automatically syncs your event-related infrastructure to a paired region. If an entire Azure region goes down, the events will begin to flow to the geo-paired region with no intervention from you.

-| **[BICS](https://bics.com/bics-solutions-suite/cloud-connect/bics-cloud-connect-an-official-microsoft-azure-technology-partner/)** | Supported | Supported | Amsterdam2, London2 |

-| **[Epsilon Global Communications](https://epsilontel.com/solutions/cloud-connect/)** |Supported |Supported | Singapore, Singapore2 |

-| **[Equinix](https://www.equinix.com/partners/microsoft-azure/)** |Supported |Supported | Amsterdam, Amsterdam2, Atlanta, Berlin, Bogota, Canberra2, Chicago, Dallas, Dubai2, Dublin, Frankfurt, Frankfurt2, Geneva, Hong Kong SAR, London, London2, Los Angeles*, Los Angeles2, Melbourne, Miami, Milan, New York, Osaka, Paris, Paris2, Quebec City, Rio de Janeiro, Sao Paulo, Seattle, Seoul, Silicon Valley, Singapore, Singapore2, Stockholm, Sydney, Tokyo, Toronto, Washington DC, Zurich</br></br> **New ExpressRoute circuits are no longer supported with Equinix in Los Angeles. Please create new circuits in Los Angeles2.* |

-| **NL-IX** |Supported |Supported | Amsterdam2 |

-| **NTT Communications India Network Services Pvt Ltd |Supported |Supported | Mumbai |

-| **NTT Communications - Flexible InterConnect |Supported |Supported | Jakarta, Osaka, Singapore2, Tokyo, Tokyo2 |

-| **[Ooredoo Cloud Connect](https://www.ooredoo.com.kw/portal/en/b2bOffConnAzureExpressRoute)** |Supported |Supported | London2, Marseille |

-| **[PacketFabric](https://www.packetfabric.com/cloud-connectivity/microsoft-azure)** |Supported |Supported | Amsterdam, Chicago, Dallas, Denver, Las Vegas, Silicon Valley, Washington DC |

-| **[Retelit](https://www.retelit.it/EN/Home.aspx)** | Supported | Supported | Milan |

-| **[Softbank](https://www.softbank.jp/biz/cloud/cloud_access/direct_access_for_az/)** |Supported |Supported | Osaka, Tokyo |

-| **[Telehouse - KDDI](https://www.telehouse.net/solutions/cloud-services/cloud-link)** |Supported |Supported | London, London2, Singapore2, Tokyo |

-| **[Tivit](https://www.tivit.com/cloud-solutions/public-cloud/public-cloud-azure/)** |Supported |Supported | Sao Paulo2 |

-By default, the new resource specific tables are disabled. Open a support ticket to enable the functionality in your environment.

-|New Zealand ISM Restricted|Policy Assignment|Optional: List of custom VM images that have supported Windows OS to add to scope additional to the images in the gallery for policy: Deploy - Configure Dependency agent to be enabled on Windows virtual machines|For more information on Guest Configuration, visit [https://aka.ms/gcpol](../../policy/concepts/guest-configuration.md)|

-|New Zealand ISM Restricted|Policy Assignment|Optional: List of custom VM images that have supported Windows OS to add to scope additional to the images in the gallery for policy: [Preview]: Log Analytics Agent should be enabled for listed virtual machine images|For more information on Guest Configuration, visit [https://aka.ms/gcpol](../../policy/concepts/guest-configuration.md)|

-|New Zealand ISM Restricted|Policy Assignment|Optional: List of custom VM images that have supported Linux OS to add to scope additional to the images in the gallery for policy: [Preview]: Log Analytics Agent should be enabled for listed virtual machine images|For more information on Guest Configuration, visit [https://aka.ms/gcpol](../../policy/concepts/guest-configuration.md)|

-|New Zealand ISM Restricted|Policy Assignment|Optional: List of custom VM images that have supported Windows OS to add to scope additional to the images in the gallery for policy: Deploy - Configure Dependency agent to be enabled on Windows virtual machine scale sets|For more information on Guest Configuration, visit [https://aka.ms/gcpol](../../policy/concepts/guest-configuration.md)|

-|New Zealand ISM Restricted|Policy Assignment|Optional: List of custom VM images that have supported Linux OS to add to scope additional to the images in the gallery for policy: Log Analytics agent should be enabled in virtual machine scale sets for listed virtual machine images|For more information on Guest Configuration, visit [https://aka.ms/gcpol](../../policy/concepts/guest-configuration.md)|

-|New Zealand ISM Restricted|Policy Assignment|Optional: List of custom VM images that have supported Windows OS to add to scope additional to the images in the gallery for policy: Log Analytics agent should be enabled in virtual machine scale sets for listed virtual machine images|For more information on Guest Configuration, visit [https://aka.ms/gcpol](../../policy/concepts/guest-configuration.md)|