-1. Get the example of an age gating policy on [GitHub](https://github.com/azure-ad-b2c/samples/tree/master/policies).

-Azure Monitor Logs are designed to scale and support collecting, indexing, and storing massive amounts of data per day from any source in your enterprise or deployed in Azure. By default, logs are retained for 30 days, but retention duration can be increased to up to two years. Learn how to [manage usage and costs with Azure Monitor Logs](../azure-monitor/logs/manage-cost-storage.md). After you select the pricing tier, you can [Change the data retention period](../azure-monitor/logs/manage-cost-storage.md#change-the-data-retention-period).

-| 6329 | MMS(3040): admaexport.cpp(2837): The server doesn't contain the LDAP password policy control. | This problem occurs if LDAP_SERVER_POLICY_HINTS_OID control (1.2.840.113556.1.4.2066) isn't enabled on the DCs. To use the password writeback feature, you must enable the control. To do so, the DCs must be on Windows Server 2008R2 or later. |

-When a guest signs in to access resources in a partner organization for the first time, they're guided through the following pages.

-> [!NOTE]

-> The consent experience appears only after the user signs in, and not before. There are some scenarios where the consent experience will not be displayed to the user, for example:

-> - The user already accepted the consent experience

-> - The admin [grants tenant-wide admin consent to an application](../manage-apps/grant-admin-consent.md)

-To review costs related to managing the Azure Monitor logs, see [Manage cost by controlling data volume and retention in Azure Monitor logs](../../azure-monitor/logs/manage-cost-storage.md).

-> | microsoft.directory/authorizationPolicy/standard/read | Read standard properties of authorization policies |

-> | microsoft.directory/b2cTrustFrameworkKeySet/allProperties/allTasks | Read and update all properties of authorization policies |

-> | microsoft.directory/b2cTrustFrameworkPolicy/allProperties/allTasks | Read and configure key sets in Azure Active Directory B2C |

-> | microsoft.directory/authorizationPolicy/standard/read | Read standard properties of authorization policies |

-> | microsoft.directory/authorizationPolicy/standard/read | Read standard properties of authorization policies |

-> | microsoft.directory/crossTenantAccessPolicies/create | Create cross-tenant access policies |

-> | microsoft.directory/crossTenantAccessPolicies/delete | Delete cross-tenant access policies |

-> | microsoft.directory/crossTenantAccessPolicies/standard/read | Read basic properties of cross-tenant access policies |

-> | microsoft.directory/crossTenantAccessPolicies/owners/read | Read owners of cross-tenant access policies |

-> | microsoft.directory/crossTenantAccessPolicies/policyAppliedTo/read | Read the policyAppliedTo property of cross-tenant access policies |

-> | microsoft.directory/crossTenantAccessPolicies/basic/update | Update basic properties of cross-tenant access policies |

-> | microsoft.directory/crossTenantAccessPolicies/owners/update | Update owners of cross-tenant access policies |

-> | microsoft.directory/crossTenantAccessPolicies/tenantDefault/update | Update the default tenant for cross-tenant access policies |

-> | microsoft.directory/authorizationPolicy/standard/read | Read standard properties of authorization policies |

-> | microsoft.directory/authorizationPolicy/standard/read | Read standard properties of authorization policies |

-> | microsoft.directory/b2cUserFlow/allProperties/allTasks | Read and configure user attributes in Azure Active Directory B2C |

-> | microsoft.directory/b2cUserAttribute/allProperties/allTasks | Read and configure custom policies in Azure Active Directory B2C |

-> | microsoft.directory/authorizationPolicy/allProperties/allTasks | Manage all aspects of authorization policies |

-> | microsoft.directory/crossTenantAccessPolicies/allProperties/allTasks | Manage all aspects of cross-tenant access policies |

-> | microsoft.directory/authorizationPolicy/standard/read | Read standard properties of authorization policies |

-> | microsoft.directory/crossTenantAccessPolicies/allProperties/read | Read all properties of cross-tenant access policies |

-> | microsoft.directory/authorizationPolicy/standard/read | Read standard properties of authorization policies |

-> | microsoft.directory/authorizationPolicy/standard/read | Read standard properties of authorization policies |

-> | microsoft.directory/authorizationPolicy/allProperties/allTasks | Manage all aspects of authorization policies |

-> | microsoft.directory/authorizationPolicy/standard/read | Read standard properties of authorization policies |

-> | microsoft.directory/crossTenantAccessPolicies/create | Create cross-tenant access policies |

-> | microsoft.directory/crossTenantAccessPolicies/delete | Delete cross-tenant access policies |

-> | microsoft.directory/crossTenantAccessPolicies/standard/read | Read basic properties of cross-tenant access policies |

-> | microsoft.directory/crossTenantAccessPolicies/owners/read | Read owners of cross-tenant access policies |

-> | microsoft.directory/crossTenantAccessPolicies/policyAppliedTo/read | Read the policyAppliedTo property of cross-tenant access policies |

-> | microsoft.directory/crossTenantAccessPolicies/basic/update | Update basic properties of cross-tenant access policies |

-> | microsoft.directory/crossTenantAccessPolicies/owners/update | Update owners of cross-tenant access policies |

-> | microsoft.directory/crossTenantAccessPolicies/tenantDefault/update | Update the default tenant for cross-tenant access policies |

-> | microsoft.directory/authorizationPolicy/standard/read | Read standard properties of authorization policies |

-> | microsoft.directory/authorizationPolicy/standard/read | Read standard properties of authorization policies |

-> | microsoft.directory/authorizationPolicy/standard/read | Read standard properties of authorization policies |

-> | microsoft.directory/authorizationPolicy/standard/read | Read standard properties of authorization policies |

-> | microsoft.directory/authorizationPolicy/standard/read | Read standard properties of authorization policies |

-> | microsoft.directory/authorizationPolicy/standard/read | Read standard properties of authorization policies |

-> * Remove users in Adobe Identity Management when they do not require access anymore

-> * Single sign-on to Adobe Identity Management (recommended)

-2. Determine who will be in [scope for provisioning](../app-provisioning/define-conditional-rules-for-provisioning-user-accounts.md).

-3. Determine what data to [map between Azure AD and Adobe Identity Management](../app-provisioning/customize-application-attributes.md).

-2. Click **Add Sync**.

-3. Select **Sync users from Microsoft Azure** and click **Next**.

-4. Copy and save the **Tenant URL** and the **Secret token**. These values will be entered in the **Tenant URL** and **Secret Token** fields in the Provisioning tab of your Adobe Identity Management application in the Azure portal.

-2. In the applications list, select **Adobe Identity Management**.

-3. Select the **Provisioning** tab.

-4. Set the **Provisioning Mode** to **Automatic**.

-5. Under the **Admin Credentials** section, input your Adobe Identity Management Tenant URL and Secret Token retrieved earlier from Step 2. Click **Test Connection** to ensure Azure AD can connect to Adobe Identity Management. If the connection fails, ensure your Adobe Identity Management account has Admin permissions and try again.

-6. In the **Notification Email** field, enter the email address of a person or group who should receive the provisioning error notifications and select the **Send an email notification when a failure occurs** check box.

-7. Select **Save**.

-8. Under the **Mappings** section, select **Synchronize Azure Active Directory Users to Adobe Identity Management**.

-9. Review the user attributes that are synchronized from Azure AD to Adobe Identity Management in the **Attribute-Mapping** section. The attributes selected as **Matching** properties are used to match the user accounts in Adobe Identity Management for update operations. If you choose to change the [matching target attribute](../app-provisioning/customize-application-attributes.md), you will need to ensure that the Adobe Identity Management API supports filtering users based on that attribute. Select the **Save** button to commit any changes.

- |Attribute|Type|

- |||

- |userName|String|

- |emails[type eq "work"].value|String|

- |active|Boolean|

- |addresses[type eq "work"].country|String|

- |name.givenName|String|

- |name.familyName|String|

- |urn:ietf:params:scim:schemas:extension:Adobe:2.0:User:emailAliases|String|

-10. Under the **Mappings** section, select **Synchronize Azure Active Directory Groups to Adobe Identity Management**.

-11. Review the group attributes that are synchronized from Azure AD to Adobe Identity Management in the **Attribute-Mapping** section. The attributes selected as **Matching** properties are used to match the groups in Adobe Identity Management for update operations. Select the **Save** button to commit any changes.

- |Attribute|Type|

- |||

- |displayName|String|

- |members|Reference|

-12. To configure scoping filters, refer to the following instructions provided in the [Scoping filter tutorial](../app-provisioning/define-conditional-rules-for-provisioning-user-accounts.md).

-13. To enable the Azure AD provisioning service for Adobe Identity Management, change the **Provisioning Status** to **On** in the **Settings** section.

-14. Define the users and/or groups that you would like to provision to Adobe Identity Management by choosing the desired values in **Scope** in the **Settings** section.

-15. When you are ready to provision, click **Save**.

-1. Use the [provisioning logs](../reports-monitoring/concept-provisioning-logs.md) to determine which users have been provisioned successfully or unsuccessfully

-2. Check the [progress bar](../app-provisioning/application-provisioning-when-will-provisioning-finish-specific-user.md) to see the status of the provisioning cycle and how close it is to completion

-3. If the provisioning configuration seems to be in an unhealthy state, the application will go into quarantine. Learn more about quarantine states [here](../app-provisioning/application-provisioning-quarantine-status.md).

-## Additional resources

- |urn:ietf:params:scim:schemas:extension:enterprise:2.0:User:manager|String||

- |emails[type eq "work"].value|String||

-03/23/2022 - Added support for **Group Provisioning**.

-description: Learn how to configure single sign-on between Azure Active Directory and Kantega SSO for JIRA.

-# Tutorial: Azure Active Directory integration with Kantega SSO for JIRA

-In this tutorial, you'll learn how to integrate Kantega SSO for JIRA with Azure Active Directory (Azure AD). When you integrate Kantega SSO for JIRA with Azure AD, you can:

-* Control in Azure AD who has access to Kantega SSO for JIRA.

-* Enable your users to be automatically signed-in to Kantega SSO for JIRA with their Azure AD accounts.

-## Prerequisites

-To configure Azure AD integration with Kantega SSO for JIRA, you need the following items:

-* An Azure AD subscription. If you don't have an Azure AD environment, you can get a [free account](https://azure.microsoft.com/free/).

-* Kantega SSO for JIRA single sign-on enabled subscription.

-In this tutorial, you configure and test Azure AD single sign-on in a test environment.

-* Kantega SSO for JIRA supports **SP and IDP** initiated SSO.

-1. To add new application, select **New application**.

-1. Select **Kantega SSO for JIRA** from results panel and then add the app. Wait a few seconds while the app is added to your tenant.

-1. **[Configure Kantega SSO for JIRA SSO](#configure-kantega-sso-for-jira-sso)** - to configure the single sign-on settings on application side.

- 1. **[Create Kantega SSO for JIRA test user](#create-kantega-sso-for-jira-test-user)** - to have a counterpart of B.Simon in Kantega SSO for JIRA that is linked to the Azure AD representation of user.

- > These values are not real. Update these values with the actual Identifier, Reply URL, and Sign-On URL. These values are received during the configuration of Jira plugin, which is explained later in the tutorial.

- 1. Select the **Show password** check box, and then write down the value that's displayed in the **Password** box.

-1. If you are expecting a role to be assigned to the users, you can select it from the **Select a role** dropdown. If no role has been set up for this app, you see "Default Access" role selected.

-1. In a different web browser window, sign in to your JIRA on-premises server as an administrator.

-1. However on cog and click the **Add-ons**.

- 

-1. Under Add-ons tab section, click **Find new add-ons**. Search **Kantega SSO for JIRA (SAML & Kerberos)** and click **Install** button to install the new SAML plugin.

- 

-1. The plugin installation starts.

- 

-1. Once the installation is complete. Click **Close**.

- 

-1. Click **Manage**.

- 

-

-1. New plugin is listed under **INTEGRATIONS**. Click **Configure** to configure the new plugin.

- 

-1. In the **SAML** section. Select **Azure Active Directory (Azure AD)** from the **Add identity provider** dropdown.

- 

-1. Select subscription level as **Basic**.

- 

-1. On the **App properties** section, perform following steps:

- 

- 1. Copy the **App ID URI** value and use it as **Identifier, Reply URL, and Sign-On URL** on the **Basic SAML Configuration** section in Azure portal.

- 1. Click **Next**.

-1. On the **Metadata import** section, perform following steps:

- 

- 1. Select **Metadata file on my computer**, and upload metadata file, which you have downloaded from Azure portal.

- 1. Click **Next**.

-1. On the **Name and SSO location** section, perform following steps:

- 

- 1. Add Name of the Identity Provider in **Identity provider name** textbox (e.g Azure AD).

- 1. Click **Next**.

-1. Verify the Signing certificate and click **Next**.

- 

-1. On the **JIRA user accounts** section, perform following steps:

- 

- 1. Select **Create users in JIRA's internal Directory if needed** and enter the appropriate name of the group for users (can be multiple no. of groups separated by comma).

- 1. Click **Next**.

-1. Click **Finish**.

- 

-1. On the **Known domains for Azure AD** section, perform following steps:

- 

- 1. Select **Known domains** from the left panel of the page.

- 2. Enter domain name in the **Known domains** textbox.

- 3. Click **Save**.

-To enable Azure AD users to sign in to JIRA, they must be provisioned into JIRA. In Kantega SSO for JIRA, provisioning is a manual task.

-**To provision a user account, perform the following steps:**

-1. Sign in to your JIRA on-premises server as an administrator.

-1. Hover on cog and click the **User management**.

- 

-1. Under **User management** tab section, click **Create user**.

- 

-1. On the **ΓÇ£Create new userΓÇ¥** dialog page, perform the following steps:

- 

- 1. In the **Email address** textbox, type the email address of user like Brittasimon@contoso.com.

- 2. In the **Full Name** textbox, type full name of the user like Britta Simon.

- 3. In the **Username** textbox, type the email of user like Brittasimon@contoso.com.

- 4. In the **Password** textbox, type the password of user.

- 5. Click **Create user**.

-In this section, you test your Azure AD single sign-on configuration with following options.

-* Click on **Test this application** in Azure portal. This will redirect to Kantega SSO for JIRA Sign on URL where you can initiate the login flow.

-* Go to Kantega SSO for JIRA Sign-on URL directly and initiate the login flow from there.

-* Click on **Test this application** in Azure portal and you should be automatically signed in to the Kantega SSO for JIRA for which you set up the SSO.

-You can also use Microsoft My Apps to test the application in any mode. When you click the Kantega SSO for JIRA tile in the My Apps, if configured in SP mode you would be redirected to the application sign on page for initiating the login flow and if configured in IDP mode, you should be automatically signed in to the Kantega SSO for JIRA for which you set up the SSO. For more information about the My Apps, see [Introduction to the My Apps](https://support.microsoft.com/account-billing/sign-in-and-start-apps-from-the-my-apps-portal-2f3b1bae-0e5a-4a86-a33e-876fbd2a4510).

-Once you configure Kantega SSO for JIRA you can enforce session control, which protects exfiltration and infiltration of your organizationΓÇÖs sensitive data in real time. Session control extends from Conditional Access. [Learn how to enforce session control with Microsoft Defender for Cloud Apps](/cloud-app-security/proxy-deployment-aad).

-> * [Single sign-on](klaxoon-saml-tutorial.md) to Klaxoon (recommended).

-* Decommission access to apps that are no longer needed, or are not supported (for example, apps added by shadow IT processes). Also have an alarm for

-You require at least one Log Analytics workspace to support Container insights and to collect and analyze other telemetry about your AKS cluster. There is no cost for the workspace, but you do incur ingestion and retention costs when you collect data. See [Manage usage and costs with Azure Monitor Logs](../azure-monitor/logs/manage-cost-storage.md) for details.

-There is a cost for sending resource logs to a workspace, so you should only collect those log categories that you intend to use. Send logs to an Azure storage account to reduce costs if you need to retain the information but don't require it to be readily available for analysis. See [Resource logs](monitor-aks-reference.md#resource-logs) for a description of the categories that are available for AKS and [Manage usage and costs with Azure Monitor Logs](../azure-monitor/logs/manage-cost-storage.md) for details on the cost of ingesting and retaining log data. Start by collecting a minimal number of categories and then modify the diagnostic setting to collect additional categories as your needs increase and as you understand your associated costs.

-When a zone goes down, the App Service platform detects lost instances and automatically attempts to find new, replacement instances. If you also have autoscale configured, and if it determines that more instances are needed, autoscale also issues a request to App Service to add more instances. Autoscale behavior is independent of App Service platform behavior.

-Applications deployed in a zone redundant App Service Environment continue to run and serve traffic, even if other zones in the same region suffer an outage. It's possible, however, that non-runtime behaviors might still be affected by an outage in other availability zones. These behaviors might include the following: App Service plan scaling, application creation, application configuration, and application publishing. Zone redundancy for App Service Environment only ensures continued uptime for deployed applications.

-When the App Service platform allocates instances to a zone redundant App Service plan, it uses [best effort zone balancing offered by the underlying Azure virtual machine scale sets](../../virtual-machine-scale-sets/virtual-machine-scale-sets-use-availability-zones.md#zone-balancing). An App Service plan is considered balanced if each zone has either the same number of instances, or +/- 1 instance in all of the other zones used by the App Service plan.

- There is a minimum charge of nine App Service plan instances in a zone redundant App Service Environment. There is no added charge for availability zone support if you have nine or more instances. If you have fewer than nine instances (of any size) across App Service plans in the zone redundant App Service Environment, you're charged for the difference between nine and the running instance count. This charge is for additional Windows I1v2 instances.

-* For help troubleshooting Log Analytics, see [Troubleshooting why Log Analytics is no longer collecting data](../azure-monitor/logs/manage-cost-storage.md#troubleshooting-why-log-analytics-is-no-longer-collecting-data).

-* Manage [usage and costs with Azure Monitor Logs](../../azure-monitor/logs/manage-cost-storage.md) describes how to control your costs by changing your data retention period, and how to analyze and alert on your data usage.

-Change Tracking and Inventory forwards data to Azure Monitor Logs, and this collected data is stored in a Log Analytics workspace. The File Integrity Monitoring (FIM) feature is available only when **Microsoft Defender for servers** is enabled. See Microsoft Defender for Cloud [Pricing](../../security-center/security-center-pricing.md) to learn more. FIM uploads data to the same Log Analytics workspace as the one created to store data from Change Tracking and Inventory. We recommend that you monitor your linked Log Analytics workspace to keep track of your exact usage. For more information about analyzing Azure Monitor Logs data usage, see [Manage usage and cost](../../azure-monitor/logs/manage-cost-storage.md).

-The average Log Analytics data usage for a machine using Change Tracking and Inventory is approximately 40 MB per month, depending on your environment. With the Usage and Estimated Costs feature of the Log Analytics workspace, you can view the data ingested by Change Tracking and Inventory in a usage chart. Use this data view to evaluate your data usage and determine how it affects your bill. See [Understand your usage and estimate costs](../../azure-monitor/logs/manage-cost-storage.md#understand-your-usage-and-estimate-costs).

-* Manage [usage and costs with Azure Monitor Logs](../../azure-monitor/logs/manage-cost-storage.md) describes how to control your costs by changing your data retention period, and how to analyze and alert on your data usage.

-The average data usage by Azure Monitor logs for a machine using Update Management is approximately 25 MB per month. This value is only an approximation and is subject to change, depending on your environment. We recommend that you monitor your environment to keep track of your exact usage. For more information about analyzing Azure Monitor Logs data usage, see [Manage usage and cost](../../azure-monitor/logs/manage-cost-storage.md).

-> * The minimum supported version of Kubernetes is v1.19. For more information, see the "Known issues" section of [Release notes - Azure Arc-enabled data services](./release-notes.md#known-issues).

-> * The minimum supported version of OCP is 4.7.

->The `k8s-configuration` CLI extension has been upgraded to manage either Flux v2 or Flux v1 configurations. Flux v2 is an important upgrade to Flux v1, and eventually GitOps support for Flux v1 will cease. Begin using Flux v2 as soon as possible.

-False whl connectedk8s C:\Users\somename\.azure\cliextensions\connectedk8s False 1.2.0

-False whl k8s-configuration C:\Users\somename\.azure\cliextensions\k8s-configuration False 1.4.1

-False whl k8s-extension C:\Users\somename\.azure\cliextensions\k8s-extension False 1.0.4

-Use the `k8s-configuration` Azure CLI extension (or the Azure portal) to enable GitOps in an AKS or Arc-enabled Kubernetes cluster. For a demonstration, use the public [flux2-kustomize-helm-example](https://github.com/fluxcd/flux2-kustomize-helm-example) repository.

-* The name of the Flux configuration is `gitops-demo`.

-* The namespace for configuration installation is `gitops-demo`.

-* The URL for the public Git repository is `https://github.com/fluxcd/flux2-kustomize-helm-example`.

-If the `microsoft.flux` extension isn't already installed in the cluster, it will be installed.

-az k8s-configuration flux create -g flux-demo-rg -c flux-demo-arc -n gitops-demo --namespace gitops-demo -t connectedClusters --scope cluster -u https://github.com/fluxcd/flux2-kustomize-helm-example --branch main --kustomization name=infra path=./infrastructure prune=true --kustomization name=apps path=./apps/staging prune=true dependsOn=["infra"]

-Command group 'k8s-configuration flux' is in preview and under development. Reference and support levels: https://aka.ms/CLI_refstatus

-Warning! https url is being used without https auth params, ensure the repository url provided is not a private repo

-Creating the flux configuration 'gitops-demo' in the cluster. This may take a few minutes...

-Show the configuration after time to finish reconciliations.

-az k8s-configuration flux show -g flux-demo-rg -c flux-demo-arc -n gitops-demo -t connectedClusters

-Command group 'k8s-configuration flux' is in preview and under development. Reference and support levels: https://aka.ms/CLI_refstatus

- "httpsCaFile": null,

- "url": "https://github.com/fluxcd/flux2-kustomize-helm-example"

- "id": "/subscriptions/REDACTED/resourceGroups/flux-demo-rg/providers/Microsoft.Kubernetes/connectedClusters/flux-demo-arc/providers/Microsoft.KubernetesConfiguration/fluxConfigurations/gitops-demo",

- {

- "kustomizationName": "infra"

- }

- "dependsOn": [],

- "lastSourceSyncedAt": "2021-11-23T22:59:22+00:00",

- "lastSourceSyncedCommitId": "main/f0c2aaef48461d8099a8fff05893e9ebb96f1561",

- "name": "gitops-demo",

- "namespace": "gitops-demo",

- "resourceGroup": "flux-demo-rg",

- "name": "gitops-demo",

- "namespace": "gitops-demo",

- "lastTransitionTime": "2021-11-23T22:59:22+00:00",

- "message": "Fetched revision: main/f0c2aaef48461d8099a8fff05893e9ebb96f1561",

- "name": "gitops-demo-apps",

- "namespace": "gitops-demo",

- "lastTransitionTime": "2021-11-23T22:59:53+00:00",

- "message": "Applied revision: main/f0c2aaef48461d8099a8fff05893e9ebb96f1561",

- "name": "gitops-demo-apps",

- "namespace": "gitops-demo"

- "name": "podinfo-podinfo",

- "namespace": "flux-system"

- "namespace": "podinfo",

- "lastTransitionTime": "2021-11-23T22:59:54+00:00",

- "lastTransitionTime": "2021-11-23T22:59:54+00:00",

- "name": "gitops-demo-infra",

- "namespace": "gitops-demo",

- "lastTransitionTime": "2021-11-23T22:59:24+00:00",

- "message": "Applied revision: main/f0c2aaef48461d8099a8fff05893e9ebb96f1561",

- "name": "gitops-demo-infra",

- "namespace": "gitops-demo"

- "namespace": "flux-system",

- "lastTransitionTime": "2021-11-23T22:59:30+00:00",

- "message": "Fetched revision: 75dd8746b22e569460eb3b453b0ae22941c680b7",

- "name": "gitops-demo-infra",

- "namespace": "gitops-demo"

- "namespace": "flux-system",

- "lastTransitionTime": "2021-11-23T22:59:24+00:00",

- "message": "Fetched revision: fddc2924c28a1a1895e215a4dc065f33a0ea2e8e",

- "name": "gitops-demo-infra",

- "namespace": "gitops-demo"

- "name": "nginx-nginx",

- "namespace": "flux-system"

- "namespace": "nginx",

- "lastTransitionTime": "2021-11-23T23:00:10+00:00",

- "lastTransitionTime": "2021-11-23T23:00:10+00:00",

- "name": "gitops-demo-infra",

- "namespace": "gitops-demo"

- "name": "redis-redis",

- "namespace": "flux-system"

- "namespace": "redis",

- "lastTransitionTime": "2021-11-23T22:59:56+00:00",

- "lastTransitionTime": "2021-11-23T22:59:56+00:00",

- "createdAt": "2021-11-23T22:58:53.736245+00:00",

- "lastModifiedAt": "2021-11-23T22:58:53.736245+00:00",

-* `gitops-demo`: Holds the Flux configuration objects.

-NAME STATUS AGE

-azure-arc Active 17d

-default Active 17d

-flux-system Active 18m

-gitops-demo Active 17m

-kube-node-lease Active 17d

-kube-public Active 17d

-kube-system Active 17d

-nginx Active 17m

-podinfo Active 16m

-redis Active 17m

-The namespace `gitops-demo` has the Flux configuration objects.

-alerts.notification.toolkit.fluxcd.io 2021-11-23T22:57:49Z

-arccertificates.clusterconfig.azure.com 2021-11-06T15:12:36Z

-azureclusteridentityrequests.clusterconfig.azure.com 2021-11-06T15:12:36Z

-connectedclusters.arc.azure.com 2021-11-06T15:12:36Z

-customlocationsettings.clusterconfig.azure.com 2021-11-06T15:12:36Z

-extensionconfigs.clusterconfig.azure.com 2021-11-06T15:12:36Z

-fluxconfigs.clusterconfig.azure.com 2021-11-23T22:57:49Z

-gitconfigs.clusterconfig.azure.com 2021-11-06T15:12:36Z

-gitrepositories.source.toolkit.fluxcd.io 2021-11-23T22:57:49Z

-healthstates.azmon.container.insights 2021-11-06T14:45:55Z

-helmcharts.source.toolkit.fluxcd.io 2021-11-23T22:57:49Z

-helmreleases.helm.toolkit.fluxcd.io 2021-11-23T22:57:49Z

-helmrepositories.source.toolkit.fluxcd.io 2021-11-23T22:57:49Z

-kustomizations.kustomize.toolkit.fluxcd.io 2021-11-23T22:57:49Z

-providers.notification.toolkit.fluxcd.io 2021-11-23T22:57:49Z

-receivers.notification.toolkit.fluxcd.io 2021-11-23T22:57:49Z

-NAMESPACE NAME SCOPE URL PROVISION AGE

-gitops-demo gitops-demo cluster https://github.com/fluxcd/flux2-kustomize-helm-example Succeeded 22m

-NAMESPACE NAME URL READY STATUS AGE

-gitops-demo gitops-demo https://github.com/fluxcd/flux2-kustomize-helm-example True Fetched revision: main/f0c2aaef48461d8099a8fff05893e9ebb96f1561 22m

-NAMESPACE NAME READY STATUS AGE

-nginx nginx True Release reconciliation succeeded 6d4h

-podinfo podinfo True Release reconciliation succeeded 6d4h

-redis redis True Release reconciliation succeeded 6d4h

-NAMESPACE NAME READY STATUS AGE

-gitops-demo gitops-demo-apps True Applied revision: main/f0c2aaef48461d8099a8fff05893e9ebb96f1561 23m

-gitops-demo gitops-demo-infra True Applied revision: main/f0c2aaef48461d8099a8fff05893e9ebb96f1561 23m

-nginx-ingress-controller 1/1 1 1 25m

-nginx-ingress-controller-default-backend 1/1 1 1 25m

-podinfo 1/1 1 1 26m

-pod/redis-master-0 1/1 Running 0 95m

-service/redis-headless ClusterIP None <none> 6379/TCP 95m

-service/redis-master ClusterIP 10.0.180.63 <none> 6379/TCP 95m

-statefulset.apps/redis-master 1/1 95m

-az k8s-configuration flux delete -g flux-demo-rg -c flux-demo-arc -n gitops-demo -t connectedClusters --yes

- This command group is in preview and under development. Reference and support levels:

- https://aka.ms/CLI_refstatus

- create : Create a Flux v2 Kubernetes configuration.

- delete : Delete a Flux v2 Kubernetes configuration.

- list : List all Flux v2 Kubernetes configurations.

- show : Show a Flux v2 Kubernetes configuration.

- update : Update a Flux v2 Kubernetes configuration.

- Command group 'k8s-configuration flux' is in preview and under development. Reference

- and support levels: https://aka.ms/CLI_refstatus

- --local-auth-ref --local-ref : Local reference to a Kubernetes secret in the configuration

-You can use Application Insights without any custom configuration. The default configuration can result in high volumes of data. If you're using a Visual Studio Azure subscription, you might hit your data cap for Application Insights. To learn more about Application Insights costs, see [Manage usage and costs for Application Insights](../azure-monitor/app/pricing.md). For more information, see [Solutions with high-volume of telemetry](#solutions-with-high-volume-of-telemetry).

-If you enable Applications Insights during development, you might hit this limit during testing. Azure provides portal and email notifications when you're approaching your daily limit. If you miss those alerts and hit the limit, new logs won't appear in Application Insights queries. Be aware of the limit to avoid unnecessary troubleshooting time. For more information, see [Manage pricing and data volume in Application Insights](../azure-monitor/app/pricing.md).

-**Disclaimer:** Customers are wholly responsible for ensuring their own compliance with all applicable laws and regulations. Information provided in this article does not constitute legal advice, and customers should consult their legal advisors for any questions regarding regulatory compliance.

-|**Department of Commerce: </br> Bureau of Industry and Security (BIS)**|- Export Administration Act (EAA) of 1979 </br>- Export Administration Regulations (EAR)|- [P.L. 96-72](https://www.govinfo.gov/link/statute/93/503) </br>- [15 CFR Parts 730 ΓÇô 774](https://www.ecfr.gov/cgi-bin/text-idx?tpl=/ecfrbrowse/Title15/15cfrv2_02.tpl)|

-|**Department of State: </br> Directorate of Defense Trade Controls (DDTC)**|- Arms Export Control Act (AECA) </br>- International Traffic in Arms Regulations (ITAR)|- [22 U.S.C. 39](https://uscode.house.gov/view.xhtml?path=/prelim@title22/chapter39&edition=prelim) </br>- [22 CFR Parts 120 ΓÇô 130](https://www.ecfr.gov/cgi-bin/text-idx?tpl=/ecfrbrowse/Title22/22cfr120_main_02.tpl)|

-|**Department of Energy: </br> National Nuclear Security Administration (NNSA)**|- Atomic Energy Act of 1954 (AEA) </br>- Assistance to Foreign Atomic Energy Activities|- [42 U.S.C. 2011 et. seq.](https://www.govinfo.gov/content/pkg/USCODE-2010-title42/html/USCODE-2010-title42-chap23-divsnA.htm) </br>- [10 CFR Part 810](https://www.ecfr.gov/cgi-bin/text-idx?tpl=/ecfrbrowse/Title10/10cfr810_main_02.tpl)|

-|**Nuclear Regulatory Commission (NRC)**|- Nuclear Non-Proliferation Act of 1978 </br>- Export and Import of Nuclear Equipment and Materials|- [P.L. 95-242](https://www.govinfo.gov/content/pkg/STATUTE-92/pdf/STATUTE-92-Pg120.pdf) </br>- [10 CFR Part 110](https://www.ecfr.gov/cgi-bin/text-idx?tpl=/ecfrbrowse/Title10/10cfr110_main_02.tpl)|

-|**Department of Treasury: </br> Office of Foreign Assets Control (OFAC)**|- Trading with the Enemy Act (TWEA) </br>- Foreign Assets Control Regulations|- [50 U.S.C. Sections 5 and 16](https://www.govinfo.gov/content/pkg/USCODE-2009-title50/pdf/USCODE-2009-title50-app-tradingwi.pdf) </br>- [31 CFR Part 500](http://www.ecfr.gov/cgi-bin/text-idx?tpl=/ecfrbrowse/Title31/31cfrv3_02.tpl)|

-The US Department of Commerce is responsible for enforcing the [Export Administration Regulations](https://www.bis.doc.gov/index.php/regulations/export-administration-regulations-ear) (EAR) through the [Bureau of Industry and Security](https://www.bis.doc.gov/) (BIS). According to BIS [definitions](https://www.bis.doc.gov/index.php/documents/regulation-docs/412-part-734-scope-of-the-export-administration-regulations/file), export is the transfer of protected technology or information to a foreign destination or release of protected technology or information to a foreign person in the United States (also known as deemed export). Items subject to the EAR can be found on the [Commerce Control List](https://www.bis.doc.gov/index.php/regulations/commerce-control-list-ccl) (CCL), and each item has a unique [Export Control Classification Number](https://www.bis.doc.gov/index.php/licensing/commerce-control-list-classification/export-control-classification-number-eccn) (ECCN) assigned. Items not listed on the CCL are designated as EAR99 and most EAR99 commercial products do not require a license to be exported. However, depending on the destination, end user, or end use of the item, even an EAR99 item may require a BIS export license.

-The EAR is applicable to dual-use items that have both commercial and military applications and to items with purely commercial application. The BIS has provided guidance that cloud service providers (CSP) are not exporters of customersΓÇÖ data due to the customersΓÇÖ use of cloud services. Moreover, in the [final rule](https://www.federalregister.gov/documents/2016/06/03/2016-12734/revisions-to-definitions-in-the-export-administration-regulations) published on 3 June 2016, BIS clarified that EAR licensing requirements would not apply if the transmission and storage of unclassified technical data and software were encrypted end-to-end using Federal Information Processing Standard (FIPS) 140 validated cryptographic modules and not intentionally stored in a military-embargoed country (that is, Country Group D:5 as described in [Supplement No. 1 to Part 740](https://ecfr.io/Title-15/pt15.2.740#ap15.2.740_121.1) of the EAR) or in the Russian Federation. The US Department of Commerce has made it clear that, when data or software is uploaded to the cloud, the customer, not the cloud provider, is the ΓÇ£exporterΓÇ¥ who has the responsibility to ensure that transfers, storage, and access to that data or software complies with the EAR.

-Both Azure and Azure Government can help you meet your EAR compliance requirements. Except for the Azure region in Hong Kong SAR, Azure and Azure Government datacenters are not located in proscribed countries or in the Russian Federation. Azure and Azure Government rely on FIPS 140 validated cryptographic modules in the underlying operating system, and provide you with a [wide range of options for encrypting data](../security/fundamentals/encryption-overview.md) in transit and at rest, including encryption key management using [Azure Key Vault](../key-vault/general/overview.md), which can store encryption keys in FIPS 140 validated hardware security modules (HSMs) under your control - known as [customer-managed keys (CMK)](../security/fundamentals/encryption-models.md). Keys generated inside the Azure Key Vault HSMs are not exportable ΓÇô there can be no clear-text version of the key outside the HSMs. This binding is enforced by the underlying HSM. Moreover, Azure Key Vault is designed, deployed, and operated such that Microsoft and its agents do not see or extract your keys.

-You are responsible for choosing Azure or Azure Government regions for deploying your applications and data. Moreover, you are responsible for designing your applications to apply end-to-end data encryption that meets EAR requirements. Microsoft does not inspect, approve, or monitor your applications deployed on Azure or Azure Government.

-Azure Government provides you with an extra layer of protection through contractual commitments regarding storage of your data in the United States and limiting potential access to systems processing your data to [screened US persons](./documentation-government-plan-security.md#screening). For more information about Azure support for EAR, see [Azure EAR compliance offering](/azure/compliance/offerings/offering-ear).

-The US Department of State has export control authority over defense articles, services, and related technologies under the [International Traffic in Arms Regulations](https://www.ecfr.gov/cgi-bin/text-idx?SID=8870638858a2595a32dedceb661c482c&mc=true&tpl=/ecfrbrowse/Title22/22CIsubchapM.tpl) (ITAR) managed by the [Directorate of Defense Trade Controls](http://www.pmddtc.state.gov/) (DDTC). Items under ITAR protection are documented on the [United States Munitions List](https://www.ecfr.gov/current/title-22/part-121) (USML). Customers who are manufacturers, exporters, and brokers of defense articles, services, and related technologies as defined on the USML must be registered with DDTC, must understand and abide by ITAR, and must self-certify that they operate in accordance with ITAR.

-DDTC [revised the ITAR rules](https://www.federalregister.gov/documents/2019/12/26/2019-27438/international-traffic-in-arms-regulations-creation-of-definition-of-activities-that-are-not-exports) effective 25 March 2020 to align them more closely with the EAR. These ITAR revisions introduced an end-to-end data encryption carve-out that incorporated many of the same terms that the Commerce Department adopted in 2016 for the EAR. Specifically, the revised ITAR rules state that activities that do not constitute exports, re-exports, re-transfers, or temporary imports include (among other activities) the sending, taking, or storing of technical data that is 1) unclassified, 2) secured using end-to-end encryption, 3) secured using FIPS 140 compliant cryptographic modules as prescribed in the regulations, 4) not intentionally sent to a person in or stored in a [country proscribed in § 126.1](https://ecfr.io/Title-22/pt22.1.126#se22.1.126_11) or the Russian Federation, and 5) not sent from a country proscribed in § 126.1 or the Russian Federation. Moreover, DDTC clarified that data in-transit via the Internet is not deemed to be stored. End-to-end encryption implies the data is always kept encrypted between the originator and intended recipient, and the means of decryption is not provided to any third party.

-There is no ITAR compliance certification; however, both Azure and Azure Government can help you meet your ITAR compliance obligations. Except for the Azure region in Hong Kong SAR, Azure and Azure Government datacenters are not located in proscribed countries or in the Russian Federation. Azure and Azure Government rely on FIPS 140 validated cryptographic modules in the underlying operating system, and provide you with a [wide range of options for encrypting data](../security/fundamentals/encryption-overview.md) in transit and at rest, including encryption key management using [Azure Key Vault](../key-vault/general/overview.md), which can store encryption keys in FIPS 140 validated hardware security modules (HSMs) under your control - known as [customer-managed keys (CMK)](../security/fundamentals/encryption-models.md). Keys generated inside the Azure Key Vault HSMs are not exportable ΓÇô there can be no clear-text version of the key outside the HSMs. This binding is enforced by the underlying HSM. Moreover, Azure Key Vault is designed, deployed, and operated such that Microsoft and its agents do not see or extract your keys.

-You are responsible for choosing Azure or Azure Government regions for deploying your applications and data. Moreover, you are responsible for designing your applications to apply end-to-end data encryption that meets ITAR requirements. Microsoft does not inspect, approve, or monitor your applications deployed on Azure or Azure Government.

-Azure Government provides you with an extra layer of protection through contractual commitments regarding storage of your data in the United States and limiting potential access to systems processing your data to [screened US persons](./documentation-government-plan-security.md#screening). For more information about Azure support for ITAR, see [Azure ITAR compliance offering](/azure/compliance/offerings/offering-itar).

-The US Department of Energy (DoE) export control regulation [10 CFR Part 810](http://www.gpo.gov/fdsys/pkg/FR-2015-02-23/pdf/2015-03479.pdf) implements section 57b.(2) of the [Atomic Energy Act of 1954](https://www.nrc.gov/docs/ML1327/ML13274A489.pdf) (AEA), as amended by section 302 of the [Nuclear Nonproliferation Act of 1978](http://www.nrc.gov/docs/ML1327/ML13274A492.pdf#page=19) (NNPA). It is administered by the [National Nuclear Security Administration](https://www.energy.gov/nnsa/national-nuclear-security-administration) (NNSA). The revised Part 810 (final rule) became effective on 25 March 2015, and, among other things, it controls the export of unclassified nuclear technology and assistance. It enables peaceful nuclear trade by helping to assure that nuclear technologies exported from the United States will not be used for non-peaceful purposes. Paragraph 810.7 (b) states that specific DoE authorization is required for providing or transferring sensitive nuclear technology to any foreign entity.

-**Azure Government can help you meet your DoE 10 CFR Part 810 export control requirements** because it is designed to implement specific controls that restrict access to information and systems to [US persons](./documentation-government-plan-security.md#screening) among Azure operations personnel. If you are deploying data to Azure Government, you are responsible for your own security classification process. For data subject to DoE export controls, the classification system is augmented by the [Unclassified Controlled Nuclear Information](https://www.energy.gov/sites/prod/files/hss/Classification/docs/UCNI-Tri-fold.pdf) (UCNI) controls established by Section 148 of the AEA. For more information about Azure support for DoE 10 CFR Part 810, see [Azure DoE 10 CFR Part 810 compliance offering](/azure/compliance/offerings/offering-doe-10-cfr-part-810).

-The [Nuclear Regulatory Commission](https://www.nrc.gov/) (NRC) is responsible for the [Export and Import of Nuclear Equipment and Materials](https://www.nrc.gov/about-nrc/ip/export-import.html) under the [10 CFR Part 110](https://www.gpo.gov/fdsys/pkg/FR-2015-02-23/pdf/2015-03479.pdf) export control regulations. The NRC regulates the export and import of nuclear facilities and related equipment and materials. The NRC does not regulate nuclear technology and assistance related to these items, which are under the DoE jurisdiction. Therefore, the **NRC 10 CFR Part 110 regulations would not be applicable** to Azure or Azure Government.

-The [Office of Foreign Assets Control](https://www.treasury.gov/about/organizational-structure/offices/Pages/Office-of-Foreign-Assets-Control.aspx) (OFAC) is responsible for administering and enforcing economic and trade sanctions based on US foreign policy and national security goals against targeted foreign countries, terrorists, international narcotics traffickers, and those entities engaged in activities related to the proliferation of weapons of mass destruction.

-The OFAC defines prohibited transactions as trade or financial transactions and other dealings in which US persons may not engage unless authorized by OFAC or expressly exempted by statute. For web-based interactions, see [FAQ No. 73](https://home.treasury.gov/policy-issues/financial-sanctions/faqs/73) for general guidance released by OFAC, which specifies for example that &#8220;Firms that facilitate or engage in e-commerce should do their best to know their customers directly.&#8221;

-As stated in the Microsoft Online Services Terms [Data Protection Addendum](https://aka.ms/dpa) (DPA), &#8220;Microsoft does not control or limit the regions from which customer or customerΓÇÖs end users may access or move customer data.&#8221; For Microsoft online services, Microsoft conducts due diligence to prevent transactions with entities from OFAC embargoed countries, for example, a sanctions target is not allowed to provision Azure services. OFAC has not issued guidance (like the guidance provided by BIS for the EAR) that draws a distinction between cloud service providers and customers when it comes to deemed export. Therefore, it would be **your responsibility to exclude sanctions targets from online transactions** involving your applications (including web sites) deployed on Azure. Microsoft does not block network traffic to your web sites deployed on Azure. Even though OFAC mentions that customers can restrict access based in IP table ranges, they also acknowledge that this approach does not fully address an internetΓÇÖs firm compliance risks. Therefore, OFAC recommends that e-commerce firms should know their customers directly. Microsoft is not responsible for and does not have the means to know directly the end users that interact with your applications deployed on Azure.

-OFAC sanctions are in place to prevent &#8220;conducting business with a sanctions target&#8221;, that is, preventing transactions involving trade, payments, financial instruments, and so on. OFAC sanctions are not intended to prevent a resident of a proscribed country from viewing a public web site.

-You should assess carefully how your use of Azure may implicate US export controls and determine whether any of the data you want to store or process in the cloud may be subject to export controls. Microsoft provides you with contractual commitments, operational processes, and technical features to help you meet your export control obligations when using Azure. The following Azure features are available to help you manage potential export control risks:

-Microsoft provides [strong customer commitments](https://www.microsoft.com/trust-center/privacy/data-location) regarding [cloud services data residency and transfer policies](https://azure.microsoft.com/global-infrastructure/data-residency/). Most Azure services are deployed regionally and enable you to specify the region into which the service will be deployed, for example, United States. This commitment helps ensure that [customer data](https://www.microsoft.com/trust-center/privacy/customer-data-definitions) stored in a US region will remain in the United States and will not be moved to another region outside the United States.

-The [Federal Information Processing Standard (FIPS) 140](https://csrc.nist.gov/publications/detail/fips/140/2/final) is a US government standard that defines minimum security requirements for cryptographic modules in information technology products. The current version of the standard, FIPS 140-2, has security requirements covering 11 areas related to the design and implementation of a cryptographic module. Microsoft maintains an active commitment to meeting the [FIPS 140 requirements](/azure/compliance/offerings/offering-fips-140-2), having validated cryptographic modules since the standardΓÇÖs inception in 2001. Microsoft validates its cryptographic modules under the US National Institute of Standards and Technology (NIST) [Cryptographic Module Validation Program](https://csrc.nist.gov/Projects/cryptographic-module-validation-program) (CMVP). Multiple Microsoft products, including many cloud services, use these cryptographic modules.

-Azure SQL Database provides [transparent data encryption](../azure-sql/database/transparent-data-encryption-tde-overview.md) (TDE) at rest by [default](https://azure.microsoft.com/updates/newly-created-azure-sql-databases-encrypted-by-default/). TDE performs real-time encryption and decryption operations on the data and log files. Database Encryption Key (DEK) is a symmetric key stored in the database boot record for availability during recovery. It is secured via a certificate stored in the master database of the server or an asymmetric key called TDE Protector stored under your control in [Azure Key Vault](../key-vault/general/security-features.md). Key Vault supports [bring your own key](../azure-sql/database/transparent-data-encryption-byok-overview.md) (BYOK), which enables you to store the TDE Protector in Key Vault and control key management tasks including key rotation, permissions, deleting keys, enabling auditing/reporting on all TDE Protectors, and so on. The key can be generated by the Key Vault, imported, or [transferred to the Key Vault from an on-premises HSM device](../key-vault/keys/hsm-protected-keys.md). You can also use the [Always Encrypted](../azure-sql/database/always-encrypted-azure-key-vault-configure.md) feature of Azure SQL Database, which is designed specifically to help protect sensitive data by allowing you to encrypt data inside your applications and [never reveal the encryption keys to the database engine](/sql/relational-databases/security/encryption/always-encrypted-database-engine). In this manner, Always Encrypted provides separation between those users who own the data (and can view it) and those users who manage the data (but should have no access).

-* It's possible that you're hitting a [data rate limit](../../azure-monitor/app/pricing.md#limits-summary) for your pricing plan. These limits are applied per minute.

-* [Commitment Tiers](../logs/manage-cost-storage.md#pricing-model) enable you to save as much as 30% compared to the Pay-As-You-Go price. Otherwise, Pay-as-you-go data ingestion and data retention are billed similarly in Log Analytics as they are in Application Insights.

-Your classic resource data will persist and be subject to the retention settings on your classic Application Insights resource. All new data ingested post migration will be subject to the [retention settings](../logs/manage-cost-storage.md#change-the-data-retention-period) of the associated Log Analytics workspace, which also supports [different retention settings by data type](../logs/manage-cost-storage.md#retention-by-data-type).

-> After migrating to a workspace-based Application Insights resource we recommend using the [workspace's daily cap](../logs/manage-cost-storage.md#manage-your-maximum-daily-data-volume) to limit ingestion and costs instead of the cap in Application Insights.

-> Data ingestion and retention for workspace-based Application Insights resources are billed through the Log Analytics workspace where the data is located. [Learn more]( ./pricing.md#workspace-based-application-insights) about billing for workspace-based Application Insights resources.

-* [Commitment Tiers](../logs/manage-cost-storage.md#pricing-model) enable you to save as much as 30% compared to the Pay-As-You-Go price.

-Raw data points (that is, items that you can query in Analytics and inspect in Search) are kept for up to 730 days. You can [select a retention duration](./pricing.md#change-the-data-retention-period) of 30, 60, 90, 120, 180, 270, 365, 550 or 730 days. If you need to keep data longer than 730 days, you can use [Continuous Export](./export-telemetry.md) to copy it to a storage account during data ingestion.

-* [Pricing](./pricing.md) - You can get started for free, and that continues while you're in low volume.

-See the [Limits summary](./pricing.md#limits-summary).

-|**Free**|There is no charge for Live Stream data|Subject to [pricing](./pricing.md)

-This article shows you how to automate the creation and update of [Application Insights](./app-insights-overview.md) resources automatically by using Azure Resource Management. You might, for example, do so as part of a build process. Along with the basic Application Insights resource, you can create [availability web tests](./monitor-web-app-availability.md), set up [alerts](../alerts/alerts-log.md), set the [pricing scheme](pricing.md), and create other Azure resources.

-All metrics that you send using [trackMetric](./api-custom-events-metrics.md#trackmetric) or [GetMetric and TrackValue](./api-custom-events-metrics.md#getmetric) API calls are automatically stored in both logs and metrics stores. However, while the log-based version of your custom metric always retains all dimensions, the pre-aggregated version of the metric is stored by default with no dimensions. You can turn on collection of dimensions of custom metrics on the [usage and estimated cost](./pricing.md) tab by checking "Enable alerting on custom metric dimensions":

-Ingesting metrics into Application Insights, whether log-based or pre-aggregated, will generate costs based on the size of the ingested data, as described [here](./pricing.md#pricing-model). Your custom metrics, including all its dimensions, are always stored in the Application Insights log-store; additionally, a pre-aggregated version of your custom metrics (with no dimensions) is forwarded to the metrics store by default.

-description: Manage telemetry volumes and monitor costs in Application Insights.

-# Manage usage and costs for Application Insights

-This article describes how to proactively monitor and control Application Insights costs.

-[Monitoring usage and estimated costs](..//usage-estimated-costs.md) describes usage and estimated costs across Azure Monitor features using [Azure Cost Management + Billing](../logs/manage-cost-storage.md#viewing-log-analytics-usage-on-your-azure-bill).

-> [!NOTE]

-> All prices and costs in this article are for example purposes only.

-<! App Insights monitoring features (availability, performance, usage, etc. ) Supported languages, integration with specific tools (Azure DevOps, Jira, and PagerDuty, etc.) should be documented elsewhere. (e.g. platforms.md) -->

-If you have questions about how pricing works for Application Insights, you can post a question in our [Microsoft Q&A question page](/answers/topics/azure-monitor.html).

-## Pricing model

-The pricing for [Azure Application Insights][start] is a **Pay-As-You-Go** model based on data volume ingested and optionally for longer data retention. Each Application Insights resource is charged as a separate service and contributes to the bill for your Azure subscription. Data volume is measured as the size of the uncompressed JSON data package that's received by Application Insights from your application. Data volume is measured in GB (10^9 bytes). There's no data volume charge for using the [Live Metrics Stream](./live-stream.md). On your Azure bill or in [Azure Cost Management + Billing](../logs/manage-cost-storage.md#viewing-log-analytics-usage-on-your-azure-bill), your data ingestion and data retention for a classic Application Insights resource will be reported with a meter category of **Log Analytics**.

-[Multi-step web tests](./availability-multistep.md) incur extra charges. Multi-step web tests are web tests that perform a sequence of actions. There's no separate charge for *ping tests* of a single page. Telemetry from ping tests and multi-step tests is charged the same as other telemetry from your app.

-The Application Insights option to [Enable alerting on custom metric dimensions](./pre-aggregated-metrics-log-metrics.md#custom-metrics-dimensions-and-pre-aggregation) can also increase costs because this can result in the creation of more pre-aggregation metrics. [Learn more](./pre-aggregated-metrics-log-metrics.md) about log-based and pre-aggregated metrics in Application Insights and about [pricing](https://azure.microsoft.com/pricing/details/monitor/) for Azure Monitor custom metrics.

-### Workspace-based Application Insights

-For Application Insights resources which send their data to a Log Analytics workspace, called [workspace-based Application Insights resources](create-workspace-resource.md), the billing for data ingestion and retention is done by the workspace where the Application Insights data is located. This enables you to leverage all options of the Log Analytics [pricing model](../logs/manage-cost-storage.md#pricing-model), including **Commitment Tiers** in addition to Pay-As-You-Go. Commitment Tiers offer pricing up to 30% lower than Pay-As-You-Go. Log Analytics also has more options for data retention, including [retention by data type](../logs/manage-cost-storage.md#retention-by-data-type). Application Insights data types in the workspace receive 90 days of retention without charges. Usage of web tests and enabling alerting on custom metric dimensions is still reported through Application Insights. Learn how to track data ingestion and retention costs in Log Analytics using the [Usage and estimated costs](../logs/manage-cost-storage.md#understand-your-usage-and-estimate-costs), [Azure Cost Management + Billing](../logs/manage-cost-storage.md#viewing-log-analytics-usage-on-your-azure-bill) and [Log Analytics queries](#data-volume-for-workspace-based-application-insights-resources).

-## Estimating the costs to manage your application

-If you're not yet using Application Insights, you can use the [Azure Monitor pricing calculator](https://azure.microsoft.com/pricing/calculator/?service=monitor) to estimate the cost of using Application Insights. Start by entering "Azure Monitor" in the Search box, and clicking on the resulting Azure Monitor tile. Scroll down the page to Azure Monitor, and expand the Application Insights section. Your estimated costs depend on the amount of log data ingested. There are two approaches to estimate data volumes:

-1. estimate your likely data ingestion based on what other similar applications generate, or

-2. use of default monitoring and adaptive sampling, which is available in the ASP.NET SDK.

-### Learn from what similar applications collect

-In the Azure Monitoring Pricing calculator for Application Insights, click to enable the **Estimate data volume based on application activity**. Here you can provide inputs about your application (requests per month and page views per month, in case you'll collect client-side telemetry), and then the calculator will tell you the median and 90th percentile amount of data collected by similar applications. These applications span the range of Application Insights configuration (e.g some have default [sampling](./sampling.md), some have no sampling etc.), so you still have the control to reduce the volume of data you ingest far below the median level using sampling.

-### Data collection when using sampling

-With the ASP.NET SDK's [adaptive sampling](sampling.md#adaptive-sampling), the data volume is adjusted automatically to keep within a specified maximum rate of traffic for default Application Insights monitoring. If the application produces a low amount of telemetry, such as when debugging or due to low usage, items won't be dropped by the sampling processor as long as volume is below the configured events per second level. For a high volume application, with the default threshold of five events per second, adaptive sampling will limit the number of daily events to 432,000. Considering a typical average event size of 1 KB, this corresponds to 13.4 GB of telemetry per 31-day month per node hosting your application since the sampling is done local to each node.

-For SDKs that don't support adaptive sampling, you can employ [ingestion sampling](./sampling.md#ingestion-sampling), which samples when the data is received by Application Insights based on a percentage of data to retain, or [fixed-rate sampling for ASP.NET, ASP.NET Core, and Java websites](sampling.md#fixed-rate-sampling) to reduce the traffic sent from your web server and web browsers

-## Viewing Application Insights usage on your Azure bill

-The easiest way to see the billed usage for a single Application Insights resource, which isn't a workspace-based resource is to go to the resource's Overview page and click **View Cost** in the upper right corner. You might need elevated access to Cost Management data ([learn more](../../cost-management-billing/costs/assign-access-acm-data.md)).

-To learn more, Azure provides a great deal of useful functionality in the [Azure Cost Management + Billing](../../cost-management-billing/costs/quick-acm-cost-analysis.md?toc=/azure/billing/TOC.json) hub. For instance, the "Cost analysis" functionality enables you to view your spends for Azure resources. Adding a filter by resource type (to microsoft.insights/components for Application Insights) will allow you to track your spending. Then for "Group by" select "Meter category" or "Meter". Application Insights billed usage for data ingestion and data retention will show up as **Log Analytics** for the Meter category since Log Analytics backend for all Azure Monitor logs.

-> [!NOTE]

-> Application Insights billing for data ingestion and data retention is reported as coming from the **Log Analytics** service (Meter category in Azure Cost Management + Billing).

-Even more understanding of your usage can be gained by [downloading your usage from the Azure portal](../../cost-management-billing/understand/download-azure-daily-usage.md).

-In the downloaded spreadsheet, you can see usage per Azure resource per day. In this Excel spreadsheet, usage from your Application Insights resources can be found by first filtering on the "Meter Category" column to show "Application Insights" and "Log Analytics", and then adding a filter on the "Instance ID" column, which is "contains microsoft.insights/components". Most Application Insights usage is reported on meters with the Meter Category of Log Analytics, since there's a single logs backend for all Azure Monitor components. Only Application Insights resources on legacy pricing tiers and multi-step web tests are reported with a Meter Category of Application Insights. The usage is shown in the "Consumed Quantity" column and the unit for each entry is shown in the "Unit of Measure" column. More details are available to help you [understand your Microsoft Azure bill](../../cost-management-billing/understand/review-individual-bill.md).

-## Understand your usage and optimizing your costs

-<a name="understand-your-usage-and-estimate-costs"></a>

-Application Insights makes it easy to understand what your costs are likely to be based on recent usage patterns. To get started, in the Azure portal, for the Application Insights resource, go to the **Usage and estimated costs** page:

-

-A. Review your data volume for the month. This includes all the data that's received and retained (after any [sampling](./sampling.md)) from your server and client apps, and from availability tests.

-B. A separate charge is made for [Multi-step web tests](./availability-multistep.md). (This doesn't include simple availability tests, which are included in the data volume charge.)

-C. View data volume trends for the past month.

-D. Enable data ingestion [sampling](./sampling.md).

-E. Set the daily data volume cap.

-(All prices displayed in screenshots in this article are for example purposes only. For current prices in your currency and region, see [Application Insights pricing][pricing].)

-To investigate your Application Insights usage more deeply, open the **Metrics** page, add the metric named "Data point volume", and then select the *Apply splitting* option to split the data by "Telemetry item type".

-Application Insights charges are added to your Azure bill. You can see details of your Azure bill in the **Cost Management + Billing** section of the Azure portal, or in the [Azure billing portal](https://account.windowsazure.com/Subscriptions). [See below](#viewing-application-insights-usage-on-your-azure-bill) for details on using this for Application Insights.

-

-### Using data volume metrics

-<a id="understanding-ingested-data-volume"></a>

-To learn more about your data volumes, selecting **Metrics** for your Application Insights resource, add a new chart. For the chart metric, under **Log-based metrics**, select **Data point volume**. Click **Apply splitting**, and select group by **`Telemetryitem` type**.

-

-### Queries to understand data volume details

-There are two approaches to investigating data volumes for Application Insights. The first uses aggregated information in the `systemEvents` table, and the second uses the `_BilledSize` property, which is available on each ingested event. `systemEvents` won't have data size information for [workspace-based-application-insights](#data-volume-for-workspace-based-application-insights-resources).

-#### Using aggregated data volume information

-For instance, you can use the `systemEvents` table to see the data volume ingested in the last 24 hours with the query:

-```kusto

-systemEvents

-| where timestamp >= ago(24h)

-| where type == "Billing"

-| extend BillingTelemetryType = tostring(dimensions["BillingTelemetryType"])

-| extend BillingTelemetrySizeInBytes = todouble(measurements["BillingTelemetrySize"])

-| summarize sum(BillingTelemetrySizeInBytes)

-```

-Or to see a chart of data volume (in bytes) by data type for the last 30 days, you can use:

-```kusto

-systemEvents

-| where timestamp >= startofday(ago(30d))

-| where type == "Billing"

-| extend BillingTelemetryType = tostring(dimensions["BillingTelemetryType"])

-| extend BillingTelemetrySizeInBytes = todouble(measurements["BillingTelemetrySize"])

-| summarize sum(BillingTelemetrySizeInBytes) by BillingTelemetryType, bin(timestamp, 1d) | render barchart

-```

-This query can be used in an [Azure Log Alert](../alerts/alerts-unified-log.md) to set up alerting on data volumes.

-To learn more about your telemetry data changes, we can get the count of events by type using the query:

-```kusto

-systemEvents

-| where timestamp >= startofday(ago(30d))

-| where type == "Billing"

-| extend BillingTelemetryType = tostring(dimensions["BillingTelemetryType"])

-| summarize count() by BillingTelemetryType, bin(timestamp, 1d)

-| render barchart

-```

-#### Using data size per event information

-To learn more details about the source of your data volumes, you can use the `_BilledSize` property that is present on each ingested event.

-For example, to look at which operations generate the most data volume in the last 30 days, we can sum `_BilledSize` for all dependency events:

-```kusto

-dependencies

-| where timestamp >= startofday(ago(30d))

-| summarize sum(_BilledSize) by operation_Name

-| render barchart

-```

-#### Data volume for workspace-based Application Insights resources

-To look at the data volume trends for all of the [workspace-based Application Insights resources](create-workspace-resource.md) in a workspace for the last week, go to the Log Analytics workspace and run the query:

-```kusto

-union (AppAvailabilityResults),

- (AppBrowserTimings),

- (AppDependencies),

- (AppExceptions),

- (AppEvents),

- (AppMetrics),

- (AppPageViews),

- (AppPerformanceCounters),

- (AppRequests),

- (AppSystemEvents),

- (AppTraces)

-| where TimeGenerated >= startofday(ago(7d)) and TimeGenerated < startofday(now())

-| summarize sum(_BilledSize) by _ResourceId, bin(TimeGenerated, 1d)

-| render areachart

-```

-To query the data volume trends by type for a specific workspace-based Application Insights resource, in the Log Analytics workspace use:

-```kusto

-union (AppAvailabilityResults),

- (AppBrowserTimings),

- (AppDependencies),

- (AppExceptions),

- (AppEvents),

- (AppMetrics),

- (AppPageViews),

- (AppPerformanceCounters),

- (AppRequests),

- (AppSystemEvents),

- (AppTraces)

-| where TimeGenerated >= startofday(ago(7d)) and TimeGenerated < startofday(now())

-| where _ResourceId contains "<myAppInsightsResourceName>"

-| summarize sum(_BilledSize) by Type, bin(TimeGenerated, 1d)

-| render areachart

-```

-## Managing your data volume

-The volume of data you send can be managed using the following techniques:

-* **Sampling**: You can use sampling to reduce the amount of telemetry that's sent from your server and client apps, with minimal distortion of metrics. Sampling is the primary tool you can use to tune the amount of data you send. Learn more about [sampling features](./sampling.md).

-* **Limit Ajax calls**: You can [limit the number of Ajax calls that can be reported](./javascript.md#configuration) in every page view, or switch off Ajax reporting. Disabling Ajax calls will disable [JavaScript correlation](./javascript.md#enable-correlation).

-* **Disable unneeded modules**: [Edit ApplicationInsights.config](./configuration-with-applicationinsights-config.md) to turn off collection modules that you don't need. For example, you might decide that performance counters or dependency data are inessential.

-* **Pre-aggregate metrics**: If you put calls to TrackMetric in your app, you can reduce traffic by using the overload that accepts your calculation of the average and standard deviation of a batch of measurements. Or, you can use a [pre-aggregating package](https://www.myget.org/gallery/applicationinsights-sdk-labs).

-

-* **Daily cap**: When you create an Application Insights resource in the Azure portal, the daily cap is set to 100 GB/day. When you create an Application Insights resource in Visual Studio, the default is small (only 32.3 MB/day). The daily cap default is set to facilitate testing. It's intended that the user will raise the daily cap before deploying the app into production.

- The maximum cap in Application Insights is 1,000 GB/day unless you request a higher maximum for a high-traffic application.

-

- > [!TIP]

- > If you have a workspace-based Application Insights resource, we recommend using the [workspace's daily cap](../logs/manage-cost-storage.md#manage-your-maximum-daily-data-volume) to limit ingestion and costs instead of the cap in Application Insights.

- Warning emails about the daily cap are sent to account that are members of these roles for your Application Insights resource: "ServiceAdmin", "AccountAdmin", "CoAdmin", "Owner".

- Use care when you set the daily cap. Your intent should be to *never hit the daily cap*. If you hit the daily cap, you lose data for the remainder of the day, and you can't monitor your application. To change the daily cap, use the **Daily volume cap** option. You can access this option in the **Usage and estimated costs** pane (this is described in more detail later in the article).

-

- We've removed the restriction on some subscription types that have credit that couldn't be used for Application Insights. Previously, if the subscription has a spending limit, the daily cap dialog has instructions to remove the spending limit and enable the daily cap to be raised beyond 32.3 MB/day.

-

-* **Throttling**: Throttling limits the data rate to 32,000 events per second, averaged over 1 minute per instrumentation key. The volume of data that your app sends is assessed every minute. If it exceeds the per-second rate averaged over the minute, the server refuses some requests. The SDK buffers the data and then tries to resend it. It spreads out a surge over several minutes. If your app consistently sends data at more than the throttling rate, some data will be dropped. (The ASP.NET, Java, and JavaScript SDKs try to resend data this way; other SDKs might drop throttled data.) If throttling occurs, a notification warning alerts you that this has occurred.

-## Manage your maximum daily data volume

-You can use the daily volume cap to limit the data collected. However, if the cap is met, a loss of all telemetry sent from your application for the remainder of the day occurs. It *isn't advisable* to have your application hit the daily cap. You can't track the health and performance of your application after it reaches the daily cap.

-> [!WARNING]

-> If you have a workspace-based Application Insights resource, we recommend using the [workspace's daily cap](../logs/manage-cost-storage.md#manage-your-maximum-daily-data-volume) to limit ingestion and costs. The daily cap in Application Insights may not limit ingestion in all cases to the selected level. (If your Application Insights resource is ingesting a lot of data, the Application Insights daily cap might need to be raised.)

-Instead of using the daily volume cap, use [sampling](./sampling.md) to tune the data volume to the level you want. Then, use the daily cap only as a "last resort" in case your application unexpectedly begins to send much higher volumes of telemetry.

-### Identify what daily data limit to define

-Review Application Insights Usage and estimated costs to understand the data ingestion trend and what is the daily volume cap to define. It should be considered with care, since you won't be able to monitor your resources after the limit is reached.

-### Set the Daily Cap

-To change the daily cap, in the **Configure** section of your Application Insights resource, in the **Usage and estimated costs** page, select **Daily Cap**.

-

-To [change the daily cap via Azure Resource Manager](./powershell.md), the property to change is the `dailyQuota`. Via Azure Resource Manager you can also set the `dailyQuotaResetTime` and the daily cap's `warningThreshold`.

-### Create alerts for the Daily Cap

-The Application Insights Daily Cap creates an event in the Azure activity log when the ingested data volumes reaches the warning level or the daily cap level. You can [create an alert based on these activity log events](../alerts/alerts-activity-log.md#azure-portal). The signal names for these events are:

-* Application Insights component daily cap warning threshold reached

-* Application Insights component daily cap reached

-## Sampling

-[sampling](./sampling.md) is a method of reducing the rate at which telemetry is sent to your app, while retaining the ability to find related events during diagnostic searches. You also retain correct event counts.

-Sampling is an effective way to reduce charges and stay within your monthly quota. The sampling algorithm retains related items of telemetry so, for example, when you use Search, you can find the request related to a particular exception. The algorithm also retains correct counts so you see the correct values in Metric Explorer for request rates, exception rates, and other counts.

-There are several forms of sampling.

-* [Adaptive sampling](./sampling.md) is the default for the ASP.NET SDK. Adaptive sampling automatically adjusts to the volume of telemetry that your app sends. It operates automatically in the SDK in your web app so that telemetry traffic on the network is reduced.

-* *Ingestion sampling* is an alternative that operates at the point where telemetry from your app enters the Application Insights service. Ingestion sampling doesn't affect the volume of telemetry sent from your app, but it reduces the volume that's retained by the service. You can use ingestion sampling to reduce the quota that's used up by telemetry from browsers and other SDKs.

-To set ingestion sampling, go to the **Pricing** pane:

-

-> [!WARNING]

-> The **Data sampling** pane controls only the value of ingestion sampling. It doesn't reflect the sampling rate that's applied by the Application Insights SDK in your app. If the incoming telemetry has already been sampled in the SDK, ingestion sampling isn't applied.

->

-To discover the actual sampling rate, no matter where it's been applied, use an [Analytics query](../logs/log-query-overview.md). The query looks like this:

-```kusto

-requests | where timestamp > ago(1d)

-| summarize 100/avg(itemCount) by bin(timestamp, 1h)

-| render areachart

-```

-In each retained record, `itemCount` indicates the number of original records that it represents. It's equal to 1 + the number of previous discarded records.

-## Change the data retention period

-The default retention for Application Insights resources is 90 days. Different retention periods can be selected for each Application Insights resource. The full set of available retention periods is 30, 60, 90, 120, 180, 270, 365, 550 or 730 days. [Learn more](https://azure.microsoft.com/pricing/details/monitor/) about pricing for longer data retention.

-To change the retention, from your Application Insights resource, go to the **Usage and Estimated Costs** page and select the **Data Retention** option:

-

-A several-day grace period begins when the retention is lowered before the oldest data is removed.

-The retention can also be [set programatically using PowerShell](powershell.md#set-the-data-retention) using the `retentionInDays` parameter. If you set the data retention to 30 days, you can trigger an immediate purge of older data using the `immediatePurgeDataOn30Days` parameter, which may be useful for compliance-related scenarios. This purge functionality is only exposed via Azure Resource Manager and should be used with extreme care. The daily reset time for the data volume cap can be configured using Azure Resource Manager to set the `dailyQuotaResetTime` parameter.

-## Data transfer charges using Application Insights

-Sending data to Application Insights might incur data bandwidth charges. As described in the [Azure Bandwidth pricing page](https://azure.microsoft.com/pricing/details/bandwidth/), data transfer between Azure services located in two regions charged as outbound data transfer at the normal rate. Inbound data transfer is free. However, this charge is very small (few %) compared to the costs for Application Insights log data ingestion. Consequently controlling costs for Log Analytics needs to focus on your ingested data volume, and we have guidance to help understand that [here](#managing-your-data-volume).

-## Limits summary

-## Disable daily cap e-mails

-To disable the daily volume cap e-mails, under the **Configure** section of your Application Insights resource, in the **Usage and estimated costs** pane, select **Daily Cap**. There are settings to send e-mail when the cap is reached, as well as when an adjustable warning level has been reached. If you wish to disable all daily cap volume-related emails, uncheck both boxes.

-## Legacy Enterprise (Per Node) pricing tier

-For early adopters of Azure Application Insights, there are still two possible pricing tiers: Basic and Enterprise. The Basic pricing tier is the same as described above and is the default tier. It includes all Enterprise tier features, at no extra cost. The Basic tier bills primarily on the volume of data that's ingested.

-These legacy pricing tiers have been renamed. The Enterprise pricing tier is now called **Per Node** and the Basic pricing tier is now called **Per GB**. These new names are used below and in the Azure portal.

-The Per Node (formerly Enterprise) tier has a per-node charge, and each node receives a daily data allowance. In the Per Node pricing tier, you're charged for data ingested above the included allowance. If you're using Operations Management Suite, you should choose the Per Node tier. In April 2018, we [introduced](https://azure.microsoft.com/blog/introducing-a-new-way-to-purchase-azure-monitoring-services/) a new pricing model for Azure monitoring. This model adopts a simple "pay-as-you-go" model across the complete portfolio of monitoring services. Learn more about the [new pricing model](..//usage-estimated-costs.md).

-For current prices in your currency and region, see [Application Insights pricing](https://azure.microsoft.com/pricing/details/application-insights/).

-### Understanding billed usage on the legacy Enterprise (Per Node) tier

-As described below in more detail, the legacy Enterprise (Per Node) tier combines usage from across all Application Insights resources in a subscription to calculate the number of nodes and the data overage. Due to this combination process, **usage for all Application Insights resources in a subscription are reported against just one of the resources**. This makes reconciling your [billed usage](#viewing-application-insights-usage-on-your-azure-bill) with the usage you observe for each Application Insights resource complicated.

-> [!WARNING]

-> Because of the complexity of tracking and understanding usage of Application Insights resources in the legacy Enterprise (Per Node) tier we strongly recommend using the current Pay-As-You-Go pricing tier.

-### Per Node tier and Operations Management Suite subscription entitlements

-Customers who purchase Operations Management Suite E1 and E2 can get Application Insights Per Node as an supplemental component at no extra cost as [previously announced](/archive/blogs/msoms/azure-application-insights-enterprise-as-part-of-operations-management-suite-subscription). Specifically, each unit of Operations Management Suite E1 and E2 includes an entitlement to one node of the Application Insights Per Node tier. Each Application Insights node includes up to 200 MB of data ingested per day (separate from Log Analytics data ingestion), with 90-day data retention at no extra cost. The tier is described in more detailed later in the article.

-Because this tier is applicable only to customers with an Operations Management Suite subscription, customers who don't have an Operations Management Suite subscription don't see an option to select this tier.

-> [!NOTE]

-> To ensure that you get this entitlement, your Application Insights resources must be in the Per Node pricing tier. This entitlement applies only as nodes. Application Insights resources in the Per GB tier don't realize any benefit.

-> This entitlement isn't visible in the estimated costs shown in the **Usage and estimated cost** pane. Also, if you move a subscription to the new Azure monitoring pricing model in April 2018, the Per GB tier is the only tier available. Moving a subscription to the new Azure monitoring pricing model isn't advisable if you have an Operations Management Suite subscription.

-### How the Per Node tier works

-* You pay for each node that sends telemetry for any apps in the Per Node tier.

- * A *node* is a physical or virtual server machine or a platform-as-a-service role instance that hosts your app.

- * Development machines, client browsers, and mobile devices don't count as nodes.

- * If your app has several components that send telemetry, such as a web service and a back-end worker, the components are counted separately.

- * [Live Metrics Stream](./live-stream.md) data isn't counted for pricing purposes. In a subscription, your charges are per node, not per app. If you have five nodes that send telemetry for 12 apps, the charge is for five nodes.

-* Although charges are quoted per month, you're charged only for any hour in which a node sends telemetry from an app. The hourly charge is the quoted monthly charge divided by 744 (the number of hours in a 31-day month).

-* A data volume allocation of 200 MB per day is given for each node that's detected (with hourly granularity). Unused data allocation isn't carried over from one day to the next.

- * If you choose the Per Node pricing tier, each subscription gets a daily allowance of data based on the number of nodes that send telemetry to the Application Insights resources in that subscription. So, if you have five nodes that send data all day, you'll have a pooled allowance of 1 GB applied to all Application Insights resources in that subscription. It doesn't matter if certain nodes send more data than other nodes because the included data is shared across all nodes. If on a given day, the Application Insights resources receive more data than is included in the daily data allocation for this subscription, the per-GB overage data charges apply.

- * The daily data allowance is calculated as the number of hours in the day (using UTC) that each node sends telemetry divided by 24 multiplied by 200 MB. So, if you have four nodes that send telemetry during 15 of the 24 hours in the day, the included data for that day would be ((4 &#215; 15) / 24) &#215; 200 MB = 500 MB. At the price of 2.30 USD per GB for data overage, the charge would be 1.15 USD if the nodes send 1 GB of data that day.

- * The Per Node tier daily allowance isn't shared with applications for which you have chosen the Per GB tier. Unused allowance isn't carried over from day-to-day.

-### Examples of how to determine distinct node count

-| Scenario | Total daily node count |

-|:|:-:|

-| 1 application using 3 Azure App Service instances and 1 virtual server | 4 |

-| 3 applications running on 2 VMs; the Application Insights resources for these applications are in the same subscription and in the Per Node tier | 2 |

-| 4 applications whose Applications Insights resources are in the same subscription; each application running 2 instances during 16 off-peak hours, and 4 instances during 8 peak hours | 13.33 |

-| Cloud services with 1 Worker Role and 1 Web Role, each running 2 instances | 4 |

-| A 5-node Azure Service Fabric cluster running 50 microservices; each microservice running 3 instances | 5|

-* The precise node counting depends on which Application Insights SDK your application is using.

- * In SDK versions 2.2 and later, both the Application Insights [Core SDK](https://www.nuget.org/packages/Microsoft.ApplicationInsights/) and the [Web SDK](https://www.nuget.org/packages/Microsoft.ApplicationInsights.Web/) report each application host as a node. Examples are the computer name for physical server and VM hosts or the instance name for cloud services. The only exception is an application that uses only the [.NET Core](https://dotnet.github.io/) and the Application Insights Core SDK. In that case, only one node is reported for all hosts because the host name isn't available.

- * For earlier versions of the SDK, the [Web SDK](https://www.nuget.org/packages/Microsoft.ApplicationInsights.Web/) behaves like the newer SDK versions, but the [Core SDK](https://www.nuget.org/packages/Microsoft.ApplicationInsights/) reports only one node, regardless of the number of application hosts.

- * If your application uses the SDK to set **roleInstance** to a custom value, by default, that same value is used to determine node count.

- * If you're using a new SDK version with an app that runs from client machines or mobile devices, the node count might return a number that's large (because of the large number of client machines or mobile devices).

-## Automation

-You can write a script to set the pricing tier by using Azure Resource Management. [Learn how](powershell.md#price).

-## Next steps

-[Sampling](./sampling.md) in Application Insights is the recommended way to reduce telemetry traffic, data costs, and storage costs.

-[api]: app-insights-api-custom-events-metrics.md

-[apiproperties]: app-insights-api-custom-events-metrics.md#properties

-[start]: ./app-insights-overview.md

-[pricing]: https://azure.microsoft.com/pricing/details/application-insights/

-[pricing]: https://azure.microsoft.com/pricing/details/application-insights/

-## Troubleshooting

-### Unexpected usage or estimated cost

-Lower your bill with updated versions of the ASP.NET Core SDK and Worker Service SDK, which [don't collect counters by default](eventcounters.md#default-counters-collected).

-### Microsoft Q&A question page

-If you have questions about how pricing works for Application Insights, you can post a question in our [Microsoft Q&A question page](/answers/topics/azure-monitor.html).

-> If you use this method to configure sampling, please make sure to set the `aiOptions.EnableAdaptiveSampling` property to `false` when calling `AddApplicationInsightsTelemetry()`. After making this change, you then need to follow the instructions in the code block below **exactly** in order to re-enable adaptive sampling with your customizations in place. Failure to do so can result in excess data ingestion. Always test post changing sampling settings, and set an appropriate [daily data cap](pricing.md#set-the-daily-cap) to help control your costs.

-* To keep within the [quota](pricing.md) of data points for your pricing tier.

-Computer name is used by Application Insights [Legacy Enterprise (Per Node) pricing tier](./pricing.md#legacy-enterprise-per-node-pricing-tier) for internal billing purposes. By default if you use a telemetry initializer to override `telemetry.Context.Cloud.RoleInstance`, a separate property `ai.internal.nodeName` will be sent which will still contain the computer name value. This value will not be stored with your Application Insights telemetry, but is used internally at ingestion to allow for backwards compatibility with the legacy node-based billing model.

-If you are on the [Legacy Enterprise (Per Node) pricing tier](./pricing.md#legacy-enterprise-per-node-pricing-tier) and simply need to override storage of the computer name, use a telemetry Initializer:

-If you aren't on the [Legacy Enterprise (Per Node) pricing tier](./pricing.md#legacy-enterprise-per-node-pricing-tier) and wish to completely prevent any telemetry containing computer name from being sent, you need to use a telemetry processor.

-> While you can technically use a telemetry processor as described above even if you are on the [Legacy Enterprise (Per Node) pricing tier](./pricing.md#legacy-enterprise-per-node-pricing-tier), this will result in the potential for over-billing due to the inability to properly distinguish nodes for per node pricing.

-There is no cost for creating a Log Analytics workspace, but there is a potential charge once you configure data to be collected into it. See [Manage usage and costs with Azure Monitor Logs](logs/manage-cost-storage.md) for details.

-There is a cost for collecting resource logs in your Log Analytics workspace, so only select those log categories with valuable data. Collecting all categories will incur cost for collecting data with little value. See the monitoring documentation for each Azure service for a description of categories and recommendations for which to collect. Also see [Manage usage and costs with Azure Monitor Logs](logs/manage-cost-storage.md) for details on optimizing the cost of your log collection.

-For more information about how to understand what the costs are likely to be based on recent usage patterns from data collected with Container insights, see [Manage your usage and estimate costs](../logs/manage-cost-storage.md).

-| Daily Data Cap Breach | When data cap is breached| When the total data ingestion to your Log Analytics workspace exceeds the [designated quota](../logs/manage-cost-storage.md#manage-your-maximum-daily-data-volume) |

-Further information on how to monitor data usage and analyze cost is available in [Manage usage and costs with Azure Monitor Logs](../logs/manage-cost-storage.md).

-> Metrics sent to Azure Monitor via the Application Insights SDK are billed as ingested log data. They incur additional metrics charges only if the Application Insights feature [Enable alerting on custom metric dimensions](../app/pre-aggregated-metrics-log-metrics.md#custom-metrics-dimensions-and-pre-aggregation) has been selected. This checkbox sends data to the Azure Monitor metrics database by using the custom metrics API to allow the more complex alerting. Learn more about the [Application Insights pricing model](../app/pricing.md#pricing-model) and [prices in your region](https://azure.microsoft.com/pricing/details/monitor/).

-|BackendDuration|Yes|Duration of Backend Requests|Milliseconds|Average|Duration of Backend Requests in milliseconds|Location, Hostname|

-|Capacity|Yes|Capacity|Percent|Average|Utilization metric for ApiManagement service|Location|

-|Duration|Yes|Overall Duration of Gateway Requests|Milliseconds|Average|Overall Duration of Gateway Requests in milliseconds|Location, Hostname|

-## Microsoft.BotService/botServices

-|RequestLatency|Yes|Requests Latencies|Milliseconds|Average|How long it takes to get request response|Operation, Authentication, Protocol, ResourceId, Region|

-|RequestsTraffic|Yes|Requests Traffic|Count|Average|Number of requests within a given period of time|Operation, Authentication, Protocol, ResourceId, Region, StatusCode, StatusCodeClass, StatusText|

-|CharactersTrained|Yes|Characters Trained (Deprecated)|Count|Total|Total number of characters trained.|ApiName, OperationName, Region|

-|CharactersTranslated|Yes|Characters Translated (Deprecated)|Count|Total|Total number of characters in incoming text request.|ApiName, OperationName, Region|

-|MatchedRewards|Yes|Matched Rewards|Count|Total| Number of Matched Rewards.|Mode, RunId|

-|ProcessedCharacters|Yes|Processed Characters|Count|Total|Number of Characters.|ApiName, FeatureName, UsageChannel, Region|

-|SpeechSessionDuration|Yes|Speech Session Duration|Seconds|Total|Total duration of speech session in seconds.|ApiName, OperationName, Region|

-|TotalTransactions|Yes|Total Transactions|Count|Total|Total number of transactions.|No Dimensions|

-|RunDuration|Yes|Run Duration|Milliseconds|Total|Run Duration in milliseconds|No Dimensions|

-|SuccessfulPullCount|Yes|Successful Pull Count|Count|Average|Number of successful image pulls|No Dimensions|

-|SuccessfulPushCount|Yes|Successful Push Count|Count|Average|Number of successful image pushes|No Dimensions|

-|TotalPullCount|Yes|Total Pull Count|Count|Average|Number of image pulls in total|No Dimensions|

-|TotalPushCount|Yes|Total Push Count|Count|Average|Number of image pushes in total|No Dimensions|

-|d2c.endpoints.latency.builtIn.events|Yes|Routing: message latency for messages/events|Milliseconds|Average|The average latency (milliseconds) between message ingress to IoT Hub and telemetry message ingress into the built-in endpoint (messages/events).|No Dimensions|

-|d2c.endpoints.latency.eventHubs|Yes|Routing: message latency for Event Hub|Milliseconds|Average|The average latency (milliseconds) between message ingress to IoT Hub and message ingress into an Event Hub endpoint.|No Dimensions|

-|d2c.endpoints.latency.serviceBusQueues|Yes|Routing: message latency for Service Bus Queue|Milliseconds|Average|The average latency (milliseconds) between message ingress to IoT Hub and telemetry message ingress into a Service Bus queue endpoint.|No Dimensions|

-|d2c.endpoints.latency.serviceBusTopics|Yes|Routing: message latency for Service Bus Topic|Milliseconds|Average|The average latency (milliseconds) between message ingress to IoT Hub and telemetry message ingress into a Service Bus topic endpoint.|No Dimensions|

-|d2c.endpoints.latency.storage|Yes|Routing: message latency for storage|Milliseconds|Average|The average latency (milliseconds) between message ingress to IoT Hub and telemetry message ingress into a storage endpoint.|No Dimensions|

-|d2c.telemetry.egress.dropped|Yes|Routing: telemetry messages dropped|Count|Total|The number of times messages were dropped by IoT Hub routing due to dead endpoints. This value does not count messages delivered to fallback route as dropped messages are not delivered there.|No Dimensions|

-|d2c.telemetry.egress.orphaned|Yes|Routing: telemetry messages orphaned|Count|Total|The number of times messages were orphaned by IoT Hub routing because they didn't match any routing rules (including the fallback rule).|No Dimensions|

-|EventGridLatency|Yes|Event Grid latency|Milliseconds|Average|The average latency (milliseconds) from when the Iot Hub event was generated to when the event was published to Event Grid. This number is an average between all event types. Use the EventType dimension to see latency of a specific type of event.|EventType|

-|RoutingDeliveryLatency|Yes|Routing Delivery Latency (preview)|Milliseconds|Average|The average latency (milliseconds) between message ingress to IoT Hub and telemetry message ingress into an endpoint. You can use the EndpointName and EndpointType dimensions to understand the latency to your different endpoints.|EndpointType, EndpointName, RoutingSource|

-## Microsoft.DocumentDB/databaseAccounts

-|AvailableStorage|No|(deprecated) Available Storage|Bytes|Total|"Available Storage"will be removed from Azure Monitor at the end of September 2023. Cosmos DB collection storage size is now unlimited. The only restriction is that the storage size for each logical partition key is 20GB. You can enable PartitionKeyStatistics in Diagnostic Log to know the storage consumption for top partition keys. For more info about Cosmos DB storage quota, please check this doc [https://docs.microsoft.com/azure/cosmos-db/concepts-limits](../../cosmos-db/concepts-limits.md). After deprecation, the remaining alert rules still defined on the deprecated metric will be automatically disabled post the deprecation date.|CollectionName, DatabaseName, Region|

-|DedicatedGatewayRequests|Yes|DedicatedGatewayRequests|Count|Count|Requests at the dedicated gateway|DatabaseName, CollectionName, CacheExercised, OperationName, Region|

-|MongoRequestsCount|No|(deprecated) Mongo Request Rate|CountPerSecond|Average|Mongo request Count per second|DatabaseName, CollectionName, Region, ErrorCode|

-|MongoRequestsDelete|No|(deprecated) Mongo Delete Request Rate|CountPerSecond|Average|Mongo Delete request per second|DatabaseName, CollectionName, Region, ErrorCode|

-|MongoRequestsInsert|No|(deprecated) Mongo Insert Request Rate|CountPerSecond|Average|Mongo Insert count per second|DatabaseName, CollectionName, Region, ErrorCode|

-|MongoRequestsQuery|No|(deprecated) Mongo Query Request Rate|CountPerSecond|Average|Mongo Query request per second|DatabaseName, CollectionName, Region, ErrorCode|

-|MongoRequestsUpdate|No|(deprecated) Mongo Update Request Rate|CountPerSecond|Average|Mongo Update request per second|DatabaseName, CollectionName, Region, ErrorCode|

-|NormalizedRUConsumption|No|Normalized RU Consumption|Percent|Maximum|Max RU consumption percentage per minute|CollectionName, DatabaseName, Region, PartitionKeyRangeId|

-|DestinationProcessingDurationInMs|No|Destination Processing Duration|Milliseconds|Average|Destination processing duration in milliseconds|Topic, EventSubscriptionName, DomainEventSubscriptionName|

-|PublishSuccessLatencyInMs|Yes|Publish Success Latency|Milliseconds|Total|Publish success latency in milliseconds|No Dimensions|

-|DeadLetteredCount|Yes|Dead Lettered Events|Count|Total|Total dead lettered events matching to this event subscription|DeadLetterReason, EventSubscriptionName|

-|DeliveryAttemptFailCount|No|Delivery Failed Events|Count|Total|Total events failed to deliver to this event subscription|Error, ErrorType, EventSubscriptionName|

-|DeliverySuccessCount|Yes|Delivered Events|Count|Total|Total events delivered to this event subscription|EventSubscriptionName|

-|DestinationProcessingDurationInMs|No|Destination Processing Duration|Milliseconds|Average|Destination processing duration in milliseconds|EventSubscriptionName|

-|DroppedEventCount|Yes|Dropped Events|Count|Total|Total dropped events matching to this event subscription|DropReason, EventSubscriptionName|

-|MatchedEventCount|Yes|Matched Events|Count|Total|Total events matched to this event subscription|EventSubscriptionName|

-|PublishFailCount|Yes|Publish Failed Events|Count|Total|Total events failed to publish to this topic|ErrorType, Error|

-|PublishSuccessCount|Yes|Published Events|Count|Total|Total events published to this topic|No Dimensions|

-|PublishSuccessLatencyInMs|Yes|Publish Success Latency|Milliseconds|Total|Publish success latency in milliseconds|No Dimensions|

-|UnmatchedEventCount|Yes|Unmatched Events|Count|Total|Total events not matching any of the event subscriptions for this topic|No Dimensions|

-|AdvancedFilterEvaluationCount|Yes|Advanced Filter Evaluations|Count|Total|Total advanced filters evaluated across event subscriptions for this topic.|EventSubscriptionName|

-|DestinationProcessingDurationInMs|No|Destination Processing Duration|Milliseconds|Average|Destination processing duration in milliseconds|EventSubscriptionName|

-|PublishFailCount|Yes|Publish Failed Events|Count|Total|Total events failed to publish to this topic|ErrorType, Error|

-|PublishSuccessCount|Yes|Published Events|Count|Total|Total events published to this topic|No Dimensions|

-|UnmatchedEventCount|Yes|Unmatched Events|Count|Total|Total events not matching any of the event subscriptions for this topic|No Dimensions|

-|DestinationProcessingDurationInMs|No|Destination Processing Duration|Milliseconds|Average|Destination processing duration in milliseconds|EventSubscriptionName|

-|PublishSuccessLatencyInMs|Yes|Publish Success Latency|Milliseconds|Total|Publish success latency in milliseconds|No Dimensions|

-## Microsoft.EventHub/namespaces

-|NamespaceCpuUsage|No|CPU|Percent|Maximum|CPU usage metric for Premium SKU namespaces.|No Dimensions|

-|NamespaceMemoryUsage|No|Memory Usage|Percent|Maximum|Memory usage metric for Premium SKU namespaces.|No Dimensions|

-|QuotaExceededErrors|No|Quota Exceeded Errors.|Count|Total|Quota Exceeded Errors for Microsoft.EventHub.|EntityName, |

-|ServerErrors|No|Server Errors.|Count|Total|Server Errors for Microsoft.EventHub.|EntityName, |

-|SuccessfulRequests|No|Successful Requests|Count|Total|Successful Requests for Microsoft.EventHub.|EntityName, |

-|ThrottledRequests|No|Throttled Requests.|Count|Total|Throttled Requests for Microsoft.EventHub.|EntityName, |

-|UserErrors|No|User Errors.|Count|Total|User Errors for Microsoft.EventHub.|EntityName, |

-## Microsoft.KeyVault/managedHSMs

-|Availability|No|Overall Vault Availability|Percent|Average|Vault requests availability|ActivityType, ActivityName, StatusCode, StatusCodeClass|

-|ServiceApiResult|Yes|Total Service Api Results|Count|Count|Gets the available metrics for a Managed HSM pool|ActivityType, ActivityName, StatusCode, StatusCodeClass|

-|ServiceApiLatency|Yes|Overall Service Api Latency|Milliseconds|Average|Overall latency of service api requests|ActivityType, ActivityName, StatusCode, StatusCodeClass|

-## Microsoft.Logic/workflows

-|IngressBytes|Yes|Ingress Bytes|Bytes|Total|The number of bytes ingressed by the pipeline node.|PipelineTopology, Pipeline, Node|

-## Microsoft.Network/applicationGateways

-## Microsoft.Network/azurefirewalls

-|AllocatedSnatPorts|No|Allocated SNAT Ports|Count|Average|Total number of SNAT ports allocated within time period|FrontendIPAddress, BackendIPAddress, ProtocolType, |

-|UsedSnatPorts|No|Used SNAT Ports|Count|Average|Total number of SNAT ports used within time period|FrontendIPAddress, BackendIPAddress, ProtocolType, |

-## Microsoft.Network/p2sVpnGateways

-|P2SBandwidth|Yes|Gateway P2S Bandwidth|BytesPerSecond|Average|Average point-to-site bandwidth of a gateway in bytes per second|Instance|

-## Microsoft.Network/virtualNetworkGateways

-|AverageBandwidth|Yes|Gateway S2S Bandwidth|BytesPerSecond|Average|Average site-to-site bandwidth of a gateway in bytes per second|Instance|

-|ExpressRouteGatewayCountOfRoutesAdvertisedToPeer|Yes|Count Of Routes Advertised to Peer|Count|Maximum|Count Of Routes Advertised To Peer by ExpressRouteGateway|roleInstance|

-|ExpressRouteGatewayCountOfRoutesLearnedFromPeer|Yes|Count Of Routes Learned from Peer|Count|Maximum|Count Of Routes Learned From Peer by ExpressRouteGateway|roleInstance|

-|ExpressRouteGatewayFrequencyOfRoutesChanged|No|Frequency of Routes change|Count|Total|Frequency of Routes change in ExpressRoute Gateway|roleInstance|

-|ExpressRouteGatewayNumberOfVmInVnet|No|Number of VMs in the Virtual Network|Count|Maximum|Number of VMs in the Virtual Network|No Dimensions|

-|P2SBandwidth|Yes|Gateway P2S Bandwidth|BytesPerSecond|Average|Average point-to-site bandwidth of a gateway in bytes per second|Instance|

-|P2SConnectionCount|Yes|P2S Connection Count|Count|Maximum|Point-to-site connection count of a gateway|Protocol, Instance|

-|TunnelNatedBytes|No|Tunnel NATed Bytes|Bytes|Total|Number of bytes that were NATed on a tunnel by a NAT rule |NatRule, ConnectionName, RemoteIP, Instance|

-|TunnelNatFlowCount|No|Tunnel NAT Flows|Count|Total|Number of NAT flows on a tunnel by flow type and NAT rule|NatRule, ConnectionName, RemoteIP, FlowType, Instance|

-|TunnelNatPacketDrop|No|Tunnel NAT Packet Drops|Count|Total|Number of NATed packets on a tunnel that dropped by drop type and NAT rule|NatRule, ConnectionName, RemoteIP, DropType, Instance|

-## Microsoft.Network/vpnGateways

-|AverageBandwidth|Yes|Gateway S2S Bandwidth|BytesPerSecond|Average|Average site-to-site bandwidth of a gateway in bytes per second|Instance|

-|TunnelNatedBytes|No|Tunnel NATed Bytes|Bytes|Total|Number of bytes that were NATed on a tunnel by a NAT rule |NatRule, ConnectionName, RemoteIP, Instance|

-|TunnelNatFlowCount|No|Tunnel NAT Flows|Count|Total|Number of NAT flows on a tunnel by flow type and NAT rule|NatRule, ConnectionName, RemoteIP, FlowType, Instance|

-|TunnelNatPacketDrop|No|Tunnel NAT Packet Drops|Count|Total|Number of NATed packets on a tunnel that dropped by drop type and NAT rule|NatRule, ConnectionName, RemoteIP, DropType, Instance|

-|Average_% Available Memory|Yes|% Available Memory|Count|Average|Average_% Available Memory|Computer, ObjectName, InstanceName, CounterPath, SourceSystem|

-|Average_% Available Swap Space|Yes|% Available Swap Space|Count|Average|Average_% Available Swap Space|Computer, ObjectName, InstanceName, CounterPath, SourceSystem|

-|Average_% Committed Bytes In Use|Yes|% Committed Bytes In Use|Count|Average|Average_% Committed Bytes In Use|Computer, ObjectName, InstanceName, CounterPath, SourceSystem|

-|Average_% DPC Time|Yes|% DPC Time|Count|Average|Average_% DPC Time|Computer, ObjectName, InstanceName, CounterPath, SourceSystem|

-|Average_% Free Inodes|Yes|% Free Inodes|Count|Average|Average_% Free Inodes|Computer, ObjectName, InstanceName, CounterPath, SourceSystem|

-|Average_% Free Space|Yes|% Free Space|Count|Average|Average_% Free Space|Computer, ObjectName, InstanceName, CounterPath, SourceSystem|

-|Average_% Idle Time|Yes|% Idle Time|Count|Average|Average_% Idle Time|Computer, ObjectName, InstanceName, CounterPath, SourceSystem|

-|Average_% Interrupt Time|Yes|% Interrupt Time|Count|Average|Average_% Interrupt Time|Computer, ObjectName, InstanceName, CounterPath, SourceSystem|

-|Average_% IO Wait Time|Yes|% IO Wait Time|Count|Average|Average_% IO Wait Time|Computer, ObjectName, InstanceName, CounterPath, SourceSystem|

-|Average_% Nice Time|Yes|% Nice Time|Count|Average|Average_% Nice Time|Computer, ObjectName, InstanceName, CounterPath, SourceSystem|

-|Average_% Privileged Time|Yes|% Privileged Time|Count|Average|Average_% Privileged Time|Computer, ObjectName, InstanceName, CounterPath, SourceSystem|

-|Average_% Processor Time|Yes|% Processor Time|Count|Average|Average_% Processor Time|Computer, ObjectName, InstanceName, CounterPath, SourceSystem|

-|Average_% Used Inodes|Yes|% Used Inodes|Count|Average|Average_% Used Inodes|Computer, ObjectName, InstanceName, CounterPath, SourceSystem|

-|Average_% Used Memory|Yes|% Used Memory|Count|Average|Average_% Used Memory|Computer, ObjectName, InstanceName, CounterPath, SourceSystem|

-|Average_% Used Space|Yes|% Used Space|Count|Average|Average_% Used Space|Computer, ObjectName, InstanceName, CounterPath, SourceSystem|

-|Average_% Used Swap Space|Yes|% Used Swap Space|Count|Average|Average_% Used Swap Space|Computer, ObjectName, InstanceName, CounterPath, SourceSystem|

-|Average_% User Time|Yes|% User Time|Count|Average|Average_% User Time|Computer, ObjectName, InstanceName, CounterPath, SourceSystem|

-|Average_Available MBytes|Yes|Available MBytes|Count|Average|Average_Available MBytes|Computer, ObjectName, InstanceName, CounterPath, SourceSystem|

-|Average_Available MBytes Memory|Yes|Available MBytes Memory|Count|Average|Average_Available MBytes Memory|Computer, ObjectName, InstanceName, CounterPath, SourceSystem|

-|Average_Available MBytes Swap|Yes|Available MBytes Swap|Count|Average|Average_Available MBytes Swap|Computer, ObjectName, InstanceName, CounterPath, SourceSystem|

-|Average_Avg. Disk sec/Read|Yes|Avg. Disk sec/Read|Count|Average|Average_Avg. Disk sec/Read|Computer, ObjectName, InstanceName, CounterPath, SourceSystem|

-|Average_Avg. Disk sec/Transfer|Yes|Avg. Disk sec/Transfer|Count|Average|Average_Avg. Disk sec/Transfer|Computer, ObjectName, InstanceName, CounterPath, SourceSystem|

-|Average_Avg. Disk sec/Write|Yes|Avg. Disk sec/Write|Count|Average|Average_Avg. Disk sec/Write|Computer, ObjectName, InstanceName, CounterPath, SourceSystem|

-|Average_Bytes Received/sec|Yes|Bytes Received/sec|Count|Average|Average_Bytes Received/sec|Computer, ObjectName, InstanceName, CounterPath, SourceSystem|

-|Average_Bytes Sent/sec|Yes|Bytes Sent/sec|Count|Average|Average_Bytes Sent/sec|Computer, ObjectName, InstanceName, CounterPath, SourceSystem|

-|Average_Bytes Total/sec|Yes|Bytes Total/sec|Count|Average|Average_Bytes Total/sec|Computer, ObjectName, InstanceName, CounterPath, SourceSystem|

-|Average_Current Disk Queue Length|Yes|Current Disk Queue Length|Count|Average|Average_Current Disk Queue Length|Computer, ObjectName, InstanceName, CounterPath, SourceSystem|

-|Average_Disk Read Bytes/sec|Yes|Disk Read Bytes/sec|Count|Average|Average_Disk Read Bytes/sec|Computer, ObjectName, InstanceName, CounterPath, SourceSystem|

-|Average_Disk Reads/sec|Yes|Disk Reads/sec|Count|Average|Average_Disk Reads/sec|Computer, ObjectName, InstanceName, CounterPath, SourceSystem|

-|Average_Disk Transfers/sec|Yes|Disk Transfers/sec|Count|Average|Average_Disk Transfers/sec|Computer, ObjectName, InstanceName, CounterPath, SourceSystem|

-|Average_Disk Write Bytes/sec|Yes|Disk Write Bytes/sec|Count|Average|Average_Disk Write Bytes/sec|Computer, ObjectName, InstanceName, CounterPath, SourceSystem|

-|Average_Disk Writes/sec|Yes|Disk Writes/sec|Count|Average|Average_Disk Writes/sec|Computer, ObjectName, InstanceName, CounterPath, SourceSystem|

-|Average_Free Megabytes|Yes|Free Megabytes|Count|Average|Average_Free Megabytes|Computer, ObjectName, InstanceName, CounterPath, SourceSystem|

-|Average_Free Physical Memory|Yes|Free Physical Memory|Count|Average|Average_Free Physical Memory|Computer, ObjectName, InstanceName, CounterPath, SourceSystem|

-|Average_Free Space in Paging Files|Yes|Free Space in Paging Files|Count|Average|Average_Free Space in Paging Files|Computer, ObjectName, InstanceName, CounterPath, SourceSystem|

-|Average_Free Virtual Memory|Yes|Free Virtual Memory|Count|Average|Average_Free Virtual Memory|Computer, ObjectName, InstanceName, CounterPath, SourceSystem|

-|Average_Logical Disk Bytes/sec|Yes|Logical Disk Bytes/sec|Count|Average|Average_Logical Disk Bytes/sec|Computer, ObjectName, InstanceName, CounterPath, SourceSystem|

-|Average_Page Reads/sec|Yes|Page Reads/sec|Count|Average|Average_Page Reads/sec|Computer, ObjectName, InstanceName, CounterPath, SourceSystem|

-|Average_Page Writes/sec|Yes|Page Writes/sec|Count|Average|Average_Page Writes/sec|Computer, ObjectName, InstanceName, CounterPath, SourceSystem|

-|Average_Pages/sec|Yes|Pages/sec|Count|Average|Average_Pages/sec|Computer, ObjectName, InstanceName, CounterPath, SourceSystem|

-|Average_Pct Privileged Time|Yes|Pct Privileged Time|Count|Average|Average_Pct Privileged Time|Computer, ObjectName, InstanceName, CounterPath, SourceSystem|

-|Average_Pct User Time|Yes|Pct User Time|Count|Average|Average_Pct User Time|Computer, ObjectName, InstanceName, CounterPath, SourceSystem|

-|Average_Physical Disk Bytes/sec|Yes|Physical Disk Bytes/sec|Count|Average|Average_Physical Disk Bytes/sec|Computer, ObjectName, InstanceName, CounterPath, SourceSystem|

-|Average_Processes|Yes|Processes|Count|Average|Average_Processes|Computer, ObjectName, InstanceName, CounterPath, SourceSystem|

-|Average_Processor Queue Length|Yes|Processor Queue Length|Count|Average|Average_Processor Queue Length|Computer, ObjectName, InstanceName, CounterPath, SourceSystem|

-|Average_Size Stored In Paging Files|Yes|Size Stored In Paging Files|Count|Average|Average_Size Stored In Paging Files|Computer, ObjectName, InstanceName, CounterPath, SourceSystem|

-|Average_Total Bytes|Yes|Total Bytes|Count|Average|Average_Total Bytes|Computer, ObjectName, InstanceName, CounterPath, SourceSystem|

-|Average_Total Bytes Received|Yes|Total Bytes Received|Count|Average|Average_Total Bytes Received|Computer, ObjectName, InstanceName, CounterPath, SourceSystem|

-|Average_Total Bytes Transmitted|Yes|Total Bytes Transmitted|Count|Average|Average_Total Bytes Transmitted|Computer, ObjectName, InstanceName, CounterPath, SourceSystem|

-|Average_Total Collisions|Yes|Total Collisions|Count|Average|Average_Total Collisions|Computer, ObjectName, InstanceName, CounterPath, SourceSystem|

-|Average_Total Packets Received|Yes|Total Packets Received|Count|Average|Average_Total Packets Received|Computer, ObjectName, InstanceName, CounterPath, SourceSystem|

-|Average_Total Packets Transmitted|Yes|Total Packets Transmitted|Count|Average|Average_Total Packets Transmitted|Computer, ObjectName, InstanceName, CounterPath, SourceSystem|

-|Average_Total Rx Errors|Yes|Total Rx Errors|Count|Average|Average_Total Rx Errors|Computer, ObjectName, InstanceName, CounterPath, SourceSystem|

-|Average_Total Tx Errors|Yes|Total Tx Errors|Count|Average|Average_Total Tx Errors|Computer, ObjectName, InstanceName, CounterPath, SourceSystem|

-|Average_Uptime|Yes|Uptime|Count|Average|Average_Uptime|Computer, ObjectName, InstanceName, CounterPath, SourceSystem|

-|Average_Used MBytes Swap Space|Yes|Used MBytes Swap Space|Count|Average|Average_Used MBytes Swap Space|Computer, ObjectName, InstanceName, CounterPath, SourceSystem|

-|Average_Used Memory kBytes|Yes|Used Memory kBytes|Count|Average|Average_Used Memory kBytes|Computer, ObjectName, InstanceName, CounterPath, SourceSystem|

-|Average_Used Memory MBytes|Yes|Used Memory MBytes|Count|Average|Average_Used Memory MBytes|Computer, ObjectName, InstanceName, CounterPath, SourceSystem|

-|Average_Users|Yes|Users|Count|Average|Average_Users|Computer, ObjectName, InstanceName, CounterPath, SourceSystem|

-|Average_Virtual Shared Memory|Yes|Virtual Shared Memory|Count|Average|Average_Virtual Shared Memory|Computer, ObjectName, InstanceName, CounterPath, SourceSystem|

-|Event|Yes|Event|Count|Average|Event|Source, EventLog, Computer, EventCategory, EventLevel, EventLevelName, EventID|

-|Heartbeat|Yes|Heartbeat|Count|Total|Heartbeat|Computer, OSType, Version, SourceComputerId|

-|Update|Yes|Update|Count|Average|Update|Computer, Product, Classification, UpdateState, Optional, Approved|

-## Microsoft.Purview/accounts

-|ScanBillingUnits|Yes|Scan Billing Units|Count|Total|Indicates the scan billing units.|ResourceId|

-|ScanCancelled|Yes|Scan Cancelled|Count|Total|Indicates the number of scans cancelled.|ResourceId|

-|ScanCompleted|Yes|Scan Completed|Count|Total|Indicates the number of scans completed successfully.|ResourceId|

-|ScanFailed|Yes|Scan Failed|Count|Total|Indicates the number of scans failed.|ResourceId|

-|ScanTimeTaken|Yes|Scan time taken|Seconds|Total|Indicates the total scan time in seconds.|ResourceId|

-|ListenerConnections-ClientError|No|ListenerConnections-ClientError|Count|Total|ClientError on ListenerConnections for Microsoft.Relay.|EntityName, |

-|ListenerConnections-ServerError|No|ListenerConnections-ServerError|Count|Total|ServerError on ListenerConnections for Microsoft.Relay.|EntityName, |

-|ListenerConnections-Success|No|ListenerConnections-Success|Count|Total|Successful ListenerConnections for Microsoft.Relay.|EntityName, |

-|SenderConnections-ClientError|No|SenderConnections-ClientError|Count|Total|ClientError on SenderConnections for Microsoft.Relay.|EntityName, |

-|SenderConnections-ServerError|No|SenderConnections-ServerError|Count|Total|ServerError on SenderConnections for Microsoft.Relay.|EntityName, |

-|SenderConnections-Success|No|SenderConnections-Success|Count|Total|Successful SenderConnections for Microsoft.Relay.|EntityName, |

-## Microsoft.ServiceBus/namespaces

-|AbandonMessage|Yes|Abandoned Messages|Count|Total|Abandoned Messages|EntityName|

-|CompleteMessage|Yes|Completed Messages|Count|Total|Completed Messages|EntityName|

-|CPUXNS|No|CPU (Deprecated)|Percent|Maximum|Service bus premium namespace CPU usage metric. This metric is depricated. Please use the CPU metric (NamespaceCpuUsage) instead.|No Dimensions|

-|NamespaceCpuUsage|No|CPU|Percent|Maximum|CPU usage metric for Premium SKU namespaces.|No Dimensions|

-|NamespaceMemoryUsage|No|Memory Usage|Percent|Maximum|Memory usage metric for Premium SKU namespaces.|No Dimensions|

-|ServerErrors|No|Server Errors.|Count|Total|Server Errors for Microsoft.ServiceBus.|EntityName, |

-|ServerSendLatency|Yes|Server Send Latency.|Milliseconds|Average|Server Send Latency.|EntityName|

-|SuccessfulRequests|No|Successful Requests|Count|Total|Total successful requests for a namespace|EntityName, |

-|ThrottledRequests|No|Throttled Requests.|Count|Total|Throttled Requests for Microsoft.ServiceBus.|EntityName, MessagingErrorSubCode|

-|UserErrors|No|User Errors.|Count|Total|User Errors for Microsoft.ServiceBus.|EntityName, |

-|WSXNS|No|Memory Usage (Deprecated)|Percent|Maximum|Service bus premium namespace memory usage metric. This metric is deprecated. Please use the Memory Usage (NamespaceMemoryUsage) metric instead.|No Dimensions|

-|InboundTraffic|Yes|Inbound Traffic|Bytes|Total|The inbound traffic of service|No Dimensions|

-|OutboundTraffic|Yes|Outbound Traffic|Bytes|Total|The outbound traffic of service|No Dimensions|

-|TotalConnectionCount|Yes|Connection Count|Count|Maximum|The amount of user connection.|No Dimensions|

-|ClientLatency|Yes|Average Client Latency|Milliseconds|Average|Average latency of client file operations to the Cache.|No Dimensions|

-|StorageTargetLatency|Yes|StorageTarget Latency|Milliseconds|Average|The average round trip latency of all the file operations the Cache sends to a partricular StorageTarget.|StorageTarget|

-|AppConnections|Yes|Connections|Count|Average|The number of bound sockets existing in the sandbox (w3wp.exe and its child processes). A bound socket is created by calling bind()/connect() APIs and remains until said socket is closed with CloseHandle()/closesocket().|Instance|

-|AverageMemoryWorkingSet|Yes|Average memory working set|Bytes|Average|The average amount of memory used by the app, in megabytes (MiB).|Instance|

-|AverageResponseTime|Yes|Average Response Time (deprecated)|Seconds|Average|The average time taken for the app to serve requests, in seconds.|Instance|

-|BytesReceived|Yes|Data In|Bytes|Total|The amount of incoming bandwidth consumed by the app, in MiB.|Instance|

-|BytesSent|Yes|Data Out|Bytes|Total|The amount of outgoing bandwidth consumed by the app, in MiB.|Instance|

-|CpuTime|Yes|CPU Time|Seconds|Total|The amount of CPU consumed by the app, in seconds. For more information about this metric. Please see: https://aka.ms/website-monitor-cpu-time-vs-cpu-percentage (CPU time vs CPU percentage).|Instance|

-|CurrentAssemblies|Yes|Current Assemblies|Count|Average|The current number of Assemblies loaded across all AppDomains in this application.|Instance|

-|FileSystemUsage|Yes|File System Usage|Bytes|Average|Percentage of filesystem quota consumed by the app.|No Dimensions|

-|FunctionExecutionCount|Yes|Function Execution Count|Count|Total|Function Execution Count|Instance|

-|FunctionExecutionUnits|Yes|Function Execution Units|Count|Total|Function Execution Units|Instance|

-|Gen0Collections|Yes|Gen 0 Garbage Collections|Count|Total|The number of times the generation 0 objects are garbage collected since the start of the app process. Higher generation GCs include all lower generation GCs.|Instance|

-|Gen1Collections|Yes|Gen 1 Garbage Collections|Count|Total|The number of times the generation 1 objects are garbage collected since the start of the app process. Higher generation GCs include all lower generation GCs.|Instance|

-|Gen2Collections|Yes|Gen 2 Garbage Collections|Count|Total|The number of times the generation 2 objects are garbage collected since the start of the app process.|Instance|

-|Handles|Yes|Handle Count|Count|Average|The total number of handles currently open by the app process.|Instance|

-|HealthCheckStatus|Yes|Health check status|Count|Average|Health check status|Instance|

-|Http101|Yes|Http 101|Count|Total|The count of requests resulting in an HTTP status code 101.|Instance|

-|Http2xx|Yes|Http 2xx|Count|Total|The count of requests resulting in an HTTP status code = 200 but < 300.|Instance|

-|Http3xx|Yes|Http 3xx|Count|Total|The count of requests resulting in an HTTP status code = 300 but < 400.|Instance|

-|Http401|Yes|Http 401|Count|Total|The count of requests resulting in HTTP 401 status code.|Instance|

-|Http403|Yes|Http 403|Count|Total|The count of requests resulting in HTTP 403 status code.|Instance|

-|Http404|Yes|Http 404|Count|Total|The count of requests resulting in HTTP 404 status code.|Instance|

-|Http406|Yes|Http 406|Count|Total|The count of requests resulting in HTTP 406 status code.|Instance|

-|Http4xx|Yes|Http 4xx|Count|Total|The count of requests resulting in an HTTP status code = 400 but < 500.|Instance|

-|Http5xx|Yes|Http Server Errors|Count|Total|The count of requests resulting in an HTTP status code = 500 but < 600.|Instance|

-|HttpResponseTime|Yes|Response Time|Seconds|Average|The time taken for the app to serve requests, in seconds.|Instance|

-|IoOtherBytesPerSecond|Yes|IO Other Bytes Per Second|BytesPerSecond|Total|The rate at which the app process is issuing bytes to I/O operations that don't involve data, such as control operations.|Instance|

-|IoOtherOperationsPerSecond|Yes|IO Other Operations Per Second|BytesPerSecond|Total|The rate at which the app process is issuing I/O operations that aren't read or write operations.|Instance|

-|IoReadBytesPerSecond|Yes|IO Read Bytes Per Second|BytesPerSecond|Total|The rate at which the app process is reading bytes from I/O operations.|Instance|

-|IoReadOperationsPerSecond|Yes|IO Read Operations Per Second|BytesPerSecond|Total|The rate at which the app process is issuing read I/O operations.|Instance|

-|IoWriteBytesPerSecond|Yes|IO Write Bytes Per Second|BytesPerSecond|Total|The rate at which the app process is writing bytes to I/O operations.|Instance|

-|IoWriteOperationsPerSecond|Yes|IO Write Operations Per Second|BytesPerSecond|Total|The rate at which the app process is issuing write I/O operations.|Instance|

-|MemoryWorkingSet|Yes|Memory working set|Bytes|Average|The current amount of memory used by the app, in MiB.|Instance|

-|PrivateBytes|Yes|Private Bytes|Bytes|Average|Private Bytes is the current size, in bytes, of memory that the app process has allocated that can't be shared with other processes.|Instance|

-|Requests|Yes|Requests|Count|Total|The total number of requests regardless of their resulting HTTP status code.|Instance|

-|RequestsInApplicationQueue|Yes|Requests In Application Queue|Count|Average|The number of requests in the application request queue.|Instance|

-|ScmCpuTime|Yes|ScmCpuTime|Seconds|Total|ScmCpuTime|Instance|

-|ScmPrivateBytes|Yes|ScmPrivateBytes|Bytes|Average|ScmPrivateBytes|Instance|

-|Threads|Yes|Thread Count|Count|Average|The number of threads currently active in the app process.|Instance|

-|TotalAppDomains|Yes|Total App Domains|Count|Average|The current number of AppDomains loaded in this application.|Instance|

-|TotalAppDomainsUnloaded|Yes|Total App Domains Unloaded|Count|Average|The total number of AppDomains unloaded since the start of the application.|Instance|

-|CdnTotalLatency|Yes|CdnTotalLatency|Seconds|Total|CdnTotalLatency|Instance|

-## Microsoft.AAD/domainServices

-|DscNodeStatus|Dsc Node Status|No|

-|JobLogs|Job Logs|No|

-|JobStreams|Job Streams|No|

-## Microsoft.BatchAI/workspaces

-|Category|Category Display Name|Costs To Export|

-||||

-|BaiClusterEvent|BaiClusterEvent|No|

-|BaiClusterNodeEvent|BaiClusterNodeEvent|No|

-|BaiJobEvent|BaiJobEvent|No|

-|guard|Kubernetes Guard|No|

-|Autoscaling|Autoscaling logs|Yes|

-## Microsoft.DocumentDB/databaseAccounts

-|DeliveryFailures|Delivery Failure Logs|No|

-## Microsoft.EventHub/namespaces

-## Microsoft.Insights/AutoscaleSettings

-## Microsoft.KeyVault/managedHSMs

-|AuditEvent|Audit Logs|No|

-## Microsoft.Logic/workflows

-## Microsoft.Network/applicationGateways

-## Microsoft.Network/azurefirewalls

-## Microsoft.Network/bastionHosts

-## Microsoft.Network/p2sVpnGateways

-## Microsoft.Network/virtualNetworkGateways

-## Microsoft.Network/vpnGateways

-|Audit|Audit Logs|No|

-## Microsoft.Purview/accounts

-|ScanStatusLogEvent|ScanStatus|Yes|

-|Analytics|Analytics|Yes|

-|DataConnectors|Data Collection ΓÇô Connectors|Yes|

-## Microsoft.ServiceBus/namespaces

-|AllLogs|Azure Web PubSub Service Logs.|Yes|

-## microsoft.web/hostingenvironments

-## microsoft.web/sites

-> Custom fields increases the amount of data collected in the Log Analytics workspace which can increase your cost. See [Manage usage and costs with Azure Monitor Logs](./manage-cost-storage.md#pricing-model) for details.

-By default, the tables of two data types - `Usage` and `AzureActivity` - keep data for at least 90 days at no charge. Increasing the workspace retention policy to more than 90 days also increases the retention policy of these tables. These tables are also free from data ingestion charges.

-* Scope for configuration of settings like [pricing tier](./manage-cost-storage.md#changing-pricing-tier), [retention](./manage-cost-storage.md#change-the-data-retention-period), and [data capping](./manage-cost-storage.md#manage-your-maximum-daily-data-volume).

-See [Azure Monitor pricing](https://azure.microsoft.com/pricing/details/monitor/) for detailed pricing and [Manage usage and costs with Azure Monitor Logs](manage-cost-storage.md) for guidance on reducing your costs. If you are using your Log Analytics workspace with services other than Azure Monitor, then see the documentation for those services for pricing information.

-The **\_BilledSize** column specifies the size in bytes of data that will be billed to your Azure account if **\_IsBillable** is true. [Learn more](manage-cost-storage.md#data-size) about the details of how the billed size is calculated.

-Log Analytics Dedicated Clusters use a Commitment Tier (formerly called capacity reservations) pricing model of at least 500 GB/day. Any usage above the tier level will be billed at effective per-GB rate of that Commitment Tier. Commitment Tier pricing information is available at the [Azure Monitor pricing page]( https://azure.microsoft.com/pricing/details/monitor/).

-The cluster Commitment Tier level is configured programmatically with Azure Resource Manager using the `Capacity` parameter under `Sku`. The `Capacity` is specified in units of GB and can have values of 500, 1000, 2000 or 5000 GB/day.

-There are two modes of billing for usage on a cluster. These can be specified by the `billingType` parameter when configuring your cluster.

-1. **Cluster (default)**--Billing for ingested data is done at the cluster level. The ingested data quantities from each workspace associated to a cluster are aggregated to calculate the daily bill for the cluster.

-2. **Workspaces**--The Commitment Tier costs for your Cluster are attributed proportionately to the workspaces in the cluster, by each workspace's data ingestion volume (after accounting for per-node allocations from [Microsoft Defender for Cloud](../../security-center/index.yml) for each workspace.) Details of pricing model are explained [here](./manage-cost-storage.md#log-analytics-dedicated-clusters).

-If your linked workspace is using legacy Per Node pricing tier, it will be billed based on data ingested against the cluster's Commitment Tier, and no longer Per Node. Per-node data allocations from Microsoft Defender for Cloud will continue to be applied.

-When you link workspaces to a cluster, the pricing tier is changed to cluster, and ingestion is billed based on cluster's Commitment Tier. Workspaces can be unlinked from a cluster at any time, and pricing tier change to per-GB.

-Complete details are billing for Log Analytics dedicated clusters are available [here](./manage-cost-storage.md#log-analytics-dedicated-clusters).

- - **Workspaces**--The costs for your cluster are attributed proportionately to the workspaces in the Cluster, with the cluster resource being billed some of the usage if the total ingested data for the day is under the commitment tier. See [Log Analytics Dedicated Clusters](./manage-cost-storage.md#log-analytics-dedicated-clusters) to learn more about the cluster pricing model.

-description: Learn how to change the pricing plan and manage data volume and retention policy for your Log Analytics workspace in Azure Monitor.

-

-# Manage usage and costs with Azure Monitor Logs

-> [!NOTE]

-> This article describes how to understand and control your costs for Azure Monitor Logs. A related article, [Monitoring usage and estimated costs](..//usage-estimated-costs.md) describes how to view usage and estimated costs across multiple Azure monitoring features using [Azure Cost Management + Billing](../logs/manage-cost-storage.md#viewing-log-analytics-usage-on-your-azure-bill). All prices and costs in this article are for example purposes only.

-Azure Monitor Logs is designed to scale and support collecting, indexing, and storing massive amounts of data per day from any source in your enterprise or deployed in Azure. Although this might be a primary driver for your organization, cost-efficiency is ultimately the underlying driver. To that end, it's important to understand that the cost of a Log Analytics workspace isn't based only on the volume of data collected; it's also dependent on the selected plan, and how long you stored data generated from your connected sources.

-This article reviews how you can proactively monitor ingested data volume and storage growth. It also discusses how to define limits to control those associated costs.

-## Pricing model

-The default pricing for Log Analytics is a **Pay-As-You-Go** model that's based on ingested data volume and, optionally, for longer data retention. Data volume is measured as the size of the data that will be stored in GB (10^9 bytes). Each Log Analytics workspace is charged as a separate service and contributes to the bill for your Azure subscription. The amount of data ingestion can be considerable, depending on the following factors:

- - The set of management solutions enabled and their configuration

- - The number and type of monitored resources

- - Type of data collected from each monitored resource

-

-<a name="commitment-tier"></a>

-### Commitment Tiers

-In addition to the Pay-As-You-Go model, Log Analytics has **Commitment Tiers**, which can save you as much as 30 percent compared to the Pay-As-You-Go price. With the commitment tier pricing, you can commit to buy data ingestion starting at 100 GB/day at a lower price than Pay-As-You-Go pricing. Any usage above the commitment level (overage) is billed at that same price per GB as provided by the current commitment tier. The commitment tiers have a 31-day commitment period from the time a commitment tier is selected.

-

-Billing for the commitment tiers is done on a daily basis. [Learn more](https://azure.microsoft.com/pricing/details/monitor/) about Log Analytics Pay-As-You-Go and Commitment Tier pricing.

-> [!NOTE]

-> Starting June 2, 2021, **Capacity Reservations** are now called **Commitment Tiers**. Data collected above your commitment tier level (overage) is now billed at the same price-per-GB as the current commitment tier level, lowering costs compared to the old method of billing at the Pay-As-You-Go rate, and reducing the need for users with large data volumes to fine-tune their commitment level. Three new commitment tiers were also added: 1000, 2000, and 5000 GB/day.

-### Data size calculation

-<a name="data-size"></a>

-<a name="free-data-types"></a>

-In all pricing tiers, an event's data size is calculated from a string representation of the properties that are stored in Log Analytics for this event, regardless of whether the data is sent from an agent or added during the ingestion process. This includes any [custom fields](custom-fields.md) that are added as data is collected and then stored in Log Analytics. Several properties common to all data types, including some [Log Analytics Standard Properties](./log-standard-columns.md), are excluded in the calculation of the event size. This includes `_ResourceId`, `_SubscriptionId`, `_ItemId`, `_IsBillable`, `_BilledSize` and `Type`. All other properties stored in Log Analytics are included in the calculation of the event size. Some data types are free from data ingestion charges altogether, for example the [AzureActivity](/azure/azure-monitor/reference/tables/azureactivity), [Heartbeat](/azure/azure-monitor/reference/tables/heartbeat), [Usage](/azure/azure-monitor/reference/tables/usage) and [Operation](/azure/azure-monitor/reference/tables/operation) types. Some solutions have more solution-specific policies about free data ingestion, for instance [Azure Migrate](https://azure.microsoft.com/pricing/details/azure-migrate/) makes dependency visualization data free for the first 180-days of a Server Assessment. To determine whether an event was excluded from billing for data ingestion, you can use the [_IsBillable](log-standard-columns.md#_isbillable) property as shown [below](#data-volume-for-specific-events). Usage is reported in GB (10^9 bytes).

-Also, some solutions, such as [Microsoft Defender for Cloud](https://azure.microsoft.com/pricing/details/azure-defender/), [Microsoft Sentinel](https://azure.microsoft.com/pricing/details/azure-sentinel/), and [Configuration management](https://azure.microsoft.com/pricing/details/automation/) have their own pricing models.

-### Log Analytics Dedicated Clusters

-[Log Analytics Dedicated Clusters](logs-dedicated-clusters.md) are collections of workspaces in a single managed Azure Data Explorer cluster to support advanced scenarios, like [Customer-Managed Keys](customer-managed-keys.md). Log Analytics Dedicated Clusters use the same commitment tier pricing model as workspaces, except that a cluster must have a commitment level of at least 500 GB/day. There is no Pay-As-You-Go option for clusters. The cluster commitment tier has a 31-day commitment period after the commitment level is increased. During the commitment period, the commitment tier level can't be reduced, but it can be increased at any time. When workspaces are associated to a cluster, the data ingestion billing for those workspaces is done at the cluster level using the configured commitment tier level. Learn more about [creating a Log Analytics Clusters](customer-managed-keys.md#create-cluster) and [associating workspaces to it](customer-managed-keys.md#link-workspace-to-cluster). For information about commitment tier pricing, see the [Azure Monitor pricing page]( https://azure.microsoft.com/pricing/details/monitor/).

-The cluster commitment tier level is programmatically configured with Azure Resource Manager using the `Capacity` parameter under `Sku`. The `Capacity` is specified in units of GB and can have values of 500, 1000, 2000 or 5000 GB/day. Any usage above the commitment level (overage) is billed at that same price per GB as provided by the current commitment tier. For more information, see [Azure Monitor customer-managed key](customer-managed-keys.md).

-There are two modes of billing for usage on a cluster. These can be specified by the `billingType` parameter when [creating a cluster](logs-dedicated-clusters.md#create-a-dedicated-cluster) or set after creation. The two modes are:

-In cluster billing options, data retention is billed for each workspace. Cluster billing starts when the cluster is created, regardless of whether workspaces are associated with the cluster. Workspaces associated to a cluster no longer have their own pricing tier.

-## Estimating the costs to manage your environment

-If you're not yet using Azure Monitor Logs, you can use the [Azure Monitor pricing calculator](https://azure.microsoft.com/pricing/calculator/?service=monitor) to estimate the cost of using Log Analytics. In the **Search** box, enter "Azure Monitor", and then select the resulting Azure Monitor tile. Scroll down the page to **Azure Monitor**, and then expand the **Log Analytics** section. Here you can enter the GB of data that you expect to collect. If you're already evaluating Azure Monitor Logs, you can use data statistics from your own environment. See below for how to determine the [number of monitored VMs](#understanding-nodes-sending-data) and the [volume of data your workspace is ingesting](#understanding-ingested-data-volume). If you're not yet running Log Analytics, here is some guidance for estimating data volumes:

-1. **Monitoring VMs:** with typical monitoring enabled, 1 GB to 3 GB of data month is ingested per monitored VM.

-2. **Monitoring Azure Kubernetes Service (AKS) clusters:** details on expected data volumes for monitoring a typical AKS cluster are available [here](../containers/container-insights-cost.md#estimating-costs-to-monitor-your-aks-cluster). Follow these [best practices](../containers/container-insights-cost.md#controlling-ingestion-to-reduce-cost) to control your AKS cluster monitoring costs.

-3. **Application monitoring:** the Azure Monitor pricing calculator includes a data volume estimator using on your application's usage and based on a statistical analysis of Application Insights data volumes. In the Application Insights section of the pricing calculator, toggle the switch next to "Estimate data volume based on application activity" to use this.

-## Viewing Log Analytics usage on your Azure bill

-The easiest way to view your billed usage for a particular Log Analytics workspace is to go to the **Overview** page of the workspace and click **View Cost** in the upper right corner of the Essentials section at the top of the page. This will launch the Cost Analysis from Azure Cost Management + Billing already scoped to this workspace. You might need additional access to Cost Management data ([learn more](../../cost-management-billing/costs/assign-access-acm-data.md))

-Alternatively, you can start in the [Azure Cost Management + Billing](../../cost-management-billing/costs/quick-acm-cost-analysis.md?toc=%2fazure%2fbilling%2fTOC.json) hub. here you can use the "Cost analysis" functionality to view your Azure resource expenses. To track your Log Analytics expenses, you can add a filter by "Resource type" (to microsoft.operationalinsights/workspace for Log Analytics and microsoft.operationalinsights/cluster for Log Analytics Clusters). For **Group by**, select **Meter category** or **Meter**. Other services, like Microsoft Defender for Cloud and Microsoft Sentinel, also bill their usage against Log Analytics workspace resources. To see the mapping to the service name, you can select the Table view instead of a chart.

-<a name="export-usage"></a>

-<a name="download-usage"></a>

-To gain more understanding of your usage, you can [download your usage from the Azure portal](../../cost-management-billing/understand/download-azure-daily-usage.md). For step-by-step instructions, review this [tutorial](../../cost-management-billing/costs/tutorial-export-acm-data.md).

-In the downloaded spreadsheet, you can see usage per Azure resource (for example, Log Analytics workspace) per day. In this Excel spreadsheet, usage from your Log Analytics workspaces can be found by first filtering on the "Meter Category" column to show "Log Analytics", "Insight and Analytics" (used by some of the legacy pricing tiers), and "Azure Monitor" (used by commitment tier pricing tiers), and then adding a filter on the "Instance ID" column that is "contains workspace" or "contains cluster" (the latter to include Log Analytics Cluster usage). The usage is shown in the "Consumed Quantity" column, and the unit for each entry is shown in the "Unit of Measure" column. For more information, see [Review your individual Azure subscription bill](../../cost-management-billing/understand/review-individual-bill.md).

-## Understand your usage and optimizing your pricing tier

-<a name="understand-your-usage-and-estimate-costs"></a>

-To learn about your usage trends and choose the most cost-effective log Analytics pricing tier, use **Log Analytics Usage and Estimated Costs**. This shows how much data is collected by each solution, how much data is being retained, and an estimate of your costs for each pricing tier based on recent data ingestion patterns.

-To explore your data in more detail, select on the icon in the upper-right corner of either chart on the **Usage and Estimated Costs** page. Now you can work with this query to explore more details of your usage.

-From the **Usage and Estimated Costs** page, you can review your data volume for the month. This includes all the billable data received and retained in your Log Analytics workspace.

-

-Log Analytics charges are added to your Azure bill. You can see details of your Azure bill under the **Billing** section of the Azure portal or in the [Azure Billing Portal](https://account.windowsazure.com/Subscriptions).

-## Changing pricing tier

-To change the Log Analytics pricing tier of your workspace:

-1. In the Azure portal, open **Usage and estimated costs** from your workspace; you'll see a list of each of the pricing tiers available to this workspace.

-2. Review the estimated costs for each pricing tier. This estimate is based on the last 31 days of usage, so this cost estimate relies on the last 31 days being representative of your typical usage. In the example below, you can see how, based on the data patterns from the last 31 days, this workspace would cost less in the Pay-As-You-Go tier (#1) compared to the 100 GB/day commitment tier (#2).

-

-3. After reviewing the estimated costs based on the last 31 days of usage, if you decide to change the pricing tier, select **Select**.

-### Changing pricing tier via ARM

-You can also [set the pricing tier via Azure Resource Manager](./resource-manager-workspace.md) using the `sku` object to set the pricing tier, and the `capacityReservationLevel` parameter if the pricing tier is `capacityresrvation`. (Learn more about [setting workspace properties via ARM](/azure/templates/microsoft.operationalinsights/2020-08-01/workspaces?tabs=json#workspacesku-object).) Here is a sample Azure Resource Manager template to set your workspace to a 300 GB/day commitment tier (in Resource Manager, it's called `capacityreservation`).

-```

-{

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

- "contentVersion": "1.0.0.0",

- "resources": [

- {

- "name": "YourWorkspaceName",

- "type": "Microsoft.OperationalInsights/workspaces",

- "apiVersion": "2020-08-01",

- "location": "yourWorkspaceRegion",

- "properties": {

- "sku": {

- "name": "capacityreservation",

- "capacityReservationLevel": 300

- }

- }

- }

- ]

-}

-```

-To use this template in PowerShell, after [installing the Azure Az PowerShell module](/powershell/azure/install-az-ps), sign in to Azure using `Connect-AzAccount`, select the subscription containing your workspace using `Select-AzSubscription -SubscriptionId YourSubscriptionId`, and apply the template (saved in a file named template.json):

-```

-New-AzResourceGroupDeployment -ResourceGroupName "YourResourceGroupName" -TemplateFile "template.json"

-```

-To set the pricing tier to other values such as Pay-As-You-Go (called `pergb2018` for the SKU), omit the `capacityReservationLevel` property. Learn more about [creating ARM templates](../../azure-resource-manager/templates/template-tutorial-create-first-template.md), [adding a resource to your template](../../azure-resource-manager/templates/template-tutorial-add-resource.md), and [applying templates](../resource-manager-samples.md).

-### Tracking pricing tier changes

-Changes to a workspace's pricing pier are recorded in the [Activity Log](../essentials/activity-log.md) with an event with the Operation named "Create Workspace". The event's **Change history** tab will show the old and new pricing tiers in the `properties.sku.name` row. Click the "Activity Log" option from your workspace to see events scoped to a particular workspace. To monitor changes the pricing tier, you can create an alert for the "Create Workspace" operation.

-## Legacy pricing tiers

-Subscriptions that contained a Log Analytics workspace or Application Insights resource on April 2, 2018, or are linked to an Enterprise Agreement that started before February 1, 2019 and is still active, will continue to have access to use the legacy pricing tiers: **Free Trial**, **Standalone (Per GB)**, and **Per Node (OMS)**. Workspaces in the Free Trial pricing tier will have daily data ingestion limited to 500 MB (except for security data types collected by [Microsoft Defender for Cloud](../../security-center/index.yml)) and the data retention is limited to seven days. The Free Trial pricing tier is intended only for evaluation purposes. No SLA is provided for the Free tier. Workspaces in the Standalone or Per Node pricing tiers have user-configurable retention from 30 to 730 days. Creating new workspaces in (or moving existing workspaces into) the Free Trial pricing tier is possible until July 1, 2022.

-Usage on the Standalone pricing tier is billed by the ingested data volume. It is reported in the **Log Analytics** service and the meter is named "Data Analyzed".

-The Per Node pricing tier charges per monitored VM (node) on an hour granularity. For each monitored node, the workspace is allocated 500 MB of data per day that's not billed. This allocation is calculated with hourly granularity and is aggregated at the workspace level each day. Data ingested above the aggregate daily data allocation is billed per GB as data overage. On your bill, the service will be **Insight and Analytics** for Log Analytics usage if the workspace is in the Per Node pricing tier. Usage is reported on three meters:

-> [!TIP]

-> If your workspace has access to the **Per Node** pricing tier but you're wondering whether it would cost less in a Pay-As-You-Go tier, you can [use the query below](#evaluating-the-legacy-per-node-pricing-tier) to easily get a recommendation.

-Workspaces created before April 2016 can continue to use the **Standard** and **Premium** pricing tiers that have fixed data retention of 30 days and 365 days, respectively. New workspaces can't be created in the **Standard** or **Premium** pricing tiers, and if a workspace is moved out of these tiers, it can't be moved back. Data ingestion meters on your Azure bill for these legacy tiers are called "Data analyzed."

-### Legacy pricing tiers and Microsoft Defender for Cloud

-There are also some behaviors between the use of legacy Log Analytics tiers and how usage is billed for [Microsoft Defender for Cloud](../../security-center/index.yml).

-More details of pricing tier limitations are available at [Azure subscription and service limits, quotas, and constraints](../../azure-resource-manager/management/azure-subscription-service-limits.md#log-analytics-workspaces).

-None of the legacy pricing tiers have regional-based pricing.

-> [!NOTE]

-> To use the entitlements that come from purchasing OMS E1 Suite, OMS E2 Suite, or OMS Add-On for System Center, choose the Log Analytics *Per Node* pricing tier.

-## Log Analytics and Microsoft Defender for Cloud

-<a name="ASC"></a>

-[Microsoft Defender for Servers (part of Defender for Cloud)](../../security-center/index.yml) billing is closely tied to Log Analytics billing. Microsoft Defender for Servers [bills by the number of monitored services](https://azure.microsoft.com/pricing/details/azure-defender/) and provides 500 MB/server/day data allocation that is applied to the following subset of [security data types](/azure/azure-monitor/reference/tables/tables-category#security) (WindowsEvent, SecurityAlert, SecurityBaseline, SecurityBaselineSummary, SecurityDetection, SecurityEvent, WindowsFirewall, MaliciousIPCommunication, LinuxAuditLog, SysmonEvent, ProtectionStatus) and the Update and UpdateSummary data types when the Update Management solution isn't running on the workspace or solution targeting is enabled ([learn more](../../security-center/security-center-pricing.md#what-data-types-are-included-in-the-500-mb-data-daily-allowance)). The count of monitored servers is calculated on an hourly granularity. The daily data allocation contributions from each monitored server are aggregated at the workspace level. If the workspace is in the legacy Per Node pricing tier, the Microsoft Defender for Cloud and Log Analytics allocations are combined and applied jointly to all billable ingested data.

-To view the daily Defender for Servers data allocations for a workspace, you need to [export your usage details](#viewing-log-analytics-usage-on-your-azure-bill), open the usage spreadsheet and filter the meter category to "Insight and Analytics". You'll then see usage with the meter name "Data Included per Node" which has a zero price per GB. The consumed quantity column will show the number of GBs of Defender for Cloud data allocation for the day. (If the workspace is in the legacy Per Node Log Analytics pricing tier, this meter will also include the data allocations from this Log Analytics pricing tier.)

-## Change the data retention period

-The following steps describe how to configure how long log data is kept by in your workspace. Data retention at the workspace level can be configured from 30 to 730 days (2 years) for all workspaces unless they're using the legacy Free Trial pricing tier. Retention for individual data types can be set as low as 4 days. [Learn more](https://azure.microsoft.com/pricing/details/monitor/) about pricing for longer data retention. To retain data longer than 730 days, consider using [Log Analytics workspace data export](logs-data-export.md).

-### Workspace level default retention

-To set the default retention for your workspace:

-

-1. In the Azure portal, from your workspace, select **Usage and estimated costs** in the left pane.

-2. On the **Usage and estimated costs** page, select **Data Retention** at the top of the page.

-3. On the pane, move the slider to increase or decrease the number of days, and then select **OK**. If you're on the *free* tier, you can't modify the data retention period; you need to upgrade to the paid tier to control this setting.

-When the retention is lowered, there's a grace period of several days before the data older than the new retention setting is removed.

-The **Data Retention** page allows retention settings of 30, 31, 60, 90, 120, 180, 270, 365, 550, and 730 days. If another setting is required, that can be configured using [Azure Resource Manager](./resource-manager-workspace.md) using the `retentionInDays` parameter. When you set the data retention to 30 days, you can trigger an immediate purge of older data using the `immediatePurgeDataOn30Days` parameter (eliminating the grace period). This might be useful for compliance-related scenarios where immediate data removal is imperative. This immediate purge functionality is only exposed via Azure Resource Manager.

-Workspaces with 30 days retention might actually retain data for 31 days. If it's imperative that data be kept for only 30 days, use the Azure Resource Manager to set the retention to 30 days and with the `immediatePurgeDataOn30Days` parameter.

-By default, two data types - `Usage` and `AzureActivity` - are retained for a minimum of 90 days at no charge. When you increase the workspace retention to more than 90 days, you also increase the retention of these data types, and you'll be charged for retaining this data beyond the 90-day period. These data types are also free from data ingestion charges.

-Data types from workspace-based Application Insights resources (`AppAvailabilityResults`, `AppBrowserTimings`, `AppDependencies`, `AppExceptions`, `AppEvents`, `AppMetrics`, `AppPageViews`, `AppPerformanceCounters`, `AppRequests`, `AppSystemEvents`, and `AppTraces`) are also retained for 90 days at no charge by default. Their retention can be adjusted using the retention by data type functionality.

-> [!TIP]

-> The Log Analytics [purge API](/rest/api/loganalytics/workspacepurge/purge) doesn't affect retention billing and is intended to be used for very limited cases. **To reduce your retention bill, the retention period must be reduced either for the workspace or for specific data types.** Learn more about managing [personal data stored in Log Analytics and Application Insights](./personal-data-mgmt.md).

-### Retention by data type

-It's also possible to specify different retention settings for individual data types from 4 to 730 days (except for workspaces in the legacy Free Trial pricing tier) that override the workspace-level default retention. Each data type is a sub-resource of the workspace. For example, the SecurityEvent table can be addressed in [Azure Resource Manager](../../azure-resource-manager/management/overview.md) as:

-```

-/subscriptions/00000000-0000-0000-0000-00000000000/resourceGroups/MyResourceGroupName/providers/Microsoft.OperationalInsights/workspaces/MyWorkspaceName/Tables/SecurityEvent

-```

-Note that the data type (table) is case-sensitive. To get the current per-data-type retention settings of a particular data type (in this example SecurityEvent), use:

-```JSON

- GET /subscriptions/00000000-0000-0000-0000-00000000000/resourceGroups/MyResourceGroupName/providers/Microsoft.OperationalInsights/workspaces/MyWorkspaceName/Tables/SecurityEvent?api-version=2017-04-26-preview

-```

-> [!NOTE]

-> Retention is only returned for a data type if the retention is explicitly set for it. Data types that don't have retention explicitly set (and thus inherit the workspace retention) don't return anything from this call.

-To get the current per-data-type retention settings for all data types in your workspace that have had their per-data-type retention set, just omit the specific data type, for example:

-```JSON

- GET /subscriptions/00000000-0000-0000-0000-00000000000/resourceGroups/MyResourceGroupName/providers/Microsoft.OperationalInsights/workspaces/MyWorkspaceName/Tables?api-version=2017-04-26-preview

-```

-To set the retention of a particular data type (in this example SecurityEvent) to 730 days, use:

-```JSON

- PUT /subscriptions/00000000-0000-0000-0000-00000000000/resourceGroups/MyResourceGroupName/providers/Microsoft.OperationalInsights/workspaces/MyWorkspaceName/Tables/SecurityEvent?api-version=2017-04-26-preview

- {

- "properties":

- {

- "retentionInDays": 730

- }

- }

-```

-Valid values for `retentionInDays` are from 4 through 730.

-A great tool to connect directly to Azure Resource Manager to set retention by data type is the OSS tool [ARMclient](https://github.com/projectkudu/ARMClient). Learn more about ARMclient from articles by [David Ebbo](http://blog.davidebbo.com/2015/01/azure-resource-manager-client.html) and Daniel Bowbyes. Here's an example using ARMClient, setting SecurityEvent data to a 730-day retention:

-```

-armclient PUT /subscriptions/00000000-0000-0000-0000-00000000000/resourceGroups/MyResourceGroupName/providers/Microsoft.OperationalInsights/workspaces/MyWorkspaceName/Tables/SecurityEvent?api-version=2017-04-26-preview "{properties: {retentionInDays: 730}}"

-```

-> [!TIP]

-> Setting retention on individual data types can be used to reduce your costs for data retention. For data collected starting in October 2019 (when this feature was released), reducing the retention for some data types can reduce your retention cost over time. For data collected earlier, setting a lower retention for an individual type won't affect your retention costs.

-## Manage your maximum daily data volume

-You can configure a daily cap and limit the daily ingestion for your workspace, but use care because your goal shouldn't be to hit the daily limit. Otherwise, you lose data for the remainder of the day, which can impact other Azure services and solutions whose functionality may depend on up-to-date data being available in the workspace. As a result, your ability to observe and receive alerts when the health conditions of resources supporting IT services are impacted. The daily cap is intended to be used as a way to manage an **unexpected increase** in data volume from your managed resources and stay within your limit, or when you want to limit unplanned charges for your workspace. It's not appropriate to set a daily cap so that it's met each day on a workspace.

-Each workspace has its daily cap applied on a different hour of the day. The reset hour is shown in the **Daily Cap** page (see below). This reset hour can't be configured.

-Soon after the daily limit is reached, the collection of billable data types stops for the rest of the day. Latency inherent in applying the daily cap means that the cap isn't applied at precisely the specified daily cap level. A warning banner appears across the top of the page for the selected Log Analytics workspace, and an operation event is sent to the *Operation* table under the **LogManagement** category. Data collection resumes after the reset time defined under *Daily limit will be set at*. We recommend defining an alert rule that's based on this operation event, configured to notify when the daily data limit is reached. For more information, see [Alert when daily cap is reached](#alert-when-daily-cap-is-reached) section.

-> [!NOTE]

-> The daily cap can't stop data collection at precisely the specified cap level and some excess data is expected, particularly if the workspace is receiving high volumes of data. If data is collected above the cap, it's still billed. For a query that is helpful in studying the daily cap behavior, see the [View the effect of the Daily Cap](#view-the-effect-of-the-daily-cap) section in this article.

-> [!WARNING]

-> For workspaces with Microsoft Defender for Cloud, the daily cap doesn't stop the collection of data types **WindowsEvent**, **SecurityAlert**, **SecurityBaseline**, **SecurityBaselineSummary**, **SecurityDetection**, **SecurityEvent**, **WindowsFirewall**, **MaliciousIPCommunication**, **LinuxAuditLog**, **SysmonEvent**, **ProtectionStatus**, **Update**, and **UpdateSummary**, except for workspaces in which Microsoft Defender for Cloud was installed before June 19, 2017.

-### Identify what daily data limit to define

-To understand the data ingestion trend and the daily volume cap to define, review [Log Analytics Usage and estimated costs](../usage-estimated-costs.md). Consider it with care, because you can't monitor your resources after the limit is reached.

-### Set the daily cap

-The following steps describe how to configure a limit to manage the volume of data that Log Analytics workspace will ingest per day.

-1. From your workspace, select **Usage and estimated costs** in the left pane.

-2. On the **Usage and estimated costs** page for the selected workspace, select **Data Cap** at the top of the page.

-3. By default, **Daily cap** is set to **OFF**. To enable it, select **ON**, and then set the data volume limit in GB/day.

-You can use Azure Resource Manager to configure the daily cap. To configure it, set the `dailyQuotaGb` parameter under `WorkspaceCapping` as described at [Workspaces - Create Or Update](/rest/api/loganalytics/workspaces/createorupdate#workspacecapping).

-You can track changes made to the daily cap using this query:

-```kusto

-_LogOperation | where Operation == "Workspace Configuration" | where Detail contains "Daily quota"

-```

-Learn more about the [_LogOperation](./monitor-workspace.md) function.

-### View the effect of the daily cap

-To view the effect of the daily cap, it's important to account for the security data types that aren't included in the daily cap, and the reset hour for your workspace. The daily cap reset hour is visible on the **Daily Cap** page. The following query can be used to track the data volumes that are subject to the daily cap between daily cap resets. In this example, the workspace's reset hour is 14:00. You'll need to update this for your workspace.

-```kusto

-let DailyCapResetHour=14;

-Usage

-| where DataType !in ("SecurityAlert", "SecurityBaseline", "SecurityBaselineSummary", "SecurityDetection", "SecurityEvent", "WindowsFirewall", "MaliciousIPCommunication", "LinuxAuditLog", "SysmonEvent", "ProtectionStatus", "WindowsEvent")

-| where TimeGenerated > ago(32d)

-| extend StartTime=datetime_add("hour",-1*DailyCapResetHour,StartTime)

-| where StartTime > startofday(ago(31d))

-| where IsBillable

-| summarize IngestedGbBetweenDailyCapResets=sum(Quantity)/1000. by day=bin(StartTime , 1d) // Quantity in units of MB

-| render areachart

-```

-Add `Update` and `UpdateSummary` data types to the `where Datatype` line when the Update Management solution is not running on the workspace or solution targeting is enabled ([learn more](../../security-center/security-center-pricing.md#what-data-types-are-included-in-the-500-mb-data-daily-allowance).)

-### Alert when daily cap is reached

-Azure portal has a visual cue when your data limit threshold is met, but this behavior doesn't necessarily align to how you manage operational issues that require immediate attention. To receive an alert notification, you can create a new alert rule in Azure Monitor. To learn more, see [how to create, view, and manage alerts](../alerts/alerts-metric.md).

-To get you started, here are the recommended settings for the alert querying the `Operation` table using the `_LogOperation` function ([learn more](./monitor-workspace.md)).

- - Signal name: Custom log search

- - Search query: `_LogOperation | where Operation =~ "Data collection stopped" | where Detail contains "OverQuota"`

- - Based on: Number of results

- - Condition: Greater than

- - Threshold: 0

- - Period: 5 (minutes)

- - Frequency: 5 (minutes)

-After an alert is defined and the limit is reached, an alert is triggered and performs the response defined in the Action Group. It can notify your team in the following ways:

-## Investigate your Log Analytics usage

-<a name="troubleshooting-why-usage-is-higher-than-expected"></a>

-Higher usage is caused by one, or both, of the following:

-If you observe high data ingestion reported using the `Usage` records (see the [Data volume by solution](#data-volume-by-solution) section), but you don't observe the same results summing `_BilledSize` directly on the [data type](#data-volume-for-specific-events), it's possible that you have significant late-arriving data. For information about how to diagnose this, see the [Late arriving data](#late-arriving-data) section of this article.

-### Log Analytics Workspace Insights

-Start understanding your data volumes in the **Usage** tab of the [Log Analytics Workspace Insights workbook](log-analytics-workspace-insights-overview.md). On the **Usage Dashboard**, you can easily see:

-You can pivot to the **Additional Queries** to easily execution more queries useful to understanding your data patterns.

-Learn more about the [capabilities of the Usage tab](log-analytics-workspace-insights-overview.md#usage-tab).

-While this workbook can answer many of the questions without even needing to run a query, to answer more specific questions or do deeper analyses, the queries in the next two sections will help to get you started.

-## Understanding ingested data volume

-On the **Usage and Estimated Costs** page, the *Data ingestion per solution* chart shows the total volume of data sent and how much is being sent by each solution. You can determine trends like whether the overall data usage (or usage by a particular solution) is growing, remaining steady, or decreasing.

-### Data volume for specific events

-To look at the size of ingested data for a particular set of events, you can query the specific table (in this example `Event`) and then restrict the query to the events of interest (in this example event ID 5145 or 5156):

-```kusto

-Event

-| where TimeGenerated > startofday(ago(31d)) and TimeGenerated < startofday(now())

-| where EventID == 5145 or EventID == 5156

-| where _IsBillable == true

-| summarize count(), Bytes=sum(_BilledSize) by EventID, bin(TimeGenerated, 1d)

-```

-Note that the clause `where _IsBillable = true` filters out data types from certain solutions for which there is no ingestion charge. [Learn more](./log-standard-columns.md#_isbillable) about `_IsBillable`.

-### Data volume by solution

-The query used to view the billable data volume by solution over the last month (excluding the last partial day) can be built using the [Usage](/azure/azure-monitor/reference/tables/usage) data type as:

-```kusto

-Usage

-| where TimeGenerated > ago(32d)

-| where StartTime >= startofday(ago(31d)) and EndTime < startofday(now())

-| where IsBillable == true

-| summarize BillableDataGB = sum(Quantity) / 1000. by bin(StartTime, 1d), Solution

-| render columnchart

-```

-The clause with `TimeGenerated` is only to ensure that the query experience in the Azure portal looks back beyond the default 24 hours. When using the **Usage** data type, `StartTime` and `EndTime` represent the time buckets for which results are presented.

-### Data volume by type

-You can drill in further to see data trends for by data type:

-```kusto

-Usage

-| where TimeGenerated > ago(32d)

-| where StartTime >= startofday(ago(31d)) and EndTime < startofday(now())

-| where IsBillable == true

-| summarize BillableDataGB = sum(Quantity) / 1000. by bin(StartTime, 1d), DataType

-| render columnchart

-```

-Or to see a table by solution and type for the last month,

-```kusto

-Usage

-| where TimeGenerated > ago(32d)

-| where StartTime >= startofday(ago(31d)) and EndTime < startofday(now())

-| where IsBillable == true

-| summarize BillableDataGB = sum(Quantity) / 1000 by Solution, DataType

-| sort by Solution asc, DataType asc

-```

-### Data volume by computer

-The **Usage** data type doesn't include information at the computer level. To see the **size** of ingested billable data per computer, use the **_BilledSize** [property](./log-standard-columns.md#_billedsize), which provides the size in bytes:

-```kusto

-find where TimeGenerated > ago(24h) project _BilledSize, _IsBillable, Computer, Type

-| where _IsBillable == true and Type != "Usage"

-| extend computerName = tolower(tostring(split(Computer, '.')[0]))

-| summarize BillableDataBytes = sum(_BilledSize) by computerName

-| sort by BillableDataBytes desc nulls last

-```

-The **_IsBillable** [property](./log-standard-columns.md#_isbillable) specifies whether the ingested data will incur charges. The **Usage** type is omitted because this is only for analytics of data trends.

-To see the **count** of billable events ingested per computer, use

-```kusto

-find where TimeGenerated > ago(24h) project _IsBillable, Computer

-| where _IsBillable == true and Type != "Usage"

-| extend computerName = tolower(tostring(split(Computer, '.')[0]))

-| summarize eventCount = count() by computerName

-| sort by eventCount desc nulls last

-```

-> [!TIP]

-> Use these `find` queries sparingly because scans across data types are [resource intensive](./query-optimization.md#query-performance-pane) to execute. If you don't need results **per computer**, query on the **Usage** data type.

-### Data volume by Azure resource, resource group, or subscription

-For data from nodes hosted in Azure, you can get the **size** of ingested data __per computer__, use the [_ResourceId property](./log-standard-columns.md#_resourceid), which provides the full path to the resource:

-```kusto

-find where TimeGenerated > ago(24h) project _ResourceId, _BilledSize, _IsBillable

-| where _IsBillable == true

-| summarize BillableDataBytes = sum(_BilledSize) by _ResourceId | sort by BillableDataBytes nulls last

-```

-For data from nodes hosted in Azure, you can get the **size** of ingested data __per Azure subscription__ by using the **_SubscriptionId** property as:

-```kusto

-find where TimeGenerated > ago(24h) project _BilledSize, _IsBillable, _SubscriptionId

-| where _IsBillable == true

-| summarize BillableDataBytes = sum(_BilledSize) by _SubscriptionId | sort by BillableDataBytes nulls last

-```

-To get data volume by resource group, you can parse **_ResourceId**:

-```kusto

-find where TimeGenerated > ago(24h) project _ResourceId, _BilledSize, _IsBillable

-| where _IsBillable == true

-| summarize BillableDataBytes = sum(_BilledSize) by _ResourceId

-| extend resourceGroup = tostring(split(_ResourceId, "/")[4] )

-| summarize BillableDataBytes = sum(BillableDataBytes) by resourceGroup | sort by BillableDataBytes nulls last

-```

-If needed, you can also parse the **_ResourceId** more fully:

-```Kusto

-| parse tolower(_ResourceId) with "/subscriptions/" subscriptionId "/resourcegroups/"

- resourceGroup "/providers/" provider "/" resourceType "/" resourceName

-```

-> [!TIP]

-> Use these `find` queries sparingly because scans across data types are [resource intensive](./query-optimization.md#query-performance-pane) to execute. If you don't need results per subscription, resouce group, or resource name, query on the **Usage** data type.

-> [!WARNING]

-> Some of the fields of the **Usage** data type, while still in the schema, have been deprecated and their values are no longer populated.

-> These are **Computer**, as well as fields related to ingestion (**TotalBatches**, **BatchesWithinSla**, **BatchesOutsideSla**, **BatchesCapped** and **AverageProcessingTimeMs**).

-## Tips for reducing data volume

-This table lists some suggestions for reducing the volume of logs collected.

-| Source of high data volume | How to reduce data volume |

-| -- | - |

-| Data Collection Rules | The [Azure Monitor Agent](../agents/azure-monitor-agent-overview.md) uses Data Collection Rules to manage the collection of data. You can [limit the collection of data](../agents/data-collection-rule-azure-monitor-agent.md#limit-data-collection-with-custom-xpath-queries) using custom XPath queries. |

-| Container Insights | [Configure Container Insights](../containers/container-insights-cost.md#controlling-ingestion-to-reduce-cost) to collect only the data you required. |

-| Microsoft Sentinel | Review any [Sentinel data sources](../../sentinel/connect-data-sources.md) that you recently enabled as sources of additional data volume. [Learn more](../../sentinel/azure-sentinel-billing.md) about Sentinel costs and billing. |

-| Security events | Select [common or minimal security events](../../security-center/security-center-enable-data-collection.md#data-collection-tier). <br> Change the security audit policy to collect only needed events. In particular, review the need to collect events for: <br> - [audit filtering platform](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/dd772749(v=ws.10)). <br> - [audit registry](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/dd941614(v%3dws.10)). <br> - [audit file system](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/dd772661(v%3dws.10)). <br> - [audit kernel object](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/dd941615(v%3dws.10)). <br> - [audit handle manipulation](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/dd772626(v%3dws.10)). <br> - audit removable storage. |

-| Performance counters | Change the [performance counter configuration](../agents/data-sources-performance-counters.md) to: <br> - Reduce the frequency of collection. <br> - Reduce the number of performance counters. |

-| Event logs | Change the [event log configuration](../agents/data-sources-windows-events.md) to: <br> - Reduce the number of event logs collected. <br> - Collect only required event levels. For example, do not collect *Information* level events. |

-| Syslog | Change the [syslog configuration](../agents/data-sources-syslog.md) to: <br> - Reduce the number of facilities collected. <br> - Collect only required event levels. For example, do not collect *Info* and *Debug* level events. |

-| AzureDiagnostics | Change the [resource log collection](../essentials/diagnostic-settings.md#create-in-azure-portal) to: <br> - Reduce the number of resources that send logs to Log Analytics. <br> - Collect only required logs. |

-| Solution data from computers that don't need the solution | Use [solution targeting](../insights/solution-targeting.md) to collect data from only required groups of computers. |

-| Application Insights | Review options for [managing Application Insights data volume](../app/pricing.md#managing-your-data-volume). |

-| [SQL Analytics](../insights/azure-sql.md) | Use [Set-AzSqlServerAudit](/powershell/module/az.sql/set-azsqlserveraudit) to tune the auditing settings. |

-## Create an alert when data collection is high

-This section describes how to create an alert when the data volume in the last 24 hours exceeded a specified amount, using Azure Monitor [Log Alerts](../alerts/alerts-unified-log.md).

-To alert if the billable data volume ingested in the last 24 hours was greater than 50 GB:

- - **Signal Name** select **Custom log search**

- - **Search query** to `Usage | where IsBillable | summarize DataGB = sum(Quantity / 1000.) | where DataGB > 50`.

- - **Alert logic** is **Based on** *number of results* and **Condition** is *Greater than* a **Threshold** of *0*

- - **Time period** of *1440* minutes and **Alert frequency** to every *1440* minutes to run once a day.

- - **Name** to *Billable data volume greater than 50 GB in 24 hours*

- - **Severity** to *Warning*

-To be notified when the log alert matches criteria, specify an existing or create a new [action group](../alerts/action-groups.md).

-When you receive an alert, use the steps in the above sections about how to troubleshoot why usage is higher than expected.

-## Querying for common data types

-To dig deeper into the source of data for a particular data type, here are some useful example queries:

-+ **Workspace-based Application Insights** resources

- - Learn more at [Manage usage and costs for Application Insights](../app/pricing.md#data-volume-for-workspace-based-application-insights-resources)

-+ **Security** solution

- - `SecurityEvent | summarize AggregatedValue = count() by EventID`

-+ **Log Management** solution

- - `Usage | where Solution == "LogManagement" and iff(isnotnull(toint(IsBillable)), IsBillable == true, IsBillable == "true") == true | summarize AggregatedValue = count() by DataType`

-+ **Perf** data type

- - `Perf | summarize AggregatedValue = count() by CounterPath`

- - `Perf | summarize AggregatedValue = count() by CounterName`

-+ **Event** data type

- - `Event | summarize AggregatedValue = count() by EventID`

- - `Event | summarize AggregatedValue = count() by EventLog, EventLevelName`

-+ **Syslog** data type

- - `Syslog | summarize AggregatedValue = count() by Facility, SeverityLevel`

- - `Syslog | summarize AggregatedValue = count() by ProcessName`

-+ **AzureDiagnostics** data type

- - `AzureDiagnostics | summarize AggregatedValue = count() by ResourceProvider, ResourceId`

-

-## Understanding nodes sending data

-To understand the number of nodes that are reporting heartbeats from the agent each day in the last month, use this query:

-```kusto

-Heartbeat

-| where TimeGenerated > startofday(ago(31d))

-| summarize nodes = dcount(Computer) by bin(TimeGenerated, 1d)

-| render timechart

-```

-The get a count of nodes sending data in the last 24 hours, use this query:

-```kusto

-find where TimeGenerated > ago(24h) project Computer

-| extend computerName = tolower(tostring(split(Computer, '.')[0]))

-| where computerName != ""

-| summarize nodes = dcount(computerName)

-```

-To get a list of nodes sending any data (and the amount of data sent by each), use this query:

-```kusto

-find where TimeGenerated > ago(24h) project _BilledSize, Computer

-| extend computerName = tolower(tostring(split(Computer, '.')[0]))

-| where computerName != ""

-| summarize TotalVolumeBytes=sum(_BilledSize) by computerName

-```

-> [!TIP]

-> Use these `find` queries sparingly because scans across data types are [resource intensive](./query-optimization.md#query-performance-pane) to execute. If you don't need results **per computer**, then query on the **Usage** data type.

-### Nodes billed by the legacy Per Node pricing tier

-The [legacy Per Node pricing tier](#legacy-pricing-tiers) bills for nodes with hourly granularity and also doesn't count nodes that are only sending a set of security data types. To get a list of computers that will be billed as nodes if the workspace is in the legacy Per Node pricing tier, look for nodes that are sending **billed data types** (some data types are free). To do this, use the [_IsBillable property](./log-standard-columns.md#_isbillable) and use the leftmost field of the fully qualified domain name. This returns the count of computers with billed data per hour:

-```kusto

-find where TimeGenerated >= startofday(ago(7d)) and TimeGenerated < startofday(now()) project Computer, _IsBillable, Type, TimeGenerated

-| where Type !in ("SecurityAlert", "SecurityBaseline", "SecurityBaselineSummary", "SecurityDetection", "SecurityEvent", "WindowsFirewall", "MaliciousIPCommunication", "LinuxAuditLog", "SysmonEvent", "ProtectionStatus", "WindowsEvent")

-| extend computerName = tolower(tostring(split(Computer, '.')[0]))

-| where computerName != ""

-| where _IsBillable == true

-| summarize billableNodesPerHour=dcount(computerName) by bin(TimeGenerated, 1h)

-| summarize billableNodesPerDay = sum(billableNodesPerHour)/24., billableNodeMonthsPerDay = sum(billableNodesPerHour)/24./31. by day=bin(TimeGenerated, 1d)

-| sort by day asc

-```

-The number of units on your bill is in units of node months, which is represented by `billableNodeMonthsPerDay` in the query.

-If the workspace has the Update Management solution installed, add the **Update** and **UpdateSummary** data types to the list in the where clause in the above query. Finally, there's some additional complexity in the actual billing algorithm when solution targeting is used that's not represented in the above query.

-> [!TIP]

-> Use these `find` queries sparingly because scans across data types are [resource intensive](./query-optimization.md#query-performance-pane) to execute. If you don't need results **per computer**, then query on the **Usage** data type.

-

-### Getting Security and Automation node counts

-To see the number of distinct Security nodes, you can use the query:

-```kusto

-union

-(

- Heartbeat

- | where (Solutions has 'security' or Solutions has 'antimalware' or Solutions has 'securitycenter')

- | project Computer

-),

-(

- ProtectionStatus

- | where Computer !in~

- (

- (

- Heartbeat

- | project Computer

- )

- )

- | project Computer

-)

-| distinct Computer

-| project lowComputer = tolower(Computer)

-| distinct lowComputer

-| count

-```

-To see the number of distinct Automation nodes, use the query:

-```kusto

- ConfigurationData

- | where (ConfigDataType == "WindowsServices" or ConfigDataType == "Software" or ConfigDataType =="Daemons")

- | extend lowComputer = tolower(Computer) | summarize by lowComputer

- | join (

- Heartbeat

- | where SCAgentChannel == "Direct"

- | extend lowComputer = tolower(Computer) | summarize by lowComputer, ComputerEnvironment

- ) on lowComputer

- | summarize count() by ComputerEnvironment | sort by ComputerEnvironment asc

-```

-## Evaluating the legacy Per Node pricing tier

-The decision of whether workspaces with access to the legacy **Per Node** pricing tier are better off in that tier or in a current **Pay-As-You-Go** or **Commitment Tier** is often difficult for customers to assess. This involves understanding the trade-off between the fixed cost per monitored node in the Per Node pricing tier and its included data allocation of 500 MB/node/day and the cost of just paying for ingested data in the Pay-As-You-Go (Per GB) tier.

-To facilitate this assessment, the following query can be used to make a recommendation for the optimal pricing tier based on a workspace's usage patterns. This query looks at the monitored nodes and data ingested into a workspace in the last seven days, and for each day, it evaluates which pricing tier would have been optimal. To use the query, you need to specify:

-Here is the pricing tier recommendation query:

-```kusto

-// Set these parameters before running query.

-// For Pay-As-You-Go (per-GB) and commitment tier pricing details, see https://azure.microsoft.com/pricing/details/monitor/.

-// You can see your per-node costs in your Azure usage and charge data. For more information, see https://docs.microsoft.com/en-us/azure/cost-management-billing/understand/download-azure-daily-usage.

-let daysToEvaluate = 7; // Enter number of previous days to analyze (reduce if the query is taking too long)

-let workspaceHasSecurityCenter = false; // Specify if the workspace has Defender for Cloud (formerly known as Azure Security Center)

-let PerNodePrice = 15.; // Montly price per monitored node

-let PerNodeOveragePrice = 2.30; // Price per GB for data overage in the Per Node pricing tier

-let PerGBPrice = 2.30; // Enter the Pay-as-you-go price for your workspace's region (from https://azure.microsoft.com/pricing/details/monitor/)

-let CommitmentTier100Price = 196.; // Enter your price for the 100 GB/day commitment tier

-let CommitmentTier200Price = 368.; // Enter your price for the 200 GB/day commitment tier

-let CommitmentTier300Price = 540.; // Enter your price for the 300 GB/day commitment tier

-let CommitmentTier400Price = 704.; // Enter your price for the 400 GB/day commitment tier

-let CommitmentTier500Price = 865.; // Enter your price for the 500 GB/day commitment tier

-let CommitmentTier1000Price = 1700.; // Enter your price for the 1000 GB/day commitment tier

-let CommitmentTier2000Price = 3320.; // Enter your price for the 2000 GB/day commitment tier

-let CommitmentTier5000Price = 8050.; // Enter your price for the 5000 GB/day commitment tier

-//

-let SecurityDataTypes=dynamic(["SecurityAlert", "SecurityBaseline", "SecurityBaselineSummary", "SecurityDetection", "SecurityEvent", "WindowsFirewall", "MaliciousIPCommunication", "LinuxAuditLog", "SysmonEvent", "ProtectionStatus", "WindowsEvent", "Update", "UpdateSummary"]);

-let StartDate = startofday(datetime_add("Day",-1*daysToEvaluate,now()));

-let EndDate = startofday(now());

-union *

-| where TimeGenerated >= StartDate and TimeGenerated < EndDate

-| extend computerName = tolower(tostring(split(Computer, '.')[0]))

-| where computerName != ""

-| summarize nodesPerHour = dcount(computerName) by bin(TimeGenerated, 1h)

-| summarize nodesPerDay = sum(nodesPerHour)/24. by day=bin(TimeGenerated, 1d)

-| join kind=leftouter (

- Heartbeat

- | where TimeGenerated >= StartDate and TimeGenerated < EndDate

- | where Computer != ""

- | summarize ASCnodesPerHour = dcount(Computer) by bin(TimeGenerated, 1h)

- | extend ASCnodesPerHour = iff(workspaceHasSecurityCenter, ASCnodesPerHour, 0)

- | summarize ASCnodesPerDay = sum(ASCnodesPerHour)/24. by day=bin(TimeGenerated, 1d)

-) on day

-| join (

- Usage

- | where TimeGenerated >= StartDate and TimeGenerated < EndDate

- | where IsBillable == true

- | extend NonSecurityData = iff(DataType !in (SecurityDataTypes), Quantity, 0.)

- | extend SecurityData = iff(DataType in (SecurityDataTypes), Quantity, 0.)

- | summarize DataGB=sum(Quantity)/1000., NonSecurityDataGB=sum(NonSecurityData)/1000., SecurityDataGB=sum(SecurityData)/1000. by day=bin(StartTime, 1d)

-) on day

-| extend AvgGbPerNode = NonSecurityDataGB / nodesPerDay

-| extend OverageGB = iff(workspaceHasSecurityCenter,

- max_of(DataGB - 0.5*nodesPerDay - 0.5*ASCnodesPerDay, 0.),

- max_of(DataGB - 0.5*nodesPerDay, 0.))

-| extend PerNodeDailyCost = nodesPerDay * PerNodePrice / 31. + OverageGB * PerNodeOveragePrice

-| extend billableGB = iff(workspaceHasSecurityCenter,

- (NonSecurityDataGB + max_of(SecurityDataGB - 0.5*ASCnodesPerDay, 0.)), DataGB )

-| extend PerGBDailyCost = billableGB * PerGBPrice

-| extend CommitmentTier100DailyCost = CommitmentTier100Price + max_of(billableGB - 100, 0.)* CommitmentTier100Price/100.

-| extend CommitmentTier200DailyCost = CommitmentTier200Price + max_of(billableGB - 200, 0.)* CommitmentTier200Price/200.

-| extend CommitmentTier300DailyCost = CommitmentTier300Price + max_of(billableGB - 300, 0.)* CommitmentTier300Price/300.

-| extend CommitmentTier400DailyCost = CommitmentTier400Price + max_of(billableGB - 400, 0.)* CommitmentTier400Price/400.

-| extend CommitmentTier500DailyCost = CommitmentTier500Price + max_of(billableGB - 500, 0.)* CommitmentTier500Price/500.

-| extend CommitmentTier1000DailyCost = CommitmentTier1000Price + max_of(billableGB - 1000, 0.)* CommitmentTier1000Price/1000.

-| extend CommitmentTier2000DailyCost = CommitmentTier2000Price + max_of(billableGB - 2000, 0.)* CommitmentTier2000Price/2000.

-| extend CommitmentTier5000DailyCost = CommitmentTier5000Price + max_of(billableGB - 5000, 0.)* CommitmentTier5000Price/5000.

-| extend MinCost = min_of(

- PerNodeDailyCost,PerGBDailyCost,CommitmentTier100DailyCost,CommitmentTier200DailyCost,

- CommitmentTier300DailyCost, CommitmentTier400DailyCost, CommitmentTier500DailyCost, CommitmentTier1000DailyCost, CommitmentTier2000DailyCost, CommitmentTier5000DailyCost)

-| extend Recommendation = case(

- MinCost == PerNodeDailyCost, "Per node tier",

- MinCost == PerGBDailyCost, "Pay-as-you-go tier",

- MinCost == CommitmentTier100DailyCost, "Commitment tier (100 GB/day)",

- MinCost == CommitmentTier200DailyCost, "Commitment tier (200 GB/day)",

- MinCost == CommitmentTier300DailyCost, "Commitment tier (300 GB/day)",

- MinCost == CommitmentTier400DailyCost, "Commitment tier (400 GB/day)",

- MinCost == CommitmentTier500DailyCost, "Commitment tier (500 GB/day)",

- MinCost == CommitmentTier1000DailyCost, "Commitment tier (1000 GB/day)",

- MinCost == CommitmentTier2000DailyCost, "Commitment tier (2000 GB/day)",

- MinCost == CommitmentTier5000DailyCost, "Commitment tier (5000 GB/day)",

- "Error"

-)

-| project day, nodesPerDay, ASCnodesPerDay, NonSecurityDataGB, SecurityDataGB, OverageGB, AvgGbPerNode, PerGBDailyCost, PerNodeDailyCost,

- CommitmentTier100DailyCost, CommitmentTier200DailyCost, CommitmentTier300DailyCost, CommitmentTier400DailyCost, CommitmentTier500DailyCost, CommitmentTier1000DailyCost, CommitmentTier2000DailyCost, CommitmentTier5000DailyCost, Recommendation

-| sort by day asc

-//| project day, Recommendation // Comment this line to see details

-| sort by day asc

-```

-This query isn't an exact replication of how usage is calculated, but it provides pricing tier recommendations in most cases.

-> [!NOTE]

-> To use the entitlements that come from purchasing OMS E1 Suite, OMS E2 Suite, or OMS Add-On for System Center, choose the Log Analytics *Per Node* pricing tier.

-<a name="allocations"></a>

-## Viewing data allocation benefits

-To view data allocation benefits from sources such as [Microsoft Defender for Servers](https://azure.microsoft.com/pricing/details/defender-for-cloud/), [Microsoft Sentinel benefit for Microsoft 365 E5, A5, F5 and G5 customers](https://azure.microsoft.com/offers/sentinel-microsoft-365-offer/), or the [Sentinel Free Trial](https://azure.microsoft.com/pricing/details/microsoft-sentinel/), you need to [export your usage details](#viewing-log-analytics-usage-on-your-azure-bill). Open the exported usage spreadsheet and filter the "Instance ID" column to your workspace. (To select all of your workspaces in the spreadsheet, filter the Instance ID column to "contains /workspaces/".) Next, filter the ResourceRate column to show only rows where this is equal to zero. Now you will see the data allocations from these various sources.

-> [!NOTE]

-> Data allocations from Defender for Servers 500 MB/server/day will appear in rows with the meter name "Data Included per Node" and the meter category to "Insight and Analytics" (the name of a legacy offer still used with this meter.) If the workspace is in the legacy Per Node Log Analytics pricing tier, this meter will also include the data allocations from this Log Analytics pricing tier.

-## Late-arriving data

-Situations can arise where data is ingested with old timestamps. For example, if an agent can't communicate to Log Analytics because of a connectivity issue or when a host has an incorrect time date/time. This can manifest itself by an apparent discrepancy between the ingested data reported by the **Usage** data type and a query summing **_BilledSize** over the raw data for a particular day specified by **TimeGenerated**, the timestamp when the event was generated.

-To diagnose late-arriving data issues, use the **_TimeReceived** column ([learn more](./log-standard-columns.md#_timereceived)) in addition to the **TimeGenerated** column. **_TimeReceived** is the time when the record was received by the Azure Monitor ingestion point in the Azure cloud. For example, when using the **Usage** records, you have observed high ingested data volumes of **W3CIISLog** data on May 2, 2021, here is a query that identifies the timestamps on this ingested data:

-```Kusto

-W3CIISLog

-| where TimeGenerated > datetime(1970-01-01)

-| where _TimeReceived >= datetime(2021-05-02) and _TimeReceived < datetime(2021-05-03)

-| where _IsBillable == true

-| summarize BillableDataMB = sum(_BilledSize)/1.E6 by bin(TimeGenerated, 1d)

-| sort by TimeGenerated asc

-```

-

-The `where TimeGenerated > datetime(1970-01-01)` statement is present only to provide the clue to the Log Analytics user interface to look over all data.

-

-## Data transfer charges using Log Analytics

-Sending data to Log Analytics might incur data bandwidth charges. However, that's limited to Virtual Machines where a Log Analytics agent is installed and doesn't apply when using Diagnostics settings or with other connectors that are built in to Microsoft Sentinel. As described in the [Azure Bandwidth pricing page](https://azure.microsoft.com/pricing/details/bandwidth/), data transfer between Azure services located in two regions is charged as outbound data transfer at the normal rate. Inbound data transfer is free. However, this charge is very small compared to the costs for Log Analytics data ingestion. So, controlling costs for Log Analytics needs to focus on your [ingested data volume](#understanding-ingested-data-volume).

-## Troubleshooting why Log Analytics is no longer collecting data

-If you're on the legacy Free pricing tier and have sent more than 500 MB of data in a day, data collection stops for the rest of the day. Reaching the daily limit is a common reason that Log Analytics stops collecting data, or data appears to be missing. Log Analytics creates an **Operation** type event when data collection starts and stops. Run the following query in search to check whether you're reaching the daily limit and missing data:

-```kusto

-Operation | where OperationCategory == 'Data Collection Status'

-```

-When data collection stops, the **OperationStatus** is **Warning**. When data collection starts, the **OperationStatus** is **Succeeded**. The following table lists reasons that data collection stops and a suggested action to resume data collection.

-|Reason collection stops| Solution|

-|--||

-|Daily cap of your workspace was reached|Wait for collection to automatically restart, or increase the daily data volume limit described in manage the maximum daily data volume. The daily cap reset time is shows on the **Daily Cap** page. |

-| Your workspace has hit the [Data Ingestion Volume Rate](../service-limits.md#log-analytics-workspaces) | The default ingestion volume rate limit for data sent from Azure resources using diagnostic settings is approximately 6 GB/min per workspace. This is an approximate value because the actual size can vary between data types, depending on the log length and its compression ratio. This limit doesn't apply to data that's sent from agents or the Data Collector API. If you send data at a higher rate to a single workspace, some data is dropped, and an event is sent to the Operation table in your workspace every 6 hours while the threshold continues to be exceeded. If your ingestion volume continues to exceed the rate limit or you are expecting to reach it sometime soon, you can request an increase to your workspace by sending an email to LAIngestionRate@microsoft.com or by opening a support request. The event to look for that indicates a data ingestion rate limit can be found by the query `Operation | where OperationCategory == "Ingestion" | where Detail startswith "The rate of data crossed the threshold"`. |

-|Daily limit of legacy Free pricing tier reached |Wait until the following day for collection to automatically restart, or change to a paid pricing tier.|

-|Azure subscription is in a suspended state due to:<br> Free trial ended<br> Azure pass expired<br> Monthly spending limit reached (such as on an MSDN or Visual Studio subscription)|Convert to a paid subscription<br> Remove limit, or wait until limit resets|

-To be notified when data collection stops, use the steps described in the [Alert when daily cap is reached](#alert-when-daily-cap-is-reached) section. To configure an e-mail, webhook, or runbook action for the alert rule, use the steps described in [create an action group](../alerts/action-groups.md).

-## Limits summary

-There are additional Log Analytics limits, some of which depend on the Log Analytics pricing tier. These are documented at [Azure subscription and service limits, quotas, and constraints](../../azure-resource-manager/management/azure-subscription-service-limits.md#log-analytics-workspaces).

-## Next steps

-* [Create an alert](./manage-cost-storage.md#alert-when-daily-cap-is-reached) on "Data collection stopped" Operation event, this alert will allow you to get notified when the collection limit was reached.

-Or, you can decide to ([Manage your maximum daily data volume](./manage-cost-storage.md#manage-your-maximum-daily-data-volume) \ [change the pricing tier](./manage-cost-storage.md#changing-pricing-tier) to one that will suite your collection rates pattern).

-* Data collection rate is calculated per day, and will reset at the start of the next day, you can also monitor collection resume event by [Create an alert](./manage-cost-storage.md#alert-when-daily-cap-is-reached) on "Data collection resumed" Operation event.

-* [Create an alert](./manage-cost-storage.md#alert-when-daily-cap-is-reached) on "Data collection stopped" Operation event, this alert will allow you to get notified when the limit is reached.

-[Manage usage and costs for Azure Monitor Logs](./manage-cost-storage.md#alert-when-daily-cap-is-reached)

-description: Get an overview of the process of using the page for Azure Monitor usage and estimated costs.

-# Monitor usage and estimated costs in Azure Monitor

-This article describes how to view usage and estimated costs across multiple Azure monitoring features.

-## Azure Monitor pricing model

-The basic Azure Monitor billing model is a cloud-friendly, consumption-based pricing (pay-as-you-go). You pay for only what you use. Pricing details are available for [alerting, metrics, and notifications](https://azure.microsoft.com/pricing/details/monitor/); [Log Analytics](https://azure.microsoft.com/pricing/details/log-analytics/); and [Application Insights](https://azure.microsoft.com/pricing/details/application-insights/).

-In addition to the pay-as-you-go model for log data, Azure Monitor Log Analytics has Commitment Tiers. They enable you to save as much as 30 percent compared to the pay-as-you-go pricing. Commitment Tiers start at 100 gigabytes (GB) a day. Any usage above the Commitment Tier will be billed at the same price per gigabyte as the Commitment Tier. [Learn more about Commitment Tier pricing](https://azure.microsoft.com/pricing/details/monitor/).

-Some customers have access to [legacy Log Analytics pricing tiers](logs/manage-cost-storage.md#legacy-pricing-tiers) and the [legacy Enterprise Application Insights pricing tier](app/pricing.md#legacy-enterprise-per-node-pricing-tier).

-## Azure Monitor costs

-There are two phases for understanding costs: estimating costs when you're considering Azure Monitor as your monitoring solution, and then tracking actual costs after deployment.

-### Estimate the costs to manage your environment

-If you're not yet using Azure Monitor Logs, you can use the [Azure Monitor pricing calculator](https://azure.microsoft.com/pricing/calculator/?service=monitor) to estimate the cost of using Azure Monitor. Start by entering **Azure Monitor** in the **Search** box, and then selecting the **Azure Monitor** tile. Scroll down the page to **Azure Monitor**, and select one of the options from the **Type** dropdown list:

-In each of these types, the pricing calculator will help you estimate your likely costs based on your expected utilization.

-For example, with Log Analytics, you can enter the number of virtual machines (VMs) and the gigabytes of data that you expect to collect from each VM. Typically, 1 GB to 3 GB of data per month is ingested from an Azure VM. If you're already evaluating Azure Monitor Logs, you can use your data statistics from your own environment. You can determine the [number of monitored VMs](logs/manage-cost-storage.md#understanding-nodes-sending-data) and the [volume of data that your workspace is ingesting](logs/manage-cost-storage.md#understanding-ingested-data-volume).

-For Application Insights, if you enable the **Estimate data volume based on application activity** functionality, you can provide inputs about your application (requests per month and page views per month, if you'll collect client-side telemetry). Then the calculator will tell you the median and 90th percentile amount of data that similar applications collect.

-These applications span the range of Application Insights configurations. For example, some have default sampling, some have no sampling, and some have custom sampling. So you still have the control to reduce the volume of data that you ingest to far below the median level by using sampling. But this is a starting point to understand what similar customers are seeing. [Learn more about estimating costs for Application Insights](app/pricing.md#estimating-the-costs-to-manage-your-application).

-### Track usage and costs

-It's important to understand and track your usage after you start using Azure Monitor. A rich set of tools can help facilitate this tracking.

-#### Azure Cost Management + Billing

-Azure provides useful functionality in the [Azure Cost Management + Billing](../cost-management-billing/costs/quick-acm-cost-analysis.md?toc=/azure/billing/TOC.json) hub. After you open the hub, select **Cost Management** and select the [scope](../cost-management-billing/costs/understand-work-scopes.md) (the set of resources to investigate). You might need additional access to Cost Management data ([learn more](../cost-management-billing/costs/assign-access-acm-data.md)).

-To see the Azure Monitor costs for the last 30 days, select the **Daily Costs** tile, select **Last 30 days** under **Relative dates**, and add a filter that selects the service names:

-The result is a view like the following example:

-You can drill in from this accumulated cost summary to get the finer details in the **Cost by resource** view. In the current pricing tiers, Azure log data is charged on the same set of meters whether it originates from Log Analytics or Application Insights.

-To separate costs from your Log Analytics or Application Insights usage, you can add a filter on **Resource type**. To see all Application Insights costs, filter **Resource type** to **microsoft.insights/components**. For Log Analytics costs, filter **Resource type** to **microsoft.operationalinsights/workspaces**.

-More details about your usage are available if you [download your usage from the Azure portal](../cost-management-billing/understand/download-azure-daily-usage.md). In the downloaded Excel spreadsheet, you can see usage per Azure resource per day. You can find usage from your Application Insights resources by filtering on the **Meter Category** column to show **Application Insights** and **Log Analytics**. Then add a **contains microsoft.insights/components** filter on the **Instance ID** column.

-Most Application Insights usage is reported on meters with **Log Analytics** for **Meter Category**, because there's a single log back end for all Azure Monitor components. Only Application Insights resources on legacy pricing tiers and multiple-step web tests are reported with **Application Insights** for **Meter Category**. The usage is shown in the **Consumed Quantity** column, and the unit for each entry is shown in the **Unit of Measure** column. More details are available to help you [understand your Microsoft Azure bill](../cost-management-billing/understand/review-individual-bill.md).

-#### Usage and estimated costs

-Another option for viewing your Azure Monitor usage is the **Usage and estimated costs** page in the Monitor hub. This page shows the usage of core monitoring features such as [alerting, metrics, and notifications](https://azure.microsoft.com/pricing/details/monitor/); [Azure Log Analytics](https://azure.microsoft.com/pricing/details/log-analytics/); and [Azure Application Insights](https://azure.microsoft.com/pricing/details/application-insights/). For customers on the pricing plans available before April 2018, this page also includes Log Analytics usage purchased through the Insights and Analytics offer.

-On this page, users can view their resource usage for the past 31 days, aggregated per subscription. Drill-ins show usage trends over the 31-day period. A lot of data needs to come together for this estimate, so please be patient as the page loads.

-This example shows monitoring usage and an estimate of the resulting costs:

-

-Select the link in the **MONTHLY USAGE** column to open a chart that shows usage trends over the last 31-day period:

-

-> Using **Cost Management** in the **Azure Cost Management + Billing** hub is the preferred approach to broadly understanding monitoring costs. The **Usage and estimated costs** experiences for [Log Analytics](logs/manage-cost-storage.md#understand-your-usage-and-estimate-costs) and [Application Insights](app/pricing.md#understand-your-usage-and-estimate-costs) provide deeper insights for each of those parts of Azure Monitor.

-Customers who purchased Microsoft Operations Management Suite E1 and E2 are eligible for per-node data ingestion entitlements for [Log Analytics](https://www.microsoft.com/cloud-platform/operations-management-suite) and [Application Insights](app/pricing.md). For customers to receive these entitlements for Log Analytics workspaces or Application Insights resources in a subscription:

-Get cost information for specific components of Azure Monitor:

-You require at least one Log Analytics workspace to support VM insights and to collect telemetry from the Log Analytics agent. There's no cost for the workspace, but you do incur ingestion and retention costs when you collect data. For more information, see [Manage usage and costs with Azure Monitor Logs](../logs/manage-cost-storage.md).

-There is no direct cost for the guest health feature, but there is a cost for ingestion and storage of health state data in the Log Analytics workspace. All data is stored in the *HealthStateChangeEvent* table. See [Manage usage and costs with Azure Monitor Logs](../logs/manage-cost-storage.md) for details on pricing models and costs.

- | project resource = tolower(name), status = d.status

-|project resource, status

-| extend eventType = properties.EventType, status = properties.Status, description = properties.Title, trackingId = properties.TrackingId, summary = properties.Summary, priority = properties.Priority, impactStartTime = properties.ImpactStartTime, impactMitigationTime = properties.ImpactMitigationTime

-| where properties.Status == 'Active' and tolong(impactStartTime) > 1 and eventType == 'PlannedMaintenance'

-| extend eventType = properties.EventType, status = properties.Status, description = properties.Title, trackingId = properties.TrackingId, summary = properties.Summary, priority = properties.Priority, impactStartTime = properties.ImpactStartTime, impactMitigationTime = properties.ImpactMitigationTime

-| where properties.Status == 'Active' and tolong(impactStartTime) > 1 and eventType == 'PlannedMaintenance'

- - OCR

-## March 2022

-## December 2020

-## August 2019

-As a holder of the cloudadmin role, you can view, but not edit, the DRS rules created by a placement policy on the cluster's Configure tab under VM/Host Rules. It lets you view additional information, such as if the DRS rules are in a conflict state.

-In the vSphere client, a VM override will be created to set DRS to partially automated for that VM.

-Further, the lack of the desired granularity in the vSphere privileges presents some challenges when managing the placement of the workloads on the private cloud. For example, vSphere DRS rules commonly used on-premises to define affinity and anti-affinity rules can't be used as-is in a VMware Cloud environment, as some of those rules can block day-to-day operation the private cloud. Placement Policies provides a way to define those rules using the Azure VMware Solution portal, thereby circumventing the need to use DRS rules. Coupled with a simplified experience, they also ensure that the rules don't impact the day-to-day infrastructure maintenance and operation activities.

-If you create conflicting rules, those conflicts may show up on the vCenter, and the newly defined rules may not take effect. It's a standard vSphere DRS behavior, the logs for which can be observed in the vCenter.

-| Cause | Recommended actions |

-| **Vault credentials aren't valid** <br/> <br/> Vault credential files might be corrupt, might have expired, or they might have a different file extension than *.vaultCredentials*. (For example, they might have been downloaded more than 10 days before the time of registration.)| [Download new credentials](backup-azure-file-folder-backup-faq.yml#where-can-i-download-the-vault-credentials-file-) from the Recovery Services vault on the Azure portal. Then take these steps, as appropriate: <ul><li> If you've already installed and registered MARS, open the Microsoft Azure Backup Agent MMC console. Then select **Register Server** in the **Actions** pane to complete the registration with the new credentials. <br/> <li> If the new installation fails, try reinstalling with the new credentials.</ul> **Note**: If multiple vault credential files have been downloaded, only the latest file is valid for the next 10 days. We recommend that you download a new vault credential file.

-| **Proxy server/firewall is blocking registration** <br/>or <br/>**No internet connectivity** <br/><br/> If your machine has limited internet access, and you don't ensure the firewall, proxy, and network settings allow access to the FQDNS and public IP addresses, the registration will fail.| Take these steps:<br/> <ul><li> Work with your IT team to ensure the system has internet connectivity.<li> If you don't have a proxy server, ensure the proxy option isn't selected when you register the agent. [Check your proxy settings](#verifying-proxy-settings-for-windows).<li> If you do have a firewall/proxy server, work with your networking team to allow access to the following FQDNs and public IP addresses. Access to all of the URLs and IP addresses listed below uses the HTTPS protocol on port 443.<br/> <br> **URLs**<br> `www.msftncsi.com` <br> `www.msftconnecttest.com` <br> \*.microsoft.com <br> \*.windowsazure.com <br> \*.microsoftonline.com <br>\*.windows.net<br><br>**IP addresses**<br> 20.190.128.0/18 <br> 40.126.0.0/18<br> <br/><li>If you are a US Government customer, ensure that you have access to the following URLs:<br><br> `www.msftncsi.com` <br> \*.microsoft.com <br> \*.windowsazure.us <br> \*.microsoftonline.us <br> `*.windows.net` <br> \*.usgovcloudapi.net</li></ul></ul>Try registering again after you complete the preceding troubleshooting steps.<br></br> If your connection is via Azure ExpressRoute, make sure the settings are configured as described in Azure [ExpressRoute support](../backup/backup-support-matrix-mars-agent.md#azure-expressroute-support).

-| **Antivirus software is blocking registration** | If you have antivirus software installed on the server, add necessary exclusion rules to the antivirus scan for these files and folders: <br/><ul> <li> CBengine.exe <li> CSC.exe<li> The scratch folder. Its default location is C:\Program Files\Microsoft Azure Recovery Services Agent\Scratch. <li> The bin folder at C:\Program Files\Microsoft Azure Recovery Services Agent\Bin.

-If you have antivirus software installed on the server, add necessary exclusion rules to the antivirus scan for these files and folders:

-For antivirus programs, we recommend that you exclude the following files and locations:

-* C:\Program Files\Microsoft Azure Recovery Services Agent\bin\cbengine.exe as a process

-* C:\Program Files\Microsoft Azure Recovery Services Agent\ folders

-* Scratch location (if you're not using the standard location)

-1. Navigate to **Backup Center** > **Backup Reports** and click on the **Email Report** tab.

-The logic app uses the [azuremonitorlogs](/connectors/azuremonitorlogs/) connector for querying the LA workspace(s) and uses the [Office365 Outlook](/connectors/office365connector/) connector for sending emails. You will need to perform a one-time authorization for these two connectors.

-1. Navigate to **Logic Apps** in the Azure portal.

-2. Search for the name of the logic app you have created and navigate to the resource.

-4. You will see two connections with the format `<location>-azuremonitorlogs` and `<location>-office365` - that is, _eastus-azuremonitorlogs_ and _eastus-office365_.

-5. Navigate to each of these connections and select the **Edit API connection** menu item. In the screen that appears, select **Authorize**, and save the connection once authorization is complete.

-6. To test whether the logic app works after authorization, you can navigate back to the logic app, open **Overview** and select **Run Trigger** in the top pane, to test whether an email is being generated successfully.

-* Tab-level filters such as **Backup Instance Name**, **Policy Name** and so on, are not applied. The only exception to this is the **Retention Optimizations** grid in the **Optimize** tab, where the filters for **Daily**, **Weekly**, **Monthly** and **Yearly** RP retention are applied.

-* This issue could be occurring because the Outlook API connector is not authorized. To authorize the connection, follow the authorization steps provided above.

-* This issue could also be occurring if you have specified an incorrect email recipient while creating the logic app. To verify that the email recipient has been specified correctly, you can navigate to the logic app in the Azure portal, open the Logic App designer and select email step to see whether the correct email IDs are being used.

-1. Navigate to the logic app in the Azure portal.

-2. At the bottom of the **Overview** screen, you will see a **Runs History** section. You can open on the latest run and view which steps in the workflow failed. Some possible causes could be:

-By default, the data in a Log Analytics workspace is retained for 30 days. To see data for a longer time horizon, change the retention period of the Log Analytics workspace. To change the retention period, see [Manage usage and costs with Azure Monitor logs](../azure-monitor/logs/manage-cost-storage.md).

-The [Batch node agent](https://github.com/Azure/Batch/blob/master/changelogs/nodeagent/CHANGELOG.md) is a program that runs on each node in the pool and provides the command-and-control interface between the node and the Batch service. There are different implementations of the node agent, known as SKUs, for different operating systems. Essentially, when you create a Virtual Machine Configuration, you first specify the virtual machine image reference, and then you specify the node agent to install on the image. Typically, each node agent SKU is compatible with multiple virtual machine images. To view supported Marketplace VM images with their corresponding node agent SKUs, you can refer to [Account - List Supported Images - REST API (Azure Batch Service) | Microsoft Docs](/rest/api/batchservice/account/list-supported-images).

-### Azure CLI

-When no longer needed, use the Azure portal, Azure CLI, or Azure PowerShell to delete the VM and all of the resources in the resource group.

- Console.WriteLine($"CANCELED: Did you update the subscription info?");

- Console.WriteLine($"CANCELED: Did you update the subscription info?");

- cout << "CANCELED: Did you update the subscription info?" << std::endl;

- cout << "CANCELED: Did you update the subscription info?" << std::endl;

-3. Submit the `GET` cURL request in your terminal or command prompt. You'll receive a 202 response and JSON similar to the below, if the request was successful.

-1. Start constructing a POST request by updating the following URL with your endpoint.

-

- `{YOUR-ENDPOINT}/text/analytics/v3.2-preview.2/analyze`

-2. In the header for the request, add your key to the `Ocp-Apim-Subscription-Key` header.

-3. In the JSON body of your request, you will specify The documents you're inputting for analysis, and the parameters for the custom entity recognition task. `project-name` is case-sensitive.

-

- > [!tip]

- > See the [quickstart article](../quickstart.md?pivots=rest-api#submit-custom-ner-task) and [reference documentation](https://westus2.dev.cognitive.microsoft.com/docs/services/TextAnalytics-v3-2-Preview-2/operations/Analyze) for more information about the JSON syntax.

- ```json

- {

- "displayName": "MyJobName",

- "analysisInput": {

- "documents": [

- {

- "id": "doc1",

- "text": "This is a document."

- }

- ]

- },

- "tasks": {

- "customEntityRecognitionTasks": [

- {

- "parameters": {

- "project-name": "MyProject",

- "deployment-name": "MyDeploymentName"

- "stringIndexType": "TextElements_v8"

- }

- }

- ]

- }

- }

- ```

-4. You will receive a 202 response indicating success. In the response headers, extract `operation-location`.

-`operation-location` is formatted like this:

- `{YOUR-ENDPOINT}/text/analytics/v3.2-preview.2/analyze/jobs/<jobId>`

- You will use this endpoint in the next step to get the custom recognition task results.

-5. Use the URL from the previous step to create a **GET** request to query the status/results of the custom recognition task. Add your key to the `Ocp-Apim-Subscription-Key` header for the request.

-1. Go to your project page in [Language Studio](https://aka.ms/languageStudio).

-2. Select **View model details** from the menu on the left side of the screen.

-3. In this page you can only view the successfully trained models. You can click on the model name for more details.

-4. You can find the **model-level** evaluation metrics under **Overview**, and the **entity-level** evaluation metrics under **Entity performance metrics**. The confusion matrix for the model is located under **Test set confusion matrix**

-

- > [!NOTE]

- > If you don't find all the entities displayed here, it's because they were not in any of the files within the test set.

- :::image type="content" source="../media/model-details.png" alt-text="A screenshot of the model performance metrics in Language Studio" lightbox="../media/model-details.png":::

-Azure Communication Services will feed into Azure Monitor logging data for understanding operational health and utilization of the service. Some of these logs include Communication Service identities and phone numbers as field data. To delete any potentially personal data [use these procedures for Azure Monitor](../../azure-monitor/logs/personal-data-mgmt.md). You may also want to configure [the default retention period for Azure Monitor](../../azure-monitor/logs/manage-cost-storage.md).

-> For the **Logic App (Standard)** resource type in single-tenant Azure Logic Apps, Azure AD OAuth is currently

-> unavailable for inbound calls to request-based triggers, such as the Request trigger and HTTP Webhook trigger.

- }],

- "initialDelaySeconds": 7,

- "periodSeconds": 3

- }

- }],

- "initialDelaySeconds": 3,

- "periodSeconds": 3

- }

- initialDelaySeconds: 7

- periodSeconds: 3

- initialDelaySeconds: 3

- periodSeconds: 3

-description: The supply chain traceability graph solution implemented by Infosys uses the Azure Cosmos DB Gremlin API and other Azure services. It provides global supply chain track and trace capability for finished goods.

-# Supply chain traceability solution using Azure Cosmos DB Gremlin API

-This article provides an overview of [traceability graph solutions implemented by Infosys](https://azuremarketplace.microsoft.com/marketplace/apps/infosysltd.infosys-traceability-knowledge-graph?tab=Overview). These solutions use Azure Cosmos DB Gremlin API and other Azure capabilities to provide global supply chain track and trace capability for finished goods.

-After reading this article, you will learn:

-* What is traceability in the context of a supply chain?

-* Architecture of a global traceability solution delivered using Azure Capabilities.

-* How the Azure Cosmos DB graph database helps intricate relationships between raw material and finished good in a global supply chain?

-* How does the Azure integration platform services such as API Management, Event Hub help you to integrate diverse supply chain application ecosystems?

-* How can you get help from Infosys to use this solution for your traceability need?

-In the food supply chain, product traceability is the ability to 'track and trace' them across the supply chain throughout the productΓÇÖs lifecycle. The supply chain includes supply, manufacturing, and distribution. Traceability is vital for food safety, brand, and regulatory exposure. In the past, some organizations failed to track and trace products effectively in their supply chain, resulting in expensive recalls, fines, and consumer health issues. The traceability solutions had to address the needs of data harmonization, data ingestion at different velocity and veracity, and, more importantly, follow the inventory cycle, objectives that weren't possible with traditional platforms.

-Infosys's traceability solution, developed with Azure capabilities such as application services, integration services and database services, provides vital capabilities to:

-* Connect to factories, warehouses/distribution centers.

-* Ingest/process parallel stock movement events.

-* A knowledge graph, which shows connections between raw material, batch, finish goods (FG) pallets, multi-level parent/child relationship of pallets, goods movement.

-* User portal with a search capability range of wildcard search to specific keyword search.

-* Identify impacts of a quality incident such as impacted raw material batch, pallets affected, location of the pallets.

-* Ability to have the history of events captured across multiple markets, including product recall information.

-Supply chain traceability commonly shares patterns in ingesting pallet movements, handing quality incidents, and tracing/analyzing store data. First, these systems need to ingest bursts of data from factory and warehouse management systems that cross geographies. Next, these systems process and analyze streaming data to derive complex relationships between raw material, production batches, finished good pallets and complex parent/child relationships (co-pack/repack). Then, the system must store information about the intricate relationships between raw material, finished goods, and pallets, all necessary for traceability. A user portal with search capability allows the users to track and trace products in the supply chain network. These services enable the end-to-end traceability solution that supports cloud-native, API-first, and data-driven capabilities.

-Microsoft Azure offers rich services that can be applied for traceability use cases, including Azure Cosmos DB, Azure Event Hubs, Azure API Management, Azure App Service, Azure SignalR, Azure Synapse Analytics, and Power BI.

-InfosysΓÇÖs traceability solution provides a pre-baked solution that you can use to improve track and trace capability. The following image explains the architecture used for this traceability solution:

-Different Azure services used in this architecture help with the following tasks:

-* Azure Cosmos DB allows you to scale performance up or down elastically. Gremlin API allows you to create and query complex relationships between raw material, finished goods and warehouses.

-* Azure API Management provides APIs for stock movement events to the 3PLs (thirdpParty Logistic Providers) and Warehouse Management Systems (WMS).

-* Azure Event Hub provides the ability to gather large numbers of concurrent events from WMS and 3PLs for further processing.

-* Azure Function apps processes events and ingest data to Azure Cosmos DB using Gremlin API.

-* Azure Search service allows users to do complex find, filter pallet information.

-* Azure Databricks reads change feed and creates models in Synapse Analytics for self-service reporting for users in Power BI.

-* Azure Web App and App Service plan allow you to deploy the user portal.

-* Azure Storage account stores archived data for long-term regulatory needs.

-## Graph DB and its data design

-The production and distribution of goods require maintaining a complex and dynamic set of relationships. An adaptive data model of our traceability graph allows storing such relationships starting from the receipt of raw material, manufacturing the finished goods in a factory, transferring to different warehouses during supply chain, and finally transferring to the customer warehouse. A high-level visualization of the process looks like the following image:

-The above diagram shows a high level and simplified view of a complex supply chain process. However, getting the vital stock movement information from the factories and warehouses in real time makes it possible to create an elaborate graph that connects all these disparate pieces of information.

-1. The traceability process starts when the supplier sends raw materials to the factories, and the initial nodes (vertices) of the graph and relationships (edges) gets created.

-1. The finished goods (Items) are produced from raw materials and packed into pallets.

-1. The pallets are then moved to factory warehouses or the market warehouses as per customer demands/orders.

-1. The warehouse could be of companyΓÇÖs owned or 3PL (third-party Logistic Providers). The pallets are then shipped to various other warehouses as per customer orders. As per the customer demands, child pallets or child-of-child pallets are created to accommodate the ordered quantity. Sometimes, a whole new item is made by mixing multiple items. For example, in a copack scenario that produces a variety pack, sometimes same item gets repacked to smaller or larger quantities to a different pallet as part of a customer order.

- :::image type="content" source="./media/supply-chain-traceability-solution/pallet-relationship.png" alt-text="Pallet relationship in supply chain traceability solution" lightbox="./media/supply-chain-traceability-solution/pallet-relationship.png" border="true":::

-1. Pallets then travel through the supply chain network and eventually reach the customer warehouse. During that process, the pallets can be further broken down or combine with other pallets to produce new pallets to fulfill customer orders.

-1. Eventually, the system creates a complex graph that holds vital relationship information for quality incident management, which we will discuss shortly.

- :::image type="content" source="./media/supply-chain-traceability-solution/supply-chain-object-relationship.png" alt-text="Supply chain object relationship complete architecture" lightbox="./media/supply-chain-traceability-solution/supply-chain-object-relationship.png" border="true":::

-1. These intricate relationships are vital in a quality incident where the system can track and trace pallets across the supply chain. Graph and its traversals provide the required information for this. For example, if there is an issue with one raw material, the graph can show the impacted pallets, current location.

-* [Infosys traceability graph solution](https://azuremarketplace.microsoft.com/marketplace/apps/infosysltd.infosys-traceability-knowledge-graph?tab=Overview)

-* [Infosys Integrate+ for Azure](https://azuremarketplace.microsoft.com/marketplace/apps/infosysltd.infosys-integrate-for-azure)

-> Azure RBAC support in Azure Cosmos DB applies to management plane operations only. This article is about role-based access control for management plane operations in Azure Cosmos DB. If you are using data plane operations, data is secured using primary keys, resource tokens, or the Azure Cosmos DB RBAC. To learn more about role-based access control applied to data plane operations, see [Secure access to data](secure-access-to-data.md) and [Azure Cosmos DB RBAC](how-to-setup-rbac.md) articles.

-FeedIterator iteratorWithStreams = container.GetChangeFeedStreamIterator<User>(ChangeFeedStartFrom.Beginning(), ChangeFeedMode.Incremental);

-FeedIterator iteratorForTheEntireContainer = container.GetChangeFeedStreamIterator<User>(ChangeFeedStartFrom.Now(), ChangeFeedMode.Incremental);

-This article highlights some of the considerations of upgrading your existing .NET application to the newer Azure Cosmos DB .NET SDK v3 for Core (SQL) API. Azure Cosmos DB .NET SDK v3 corresponds to the Microsoft.Azure.Cosmos namespace. You can use the information provided in this doc if you are migrating your application from any of the following Azure Cosmos DB .NET SDKs:

-In addition to the numerous usability and performance improvements, new feature investments made in the latest SDK will not be back ported to older versions.

-Because the .NET v3 SDK allows users to configure a custom serialization engine, there is no direct replacement for the `Document` type. When using Newtonsoft.Json (default serialization engine), `JObject` can be used to achieve the same functionality. When using a different serialization engine, you can use its base json document type (for example, `JsonDocument` for System.Text.Json). The recommendation is to use a C# type that reflects the schema of your items instead of relying on generic types.

-## Create a database account

-> [!IMPORTANT]

-> You need to create a new Table API account to work with the generally available Table API SDKs. Table API accounts created during preview are not supported by the generally available SDKs.

->

-## Add a table

-## Add sample data

-## Clone the sample application

-Now let's clone a Table app from GitHub, set the connection string, and run it. You'll see how easy it is to work with data programmatically.

-1. Open a command prompt, create a new folder named git-samples, then close the command prompt.

- ```bash

- md "C:\git-samples"

- ```

-2. Open a git terminal window, such as git bash, and use the `cd` command to change to the new folder to install the sample app.

- ```bash

- cd "C:\git-samples"

- ```

-3. Run the following command to clone the sample repository. This command creates a copy of the sample app on your computer.

- ```bash

- git clone https://github.com/Azure-Samples/storage-table-node-getting-started.git

- ```

-> [!TIP]

-> For a more detailed walkthrough of similar code, see the [Cosmos DB Table API sample](how-to-use-nodejs.md) article.

-## Review the code

-This step is optional. If you're interested in learning how the database resources are created in the code, you can review the following snippets. Otherwise, you can skip ahead to [update the connection string](#update-your-connection-string) section of this doc.

-* The following code shows how to create a table within the Azure Storage:

- ```javascript

- storageClient.createTableIfNotExists(tableName, function (error, createResult) {

- if (error) return callback(error);

- if (createResult.isSuccessful) {

- console.log("1. Create Table operation executed successfully for: ", tableName);

- }

- }

- ```

-* The following code shows how to insert data into the table:

- ```javascript

- var customer = createCustomerEntityDescriptor("Harp", "Walter", "Walter@contoso.com", "425-555-0101");

- storageClient.insertOrMergeEntity(tableName, customer, function (error, result, response) {

- if (error) return callback(error);

- console.log(" insertOrMergeEntity succeeded.");

- ```

-* The following code shows how to query data from the table:

- ```javascript

- console.log("6. Retrieving entities with surname of Smith and first names > 1 and <= 75");

- var storageTableQuery = storage.TableQuery;

- var segmentSize = 10;

- // Demonstrate a partition range query whereby we are searching within a partition for a set of entities that are within a specific range.

- var tableQuery = new storageTableQuery()

- .top(segmentSize)

- .where('PartitionKey eq ?', lastName)

- .and('RowKey gt ?', "0001").and('RowKey le ?', "0075");

-

- runPageQuery(tableQuery, null, function (error, result) {

-

- if (error) return callback(error);

-

- ```

-* The following code shows how to delete data from the table:

- ```javascript

- storageClient.deleteEntity(tableName, customer, function entitiesQueried(error, result) {

- if (error) return callback(error);

-

- console.log(" deleteEntity succeeded.");

- ```

-

-## Update your connection string

-Now go back to the Azure portal to get your connection string information and copy it into the app. This enables your app to communicate with your hosted database.

-1. In your Azure Cosmos DB account in the [Azure portal](https://portal.azure.com/), select **Connection String**.

- :::image type="content" source="./media/create-table-nodejs/connection-string.png" alt-text="View and copy the required connection string information from the in the Connection String pane":::

-2. Copy the PRIMARY CONNECTION STRING using the copy button on the right side.

-3. Open the *app.config* file, and paste the value into the connectionString on line three.

- > [!IMPORTANT]

- > If your Endpoint uses documents.azure.com, that means you have a preview account, and you need to create a [new Table API account](#create-a-database-account) to work with the generally available Table API SDK.

- >

-3. Save the *app.config* file.

-You've now updated your app with all the info it needs to communicate with Azure Cosmos DB.

-## Run the app

-1. In the git terminal window, `cd` to the storage-table-java-getting-started folder.

- ```

- cd "C:\git-samples\storage-table-node-getting-started"

- ```

-2. Run the following command to install the [azure], [node-uuid], [nconf] and [async] modules locally as well as to save an entry for them to the *package.json* file.

- ```

- npm install azure-storage node-uuid async nconf --save

- ```

-2. In the git terminal window, run the following commands to run the Node.js application.

- ```

- node ./tableSample.js

- ```

- The console window displays the table data being added to the new table database in Azure Cosmos DB.

- You can now go back to Data Explorer and see, query, modify, and work with this new data.

-## Review SLAs in the Azure portal

-IR type | Public network | Private network

-Azure | Data Flow<br/>Data movement<br/>Activity dispatch | Data Flow<br/>Data movement<br/>Activity dispatch

-Self-hosted | Data movement<br/>Activity dispatch | Data movement<br/>Activity dispatch

-Azure-SSIS | SSIS package execution | SSIS package execution

-Azure Integration Runtime supports connecting to data stores and computes services with public accessible endpoints. Enabling Managed Virtual Network, Azure Integration Runtime supports connecting to data stores using private link service in private network environment.

-| upsertSettings | Specify the group of the settings for write behavior. <br/> Apply when the WriteBehavior option is `Upert`. | No |

-This article outlines how to use Copy Activity in a Azure Data Factory or Synapse Analytics pipeline to copy data from an OData source. The article builds on [Copy Activity](copy-activity-overview.md), which presents a general overview of Copy Activity.

-1. Browse to the Manage tab in your Azure Data Factory or Synapse workspace and select Linked Services, then click New:

-| aadResourceId | Specify the AAD resource you are requesting for authorization.| No |

-| azureCloudType | For service principal authentication, specify the type of Azure cloud environment to which your AAD application is registered. <br/> Allowed values are **AzurePublic**, **AzureChina**, **AzureUsGovernment**, and **AzureGermany**. By default, the service's cloud environment is used. | No |

- - **Client ID**: Enter your AAD service principal ID.

- 1. You will be asked to login with your username and password.

-For a list of data stores that Copy Activity supports as sources and sinks, see [Supported data stores and formats](copy-activity-overview.md#supported-data-stores-and-formats).

- Get-AzDataFactoryV2IntegrationRuntimeKey -ResourceGroupName $resourceGroupName -DataFactoryName $dataFactoryName -Name $selfHostedIntegrationRuntime

-By using Azure Private Link, you can connect to various platforms as a service (PaaS) deployments in Azure via a private endpoint. A private endpoint is a private IP address within a specific virtual network and subnet. For a list of PaaS deployments that support Private Link functionality, see [Private Link documentation](../private-link/index.yml).

-* You let the networks and Data Factory securely communicate with each other.

-Several communication channels are required between Azure Data Factory and the customer virtual network, as shown in the following table:

-| `adf.azure.com` | 443 | A control plane, required by Data Factory authoring and monitoring. |

-With the support of Private Link for Azure Data Factory, you can:

-* Create a private endpoint in your virtual network.

-* Enable the private connection to a specific data factory instance.

-The communications to Azure Data Factory service go through Private Link and help provide secure private connectivity.

-Enabling the Private Link service for each of the preceding communication channels offers the following functionality:

- - You can author and monitor the data factory in your virtual network, even if you block all outbound communications.

- - The command communications between the self-hosted integration runtime and the Azure Data Factory service can be performed securely in a private network environment. The traffic between the self-hosted integration runtime and the Azure Data Factory service goes through Private Link.

- > Connecting to Azure Data Factory via private endpoint is only applicable to self-hosted integration runtime in data factory. It is not supported for Azure Synapse.

-> If you enable Private Link in Azure Data Factory and block public access at the same time, it is reccomended that you store your credentials in an Azure key vault to ensure they are secure.

-When you create a private endpoint, the DNS CNAME resource record for the Data Factory is updated to an alias in a subdomain with the prefix 'privatelink'. By default, we also create a [private DNS zone](../dns/private-dns-overview.md), corresponding to the 'privatelink' subdomain, with the DNS A resource records for the private endpoints.

-When you resolve the data factory endpoint URL from outside the VNet with the private endpoint, it resolves to the public endpoint of the data factory service. When resolved from the VNet hosting the private endpoint, the storage endpoint URL resolves to the private endpoint's IP address.

-For the illustrated example above, the DNS resource records for the Data Factory 'DataFactoryA', when resolved from outside the VNet hosting the private endpoint, will be:

-The DNS resource records for DataFactoryA, when resolved in the VNet hosting the private endpoint, will be:

-If you are using a custom DNS server on your network, clients must be able to resolve the FQDN for the Data Factory endpoint to the private endpoint IP address. You should configure your DNS server to delegate your private link subdomain to the private DNS zone for the VNet, or configure the A records for ' DataFactoryA.{region}.datafactory.azure.net' with the private endpoint IP address.

- > [!NOTE]

- > There is currently only one Azure Data Factory Portal endpoint and therefore only one private endpoint for portal in a DNS zone. Attempting to create a second or subsequent portal private endpoint will overwrite the previously created private DNS entry for portal.

-> [!NOTE]

-> Disabling public network access is applicable only to the self-hosted integration runtime, not to Azure Integration Runtime and SQL Server Integration Services (SSIS) Integration Runtime.

-> [!NOTE]

-> You can still access the Azure Data Factory portal through a public network after you create private endpoint for the portal.

-Save the workflow. Browse to the Overview page for the workflow. Make a note of the Workflow URL for your new workflow then:

-# Push Data Factory lineage data to Azure Purview (Preview)

-[Connect Data Factory to Azure Purview](connect-data-factory-to-azure-purview.md)

-Before you set up a compute role on your Azure Stack Edge Pro device, make sure that:

- > - DHCP mode is not supported for Kubernetes node IPs. If you plan to deploy IoT Edge/Kubernetes, you must assign static Kubernetes IPs and then enable IoT role. This will ensure that static IPs are assigned to Kubernetes node VMs.

-## Does Microsoft Defender for Containers support AKS clusters with virtual machines scale set (VMSS)?

-Yes.

- - Microsoft Defender for Endpoint is deployed automatically to all cloud workloads so that you know they are protected when they spin up.

-2. If Microsoft Defender for Servers is not enabled, set it to **On**.

- If you want to change the Defender for server plan:

- 1. In the **Plan/Pricing** column, click **configure**.

- 2. Select the plan that you want.

-| Log-analytics (500MB free) | | :::image type="icon" source="./media/icons/yes-icon.png"::: |

- - **Microsoft threat and vulnerability management** - Discover vulnerabilities and misconfigurations in real time with Microsoft Defender for Endpoint, and without the need of additional agents or periodic scans. [Threat and vulnerability management](/microsoft-365/security/defender-endpoint/next-gen-threat-and-vuln-mgt) prioritizes vulnerabilities based on the threat landscape, detections in your organization, sensitive information on vulnerable devices, and business context. Learn more in [Investigate weaknesses with Microsoft Defender for Endpoint's threat and vulnerability management](deploy-vulnerability-assessment-tvm.md)

- When you enable Microsoft Defender for Servers, you can use just-in-time VM access to lock down the inbound traffic to your VMs, reducing exposure to attacks while providing easy access to connect to VMs when needed. For more information, see [Understanding JIT VM access](just-in-time-access-overview.md).

- When you've enabled and configured adaptive application controls, you'll get security alerts if any application runs other than the ones you've defined as safe. For more information, see [Use adaptive application controls to reduce your machines' attack surfaces](adaptive-application-controls.md).

- Adaptive Network Hardening provides recommendations to further harden the NSG rules. It uses a machine learning algorithm that factors in actual traffic, known trusted configuration, threat intelligence, and other indicators of compromise, and then provides recommendations to allow traffic only from specific IP/port tuples. For more information, see [Improve your network security posture with adaptive network hardening](adaptive-network-hardening.md).

- - Shellcode, which is a small piece of code typically used as the payload in the exploitation of a software vulnerability.

- Log Analytics agent for Linux collects auditd records and enriches and aggregates them into events. Defender for Cloud continuously adds new analytics that use Linux signals to detect malicious behaviors on cloud and on-premises Linux machines. Similar to Windows capabilities, these analytics span across suspicious processes, dubious sign-in attempts, kernel module loading, and other activities. These activities can indicate a machine is either under attack or has been breached.

-| Kubernetes distributions and configurations | **Supported**<br> ΓÇó Any Cloud Native Computing Foundation (CNCF) certified Kubernetes clusters<br>ΓÇó [Azure Kubernetes Service (AKS)](../aks/intro-kubernetes.md)^{[1](#footnote1)}<br> ΓÇó [Amazon Elastic Kubernetes Service (EKS)](https://aws.amazon.com/eks/)<br> ΓÇó [Google Kubernetes Engine (GKE) Standard](https://cloud.google.com/kubernetes-engine/) <br><br> **Supported via Arc enabled Kubernetes** ^{[2](#footnote2)} ^{[3](#footnote3)}<br>ΓÇó [Azure Kubernetes Service on Azure Stack HCI](/azure-stack/aks-hci/overview)<br> ΓÇó [Kubernetes](https://kubernetes.io/docs/home/)<br> ΓÇó [AKS Engine](https://github.com/Azure/aks-engine)<br> ΓÇó [Azure Red Hat OpenShift](https://azure.microsoft.com/services/openshift/)<br> ΓÇó [Red Hat OpenShift](https://www.openshift.com/learn/topics/kubernetes/) (version 4.6 or newer)<br> ΓÇó [VMware Tanzu Kubernetes Grid](https://tanzu.vmware.com/kubernetes-grid)<br> ΓÇó [Rancher Kubernetes Engine](https://rancher.com/docs/rke/latest/en/)<br><br>**Unsupported**<br> ΓÇó Azure Kubernetes Service (AKS) Clusters without [Kubernetes RBAC](../aks/concepts-identity.md#kubernetes-rbac) <br> |

-^{<a name="footnote1"></a>1}The AKS Defender profile doesn't support AKS clusters that don't have RBAC role enabled.<br>

-^{<a name="footnote2"></a>2}Any Cloud Native Computing Foundation (CNCF) certified Kubernetes clusters should be supported, but only the specified clusters have been tested.<br>

-^{<a name="footnote3"></a>3}To get [Microsoft Defender for Containers](../azure-arc/kubernetes/overview.md) protection for you should onboard to [Azure Arc-enabled Kubernetes](https://mseng.visualstudio.com/TechnicalContent/_workitems/recentlyupdated/) and enable Defender for Containers as an Arc extension.

- ### Alert news

-New alerts may be added and existing alerts may be updated or disabled. Certain disabled alerts can be re-enabled from the Support page of the sensor console. Alerts tht can be re-enabled are marked with an asterisk (*) in the tables below.

-| Database Login Failed | A failed sign in attempt was detected from a source device to a destination server. This might be the result of human error, but could also indicate a malicious attempt to compromise the server or data on it. | Major |

-| FTP Login Failed | A failed sign in attempt was detected from a source device to a destination server. This might be the result of human error, but could also indicate a malicious attempt to compromise the server or data on it. | Major |

-| Unauthorized Database Login | A sign in attempt between a source client and destination server was detected. Communication between these devices hasn't been authorized as learned traffic on your network. | Major |

-| Unauthorized SMB Login | A sign in attempt between a source client and destination server was detected. Communication between these devices has not been authorized as learned traffic on your network. | Major |

-| Excessive Login Attempts | A source device was seen performing excessive sign in attempts to a destination server. This may be a brute force attack. The server may be compromised by a malicious actor. | Critical |

-| Excessive Number of Sessions | A source device was seen performing excessive sign in attempts to a destination server. This may be a brute force attack. The server may be compromised by a malicious actor. | Critical |

-| Excessive SMB login attempts | A source device was seen performing excessive sign in attempts to a destination server. This may be a brute force attack. The server may be compromised by a malicious actor. | Critical |

-| Password Guessing Attempt Detected | A source device was seen performing excessive sign in attempts to a destination server. This may be a brute force attack. The server may be compromised by a malicious actor. | Critical |

-# Sensor connection methods

-This article describes the architectures and connection methods supported for connecting your sensors to Microsoft Defender for IoT in the Azure portal.

-All supported connection methods provide:

-This method supports connecting your sensors without direct internet access, using an SSL-encrypted tunnel to transfer data from the sensor to the service endpoint via proxy servers. The proxy server does not perform any data inspection, analysis, or caching.

-With a proxy chaining method, Defender for IoT does not support your proxy service. It's the customer's responsibility to set up and maintain the proxy service.

-If you are a customer with an existing production deployment, we recommend that upgrade any legacy sensor versions to version 22.1.x.

-description: Learn about Microsoft Defender for IoT agentless architecture and information flow.

-# Microsoft Defender for IoT architecture

-This article describes the functional system architecture of the Defender for IoT agentless solution. Microsoft Defender for IoT offers two sets of capabilities to fit your environment's needs, agentless solution for organizations, and agent-based solution for device builders. This article provides architectural information about the agentless solution for organizations.

-## Agentless solution architecture for organizations

-### Defender for IoT components

-Defender for IoT connects both to the Azure cloud and to on-premises components. The solution is designed for scalability in large and geographically distributed environments with multiple remote locations. This solution enables a multi-layered distributed architecture by country, region, business unit, or zone.

-Microsoft Defender for IoT includes the following components:

-**Cloud connected deployments**

-**Air-gapped (Offline) deployments**

-### Microsoft Defender for IoT sensors

-The Defender for IoT sensors discover, and continuously monitor network devices. Sensors collect ICS network traffic using passive (agentless) monitoring on IoT and OT devices.

-

-Purpose-built for IoT and OT networks, the agentless technology delivers deep visibility into IoT and OT risk within minutes of being connected to the network. It has zero performance impact on the network and network devices due to its non-invasive, Network Traffic Analysis (NTA) approach.

-

-Applying patented, IoT and OT-aware behavioral analytics and Layer-7 Deep Packet Inspection (DPI), it allows you to analyze beyond traditional signature-based solutions to immediately detect advanced IoT and OT threats (such as fileless malware) based on anomalous or unauthorized activity.

-

-Defender for IoT sensors connects to a SPAN port or network TAP and immediately begins performing DPI on IoT and OT network traffic.

-

-Data collection, processing, analysis, and alerting takes place directly on the sensor. This process makes it ideally suited for locations with low bandwidth or high latency connectivity, because only metadata is transferred to the management console.

-The sensor includes five analytics detection engines. The engines trigger alerts based on analysis of both real-time and pre-recorded traffic. The following engines are available:

-#### Protocol violation detection engine

-The protocol violation detection engine identifies the use of packet structures and field values that violate ICS protocol specifications, for example: Modbus exception, and Initiation of an obsolete function code alerts.

-#### Policy violation detection engine

-Using machine learning, the policy violation detection engine alerts users of any deviation from baseline behavior, such as unauthorized use of specific function codes, access to specific objects, or changes to device configuration. For example: DeltaV software version changed, and Unauthorized PLC programming alerts. Specifically, the policy violation engine models the ICS networks as deterministic sequences of states and transitionsΓÇöusing a patented technique called Industrial Finite State Modeling (IFSM). The policy violation detection engine establishes a baseline of the ICS networks, so that the platform requires a shorter learning period to build a baseline of the network than generic mathematical approaches or analytics, which were originally developed for IT rather than OT networks.

-#### Industrial malware detection engine

-The industrial malware detection engine identifies behaviors that indicate the presence of known malware, such as Conficker, Black Energy, Havex, WannaCry, NotPetya, and Triton.

-#### Anomaly detection engine

-The anomaly detection engine detects unusual machine-to-machine (M2M) communications and behaviors. By modeling ICS networks as deterministic sequences of states and transitions, the platform requires a shorter learning period than generic mathematical approaches or analytics originally developed for IT rather than OT. It also detects anomalies faster, with minimal false positives. Anomaly detection engine alerts include Excessive SMB sign in attempts, and PLC Scan Detected alerts.

-#### Operational incident detection

-The operational incident detection detects operational issues such as intermittent connectivity that can indicate early signs of equipment failure. For example, the device is thought to be disconnected (unresponsive), and Siemens S7 stop PLC command was sent alerts.

-### Management consoles

-Managing Microsoft Defender for IoT across hybrid environments is accomplished via three management portals:

-### Sensor console

-Sensor detections are displayed in the sensor console, where they can be viewed, investigated, and analyzed in a network map, device inventory, and in an extensive range of reports, for example risk assessment reports, data mining queries and attack vectors. You can also use the console to view and handle threats detected by sensor engines, forward information to partner systems, manage users, and more.

-### On-premises management console

-The on-premises management console enables security operations center (SOC) operators to manage and analyze alerts aggregated from multiple sensors into one single dashboard and provides an overall view of the health of the OT networks.

-This architecture provides a comprehensive unified view of the network at a SOC level, optimized alert handling, and the control of operational network security, ensuring that decision-making and risk management remain flawless.

-In addition to multi-tenancy, monitoring, data analysis, and centralized sensor remote control, the management console provides extra system maintenance tools (such as alert exclusion) and fully customized reporting features for each of the remote appliances. This architecture supports both local management at a site level, zone level, and global management within the SOC.

-The management console can be deployed for high-availability configuration, which provides a backup console that periodically receives backups of all configuration files required for recovery. If the primary console fails, the local site management appliances will automatically fail over to synchronize with the backup console to maintain availability without interruption.

-Tightly integrated with your SOC workflows and run books, it enables easy prioritization of mitigation activities and cross-site correlation of threats.

-### Azure portal

-Defender for IoT in the Azure portal in Azure is used to help you:

-[Defender for IoT FAQ](resources-frequently-asked-questions.md)

-description: Learn about basic Defender for IoT concepts.

-# Basic concepts

-This article describes key advantages of Microsoft Defender for IoT.

-## Rapid non-invasive deployment and passive monitoring

-Defender for IoT sensors connects to switch SPAN (Mirror) ports, and network TAPs and immediately begin collecting ICS network traffic via passive (agentless) monitoring. Deep packet inspection (DPI) is used to dissect traffic from both serial and Ethernet control network equipment. Defender for IoT has zero impact on OT networks because it isn't placed in the data path and doesn't actively scan OT devices.

-To deliver instant snapshots of detailed Windows device information, Defender for IoT sensor can be configured to supplement passive monitoring with an optional active component. This component uses safe, vendor-approved commands to query Windows devices for device details, as often or as infrequently as you want.

-## Embedded knowledge of ICS protocols, devices, and applications

-DPI alone is not enough to identify protocol anomalies and identify device at a granular level. The Defender for IoT sensor addresses some of the largest and most complex environments. More than 1,300 OT networks have been analyzed to date, across all industrial sectors.

-## Analytics and self-learning engines

-Engines identify security issues via continuous monitoring and five analytics engines that incorporate self-learning to eliminate the need for updating signatures or defining rules. The engines use ICS-specific behavioral analytics and data science to continuously analyze OT network traffic for anomalies. The five engines are:

-

-Tools are available to enable and disable sensor engines. Alerts are not triggered from engines that are disabled. See [Control what traffic is monitored](how-to-control-what-traffic-is-monitored.md).

-

-You can fine-tune detection instructions by working with Smart IT learning. See [Learning and Smart IT Learning modes](how-to-control-what-traffic-is-monitored.md#learning-and-smart-it-learning-modes)

-## Detection engines and alerts

-Alerts are triggered when sensor engines detect changes in network traffic and behavior that need your attention. This section describes the kind of alerts that each engine triggers.

-| Alert type | Description |

-|-|-|

-| Policy violation alerts | Triggered when the Policy Violation engine detects a deviation from traffic previously learned. For example: <br /> - A new device is detected. <br /> - A new configuration is detected on a device. <br /> - A device not defined as a programming device carries out a programming change. <br /> - A firmware version changed. |

-| Protocol violation alerts | Triggered when the Protocol Violation engine detects packet structures or field values that don't comply with the protocol specification. |

-| Operational alerts | Triggered when the Operational engine detects network operational incidents or a device malfunctioning. For example, a network device was stopped through a Stop PLC command, or an interface on a sensor stopped monitoring traffic. |

-| Malware alerts | Triggered when the Malware engine detects malicious network activity. For example, the engine detects a known attack such as Conficker. |

-| Anomaly alerts | Triggered when the Anomaly engine detects a deviation. For example, a device is performing network scans but is not defined as a scanning device. |

-

-For more alert information, see:

-## Network Traffic Analysis for risk and vulnerability assessment

-Unique in the industry, Defender for IoT uses proprietary Network Traffic Analysis (NTA) algorithms to passively identify all network and endpoint vulnerabilities, such as:

-## Data mining for investigations, forensics, and threat hunting

-The platform provides an intuitive data-mining interface for granular searching of historical traffic across all relevant dimensions. Examples include time period, IP address, MAC address, and ports. You can also make protocol-specific queries based on function codes, protocol services, and modules. Full-fidelity PCAPs are available for further drill-down analysis.

-## Sensor Cloud Management mode

-The Sensor Cloud Management mode determines where device, alert, and other information that the sensor detects is displayed.

-For **cloud-connected sensors**, information that the sensor detects is displayed in the sensor console. Alert information is delivered to Azure and can be shared with other Azure services, such as Microsoft Sentinel.

-For **locally connected sensors**, information that the sensor detects is displayed in the sensor console. Detection information is also shared with the on-premises management console if the sensor is connected to it.

-## Air-gapped networks

-If you're working in an air-gapped environment, the on-premises management console in Defender for IoT delivers a real-time view of key IoT and OT risk indicators and alerts across all of your facilities. Tightly integrated with your SOC workflows and runbooks, it enables easy prioritization of mitigation activities and cross-site correlation of threats.

-Defender for IoT provides a consolidated view of all your devices. It also provides critical information about the devices, such as type (PLC, RTU, DCS, and more), manufacturer, model, and firmware revision level, as well as alert information.

-Defender for IoT enables the effective management of multiple deployments and a comprehensive unified view of the network. Defender for IoT optimizes alert handling and control of operational network security.

-The on-premises management console is a web-based administrative platform that lets you monitor and control the activities of global sensor installations. In addition to managing the data received from deployed sensors, the on-premises management console seamlessly integrates data from various business resources: CMDBs, DNS, firewalls, Web APIs, and more.

-We recommend that you familiarize yourself with the concepts, capabilities, and features available to sensors before working with the on-premises management console.

-## Integrations

-You can expand the capabilities of Defender for IoT by sharing both device and alert information with partner systems. Integrations help enterprises bridge previously siloed security solutions to significantly enhance device visibility and threat intelligence. Integrations also help enterprises accelerate the system-wide responses and mitigate risks faster.

-Integrations reduce complexity and eliminate IT and OT silos by integrating them into your existing SOC workflows and security stack. For example:

-## Complete protocol support

-In addition to embedded protocol support, you can secure IoT and ICS devices running proprietary and custom protocols, or protocols that deviate from any standard. By using the Horizon Open Development Environment (ODE) SDK, developers can create dissector plug-ins that decode network traffic based on defined protocols. Services analyzes traffic to provide complete monitoring, alerting, and reporting. Use Horizon to:

-In addition, you can use proprietary protocol alerts to communicate information:

-Alerts are triggered when Horizon alert rule conditions are met.

-In addition, working with Horizon custom alerts lets you write your own alert titles and messages. Resolved protocol fields and values can be embedded in the alert message text.

-Using custom, condition-based alert triggering and messaging helps pinpoint specific network activity and effectively update your security, IT, and operational teams.

-For a complete list of supported protocols see, [Supported Protocols](concept-supported-protocols.md).

-## What is an Inventory Device

-The Defender for IoT Device inventory displays an extensive range of asset attributes that are detected by sensors monitoring the organizations networks and managed endpoints.

-Defender for IoT will identify and classify devices as a single unique network device in the inventory for:

-1. Standalone IT/OT/IoT devices (w/ 1 or multiple NICs)

-1. Devices composed of multiple backplane components (including all racks/slots/modules)

-1. Devices acting as network infrastructure such as Switch/Router (w/ multiple NICs).

-Public internet IP addresses, multicast groups, and broadcast groups are not considered inventory devices.

-Devices that have been inactive for more than 60 days are classified as inactive Inventory devices.

-## High availability

-Increase the resilience of your Defender for IoT deployment by installing a high-availability appliance in the on-premises management console. High-availability deployments ensure that your managed sensors continuously report to an active on-premises management console.

-This deployment is implemented with an on-premises management console pair that includes a primary and secondary appliance.

-## Localization

-Many console features support an extensive range of languages.

-## Next step

-[Getting started with Defender for IoT](getting-started.md)

-description: Learn about how integration with Microsoft Sentinel can help SOC teams bridge the gap between IT and OT security sectors

-This article describes how integration with Microsoft Sentinel can help SOC teams bridge the gap between IT and OT security sectors.

-## About the digital transformation in business-critical industries

-As the digital transformation in business-critical industries connects OT systems with IT infrastructures, the OT/IT convergence puts data, systems, and safety at risk.

-As a result, CISOs and Security Operations Center (SOC) teams are becoming increasingly responsible for threats from OT network segments that they traditionally did not handle.

-This means SOC teams must deal with various new challenges, including:

-**People**

-**Processes**

-**Technology and Tools**

-Without OT telemetry, context and integration with existing SOC tools and workflows, OT security and operational threats may be handled incorrectly, or even go unnoticed.

-## About Microsoft Sentinel

-Microsoft Sentinel is a scalable, cloud-native, security information event management (SIEM) and, security orchestration automated response (SOAR) solution that lets users:

-## About the Defender for IoT and Microsoft Sentinel Integration

-By bringing rich telemetry into Microsoft Sentinel from Microsoft Defender for IoT, SOC teams can bridge the gap between IT and OT security sectors. This allows SOC teams to detect and respond faster during the entire attack timelineΓÇöenhancing communication, processes, and response time for both security analysts and OT personnel.

-To set up the integration, see [Integrate Microsoft Defender for IoT and Microsoft Sentinel](../../sentinel/iot-solution.md?tabs=use-out-of-the-box-analytics-rules-recommended).

-## OT Security

-This section describes how the integration helps you handled OT threats.

-**OT Security Alerts**

-Once ingested into Sentinel, security experts can work with IoT/OT-specific analytics rules, workbooks, and SOAR playbooks, as well as incident mappings to MITRE ATT&CK for ICS.

-**MITRE ATT&CK for ICS**

-MITRE ATT&CK® for ICS is a knowledge base used for describing the actions an adversary may take while operating within an ICS network. The knowledge base can be used to better characterize and describe post-compromise adversary behavior.

-The Microsoft Defender for IoT integration delivers a library of mappings that link Microsoft Sentinel incidents to MITRE ATT&CK for ICS tactics.

-## Workbooks, analytics rules, and SOAR playbooks

-This section describes how Microsoft Sentinel workbooks, analytics rules, and SOAR playbooks help you monitor and respond to OT threats.

-To visualize and monitor your Defender for IoT data, use the workbooks deployed to your Microsoft Sentinel workspace as part of the IoT OT Threat Monitoring with Defender for IoT solution.

-For example:

-**Alert workbooks**

-Microsoft Sentinel Alert Workbooks show alerts by:

-**MITRE ATT&CK for ICS Workbook**

-Microsoft Sentinel MITRE ATT&CK for ICS workbooks show the result of mapping alerts to MITRE ATT&CK for ICS tactics, plus the distribution of tactics by count and time period.

-The Workbooks are described in the [Visualize and monitor Defender for IoT data](../../sentinel/iot-solution.md?tabs=use-out-of-the-box-analytics-rules-recommended)

-section of the integration tutorial. Workbooks are deployed to your Microsoft Sentinel workspace as part of the IoT OT Threat Monitoring with Defender for IoT solution.

-### Analytics rules

-Create Microsoft Sentinel incidents for relevant alerts generated by Defender for IoT, either by using out-of-the-box analytics rules provided in the IoT OT Threat Monitoring with Defender for IoT solution, configuring analytics rules manually, or by configuring your data connector to automatically create incidents for all alerts generated by Defender for IoT.

-The Analytics rules are described in the [Detect threats out-of-the-box with Defender for IoT data](../../sentinel/iot-solution.md?tabs=use-out-of-the-box-analytics-rules-recommended) section of the integration tutorial. The rules are deployed to your Microsoft Sentinel workspace as part of the IoT OT Threat Monitoring with Defender for IoT solution.

-Use SOAR playbooks, for example to:

-The playbooks are described in the [Automate response to Defender for IoT alerts](../../sentinel/iot-solution.md?tabs=use-out-of-the-box-analytics-rules-recommended) section of the integration tutorial.

-Playbooks are deployed to your Microsoft Sentinel workspace as part of the IoT OT Threat Monitoring with Defender for IoT solution.

-description: Learn how to connect your sensors to Microsoft Defender for IoT on Azure

-# Connect your sensors to Microsoft Defender for IoT

-If you do not yet have a proxy configured in your Azure VNET, use the following procedures to configure your proxy:

-Use the following procedure to create a scale set to use with your sensor connection. For more information, see [What are Virtual Machine scale sets?](/azure/virtual-machine-scale-sets/overview)

-1. Create a network interface in the `Proxyserver` subnet you created [earlier](#step-2-define-virtual-networks-and-subnets), but do not yet define a load balancer.

- 1. Create the following configuration script, depending on the port and services you are using:

-1. For a backend, choose the VM scale set you created in the [earlier](#step-5-define-an-azure-virtual-machine-scale-set).

- 1. In the Azure portal, go to the load balancer you've just created.

-We have validated this procedure using the open-source [Squid](http://www.squid-cache.org/) proxy. This proxy uses HTTP tunneling and the HTTP CONNECT command for connectivity. Any other proxy chaining connection that supports the CONNECT command can be used for this connection method.

- - **Use public IP addresses over the internet** if you do not need to exchange data using private IP addresses

- - **Use site-to-site VPN over the internet** only if you do *not* require any of the following:

- - If you do not need to own and manage the routers making the connection, use ExpressRoute with a cloud exchange provider.

-1. To enable private connectivity between your VPCs and Defender for IoT, connect your VPC to an Azure VNET over a VPN connection. For example if you are connecting from an AWS VPC, see our TechCommunity blog: [How to create a VPN between Azure and AWS using only managed solutions](https://techcommunity.microsoft.com/t5/fasttrack-for-azure/how-to-create-a-vpn-between-azure-and-aws-using-only-managed/ba-p/2281900).

-1. **Configure any additional resources required** as described in the procedure in this article for your chosen connectivity method. For example, additional resources might include a proxy, VPN, or ExpressRoute.

-1. **After the migration in your production environment**, you can delete any previous IoT Hubs that you had used before the migration. Make sure that any IoT Hubs you delete are not used by any other

-description: In this quickstart, learn how to get started with understanding the basic workflow for Defender for IoT deployment.

-This article provides an overview of the steps you'll take to set up Microsoft Defender for IoT. The process requires that you:

-## Prerequisites

-Here's what you need to get started with Defender for IoT.

-If you are using a Defender for IoT sensor version lower than 22.1.x, you must also have an Azure IoT Hub (Free or Standard tier) **Contributor** role, for cloud-connected management. Make sure that the **Microsoft Defender for IoT** feature is enabled.

-### Supported service regions

-Defender for IoT routes all traffic from all European regions to the West Europe regional datacenter. It routes traffic from all remaining regions to the Central US regional datacenter.

-If you are connecting your sensors using an IoT Hub (legacy), see also the [IoT Hub supported regions](https://azure.microsoft.com/global-infrastructure/services/?products=iot-hub).

-### Permissions: Sensors and on-premises management consoles

-Some of the setup steps require specific user permissions.

-Administrative user permissions are required to activate the sensor and management console, upload SSL/TLS certificates, and generate new passwords.

-### Permissions: Defender for IoT in the Azure portal

-The following table describes user access permissions to Azure portal tools:

-| View details and access software, activation files and threat intelligence packages | Γ£ô | Γ£ô | Γ£ô | Γ£ô |

-| Onboard sensors | | Γ£ô | Γ£ô | Γ£ô |

-## Identify the solution infrastructure

-**Clarify your network setup needs**

-Research your:

-For more information, see [About Microsoft Defender for IoT network setup](how-to-set-up-your-network.md).

-**Clarify which sensor appliances are required to handle the network load**

-Microsoft Defender for IoT supports both physical and virtual deployments. For the physical deployments, you can purchase various certified appliances. For more information, see [Identify required appliances](how-to-identify-required-appliances.md).

-We recommend that you calculate the approximate number of devices that will be monitored. Later, when you register your Azure subscription to the portal, you'll be asked to enter this number. Numbers can be added in intervals of 1,000, for example 1000, 2000, 3000. The numbers of monitored devices are called *committed devices*.

-If you are using a Defender for IoT sensor version lower than 22.1.x, you must also clarify your appliances for the on-premises management console.

-## Register with Microsoft Defender for IoT

-Registration includes:

-You can also use a trial subscription to monitor 1000 devices for free for 30 days. See [Onboard a trial subscription](how-to-manage-subscriptions.md#onboard-a-trial-subscription) for more information.

-**To register**:

-1. Go to the [Defender for IoT: Getting started](https://portal.azure.com/#blade/Microsoft_Azure_IoT_Defender/IoTDefenderDashboard/Getting_Started) in the Azure portal.

-1. Select **Onboard subscription**.

-1. On the **Pricing** page, select a subscription or create a new one, and add the number of committed devices.

-1. Select the **Download the on-premises management console** tab and save the downloaded activation file. This file contains the aggregate committed devices that you defined. The file will be uploaded to the management console after initial sign-in.

-For information on how to offboard a subscription, see [Offboard a subscription](how-to-manage-subscriptions.md#offboard-a-subscription).

-## Install and set up the on-premises management console

-This section is required only when you are using a Defender for IoT sensor version lower than 22.1.x.

-After you acquire your on-premises management console appliance:

-**To install and set up**:

-1. Go to [Defender for IoT: Getting Started](https://portal.azure.com/#blade/Microsoft_Azure_IoT_Defender/IoTDefenderDashboard/Getting_Started) in the Azure portal.

-1. Select the **On-premises management console** tab.

-1. Choose a version and select **Download**.

-1. Install the on-premises management console software. For more information, see [Defender for IoT installation](how-to-install-software.md).

-1. Activate and set up the management console. For more information, see [Activate and set up your on-premises management console](how-to-activate-and-set-up-your-on-premises-management-console.md).

-## Onboard a sensor

-Onboard a sensor by registering it with Microsoft Defender for IoT and downloading a sensor activation file:

-1. Define a sensor name and associate it with a subscription.

-1. Choose a sensor connection mode:

- - **Cloud connected sensors**: Information that sensors detect is displayed in the sensor console. In addition, alert information is delivered to Azure and can be shared with other Azure services, such as Microsoft Sentinel. You can also choose to automatically push threat intelligence packages from Defender for IoT to your sensors. For more information, see [Threat intelligence research and packages](how-to-work-with-threat-intelligence-packages.md).

- - **Locally managed sensors**: Information that sensors detect is displayed in the sensor console. If you're working in an air-gapped network and want a unified view of all information detected by multiple locally managed sensors, work with the on-premises management console.

-1. Select a site to associate your sensor to. Define the display name, and zone. You can also add descriptive tags. The display name, zone, and tags are descriptive entries on the [Sites and Sensors page](how-to-manage-sensors-on-the-cloud.md#manage-on-boarded-sensors).

-1. Select **Register**.

-1. Select **Download activation file**.

-For details about onboarding, see [Onboard and manage sensors with Defender for IoT](how-to-manage-sensors-on-the-cloud.md).

-## Install and set up the sensor

-Download the ISO package from the Azure portal, install the software, and set up the sensor.

-1. Go to [Defender for IoT: Getting started](https://portal.azure.com/#blade/Microsoft_Azure_IoT_Defender/IoTDefenderDashboard/Getting_Started) in the Azure portal.

-1. Select **Set up sensor**.

-1. Choose a version and select **Download**.

-1. Install the sensor software. For more information, see [Defender for IoT installation](how-to-install-software.md).

-1. Activate and set up your sensor. For more information, see [Sign in and activate a sensor](how-to-activate-and-set-up-your-sensor.md).

-## Connect sensors to Defender for IoT

-This section is required only when you are using a Defender for IoT sensor version 22.1.x or higher.

-Connect your sensors to Defender for IoT to ensure that sensors send alert and device inventory information to Defender for IoT on the Azure portal.

-For more information, see [Sensor connection methods](architecture-connections.md) and [Connect your sensors to Microsoft Defender for IoT](connect-sensors.md)

-.

-## Connect sensors to an on-premises management console

-Connect sensors to the management console to ensure that:

-We recommend that you group multiple sensors monitoring the same networks in one zone. Doing this will coalesce information collected by multiple sensors.

-For more information, see [Connect sensors to the on-premises management console](how-to-activate-and-set-up-your-on-premises-management-console.md#connect-sensors-to-the-on-premises-management-console).

-## Next steps ##

-[Welcome to Microsoft Defender for IoT](overview.md)

-[Microsoft Defender for IoT architecture](architecture.md)

- :::image type="content" source="media/how-to-activate-and-set-up-your-sensor/sensor-log-in-1.png" alt-text="Screenshot of a Defender for IoT sensor sign in page.":::

-1. Enter a passphrase and upload a PEM file if required.

-After your sign in, the Microsoft Defender for IoT sensor console opens.

-After your first sign in, the Microsoft Defender for IoT sensor starts to monitor your network automatically. Network devices will appear in the device map and device inventory sections. Microsoft Defender for IoT will begin to detect and alert you on all security and operational incidents that occur in your network. You can then create reports and queries based on the detected information.

- :::image type="content" source="media/how-to-activate-and-set-up-your-sensor/sensor-log-in-1.png" alt-text="Screenshot of the sensor sign in page after the initial setup.":::

-| Alerts | Alerts are triggered when sensor engines detect changes or suspicious activity in network traffic that require your attention. For more information, see [View alerts on your sensor](how-to-view-alerts.md#view-alerts-on-your-sensor).|

- System messages provide general information about your sensor that may require your attention, for example if:

- - your sensor activation file is expired or will expire soon

- - your sensor isn't detecting traffic

- :::image type="content" source="media/how-to-activate-and-set-up-your-sensor/system-messages.png" alt-text="Screenshot of the System messages area on the sensor console page, displayed after selecting the bell icon.":::

-1. Select **System settings** > **Network monitoring** > **Detection Engines and Network Modelling**.

- :::image type="content" source="media/how-to-prepare-your-network/azure-defender-for-iot-sensor-download-software-screen.png" alt-text="Screenshot for sensor software download.":::

-This section provides describes virtual sensors that are available.

-| **Alert Exclusion rules**| Alert *Exclusion rules* defined in the on-premises management console impact the rules detected by managed sensors. As a result, the alerts excluded be these rules won't be displayed in the Alerts page. See [Create alert exclusion rules](how-to-work-with-alerts-on-premises-management-console.md#create-alert-exclusion-rules) for more information.

-| **Managing alerts on-premises** | Alerts **Learned**, **Acknowledged**, or **Muted** in the on-premises management console or in sensors aren't simultaneously updated in Alerts page on the Defender for IoT Cloud Alerts page. This means that this alert will stay open on the Cloud. However another alert will not be triggered from the on-premises components for this activity.

-| **Managing alert in the portal Alerts page** | Changing the status of an alert to **New**, **Active**, or **Closed** on the Alerts page or changing the alert severity on the Alerts page doesn't impact the alert status or severity in the on-premises management console or sensors.

-1. Verify that you've already updated the on-premises management console to the version that you're updating the sensors. For more information see [Update the software version](how-to-manage-the-on-premises-management-console.md#update-the-software-version).

-If you are updating your sensor version from a legacy version to 22.1.x or higher, you'll need a somewhat different activation procedure than for earlier releases.

-# About Microsoft Defender for IoT network setup

-Microsoft Defender for IoT delivers continuous ICS threat monitoring and device discovery. The platform includes the following components:

-**Defender for IoT sensors:** Sensors collect ICS network traffic by using passive (agentless) monitoring. Passive and nonintrusive, the sensors have zero performance impact on OT and IoT networks and devices. The sensor connects to a SPAN port or network TAP and immediately begins monitoring your network. Detections are displayed in the sensor console. There, you can view, investigate, and analyze them in a network map, a device inventory, and an extensive range of reports. Examples include risk assessment reports, data mining queries, and attack vectors.

-**Defender for IoT on-premises management console**: The on-premises management console provides a consolidated view of all network devices. It delivers a real-time view of key OT and IoT risk indicators and alerts across all your facilities. Tightly integrated with your SOC workflows and playbooks, it enables easy prioritization of mitigation activities and cross-site correlation of threats.

-**Defender for IoT in the Azure portal:** The Defender for IoT application can help you purchase solution appliances, install and update software, and update TI packages.

-This article provides information about solution architecture, network preparation, prerequisites, and more to help you successfully set up your network to work with Defender for IoT appliances. Readers working with the information in this article should be experienced in operating and managing OT and IoT networks. Examples include automation engineers, plant managers, OT network infrastructure service providers, cybersecurity teams, CISOs, or CIOs.

-## On-site deployment tasks

-Site deployment tasks include:

-Record site information such as:

-For a detailed list and description of important site information, see [Predeployment checklist](#predeployment-checklist).

-#### Successful monitoring guidelines

-To find the optimal place to connect the appliance in each of your production networks, we recommend that you follow this procedure:

-Prepare a Windows workstation, including the following:

-Make sure the required firewall rules are open on the workstation. See [Network access requirements](#network-access-requirements) for details.

-#### Supported browsers

-The following browsers are supported for the sensors and on-premises management console web applications:

-For more information on supported browsers, see [recommended browsers](../../azure-portal/azure-portal-supported-browsers-devices.md#recommended-browsers).

-Following sensor and on-premises management console installation, a local self-signed certificate is generated and used to access the sensor web application. When signing in to Defender for IoT for the first time, Administrator users are prompted to provide an SSL/TLS certificate. In addition, an option to validate to this certificate as well other system certificates is automatically is enabled. See [About Certificates](how-to-deploy-certificates.md) for details.

-### Network access requirements

-Verify that your organizational security policy allows access to the following:

-#### User access to the sensor and management console

-| Protocol | Transport | In/Out | Port | Used | Purpose | Source | Destination |

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

-| SSH | TCP | In/Out | 22 | CLI | To access the CLI. | Client | Sensor and on-premises management console |

-| HTTPS | TCP | In/Out | 443 | To access the sensor, and on-premises management console web console. | Access to Web console | Client | Sensor and on-premises management console |

-#### Sensor access to Azure portal

-| Protocol | Transport | In/Out | Port | Purpose | Source | Destination |

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

-| HTTPS | TCP | Out | 443 | Access to Azure | Sensor | `*.azure-devices.net`<br> `*.blob.core.windows.net`<br> `*.servicebus.windows.net` |

-#### Sensor access to the on-premises management console

-| Protocol | Transport | In/Out | Port | Used | Purpose | Source | Destination |

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

-| NTP | UDP | In/Out | 123 | Time Sync | Connects the NTP to the on-premises management console. | Sensor | On-premises management console |

-| SSL | TCP | In/Out | 443 | Give the sensor access to the on-premises management console. | The connection between the sensor, and the on-premises management console | Sensor | On-premises management console |

-#### Additional firewall rules for external services (optional)

-Open these ports to allow extra services for Defender for IoT.

-| Protocol | Transport | In/Out | Port | Used | Purpose | Source | Destination |

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

-| SMTP | TCP | Out | 25 | Email | Used to open the customer's mail server, in order to send emails for alerts, and events. | Sensor and On-premises management console | Email server |

-| DNS | TCP/UDP | In/Out | 53 | DNS | The DNS server port. | On-premises management console and Sensor | DNS server |

-| HTTP | TCP | Out | 80 | The CRL download for certificate validation when uploading certificates. | Access to the CRL server | Sensor and on-premises management console | CRL server |

-| [WMI](how-to-configure-windows-endpoint-monitoring.md) | TCP/UDP | Out | 135, 1025-65535 | Monitoring | Windows Endpoint Monitoring. | Sensor | Relevant network element |

-| [SNMP](how-to-set-up-snmp-mib-monitoring.md) | UDP | Out | 161 | Monitoring | Monitors the sensor's health. | On-premises management console and Sensor | SNMP server |

-| LDAP | TCP | In/Out | 389 | Active Directory | Allows Active Directory management of users that have access, to log in to the system. | On-premises management console and Sensor | LDAP server |

-| Proxy | TCP/UDP | In/Out | 443 | Proxy | To connect the sensor to a proxy server | On-premises management console and Sensor | Proxy server |

-| Syslog | UDP | Out | 514 | LEEF | The logs that are sent from the on-premises management console to Syslog server. | On-premises management console and Sensor | Syslog server |

-| LDAPS | TCP | In/Out | 636 | Active Directory | Allows Active Directory management of users that have access, to log in to the system. | On-premises management console and Sensor | LDAPS server |

-| Tunneling | TCP | In | 9000 </br></br> in addition to port 443 </br></br> Allows access from the sensor, or end user, to the on-premises management console. </br></br> Port 22 from the sensor to the on-premises management console. | Monitoring | Tunneling | Endpoint, Sensor | On-premises management console |

-To plan your rack installation:

-## About passive network monitoring

-The appliance receives traffic from multiple sources, either by switch mirror ports (SPAN ports) or by network TAPs. The management port is connected to the business, corporate, or sensor management network with connectivity to an on-premises management console or Defender for IoT in the Azure portal.

-### Purdue model

-The following sections describe Purdue levels.

-#### Level 0: Cell and area

-Level 0 consists of a wide variety of sensors, actuators, and devices involved in the basic manufacturing process. These devices perform the basic functions of the industrial automation and control system, such as:

-#### Level 1: Process control

-Level 1 consists of embedded controllers that control and manipulate the manufacturing process whose key function is to communicate with the Level 0 devices. In discrete manufacturing, those devices are programmable logic controllers (PLCs) or remote telemetry units (RTUs). In process manufacturing, the basic controller is called a distributed control system (DCS).

-#### Level 2: Supervisory

-Level 2 represents the systems and functions associated with the runtime supervision and operation of an area of a production facility. These usually include the following:

-These systems communicate with the PLCs and RTUs in Level 1. In some cases, they communicate or share data with the site or enterprise (Level 4 and Level 5) systems and applications. These systems are primarily based on standard computing equipment and operating systems (Unix or Microsoft Windows).

-#### Levels 3 and 3.5: Site-level and industrial perimeter network

-The site level represents the highest level of industrial automation and control systems. The systems and applications that exist at this level manage site-wide industrial automation and control functions. Levels 0 through 3 are considered critical to site operations. The systems and functions that exist at this level might include the following:

-These systems communicate with the production zone and share data with the enterprise (Level 4 and Level 5) systems and applications.

-#### Levels 4 and 5: Business and enterprise networks

-Level 4 and Level 5 represent the site or enterprise network where the centralized IT systems and functions exist. The IT organization directly manages the services, systems, and applications at these levels.

-## Planning for network monitoring

-The following examples present different types of topologies for industrial control networks, along with considerations for optimal monitoring and placement of sensors.

-### What should be monitored?

-Traffic that goes through layers 1 and 2 should be monitored.

-### What should the Defender for IoT appliance connect to?

-The Defender for IoT appliance should connect to the managed switches that see the industrial communications between layers 1 and 2 (in some cases also layer 3).

-The following diagram is a general abstraction of a multilayer, multitenant network, with an expansive cybersecurity ecosystem typically operated by an SOC and MSSP.

-Typically, NTA sensors are deployed in layers 0 to 3 of the OSI model.

-#### Example: Ring topology

-The ring network is a topology in which each switch or node connects to exactly two other switches, forming a single continuous pathway for the traffic.

-#### Example: Linear bus and star topology

-In a star network, every host is connected to a central hub. In its simplest form, one central hub acts as a conduit to transmit messages. In the following example, lower switches are not monitored, and traffic that remains local to these switches will not be seen. Devices might be identified based on ARP messages, but connection information will be missing.

-#### Multisensor deployment

-Here are some recommendations for deploying multiple sensors:

-| **Number** | **Meters** | **Dependency** | **Number of sensors** |

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

-| The maximum distance between switches | 80 meters | Prepared Ethernet cable | More than 1 |

-| Number of OT networks | More than 1 | No physical connectivity | More than 1 |

-| Number of switches | Can use RSPAN configuration | Up to eight switches with local span close to the sensor by cabling distance | More than 1 |

-#### Traffic mirroring

-To see only relevant information for traffic analysis, you need to connect the Defender for IoT platform to a mirroring port on a switch or a TAP that includes only industrial ICS and SCADA traffic.

-You can monitor switch traffic by using the following methods:

-SPAN and RSPAN are Cisco terminology. Other brands of switches have similar functionality but might use different terminology.

-#### Switch SPAN port

-A switch port analyzer mirrors local traffic from interfaces on the switch to interface on the same switch. Here are some considerations:

-The following configuration examples are for reference only and are based on a Cisco 2960 switch (24 ports) running IOS. They are typical examples only, so don't use them as instructions. Mirror ports on other Cisco operating systems and other brands of switches are configured differently.

-##### Monitoring multiple VLANs

-Defender for IoT allows monitoring VLANs configured in your network. No configuration of the Defender for IoT system is required. The user needs to ensure that the switch in your network is configured to send VLAN tags to Defender for IoT.

-The following example shows the required commands that must be configured on the Cisco switch to enable monitoring VLANs in Defender for IoT:

-**Monitor session**: This command is responsible for the process of sending VLANs to the SPAN port.

-**Monitor Trunk Port F.E. Gi1/1**: VLANs are configured on the trunk port.

-#### Remote SPAN (RSPAN)

-The remote SPAN session mirrors traffic from multiple distributed source ports into a dedicated remote VLAN.

-The data in the VLAN is then delivered through trunked ports across multiple switches to a specific switch that contains the physical destination port. This port connects to the Defender for IoT platform.

-##### More about RSPAN

-> [!NOTE]

-> Make sure that the trunk port that's sharing the remote VLAN between the switches is not defined as a mirror session source port.

->

-> The remote VLAN increases the bandwidth on the trunked port by the size of the mirrored session's bandwidth. Verify that the switch's trunk port supports that.

-#### RSPAN configuration examples

-RSPAN: Based on Cisco catalyst 2960 (24 ports).

-**Source switch configuration example:**

-1. Enter global configuration mode.

-1. Create a dedicated VLAN.

-1. Identify the VLAN as the RSPAN VLAN.

-1. Return to "configure terminal" mode.

-1. Configure all 24 ports as session sources.

-1. Configure the RSPAN VLAN to be the session destination.

-1. Return to privileged EXEC mode.

-1. Verify the port mirroring configuration.

-**Destination switch configuration example:**

-1. Enter global configuration mode.

-1. Configure the RSPAN VLAN to be the session source.

-1. Configure physical port 24 to be the session destination.

-1. Return to privileged EXEC mode.

-1. Verify the port mirroring configuration.

-1. Save the configuration.

-#### Active and passive aggregation TAP

-An active or passive aggregation TAP is installed inline to the network cable. It duplicates both RX and TX to the monitoring sensor.

-The terminal access point (TAP) is a hardware device that allows network traffic to flow from port A to port B, and from port B to port A, without interruption. It creates an exact copy of both sides of the traffic flow, continuously, without compromising network integrity. Some TAPs aggregate transmit and receive traffic by using switch settings if desired. If aggregation is not supported, each TAP uses two sensor ports to monitor send and receive traffic.

-TAPs are advantageous for various reasons. They're hardware-based and can't be compromised. They pass all traffic, even damaged messages, which the switches often drop. They're not processor sensitive, so packet timing is exact where switches handle the mirror function as a low-priority task that can affect the timing of the mirrored packets. For forensic purposes, a TAP is the best device.

-TAP aggregators can also be used for port monitoring. These devices are processor-based and are not as intrinsically secure as hardware TAPs. They might not reflect exact packet timing.

-##### Common TAP models

-These models have been tested for compatibility. Other vendors and models might also be compatible.

-| Image | Model |

-|--|--|

-| :::image type="content" source="media/how-to-set-up-your-network/garland-p1gccas-v2.png" alt-text="Screenshot of Garland P1GCCAS."::: | Garland P1GCCAS |

-| :::image type="content" source="media/how-to-set-up-your-network/ixia-tpa2-cu3-v2.png" alt-text="Screenshot of IXIA TPA2-CU3."::: | IXIA TPA2-CU3 |

-| :::image type="content" source="media/how-to-set-up-your-network/us-robotics-usr-4503-v2.png" alt-text="Screenshot of US Robotics USR 4503."::: | US Robotics USR 4503 |

-##### Special TAP configuration

-| Garland TAP | US Robotics TAP |

-| -- | |

-| Make sure jumpers are set as follows:<br />:::image type="content" source="media/how-to-set-up-your-network/jumper-setup-v2.jpg" alt-text="Screenshot of US Robotics switch.":::| Make sure Aggregation mode is active. |

-## Deployment validation

-### Engineering self-review

-Reviewing your OT and ICS network diagram is the most efficient way to define the best place to connect to, where you can get the most relevant traffic for monitoring.

-The site engineers know what their network looks like. Having a review session with the local network and operational teams will usually clarify expectations and define the best place to connect the appliance.

-Relevant information:

-#### Common questions

-#### Other considerations

-The purpose of the Defender for IoT appliance is to monitor traffic from layers 1 and 2.

-For some architectures, the Defender for IoT appliance will also monitor layer 3, if OT traffic exists on this layer. While you're reviewing the site architecture and deciding whether to monitor a switch, consider the following variables:

- If the ICS architecture is a ring topology, only one switch in this ring needs to be monitored.

-#### Technical validation

-Receiving a sample of recorded traffic (PCAP file) from the switch SPAN (or mirror) port can help to:

-You can record a sample PCAP file (a few minutes) by connecting a laptop to an already configured SPAN port through the Wireshark application.

-#### Wireshark validation

-Use these sections for troubleshooting issues:

-3. Ping the appliance IP address. If there is no response to ping:

- 1. Use the command **network list** to see the current IP address.

- :::image type="content" source="media/how-to-set-up-your-network/list-of-network-commands.png" alt-text="Screenshot of the network list command.":::

-### Appliance is not responding

-For any other issues, contact [Microsoft Support](https://support.microsoft.com/en-us/supportforbusiness/productselection?sapId=82c88f35-1b8e-f274-ec11-c6efdd6dd099).

-## Predeployment checklist

-Use the predeployment checklist to retrieve and review important information that you need for network setup.

-### Site checklist

-Review this list before site deployment:

-| **#** | **Task or activity** | **Status** | **Comments** |

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

-| 1 | Order appliances. | ΓÿÉ | |

-| 2 | Prepare a list of subnets in the network. | ΓÿÉ | |

-| 3 | Provide a VLAN list of the production networks. | ΓÿÉ | |

-| 4 | Provide a list of switch models in the network. | ΓÿÉ | |

-| 5 | Provide a list of vendors and protocols of the industrial equipment. | ΓÿÉ | |

-| 6 | Provide network details for sensors (IP address, subnet, D-GW, DNS). | ΓÿÉ | |

-| 7 | Third-party switch management | ΓÿÉ | |

-| 8 | Create necessary firewall rules and the access list. | ΓÿÉ | |

-| 9 | Create spanning ports on switches for port monitoring, or configure network taps as desired. | ΓÿÉ | |

-| 10 | Prepare rack space for sensor appliances. | ΓÿÉ | |

-| 11 | Prepare a workstation for personnel. | ΓÿÉ | |

-| 12 | Provide a keyboard, monitor, and mouse for the Defender for IoT rack devices. | ΓÿÉ | |

-| 13 | Rack and cable the appliances. | ΓÿÉ | |

-| 14 | Allocate site resources to support deployment. | ΓÿÉ | |

-| 15 | Create Active Directory groups or local users. | ΓÿÉ | |

-| 16 | Set up training (self-learning). | ΓÿÉ | |

-| 17 | Go or no-go. | ΓÿÉ | |

-| 18 | Schedule the deployment date. | ΓÿÉ | |

-| **Date** | **Note** | **Deployment date** | **Note** |

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

-| Defender for IoT | | Site name* | |

-| Name | | Name | |

-| Position | | Position | |

-#### Architecture review

-An overview of the industrial network diagram will allow you to define the proper location for the Defender for IoT equipment.

-1. **Global network diagram** - View a global network diagram of the industrial OT environment. For example:

- :::image type="content" source="media/how-to-set-up-your-network/backbone-switch.png" alt-text="Diagram of the industrial OT environment for the global network.":::

- > [!NOTE]

- > The Defender for IoT appliance should be connected to a lower-level switch that sees the traffic between the ports on the switch.

-1. **Committed devices** - Provide the approximate number of network devices that will be monitored. You will need this information when onboarding your subscription to Defender for IoT in the Azure portal. During the onboarding process, you will be prompted to enter the number of devices in increments of 1000.

-1. **(Optional) Subnet list** - Provide a subnet list for the production networks and a description (optional).

- | **#** | **Subnet name** | **Description** |

- |--| | |

- | 1 | |

- | 2 | |

- | 3 | |

- | 4 | |

-1. **VLANs** - Provide a VLAN list of the production networks.

- | **#** | **VLAN Name** | **Description** |

- |--|--|--|

- | 1 | | |

- | 2 | | |

- | 3 | | |

- | 4 | | |

-1. **Switch models and mirroring support** - To verify that the switches have port mirroring capability, provide the switch model numbers that the Defender for IoT platform should connect to:

- | **#** | **Switch** | **Model** | **Traffic mirroring support (SPAN, RSPAN, or none)** |

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

- | 1 | | |

- | 2 | | |

- | 3 | | |

- | 4 | | |

-1. **Third-party switch management** - Does a third party manage the switches? Y or N

- If yes, who? __________________________________

- What is their policy? __________________________________

- For example:

- - Siemens

- - Rockwell automation ΓÇô Ethernet or IP

- - Emerson ΓÇô DeltaV, Ovation

-1. **Serial connection** - Are there devices that communicate via a serial connection in the network? Yes or No

- If yes, specify which serial communication protocol: ________________

- If yes, mark on the network diagram what devices communicate with serial protocols, and where they are:

- *Add your network diagram with marked serial connection*

-1. **Quality of Service** - For Quality of Service (QoS), the default setting of the sensor is 1.5 Mbps. Specify if you want to change it: ________________

- Business unit (BU): ________________

-1. **Sensor** - Specifications for site equipment

- The sensor appliance is connected to switch SPAN port through a network adapter. It's connected to the customer's corporate network for management through another dedicated network adapter.

- Provide address details for the sensor NIC that will be connected in the corporate network:

- | Item | Appliance 1 | Appliance 2 | Appliance 3 |

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

- | Appliance IP address | | | |

- | Subnet | | | |

- | Default gateway | | | |

- | DNS | | | |

- | Host name | | | |

-1. **iDRAC/iLO/Server management**

- | Item | Appliance 1 | Appliance 2 | Appliance 3 |

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

- | Appliance IP address | | | |

- | Subnet | | | |

- | Default gateway | | | |

- | DNS | | | |

-1. **On-premises management console**

- | Item | Active | Passive (when using HA) |

- |--|--|--|

- | IP address | | |

- | Subnet | | |

- | Default gateway | | |

- | DNS | | |

-1. **SNMP**

- | Item | Details |

- |--|--|

- | IP | |

- | IP address | |

- | Username | |

- | Password | |

- | Authentication type | MD5 or SHA |

- | Encryption | DES or AES |

- | Secret key | |

- | SNMP v2 community string |

-1. **On-premises management console SSL certificate**

- Are you planning to use an SSL certificate? Yes or No

- If yes, what service will you use to generate it? What attributes will you include in the certificate (for example, domain or IP address)?

-1. **SMTP authentication**

- Are you planning to use SMTP to forward alerts to an email server? Yes or No

- If yes, what authentication method you will use?

-1. **Active Directory or local users**

- Contact an Active Directory administrator to create an Active Directory site user group or create local users. Be sure to have your users ready for the deployment day.

-1. IoT device types in the network

- | Device type | Number of devices in the network | Average bandwidth |

- | | | -- |

- | Camera | |

- | X-ray machine | |

- | | |

- | | |

- | | |

- | | |

- | | |

- | | |

- | | |

- | | |

-[About the Defender for IoT installation](how-to-install-software.md)

-Security teams in Microsoft carry out proprietary ICS threat intelligence and vulnerability research. These teams include MSTIC (Microsoft Threat Intelligence Center), DART (Microsoft Detection and Response Team), DCU (Digital Crimes Unit), and Section 52 (IoT/OT/ICS domain experts that track ICS-specific zero-days, reverse-engineering malware, campaigns, and adversaries)

-Threat intelligence packages can be automatically updated to *cloud connected* sensors as they are released by Defender for IoT. Ensure automatic package update by onboarding your cloud connected sensor with the **Automatic Threat Intelligence Updates** option enabled. For more information, see [Onboard a sensor](getting-started.md#onboard-a-sensor).

-Your *cloud connected* sensors can be automatically updated with threat intelligence packages. However, if you would like to take a more conservative approach, you can push packages from Defender for IoT to sensors only when you feel it is required. This gives you the ability to control when a package is installed, without the need to download and then upload it to your sensors.

-1. Review the **Threat Intelligence mode** . *Automatic* indicates that newly available packages will be automatically installed on sensors as they are released by Defender for IoT. *Manual* indicates that you can push newly available packages directly to sensors as needed.

-description: This article discusses Microsoft Defender for IoT features and services and how it helps provide comprehensive IoT security for enterprise IoT networks.

-# Enterprise IoT network protection

-The Microsoft Defender for IoT team is responsible for securing IoT and operational technology (OT) devices end-to-end, whether they're connected to IT, OT, or dedicated IoT networks.

-Enterprise IoT network protection extends agentless capabilities beyond operational environments and into enterprise environments. This protection provides coverage for the entire breadth of IoT devices in these environments, devices that include corporate printers, cameras, and purpose-built or proprietary devices.

-The expansion of IoT into the enterprise network creates a unique opportunity to apply the asset-discovery capabilities of Microsoft 365 Defender.

-## Integration with Microsoft Defender for Endpoint

-You can now integrate Defender for IoT with Defender for Endpoint. When you do so, you're combining Defender for Endpoint device-discovery and agentless monitoring capabilities to help secure enterprise IoT devices that are connected to an IT network. Two examples of such devices are Voice over Internet Protocol (VoIP) phones and smart TVs. The result of this integration is a single, integrated solution that helps secure your entire IoT and OT infrastructure.

-With this integration, you can use Defender for IoT sensors as additional data sources. Defender for IoT sensors provide visibility into areas of your network where Defender for Endpoint is not deployed and employees need to access data remotely. These sensors also provide visibility into IoT-to-IoT and IoT-to-internet communications.

-After you've enabled this integration, any devices that are discovered on the network by either Defender for Iot or Defender for Endpoint will be synced automatically across both portals.

-To learn how to integrate Defender for Endpoint with your Defender for IoT solution, see the Microsoft Defender for Endpoint documentation.

-## Automatic discovery for IT, IoT, and OT

-Use passive, agentless network monitoring to gain insight into your entire inventory of IT, IoT, and OT devices. The discovery process continuously identifies and classifies devices in your network, and it resolves all device details, with zero effect on the network.

-## Single pane of glass

-A centralized user experience lets your security team visualize and secure all IT, IoT, and OT devices, no matter where they're located.

-## The power of unified SIEM and XDR

-Defender for IoT shares its high-resolution signal data with Microsoft Defender 365 and Microsoft Sentinel. This sharing accelerates incident response and provides a bird's eye view across IT, OT, and IoT boundaries.

-Defender for IoT shares rich telemetry data seamlessly with security information and event management (SIEM) and extended detection and response (XDR) platforms, such as Microsoft Sentinel and Microsoft 365 Defender. It also interoperates with other Security Operations Center (SOC) tools, such as Splunk, IBM QRadar, and ServiceNow. Azure Sentinel customers no longer need to switch consoles to put the story together.

-## Easy deployment for a scalable solution

-Defender for IoT helps ensure a quick, frictionless deployment of network sensor appliances, both physical and virtual.

-If you experience any issues, we encourage you to contact our customer support team.

-## Next steps

-For more information, see [Tutorial: Get started with enterprise IoT](tutorial-getting-started-eiot-sensor.md).

-description: Learn more about Defender for IoT features and services, and understand how Defender for IoT provides comprehensive IoT security for OT networks.

-Operational technology (OT) networks power many of the most critical aspects of our society. But many of these technologies were not designed with security in mind and can't be protected with traditional IT security controls. Meanwhile, the Internet of Things (IoT) is enabling a new wave of innovation with billions of connected devices, increasing the attack surface and risk.

-Microsoft Defender for IoT is a unified security solution for identifying IoT/OT devices, vulnerabilities, and threats. It enables you to secure your entire IoT/OT environment, whether you need to protect existing IoT/OT devices or build security into new IoT innovations.

-Microsoft Defender for IoT offers two sets of capabilities to fit your environment's needs.

-For end-user organizations with IoT/OT environments, Microsoft Defender for IoT delivers agentless, network-layer monitoring that:

-The platform can be deployed fully on-premises or in Azure-connected and hybrid environments.

-For IoT device builders, Microsoft Defender for IoT also offers lightweight a micro agent that supports standard IoT operating systems, such as Linux and RTOS. This lightweight agent helps ensure that security is built into your IoT/OT initiatives from the edge to the cloud. It includes source code for flexible, customizable deployment.

-## Agentless solution

-Older IoT, and OT devices don't support agents, and are often unpatched, misconfigured, and invisible to IT teams. Those qualities make them soft targets for threat actors who want to pivot deeper into corporate networks.

-Traditional network security monitoring tools developed for corporate IT networks can't address these environments because they lack a deep understanding of the specialized protocols, devices, and machine-to-machine (M2M) behaviors found in IoT and OT environments.

-The agentless monitoring capabilities in Microsoft Defender for IoT give you visibility and security for these networks. You can then address key concerns for these environments.

-### Automatic device discovery

-Use passive, agentless network monitoring to gain a complete inventory of all your IoT/OT devices, their details, and how they communicate, with zero impact on the IoT/OT network.

-### Proactive visibility into risk and vulnerabilities

-Identify risks and vulnerabilities in your IoT/OT environment. For example, identify unpatched devices, open ports, unauthorized applications, and unauthorized connections. You can also identify changes to device configurations, PLC code, and firmware.

-### IoT/OT threat detection

-Detect anomalous or unauthorized activities with specialized IoT/OT-aware threat intelligence and behavioral analytics. You can even detect advanced threats missed by static IOCs, like zero-day malware, fileless malware, and living-off-the-land tactics.

-### Unified security management across IoT/OT

-Integrate into Microsoft Sentinel for a bird's-eye view of your entire organization. Implement unified IoT/OT security governance with integration into your existing workflows, including third-party tools like Splunk, IBM QRadar, and ServiceNow.

-For more information, see [Microsoft Defender for IoT architecture](architecture.md).

-This article serves as an archive for features and enhancements released for Microsoft Defender for IoT for organizations more than 6 months ago.

-This article lists Microsoft Defender for IoT's new features and enhancements for end-user organizations from the last 6 months.

-Features released earlier than 6 months ago are listed in [What's new archive for in Microsoft Defender for IoT for organizations](release-notes-archive.md).

-description: In this tutorial, you will learn how to onboard to Microsoft Defender for IoT with an Enterprise IoT deployment

-An Azure subscription is required for this tutorial.

-If you don't already have an Azure subscription, create a [free account](https://azure.microsoft.com/free/?WT.mc_id=A261C142F) before you begin.

-If you already have a subscription that is onboarded for Microsoft Defender for IoT for OT environments, you will need to create a new subscription. To learn how to onboard a subscription, see [Onboard a subscription](how-to-manage-subscriptions.md#onboard-a-subscription).

-There is a minimum security level needed to access different parts of Microsoft Defender for IoT. You must have a level of Security Owner, or a Subscription contributor of the subscription to onboard a subscription, and commit to a pricing. Security Reader level permissions to access the Defender for IoT user interface.

-Before you deploy your Enterprise IoT sensor, you will need to configure your server, or VM, and connect a Network Interface Card (NIC) to a switch monitoring (SPAN) port.

-1. (Optional) If you are setting up a proxy server.

- Ensure that packets are being sent to the Event Hub.

-Once you have validated your setup, the device inventory will start to populate with all of your devices after 15 minutes.

-The device inventory is where you will be able to view all of your device systems, and network information. Learn more about the device inventory see [Manage your IoT devices with the device inventory for organizations](how-to-manage-device-inventory-for-organizations.md#manage-your-iot-devices-with-the-device-inventory-for-organizations).

-[Manage your IoT devices with the device inventory for organizations](how-to-manage-device-inventory-for-organizations.md#manage-your-iot-devices-with-the-device-inventory-for-organizations)

-description: In this tutorial, you will learn how to onboard to Microsoft Defender for IoT with a virtual sensor, on a virtual machine, with a trial subscription of Microsoft Defender for IoT.

-# Tutorial: Microsoft Defender for IoT trial setup

-This tutorial will help you learn how to onboard to Microsoft Defender for IoT with a virtual sensor, on a virtual machine, with a trial subscription of Microsoft Defender for IoT. This tutorial will show you the optimal setup for someone who wishes to test Microsoft Defender for IoT, before signing up, and incorporating it into their environment.

-By using virtual environments, along with the software needed to create a sensor, Defender for IoT allows you to:

-> * Onboard with Microsoft Defender for IoT

-> * Download the ISO for the virtual sensor

-> * Create a virtual machine for the sensor

-> * Onboard, and activate the virtual sensor

-## Onboard with Microsoft Defender for IoT

-To get started with Microsoft Defender for IoT, you must have a Microsoft Azure subscription. If you do not have a subscription, you can [create your Azure free account today](https://azure.microsoft.com/free/).

-To evaluate Defender for IoT, you can use a trial subscription. The trial is valid for 30 days and supports up to 1000 committed devices. The trial allows you to deploy a virtual sensor on your network. Use the sensors to monitor traffic, analyze data, generate alerts, learn about network risks and vulnerabilities, and more. The trial also allows you to deploy a virtual on-premises management console to view the aggregated information generated by the sensor.

-**To onboard a subscription to Microsoft Defender for IoT**:

-1. Navigate to the [Azure portal](https://portal.azure.com/).

-1. Search for, and select **Microsoft Defender for IoT**.

-1. Select **Onboard subscription**.

- :::image type="content" source="media/tutorial-onboarding/onboard-subscription.png" alt-text="Screenshot of the selecting the onboard subscription button from the Getting started page.":::

-1. On the Pricing page, select **Start with a trial**.

- :::image type="content" source="media/tutorial-onboarding/start-with-trial.png" alt-text="Screenshot of the start with a trial button to open the trial window.":::

-1. Select a subscription from the Onboard trial subscription pane and then select **Evaluate**.

-1. Confirm your evaluation.

-## Download the ISO for the virtual sensor

-The virtual appliances have minimum specifications that are required for both the sensor and management console. The following table shows the specifications needed for the sensor depending on your environment.

-### Virtual sensor

-| Type | Corporate | Enterprise | SMB |

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

-| vCPU | 32 | 8 | 4 |

-| Memory | 32 GB | 32 GB | 8 GB |

-| Storage | 5.6 TB | 1.8 TB | 500 GB |

-**To download the ISO file for the virtual sensor**:

-1. Navigate to the [Azure portal](https://portal.azure.com/).

-1. Search for, and select **Microsoft Defender for IoT**.

-1. On the Getting started page, select the **Sensor** tab.

-1. Select **Download**.

- :::image type="content" source="media/tutorial-onboarding/sensor-download.png" alt-text="Screenshot of the sensor tab, select download, to download the ISO file for the virtual sensor.":::

-## Create a virtual machine for the sensor

-The virtual sensor supports both VMware, and Hyper-V deployment options. Before you begin the installation, make sure you have the following items:

-### Create the virtual machine for the sensor with ESXi

-**To create the virtual machine for the sensor (ESXi)**:

-1. Add a sensor name and choose:

-1. Change the virtual hardware parameters according to the required [architecture](#download-the-iso-for-the-virtual-sensor).

-1. For **CD/DVD Drive 1**, select **Datastore ISO file** and choose the ISO file that you uploaded earlier.

-### Create a virtual machine for the sensor with Hyper-V

-This procedure describes how to create a virtual machine by using Hyper-V.

-**To create a virtual machine with Hyper-V**:

-1. Create a virtual disk in Hyper-V Manager.

-1. Select **format = VHDX**.

-1. Select **type = Dynamic Expanding**.

-1. Enter the name and location for the VHD.

-1. Enter the required size (according to the [architecture](#download-the-iso-for-the-virtual-sensor)).

-1. Review the summary and select **Finish**.

-1. On the **Actions** menu, create a new virtual machine.

-1. Enter a name for the virtual machine.

-1. Select **Specify Generation** > **Generation 1**.

-1. Specify the memory allocation (according to the [architecture](#download-the-iso-for-the-virtual-sensor)) and select the check box for dynamic memory.

-1. Configure the network adaptor according to your server network topology.

-1. Connect the VHDX created previously to the virtual machine.

-1. Review the summary and select **Finish**.

-1. Right-click the new virtual machine and select **Settings**.

-1. Select **Add Hardware** and add a new network adapter.

-1. Select the virtual switch that will connect to the sensor management network.

-1. Allocate CPU resources (according to the [architecture](#download-the-iso-for-the-virtual-sensor)).

-1. Connect the management console's ISO image to a virtual DVD drive.

-1. Start the virtual machine.

-1. On the **Actions** menu, select **Connect** to continue the software installation.

-## Install the virtual sensor software with ESXi or Hyper-V

-Either ESXi, or Hyper-V can be used to install the software for the virtual sensor.

-1. Open the virtual machine console.

-1. Select the required [architecture](#download-the-iso-for-the-virtual-sensor).

-1. Define the appliance profile and network properties:

- | **Hardware profile** | Based on the required [architecture](#download-the-iso-for-the-virtual-sensor). |

- | **bridge interfaces:** | There's no need to configure the bridge interface. This option is for special use cases only. |

-1. Sign-in credentials are automatically generated and presented. Copy the username and password in a safe place, because they're required to sign-in, and manage your device. The username and password will not be presented again.

-1. The appliance restarts.

-1. Access the sensor via the IP address previously configured: `https://ip_address`.

-To validate the installation of a physical appliance, you need to perform many tests.

-The validation is available to both the **Support**, and **CyberX** user.

-**To access the post validation tool**:

-1. Select **System Settings**> **Health and troubleshooting** > **System Health Check**.

-1. Select a command.

-For post-installation validation, test that:

-**To verify that the system is running**:

-1. Select **Appliance**, and ensure that each line item shows `Running` and the bottom line states `System is up`.

-1. Select **Version**, and ensure that the correct version appears.

-1. Select **ifconfig** to display the parameters for the appliance's physical interfaces, and ensure that they are correct.

-A virtual switch does not have mirroring capabilities. However, you can use promiscuous mode in a virtual switch environment. Promiscuous mode is a mode of operation, as well as a security, monitoring and administration technique, that is defined at the virtual switch, or portgroup level. By default, Promiscuous mode is disabled. When Promiscuous mode is enabled the virtual machineΓÇÖs network interfaces that are in the same portgroup will use the Promiscuous mode to view all network traffic that goes through that virtual switch. You can implement a workaround with either ESXi, or Hyper-V.

-### Configure a SPAN port with ESXi

-### Configure a SPAN port with Hyper-V

-Prior to starting you will need to:

-**To configure a SPAN port with Hyper-V**:

-1. Open the Virtual Switch Manager.

-1. In the Virtual Switches list, select **New virtual network switch** > **External** as the dedicated spanned network adapter type.

- :::image type="content" source="media/tutorial-onboarding/new-virtual-network.png" alt-text="Screenshot of selecting new virtual network and external before creating the virtual switch.":::

-1. Select **Create Virtual Switch**.

-1. Under connection type, select **External Network**.

-1. Ensure the checkbox for **Allow management operating system to share this network adapter** is checked.

- :::image type="content" source="media/tutorial-onboarding/external-network.png" alt-text="Select external network, and allow the management operating system to share the network adapter.":::

-1. Select **OK**.

-#### Attach a SPAN Virtual Interface to the virtual switch

-You are able to attach a SPAN Virtual Interface to the Virtual Switch through Windows PowerShell, or through Hyper-V Manager.

-**To attach a SPAN Virtual Interface to the virtual switch with PowerShell**:

-1. Select the newly added SPAN virtual switch, and add a new network adapter with the following command:

- ```bash

- ADD-VMNetworkAdapter -VMName VK-C1000V-LongRunning-650 -Name Monitor -SwitchName vSwitch_Span

- ```

-1. Enable port mirroring for the selected interface as the span destination with the following command:

- ```bash

- Get-VMNetworkAdapter -VMName VK-C1000V-LongRunning-650 | ? Name -eq Monitor | Set-VMNetworkAdapter -PortMirroring Destination

- ```

- | Parameter | Description |

- |--|--|

- | VK-C1000V-LongRunning-650 | CPPM VA name |

- |vSwitch_Span |Newly added SPAN virtual switch name |

- |Monitor |Newly added adapter name |

-1. Select **OK**.

-These commands set the name of the newly added adapter hardware to be `Monitor`. If you are using Hyper-V Manager, the name of the newly added adapter hardware is set to `Network Adapter`.

-**To attach a SPAN Virtual Interface to the virtual switch with Hyper-V Manager**:

-1. Under the Hardware list, select **Network Adapter**.

-1. In the Virtual Switch field, select **vSwitch_Span**.

- :::image type="content" source="media/tutorial-onboarding/vswitch-span.png" alt-text="Screenshot of selecting the following options on the virtual switch screen.":::

-1. In the Hardware list, under the Network Adapter drop-down list, select **Advanced Features**.

-1. In the Port Mirroring section, select **Destination** as the mirroring mode for the new virtual interface.

- :::image type="content" source="media/tutorial-onboarding/destination.png" alt-text="Screenshot of the selections needed to configure mirroring mode.":::

-1. Select **OK**.

-#### Enable Microsoft NDIS Capture Extensions for the Virtual Switch

-Microsoft NDIS Capture Extensions will need to be enabled for the new virtual switch.

-**To enable Microsoft NDIS Capture Extensions for the newly added virtual switch**:

-1. Open the Virtual Switch Manager on the Hyper-V host.

-1. In the Virtual Switches list, expand the virtual switch name `vSwitch_Span` and select **Extensions**.

-1. In the Switch Extensions field, select **Microsoft NDIS Capture**.

- :::image type="content" source="media/tutorial-onboarding/microsoft-ndis.png" alt-text="Screenshot of enabling the Microsoft NDIS by selecting it from the switch extensions menu.":::

-1. Select **OK**.

-#### Set the Mirroring Mode on the external port

-Mirroring mode will need to be set on the external port of the new virtual switch to be the source.

-You will need to configure the Hyper-V virtual switch (vSwitch_Span) to forward any traffic that comes to the external source port, to the virtual network adapter that you configured as the destination.

-Use the following PowerShell commands to set the external virtual switch port to source mirror mode:

-```bash

-$ExtPortFeature=Get-VMSystemSwitchExtensionPortFeature -FeatureName "Ethernet Switch Port Security Settings"

-$ExtPortFeature.SettingData.MonitorMode=2

-Add-VMSwitchExtensionPortFeature -ExternalPort -SwitchName vSwitch_Span -VMSwitchExtensionFeature $ExtPortFeature

-```

-| Parameter | Description |

-|--|--|

-| vSwitch_Span | Newly added SPAN virtual switch name. |

-| MonitorMode=2 | Source |

-| MonitorMode=1 | Destination |

-| MonitorMode=0 | None |

-Use the following PowerShell command to verify the monitoring mode status:

-```bash

-Get-VMSwitchExtensionPortFeature -FeatureName "Ethernet Switch Port Security Settings" -SwitchName vSwitch_Span -ExternalPort | select -ExpandProperty SettingData

-```

-| Parameter | Description |

-|--|--|

-| vSwitch_Span | Newly added SPAN virtual switch name |

-## Onboard, and activate the virtual sensor

-Before you can start using your Defender for IoT sensor, you will need to onboard the created virtual sensor to your Azure subscription, and download the virtual sensor's activation file to activate the sensor.

-1. Go to [Defender for IoT: Getting started](https://portal.azure.com/#blade/Microsoft_Azure_IoT_Defender/IoTDefenderDashboard/Getting_Started) in the Azure portal.

-1. Select **Onboard sensor**.

-1. Enter a name for the sensor.

- We recommend that you include the IP address of the sensor as part of the name, or use an easily identifiable name. Naming your sensor in this way will ensure easier tracking.

-1. Select a subscription from the drop-down menu.

- :::image type="content" source="media/tutorial-onboarding/name-subscription.png" alt-text="Screenshot of entering a meaningful name, and connect your sensor to a subscription.":::

-1. Choose a sensor connection mode by using the **Cloud connected** toggle. If the toggle is on, the sensor is cloud connected. If the toggle is off, the sensor is locally managed.

- - **Cloud-connected sensors**: Information that the sensor detects is displayed in the sensor console. Alert information is delivered to Defender for Cloud on Azure and can be shared with other Azure services, such as Microsoft Sentinel. In addition, threat intelligence packages can be pushed from Defender for IoT to sensors. Conversely when, the sensor is not cloud connected, you must download threat intelligence packages and then upload them to your enterprise sensors. To allow Defender for IoT to push packages to sensors, enable the **Automatic Threat Intelligence Updates** toggle. For more information, see [Threat intelligence research and packages](how-to-work-with-threat-intelligence-packages.md).

- For cloud connected sensors, the name defined during onboarding is the name that appears in the sensor console. You can't change this name from the console directly. For locally managed sensors, the name applied during onboarding will be stored in Azure but can be updated in the sensor console.

- For more information, see [Sensor connection methods](architecture-connections.md) and [Connect your sensors to Microsoft Defender for IoT](connect-sensors.md).

- - **Locally managed sensors**: Information that sensors detect is displayed in the sensor console. If you're working in an air-gapped network and want a unified view of all information detected by multiple locally managed sensors, work with the on-premises management console.

-1. Select a site to associate your sensor to. Define the display name, and zone. You can also add descriptive tags. The display name, zone, and tags are descriptive entries on the [View onboarded sensors](how-to-manage-sensors-on-the-cloud.md#manage-on-boarded-sensors).

-1. Select **Register**.

-### Download the sensor activation file

-Once registration is complete for the sensor, you will be able to download an activation file for the sensor. The sensor activation file contains instructions about the management mode of the sensor. The activation file you download, will be unique for each sensor that you deploy. The user who signs in to the sensor console for the first time, will uploads the activation file to the sensor.

-**To download an activation file:**

-1. On the **Onboard Sensor** page, select **Register**

-1. Select **download activation file**.

-1. Make the file accessible to the user who's signing in to the sensor console for the first time.

-### Sign in and activate the sensor

-**To sign in and activate:**

-1. Go to the sensor console from your browser by using the IP defined during the installation.

- :::image type="content" source="media/tutorial-onboarding/defender-for-iot-sensor-log-in-screen.png" alt-text="Screenshot of the Microsoft Defender for IoT sensor.":::

-1. Enter the credentials defined during the sensor installation.

-1. Select **Log in** and follow the instructions described in [Activate and set up your sensor](how-to-activate-and-set-up-your-sensor.md#activate-and-set-up-your-sensor).

-## Next steps

-Learn how to set up [other appliances](how-to-install-software.md#about-defender-for-iot-appliances).

-Read about the [agentless architecture](architecture.md).

->

- - the VMs

- - the Stored Secrets

- - PAT tokens of the private Artifact Repos to move the private repos together with the lab.

-<a id="prepare"></a>

-1. Move your current Virtual Network to the new region and resource group using the steps included in the article, "[Move an Azure virtual network to another region](../virtual-network/move-across-regions-vnet-portal.md)".

- Alternately, you can create a new virtual network, if you don't have to keep the original one.

-

- This zip file contains the .json files that comprise the template and scripts to deploy the template. It contains all the resources under your lab listed in ARM template format, except for the Shared Image Gallery resources.

-In order for the ARM template to deploy correctly in the new region, you must change a few parts of the template.

-2. In **Search the Marketplace**, type **template deployment**, and then press **ENTER**.

-3. Select **Template deployment**.

- 

-4. Select **Create**.

-5. Select **Build your own template in the editor**.

-6. Select **Load file**, and then follow the instructions to load the **template.json** file that you downloaded in the last section.

-7. In the editor, make the following changes to the **template.json** file:

- 1. Find the `"type": "microsoft.devtestlab/labs/virtualnetworks"` resource. If you created a new virtual network earlier in these steps, you must add the actual subnet name in `/subnets/[SUBNET_NAME]`. If you chose to move the Vnet to a new region, you should skip this step.

- 1. Find the `"type": "microsoft.devtestlab/labs/virtualmachines"` resource.

- 1. Under the "properties", add ` "password": "RANDOM_PASSWORD" `

- > [!Note]

- > A "password" property is required to create a new VM. We input a random password because we will later be swapping the OS disk with the original VM.

-

- 1. For Shared IP virtual machines, add this snippet under the "properties.networkInterface",

- Windows VM with RDP:

- ```