-| Default page | Description | Content definition ID<br/>(custom policy only) |

-| [exception.html](https://login.microsoftonline.com/static/tenant/default/exception.cshtml) | **Error page**. This page is displayed when an exception or an error is encountered. | *api.error* |

-| [selfasserted.html](https://login.microsoftonline.com/static/tenant/default/selfAsserted.cshtml) | **Self-Asserted page**. Use this file as a custom page content for a social account sign-up page, a local account sign-up page, a local account sign-in page, password reset, and more. The form can contain various input controls, such as: a text input box, a password entry box, a radio button, single-select drop-down boxes, and multi-select check boxes. | *api.localaccountsignin*, *api.localaccountsignup*, *api.localaccountpasswordreset*, *api.selfasserted* |

-| [multifactor-1.0.0.html](https://login.microsoftonline.com/static/tenant/default/multifactor-1.0.0.cshtml) | **Multi-factor authentication page**. On this page, users can verify their phone numbers (by using text or voice) during sign-up or sign-in. | *api.phonefactor* |

-| [updateprofile.html](https://login.microsoftonline.com/static/tenant/default/updateProfile.cshtml) | **Profile update page**. This page contains a form that users can access to update their profile. This page is similar to the social account sign-up page, except for the password entry fields. | *api.selfasserted.profileupdate* |

-| [unified.html](https://login.microsoftonline.com/static/tenant/default/unified.cshtml) | **Unified sign-up or sign-in page**. This page handles the user sign-up and sign-in process. Users can use enterprise identity providers, social identity providers such as Facebook or Google+, or local accounts. | *api.signuporsignin* |

-#### Single-template approach

-Learn how to enable [client-side JavaScript code](javascript-and-page-layout.md).

-Requiring multi-factor authentication (MFA) for the administrators in your tenant is one of the first steps you can take to increase the security of your tenant. In this article, we'll cover how to make sure all of your administrators are covered by multi-factor authentication.

- 

-## Enforce multi-factor authentication on your administrators

-Based on gaps you found, require administrators to use multi-factor authentication in one of the following ways:

-After your admins are enforced for multi-factor authentication and have been using it for a while, it is time to raise the bar on strong authentication and use Passwordless and phishing resistant authentication method:

-## Known issues

-> Windows Hello for Business requires additional configuration to enable on-premises SSO from an Azure AD joined device. For more information, see [Configure Azure AD joined devices for On-premises Single-Sign On using Windows Hello for Business](/windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso-base).

-> FIDO2 security key based passwordless authentication with Windows 10 or newer requires additional configuration to enable on-premises SSO from an Azure AD joined device. For more information, see [Enable passwordless security key sign-in to on-premises resources with Azure Active Directory](../authentication/howto-authentication-passwordless-security-key-on-premises.md).

- - `curl https://login.microsoftonline.com/ -D -`

- - `curl https://login.microsoftonline.com/<TenantID>/ -D -`

- - `curl https://enterpriseregistration.windows.net/ -D -`

- - `curl https://device.login.microsoftonline.com/ -D -`

- - `curl https://pas.windows.net/ -D -`

-Get-MgAuditLogSignIn `

-group ResourceTenantId,AppDisplayName,UserPrincipalName| `

-select count, @{n=ΓÇÖExt TenantID/App User PairΓÇÖ;e={$_.name}}]

-With Azure AD B2C, customers can sign in with an identity they've already established (like Facebook or Gmail). With Azure AD B2C, you can completely customize and control how customers sign up, sign in, and manage their profiles when using your applications. For more information, see the Azure AD B2C documentation.

-Learn more about [Azure AD B2C](../../active-directory-b2c/index.yml).

-3. Ensure that **Require approval** is set to **Yes**.

-5. Under the **Admin Credentials** section, input the **SCIM 2.0 base URL and Access Token** values retrieved earlier from Smartsheet in **Tenant URL** and **Secret Token** respectively.. Click **Test Connection** to ensure Azure AD can connect to Smartsheet. If the connection fails, ensure your Smartsheet account has SysAdmin permissions and try again.

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

- "claim": "$.vc.credentialSubject.firstName",

- ],

-To see the Azure Vote app in action, open a web browser to the external IP address of you

-[byo-vnet-kubenet]: configure-kubenet.md

-az aks create --resource-group myResourceGroup --name myAKSCluster--node-count 1

-## Add Dedicated Hosts to the Host Group

-

-A revision can be taken offline, which makes it inaccessible to callers even if they try to access the revision through its URL. You can mark a revision as offline using the Azure portal. If you use PowerShell, you can use the `Set-AzApiManagementApiRevision` cmdlet and set the `Path` argument to `$null`.

-> [!NOTE]

-> We suggest taking revisions offline when you aren't using them for testing.

-Rename the exported module classes by replacing the `Widget` prefix with `ConferenceSession` in these files:

- var model = new ConferenceSessionModel();

-This article provides a reference for a new API Management policy to validate and authorize requests to a [GraphQL API](graphql-api.md) imported to API Management.

-**Authorization elements**

-You can use multiple authorization elements. The most specific path is used to select the appropriate authorization rule for each leaf node in the query.

-* Each authorization can optionally provide a different action.

-* `if` clauses allow the admin to specify conditional actions.

-<validate-graphql-request error-variable-name="variable name" max-size="size in bytes" max-depth="query depth">

- <authorize-path="query path, for example: /Query/list Users or /__*" action="allow|remove|reject" />

- <if condition="policy expression" action="allow|remove|reject" />

-### Example

-In the following example, we validate a GraphQL query and reject:

-* Requests larger than 100 kb or with query depth greater than 4.

-* Access to the introspection system and the `list Users` query.

- <authorize path="/" action="allow" />

- <authorize path="/__*" action="reject" />

- <authorize path="/Query/list Users" action="reject" />

-| `authorize` | Add one or more of these elements to provides field-level authorization with both request- and field-level errors. | Yes |

-| `if` | Add one or more of these elements for conditional changes to the action for a field-level authorization. | No |

-| `path` | Query path to execute authorization validation on. | Yes | N/A |

-| `action` | [Action](#request-actions) to perform for the matching field. May be changed if a matching condition is specified. | Yes | N/A |

-| `condition` | Boolean value that determines if the [policy expression](api-management-policy-expressions.md) matches. The first matching condition is used. | No | N/A |

-|`reject` | A request error happens, and the request is not sent to the back end. |

-Use validation policies to validate API requests and responses against an OpenAPI schema and protect from vulnerabilities such as injection of headers or payload. While not a replacement for a Web Application Firewall, validation policies provide flexibility to respond to another class of threats that are not covered by security products that rely on static, predefined rules.

-Each validation policy includes an attribute that specifies an action, which API Management takes when validating an entity in an API request or response against the API schema. An action may be specified for elements that are represented in the API schema and, depending on the policy, for elements that aren't represented in the API schema. An action specified in a policy's child element overrides an action specified for its parent.

-The `validate-content` policy validates the size or JSON schema of a request or response body against the API schema. Formats other than JSON aren't supported.

-<validate-content unspecified-content-type-action="ignore|prevent|detect" max-size="size in bytes" size-exceeded-action="ignore|prevent|detect" errors-variable-name="variable name">

- <content type="content type string, for example: application/json, application/hal+json" validate-as="json" action="ignore|prevent|detect" />

-### Example

-In the following example, the JSON payload in requests and responses is validated in detection mode. Messages with payloads larger than 100 KB are blocked.

- <content type="application/hal+json" validate-as="json" action="detect" />

-| `content` | Add one or more of these elements to validate the content type in the request or response, and perform the specified action. | No |

-| `unspecified-content-type-action` | [Action](#actions) to perform for requests or responses with a content type that isnΓÇÖt specified in the API schema. | Yes | N/A |

-| `max-size` | Maximum length of the body of the request or response in bytes, checked against the `Content-Length` header. If the request body or response body is compressed, this value is the decompressed length. Maximum allowed value: 102,400 bytes (100 KB). (Contact [support](https://azure.microsoft.com/support/options/) if you need to increase this limit.) | Yes | N/A |

-| `size-exceeded-action` | [Action](#actions) to perform for requests or responses whose body exceeds the size specified in `max-size`. | Yes | N/A |

-| `errors-variable-name` | Name of the variable in `context.Variables` to log validation errors to. | No | N/A |

-| `type` | Content type to execute body validation for, checked against the `Content-Type` header. This value is case insensitive. If empty, it applies to every content type specified in the API schema. | No | N/A |

-| `validate-as` | Validation engine to use for validation of the body of a request or response with a matching content type. Currently, the only supported value is "json". | Yes | N/A |

-| `action` | [Action](#actions) to perform for requests or responses whose body doesn't match the specified content type. | Yes | N/A |

-| `unspecified-parameter-action` | [Action](#actions) to perform for request parameters that are not specified in the API schema. <br/><br/>When provided in a `headers`or `query` element, the value overrides the value of `unspecified-parameter-action` in the `validate-parameters` element. | Yes | N/A |

-| `unspecified-header-action` | [Action](#actions) to perform for response headers that are not specified in the API schema. | Yes | N/A |

-| `unspecified-status-code-action` | [Action](#actions) to perform for HTTP status codes in responses that are not specified in the API schema. | Yes | N/A |

-| `action` | [Action](#actions) to perform for the matching status code, which is not specified in the API schema. If the status code is specified in the API schema, this override does not take effect. | Yes | N/A |

-description: Overview on the App Service Environment

-The Azure App Service Environment is an Azure App Service feature that provides a fully isolated and dedicated environment for securely running App Service apps at high scale. This capability can host your:

-> [!NOTE]

-> This article is about the App Service Environment v3 which is used with Isolated v2 App Service plans

->

-App Service Environment host applications from only one customer and do so in one of their virtual networks. Customers have fine-grained control over inbound and outbound application network traffic. Applications can establish high-speed secure connections over VPNs to on-premises corporate resources.

-The App Service Environment has many use cases including:

-There are many networking features that enable apps in the multi-tenant App Service to reach network isolated resources or become network isolated themselves. These features are enabled at the application level. With an App Service Environment, there's no added configuration required for the apps to be in the virtual network. The apps are deployed into a network-isolated environment that is already in a virtual network. If you really need a complete isolation story, you can also get your App Service Environment deployed onto dedicated hardware.

-The App Service Environment is a single tenant deployment of the Azure App Service that runs in your virtual network.

-Applications are hosted in App Service plans, which are created in an App Service Environment. The App Service plan is essentially a provisioning profile for an application host. As you scale your App Service plan out, you create more application hosts with all of the apps in that App Service plan on each host. A single App Service Environment v3 can have up to 200 total App Service plan instances across all of the App Service plans combined. A single Isolated v2 App Service plan can have up to 100 instances by itself.

-When you're deploying on dedicated hardware (hosts), you're limited in scaling across all App Service plans to the amount of cores in this type of environment. An App Service Environment deployed on dedicated hosts has 132 vCores available. I1v2 uses 2 vCores, I2v2 uses 4 vCores, and I3v2 uses 8 vCores per instance.

-The App Service Environment feature is a deployment of the Azure App Service into a single subnet in a customer's virtual network. When you deploy an app into an App Service Environment, the app will be exposed on the inbound address assigned to the App Service Environment. If your App Service Environment is deployed with an internal virtual IP (VIP), then the inbound address for all of the apps will be an address in the App Service Environment subnet. If your App Service Environment is deployed with an external VIP, then the inbound address will be an internet-addressable address and your apps will be in public DNS.

-The number of addresses used by an App Service Environment v3 in its subnet will vary based on how many instances you have along with how much traffic. There are infrastructure roles that are automatically scaled depending on the number of App Service plans and the load. The recommended size for your App Service Environment v3 subnet is a `/24` CIDR block with 256 addresses in it as that can host an App Service Environment v3 scaled out to its limit.

-The apps in an App Service Environment don't need any features enabled to access resources in the same virtual network that the App Service Environment is in. If the App Service Environment virtual network is connected to another network, then the apps in the App Service Environment can access resources in those extended networks. Traffic can be blocked by user configuration on the network.

-The multi-tenant version of Azure App Service contains numerous features to enable your apps to connect to your various networks. Those networking features enable your apps to act as if they were deployed in a virtual network. The apps in an App Service Environment v3 don't need any configuration to be in the virtual network. A benefit of using an App Service Environment over the multi-tenant service is that any network access controls to the App Service Environment hosted apps is external to the application configuration. With the apps in the multi-tenant service, you must enable the features on an app-by-app basis and use Role-based access control or policy to prevent any configuration changes.

-Compared to earlier versions of the App Service Environment, there are some differences with App Service Environment v3:

-There are a few features that are not available in App Service Environment v3 that were available in earlier versions of the App Service Environment. In App Service Environment v3, you can't:

-With App Service Environment v3, there is a different pricing model depending on the type of App Service Environment deployment you have. The three pricing models are:

-Reserved Instance pricing for Isolated v2 is available and is described in [How reservation discounts apply to Azure App Service](../../cost-management-billing/reservations/reservation-discount-app-service.md). The pricing, along with reserved instance pricing, is available at [App Service pricing](https://azure.microsoft.com/pricing/details/app-service/windows/) under **Isolated v2 plan**.

-The App Service Environment v3 is available in the following regions.

-App Service Environment has three versions: App Service Environment v1, App Service Environment v2, and App Service Environment v3. The preceding information was based on App Service Environment v3. To learn more about App Service Environment v2, see [App Service Environment v2 introduction](./intro.md).

-> Visual Studio Code is cross-platform, however; .NET Framework is not. If you're developing .NET Framework apps with Visual Studio Code, consider using a Windows machine to satisfy the build dependencies.

-1. In **Create a new project**, find, and choose **ASP.NET Core Web App**, then select **Next**.

-1. Make sure **Authentication Type** is set to **None**. Select **Create**.

-1. In **Create a new project**, find, and choose **ASP.NET Web Application (.NET Framework)**, then select **Next**.

-1. Make sure **Authentication** is set to **No Authentication**. Select **Create**.

-1. In the terminal in Visual Studio Code, create a new .NET web app using the [`dotnet new webapp`](/dotnet/core/tools/dotnet-new#web-options) command.

-1. Choose the **Specific target**, either **Azure App Service (Linux)** or **Azure App Service (Windows)**. Then, click **Next**.

- Once the wizard completes, the Azure resources are created for you and you are ready to publish your ASP.NET Core project.

-1. In the **Publish** dialog, make sure your new App Service app is selected in **App Service instance**, then select **Finish**. Visual Studio creates a publish profile for you for the selected App Service app.

-1. In the **Publish** page, select **Publish**. If you see a warning message, click **Continue**.

-1. In the popup **Always deploy the workspace "MyFirstAzureWebApp" to \<app-name>"**, select **Yes**. This way, as long as you're in the same workspace, Visual Studio Code deploys to the same App Service app each time.

- - If the `az` command isn't recognized, be sure you have the Azure CLI installed as described in [Prerequisites](#prerequisites).

- The command may take a few minutes to complete. While running, it provides messages about creating the resource group, the App Service plan, and hosting app, configuring logging, then performing ZIP deployment. It then outputs a message with the app's URL:

- - Replace `<app-name>` with a name that's unique across all of Azure (*valid characters are `a-z`, `0-9`, and `-`*). A good pattern is to use a combination of your company name and an app identifier.

- The command may take a few minutes to complete. While running, it creates a resource group, an App Service plan, and the App Service resource.

-1. Search for and select "Azure App Service: Deploy to Web App". Remember that your told Visual Studio Code to remember the app to deploy your workspace to in an earlier step.

-The custom neural (custom document) model is a deep learning model type that relies on a base model trained on a large collection of documents. This model is then fine-tuned or adapted to your data when you train the model with a labeled dataset. Custom neural models support structured, semi-structured, and unstructured documents to extract fields. Custom neural models currently support English-language documents. When choosing between the two model types, start with a neural model if it meets your functional needs. See [neural models](concept-custom-neural.md) to learn more about custom document models.

-**Table symbols**: Γ£ö ΓÇö supported; &#10033; ΓÇö preview; **n/a** ΓÇö currently unavailable

-1. On the train model dialog, provide a unique model ID and, optionally, a description.

-# Create and use managed identities with Form Recognizer

-> [!IMPORTANT]

-> Azure RBAC (Azure role-based access control) assignment is currently in preview and not recommended for production workloads. Certain features may not be supported or have constrained capabilities. Azure RBAC assignments are used to grant permissions for managed identity.

-## What is managed identity?

-Azure managed identity is a service principal. It creates an Azure Active Directory (Azure AD) identity and specific permissions for Azure managed resources. You can use a managed identity to grant access to any resource that supports Azure AD authentication. To grant access, assign a role to a managed identity using [Azure RBAC](../../role-based-access-control/overview.md) (Azure role-based access control). There's no added cost to use managed identity in Azure.

-Managed identity supports both privately and publicly accessible Azure blob storage accounts. For storage accounts with public access, you can opt to use a shared access signature (SAS) to grant limited access. In this article, you'll learn to enable a system-assigned managed identity for your Form Recognizer instance.

-## Private storage account access

-> [!NOTE]

->

-> Form Recognizer only supports system-assigned managed identities today. User-assigned managed identities is on the roadmap and will be enabled in the near future.

-* An [**Azure blob storage account**](https://portal.azure.com/#create/Microsoft.StorageAccount-ARM) in the same region as your Form Recognizer resource. You'll create containers to store and organize your blob data within your storage account.

-There are two types of managed identity: **system-assigned** and **user-assigned**. Currently, Form Recognizer is supported by system-assigned managed identity. A system-assigned managed identity is **enabled** directly on a service instance. It isn't enabled by default; you have to go to your resource and update the identity setting. The system-assigned managed identity is tied to your resource throughout its lifecycle. If you delete your resource, the managed identity will be deleted as well.

- 7. Next, you're going to assign a **Storage Blob Data Reader** role to your Form Recognizer service resource. In the **Add role assignment** pop-up window complete the fields as follows and select **Save**:

- |**Scope**| ***Storage***|

- |**Subscription**| ***The subscription associated with your storage resource***.|

- |**Resource**| ***The name of your storage resource***|

- |**Role** | ***Storage Blob Data Reader***ΓÇöallows for read access to Azure Storage blob containers and data.|

- That's it! You've completed the steps to enable a system-assigned managed identity. With this identity credential, you can grant Form Recognizer-specific access rights to documents and files stored in your BYOS account.

-> [Managed identities for Azure resources: frequently asked questions - Azure AD](../../active-directory/managed-identities-azure-resources/managed-identities-faq.md)

-* To learn how to configure your runbooks to automate processes in your on-premises datacenter or other cloud environment, see [Run runbooks on a Hybrid Runbook Worker](automation-hrw-run-runbooks.md).

-* To learn how to troubleshoot your Hybrid Runbook Workers, see [Troubleshoot Hybrid Runbook Worker issues](troubleshoot/extension-based-hybrid-runbook-worker.md).

-General availability of Azure Arc-enabled Kubernetes includes GitOps with Flux v1. The public preview of GitOps with Flux v2, documented here, is available in both Azure Arc-enabled Kubernetes and AKS. Flux v2 is the way forward, and Flux v1 will eventually be deprecated.

- ```azurecli

- ```azurecli

- ```azurecli

- ```azurecli

- ```

- ```output

-```azurecli

-```azurecli

-```azurecli

-```

-```output

-```azurecli

-```

-```output

-```azurecli

-```

-```output

-```azurecli

-```azurecli

-```azurecli

-```azurecli

-```

-```output

-```azurecli

-```

-```output

-```azurecli

->If you need Flux to access the source through your proxy, you'll need to update the Azure Arc agents with the proxy settings. For more information, see [Connect using an outbound proxy server](./quickstart-connect-cluster.md?tabs=azure-cli#connect-using-an-outbound-proxy-server).

-```azurecli

-```

-```output

-```azurecli

-```

-```output

-```azurecli

-> The Linux hostname or Windows computer name cannot use one of the reserved words or trademarks in the name, otherwise attempting to register the connected machine with Azure will fail. See [Resolve reserved resource name errors](../../azure-resource-manager/templates/error-reserved-resource-name.md) for a list of the reserved words.

-> While Azure Arc-enabled servers supports Amazon Linux, the following do not support this distro:

-If they are not registered, you can register them using the following commands:

-You can also register the resource providers in the Azure portal by following the steps under [Azure portal](../../azure-resource-manager/management/resource-providers-and-types.md#azure-portal).

-For a list of IP addresses for each service tag/region, see the JSON file - [Azure IP Ranges and Service Tags ΓÇô Public Cloud](https://www.microsoft.com/download/details.aspx?id=56519). Microsoft publishes weekly updates containing each Azure Service and the IP ranges it uses. This information in the JSON file is the current point-in-time list of the IP ranges that correspond to each service tag. The IP addresses are subject to change. If IP address ranges are required for your firewall configuration, then the **AzureCloud** Service Tag should be used to allow access to all Azure services. Do not disable security monitoring or inspection of these URLs, allow them as you would other Internet traffic.

-For more information, review [Service tags overview](../../virtual-network/service-tags-overview.md).

-Connecting machines in your hybrid environment directly with Azure can be accomplished using different methods depending on your requirements. The following table highlights each method to determine which works best for your organization.

-> [!IMPORTANT]

-> The Connected Machine agent cannot be installed on an Azure Windows virtual machine. If you attempt to, the installation detects this and rolls back.

-| Interactively | Manually install the agent on a single or small number of machines following the steps in [Connect machines from Azure portal](onboard-portal.md).<br> From the Azure portal, you can generate a script and execute it on the machine to automate the install and configuration steps of the agent.|

-| At scale | Install and configure the agent for multiple machines following the [Connect machines using a Service Principal](onboard-service-principal.md).<br> This method creates a service principal to connect machines non-interactively.|

-| At scale | Install and configure the agent for multiple machines following the method [Connect hybrid machines to Azure from Automation Update Management](onboard-update-management-machines.md).<br> This method creates a service principal, and installs and configures the agent for multiple machines managed with Azure Automation Update Management to connect machines non-interactively. |

-| At scale | Install and configure the agent for multiple machines following the method [Using Windows PowerShell DSC](onboard-dsc.md).<br> This method uses a service principal to connect machines non-interactively with PowerShell DSC. |

-* Double-click the file `AzureConnectedMachineAgent.msi`.

-> To create a service principal and assign roles, your account must be a member of the **Owner** or **User Access Administrator** role in the subscription that you want to use for onboarding.

-| Download the pre-defined installation script | Review and customize the pre-defined installation script for at-scale deployment of the Connected Machine agent to support your automated deployment requirements.<br><br> Sample at-scale onboarding resources:<br><br> <ul><li> [At-scale basic deployment script](onboard-service-principal.md)</ul></li> <ul><li>[At-scale onboarding VMware vSphere Windows Server VMs](https://github.com/microsoft/azure_arc/blob/main/docs/azure_arc_jumpstart/azure_arc_servers/scaled_deployment/vmware_scaled_powercli_win/_index.md)</ul></li> <ul><li>[At-scale onboarding VMware vSphere Linux VMs](https://github.com/microsoft/azure_arc/blob/main/docs/azure_arc_jumpstart/azure_arc_servers/scaled_deployment/vmware_scaled_powercli_linux/_index.md)</ul></li> <ul><li>[At-scale onboarding AWS EC2 instances using Ansible](https://github.com/microsoft/azure_arc/blob/main/docs/azure_arc_jumpstart/azure_arc_servers/scaled_deployment/aws_scaled_ansible/_index.md)</ul></li> <ul><li>[At-scale deployment using PowerShell remoting](./onboard-powershell.md) (Windows only)</ul></li>| One or more days depending on requirements, organizational processes (for example, Change and Release Management), and automation method used. |

-app=FastAPI("Test")

-@app.route("/api/HandleApproach")

-def test():

- return "Hello!"

-def main(req: func.HttpRequest, context) -> func.HttpResponse:

- logging.info('Python HTTP trigger function processed a request.')

- return func.AsgiMiddleware(app).handle(req, context)

-@app.route("/api/WrapperApproach")

-def test():

- return "Hello!"

-Azure Event Grid is a fully managed event routing service, which uses a publish-subscribe model. Event Grid has built-in support for Azure services like [Azure Functions](../azure-functions/functions-overview.md) and [Azure Logic Apps](../azure-functions/functions-overview.md). It can deliver event alerts to non-Azure services using webhooks. For a complete list of the event handlers that Event Grid supports, see [An introduction to Azure Event Grid](../event-grid/overview.md).

-Event grid uses [event subscriptions](../event-grid/concepts.md#event-subscriptions) to route event messages to subscribers. An Azure Maps account emits the following event types:

-> [Set up a geofence by using Azure Maps](tutorial-geofence.md)

-1. [Create an Azure Maps account](quick-demo-map-app.md#create-an-azure-maps-account).

-2. [Obtain a primary subscription key](quick-demo-map-app.md#get-the-primary-key-for-your-account), also known as the primary key or the subscription key.

-This tutorial uses the [Postman](https://www.postman.com/) application, but you can use a different API development environment.

-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)](data-collection-rule-overview.md) which provide a more scalable method of configuring data collection and destinations for each agent.

-The Azure Monitor agent uses [data collection rules](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).

-| [Connect using private links](data-collection-endpoint-overview.md#enable-network-isolation-for-the-azure-monitor-agent) | Public preview | No sign-up needed |

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

-1. Use this flowchart to determine the values of the *setting* and *protectedSetting* parameters first.

- 

-2. After the values for the *setting* and *protectedSetting* parameters are determined, provide these additional parameters when you deploy the Azure Monitor agent by using PowerShell commands. The following examples are for Azure virtual machines.

- | Setting | A JSON object from the preceding flowchart converted to a string. Skip if not applicable. An example is {"proxy":{"mode":"application","address":"http://[address]:[port]","auth": false}}. |

- | ProtectedSetting | A JSON object from the preceding flowchart converted to a string. Skip if not applicable. An example is {"proxy":{"username": "[username]","password": "[password]"}}. |

-Set-AzVMExtension -ExtensionName AzureMonitorWindowsAgent -ExtensionType AzureMonitorWindowsAgent -Publisher Microsoft.Azure.Monitor -ResourceGroupName <resource-group-name> -VMName <virtual-machine-name> -Location <location> -TypeHandlerVersion 1.0 -Setting <settingString> -ProtectedSetting <protectedSettingString>

-Set-AzVMExtension -ExtensionName AzureMonitorLinuxAgent -ExtensionType AzureMonitorLinuxAgent -Publisher Microsoft.Azure.Monitor -ResourceGroupName <resource-group-name> -VMName <virtual-machine-name> -Location <location> -TypeHandlerVersion 1.5 -Setting <settingString> -ProtectedSetting <protectedSettingString>

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

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

-### Log Analytics gateway configuration

-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 allow list for the gateway

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

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

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

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

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

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

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

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

-### Private link configuration

-To configure the agent to use private links for network communications with Azure Monitor, you can use [Azure Monitor Private Links Scopes (AMPLS)](../logs/private-link-security.md) and [data collection endpoints](./data-collection-endpoint-overview.md) to enable required network isolation. [View steps to configure network isolation for the agent](./data-collection-endpoint-overview.md#enable-network-isolation-for-the-azure-monitor-agent)

-For a complete description of data collection rules, see [Data collection rules in Azure Monitor](data-collection-rule-overview.md).

-## Permissions required to create data collection rules and associations

-When using programmatic methods to create data collection rules and associations (i.e. mehtods other than Azure portal), you require the below permissions:

-| Built-in Role | Scope(s) | Reason |

-|:|:|:|

-| [Monitoring Contributor](../../role-based-access-control/built-in-roles.md#monitoring-contributor) | <ul><li>Subscription and/or</li><li>Resource group and/or </li><li>An existing data collection rule</li></ul> | To create or edit data collection rules |

-| <ul><li>[Virtual Machine Contributor](../../role-based-access-control/built-in-roles.md#virtual-machine-contributor)</li><li>[Azure Connected Machine Resource Administrator](../../role-based-access-control/built-in-roles.md#azure-connected-machine-resource-administrator)</li></ul> | <ul><li>Virtual machines, virtual machine scale sets</li><li>Arc-enabled servers</li></ul> | To deploy associations (i.e. to assign rules to the machine) |

-| Any role that includes the action *Microsoft.Resources/deployments/** | <ul><li>Subscription and/or</li><li>Resource group and/or </li><li>An existing data collection rule</li></ul> | To deploy ARM templates |

-If you need network isolation using private links for collecting data using agents from your resources, simply select existing endpoints (or create a new endpoint) from the same region for the respective resource(s) as shown below. See [how to create data collection endpoint](./data-collection-endpoint-overview.md).

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

-1. Manually create the DCR file using the JSON format shown in [Sample DCR](data-collection-rule-overview.md#sample-data-collection-rule).

-description: Overview of data collection rules (DCRs) in Azure Monitor including their contents and structure and how you can create and work with them.

-# Data collection rules in Azure Monitor

-Data Collection Rules (DCR) define data coming into Azure Monitor and specify where that data should be sent or stored. This article provides an overview of data collection rules including their contents and structure and how you can create and work with them.

-## Input sources

-Data collection rules currently support the following input sources:

-## Components of a data collection rule

-A data collection rule includes the following components.

-| Component | Description |

-|:|:|

-| Data sources | Unique source of monitoring data with its own format and method of exposing its data. Examples of a data source include Windows event log, performance counters, and syslog. Each data source matches a particular data source type as described below. |

-| Streams | Unique handle that describes a set of data sources that will be transformed and schematized as one type. Each data source requires one or more streams, and one stream may be used by multiple data sources. All data sources in a stream share a common schema. Use multiple streams for example, when you want to send a particular data source to multiple tables in the same Log Analytics workspace. |

-| Destinations | Set of destinations where the data should be sent. Examples include Log Analytics workspace and Azure Monitor Metrics. |

-| Data flows | Definition of which streams should be sent to which destinations. |

-The following diagram shows the components of a data collection rule and their relationship

-[](media/data-collection-rule-overview/data-collection-rule-components.png#lightbox)

-### Data source types

-Each data source has a data source type. Each type defines a unique set of properties that must be specified for each data source. The data source types currently available are shown in the following table.

-| Data source type | Description |

-|:|:|

-| extension | VM extension-based data source, used exclusively by Log Analytics solutions and Azure services ([View agent supported services and solutions](./azure-monitor-agent-overview.md#supported-services-and-features)) |

-| performanceCounters | Performance counters for both Windows and Linux |

-| syslog | Syslog events on Linux |

-| windowsEventLogs | Windows event log |

-## Supported regions

-Data collection rules are stored regionally, and are available in all public regions where Log Analytics is supported, as well as the Azure Government and China clouds. Air-gapped clouds are not yet supported.

-## Limits

-For limits that apply to each data collection rule, see [Azure Monitor service limits](../service-limits.md#data-collection-rules).

-## Data resiliency and high availability

-Data Collection Rules as a service is deployed regionally. A rule gets created and stored in the region you specify, and is backed up to the [paired-region](../../availability-zones/cross-region-replication-azure.md#azure-cross-region-replication-pairings-for-all-geographies) within the same Geo.

-Additionally, the service is deployed to all 3 [availability zones](../../availability-zones/az-overview.md#availability-zones) within the region, making it a **zone-redundant service** which further adds to high availability.

-**Single region data residency**: The previewed feature to enable storing customer data in a single region is currently only available in the Southeast Asia Region (Singapore) of the Asia Pacific Geo and Brazil South (Sao Paulo State) Region of Brazil Geo. Single region residency is enabled by default in these regions.

-## Create a DCR

-You can currently use any of the following methods to create a DCR:

- - [Get-AzDataCollectionRule](https://github.com/Azure/azure-powershell/blob/master/src/Monitor/Monitor/help/Get-AzDataCollectionRule.md)

- - [New-AzDataCollectionRule](https://github.com/Azure/azure-powershell/blob/master/src/Monitor/Monitor/help/New-AzDataCollectionRule.md)

- - [Set-AzDataCollectionRule](https://github.com/Azure/azure-powershell/blob/master/src/Monitor/Monitor/help/Set-AzDataCollectionRule.md)

- - [Update-AzDataCollectionRule](https://github.com/Azure/azure-powershell/blob/master/src/Monitor/Monitor/help/Update-AzDataCollectionRule.md)

- - [Remove-AzDataCollectionRule](https://github.com/Azure/azure-powershell/blob/master/src/Monitor/Monitor/help/Remove-AzDataCollectionRule.md)

- - [Get-AzDataCollectionRuleAssociation](https://github.com/Azure/azure-powershell/blob/master/src/Monitor/Monitor/help/Get-AzDataCollectionRuleAssociation.md)

- - [New-AzDataCollectionRuleAssociation](https://github.com/Azure/azure-powershell/blob/master/src/Monitor/Monitor/help/New-AzDataCollectionRuleAssociation.md)

- - [Remove-AzDataCollectionRuleAssociation](https://github.com/Azure/azure-powershell/blob/master/src/Monitor/Monitor/help/Remove-AzDataCollectionRuleAssociation.md)

-## Sample data collection rule

-The sample data collection rule below is for virtual machines with Azure Monitor agent and has the following details:

- - Collects specific Processor, Memory, Logical Disk, and Physical Disk counters every 15 seconds and uploads every minute.

- - Collects specific Process counters every 30 seconds and uploads every 5 minutes.

- - Collects Windows security events and uploads every minute.

- - Collects Windows application and system events and uploads every 5 minutes.

- - Collects Debug, Critical, and Emergency events from cron facility.

- - Collects Alert, Critical, and Emergency events from syslog facility.

- - Sends all data to a Log Analytics workspace named centralWorkspace.

-> [!NOTE]

-> For an explanation of XPaths that are used to specify event collection in data collection rules, see [Limit data collection with custom XPath queries](data-collection-rule-azure-monitor-agent.md#limit-data-collection-with-custom-xpath-queries)

-```json

-{

- "location": "eastus",

- "properties": {

- "dataSources": {

- "performanceCounters": [

- {

- "name": "cloudTeamCoreCounters",

- "streams": [

- "Microsoft-Perf"

- ],

- "scheduledTransferPeriod": "PT1M",

- "samplingFrequencyInSeconds": 15,

- "counterSpecifiers": [

- "\\Processor(_Total)\\% Processor Time",

- "\\Memory\\Committed Bytes",

- "\\LogicalDisk(_Total)\\Free Megabytes",

- "\\PhysicalDisk(_Total)\\Avg. Disk Queue Length"

- ]

- },

- {

- "name": "appTeamExtraCounters",

- "streams": [

- "Microsoft-Perf"

- ],

- "scheduledTransferPeriod": "PT5M",

- "samplingFrequencyInSeconds": 30,

- "counterSpecifiers": [

- "\\Process(_Total)\\Thread Count"

- ]

- }

- ],

- "windowsEventLogs": [

- {

- "name": "cloudSecurityTeamEvents",

- "streams": [

- "Microsoft-Event"

- ],

- "scheduledTransferPeriod": "PT1M",

- "xPathQueries": [

- "Security!*"

- ]

- },

- {

- "name": "appTeam1AppEvents",

- "streams": [

- "Microsoft-Event"

- ],

- "scheduledTransferPeriod": "PT5M",

- "xPathQueries": [

- "System!*[System[(Level = 1 or Level = 2 or Level = 3)]]",

- "Application!*[System[(Level = 1 or Level = 2 or Level = 3)]]"

- ]

- }

- ],

- "syslog": [

- {

- "name": "cronSyslog",

- "streams": [

- "Microsoft-Syslog"

- ],

- "facilityNames": [

- "cron"

- ],

- "logLevels": [

- "Debug",

- "Critical",

- "Emergency"

- ]

- },

- {

- "name": "syslogBase",

- "streams": [

- "Microsoft-Syslog"

- ],

- "facilityNames": [

- "syslog"

- ],

- "logLevels": [

- "Alert",

- "Critical",

- "Emergency"

- ]

- }

- ]

- },

- "destinations": {

- "logAnalytics": [

- {

- "workspaceResourceId": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/my-resource-group/providers/Microsoft.OperationalInsights/workspaces/my-workspace",

- "name": "centralWorkspace"

- }

- ]

- },

- "dataFlows": [

- {

- "streams": [

- "Microsoft-Perf",

- "Microsoft-Syslog",

- "Microsoft-Event"

- ],

- "destinations": [

- "centralWorkspace"

- ]

- }

- ]

- }

- }

-```

-## Next steps

-A gateway can be multihomed to up to ten workspaces using the Azure Monitor Agent and [data dollection rules](./data-collection-rule-azure-monitor-agent.md). Using the legacy Microsoft Monitor Agent, you can only multihome up to four workspaces as that is the total number of workspaces the legacy Windows agent supports.

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

-This article includes sample [Azure Resource Manager templates](../../azure-resource-manager/templates/syntax.md) to create an association between a [data collection rule](data-collection-rule-overview.md) and the [Azure Monitor agent](./azure-monitor-agent-overview.md). Each sample includes a template file and a parameters file with sample values to provide to the template.

-Prior to the introduction of [workspace-based Application Insights resources](create-workspace-resource.md), Application Insights data was stored separate from other log data in Azure Monitor. Both are based on Azure Data Explorer and use the same Kusto Query Language (KQL). This is described in [Logs in Azure Monitor](../logs/data-platform-logs.md).

-With workspace-based Application Insights resources data is stored in a Log Analytics workspace with other monitoring data and application data. This simplifies your configuration by allowing you to more easily analyze data across multiple solutions and to leverage the capabilities of workspaces.

- "virtualPathFilter": ".*",

- "instrumentationSettings" : {

- "connectionString": "InstrumentationKey=00000000-0000-0000-0000-000000000000;IngestionEndpoint=https://xxxx.applicationinsights.azure.com/" # Application Insights connection string, create new Application Insights resource if you don't have one. https://portal.azure.com/#blade/HubsExtension/BrowseResourceBlade/resourceType/microsoft.insights%2Fcomponents

-Azure services actually require Azure Monitor to collect telemetry, and it's enabled the moment that you create an Azure subscription. The [Activity log](essentials/activity-log.md) is automatically collected for the subscription, and [platform metrics](essentials/data-platform-metrics.md) are automatically collected from any Azure resources you create. You can immediately start using [metrics explorer](essentials/metrics-getting-started.md), which is similar to performance views in the Operations console, but it provides interactive analysis and [advanced aggregations](essentials/metrics-charts.md) of data. [Create a metric alert](alerts/alerts-metric.md) to be notified when a value crosses a threshold or [add a chart to an Azure dashboard](essentials/metrics-charts.md#pinning-to-dashboards) for visibility.

-While the [Azure Active Directory logs](../active-directory/reports-monitoring/overview-reports.md) for your tenant and the [Activity log](essentials/platform-logs-overview.md) for your subscription are collected automatically, sending them to a Log Analytics workspace enables you to analyze these events with other log data using log queries in Log Analytics. This also allows you to create log query alerts which is the only way to alert on Azure Active Directory logs and provide more complex logic than Activity log alerts.

-You must create a resource in Application Insights for each application that you're going to monitor. Log data collected by Application Insights is stored in Azure Monitor Logs for a workspace-based application. Log data for classic applications is stored separate from your Log Analytics workspace as described in [Data structure](logs/data-platform-logs.md#data-structure).

-Availability tests in Application Insights are recurring tests that monitor the availability and responsiveness of your application at regular intervals from points around the world. You can create a simple ping test for free or create a sequence of web requests to simulate user transactions which has associated cost.

-## Pinning to dashboards

-After you configure a chart, you might want to add it to a dashboard. By pinning a chart to a dashboard, you can make it accessible to your team. You can also gain insights by viewing it in the context of other monitoring telemetry.

-To pin a configured chart to a dashboard, in the upper-right corner of the chart, select **Pin to dashboard**.

-

-To pin your multiple-resource chart to a dashboard, see [Pinning to dashboards](../essentials/metrics-charts.md#pinning-to-dashboards).

-1. Click on the "Select a scope" button to open the resource scope picker. This will allow you to select the resource(s) you want to see metrics for. The resource should already be populated if you opened metrics explorer from the resource's menu. To learn how to view metrics across multiple resources, [read this article](./metrics-dynamic-scope.md).

-2. For some resources, you must pick a namespace. The namespace is just a way to organize metrics so that you can easily find them. For example, storage accounts have separate namespaces for storing Files, Tables, Blobs, and Queues metrics. Many resource types only have one namespace.

-3. Select a metric from a list of available metrics.