- * [Set up enrollment for macOS devices - Microsoft Intune](/mem/intune/enrollment/macos-enroll)

- * Deploy [Microsoft Enterprise SSO plug-in for Apple devices - Microsoft identity platform | Azure](../develop/apple-sso-plugin.md)

-* Linux

- * Consider Linux on Azure VM where possible

- * [Sign in to a Linux VM with Azure Active Directory credentials - Azure Virtual Machines](../../active-directory/devices/howto-vm-sign-in-azure-ad-linux.md)

-Permission | Setting explanation

-**Register applications** | Setting this option to **No** prevents users from creating application registrations. You can the grant the ability back to specific individuals by adding them to the application developer role.

-**Allow users to connect work or school account with LinkedIn** | Setting this option to **No** prevents users from connecting their work or school account with their LinkedIn account. For more information, see [LinkedIn account connections data sharing and consent](../enterprise-users/linkedin-user-consent.md).

-**Create security groups** | Setting this option to **No** prevents users from creating security groups. Global administrators and user administrators can still create security groups. To learn how, see [Azure Active Directory cmdlets for configuring group settings](../enterprise-users/groups-settings-cmdlets.md).

-**Create Microsoft 365 groups** | Setting this option to **No** prevents users from creating Microsoft 365 groups. Setting this option to **Some** allows a set of users to create Microsoft 365 groups. Global administrators and user administrators can still create Microsoft 365 groups. To learn how, see [Azure Active Directory cmdlets for configuring group settings](../enterprise-users/groups-settings-cmdlets.md).

-**Access the Azure AD administration portal** | <p>Setting this option to **No** lets non-administrators use the Azure AD administration portal to read and manage Azure AD resources. **Yes** restricts all non-administrators from accessing any Azure AD data in the administration portal.</p><p>This setting does not restrict access to Azure AD data by using PowerShell or other clients such as Visual Studio. When you set this option to **Yes** to grant a specific non-admin user the ability to use the Azure AD administration portal, assign any administrative role such as the directory reader role.</p><p>The directory reader role allows reading basic directory information. Member users have it by default. Guests and service principals don't.</p><p>This settings blocks non-admin users who are owners of groups or applications from using the Azure portal to manage their owned resources. This setting does not restrict access as long as a user is assigned a custom role (or any role) and is not just a user.</p>

-**Read other users** | This setting is available in Microsoft Graph and PowerShell only. Setting this flag to `$false` prevents all non-admins from reading user information from the directory. This flag does not prevent reading user information in other Microsoft services like Exchange Online.</p><p>This setting is meant for special circumstances, so we don't recommend setting the flag to `$false`.

->[!NOTE]

->It's assumed that the average user would only use the portal to access Azure AD, and not use PowerShell or the Azure CLI to access their resources. Currently, restricting access to users' default permissions occurs only when users try to access the directory within the Azure portal.

-As a security improvement, the [device code flow](../develop/v2-oauth2-device-code.md) has been updated to include an another prompt, which validates that the user is signing into the app they expect. The rollout is planned to start in June and expected to be complete by June 30.

-You can add free text notes to Enterprise applications. You can add any relevant information that will help you manager applications under Enterprise applications. For more information, see [Quickstart: Configure properties for an application in your Azure Active Directory (Azure AD) tenant](../manage-apps/add-application-portal-configure.md).

-Starting May 5th, Azure AD will begin enforcing the endpoint change, blocking Azure Government users from signing into apps hosted in Azure Government tenants using the public endpoint (microsoftonline.com). affected apps will begin seeing an error AADSTS900439 - USGClientNotSupportedOnPublicEndpoint.

-[Report-only mode for Azure AD Conditional Access](../conditional-access/concept-conditional-access-report-only.md) lets you evaluate the result of a policy without enforcing access controls. You can test report-only policies across your organization and understand their affect before enabling them, making deployment safer and easier. Over the past few months, weΓÇÖve seen strong adoption of report-only modeΓÇöover 26M users are already in scope of a report-only policy. With the announcement today, new Azure AD Conditional Access policies will be created in report-only mode by default. This means you can monitor the affect of your policies from the moment theyΓÇÖre created. And for those of you who use the MS Graph APIs, you can [manage report-only policies programmatically](/graph/api/resources/conditionalaccesspolicy) as well.

-[Report-only mode for Azure AD Conditional Access](../conditional-access/concept-conditional-access-report-only.md) lets you evaluate the result of a policy without enforcing access controls. You can test report-only policies across your organization and understand their affect before enabling them, making deployment safer and easier. Over the past few months, weΓÇÖve seen strong adoption of report-only mode, with over 26M users already in scope of a report-only policy. With this announcement, new Azure AD Conditional Access policies will be created in report-only mode by default. This means you can monitor the affect of your policies from the moment theyΓÇÖre created. And for those of you who use the MS Graph APIs, you can also [manage report-only policies programmatically](/graph/api/resources/conditionalaccesspolicy).

-[Firstbird](../saas-apps/firstbird-tutorial.md), [Folloze](../saas-apps/folloze-tutorial.md), [Talent Palette](../saas-apps/talent-palette-tutorial.md), [Infor CloudSuite](../saas-apps/infor-cloud-suite-tutorial.md), [Cisco Umbrella](../saas-apps/cisco-umbrella-tutorial.md), [Zscaler Internet Access Administrator](../saas-apps/zscaler-internet-access-administrator-tutorial.md), [Expiration Reminder](../saas-apps/expiration-reminder-tutorial.md), [InstaVR Viewer](../saas-apps/instavr-viewer-tutorial.md), [CorpTax](../saas-apps/corptax-tutorial.md), [Verb](https://app.verb.net/login), [OpenLattice](https://openlattice.com/#/), [TheOrgWiki](https://www.theorgwiki.com/signup), [Pavaso Digital Close](../saas-apps/pavaso-digital-close-tutorial.md), [GoodPractice Toolkit](../saas-apps/goodpractice-toolkit-tutorial.md), [Cloud Service PICCO](../saas-apps/cloud-service-picco-tutorial.md), [AuditBoard](../saas-apps/auditboard-tutorial.md), [iProva](../saas-apps/iprova-tutorial.md), [Workable](../saas-apps/workable-tutorial.md), [CallPlease](https://webapp.callplease.com/create-account/create-account.html), [GTNexus SSO System](../saas-apps/gtnexus-sso-module-tutorial.md), [CBRE ServiceInsight](../saas-apps/cbre-serviceinsight-tutorial.md), [Deskradar](../saas-apps/deskradar-tutorial.md), [Coralogixv](../saas-apps/coralogix-tutorial.md), [Signagelive](../saas-apps/signagelive-tutorial.md), [ARES for Enterprise](../saas-apps/ares-for-enterprise-tutorial.md), [K2 for Office 365](https://www.k2.com/O365), [Xledger](https://www.xledger.net/), [IDID Manager](../saas-apps/idid-manager-tutorial.md), [HighGear](../saas-apps/highgear-tutorial.md), [Visitly](../saas-apps/visitly-tutorial.md), [Korn Ferry ALP](../saas-apps/korn-ferry-alp-tutorial.md), [Acadia](../saas-apps/acadia-tutorial.md), [Adoddle cSaas Platform](../saas-apps/adoddle-csaas-platform-tutorial.md)

-You can access the Azure AD portal to get contextual PowerShell scripts to perform the actions.

-## Review application permissions

-## Revoke permissions using PowerShell commands

-Using the following PowerShell script revokes all permissions granted to this application.

-> [!NOTE]

-> Revoking the current granted permission won't stop users from re-consenting to the application. If you want to block users from consenting, read [Configure how users consent to applications](configure-user-consent.md).

-Now that you have the access key for the Cosmos DB account you can pass it to a Cosmos DB SDK and make calls to access the account. For a quick example, you can pass the access key to the Azure CLI. You can get the `<COSMOS DB CONNECTION URL>` from the **Overview** tab on the Cosmos DB account blade in the Azure portal. Replace the `<ACCESS KEY>` with the value you obtained above:

-```azurecli-interactive

-az cosmosdb collection show -c <COLLECTION ID> -d <DATABASE ID> --url-connection "<COSMOS DB CONNECTION URL>" --key <ACCESS KEY>

-```

-This CLI command returns details about the collection:

-```output

-{

- "collection": {

- "_conflicts": "conflicts/",

- "_docs": "docs/",

- "_etag": "\"00006700-0000-0000-0000-5a8271e90000\"",

- "_rid": "Es5SAM2FDwA=",

- "_self": "dbs/Es5SAA==/colls/Es5SAM2FDwA=/",

- "_sprocs": "sprocs/",

- "_triggers": "triggers/",

- "_ts": 1518498281,

- "_udfs": "udfs/",

- "id": "Test",

- "indexingPolicy": {

- "automatic": true,

- "excludedPaths": [],

- "includedPaths": [

- {

- "indexes": [

- {

- "dataType": "Number",

- "kind": "Range",

- "precision": -1

- },

- {

- "dataType": "String",

- "kind": "Range",

- "precision": -1

- },

- {

- "dataType": "Point",

- "kind": "Spatial"

- }

- ],

- "path": "/*"

- }

- ],

- "indexingMode": "consistent"

- }

- },

- "offer": {

- "_etag": "\"00006800-0000-0000-0000-5a8271ea0000\"",

- "_rid": "f4V+",

- "_self": "offers/f4V+/",

- "_ts": 1518498282,

- "content": {

- "offerIsRUPerMinuteThroughputEnabled": false,

- "offerThroughput": 400

- },

- "id": "f4V+",

- "offerResourceId": "Es5SAM2FDwA=",

- "offerType": "Invalid",

- "offerVersion": "V2",

- "resource": "dbs/Es5SAA==/colls/Es5SAM2FDwA=/"

- }

-}

-```

-Now that you have the access key for the Cosmos DB account you can pass it to a Cosmos DB SDK and make calls to access the account. For a quick example, you can pass the access key to the Azure CLI. You can get the `<COSMOS DB CONNECTION URL>` from the **Overview** tab on the Cosmos DB account blade in the Azure portal. Replace the `<ACCESS KEY>` with the value you obtained above:

-```azurecli

-az cosmosdb collection show -c <COLLECTION ID> -d <DATABASE ID> --url-connection "<COSMOS DB CONNECTION URL>" --key <ACCESS KEY>

-```

-This CLI command returns details about the collection:

-```output

-{

- "collection": {

- "_conflicts": "conflicts/",

- "_docs": "docs/",

- "_etag": "\"00006700-0000-0000-0000-5a8271e90000\"",

- "_rid": "Es5SAM2FDwA=",

- "_self": "dbs/Es5SAA==/colls/Es5SAM2FDwA=/",

- "_sprocs": "sprocs/",

- "_triggers": "triggers/",

- "_ts": 1518498281,

- "_udfs": "udfs/",

- "id": "Test",

- "indexingPolicy": {

- "automatic": true,

- "excludedPaths": [],

- "includedPaths": [

- {

- "indexes": [

- {

- "dataType": "Number",

- "kind": "Range",

- "precision": -1

- },

- {

- "dataType": "String",

- "kind": "Range",

- "precision": -1

- },

- {

- "dataType": "Point",

- "kind": "Spatial"

- }

- ],

- "path": "/*"

- }

- ],

- "indexingMode": "consistent"

- }

- },

- "offer": {

- "_etag": "\"00006800-0000-0000-0000-5a8271ea0000\"",

- "_rid": "f4V+",

- "_self": "offers/f4V+/",

- "_ts": 1518498282,

- "content": {

- "offerIsRUPerMinuteThroughputEnabled": false,

- "offerThroughput": 400

- },

- "id": "f4V+",

- "offerResourceId": "Es5SAM2FDwA=",

- "offerType": "Invalid",

- "offerVersion": "V2",

- "resource": "dbs/Es5SAA==/colls/Es5SAM2FDwA=/"

- }

-}

-```

-description: Learn how to configure Azure Active Directory to automatically provision and de-provision user accounts to iProva.

-writer: twimmers

-# Tutorial: Configure iProva for automatic user provisioning

-The objective of this tutorial is to demonstrate the steps to be performed in iProva and Azure Active Directory (Azure AD) to configure Azure AD to automatically provision and de-provision users and/or groups to [iProva](https://www.iProva.com/). For important details on what this service does, how it works, and frequently asked questions, see [Automate user provisioning and deprovisioning to SaaS applications with Azure Active Directory](../app-provisioning/user-provisioning.md). Before you attempt to use this tutorial, be sure that you know and meet all requirements. If you have questions, please contact Infoland.

-> [!NOTE]

-> This connector is currently in Public Preview. For more information on the general Microsoft Azure terms of use for Preview features, see [Supplemental Terms of Use for Microsoft Azure Previews](https://azure.microsoft.com/support/legal/preview-supplemental-terms/).

-## Capabilities supported

-> [!div class="checklist"]

-> * Create users in iProva

-> * Remove/disable users in iProva when they do not require access anymore

-> * Keep user attributes synchronized between Azure AD and iProva

-> * Provision groups and group memberships in iProva

-> * [Single sign-on](./iprova-tutorial.md) to iProva (recommended)

-## Prerequisites

-The scenario outlined in this tutorial assumes that you already have the following prerequisites:

-* [An Azure AD tenant](../develop/quickstart-create-new-tenant.md).

-* A user account in Azure AD with [permission](../roles/permissions-reference.md) to configure provisioning (e.g. Application Administrator, Cloud Application administrator, Application Owner, or Global Administrator).

-* [An iProva tenant](https://www.iProva.com/).

-* A user account in iProva with Admin permissions.

-## Step 1. Plan your provisioning deployment

-1. Learn about [how the provisioning service works](../app-provisioning/user-provisioning.md).

-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 iProva](../app-provisioning/customize-application-attributes.md).

-## Step 2. Configure iProva to support provisioning with Azure AD

-1. Sign in to your [iProva Admin Console](https://www.iProva.com/). Navigate to **Go to > Application Management**.

- 

-2. Click on **External user management**.

- 

-3. To add a new provider, Click on the **plus** icon. In the new **Add provider** dialog box, provide a **Title**. You can choose to add **IP-based access restriction**. Click on **OK** button.

- 

- 

-4. Click on **Permanent token** button. Copy the **Permanent token** and save it as this will be the only time you can view it. This value will be entered in the Secret Token field in the Provisioning tab of your iProva application in the Azure portal.

- 

-## Step 3. Add iProva from the Azure AD application gallery

-Add iProva from the Azure AD application gallery to start managing provisioning to iProva. If you have previously setup iProva for SSO you can use the same application. However it is recommended that you create a separate app when testing out the integration initially. Learn more about adding an application from the gallery [here](../manage-apps/add-application-portal.md).

-## Step 4. Define who will be in scope for provisioning

-The Azure AD provisioning service allows you to scope who will be provisioned based on assignment to the application and or based on attributes of the user / group. If you choose to scope who will be provisioned to your app based on assignment, you can use the following [steps](../manage-apps/assign-user-or-group-access-portal.md) to assign users and groups to the application. If you choose to scope who will be provisioned based solely on attributes of the user or group, you can use a scoping filter as described [here](../app-provisioning/define-conditional-rules-for-provisioning-user-accounts.md).

-* Start small. Test with a small set of users and groups before rolling out to everyone. When scope for provisioning is set to assigned users and groups, you can control this by assigning one or two users or groups to the app. When scope is set to all users and groups, you can specify an [attribute based scoping filter](../app-provisioning/define-conditional-rules-for-provisioning-user-accounts.md).

-* If you need additional roles, you can [update the application manifest](../develop/howto-add-app-roles-in-azure-ad-apps.md) to add new roles.

-## Step 5. Configure automatic user provisioning to iProva

-This section guides you through the steps to configure the Azure AD provisioning service to create, update, and disable users and/or groups in iProva based on user and/or group assignments in Azure AD.

-### To configure automatic user provisioning for iProva in Azure AD:

-1. Sign in to the [Azure portal](https://portal.azure.com). Select **Enterprise Applications**, then select **All applications**.

- 

-2. In the applications list, select **iProva**.

- 

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

- 

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

- 

-5. In the **Admin Credentials** section, input the **SCIM 2.0 base URL and Permanent Token** values retrieved earlier in the **Tenant URL** and add /scim/ to it. Also add the **Secret Token**. You can generate a secret token in iProva by using the **permanent token** button. Click **Test Connection** to ensure Azure AD can connect to iProva. If the connection fails, ensure your iProva 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 check the checkbox - **Send an email notification when a failure occurs**.

- 

-7. Click **Save**.

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

-9. Review the user attributes that are synchronized from Azure AD to iProva in the **Attribute Mapping** section. The attributes selected as **Matching** properties are used to match the user accounts in iProva for update operations. Select the **Save** button to commit any changes.

- |Attribute|Type|

- |||

- |active|Boolean|

- |displayName|String|

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

- |preferredLanguage|String|

- |userName|String|

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

- |externalId|String|

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

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

- |Attribute|Type|

- |||

- |displayName|String|

- |members|Reference|

- |externalID|String|

-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 iProva, change the **Provisioning Status** to **On** in the **Settings** section.

- 

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

- 

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

- 

-This operation starts the initial synchronization of all users and/or groups defined in **Scope** in the **Settings** section. The initial sync takes longer to perform than subsequent syncs, which occur approximately every 40 minutes as long as the Azure AD provisioning service is running.

-## Step 6. Monitor your deployment

-Once you've configured provisioning, use the following resources to monitor your deployment:

-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).

-## Change log

-* 06/17/2020 - Enterprise extension attribute "Manager" has been removed.

-## Additional resources

-* [Managing user account provisioning for Enterprise Apps](../app-provisioning/configure-automatic-user-provisioning-portal.md)

-* [What is application access and single sign-on with Azure Active Directory?](../manage-apps/what-is-single-sign-on.md)

-## Next steps

-* [Learn how to review logs and get reports on provisioning activity](../app-provisioning/check-status-user-account-provisioning.md)

-Kubernetes uses the horizontal pod autoscaler (HPA) to monitor the resource demand and automatically scale the number of replicas. By default, the horizontal pod autoscaler checks the Metrics API every 60 seconds for any required changes in replica count. When changes are required, the number of replicas is increased or decreased accordingly. Horizontal pod autoscaler works with AKS clusters that have deployed the Metrics Server for Kubernetes 1.8+.

-As the horizontal pod autoscaler checks the Metrics API every 30 seconds, previous scale events may not have successfully completed before another check is made. This behavior could cause the horizontal pod autoscaler to change the number of replicas before the previous scale event could receive application workload and the resource demands to adjust accordingly.

-[Dapr](https://dapr.io/) is a portable, event-driven runtime that makes it easy for any developer to build resilient, stateless and stateful applications that run on the cloud and edge and embraces the diversity of languages and developer frameworks. Leveraging the benefits of a sidecar architecture, Dapr helps you tackle the challenges that come with building microservices and keeps your code platform agnostic. In particular, it helps with solving problems around services calling other services reliably and securely, building event-driven apps with pub-sub, and building applications that are portable across multiple cloud services and hosts (e.g., Kubernetes vs. a VM).

-> If you plan on installing Dapr in a Kubernetes production environment, please see the [Dapr guidelines for production usage][kubernetes-production] documentation page.

-Once Dapr is installed on your cluster, you can begin to develop using the Dapr building block APIs by [adding a few annotations][dapr-deployment-annotations] to your deployments. For a more in-depth overview of the building block APIs and how to best use them, please see the [Dapr building blocks overview][building-blocks-concepts].

-You will need the `k8s-extension` Azure CLI extension. Install this by running the following commands:

-For a list of available options, please see [Dapr configuration][dapr-configuration-options].

-## Limiting the extension to certain nodes (`nodeSelector`)

-In some configurations you may only want to run Dapr on certain nodes. This can be accomplished by passing a `nodeSelector` in the extension configuration. Note that if the desired `nodeSelector` contains `.`, you must escape them from the shell and the extension. For example, the following configuration will install Dapr to only nodes with `kubernetes.io/os=linux`:

-> Some configuration options cannot be modified post-creation. Adjustments to these options require deletion and recreation of the extension. This is applicable to the following settings:

-To update your Dapr configuration settings, simply recreate the extension with the desired state. For example, assume we have previously created and installed the extension using the following configuration:

-To update the `dapr_operator.replicaCount` from 2 to 3, use the following:

- - You can provide configuration settings for Gunicorn through a *gunicorn.conf.py* file in the project root, as described on [Gunicorn configuration overview](https://docs.gunicorn.org/en/stable/configure.html#configuration-file) (docs.gunicorn.org). You can alternately [customize the startup command](#customize-startup-command).

-As noted earlier in this article, you can provide configuration settings for Gunicorn through a *gunicorn.conf.py* file in the project root, as described on [Gunicorn configuration overview](https://docs.gunicorn.org/en/stable/configure.html#configuration-file).

-If such configuration is not sufficient, you can control the container's startup behavior by providing either a custom startup command or multiple commands in a startup command file. A startup command file can use whatever name you choose, such as *startup.sh*, *startup.cmd*, *startup.txt*, and so on.

-`abfa0a7c-a6b6-4736-8310-5855508787cd` is the resource provider service principal name for App Service, and it's the same for all Azure subscriptions. For Azure Government cloud environment, use `6a02c803-dafd-4136-b4c3-5a6f318b4714` instead as the resource provider service principal name.

-> [Manage an App Service plan](app-service-plan-manage.md)

-> id=$(az ad app show --id <back-end-client-id> --query objectId --output tsv)

-1. In the SQL prompt for the database you want, run the following commands to grant the permissions your app needs. For example,

- - For windows: you can find the settings file at `C:\Packages\Plugins\Microsoft.Azure.Automation.HybridWorker.HybridWorkerForWindows\<version>\bin`.

-* File an Azure support incident. Go to the [Azure support site](https://azure.microsoft.com/support/options/), and select **Get Support**.

-> Update assessment of Linux machines is only supported in certain regions as listed in the Automation account and Log Analytics workspace [mappings table](../how-to/region-mappings.md#supported-mappings).

-### Windows

-### Linux

-> Update Management does not support safely automating update management across all instances in an Azure virtual machine scale set. [Automatic OS image upgrades](../../virtual-machine-scale-sets/virtual-machine-scale-sets-automatic-upgrade.md) is the recommended method for managing OS image upgrades on your scale set.

-The following information describes operating system-specific requirements. For additional guidance, see [Network planning](plan-deployment.md#ports). To understand requirements for TLS 1.2, see [TLS 1.2 for Azure Automation](../automation-managing-data.md#tls-12-for-azure-automation).

-### Windows

-Software Requirements:

-Windows Update agents must be configured to communicate with a Windows Server Update Services (WSUS) server, or they require access to Microsoft Update. For hybrid machines, we recommend installing the Log Analytics agent for Windows by first connecting your machine to [Azure Arc-enabled servers](../../azure-arc/servers/overview.md), and then use Azure Policy to assign the [Deploy Log Analytics agent to Windows Azure Arc machines](../../governance/policy/samples/built-in-policies.md#monitoring) built-in policy definition. Alternatively, if you plan to monitor the machines with VM insights, instead use the [Enable Enable VM insights](../../governance/policy/samples/built-in-initiatives.md#monitoring) initiative.

-### Linux

-Software Requirements:

-> Update assessment of Linux machines is only supported in certain regions. See the Automation account and Log Analytics workspace [mappings table](../how-to/region-mappings.md#supported-mappings).

-For hybrid machines, we recommend installing the Log Analytics agent for Linux by first connecting your machine to [Azure Arc-enabled servers](../../azure-arc/servers/overview.md), and then use Azure Policy to assign the [Deploy Log Analytics agent to Linux Azure Arc machines](../../governance/policy/samples/built-in-policies.md#monitoring) built-in policy definition. Alternatively, if you plan to monitor the machines with Azure Monitor for VMs, instead use the [Enable Azure Monitor for VMs](../../governance/policy/samples/built-in-initiatives.md#monitoring) initiative.

-| [Azure Container Instances](../container-instances/container-instances-region-availability.md) |  |

-description: Learn how to disable access key authentication for an Azure App Configuration instance (preview)

-# Disable access key authentication for an Azure App Configuration instance (preview)

-The capability to disable access key authentication is available as a preview. The following limitations are currently in place.

-# Recover Azure App Configuration stores (Preview)

-description: "Use Cluster Connect to securely connect to Azure Arc-enabled Kubernetes clusters"

-# Use Cluster Connect to connect to Azure Arc-enabled Kubernetes clusters

-With Cluster Connect, you can securely connect to Azure Arc-enabled Kubernetes clusters without requiring any inbound port to be enabled on the firewall.

-1. Create a service account token by :

-1. Set up the Cluster Connect based kubeconfig needed to access your cluster based on the authentication option used:

- - If using Azure Active Directory authentication option, after logging into Azure CLI using the Azure AD entity of interest, get the Cluster Connect `kubeconfig` needed to communicate with the cluster from anywhere (from even outside the firewall surrounding the cluster):

- - If using the service account authentication option, get the Cluster Connect `kubeconfig` needed to communicate with the cluster from anywhere:

-When making requests to the Kubernetes cluster, if the Azure AD entity used is a part of more than 200 groups, the following error is observed as this is a known limitation:

-To get past this error:

-description: "This article provides a conceptual overview of Cluster Connect capability of Azure Arc-enabled Kubernetes"

-# Access Azure Arc-enabled Kubernetes cluster from anywhere using Cluster Connect

-The Azure Arc-enabled Kubernetes *cluster connect* feature provides connectivity to the `apiserver` of the cluster without requiring any inbound port to be enabled on the firewall. A reverse proxy agent running on the cluster can securely start a session with the Azure Arc service in an outbound manner.

-Cluster connect allows developers to access their clusters from anywhere for interactive development and debugging. It also lets cluster users and administrators access or manage their clusters from anywhere. You can even use hosted agents/runners of Azure Pipelines, GitHub Actions, or any other hosted CI/CD service to deploy applications to on-prem clusters, without requiring self-hosted agents.

-On the cluster side, a reverse proxy agent called `clusterconnect-agent` deployed as part of agent helm chart, makes outbound calls to Azure Arc service to establish the session.

-1. Azure Arc proxy binary is downloaded and spun up as a process on the client machine.

-1. Azure Arc proxy fetches a `kubeconfig` file associated with the Azure Arc-enabled Kubernetes cluster on which the `az connectedk8s proxy` is invoked.

- * Azure Arc proxy uses the caller's Azure access token and the Azure Resource Manager ID name.

-1. The `kubeconfig` file, saved on the machine by Azure Arc proxy, points the server URL to an endpoint on the Azure Arc proxy process.

-1. Azure Arc proxy maps the endpoint receiving the request to the Azure Arc service.

-1. Azure Arc service then forwards the request to the `clusterconnect-agent` running on the cluster.

-1. The `clusterconnect-agent` passes on the request to the `kube-aad-proxy` component, which performs Azure AD authentication on the calling entity.

-1. After Azure AD authentication, `kube-aad-proxy` uses Kubernetes [user impersonation](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#user-impersonation) feature to forward the request to the cluster's `apiserver`.

-* [Access your cluster](./cluster-connect.md) securely from anywhere using Cluster connect.

-description: "This article provides a conceptual overview of Custom Locations capability of Azure Arc-enabled Kubernetes"

-As an extension of the Azure location construct, *Custom Locations* provides a way for tenant administrators to use their Azure Arc-enabled Kubernetes clusters as target locations for deploying Azure services instances. Azure resources examples include Azure Arc-enabled SQL Managed Instance and Azure Arc-enabled PostgreSQL Hyperscale.

-Similar to Azure locations, end users within the tenant with access to Custom Locations can deploy resources there using their company's private compute.

-You can visualize Custom Locations as an abstraction layer on top of Azure Arc-enabled Kubernetes cluster, cluster connect, and cluster extensions. Custom Locations creates the granular [RoleBindings and ClusterRoleBindings](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#rolebinding-and-clusterrolebinding) necessary for other Azure services to access the cluster. These other Azure services require cluster access to manage resources the customer wants to deploy on their clusters.

-When the admin enables the Custom Locations feature on the cluster, a ClusterRoleBinding is created on the cluster, authorizing the Azure AD application used by the Custom Locations Resource Provider (RP). Once authorized, Custom Locations RP can create ClusterRoleBindings or RoleBindings needed by other Azure RPs to create custom resources on this cluster. The cluster extensions installed on the cluster determines the list of RPs to authorize.

-When the user creates a data service instance on the cluster:

-1. The PUT request is forwarded to the Azure Arc-enabled Data Services RP.

-1. The RP fetches the `kubeconfig` file associated with the Azure Arc-enabled Kubernetes cluster, on which the Custom Location exists.

- * Custom Location is referenced as `extendedLocation` in the original PUT request.

-1. Azure Arc-enabled Data Services RP uses the `kubeconfig` to communicate with the cluster to create a custom resource of the Azure Arc-enabled Data Services type on the namespace mapped to the Custom Location.

- * The Azure Arc-enabled Data Services operator was deployed via cluster extension creation before the Custom Location existed.

-1. The Azure Arc-enabled Data Services operator reads the new custom resource created on the cluster and creates the data controller, translating into realization of the desired state on the cluster.

- *Custom Locations* provides a way for tenant or cluster administrators to configure their Azure Arc-enabled Kubernetes clusters as target locations for deploying instances of Azure offerings. Examples of Azure offerings that can be deployed on top of custom locations include databases like Azure Arc-enabled SQL Managed Instance and Azure Arc-enabled PostgreSQL Hyperscale or application instances like App Services, Functions, Event Grid, Logic Apps, and API Management. A custom location has a one-to-one mapping to a namespace within the Azure Arc-enabled Kubernetes cluster. The custom location Azure resource combined with Azure RBAC can be used to grant application developers or database admins granular permissions to deploy different resources like databases or application instances on top of the Arc-enabled Kubernetes cluster in a multi-tenant manner.

-

-A conceptual overview of this feature is available in [Custom locations - Azure Arc-enabled Kubernetes](conceptual-custom-locations.md) article.

-> * Enable custom locations on your Azure Arc-enabled Kubernetes cluster.

-> * Create a custom location.

- - `connectedk8s` (version 1.2.0 or later)

- - `k8s-extension` (version 1.0.0 or later)

- - `customlocation` (version 0.1.3 or later)

-

-

-

- - [Upgrade your agents](agent-upgrade.md#manually-upgrade-agents) to version 1.5.3 or later.

-## Enable custom locations on cluster

-If you are logged into Azure CLI as an Azure AD user, to enable this feature on your cluster, execute the following command:

-If you run the above command while being logged into Azure CLI using a service principal, you may observe the following warning:

-This is because a service principal doesn't have permissions to get information of the application used by Azure Arc service. To avoid this error, execute the following steps:

-1. Login into Azure CLI using your user account. Fetch the Object ID of the Azure AD application used by Azure Arc service:

-1. Login into Azure CLI using the service principal. Use the `<objectId>` value from above step to enable custom locations feature on the cluster:

-> 1. Custom Locations feature is dependent on the Cluster Connect feature. So both features have to be enabled for custom locations to work.

-> 2. `az connectedk8s enable-features` needs to be run on a machine where the `kubeconfig` file is pointing to the cluster on which the features are to be enabled.

- * [Azure Arc-enabled Data Services](../dat)

- > [!NOTE]

- > Outbound proxy without authentication and outbound proxy with basic authentication are supported by the Azure Arc-enabled Data Services cluster extension. Outbound proxy that expects trusted certificates is currently not supported.

- * [Azure App Service on Azure Arc](../../app-service/manage-create-arc-environment.md#install-the-app-service-extension)

- * [Event Grid on Kubernetes](../../event-grid/kubernetes/install-k8s-extension.md)

-2. Get the Azure Resource Manager identifier of the Azure Arc-enabled Kubernetes cluster, referenced in later steps as `connectedClusterId`:

-3. Get the Azure Resource Manager identifier of the cluster extension deployed on top of Azure Arc-enabled Kubernetes cluster, referenced in later steps as `extensionId`:

-4. Create custom location by referencing the Azure Arc-enabled Kubernetes cluster and the extension:

-**Required parameters**

-| Parameter name | Description |

-|-||

-| `--name, --n` | Name of the custom location |

-| `--resource-group, --g` | Resource group of the custom location |

-| `--namespace` | Namespace in the cluster bound to the custom location being created |

-| `--host-resource-id` | Azure Resource Manager identifier of the Azure Arc-enabled Kubernetes cluster (connected cluster) |

-| `--cluster-extension-ids` | Azure Resource Manager identifiers of the cluster extension instances installed on the connected cluster. Provide a space-separated list of the cluster extension IDs |

-**Optional parameters**

-| Parameter name | Description |

-|--||

-| `--location, --l` | Location of the custom location Azure Resource Manager resource in Azure. By default it will be set to the location of the connected cluster |

-| `--tags` | Space-separated list of tags: key[=value] [key[=value] ...]. Use '' to clear existing tags |

-| `--kubeconfig` | Admin `kubeconfig` of cluster |

-Show details of a custom location

-**Required parameters**

-| `--resource-group, --g` | Resource group of the custom location |

-Lists all custom locations in a resource group

-**Required parameters**

-| `--resource-group, --g` | Resource group of the custom location |

-Use `update` command when you want to add new tags, associate new cluster extension IDs to the custom location while retaining existing tags and associated cluster extensions. `--cluster-extension-ids`, `--tags`, `assign-identity` can be updated.

-**Required parameters**

-**Optional parameters**

-Use `patch` command when you want to replace existing tags, cluster extension IDs with new tags, cluster extension IDs. `--cluster-extension-ids`, `assign-identity`, `--tags` can be patched.

-**Required parameters**

-**Optional parameters**

-The Azure portal includes a Kubernetes resource view for easy access to the Kubernetes resources in your Azure Arc-enabled Kubernetes cluster. Viewing Kubernetes resources from the Azure portal reduces context switching between the Azure portal and the `kubectl` command-line tool, streamlining the experience for viewing and editing your Kubernetes resources. The resource viewer currently includes multiple resource types, such as deployments, pods, and replica sets.

-To see the Kubernetes resources, navigate to your AKS cluster in the Azure portal. The navigation pane on the left is used to access your resources. The resources include:

-After editing the YAML, changes are applied by selecting **Review + save**, confirming the changes, and then saving again.

-> Performing direct production changes via UI or CLI is not recommended and you should consider using [Configurations (GitOps)](tutorial-use-gitops-connected-cluster.md) for production environments. The Azure portal Kubernetes management capabilities and the YAML editor are built for learning and flighting new deployments in a development and testing setting.

-Azure Monitor for containers provides more in-depth information about nodes and containers of the cluster when compared to the logical view of the Kubernetes resources available with Kubernetes resources view described in this article. Learn how to [deploy Azure Monitor for containers](../../azure-monitor/containers/container-insights-enable-arc-enabled-clusters.md?toc=/azure/azure-arc/kubernetes/toc.json) on your cluster.

-Azure Arc-enabled VMware vSphere (preview) works with VMware vSphere version 6.7.

-This article provides details on installing the Log Analytics agent on Windows computers using the following methods:

-* Manual installation using the [setup wizard](#install-agent-using-setup-wizard) or [command line](#install-agent-using-command-line).

-* [Azure Automation Desired State Configuration (DSC)](#install-agent-using-dsc-in-azure-automation).

-The installation methods described in this article are typically used for virtual machines on-premises or in other clouds. See [Installation options](./log-analytics-agent.md#installation-options) for more efficient options you can use for Azure virtual machines.

-> Installing the Log Analytics agent will typically not require you to restart the machine.

-See [Overview of Azure Monitor agents](agents-overview.md#supported-operating-systems) for a list of Windows versions supported by the Log Analytics agent.

-### SHA-2 Code Signing Support Requirement

-The Windows agent will begin to exclusively use SHA-2 signing on August 17, 2020. This change will impact customers using the Log Analytics agent on a legacy OS as part of any Azure service (Azure Monitor, Azure Automation, Azure Update Management, Azure Change Tracking, Microsoft Defender for Cloud, Microsoft Sentinel, Windows Defender ATP). The change does not require any customer action unless you are running the agent on a legacy OS version (Windows 7, Windows Server 2008 R2 and Windows Server 2008). Customers running on a legacy OS version are required to take the following actions on their machines before August 17, 2020 or their agents will stop sending data to their Log Analytics workspaces:

-1. Install the latest Service Pack for your OS. The required service pack versions are:

-2. Install the SHA-2 signing Windows updates for your OS as described in [2019 SHA-2 Code Signing Support requirement for Windows and WSUS](https://support.microsoft.com/help/4472027/2019-sha-2-code-signing-support-requirement-for-windows-and-wsus)

-3. Update to the latest version of the Windows agent (version 10.20.18029).

-4. Recommended to configure the agent to [use TLS 1.2](agent-windows.md#configure-agent-to-use-tls-12).

-See [Log Analytics agent overview](./log-analytics-agent.md#network-requirements) for the network requirements for the Windows agent.

-

-## Configure Agent to use TLS 1.2

-[TLS 1.2](/windows-server/security/tls/tls-registry-settings#tls-12) protocol ensures the security of data in transit for communication between the Windows agent and the Log Analytics service. If you're installing on an [operating system without TLS 1.2 enabled by default](../logs/data-security.md#sending-data-securely-using-tls-12), then you should configure TLS 1.2 using the steps below.

-1. Locate the following registry subkey: **HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols**

-2. Create a subkey under **Protocols** for TLS 1.2 **HKLM\System\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2**

-3. Create a **Client** subkey under the TLS 1.2 protocol version subkey you created earlier. For example, **HKLM\System\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client**.

-4. Create the following DWORD values under **HKLM\System\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client**:

-Configure .NET Framework 4.6 or later to support secure cryptography, as by default it is disabled. The [strong cryptography](/dotnet/framework/network-programming/tls#schusestrongcrypto) uses more secure network protocols like TLS 1.2, and blocks protocols that are not secure.

-1. Locate the following registry subkey: **HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\\.NETFramework\v4.0.30319**.

-2. Create the DWORD value **SchUseStrongCrypto** under this subkey with a value of **1**.

-3. Locate the following registry subkey: **HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\\.NETFramework\v4.0.30319**.

-4. Create the DWORD value **SchUseStrongCrypto** under this subkey with a value of **1**.

-5. Restart the system for the settings to take effect.

-Regardless of the installation method used, you will require the workspace ID and key for the Log Analytics workspace that the agent will connect to. Select the workspace from the **Log Analytics workspaces** menu in the Azure portal. Then select **Agents management** in the **Settings** section.

-[](media/log-analytics-agent/workspace-details.png#lightbox)

-> You can't configure the agent to report to more than one workspace during initial setup. [Add or remove a workspace](agent-manage.md#adding-or-removing-a-workspace) afer installation by updating the settings from Control Panel or PowerShell.

-The following steps install and configure the Log Analytics agent in Azure and Azure Government cloud by using the setup wizard for the agent on your computer. If you want to learn how to configure the agent to also report to a System Center Operations Manager management group, see [deploy the Operations Manager agent with the Agent Setup Wizard](/system-center/scom/manage-deploy-windows-agent-manually#to-deploy-the-operations-manager-agent-with-the-agent-setup-wizard).

-1. In your Log Analytics workspace, from the **Windows Servers** page you navigated to earlier, select the appropriate **Download Windows Agent** version to download depending on the processor architecture of the Windows operating system.

-2. Run Setup to install the agent on your computer.

-2. On the **Welcome** page, click **Next**.

-3. On the **License Terms** page, read the license and then click **I Agree**.

-4. On the **Destination Folder** page, change or keep the default installation folder and then click **Next**.

-5. On the **Agent Setup Options** page, choose to connect the agent to Azure Log Analytics and then click **Next**.

-6. On the **Azure Log Analytics** page, perform the following:

- 1. Paste the **Workspace ID** and **Workspace Key (Primary Key)** that you copied earlier. If the computer should report to a Log Analytics workspace in Azure Government cloud, select **Azure US Government** from the **Azure Cloud** drop-down list.

- 2. If the computer needs to communicate through a proxy server to the Log Analytics service, click **Advanced** and provide the URL and port number of the proxy server. If your proxy server requires authentication, type the username and password to authenticate with the proxy server and then click **Next**.

-7. Click **Next** once you have completed providing the necessary configuration settings.<br><br> <br><br>

-8. On the **Ready to Install** page, review your choices and then click **Install**.

-9. On the **Configuration completed successfully** page, click **Finish**.

-When complete, the **Microsoft Monitoring Agent** appears in **Control Panel**. To confirm it is reporting to Log Analytics, review [Verify agent connectivity to Log Analytics](#verify-agent-connectivity-to-azure-monitor).

-The downloaded file for the agent is a self-contained installation package. The setup program for the agent and supporting files are contained in the package and need to be extracted in order to properly install using the command line shown in the following examples.

->If you want to upgrade an agent, you need to use the Log Analytics scripting API. See the topic [Managing and maintaining the Log Analytics agent for Windows and Linux](agent-manage.md) for further information.

-The following table highlights the specific parameters supported by setup for the agent, including when deployed using Automation DSC.

-|ADD_OPINSIGHTS_WORKSPACE | 1 = Configure the agent to report to a workspace |

-|OPINSIGHTS_WORKSPACE_ID | Workspace ID (guid) for the workspace to add |

-|OPINSIGHTS_WORKSPACE_KEY | Workspace key used to initially authenticate with the workspace |

-|OPINSIGHTS_WORKSPACE_AZURE_CLOUD_TYPE | Specify the cloud environment where the workspace is located <br> 0 = Azure commercial cloud (default) <br> 1 = Azure Government |

-|OPINSIGHTS_PROXY_USERNAME | Username to access an authenticated proxy |

-|OPINSIGHTS_PROXY_PASSWORD | Password to access an authenticated proxy |

-1. To extract the agent installation files, from an elevated command prompt run `MMASetup-<platform>.exe /c` and it will prompt you for the path to extract files to. Alternatively, you can specify the path by passing the arguments `MMASetup-<platform>.exe /c /t:<Full Path>`.

-2. To silently install the agent and configure it to report to a workspace in Azure commercial cloud, from the folder you extracted the setup files to type:

-

- or to configure the agent to report to Azure US Government cloud, type:

- >The string values for the parameters *OPINSIGHTS_WORKSPACE_ID* and *OPINSIGHTS_WORKSPACE_KEY* need to be encapsulated in double-quotes to instruct Windows Installer to interprit as valid options for the package.

-You can use the following script example to install the agent using Azure Automation DSC. If you do not have an Automation account, see [Get started with Azure Automation](../../automation/index.yml) to understand requirements and steps for creating an Automation account required before using Automation DSC. If you are not familiar with Automation DSC, review [Getting started with Automation DSC](../../automation/automation-dsc-getting-started.md).

->This procedure and script example does not support upgrading the agent already deployed to a Windows computer.

-The 32-bit and 64-bit versions of the agent package have different product codes and new versions released also have a unique value. The product code is a GUID that is the principal identification of an application or product and is represented by the Windows Installer **ProductCode** property. The `ProductId` value in the **MMAgent.ps1** script has to match the product code from the 32-bit or 64-bit agent installer package.

-To retrieve the product code from the agent install package directly, you can use Orca.exe from the [Windows SDK Components for Windows Installer Developers](/windows/win32/msi/platform-sdk-components-for-windows-installer-developers) that is a component of the Windows Software Development Kit or using PowerShell following an [example script](https://www.scconfigmgr.com/2014/08/22/how-to-get-msi-file-information-with-powershell/) written by a Microsoft Valuable Professional (MVP). For either approach, you first need to extract the **MOMagent.msi** file from the MMASetup installation package. This is shown earlier in the first step under the section [Install the agent using the command line](#install-agent-using-command-line).

-1. Import the xPSDesiredStateConfiguration DSC Module from [https://www.powershellgallery.com/packages/xPSDesiredStateConfiguration](https://www.powershellgallery.com/packages/xPSDesiredStateConfiguration) into Azure Automation.

-2. Create Azure Automation variable assets for *OPSINSIGHTS_WS_ID* and *OPSINSIGHTS_WS_KEY*. Set *OPSINSIGHTS_WS_ID* to your Log Analytics workspace ID and set *OPSINSIGHTS_WS_KEY* to the primary key of your workspace.

-3. Copy the script and save it as MMAgent.ps1.

-```powershell

-Configuration MMAgent

-{

- $OIPackageLocalPath = "C:\Deploy\MMASetup-AMD64.exe"

- $OPSINSIGHTS_WS_ID = Get-AutomationVariable -Name "OPSINSIGHTS_WS_ID"

- $OPSINSIGHTS_WS_KEY = Get-AutomationVariable -Name "OPSINSIGHTS_WS_KEY"

- Import-DscResource -ModuleName xPSDesiredStateConfiguration

- Import-DscResource -ModuleName PSDesiredStateConfiguration

- Node OMSnode {

- Service OIService

- {

- Name = "HealthService"

- State = "Running"

- DependsOn = "[Package]OI"

- }

- xRemoteFile OIPackage {

- Uri = "https://go.microsoft.com/fwlink/?LinkId=828603"

- DestinationPath = $OIPackageLocalPath

- }

- Package OI {

- Ensure = "Present"

- Path = $OIPackageLocalPath

- Name = "Microsoft Monitoring Agent"

- ProductId = "8A7F2C51-4C7D-4BFD-9014-91D11F24AAE2"

- Arguments = '/C:"setup.exe /qn NOAPM=1 ADD_OPINSIGHTS_WORKSPACE=1 OPINSIGHTS_WORKSPACE_ID=' + $OPSINSIGHTS_WS_ID + ' OPINSIGHTS_WORKSPACE_KEY=' + $OPSINSIGHTS_WS_KEY + ' AcceptEndUserLicenseAgreement=1"'

- DependsOn = "[xRemoteFile]OIPackage"

-}

-```

-4. Update the `ProductId` value in the script with the product code extracted from the latest version of the agent install package using the methods recommended earlier.

-5. [Import the MMAgent.ps1 configuration script](../../automation/automation-dsc-getting-started.md#import-a-configuration-into-azure-automation) into your Automation account.

-6. [Assign a Windows computer or node](../../automation/automation-dsc-getting-started.md#enable-an-azure-resource-manager-vm-for-management-with-state-configuration) to the configuration. Within 15 minutes, the node checks its configuration and the agent is pushed to the node.

-Once installation of the agent is complete, verifying it is successfully connected and reporting can be accomplished in two ways.

-From the computer in **Control Panel**, find the item **Microsoft Monitoring Agent**. Select it and on the **Azure Log Analytics** tab, the agent should display a message stating: **The Microsoft Monitoring Agent has successfully connected to the Microsoft Operations Management Suite service.**<br><br> 

-You can also perform a simple log query in the Azure portal.

-1. Select **Logs** in the menu.

-1. On the **Logs** pane, in the query field type:

-In the search results returned, you should see heartbeat records for the computer indicating it is connected and reporting to the service.

-The default cache size is 50 MB but can be configured between a minimum of 5 MB and maximum of 1.5 GB. It's stored in the registry key *HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\HealthService\Parameters\Persistence Cache Maximum*. The value represents the number of pages, with 8 KB per page.

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

-Virtual machines and other compute resources require an agent to collect monitoring data required to measure the performance and availability of their guest operating system and workloads. There are many legacy agents that exist today for this purpose, that will all be eventually replaced by the new consolidated [Azure Monitor agent](./azure-monitor-agent-overview.md). This article describes both the legacy agents as well as the new Azure Monitor agent.

-The general recommendation is to use the Azure Monitor agent if you are not bound by [these limitations](./azure-monitor-agent-overview.md#current-limitations), as it consolidates the features of all the legacy agents listed below and provides these [additional benefits](#azure-monitor-agent).

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

-The following tables provide a quick comparison of the telemetry agents for Windows and Linux. Further detail on each is provided in the section below.

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

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

-| **Data sent to** | Azure Monitor Logs<br>Azure Monitor Metrics¹ | Azure Storage<br>Azure Monitor Metrics<br>Event Hub | Azure Monitor Logs | Azure Monitor Logs<br>(through Log Analytics agent) |

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

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

-| **Data collected** | Syslog<br>Performance<br>File based logs (preview)<br> | Syslog<br>Performance | Performance | Syslog<br>Performance| Process dependencies<br>Network connection metrics |

-| **Data sent to** | Azure Monitor Logs<br>Azure Monitor Metrics¹ | Azure Storage<br>Event Hub | Azure Monitor Metrics | Azure Monitor Logs | Azure Monitor Logs<br>(through Log Analytics agent) |

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

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

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

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

- - Use XPath queries to filter Windows events that get collected. This helps further reduce ingestion and storage costs.

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

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

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

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

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

-Limitations of the Log Analytics agent include:

-## Azure diagnostics extension

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

-Use Azure diagnostic extension if you need to:

-Limitations of Azure diagnostics extension include:

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

-Use Telegraf agent if you need to:

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

-The Dependency agent collects discovered data about processes running on the machine and external process dependencies.

-Consider the following when using the Dependency agent:

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

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

-¹ Running the OS on server hardware, i.e. machines that are always connected, always turned on, and not running other workloads (PC, office, browser, etc.)

-> For Dependency Agent, please additionally check for supported kernel versions. See "Dependency agent Linux kernel support" table below for details

-| Operating system | Azure Monitor agent ¹ | Log Analytics agent ¹ | Dependency agent | Diagnostics extension ²|

-| CentOS Linux 8 | X ³ | X | X | |

-| Debian 9 | X | X | x | X |

-| Oracle Linux 8 | X ³ | X | | |

-| Red Hat Enterprise Linux Server 8, 8.1, 8.2, 8.3, 8.4 | X ³ | X | X | |

-| SUSE Linux Enterprise Server 15.2 | X ³ | | | |

-| SUSE Linux Enterprise Server 15.1 | X ³ | X | | |

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

-¹ Requires Python (2 or 3) to be installed on the machine.

-³ Known issue collecting Syslog events in versions prior to 1.9.0.

-⁴ Not all kernel versions are supported, check supported kernel versions below.

-Since the Dependency agent works at the kernel level, support is also dependent on the kernel version. As of Dependency agent version 9.10.* the agent supports * kernels. The following table lists the major and minor Linux OS release and supported kernel versions for the Dependency agent.

-Get more details on each of the agents at the following:

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

-Here's an **introductory video** explaining all about this new agent, including a quick demo of how to set things up using the Azure portal: [ITOps Talk: Azure Monitor Agent](https://www.youtube.com/watch?v=f8bIrFU8tCs)

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

-**Currently**, the Azure Monitor agent consolidates features from the Telegraf agent and Log Analytics agent, with [a few limitations](#current-limitations).

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

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

- - Use XPath queries to filter Windows events that get collected. This helps further reduce ingestion and storage costs.

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

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

-## Should I switch to the Azure Monitor agent?

-To start transitioning your VMs off the current agents to the new agent, consider the following factors:

- That said, most new capabilities in Azure Monitor will be made available only with the Azure Monitor agent. Review whether the Azure Monitor agent has the features you require and if there are some features that you can temporarily do without to get other important features in the new agent.

- If the Azure Monitor agent has all the core capabilities you require, start transitioning to it. If there are critical features that you require, continue with the current agent until the Azure Monitor agent reaches parity.

- Azure Monitor's Log Analytics agent is retiring on 31 August 2024. The current agents will be supported until the retirement date.

-## Coexistence with other agents

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

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

-| Resource type | Installation method | Additional information |

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

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

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

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

-Azure Monitor agent is available in all public regions and Azure Government clouds. It is not yet supported in Air-gapped clouds. See here for [product availability by region](https://azure.microsoft.com/global-infrastructure/services/?products=monitor&rar=true&regions=all).

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

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

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

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

-| [Update Management](../../automation/update-management/overview.md) | Use Update Management v2 (Private Preview) that doesn't require an agent. | [Sign-up link](https://www.yammer.com/azureadvisors/threads/1064001355087872) |

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

-The Azure Monitor agent supports Azure service tags (both *AzureMonitor* and *AzureResourceManager* tags are required). It supports connecting via **direct proxies, Log Analytics gateway, and private links** as described below.

-| Azure Government |global.handler.control.monitor.azure.us |Access control service|Port 443 |Outbound|Yes |

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

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

-| Azure China |global.handler.control.monitor.azure.cn |Access control service|Port 443 |Outbound|Yes |

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

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

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

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

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

- 

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

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

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

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

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

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

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

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

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

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

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

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

-description: Azure Monitor can collect events from text files on both Windows and Linux computers. This article describes how to define a new custom log and details of the records they create in Azure Monitor.

-# Collect text logs with Log Analytics agent in Azure Monitor

-The Custom Logs data source for the Log Analytics agent in Azure Monitor allows you to collect events from text files on both Windows and Linux computers. Many applications log information to text files instead of standard logging services such as Windows Event log or Syslog. Once collected, you can either parse the data into individual fields in your queries or extract the data during collection to individual fields.

-

-The log files to be collected must match the following criteria.

-> If there are duplicate entries in the log file, Azure Monitor will collect them. However, the query results will be inconsistent where the filter results show more events than the result count. It will be important that you validate the log to determine if the application that creates it is causing this behavior and address it if possible before creating the custom log collection definition.

->

->[!NOTE]

-> A Log Analytics workspace supports the following limits:

->

-> * Only 500 custom logs can be created.

-> * A table only supports up to 500 columns.

-> * The maximum number of characters for the column name is 500.

->

-## Defining a custom log

-Use the following procedure to define a custom log file. Scroll to the end of this article for a walkthrough of a sample of adding a custom log.

-### Step 1. Open the Custom Log Wizard

-The Custom Log Wizard runs in the Azure portal and allows you to define a new custom log to collect.

-2. Click on **Custom logs**.

-3. By default, all configuration changes are automatically pushed to all agents. For Linux agents, a configuration file is sent to the Fluentd data collector.

-4. Click **Add+** to open the Custom Log Wizard.

-### Step 2. Upload and parse a sample log

-You start by uploading a sample of the custom log. The wizard will parse and display the entries in this file for you to validate. Azure Monitor will use the delimiter that you specify to identify each record.

-**New Line** is the default delimiter and is used for log files that have a single entry per line. If the line starts with a date and time in one of the available formats, then you can specify a **Timestamp** delimiter which supports entries that span more than one line.

-If a timestamp delimiter is used, then the TimeGenerated property of each record stored in Azure Monitor will be populated with the date/time specified for that entry in the log file. If a new line delimiter is used, then TimeGenerated is populated with date and time that Azure Monitor collected the entry.

-1. Click **Browse** and browse to a sample file. Note that this may button may be labeled **Choose File** in some browsers.

-2. Click **Next**.

-3. The Custom Log Wizard will upload the file and list the records that it identifies.

-4. Change the delimiter that is used to identify a new record and select the delimiter that best identifies the records in your log file.

-5. Click **Next**.

-### Step 3. Add log collection paths

-You must define one or more paths on the agent where it can locate the custom log. You can either provide a specific path and name for the log file, or you can specify a path with a wildcard for the name. This supports applications that create a new file each day or when one file reaches a certain size. You can also provide multiple paths for a single log file.

-For example, an application might create a log file each day with the date included in the name as in log20100316.txt. A pattern for such a log might be *log\*.txt* which would apply to any log file following the applicationΓÇÖs naming scheme.

-| All files in *C:\Logs* with .txt extension on Windows agent |C:\Logs\\\*.txt |

-| All files in *C:\Logs* with a name starting with log and a .txt extension on Windows agent |C:\Logs\log\*.txt |

-| All files in */var/log/audit* with .txt extension on Linux agent |/var/log/audit/*.txt |

-| All files in */var/log/audit* with a name starting with log and a .txt extension on Linux agent |/var/log/audit/log\*.txt |

-1. Select Windows or Linux to specify which path format you are adding.

-2. Type in the path and click the **+** button.

-3. Repeat the process for any additional paths.

-### Step 4. Provide a name and description for the log

-The name that you specify will be used for the log type as described above. It will always end with _CL to distinguish it as a custom log.

-1. Type in a name for the log. The **\_CL** suffix is automatically provided.

-2. Add an optional **Description**.

-3. Click **Next** to save the custom log definition.

-### Step 5. Validate that the custom logs are being collected

-It may take up to an hour for the initial data from a new custom log to appear in Azure Monitor. It will start collecting entries from the logs found in the path you specified from the point that you defined the custom log. It will not retain the entries that you uploaded during the custom log creation, but it will collect already existing entries in the log files that it locates.

-Once Azure Monitor starts collecting from the custom log, its records will be available with a log query. Use the name that you gave the custom log as the **Type** in your query.

-> If the RawData property is missing from the query, you may need to close and reopen your browser.

-### Step 6. Parse the custom log entries

-The entire log entry will be stored in a single property called **RawData**. You will most likely want to separate the different pieces of information in each entry into individual properties for each record. Refer to [Parse text data in Azure Monitor](../logs/parse-text.md) for options on parsing **RawData** into multiple properties.

-## Removing a custom log

-2. Click **Remove** next to the custom log to remove.

-Azure Monitor will collect new entries from each custom log approximately every 5 minutes. The agent will record its place in each log file that it collects from. If the agent goes offline for a period of time, then Azure Monitor will collect entries from where it last left off, even if those entries were created while the agent was offline.

-The entire contents of the log entry are written to a single property called **RawData**. See [Parse text data in Azure Monitor](../logs/parse-text.md) for methods to parse each imported log entry into multiple properties.

-| TimeGenerated |Date and time that the record was collected by Azure Monitor. If the log uses a time-based delimiter then this is the time collected from the entry. |

-| RawData |Full text of the collected entry. You will most likely want to [parse this data into individual properties](../logs/parse-text.md). |

-| ManagementGroupName |Name of the management group for System Center Operations Manage agents. For other agents, this is AOI-\<workspace ID\> |

-The following section walks through an example of creating a custom log. The sample log being collected has a single entry on each line starting with a date and time and then comma-delimited fields for code, status, and message. Several sample entries are shown below.

-We provide one of the log files and can see the events that it will be collecting. In this case New Line is a sufficient delimiter. If a single entry in the log could span multiple lines though, then a timestamp delimiter would need to be used.

-

-The log files will be located in *C:\MyApp\Logs*. A new file will be created each day with a name that includes the date in the pattern *appYYYYMMDD.log*. A sufficient pattern for this log would be *C:\MyApp\Logs\\\*.log*.

-

-

-We use a simple query of *MyApp_CL* to return all records from the collected log.

-

-While custom logs are useful if your data fits the criteria listed above, there are cases such as the following where you need another strategy:

-description: This topic helps you understand how to collect data and monitor computers hosted in Azure, on-premises, or other cloud environment with Log Analytics.

-The Azure Log Analytics agent collects telemetry from Windows and Linux virtual machines in any cloud, on-premises machines, and those monitored by [System Center Operations Manager](/system-center/scom/) and sends collected data to your Log Analytics workspace in Azure Monitor. The Log Analytics agent also supports insights and other services in Azure Monitor such as [VM insights](../vm/vminsights-enable-overview.md), [Microsoft Defender for Cloud](../../security-center/index.yml), and [Azure Automation](../../automation/automation-intro.md). This article provides a detailed overview of the agent, system and network requirements, and deployment methods.

->The Log Analytics agent is on a **deprecation path** and won't be supported after **August 31, 2024**. If you use the Log Analytics agent to ingest data to Azure Monitor, make sure to [migrate to the new Azure Monitor agent](./azure-monitor-agent-migration.md) prior to that date.

-> [!NOTE]

-> You may also see the Log Analytics agent referred to as the Microsoft Monitoring Agent (MMA).

-See [Overview of Azure Monitor agents](agents-overview.md) for a comparison between the Log Analytics and other agents in Azure Monitor.

- See [Supported operating systems](../agents/agents-overview.md#supported-operating-systems) for a list of the Windows and Linux operating system versions that are supported by the Log Analytics agent.

-> It is not supported to clone a machine with the Log Analytics Agent already configured. If the agent has already been associated with a workspace this will not work for 'golden images'.

-The following table lists the types of data you can configure a Log Analytics workspace to collect from all connected agents. See [What is monitored by Azure Monitor?](../monitor-reference.md) for a list of insights, solutions, and other solutions that use the Log Analytics agent to collect other kinds of data.

-| [Windows Event logs](../agents/data-sources-windows-events.md) | Information sent to the Windows event logging system. |

-| [Syslog](../agents/data-sources-syslog.md) | Information sent to the Linux event logging system. |

-| [Performance](../agents/data-sources-performance-counters.md) | Numerical values measuring performance of different aspects of operating system and workloads. |

-| [IIS logs](../agents/data-sources-iis-logs.md) | Usage information for IIS web sites running on the guest operating system. |

-| [Custom logs](../agents/data-sources-custom-logs.md) | Events from text files on both Windows and Linux computers. |

-The agent for Linux and Windows isn't only for connecting to Azure Monitor. Other services such as Microsoft Defender for Cloud and Microsoft Sentinel rely on the agent and its connected Log Analytics workspace. The agent also supports Azure Automation to host the Hybrid Runbook worker role and other services such as [Change Tracking](../../automation/change-tracking/overview.md), [Update Management](../../automation/update-management/overview.md), and [Microsoft Defender for Cloud](../../security-center/security-center-introduction.md). For more information about the Hybrid Runbook Worker role, see [Azure Automation Hybrid Runbook Worker](../../automation/automation-hybrid-runbook-worker.md).

-See [Configure agent to report to an Operations Manager management group](../agents/agent-manage.md#configure-agent-to-report-to-an-operations-manager-management-group) for details on connecting an agent to an Operations Manager management group.

-* Windows agents can connect to up to four workspaces, even if they are connected to a System Center Operations Manager management group.

-* The Linux agent does not support multi-homing and can only connect to a single workspace or management group.

-* The Windows and Linux agents support the [FIPS 140 standard](/windows/security/threat-protection/fips-140-validation), but [other types of hardening may not be supported](../agents/agent-linux.md#supported-linux-hardening).

-To ensure the security of data in transit to Azure Monitor logs, we strongly encourage you to configure the agent to use at least Transport Layer Security (TLS) 1.2. Older versions of TLS/Secure Sockets Layer (SSL) have been found to be vulnerable and while they still currently work to allow backwards compatibility, they are **not recommended**. For additional information, review [Sending data securely using TLS 1.2](../logs/data-security.md#sending-data-securely-using-tls-12).

-The agent for Linux and Windows communicates outbound to the Azure Monitor service over TCP port 443. If the machine connects through a firewall or proxy server to communicate over the Internet, review requirements below to understand the network configuration required. If your IT security policies do not allow computers on the network to connect to the Internet, you can set up a [Log Analytics gateway](gateway.md) and then configure the agent to connect through the gateway to Azure Monitor. The agent can then receive configuration information and send data collected.

-

-For firewall information required for Azure Government, see [Azure Government management](../../azure-government/compare-azure-government-global-azure.md#azure-monitor).

-The Windows and Linux agent supports communicating either through a proxy server or Log Analytics gateway to Azure Monitor using the HTTPS protocol. Both anonymous and basic authentication (username/password) are supported. For the Windows agent connected directly to the service, the proxy configuration is specified during installation or [after deployment](../agents/agent-manage.md#update-proxy-settings) from Control Panel or with PowerShell. Log Analytics Agent (MMA) does not use the system proxy settings. Hence, user has to pass proxy setting while installing MMA and these settings will be stored under MMA configuration(registry) on VM.

-> If you use special characters such as "\@" in your password, you receive a proxy connection error because value is parsed incorrectly. To work around this issue, encode the password in the URL using a tool such as [URLDecode](https://www.urldecoder.org/).

-* Learn about [log queries](../logs/log-query-overview.md) to analyze the data collected from data sources and solutions.

-Post questions to the [answers forum](/answers/topics/24223/azure-monitor.html).

-description: Provides instructions to quickly set up a mobile app for monitoring with Azure Monitor Application Insights and App Center

-# Start analyzing your mobile app with App Center and Application Insights

-description: Learn how to use Azure PowerShell in Azure Monitor's Change Analysis to determine changes to resources in your subscription

-ms.contributor: cawa

-ms.reviwer: cawa

-# Azure PowerShell for Change Analysis in Azure Monitor (preview)

-This article describes how you can use Change Analysis with the

-[Az.ChangeAnalysis PowerShell module](/powershell/module/az.changeanalysis/) to determine changes

-made to resources in your Azure subscription.

-> [!CAUTION]

-> Change analysis is currently in public preview. This preview version is provided without a

-> service level agreement. It's not recommended for production workloads. Some features might not be

-> supported or might have constrained capabilities. For more information, see

-> [Supplemental Terms of Use for Microsoft Azure Previews](https://azure.microsoft.com/support/legal/preview-supplemental-terms/).

-## Prerequisites

-If you don't have an Azure subscription, create a [free](https://azure.microsoft.com/free/) account

-before you begin.

-> [!IMPORTANT]

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

-> the `Install-Module` cmdlet.

-```azurepowershell-interactive

-Install-Module -Name Az.ChangeAnalysis -Scope CurrentUser -Repository PSGallery

-```

-If you have multiple Azure subscriptions, choose the appropriate subscription. Select a specific

-subscription using the [Set-AzContext](/powershell/module/az.accounts/set-azcontext) cmdlet.

-```azurepowershell-interactive

-Set-AzContext -SubscriptionId 00000000-0000-0000-0000-000000000000

-```

-## View Azure subscription changes

-To view changes made to all resources in your Azure subscription, you use the `Get-AzChangeAnalysis`

-command. You specify the time range for events in UTC date format using the `StartTime` and

-`EndTime` parameters.

-```azurepowershell-interactive

-$startDate = Get-Date -Date '2022-04-07T12:09:03.141Z' -AsUTC

-$endDate = Get-Date -Date '2022-04-10T12:09:03.141Z' -AsUTC

-Get-AzChangeAnalysis -StartTime $startDate -EndTime $endDate

-```

-## View Azure resource group changes

-To view changes made to all resources in a resource group, you use the `Get-AzChangeAnalysis`

-command and specify the `ResourceGroupName` parameter. The following example returns a list of

-changes made within the last 12 hours. Specify `StartTime` and `EndTime` in UTC date formats.

-```azurepowershell-interactive

-$startDate = (Get-Date -AsUTC).AddHours(-12)

-$endDate = Get-Date -AsUTC

-Get-AzChangeAnalysis -ResourceGroupName <myResourceGroup> -StartTime $startDate -EndTime $endDate

-```

-## View Azure resource changes

-To view changes made to a resource, you use the `Get-AzChangeAnalysis` command and specify the

-`ResourceId` parameter. The following example uses PowerShell splatting to return a list of the

-changes made within the last day. Specify `StartTime` and `EndTime` in UTC date formats.

-```azurepowershell-interactive

-$Params = @{

- StartTime = (Get-Date -AsUTC).AddDays(-1)

- EndTime = Get-Date -AsUTC

- ResourceId = '/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/<myResourceGroup>/providers/Microsoft.Network/networkInterfaces/<myNetworkInterface>'

-}

-Get-AzChangeAnalysis @Params

-```

-> [!NOTE]

-> A resource not found message is returned if the specified resource has been removed or deleted.

-> Use Change Analysis at the resource group or subscription level to determine changes for resources

-> that have been removed or deleted.

-## View detailed information

-You can view more properties for any of the commands shown in this article by piping the results to

-`Select-Object -Property *`.

-```azurepowershell-interactive

-$startDate = (Get-Date -AsUTC).AddHours(-12)

-$endDate = Get-Date -AsUTC

-Get-AzChangeAnalysis -ResourceGroupName <myResourceGroup> -StartTime $startDate -EndTime $endDate |

- Select-Object -Property *

-```

-The `PropertyChange` property is a complex object that has addition nested properties. Pipe the

-`PropertyChange` property to `Select-Object -Property *` to see the nested properties.

-```azurepowershell-interactive

-$startDate = (Get-Date -AsUTC).AddHours(-12)

-$endDate = Get-Date -AsUTC

-(Get-AzChangeAnalysis -ResourceGroupName <myResourceGroup> -StartTime $startDate -EndTime $endDate |

- Select-Object -First 1).PropertyChange | Select-object -Property *

-```

-## Next steps

-description: This article presents troubleshooting steps and information to help developers enable and use Application Insights Profiler.

-# Troubleshoot problems enabling or viewing Application Insights Profiler

-## <a id="troubleshooting"></a>General troubleshooting

-### Make sure you're using the appropriate Profiler Endpoint

-Currently the only regions that require endpoint modifications are [Azure Government](../../azure-government/compare-azure-government-global-azure.md#application-insights) and [Azure China](/azure/china/resources-developer-guide).

-### Profiles are uploaded only if there are requests to your application while Profiler is running

-Azure Application Insights Profiler collects data for two minutes each hour. It can also collect data when you select the **Profile Now** button in the **Configure Application Insights Profiler** pane.

-> [!NOTE]

-> The profiling data is uploaded only when it can be attached to a request that happened while Profiler was running.

-Profiler writes trace messages and custom events to your Application Insights resource. You can use these events to see how Profiler is running:

-1. Search for trace messages and custom events sent by Profiler to your Application Insights resource. You can use this search string to find the relevant data:

- ```

- stopprofiler OR startprofiler OR upload OR ServiceProfilerSample

- ```

- The following image displays two examples of searches from two AI resources:

-

- * At the left, the application isn't receiving requests while Profiler is running. The message explains that the upload was canceled because of no activity.

- * At the right, Profiler started and sent custom events when it detected requests that happened while Profiler was running. If the `ServiceProfilerSample` custom event is displayed, it means that a profile was captured and its available in the **Application Insights Performance** pane.

- If no records are displayed, Profiler isn't running. To troubleshoot, see the troubleshooting sections for your specific app type later in this article.

- ![Search Profiler telemetry][profiler-search-telemetry]

-### Other things to check

-* Make sure that your app is running on .NET Framework 4.6.

-* If your web app is an ASP.NET Core application, it must be running at least ASP.NET Core [LTS](https://dotnet.microsoft.com/platform/support/policy/dotnet-core).

-* If the data you're trying to view is older than a couple of weeks, try limiting your time filter and try again. Traces are deleted after seven days.

-* Make sure that proxies or a firewall haven't blocked access to https://gateway.azureserviceprofiler.net.

-* Profiler isn't supported on free or shared app service plans. If you're using one of those plans, try scaling up to one of the basic plans and Profiler should start working.

-### <a id="double-counting"></a>Double counting in parallel threads

-In some cases, the total time metric in the stack viewer is more than the duration of the request.

-This situation might occur when two or more parallel threads are associated with a request. In that case, the total thread time is more than the elapsed time.

-One thread might be waiting on the other to be completed. The viewer tries to detect this situation and omits the uninteresting wait. In doing so, it errs on the side of displaying too much information rather than omit what might be critical information.

-When you see parallel threads in your traces, determine which threads are waiting so that you can identify the hot path for the request.

-Usually, the thread that quickly goes into a wait state is simply waiting on the other threads. Concentrate on the other threads, and ignore the time in the waiting threads.

-### Error report in the profile viewer

-Submit a support ticket in the portal. Be sure to include the correlation ID from the error message.

-## Troubleshoot Profiler on Azure App Service

-For Profiler to work properly:

-* Your web app service plan must be Basic tier or higher.

-* Your web app must have Application Insights enabled.

-* Your web app must have the following app settings:

- |App Setting | Value |

- ||-|

- |APPINSIGHTS_INSTRUMENTATIONKEY | iKey for your Application Insights resource |

- |APPINSIGHTS_PROFILERFEATURE_VERSION | 1.0.0 |

- |DiagnosticServices_EXTENSION_VERSION | ~3 |

-* The **ApplicationInsightsProfiler3** webjob must be running. To check the webjob:

- 1. Go to [Kudu](/archive/blogs/cdndevs/the-kudu-debug-console-azure-websites-best-kept-secret).

- 1. In the **Tools** menu, select **WebJobs Dashboard**.

- ![Screenshot shows the WebJobs pane, which displays the name, status, and last run time of jobs.][profiler-webjob]

-

- ![Screenshot shows the Continuous WebJob Details pane.][profiler-webjob-log]

-If Profiler isn't working for you, you can download the log and send it to our team for assistance, serviceprofilerhelp@microsoft.com.

-### Check the Diagnostic Services site extension' Status Page

-If Profiler was enabled through the [Application Insights pane](profiler.md) in the portal, it was enabled by the Diagnostic Services site extension.

-> [!NOTE]

-> Codeless installation of Application Insights Profiler follows the .NET Core support policy.

-> For more information about supported runtimes, see [.NET Core Support Policy](https://dotnet.microsoft.com/platform/support/policy/dotnet-core).

-You can check the Status Page of this extension by going to the following url:

-> The domain of the Status Page link will vary depending on the cloud.

-This domain will be the same as the Kudu management site for App Service.

-This Status Page shows the installation state of the Profiler and Snapshot Collector agents. If there was an unexpected error, it will be displayed and show how to fix it.

-You can use the Kudu management site for App Service to get the base url of this Status Page:

-2. Select **Advanced Tools**, or search for **Kudu**.

-4. Once you are on the Kudu management site, in the URL, **append the following `/DiagnosticServices` and press enter**.

- It will end like this: `https://<kudu-url>/DiagnosticServices`

-It will display a Status Page similar like the below:

-

-### Manual installation

-When you configure Profiler, updates are made to the web app's settings. If your environment requires it, you can apply the updates manually. An example might be that your application is running in a Web Apps environment for Power Apps. To apply updates manually:

-1. In the **Web App Control** pane, open **Settings**.

-1. Set **.NET Framework version** to **v4.6**.

-1. Set **Always On** to **On**.

-1. Create these app settings:

- |App Setting | Value |

- ||-|

- |APPINSIGHTS_INSTRUMENTATIONKEY | iKey for your Application Insights resource |

- |APPINSIGHTS_PROFILERFEATURE_VERSION | 1.0.0 |

- |DiagnosticServices_EXTENSION_VERSION | ~3 |

-### Too many active profiling sessions

-You can enable Profiler on a maximum of four Web Apps that are running in the same service plan. If you've more than four, Profiler might throw a *Microsoft.ServiceProfiler.Exceptions.TooManyETWSessionException*. To solve it, move some web apps to a different service plan.

-### Deployment error: Directory Not Empty 'D:\\home\\site\\wwwroot\\App_Data\\jobs'

-This error occurs if you run Web Deploy from scripts or from the Azure Pipelines. The solution is to add the following deployment parameters to the Web Deploy task:

-These parameters delete the folder that's used by Application Insights Profiler and unblock the redeploy process. They don't affect the Profiler instance that's currently running.

-### How do I determine whether Application Insights Profiler is running?

-## Troubleshoot VMs and Cloud Services

->**The bug in the profiler that ships in the WAD for Cloud Services has been fixed.** The latest version of WAD (1.12.2.0) for Cloud Services works with all recent versions of the App Insights SDK. Cloud Service hosts will upgrade WAD automatically, but it isn't immediate. To force an upgrade, you can redeploy your service or reboot the node.

-To see whether Profiler is configured correctly by Azure Diagnostics, follow the below steps:

-1. Second, make sure that Azure Diagnostics passes the proper iKey on the Profiler command line.

-1. Third, check the Profiler log file to see whether Profiler ran but returned an error.

-1. Sign in to the virtual machine (VM), and then open the log file at this location. The plugin version may be newer on your machine.

-1. In the file, you can search for the string **WadCfg** to find the settings that were passed to the VM to configure Azure Diagnostics. You can check to see whether the iKey used by the Profiler sink is correct.

-1. Check the command line that's used to start Profiler. The arguments that are used to launch Profiler are in the following file. (The drive could be c: or d: and the directory may be hidden.)

-1. Using the path found in the preceding *config.json* file, check the Profiler log file, called **BootstrapN.log**. It displays the debug information that indicates the settings that Profiler is using. It also displays status and error messages from Profiler.

- For VMs, the file is here:

- If Profiler is running while your application is receiving requests, the following message is displayed: *Activity detected from iKey*.

- When the trace is being uploaded, the following message is displayed: *Start to upload trace*.

-## Edit network proxy or firewall rules

-[profiler-search-telemetry]:./media/profiler-troubleshooting/Profiler-Search-Telemetry.png

-[profiler-webjob]:./media/profiler-troubleshooting/profiler-web-job.png

-[profiler-webjob-log]:./media/profiler-troubleshooting/profiler-web-job-log.png

-# Authenticate and authorize an application with Azure Active Directory to access Azure Relay entities (Preview)

-# Authenticate a managed identity with Azure Active Directory to access Azure Relay resources (preview)

-## Azure Active Directory (Preview)

-```

-In Azure VMware Solution, vCenter Server has a built-in local user called *cloudadmin* assigned to the CloudAdmin role. The CloudAdmin role has vCenter Server [privileges](concepts-identity.md#view-the-vcenter-privileges) that differ from other VMware cloud solutions and on-premises deployments. The Run command feature lets you perform operations that would normally require elevated privileges through a collection of PowerShell cmdlets.

-3. In **Backup Now**, choose the type of backup you want to perform. Then select **OK**. This backup will be retained according to the policy associated with this backup item.

-4. Monitor the portal notifications. To monitor the job progress, go to **Backup center** -> **Backup Jobs** and filter for jobs with status **In Progress**. Depending on the size of your database, creating the initial backup may take a while.

-By default, the retention of on-demand backups is 45 days.

-While the section above details how to configure a scheduled backup, this section talks about triggering an on-demand backup. To do this, we use the [az backup protection backup-now](/cli/azure/backup/protection#az-backup-protection-backup-now) cmdlet.

-> The retention policy of an on-demand backup is determined by the underlying retention policy for the database.

-| Chinese (Taiwanese Mandarin) | `zh-TW` |

-> At this time, the custom lexicon isn't supported for five voices: et-EE-AnuNeural, ga-IE-OrlaNeural, lt-LT-OnaNeural, lv-LV-EveritaNeural, and mt-MT-GarceNeural.

-* [Metrics Advisor (preview)]()

-* [Metrics Advisor (preview)](https://stackoverflow.com/search?q=azure+metrics+advisor)

-* [Metrics Advisor (preview)](https://feedback.azure.com/d365community/forum/09041fae-0b25-ec11-b6e6-000d3a4f0858?c=6c8853b4-0b25-ec11-b6e6-000d3a4f0858)

-You can use the Azure Communication Services Identity SDK to exchange Azure Active Directory (Azure AD) access tokens of Teams users for Communication Identity access tokens. The diagrams in the next sections demonstrate multitenant use cases, where fictional company Fabrikam is the customer of fictional company Contoso.

-Voice, video, and screen-sharing capabilities are provided via Azure Communication Services Calling SDKs. The following diagram shows an overview of the process you'll follow as you integrate your calling experiences with Azure Communication Services support Teams identities.

-Learn about [Teams interoperability](./teams-interop.md).

-## Bring your own identity

-Developers can use Communication Services Calling SDK with Teams identity to build custom applications for Teams users. Custom applications can enable specialized workflows for Teams users such as management of incoming and outgoing PSTN calls or bring Teams calling experience into devices that are not supported with the standard Teams client. Teams identities are authenticated by Azure Active Directory, and all attributes and details about the user are bound to their Azure Active Directory account.

-All usage of Azure Communication Service APIs and SDKs increments [Azure Communication Service billing meters](https://azure.microsoft.com/pricing/details/communication-services/). Interactions with Microsoft Teams, such as joining a meeting or initiating a phone call using a Teams allocated number, will increment these meters but there is no additional fee for the Teams interoperability capability itself, and there is no pricing distinction between the BYOI and Microsoft 365 authentication options.

-> [Enable Teams access tokens](../quickstarts/manage-teams-identity.md)

-description: In this quickstart, you'll learn how to add voice & video-calling capabilities to your custom Teams app using Azure Communication Services.

-# QuickStart: Add 1:1 video calling to your customized Teams application

-You can list the manifests for a repository with the Azure CLI command [az acr repository show-manifests][az-acr-repository-show-manifests]:

-az acr repository show-manifests --name <acrName> --repository <repositoryName>

-az acr repository show-manifests --name myregistry --repository acr-helloworld

-[az-acr-repository-show-manifests]: /cli/azure/acr/repository#az_acr_repository_show_manifests

-az acr repository show-manifests --name myregistry --repository acr-helloworld

-az acr repository show-manifests --name <acrName> --repository <repositoryName> \

- az acr repository show-manifests --name $REGISTRY --repository $REPOSITORY \

- az acr repository show-manifests --name $REGISTRY --repository $REPOSITORY \

- az acr repository show-manifests --name myregistry --repository acr-helloworld

- az acr repository show-manifests --name myregistry --repository acr-helloworld

-Run the [az acr repository show-manifests][az-acr-repository-show-manifests] command to see details of the chart stored in the repository. For example:

-[az-acr-repository-show-manifests]: /cli/azure/acr/repository#az_acr_repository_show_manifests

-To lock a *myimage* image identified by manifest digest (SHA-256 hash, represented as `sha256:...`), run the following command. (To find the manifest digest associated with one or more image tags, run the [az acr repository show-manifests][az-acr-repository-show-manifests] command.)

-[az-acr-repository-show-manifests]: /cli/azure/acr/repository#az_acr_repository_show_manifests

-You can verify that multiple manifests are associated with this image by running the `az acr repository show-manifests` command:

-az acr repository show-manifests \

- --name myregistry \

- --repository hello-world

-az acr repository show-manifests \

- -n $ACR_NAME \

- --repository $REPO \

- --detail -o jsonc

-az acr repository show-manifests \

- -n $ACR_NAME \

- --repository $REPO \

- |`metadata/read` | `az acr repository show`<br/><br/>`az acr repository show-tags`<br/><br/>`az acr repository show-manifests` in Azure CLI |

-To read metadata in the `samples/hello-world` repository, run the [az acr repository show-manifests][az-acr-repository-show-manifests] or [az acr repository show-tags][az-acr-repository-show-tags] command.

-[az-acr-repository-show-manifests]: /cli/azure/acr/repository/#az_acr_repository_show_manifests

-1. Within a few seconds, the untagged manifest is deleted. You can verify the deletion by listing manifests in the repository, for example, using the [az acr repository show-manifests][az-acr-repository-show-manifests] command. If the test image was the only one in the repository, the repository itself is deleted.

-[az-acr-repository-show-manifests]: /cli/azure/acr/repository#az_acr_repository_show_manifests

-You can view a manifest in Azure Container Registry using the Azure portal or tools such as the [az acr repository show-manifests](/cli/azure/acr/repository#az-acr-repository-show-manifests) command in the Azure CLI.

-When a multi-arch manifest list is stored in Azure Container Registry, you can also view the manifest list using the Azure portal or with tools such as the [az acr repository show-manifests](/cli/azure/acr/repository#az-acr-repository-how-manifests) command.

-description: Learn how to use the bulk executor library to massively import graph data into an Azure Cosmos DB Gremlin API container.

-# Bulk ingestion in Azure Cosmos DB Gremlin API using BulkExecutor

-Graph database often has a use case to perform bulk ingestion to refresh the entire graph or update a portion of it. Cosmos DB, which is a distributed database and backbone of Azure Cosmos DB - Gremlin API, is meant to perform if the load is well distributed. BulkExecutor libraries in Cosmos DB designed to exploit this unique capability of Cosmos DB and provide the best performance, refer [here](https://devblogs.microsoft.com/cosmosdb/introducing-bulk-support-in-the-net-sdk).

-This tutorial provides instructions about using Azure Cosmos DB's bulk executor library to import and update graph objects into an Azure Cosmos DB Gremlin API container. This process makes use to create Vertex and Edge objects programmatically to then insert multiple of them per network request.

-Instead of sending Gremlin queries to a database, where the command is evaluated and then executed one at a time, using the BulkExecutor library will require to create and validate the objects locally. After initializing, the graph objects, the library allows you to send graph objects to the database service sequentially. Using this method, data ingestion speeds can be increased up to 100x, which makes it an ideal method for initial data migrations or periodical data movement operations.

-It's now available in following flavors:

-* An Azure subscription. You can create [a free Azure account here](https://azure.microsoft.com/free/?ref=microsoft.com&utm_source=microsoft.com&utm_medium=docs&utm_campaign=cosmos-db). Alternatively, you can create a Cosmos database account with [Try Azure Cosmos DB for free](https://azure.microsoft.com/try/cosmosdb/) without an Azure subscription.

-* An Azure Cosmos DB Gremlin API database with an **unlimited collection**. The guide shows how to get started with [Azure Cosmos DB Gremlin API in .NET](./create-graph-dotnet.md).

-* Git. For more information check out the [Git Downloads page](https://git-scm.com/downloads).

-To run this sample, run the `git clone` command below:

-The sample is available at path .\azure-cosmos-graph-bulk-executor\dotnet\src\

-Modify the following parameters as:

-Parameter|Description

-|

-`ConnectionString`|It is **your .NET SDK endpoint** found in the Overview section of your Azure Cosmos DB Gremlin API database account. It has the format of `https://your-graph-database-account.documents.azure.com:443/`

-`DatabaseName`, `ContainerName`|These parameters are the **target database and container names**.

-`DocumentsToInsert`| Number of documents to be generated (only relevant to generate synthetic data)

-`PartitionKey` | To ensure partition key is specified along with each document while ingestion.

-`NumberOfRUs` | Only relevant if container doesn't exists and needs to be created as part of execution

-Download the full sample application in .NET from [here](https://github.com/Azure-Samples/azure-cosmos-graph-bulk-executor/tree/main/dotnet).

-## JAVA

-The sample application is provided to illustrate how to use the GraphBulkExecutor package. Samples are available for using either the Domain object annotations or using the POJO objects directly. It's recommended, to try both approaches, to determine which better meets your implementation and performance demands.

-To run the sample, run the `git clone` command below:

-The sample is available at .\azure-cosmos-graph-bulk-executor\java\

-To run this sample, you'll need to have the following software:

-* An Azure Cosmos DB Account configured to use the Gremlin API

-To run the sample, refer the configuration as follows and modify as needed:

-The /resources/application.properties file defines the data required to configure the Cosmos DB the required values are:

-* **sample.sql.host**: It's the value provided by the Azure Cosmos DB. Ensure you use the ".NET SDK URI", which can be located on the Overview section of the Cosmos DB Account.

-* **sample.sql.key**: You can get the primary or secondary key from the Keys section of the Cosmos DB Account.

-* **sample.sql.database.name**: The name of the database within the Cosmos DB account to run the sample against. If the database isn't found, the sample code will create it.

-* **sample.sql.container.name**: The name of the container within the database to run the sample against. If the container isn't found, the sample code will create it.

-* **sample.sql.partition.path**: If the container needs to be created, this value will be used to define the partitionKey path.

-* **sample.sql.allow.throughput**: The container will be updated to use the throughput value defined here. If you're exploring different throughput options to meet your performance demands, make sure to reset the throughput on the container when done with your exploration. There are costs associated with leaving the container provisioned with a higher throughput.

-Once the configuration is modified as per your environment, then run the command:

-For added safety, you can also run the integration tests by changing the "skipIntegrationTests" value in the pom.xml to

-false.

-Assuming the Unit tests were run successfully. You can run the command line to execute the sample code:

-Running the above commands will execute the sample with a small batch (1k Vertices and roughly 5k Edges). Use the following command lines arguments to tweak the volumes run and which sample version to run.

-### Command line Arguments

-There are several command line arguments are available while running this sample, which is detailed as:

-* **--vertexCount** (-v): Tells the application how many person vertices to generate.

-* **--edgeMax** (-e): Tells the application what the maximum number of edges to generate for each Vertex. The generator will randomly select a number between 1 and the value provided here.

-* **--domainSample** (-d): Tells the application to run the sample using the Person and Relationship domain structures instead of the GraphBulkExecutors GremlinVertex and GremlinEdge POJOs.

-* **--createDocuments** (-c): Tells the application to use create operations. If not present, the application will default to using upsert operations.

-### Details about the sample

-#### Person Vertex

-The Person class is a fairly simple domain object that has been decorated with several annotations to help the

-transformation into the GremlinVertex class. They are as follows:

-* **GremlinVertex**: Notice how we're using the optional "label" parameter to define all Vertices created using this class.

-* **GremlinId**: Being used to define which field will be used as the ID value. While the field name on the Person class is ID, it isn't required.

-* **GremlinProperty**: Is being used on the email field to change the name of the property when stored in the database.

-* **GremlinPartitionKey**: Is being used to define which field on the class contains the partition key. The field name provided here should match the value defined by the partition path on the container.

-* **GremlinIgnore**: Is being used to exclude the isSpecial field from the property being written to the database.

-#### Relationship Edge

-The RelationshipEdge is a fairly versatile domain object. Using the field level label annotation allows for a dynamic

-collection of edge types to be created. The following annotations are represented in this sample domain edge:

-* **GremlinEdge**: The GremlinEdge decoration on the class, defines the name of the field for the specified partition key. The value assigned, when the edge document is created, will come from the source vertex information.

-* **GremlinEdgeVertex**: Notice that there are two instances of GremlinEdgeVertex defined. One for each side of the edge (Source and Destination). Our sample has the field's data type as GremlinEdgeVertexInfo. The information provided by GremlinEdgeVertex class is required for the edge to be created correctly in the database. Another option would be to have the data type of the vertices be a class that has been decorated with the GremlinVertex annotations.

-* **GremlinLabel**: The sample edge is using a field to define what the label value is. It allows different labels to be defined while still using the same base domain class.

-### Output Explained

-The console will finish its run with a json string describing the run times of the sample. The json string contains the

-following information.

-* **startTime**: The System.nanoTime() when the process started.

-* **endtime**: The System.nanoTime() when the process completed.

-* **durationInNanoSeconds**: The difference between the endTime and the startTime.

-* **durationInMinutes**: The durationInNanoSeconds converted into minutes. Important to note that durationInMinutes is represented as a float number, not a time value. For example, a value 2.5 would be 2 minutes and 30 seconds.

-* **vertexCount**: The volume of vertices generated which should match the value passed into the command line execution.

-* **edgeCount**: The volume of edges generated which isn't static and it's built with an element of randomness.

-* **exception**: Only populated when there was an exception thrown when attempting to make the run.

-#### States Array

-The states array gives insight into how long each step within the execution takes. The steps that occur are:

-* **Build sample vertices**: The time it takes to fabricate the requested volume of Person objects.

-* **Build sample edges**: The time it takes to fabricate the Relationship objects.

-* **Configure Database**: The amount of time it took to get the database configured based on the values provided in the

- application.properties.

-* **Write Documents**: The total time it took to write the documents to the database.

-Each state will contain the following values:

-* **stateName**: The name of the state being reported.

-* **startTime**: The System.nanoTime() when the state started.

-* **endtime**: The System.nanoTime() when the state completed.

-* **durationInNanoSeconds**: The difference between the endTime and the startTime.

-* **durationInMinutes**: The durationInNanoSeconds converted into minutes. Important to note that durationInMinutes is represented as a float number, not a time value. for example, a value 2.5 would be 2 minutes and 30 seconds.

-* Review the [BulkExecutor Java, which is Open Source](https://github.com/Azure-Samples/azure-cosmos-graph-bulk-executor/tree/main/java/src/main/java/com/azure/graph/bulk/impl) for more details about the classes and methods defined in this namespace.

-* Review the [BulkMode, which is part of .NET V3 SDK](../sql/tutorial-sql-api-dotnet-bulk-import.md)

-| EA purchaser | Purchase reservation orders and view reservation transactions. Can view usage and charges across all accounts and subscriptions. Can view the Azure Prepayment (previously called monetary commitment) balance associated with the enrollment. | da6647fb-7651-49ee-be91-c43c4877f0c4 |

-Your invoice displays Azure usage charges with costs associated to them first, followed by any Marketplace charges. If you have a credit balance, it's applied to Azure usage and your invoice will display Azure usage and Marketplace usage without any cost last.

-|Billing account owner|Manage everything for billing account|

-The default cluster size is four driver nodes and four worker nodes. As you process more data, larger clusters are recommended. Below are the possible sizing options:

-| 4 | 4 | 8 | |

-| 8 | 8 | 16 | |

-| 64 | 16 | 80 | |

-This Amazon S3 Compatible Storage connector is supported for the following activities:

-Specifically, this Amazon S3 Compatible Storage connector supports copying files as is or parsing files with the [supported file formats and compression codecs](supported-file-formats-and-compression-codecs.md). The connector uses [AWS Signature Version 4](https://docs.aws.amazon.com/general/latest/gr/signature-version-4.html) to authenticate requests to S3. You can use this Amazon S3 Compatible Storage connector to copy data from any S3-compatible storage provider. Specify the corresponding service URL in the linked service configuration.

-This Amazon S3 connector is supported for the following activities:

-This Cassandra connector is supported for the following activities:

-You can copy data from Cassandra database to any supported sink data store. For a list of data stores that are supported as sources/sinks by the copy activity, see the [Supported data stores](copy-activity-overview.md#supported-data-stores-and-formats) table.

-This Couchbase connector is supported for the following activities:

-You can copy data from Couchbase to any supported sink data store. For a list of data stores that are supported as sources/sinks by the copy activity, see the [Supported data stores](copy-activity-overview.md#supported-data-stores-and-formats) table.

-This file system connector is supported for the following activities:

-This FTP connector is supported for the following activities:

-This Google Cloud Storage connector is supported for the following activities:

-The HDFS connector is supported for the following activities:

-This HTTP connector is supported for the following activities:

-You can copy data from an HTTP source to any supported sink data store. 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).

-| authenticationType | Specifies the authentication type. Allowed values are **Anonymous**, **Basic**, **Digest**, **Windows**, and **ClientCertificate**. User-based OAuth isn't supported. You can additionally configure authentication headers in `authHeader` property. See the sections that follow this table for more properties and JSON samples for these authentication types. | Yes |

-You can copy data from MongoDB Atlas database to any supported sink data store, or copy data from any supported source data store to MongoDB Atlas database. For a list of data stores that are supported as sources/sinks by the copy activity, see the [Supported data stores](copy-activity-overview.md#supported-data-stores-and-formats) table.

-You can copy data from MongoDB database to any supported sink data store, or copy data from any supported source data store to MongoDB database. For a list of data stores that are supported as sources/sinks by the copy activity, see the [Supported data stores](copy-activity-overview.md#supported-data-stores-and-formats) table.

-This OData connector is supported for the following activities:

-You can copy data from an OData source to any supported sink data store. 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).

-This ODBC connector is supported for the following activities:

-You can copy data from ODBC source to any supported sink data store, or copy from any supported source data store to ODBC sink. For a list of data stores that are supported as sources/sinks by the copy activity, see the [Supported data stores](copy-activity-overview.md#supported-data-stores-and-formats) table.

-This Oracle Cloud Storage connector is supported for the following activities:

-You can copy data from a REST source to any supported sink data store. You also can copy data from any supported source data store to a REST sink. 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).

-The SFTP connector is supported for the following activities:

-The Core Count and Compute Type properties can be set dynamically to adjust to the size of your incoming source data at runtime. Use pipeline activities like Lookup or Get Metadata in order to find the size of the source dataset data. Then, use Add Dynamic Content in the Data Flow activity properties.

-> [!NOTE]

-> When choosing driver and worker node cores in Azure Synapse Data Flows, a minimum of 3 nodes will always be utilized.

-In this quickstart, you'll explore a prebuilt Azure Digital Twins graph using the [Azure Digital Twins Explorer](concepts-azure-digital-twins-explorer.md). This tool allows you to visualize and interact with your Azure Digital Twins data within the Azure portal.

-With Azure Digital Twins, you can create and interact with live models of your real-world environments, which can be part of wider IoT solutions. First, you model individual elements as digital twins. Then you connect them into a knowledge graph that can respond to live events and be queried for information.

-You'll complete the following steps:

-1. Create an Azure Digital Twins instance, and connect to it in Azure Digital Twins Explorer.

-1. Upload prebuilt models and graph data to construct the sample scenario.

-1. Explore the scenario graph that's created.

-1. Make changes to the graph.

-1. Review your learnings from the experience.

-The Azure Digital Twins example graph you'll be working with represents a building with two floors and two rooms. Floor0 contains Room0, and Floor1 contains Room1. The graph will look like this image:

->This quickstart is for exploring a prebuilt graph to understand how Azure Digital Twins represents data. For simplicity, the quickstart does not cover setting up connections between IoT Hub devices and their graph representations. To set up a connected end-to-end flow for your graph, move ahead to the tutorials: [Connect an end-to-end solution](tutorial-end-to-end.md).

-You'll also need to download the materials for the sample graph used in the quickstart. Use the instructions below to download the three required files. Later, you'll follow more instructions to upload them to Azure Digital Twins.

-* [Room.json](https://raw.githubusercontent.com/Azure-Samples/digital-twins-explorer/main/client/examples/Room.json): This is a model file representing a room in a building. Navigate to the link, right-click anywhere on the screen, and select **Save as** in your browser's right-click menu. Use the following Save As window to save the file somewhere on your machine with the name *Room.json*.

-* [Floor.json](https://raw.githubusercontent.com/Azure-Samples/digital-twins-explorer/main/client/examples/Floor.json): This is a model file representing a floor in a building. Navigate to the link, right-click anywhere on the screen, and select **Save as** in your browser's right-click menu. Use the following Save As window to save the file to the same location as *Room.json*, under the name *Floor.json*.

-* [buildingScenario.xlsx](https://github.com/Azure-Samples/digital-twins-explorer/raw/main/client/examples/buildingScenario.xlsx): This file contains a graph of room and floor twins, and relationships between them. Depending on your browser settings, selecting this link may download the *buildingScenario.xlsx* file automatically to your default download location, or it may open the file in your browser with an option to download. Here is what that download option looks like in Microsoft Edge:

-The first step in working with Azure Digital Twins is to create an Azure Digital Twins instance. After you create an instance of the service, you can connect to the instance in Azure Digital Twins Explorer, which you'll use to work with the instance throughout the quickstart.

-The rest of this section walks you through the instance creation.

-## Upload the sample materials

-Next, you'll import the sample models and graph into Azure Digital Twins Explorer. You'll use the model files and the graph file that you downloaded to your machine in the [Prerequisites](#prerequisites) section.

-The first step in an Azure Digital Twins solution is to define the vocabulary for your environment. You'll create custom *models* that describe the types of entity that exist in your environment.

-Each model is written in a language like [JSON-LD](https://json-ld.org/) called *Digital Twin Definition Language (DTDL)*. Each model describes a single type of entity in terms of its properties, telemetry, relationships, and components. Later, you'll use these models as the basis for digital twins that represent specific instances of these types.

-Typically, when you create a model, you'll complete three steps:

-1. Write the model definition. In the quickstart, this step is already done as part of the sample solution.

-1. Validate it to make sure the syntax is accurate. In the quickstart, this step is already done as part of the sample solution.

-1. Upload it to your Azure Digital Twins instance.

-For this quickstart, the model files are already written and validated for you. They're included with the solution you downloaded. In this section, you'll upload two prewritten models to your instance to define these components of a building environment:

-* Floor

-* Room

-Follow these steps to upload models (the *.json* files you downloaded earlier).

-1. In the Open window that appears, navigate to the folder containing the *Room.json* and *Floor.json* files that you downloaded earlier.

-1. Select *Room.json* and *Floor.json*, and select **Open** to upload them both.

-You can select **View Model** for either model to see the DTDL code behind it.

- :::column:::

- :::image type="content" source="media/quickstart-azure-digital-twins-explorer/model-info.png" alt-text="Screenshot of the Azure Digital Twins Explorer showing the Models panel with two model definitions listed inside, Floor and Room." lightbox="media/quickstart-azure-digital-twins-explorer/model-info.png":::

- :::column-end:::

- :::column:::

- :::column-end:::

- :::column:::

- :::column-end:::

-Now that some models have been uploaded to your Azure Digital Twins instance, you can add *digital twins* based on the model definitions.

-*Digital twins* represent the actual entities within your business environment. They can be things like sensors on a farm, lights in a car, orΓÇöin this quickstartΓÇörooms on a building floor. You can create many twins of any given model type, such as multiple rooms that all use the Room model. You connect them with relationships into a *twin graph* that represents the full environment.

-In this section, you'll upload pre-created twins that are connected into a pre-created graph. The graph contains two floors and two rooms, connected in the following layout:

-* Floor0

- - Contains Room0

-* Floor1

- - Contains Room1

-Follow these steps to import the graph (the *.xlsx* file you downloaded earlier).

-2. In the Open window, navigate to the *buildingScenario.xlsx* file you downloaded earlier. This file contains a description of the sample graph. Select **Open**.

- :::row:::

- :::column:::

- :::image type="content" source="media/quickstart-azure-digital-twins-explorer/import-success.png" alt-text="Screenshot of the Azure Digital Twins Explorer showing a dialog box indicating graph import success." lightbox="media/quickstart-azure-digital-twins-explorer/import-success.png":::

- :::column-end:::

- :::column:::

- :::column-end:::

- :::row-end:::

-This action runs the default query to select and display all digital twins. Azure Digital Twins Explorer retrieves all twins and relationships from the service. It draws the graph defined by them in the **Twin Graph** panel.

-## Explore the graph

-Now you can see the uploaded graph of the sample scenario.

-The circles (graph "nodes") represent digital twins. The lines represent relationships. The Floor0 twin contains Room0, and the Floor1 twin contains Room1.

-If you're using a mouse, you can click and drag in the graph to move elements around.

-### View twin properties

-You can select a twin to see a list of its properties and their values in the **Twin Properties** panel.

-Here are the properties of Room0:

- :::column:::

- :::image type="content" source="media/quickstart-azure-digital-twins-explorer/properties-room0.png" alt-text="Screenshot of the Azure Digital Twins Explorer highlighting the Twin Properties panel, which shows $dtId, Temperature, and Humidity properties for Room0." lightbox="media/quickstart-azure-digital-twins-explorer/properties-room0.png":::

- :::column-end:::

- :::column:::

- :::column-end:::

-Room0 has a temperature of 70.

-Here are the properties of Room1:

- :::column:::

- :::image type="content" source="media/quickstart-azure-digital-twins-explorer/properties-room1.png" alt-text="Screenshot of the Azure Digital Twins Explorer highlighting the Twin Properties panel, which shows $dtId, Temperature, and Humidity properties for Room1." lightbox="media/quickstart-azure-digital-twins-explorer/properties-room1.png":::

- :::column-end:::

- :::column:::

- :::column-end:::

-Room1 has a temperature of 80.

-### Query the graph

-In Azure Digital Twins, you can query your twin graph to answer questions about your environment, using the SQL-style *Azure Digital Twins query language*.

-One way to query the twins in your graph is by their properties. Querying based on properties can help answer questions about your environment. For example, you can find outliers in your environment that might need attention.

-In this section, you'll run a query to answer the question of how many twins in your environment have a temperature above 75.

-To see the answer, run the following query in the **Query Explorer** panel.

-Recall from viewing the twin properties earlier that Room0 has a temperature of 70, and Room1 has a temperature of 80. The Floor twins don't have a Temperature property at all. For these reasons, only Room1 shows up in the results here.

-> Other comparison operators (<,>, =, or !=) are also supported within the preceding query. You can try plugging these operators, different values, or different twin properties into the query to try out answering your own questions.

-## Edit data in the graph

-In a fully connected Azure Digital Twins solution, the twins in your graph can receive live updates from real IoT devices and update their properties to stay synchronized with your real-world environment. You can also manually set the properties of the twins in your graph, using Azure Digital Twins Explorer or another development interface (like the APIs or Azure CLI).

-For simplicity, you'll use Azure Digital Twins Explorer here to manually set the temperature of Room0 to 76.

-First, rerun the following query to select all digital twins. This will display the full graph once more in the **Twin Graph** panel.

-The properties in this list are editable. Select the temperature value of **70** to enable entering a new value. Enter *76* and select the **Save** icon to update the temperature.

- :::column:::

- :::image type="content" source="media/quickstart-azure-digital-twins-explorer/new-properties-room0.png" alt-text="Screenshot of the Azure Digital Twins Explorer highlighting that the Twin Properties panel is showing properties that can be edited for Room0." lightbox="media/quickstart-azure-digital-twins-explorer/new-properties-room0.png":::

- :::column-end:::

- :::column:::

- :::column-end:::

- :::column:::

- :::image type="content" source="media/quickstart-azure-digital-twins-explorer/patch-information.png" alt-text="Screenshot of the Azure Digital Twins Explorer showing Patch Information for the temperature update." lightbox="media/quickstart-azure-digital-twins-explorer/patch-information.png":::

- :::column-end:::

- :::column:::

- :::column-end:::

-### Query to see the result

-To verify that the graph successfully registered your update to the temperature for Room0, rerun the query from earlier to get all the twins in the environment with a temperature above 75.

-Now that the temperature of Room0 has been changed from 70 to 76, both twins should show up in the result.

-In this quickstart, you created an Azure Digital Twins instance and used Azure Digital Twins Explorer to populate it with a sample scenario.

-You then explored the graph, by:

-The intent of this exercise is to demonstrate how you can use the Azure Digital Twins graph to answer questions about your environment, even as the environment continues to change.

-In this quickstart, you made the temperature update manually. It's common in Azure Digital Twins to connect digital twins to real IoT devices so that they receive updates automatically, based on telemetry data. In this way, you can build a live graph that always reflects the real state of your environment. You can use queries to get information about what's happening in your environment in real time.

-You may also want to delete the sample project folder from your local machine.

-An endpoint's domain can be reused within the same tenant, subscription, or resource group scope level. You can also choose to not allow the reuse of an endpoint domain. By default, your allow reuse of the endpoint domain within the same Azure Active Directory tenant.

- * Express Route - ExpressRoute is an Azure service that lets you create private connections between Microsoft datacenters and infrastructure thatΓÇÖs on your premises or in a colocation facility. ExpressRoute connections don't go over the public Internet, and offer higher security, reliability, and speeds with lower latencies than typical connections over the Internet. For more information, see [Create and modify an ExpressRoute circuit](../../expressroute/expressroute-howto-circuit-portal-resource-manager.md).

- Data Box offline data transfer - Data Box, Data Box Disk, and Data Box Heavy devices help you transfer large amounts of data to Azure when the network isnΓÇÖt an option. These offline data transfer devices are shipped between your organization and the Azure datacenter. They use AES encryption to help protect your data in transit, and they undergo a thorough post-upload sanitization process to delete your data from the device. For more information on the Data Box offline transfer devices, see [Azure Data Box Documentation - Offline Transfer](../../databox/index.yml). For more information on migration of Hadoop clusters, see [Use Azure Data Box to migrate from an on-premises HDFS store to Azure Storage](../../storage/blobs/data-lake-storage-migrate-on-premises-hdfs-cluster.md).

-* A default metastore database (Ambari, Hive, Oozie, Ranger) has reached itΓÇÖs utilization limit. Microsoft will ask you to recreate the cluster using a [custom metastore](hdinsight-use-external-metadata-stores.md#custom-metastore) database.

-> It's recommended to have sufficient gap between two schedules so that data cache is efficiently utilized i.e schedule scale upΓÇÖs when there is peak usage and scale downΓÇÖs when there is no usage.

- at com.google.common.util.concurrent.AbstractFuture.cancellationExceptionWithCause(AbstractFuture.java:1349) ~[guava-28.0-jre.jar:?]

- at com.google.common.util.concurrent.AbstractFuture.getDoneValue(AbstractFuture.java:550) ~[guava-28.0-jre.jar:?]

- at com.google.common.util.concurrent.AbstractFuture.get(AbstractFuture.java:513) ~[guava-28.0-jre.jar:?]

- at com.google.common.util.concurrent.AbstractFuture$TrustedFuture.get(AbstractFuture.java:90) ~[guava-28.0-jre.jar:?]

- at com.google.common.util.concurrent.Uninterruptibles.getUninterruptibly(Uninterruptibles.java:237) ~[guava-28.0-jre.jar:?]

- at com.google.common.util.concurrent.Futures.getDone(Futures.java:1064) ~[guava-28.0-jre.jar:?]

- at com.google.common.util.concurrent.Futures$CallbackListener.run(Futures.java:1013) ~[guava-28.0-jre.jar:?]

- at com.google.common.util.concurrent.DirectExecutor.execute(DirectExecutor.java:30) ~[guava-28.0-jre.jar:?]

- at com.google.common.util.concurrent.AbstractFuture.executeListener(AbstractFuture.java:1137) ~[guava-28.0-jre.jar:?]

- at com.google.common.util.concurrent.AbstractFuture.complete(AbstractFuture.java:957) ~[guava-28.0-jre.jar:?]

- at com.google.common.util.concurrent.AbstractFuture.cancel(AbstractFuture.java:611) ~[guava-28.0-jre.jar:?]

- at com.google.common.util.concurrent.AbstractFuture$TrustedFuture.cancel(AbstractFuture.java:118) ~[guava-28.0-jre.jar:?]

- at org.apache.hadoop.hive.ql.exec.tez.WmTezSession$TimeoutRunnable.run(WmTezSession.java:264) ~[hive-exec-3.1.3.4.1.3.6.jar:3.1.3.4.1.3.6]

- at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:1.8.0_275]

- at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:1.8.0_275]

- at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) ~[?:1.8.0_275]

- at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) ~[?:1.8.0_275]

- at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_275]

- at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_275]

- at java.lang.Thread.run(Thread.java:748) [?:1.8.0_275]

-This is the first [major official release](https://github.com/dotnet/spark/releases/tag/v1.0.0) of .NET for Apache Spark and provides DataFrame API completeness for Spark 2.4.x as well as Spark 3.0.x along with other features. For a complete list of all features, improvements and bug fixes, see the official [v1.0.0 release notes](https://github.com/dotnet/spark/blob/master/docs/release-notes/1.0.0/release-1.0.0.md).

-Another important thing to note is that this version is **not** compatible with prior versions of `Microsoft.Spark` and `Microsoft.Spark.Worker`. Check out the [migration guide](https://github.com/dotnet/spark/blob/master/docs/migration-guide.md#upgrading-from-microsoftspark-0x-to-10) if you are planning to upgrade your .NET for Apache Spark application to be compatible with v1.0.0.

-While current HDI clusters will not be affected (i.e. they will still have the same version as before), newly created HDI clusters will carry this latest v1.0.0 version of .NET for Apache Spark. What this means if:

-If you don't want to change the current version of .NET for Apache Spark in your application, you would have to change the version on your HDI cluster from v1.0 (default on new clusters) to whichever version you are using. For more information, see the [changing versions of .NET for Apache Spark on HDI cluster section](spark-dotnet-version-update.md#changing-net-for-apache-spark-version-on-hdinsight).

-3. Upload the above mentioned files to the Azure Storage account your cluster has access to. You can refer to [the .NET for Apache Spark HDI deployment article](/dotnet/spark/tutorials/hdinsight-deployment#upload-files-to-azure) for more details.

-4. Run the `install-worker.sh` script on all worker nodes of your cluster, using Script actions. Refer to [the .NET for Apache Spark HDI deployment article](/dotnet/spark/tutorials/hdinsight-deployment#run-the-hdinsight-script-action) for more information.

-Existing HDI clusters will continue to have the same previous version for .NET for Apache Spark and your existing application (having previous version of Spark .NET) will not be affected.

-[Deploy your .NET for Apache Spark application on HDInsight](/dotnet/spark/tutorials/hdinsight-deployment)

-# The MedTech service data flows

-This article provides an overview of the MedTech service data flows. You'll learn about the different data processing stages within the MedTech service that transforms device data into Fast Healthcare Interoperability Resources (FHIR&#174;)-based [Observation](https://www.hl7.org/fhir/observation.html) resources.

-Data from health-related devices or medical devices flows through a path in which the MedTech service transforms data into FHIR, and then data is stored on and accessed from the FHIR service. The health data path follows these steps in this order: ingest, normalize, group, transform, and persist. In this data flow, health data is retrieved from the device in the first step of ingestion. After the data is received, it's processed or normalized per user-selected or user-created schema templates, so that the health data is simpler to process and can be grouped. Health data is grouped into three Operate parameters. After the health data is normalized and grouped, it can be processed or transformed through FHIR destination mappings, and then saved or persisted on the FHIR service.

-This article goes into more depth about each step in the data flow. The next steps are [Deploy the MedTech service using the Azure portal](deploy-iot-connector-in-azure.md) by using Device mappings (the normalization step) and FHIR destination mappings (the transformation step).

-This next section of the article describes the stages that IoMT (Internet of Medical Things) data goes through once received from an event hub and into the MedTech service.

-Ingest is the first stage where device data is received into the MedTech service. The ingestion endpoint for device data is hosted on an [Azure Event Hubs](../../event-hubs/index.yml). Azure Event Hubs platform supports high scale and throughput with ability to receive and process millions of messages per second. It also enables the MedTech service to consume messages asynchronously, removing the need for devices to wait while device data gets processed.

-Normalize is the next stage where device data is retrieved from the above event hub and processed using the Device mappings. This mapping process results in transforming device data into a normalized schema.

-description: This article explains how to configure the MedTech service Diagnostic settings for metrics exporting.

-# Configure diagnostic setting for the MedTech service metrics exporting

-In this article, you'll learn how to configure the diagnostic setting for MedTech service to export metrics to different destinations for audit, analysis, or backup.

-Having access to metrics is essential for monitoring and troubleshooting. MedTech service allows you to do these actions through the export of metrics.

-(FHIR&#174;) is a registered trademark of HL7 and is used with the permission of HL7.

-A downstream device can be any application or platform that has an identity created with the [Azure IoT Hub](../iot-hub/index.yml) cloud service. These applications often use the [Azure IoT device SDK](../iot-hub/iot-hub-devguide-sdks.md). A downstream device could even be an application running on the IoT Edge gateway device itself. However, an IoT Edge device cannot be downstream of an IoT Edge gateway.

-If you do not have a device ready, you can create one in an Azure virtual machine. Follow the steps in [Deploy your first IoT Edge module to a virtual Linux device](quickstart-linux.md) to create an IoT Hub, create a virtual machine, and configure the IoT Edge runtime.

- 1. To start, set up the scripts for generating certificates on your device.

- 2. Create a root CA certificate. At the end of those instructions, you'll have a root CA certificate file:

- * `<path>/certs/azure-iot-test-only.root.ca.cert.pem`.

- 3. Create IoT Edge device CA certificates. At the end of those instructions, you'll have a device CA certificate and its private key:

- * `<path>/certs/iot-edge-device-ca-<cert name>-full-chain.cert.pem` and

- * `<path>/private/iot-edge-device-ca-<cert name>.key.pem`

-If you created the certificates on a different machine, copy them over to your IoT Edge device then proceed with the next steps.

- Make sure there is no preceding whitespace on the **certificates:** line, and that the other lines are indented by two spaces.

-1. On your IoT Edge device, open the config file: `/etc/aziot/config.toml`

-For a gateway scenario to work, at least one of the IoT Edge hub's supported protocols must be open for inbound traffic from downstream devices. The supported protocols are MQTT, AMQP, HTTPS, MQTT over WebSockets, and AMQP over WebSockets.

-In all three cases, the fully-qualified domain name (FQDN) would match the pattern `\*.azure-devices.net`.

-Since the IP address of an IoT hub can change without notice, always use the FQDN to allow-list configuration. To learn more, see [Understanding the IP address of your IoT hub](../iot-hub/iot-hub-understand-ip-address.md).

-description: Tutorial - Learn how to set up and use metrics and logs with an Azure IoT hub. This will provide data to analyze to help diagnose problems your hub may be having.

-You can use Azure Monitor to collect metrics and logs for your IoT hub that can help you monitor the operation of your solution and troubleshoot problems when they occur. In this article, you'll see how to create charts based on metrics, how to create alerts that trigger on metrics, how to send IoT Hub operations and errors to Azure Monitor Logs, and how to check the logs for errors.

-This tutorial uses the Azure sample from the [.NET Send telemetry quickstart](../iot-develop/quickstart-send-telemetry-iot-hub.md?pivots=programming-language-csharp) to send messages to the IoT hub. You can always use a device or another sample to send messages, but you may have to modify a few steps accordingly.

-For this tutorial, you need an IoT hub, a Log Analytics workspace, and a simulated IoT device. These resources can be created using Azure CLI or Azure PowerShell. Use the same resource group and location for all of the resources. Then, when you've finished the tutorial, you can remove everything in one step by deleting the resource group.

-Here are the required steps.

-Copy and paste this script into Cloud Shell. Assuming you are already logged in, it runs the script one line at a time. Some of the commands may take some time to execute. The new resources are created in the resource group *ContosoResources*.

-Only one free IoT hub is permitted per subscription. If you already have a free IoT hub in your subscription, either delete it before running the script or modify the script to use your free IoT hub or an IoT Hub that uses the standard or basic tier.

-The script prints the name of the IoT hub, the name of the Log Analytics workspace, and the connection string for the device it registers. Be sure to note these down as you'll need them later in this article.

-# This is the IOT Extension for Azure CLI.

-# You only need to install this the first time.

-# You need it to create the device identity.

-az extension add --name azure-iot

-# Set the values for the resource names that don't have to be globally unique.

-# The resources that have to have unique names are named in the script below

-# with a random number concatenated to the name so you can probably just

-# run this script, and it will work with no conflicts.

-randomValue=$RANDOM

-# Create the resource group to be used

-# for all the resources for this tutorial.

-az group create --name $resourceGroup \

- --location $location

-# The IoT hub name must be globally unique, so add a random number to the end.

-# Create the IoT hub in the Free tier. Partition count must be 2.

-az iot hub create --name $iotHubName \

- --resource-group $resourceGroup \

- --partition-count 2 \

- --sku F1 --location $location

-# The Log Analytics workspace name must be globally unique, so add a random number to the end.

-# Create the Log Analytics workspace

-az monitor log-analytics workspace create --resource-group $resourceGroup \

- --workspace-name $workspaceName --location $location

-# Create the IoT device identity to be used for testing.

-az iot hub device-identity create --device-id $iotDeviceName \

- --hub-name $iotHubName

-# Retrieve the primary connection string for the device identity, then copy it to

-# Notepad. You need this to run the device simulation during the testing phase.

-az iot hub device-identity show-connection-string --device-id $iotDeviceName \

- --hub-name $iotHubName

->[!NOTE]

->When creating the device identity, you may get the following error: *No keys found for policy iothubowner of IoT Hub ContosoTestHub*. To fix this error, update the Azure CLI IoT Extension and then run the last two commands in the script again.

->

->Here is the command to update the extension. Run this command in your Cloud Shell instance.

->

->```cli

->az extension update --name azure-iot

->```

-IoT Hub emits resource logs for several categories of operation; however, for you to view these logs you must create a diagnostic setting to send them to a destination. One such destination is Azure Monitor Logs, which are collected in a Log Analytics workspace. IoT Hub resource logs are grouped into different categories. You can select which categories you want sent to Azure Monitor Logs in the diagnostic setting. In this article, we'll collect logs for operations and errors that occur having to do with connections and device telemetry. For a full list of the categories supported for IoT Hub, see [IoT Hub resource logs](monitor-iot-hub-reference.md#resource-logs).

-1. First, if you're not already on your hub in the portal, select **Resource groups** and select the resource group ContosoResources. Select your IoT hub from the list of resources displayed.

-1. Look for the **Monitoring** section in the IoT Hub blade. Select **Diagnostic settings**. Then select **Add diagnostic setting**.

-1. On the **Diagnostics setting** pane, give your setting a descriptive name, such as "Send connections and telemetry to logs".

-1. Under **Category details**, select **Connections** and **Device Telemetry**.

-1. Under **Destination details**, select **Send to Log Analytics**, then use the Log Analytics workspace picker to select the workspace you noted previously. When you're finished, the diagnostic setting should look similar to the following screenshot:

-1. On the left pane of your IoT hub, select **Metrics** in the **Monitoring** section.

-1. On the chart, there is a partial metric setting displayed scoped to your IoT hub. Leave the **Scope** and **Metric Namespace** values at their defaults. Select the **Metric** setting and type "Telemetry", then select **Telemetry messages sent** from the dropdown. **Aggregation** will be automatically set to **Sum**. Notice that the title of your chart also changes.

-1. Now select **Add metric** to add another metric to the chart. Under **Metric**, select **Total number of messages used**. **Aggregation** will be automatically set to **Avg**. Notice again that the title of the chart has changed to include this metric.

-1. In the upper right of the chart, select **Pin to dashboard**.

- :::image type="content" source="media/tutorial-use-metrics-and-diags/metrics-total-number-of-messages-used-pin.png" alt-text="Screenshot that highlights the Pin to dashboard button.":::

-1. On the **Pin to dashboard** pane, select the **Existing** tab. Select **Private** and then select **Dashboard** from the Dashboard dropdown. Finally, select **Pin** to pin the chart to your default dashboard in Azure portal. If you don't pin your chart to a dashboard, your settings are not retained when you exit metric explorer.

-Now we'll set up alerts to trigger on two metrics *Telemetry messages sent* and *Total number of messages used*.

-*Telemetry messages sent* is a good metric to monitor to track message throughput and avoid being throttled. For an IoT Hub in the free tier, the throttling limit is 100 messages/sec. With a single device, we won't be able to achieve that kind of throughput, so instead, we'll set up the alert to trigger if the number of messages exceeds 1000 in a 5-minute period. In production, you can set the signal to a more significant value based on the tier, edition, and number of units of your IoT hub.

-*Total number of messages used* tracks the daily number of messages used. This metric resets every day at 00:00 UTC. If you exceed your daily quota past a certain threshold, your IoT Hub will no longer accept messages. For an IoT Hub in the free tier, the daily message quota is 8000. We'll set up the alert to trigger if the total number of messages exceeds 4000, 50% of the quota. In practice, you'd probably set this percentage to a higher value. The daily quota value is dependent on the tier, edition, and number of units of your IoT hub.

-1. Go to your IoT hub in Azure portal.

-1. Under **Monitoring**, select **Alerts**. Then select **New alert rule**. The **Create alert rule** pane opens.

- :::image type="content" source="media/tutorial-use-metrics-and-diags/create-alert-rule-pane.png" alt-text="Screenshot showing the Create alert rule pane.":::

- On the **Create alert rule** pane, there are four sections:

- * **Scope** is already set to your IoT hub, so we'll leave this section alone.

- * **Condition** sets the signal and conditions that will trigger the alert.

- * **Actions** configures what happens when the alert triggers.

- * **Alert rule details** lets you set a name and a description for the alert.

- 1. Under **Condition**, select **Add condition**. On the **Configure signal logic** pane, type "telemetry" in the search box and select **Telemetry messages sent**.

- :::image type="content" source="media/tutorial-use-metrics-and-diags/configure-signal-logic-telemetry-messages-sent.png" alt-text="Screenshot showing selecting the metric.":::

- 1. On the **Configure signal logic** pane, set or confirm the following fields under **Alert logic** (you can ignore the chart):

- **Threshold**: *Static*.

- **Operator**: *Greater than*.

- **Aggregation type**: *Total*.

- **Threshold value**: 1000.

- **Aggregation granularity (Period)**: *5 minutes*.

- **Frequency of evaluation**: *Every 1 Minute*

- :::image type="content" source="media/tutorial-use-metrics-and-diags/configure-signal-logic-set-conditions.png" alt-text="Screenshot showing alert conditions settings.":::

- These settings set the signal to total the number of messages over a period of 5 minutes. This total will be evaluated every minute, and, if the total for the preceding 5 minutes exceeds 1000 messages, the alert will trigger.

- Select **Done** to save the signal logic.

-1. Now configure the action for the alert.

- 1. Back on the **Create alert rule** pane, under **Actions**, select **Add action groups**. On the **Select an action group to attach to this alert rule** pane, select **Create action group**.

- 1. Under the **Basics** tab on the **Create action group** pane, give your action group a name and a display name.

- :::image type="content" source="media/tutorial-use-metrics-and-diags/create-action-group-basics.png" alt-text="Screenshot showing Basics tab of Create action group pane.":::

- 1. (Optional) If you select the **Actions** tab, and then select the **Action type** dropdown, you can see the kinds of actions that you can trigger with an alert. For this article, we'll only use notifications, so you can ignore the settings under this tab.

- :::image type="content" source="media/tutorial-use-metrics-and-diags/create-action-group-review-and-create.png" alt-text="Screenshot showing Review and Create pane.":::

- 1. Back on the **Create alert rule** pane, notice that your new action group has been added to the actions for the alert.

-1. Finally configure the alert rule details and save the alert rule.

- 1. On the **Create alert rule** pane, under Alert rule details, enter a name and a description for your alert; for example, "Alert if more than 1000 messages over 5 minutes". Make sure that **Enable alert rule upon creation** is checked. Your completed alert rule will look similar to this screenshot.

- :::image type="content" source="media/tutorial-use-metrics-and-diags/create-alert-rule-final.png" alt-text="Screenshot showing completed Create alert rule pane.":::

- 1. Select **Create alert rule** to save your new rule.

-1. Now set up another alert for the *Total number of messages used*. This metric is useful if you want to send an alert when the number of messages used is approaching the daily quota for the IoT hub, at which point, the IoT hub will start rejecting messages. Follow the steps you did before, with the following differences.

- * For the signal on the **Configure signal logic** pane, select **Total number of messages used**.

- * On the **Configure signal logic** pane, set or confirm the following fields (you can ignore the chart):

- **Threshold**: *Static*.

- **Operator**: *Greater than*.

- **Aggregation type**: *Maximum*.

- **Threshold value**: 4000.

- **Aggregation granularity (Period)**: *1 minute*.

- **Frequency of evaluation**: *Every 1 Minute*

- These settings set the signal to fire when the number of messages reaches 4000. The metric is evaluated every minute.

- * When you specify the action for your alert rule, just select the action group you created previously.

- * For the alert details, choose a different name and description than you did previously.

-1. Select **Alerts**, under **Monitoring** on the left pane of your IoT hub. Now select **Manage alert rules** on the menu at the top of the **Alerts** pane. The **Rules** pane opens. You should now see your two alerts:

-1. Close the **Rules** pane.

-Download the solution for the [IoT Device Simulation](https://github.com/Azure-Samples/azure-iot-samples-csharp/archive/main.zip). This link downloads a repo with several applications in it; the one you are looking for is in iot-hub/Quickstarts/simulated-device/.

- 1. Replace the value of the `s_connectionString` variable with the device connection string you noted when you ran the script to set up resources.

- 1. In the `SendDeviceToCloudMessagesAsync` method, change the `Task.Delay` from 1000 to 1, which reduces the amount of time between sending messages from 1 second to 0.001 seconds. Shortening this delay increases the number of messages sent. (You will likely not get a message rate of 100 messages per second.)

- ```csharp

- await Task.Delay(1);

- ```

- 1. Save your changes to **SimulatedDevice.cs**.

-Advance to the next tutorial to learn how to manage the state of an IoT device.

-> [Configure your devices from a back-end service](tutorial-device-twins.md)

-Automated cryptographic key rotation in [Key Vault](../general/overview.md) allows users to configure Key Vault to automatically generate a new key version at a specified frequency. To configure roation you can use key rotation policy, which can be defined on each individual key.

- WHERE jobid = $(job_execution_id))

- * .NET Framework 4.7.2

-Navigate to the **Jobs** tab. To view all your jobs in your Workspace across Experiments, select the **All jobs** tab. You can drill down on jobs for specific Experiments by applying the Experiment filter in the top menu bar.

-For the individual Experiment view, select the **All experiments** tab. On the experiment run dashboard, you can see tracked metrics and logs for each run.

-You can also edit the job list table to select multiple jobs and display either the last, minimum, or maximum logged value for your jobs. Customize your charts to compare the logged metrics values and aggregates across multiple jobs. You can plot multiple metrics on the y-axis of your chart and customize your x-axis to plot your logged metrics.

-description: This how to guide describes how you can view and edit asset details.

-# View, edit and delete assets in Microsoft Purview catalog

-This article discusses how you can view your assets and their relevant details. It also describes how you can edit and delete assets from your catalog.

-## Viewing asset details

-You can discover your assets in the Microsoft Purview data catalog by either:

-Once you find the asset you are looking for, you can view all of its details, edit, or delete them as described in following sections.

-The overview section of the asset details gives you a summarized view of an asset. The sections that follow explains the different parts of the overview page.

-### Asset hierarchy

-You can view the full asset hierarchy within the overview tab. As an example: if you navigate to a SQL table, then you can see the schema, database, and the server the table belongs to.

-### Asset classifications

-Asset classifications identify the kind of data being represented, and are applied manually or during a scan. For example: a National ID or passport number are supported classifications. (For a full list of classifications, see the [supported classifications page](supported-classifications.md).) The overview tab reflects both asset level classifications and column level classifications that have been applied, which you can also view as part of the schema.

-### Asset description

-You can view the description on an asset in the overview section. You can add an asset description by [editing the asset](#editing-assets)

-### Asset glossary terms

-Asset glossary terms are a managed vocabulary for business terms that can be used to categorize and relate assets across your environment. For example, terms like 'customer', 'buyer', 'cost center', or any terms that give your data context for your users. For more information, see the [business glossary page](concept-business-glossary.md). You can view the glossary terms for an asset in the overview section, and you can add a glossary term on an asset by [editing the asset](#editing-assets).

-## Editing assets

-You can edit an asset by selecting the edit icon on the top-left corner of the asset.

-### Scans on edited assets

-If you edit an asset by adding a description, asset level classification, glossary term, or a contact, later scans will still update the asset schema (new columns and classifications detected by the scanner in subsequent scan runs).

-If you make some column level updates, like adding a description, column level classification, or glossary term, then subsequent scans will also update the asset schema (new columns and classifications will be detected by the scanner in subsequent scan runs).

-Even on edited assets, after a scan Microsoft Purview will reflect the truth of the source system. For example: if you edit a column and it's deleted from the source, it will be deleted from your asset in Microsoft Purview.

->[!NOTE]

-> If you update the **name or data type of a column** in a Microsoft Purview asset, later scans **will not** update the asset schema. New columns and classifications **will not** be detected.

-## Deleting assets

-You can delete an asset by selecting the delete icon under the name of the asset.

-### Delete behavior explained

-Any asset you delete using the delete button is permanently deleted in Microsoft Purview. However, if you run a **full scan** on the source from which the asset was ingested into the catalog, then the asset is reingested and you can discover it using the Microsoft Purview catalog.

-If you have a scheduled scan (weekly or monthly) on the source, the **deleted asset will not get re-ingested** into the catalog unless the asset is modified by an end user since the previous run of the scan. For example, if a SQL table was deleted from Microsoft Purview, but after the table was deleted a user added a new column to the table in SQL, at the next scan the asset will be rescanned and ingested into the catalog.

-If you delete an asset, only that asset is deleted. Microsoft Purview does not currently support cascaded deletes. For example, if you delete a storage account asset in your catalog - the containers, folders and files within them are not deleted.

- public void StopRemoteSession()

- public void ConnectRuntimeToRemoteSession()

-public void StopRemoteSession()

- ARRSessionService.CurrentActiveSession.StopAsync();

-public void ConnectRuntimeToRemoteSession()

- //Connect the local runtime to the currently connected session

- //This session is set when connecting to a new or existing session

- ARRSessionService.CurrentActiveSession.ConnectAsync(new RendererInitOptions());

- CurrentCoordinatorState = RemoteRenderingState.ConnectingToRuntime;

-This article will show you how to configure your application for authentication with the [Microsoft identity platform](../active-directory/develop/v2-overview.md). To learn more about the OAuth 2.0 code grant flow used by Azure AD, see [Authorize access to Azure Active Directory web applications using the OAuth 2.0 code grant flow](../active-directory/develop/v2-oauth2-auth-code-flow.md).

-## Register an application with Azure AD

-The next step to using Azure AD for authentication is to register an application with the [Microsoft identity platform](../active-directory/develop/quickstart-register-app.md). If you have problems registering the application, make sure you have the [required permissions](../active-directory/develop/howto-create-service-principal-portal.md#permissions-required-for-registering-an-app).

-1. Sign into your Azure Account in the [Azure portal](https://portal.azure.com).

-1. Search for **Azure Active Directory**.

-1. Select **App Registrations**.

-1. Select **+ New Registration**.

-1. Give your application a name and select a supported account type, which determines who can use the application. Then, select **Register**.

- :::image type="content" source="media/search-howto-aad/register-app.png" alt-text="Screenshot of the register an application wizard" border="true" :::

-At this point, you've created your Azure AD application and service principal. Make a note of tenant (or directory) ID and the client (or application) ID on the overview page of your app registration. You'll need those values in a future step.

-## Create a client secret

-The application will also need a client secret or certificate to prove its identity when requesting a token.

-1. Navigate to the app registration you created.

-1. Select **Certificates and secrets**.

-1. Under **Client secrets**, select **New client secret**.

-1. Provide a description of the secret and select the desired expiration interval.

- :::image type="content" source="media/search-howto-aad/create-secret.png" alt-text="Screenshot of create a client secret wizard" border="true" :::

-Make sure to save the value of the secret in a secure location as you won't be able to access the value again.

-## Assign a role to the application

-Next, you need to grant your Azure AD application access to your search service. Azure Cognitive Search has various [built-in roles](search-security-rbac.md#built-in-roles-used-in-search). You can also create a [custom role](search-security-rbac.md#create-a-custom-role).

-1. Select **Access Control (IAM)** in the left navigation pane.

- + Search Index Data Contributor (preview)

-1. On the **Members** tab, select the Azure AD user or group identity under which your application runs.

-Once you have an Azure AD application created and you've granted it permissions to access your search service, you're ready you can add code to your application to authenticate a security principal and acquire an OAuth 2.0 token.

- The sample currently uses key-based authentication to create the `SearchClient` and `SearchIndexClient` but you can make a small change to switch over to role-based authentication. Instead of using `AzureKeyCredential` in the beginning of `Main()` in [Program.cs](https://github.com/Azure-Samples/azure-search-dotnet-samples/blob/master/quickstart/v11/AzureSearchQuickstart-v11/Program.cs), use this:

- ```csharp

- AzureKeyCredential credential = new AzureKeyCredential(apiKey);

-

- SearchIndexClient adminClient = new SearchIndexClient(serviceEndpoint, credential);

- SearchClient srchclient = new SearchClient(serviceEndpoint, indexName, credential);

-1. Use `ClientSecretCredential` to authenticate with the search service. First, import the [Azure.Identity](https://www.nuget.org/packages/Azure.Identity/) library to use `ClientSecretCredential`.

-1. You'll need to provide the following strings:

- + The tenant (or directory) ID. This can be retrieved from the overview page of your app registration.

- + The client (or application) ID. This can be retrieved from the overview page of your app registration.

- + The value of the client secret that you copied in a preview step.

- ```csharp

- var tokenCredential = new ClientSecretCredential(aadTenantId, aadClientId, aadSecret);

- SearchIndexClient adminClient = new SearchIndexClient(serviceEndpoint, tokenCredential);

- ```

-The Azure.Identity documentation also has additional details on using [Azure AD authentication with the Azure SDK for .NET](/dotnet/api/overview/azure/identity-readme).

-Search is foundational to any app that surfaces text content to users, with common scenarios including catalog or document search, online retail, or data exploration over proprietary content. When you create a search service, you'll work with the following capabilities:

-+ A search engine for full text search over a search index containing your user-owned content

-+ Rich indexing, with [text analysis](search-analyzers.md) and [optional AI enrichment](cognitive-search-concept-intro.md) for content extraction and transformation

-+ Rich query syntax that supplements free text search with filters, autocomplete, regex, geo-search and more

-+ Programmability through REST APIs and client libraries in Azure SDKs for .NET, Python, Java, and JavaScript

-+ [**Indexing**](search-what-is-an-index.md) is an intake process that loads content into to your search service and makes it searchable. Internally, inbound text is processed into tokens and stored in inverted indexes for fast scans. You can upload any text that is in the form of JSON documents.

- Additionally, if your content includes mixed files, you have the option of adding *AI enrichment* through [cognitive skills](cognitive-search-working-with-skillsets.md). AI enrichment can extract text embedded in application files, and also infer text and structure from non-text files by analyzing the content.

- The skills providing the analysis are predefined ones from Microsoft, or custom skills that you create. The subsequent analysis and transformations can result in new information and structures that didn't previously exist, providing high utility for many search and knowledge mining scenarios.

-+ [**Querying**](search-query-overview.md) can happen once an index is populated with searchable text, when your client app sends query requests to a search service and handles responses. All query execution is over a search index that you create, own, and store in your service. In your client app, the search experience is defined using APIs from Azure Cognitive Search, and can include relevance tuning, autocomplete, synonym matching, fuzzy matching, pattern matching, filter, and sort.

-Functionality is exposed through simple [REST APIs](/rest/api/searchservice/), or Azure SDKs like the [Azure SDK for .NET](search-howto-dotnet-sdk.md), that mask the inherent complexity of information retrieval. You can also use the Azure portal for service administration and content management, with tools for prototyping and querying your indexes and skillsets. Because the service runs in the cloud, infrastructure and availability are managed by Microsoft.

-+ Transform large undifferentiated text or image files, or application files stored in Azure Blob Storage or Cosmos DB, into searchable JSON documents. This is achieved during indexing through [cognitive skills](cognitive-search-concept-intro.md) that add external processing.

-This article provides the details of the root and subordinate Certificate Authorities (CAs) utilized by Azure. The minimum requirements for public key encryption and signature algorithms as well as links to certificate downloads and revocation lists are provided below the CA details tables.

-* Node 2: NodeColor=Green

-7. If a vCenter server manages the VMs to which you'll fail back, make sure that you have the required permissions. If you perform a read-only user vCenter discovery and protect virtual machines, protection succeeds, and failover works. However, during reprotection, failover fails because the datastores can't be discovered, and aren't listed during reprotection. To resolve this problem, you can update the vCenter credentials with an [appropriate account/permissions](vmware-azure-tutorial-prepare-on-premises.md#prepare-an-account-for-automatic-discovery), and then retry the job.

-9. If you're failing back to an alternate vCenter Server, make sure that the new vCenter Server and the master target server are discovered. Typically if they're not the datastores aren't accessible, or aren't visible in **Reprotect**.

-1. Select **Vault** > **Replicated items**. Right-click the virtual machine that failed over, and then select **Re-Protect**. Or, from the command buttons, select the machine, and then select **Re-Protect**.

-2. Verify that the **Azure to On-premises** direction of protection is selected.

-3. In **Master Target Server** and **Process Server**, select the on-premises master target server and the process server.

-4. For **Datastore**, select the datastore to which you want to recover the disks on-premises. This option is used when the on-premises virtual machine is deleted, and you need to create new disks. This option is ignored if the disks already exist. You still need to specify a value.

-When using SFTP, you may want to limit public access through configuration of a firewall, virtual network, or private endpoint. These settings are enforced at the application layer, which means they are not specific to SFTP and will impact connectivity to all Azure Storage Endpoints. For more information on firewalls and network configuration, see [Configure Azure Storage firewalls and virtual networks](../common/storage-network-security.md).

-Blob soft delete is enabled by default for a new storage account. You can enable or disable soft delete for a storage account at any time by using the Azure portal, PowerShell, or Azure CLI.

-To enable blob soft delete for your storage account by using the Azure portal, follow these steps:

-To enable blob soft delete with PowerShell, call the [Enable-AzStorageBlobDeleteRetentionPolicy](/powershell/module/az.storage/enable-azstorageblobdeleteretentionpolicy) command, specifying the retention period in days.

-To enable blob soft delete with Azure CLI, call the [az storage account blob-service-properties update](/cli/azure/storage/account/blob-service-properties#az-storage-account-blob-service-properties-update) command, specifying the retention period in days.

-* **Azure Orbital analytics with Synapse Analytics** - We now offer an [Azure Orbital analytics sample solution](https://github.com/Azure/Azure-Orbital-Analytics-Samples) showing an end-to-end implementation of extracting, loading, transforming, and analyzing spaceborne data by using geospatial libraries and AI models with [Azure Synapse Analytics](overview-what-is.md). The sample solution also demonstrates how to integrate geospatial-specific [Azure Cognitive Services](/cognitive-services/) models, AI models from partners, and bring-your-own-data models.

-* **Web Explorer dashboards drill through capabilities** - You can now add drill through capabilities to your Synapse Web Explorer dashboards. The new drill through capabilities allow you to easily jump back and forth between dashboard pages. This is made possible by using a contextual filter to connect your dashboards. Defining these contextual drill throughs is done by editing the visual interactions of the selected tile in your dashboard. To learn more about drill through capabilities, read [Use drillthroughs as dashboard parameters](/data-explorer/dashboard-parameters.md#use-drillthroughs-as-dashboard-parameters).

-* **Time Zone settings for Web Explorer** - Being able to display data in different time zones is very powerful. You can now decide to view the data in UTC time, your local time zone, or the time zone of the monitored device/machine. The Time Zone settings of the Web Explorer now apply to both the Query results and to the Dashboard. By changing the time zone, the dashboards will be automatically refreshed to present the data with the selected time zone. For more information on time zone settings, read [Change datetime to specific time zone](/data-explorer/web-query-data.md#change-datetime-to-specific-time-zone).

-](./concepts-json-flattening-escaping-rules#how-to-know-if-my-array-of-objects-will-produce-multiple-events).

-](./concepts-json-flattening-escaping-rules#how-to-know-if-my-array-of-objects-will-produce-multiple-events).

-| `*.wvd.microsoft.us` | 443 | Service traffic | All |

-> [!IMPORTANT]

-> If Azure AD is being used to enforce upload restrictions, you must use the Azure PowerShell module's [Add-AzVHD command](../windows/disks-upload-vhd-to-managed-disk-powershell.md#secure-uploads-with-azure-ad-preview) to upload a disk. Azure CLI doesn't currently support uploading a disk if Azure AD is being used to enforce upload restrictions.

-If you're using [Azure Active Directory (Azure AD)](../../active-directory/fundamentals/active-directory-whatis.md) to control resource access, you can now use it to restrict uploading of Azure managed disks. This feature is currently in preview. When a user attempts to upload a disk, Azure validates the identity of the requesting user in Azure AD, and confirms that user has the required permissions. At a higher level, a system administrator could set a policy at the Azure account or subscription level, to ensure that all disks and snapshots must use Azure AD for uploading.

-# Create and deploy VM Applications (preview)

-> **VM applications in Azure Compute Gallery** are currently in public preview.

-> This preview version is provided without a service-level agreement, and we don't recommend it for production workloads. Certain features might not be supported or might have constrained capabilities.

-> For more information, see [Supplemental Terms of Use for Microsoft Azure Previews](https://azure.microsoft.com/support/legal/preview-supplemental-terms/).

- -GalleryApplicationName $applicationname `

- -GalleryName $galleryname `

- -ResourceGroupName $rgname

-Add-AzVmGalleryApplication -VM $vm -GalleryApplication $app

-Update-AzVM -ResourceGroupName $rgname -VM $vm

-Get-AzVM -ResourceGroupName $rgname -VMName $vmname -Status

- "configurationReference": "{path to configuration storage blob}"

- "configurationReference": "{path to configuration storage blob}"

-# VM Applications overview (preview)

-> **VM applications in Azure Compute Gallery** are currently in public preview.

-> This preview version is provided without a service-level agreement, and we don't recommend it for production workloads. Certain features might not be supported or might have constrained capabilities.

-> For more information, see [Supplemental Terms of Use for Microsoft Azure Previews](https://azure.microsoft.com/support/legal/preview-supplemental-terms/).

-During the preview, when the application file gets downloaded to the VM, the file name is the same as the name you use when you create the VM application. For example, if I name my VM application `myApp`, the file that will be downloaded to the VM will also be named `myApp`, regardless of what the file name is used in the storage account. If your VM application also has a configuration file, that file is the name of the application with `_config` appended. If `myApp` has a configuration file, it will be named `myApp_config`.

-The install, update, and remove commands must be written with file naming in mind.

-## Troubleshooting during preview

-During the preview, the VM application extension always returns a success regardless of whether any VM app failed while being installed/updated/removed. The VM Application extension will only report the extension status as failure when there's a problem with the extension or the underlying infrastructure. To know whether a particular VM application was successfully added to the VM instance, check the message of the VM Application extension.

-Get-AzVmss -name <VMSS name> -ResourceGroupName <resource group name> -Status | convertto-json -Depth 10

-If you're using [Azure Active Directory (Azure AD)](../../active-directory/fundamentals/active-directory-whatis.md) to control resource access, you can now use it to restrict uploading of Azure managed disks. This feature is currently in preview. When a user attempts to upload a disk, Azure validates the identity of the requesting user in Azure AD, and confirms that user has the required permissions. At a higher level, a system administrator could set a policy at the Azure account or subscription level, to ensure that all disks and snapshots must use Azure AD for uploading. If you have any questions on securing uploads with Azure AD, reach out to this email: azuredisks@microsoft .com

- > [!IMPORTANT]

-> If Azure AD is being used to enforce upload restrictions, you must use Add-AzVHD to upload a disk. The manual upload process isn't currently supported.

-> If you're using Auzre AD to enforce upload restrictions, add `DataAccessAuthMode 'AzureActiveDirectory'` to the end of your `Add-AzVhd` command.

-* Use [Azure Site Recovery](../../../site-recovery/site-recovery-overview.md) to orchestrate and manage disaster recovery for your Oracle Linux VMs in Azure and your physical servers.

-[Azure Application Gateway](../../../application-gateway/how-application-gateway-works.md) handles public [internet-based](../../../application-gateway/configuration-front-end-ip.md) and/or [internal private](../../../application-gateway/configuration-front-end-ip.md) http routing and [encrypted tunneling across Azure subscriptions](../../../application-gateway/private-link.md), [security](../../../application-gateway/features.md), and [auto-scaling](../../../application-gateway/application-gateway-autoscaling-zone-redundant.md) for instance. Workloads in other virtual networks (VNet) or even Azure Subscriptions that shall communicate with SAP through the app gateway can be connected via [private links](../../../application-gateway/private-link-configure.md). Azure Application Gateway is focused on exposing web applications, hence offers a Web Application Firewall.

-classic

-## Associate of dissociate WAF policies