-The provisioned throughput capability allows you to specify the amount of throughput you require in a deployment. The service then allocates the necessary model processing capacity and ensures it's ready for you. Throughput is defined in terms of provisioned throughput units (PTU) which is a normalized way of representing the throughput for your deployment. Each model-version pair requires different amounts of PTU to deploy and provide different amounts of throughput per PTU.

-> [!NOTE]

-> Provisioned throughput unit (PTU) quota is different from standard quota in Azure OpenAI and is not available by default. To learn more about this offering contact your Microsoft Account Team.

-## How do I get access to Provisioned?

-You need to speak with your Microsoft sales/account team to acquire provisioned throughput. If you don't have a sales/account team, unfortunately at this time, you cannot purchase provisioned throughput.

-### Provisioned throughput units

-Provisioned throughput units (PTU) are units of model processing capacity that you can reserve and deploy for processing prompts and generating completions. The minimum PTU deployment, increments, and processing capacity associated with each unit varies by model type & version.

-When deploying a model in Azure OpenAI, you need to set the `sku-name` to be Provisioned-Managed. The `sku-capacity` specifies the number of PTUs assigned to the deployment.

-Provisioned throughput quota represents a specific amount of total throughput you can deploy. Quota in the Azure OpenAI Service is managed at the subscription level. All Azure OpenAI resources within the subscription share this quota.

-Quota is specified in Provisioned throughput units and is specific to a (deployment type, model, region) triplet. Quota isn't interchangeable. Meaning you can't use quota for GPT-4 to deploy GPT-3.5-Turbo.

-While we make every attempt to ensure that quota is deployable, quota doesn't represent a guarantee that the underlying capacity is available. The service assigns capacity during the deployment operation and if capacity is unavailable the deployment fails with an out of capacity error.

-PTUs represent an amount of model processing capacity. Similar to your computer or databases, different workloads or requests to the model will consume different amounts of underlying processing capacity. The conversion from call shape characteristics (prompt size, generation size and call rate) to PTUs is complex and non-linear. To simplify this process, you can use the [Azure OpenAI Capacity calculator](https://oai.azure.com/portal/calculator) to size specific workload shapes.

-In the Provisioned-Managed offering, each request is evaluated individually according to its prompt size, expected generation size, and model to determine its expected utilization. This is in contrast to pay-as-you-go deployments which have a [custom rate limiting behavior](../how-to/quota.md) based on the estimated traffic load. For pay-as-you-go deployments this can lead to HTTP 429s being generated prior to defined quota values being exceeded if traffic is not evenly distributed.

-> Calls are accepted until utilization reaches 100%. Bursts just over 100% maybe permitted in short periods, but over time, your traffic is capped at 100% utilization.

-|||

-## Retrieve batch job output file

-The following guide walks you through setting up a provisioned deployment with your Azure OpenAI Service resource.

-> [!NOTE]

-> Provisioned Throughput Units (PTU) are different from standard quota in Azure OpenAI and are not available by default. To learn more about this offering contact your Microsoft Account Team.

-## Create your provisioned deployment

-4. Select Create new deployment and configure the following fields. Expand the ΓÇÿadvanced optionsΓÇÖ drop-down.

-REST, ARM template, Bicep and Terraform can also be used to create deployments. See the section on automating deployments in the [Managing Quota](quota.md?tabs=rest#automate-deployment) how-to guide and replace the `sku.name` with "ProvisionedManaged" rather than "Standard."

-## Make your first calls

-The inferencing code for provisioned deployments is the same a standard deployment type. The following code snippet shows a chat completions call to a GPT-4 model. For your first time using these models programmatically, we recommend starting with our [quickstart guide](../quickstart.md). Our recommendation is to use the OpenAI library with version 1.0 or greater since this includes retry logic within the library.

-The amount of throughput that you can achieve on the endpoint is a factor of the number of PTUs deployed, input size, output size and call rate. The number of concurrent calls and total tokens processed can vary based on these values. Our recommended way for determining the throughput for your deployment is as follows:

-You can find the utilization measure in the Azure-Monitor section for your resource. To access the monitoring dashboards sign-in to [https://portal.azure.com](https://portal.azure.com), go to your Azure OpenAI resource and select the Metrics page from the left nav. On the metrics page, select the 'Provisioned-managed utilization' measure. If you have more than one deployment in the resource, you should also split the values by each deployment by clicking the 'Apply Splitting' button.

-Provisioned deployments provide you with an allocated amount of compute capacity to run a given model. The ΓÇÿProvisioned-Managed UtilizationΓÇÖ metric in Azure Monitor measures the utilization of the deployment in one-minute increments. Provisioned-Managed deployments are also optimized so that calls accepted are processed with a consistent per-call max latency. When the workload exceeds its allocated capacity, the service returns a 429 HTTP status code until the utilization drops down below 100%. The time before retrying is provided in the `retry-after` and `retry-after-ms` response headers that provide the time in seconds and milliseconds respectively. This approach maintains the per-call latency targets while giving the developer control over how to handle high-load situations ΓÇô for example retry or divert to another experience/endpoint.

-1. Run a benchmark with your own traffic shape and workloads using your client implementation. Be sure to implement retry logic using either an Azure Openai client library or custom logic.

-> [!NOTE]

-> Provisioned Throughput Units (PTU) are different from standard quota in Azure OpenAI and are not available by default. To learn more about this offering contact your Microsoft Account Team.

-You should consider switching from pay-as-you-go to provisioned throughput when you have well-defined, predictable throughput requirements. Typically, this occurs when the application is ready for production or has already been deployed in production and there is an understanding of the expected traffic. This will allow users to accurately forecast the required capacity and avoid unexpected billing.

-> In function calling and agent use cases, token usage can be variable. You should understand your expected Tokens Per Minute (TPM) usage in detail prior to migrating the workloads to PTU.

-| Tokens in prompt call | The number of tokens in the prompt for each call to the model. Calls with larger prompts will utilize more of the PTU deployment. Currently this calculator assumes a single prompt value so for workloads with wide variance, we recommend benchmarking your deployment on your traffic to determine the most accurate estimate of PTU needed for your deployment. |

-| Tokens in model response | The number of tokens generated from each call to the model. Calls with larger generation sizes will utilize more of the PTU deployment. Currently this calculator assumes a single prompt value so for workloads with wide variance, we recommend benchmarking your deployment on your traffic to determine the most accurate estimate of PTU needed for your deployment. |

-> The capacity planner is an estimate based on simple input criteria. The most accurate way to determine your capacity is to benchmark a deployment with a representational workload for your use case.

-### Understanding the provisioned throughput purchase model

-Unlike Azure services where you're charged based on usage, the Azure OpenAI Provisioned Throughput feature is purchased as a renewable, monthly commitment. This commitment is charged to your subscription upon creation and at each monthly renewal. When you onboard to Provisioned Throughput, you need to create a commitment on each Azure OpenAI resource where you intend to create a provisioned deployment. The PTUs you purchase in this way are available for use when creating deployments on those resources.

-The total number of PTUs you can purchase via commitments is limited to the amount of Provisioned Throughput quota that is assigned to your subscription. The following table compares other characteristics of Provisioned Throughput quota (PTUs) and Provisioned Throughput commitments.

-|Topic|Quota|Commitments|

-||||

-|Purpose| Grants permission to create provisioned deployments, and provides the upper limit on the capacity that can be used|Purchase vehicle for Provisioned Throughput capacity|

-|Lifetime| Quota might be removed from your subscription if it isn't purchased via a commitment within five days of being granted|The minimum term is one month, with customer-selectable autorenewal behavior. A commitment isn't cancelable, and can't be moved to a new resource while it's active|

-|Scope |Quota is specific to a subscription and region, and is shared across all Azure OpenAI resources | Commitments are an attribute of an Azure OpenAI resource, and are scoped to deployments within that resource. A subscription might contain as many active commitments as there are resources.|

-|Granularity| Quota is granted specific to a model family (for example, GPT-4) but is shareable across model versions within the family| Commitments aren't model or version specific. For example, a resourceΓÇÖs 1000 PTU commitment can cover deployments of both GPT-4 and GPT-35-Turbo|

-|Capacity guarantee| Having quota doesn't guarantee that capacity is available when you create the deployment| Capacity availability to cover committed PTUs is guaranteed as long as the commitment is active.|

-|Increases/Decreases| New quota can be requested and approved at any time, independent of your commitment renewal dates | The number of PTUs covered by a commitment can be increased at any time, but can't be decreased except at the time of renewal.|

-Quota and commitments work together to govern the creation of deployments within your subscriptions. To create a provisioned deployment, two criteria must be met:

-### Commitment properties and charging model

-A commitment includes several properties.

-|Property|Description|When Set|

-||||

-|Azure OpenAI Resource | The resource hosting the commitment | Commitment creation|

-|Committed PTUs| The number of PTUs covered by the commitment. | Initially set at commitment creation, and can be increased at any time, but not decreased.|

-|Term| The term of the commitment. A commitment expires one month from its creation date. The renewal policy defines what happens next. | Commitment creation |

-|Expiration Date| The expiration date of the commitment. This time of expiration is midnight UTC.| Initially, 30 days from creation. However, the expiration date changes if the commitment is renewed.|

-|Renewal Policy| There are three options for what to do upon expiration: <br><br> - Autorenew: A new commitment term begins for another 30 days at the current number of PTUs <br>- Autorenew with different settings: This setting is the same as *Autorenew*, except that the number of PTUs committed upon renewal can be decreased <br>- Don't autorenew: Upon expiration, the commitment ends and isn't renewed.| Initially set at commitment creation, and can be changed at any time.|

-### Commitment charges

-Provisioned Throughput Commitments generate charges against your Azure subscription at the following times:

-As long as the number of deployed PTUs in a resource is covered by the resourceΓÇÖs commitment, then you'll only see the commitment charges. However, if the number of deployed PTUs in a resource becomes greater than the resourceΓÇÖs committed PTUs, the excess PTUs will be charged as overage at an hourly rate. Typically, the only way this overage will happen is if a commitment expires or is reduced at its renewal while the resource contains deployments. For example, if a 300 PTU commitment is allowed to expire on a resource that has 300 PTUs deployed, the deployed PTUs is no longer be covered by any commitment. Once the expiration date is reached, the subscription is charged an hourly overage fee based on the 300 excess PTUs.

-The hourly rate is higher than the monthly commitment rate and the charges exceed the monthly rate within a few days. There are two ways to end hourly overage charges:

-## Purchasing and managing commitments

-### Planning your commitments

-Upon receiving confirmation that Provisioned Throughput Unit (PTU) quota is assigned to a subscription, you must create commitments on the target resources (or extend existing commitments) to make the quota usable for deployments.

-Prior to creating commitments, plan how the provisioned deployments will be used and which Azure OpenAI resources will host them. Commitments have a **one month minimum term and can't be decreased in size until the end of the term**. They also can't be moved to new resources once created. Finally, the sum of your committed PTUs can't be greater than your quota ΓÇô PTUs committed on a resource are no longer available to commit to on a different resource until the commitment expires. Having a clear plan on which resources will be used for provisioned deployments and the capacity you intend to apply to them (for at least a month) will help ensure an optimal experience with your provisioned throughput setup.

-For example:

- - Example 1: GPT-4-32K requires a minimum of 200 PTUs to deploy. If you create a commitment of only 100 PTUs on a resource, you wonΓÇÖt have enough committed PTUs to deploy GPT-4-32K there

- - Example 2: If you need to create multiple deployments on a resource, sum the PTUs required for each deployment. A production resource hosting deployments for 300 PTUs of GPT-4, and 500 PTUs of GPT-4-32K will require a commitment of at least 800 PTUs to cover both deployments.

- - Organizationally required resource naming conventions

- - Business continuity policies that require multiple deployments of a model per region, perhaps on different Azure OpenAI resources

-### Managing Provisioned Throughput Commitments

-Provisioned throughput commitments are created and managed from the **Manage Commitments** view in Azure OpenAI Studio. You can navigate to this view by selecting **Manage Commitments** from the Quota pane:

-From the Manage Commitments view, you can do several things:

-The sections below will take you through these tasks.

-### Purchase a Provisioned Throughput Commitment

-With your commitment plan ready, the next step is to create the commitments. Commitments are created manually via Azure OpenAI Studio and require the user creating the commitment to have either the [Contributor or Cognitive Services Contributor role](./role-based-access-control.md) at the subscription level.

-For each new commitment you need to create, follow these steps:

-1. Launch the Provisioned Throughput purchase dialog by selecting **Quotas** > **Provisioned** > **Manage Commitments**.

-2. Select **Purchase commitment**.

-3. Select the Azure OpenAI resource and purchase the commitment. You will see your resources divided into resources with existing commitments, which you can edit and resources that don't currently have a commitment.

-| Setting | Notes |

-||-|

-| **Select a resource** | Choose the resource where you'll create the provisioned deployment. Once you have purchased the commitment, you will be unable to use the PTUs on another resource until the current commitment expires. |

-| **Select a commitment type** | Select Provisioned. (Provisioned is equivalent to Provisioned Managed) |

-| **Current uncommitted provisioned quota** | The number of PTUs currently available for you to commit to this resource. |

-| **Amount to commit (PTU)** | Choose the number of PTUs you're committing to. **This number can be increased during the commitment term, but can't be decreased**. Enter values in increments of 50 for the commitment type Provisioned. |

-| **Commitment tier for current period** | The commitment period is set to one month. |

-| **Renewal settings** | Auto-renew at current PTUs <br> Auto-renew at lower PTUs <br> Do not auto-renew |

-4. Select Purchase. A confirmation dialog will be displayed. After you confirm, your PTUs will be committed, and you can use them to create a provisioned deployment. |

-> [!IMPORTANT]

-> A new commitment is billed up-front for the entire term. If the renewal settings are set to auto-renew, then you will be billed again on each renewal date based on the renewal settings.

-## Edit an existing Provisioned Throughput commitment

-From the Manage Commitments view, you can also edit an existing commitment. There are two types of changes you can make to an existing commitment:

-To edit a commitment, select the current to edit, then select Edit commitment.

-### Adding Provisioned Throughput Units to existing commitments

-Adding PTUs to an existing commitment will allow you to create larger or more numerous deployments within the resource. You can do this at any time during the term of your commitment.

-> [!IMPORTANT]

-> When you add PTUs to a commitment, they will be billed immediately, at a pro-rated amount from the current date to the end of the existing commitment term. Adding PTUs does not reset the commitment term.

-### Changing renewal settings

-Commitment renewal settings can be changed at any time before the expiration date of your commitment. Reasons you might want to change the renewal settings include ending your use of provisioned throughput by setting the commitment to not auto-renew, or to decrease usage of provisioned throughput by lowering the number of PTUs that will be committed in the next period.

-> [!IMPORTANT]

-> If you allow a commitment to expire or decrease in size such that the deployments under the resource require more PTUs than you have in your resource commitment, you will receive hourly overage charges for any excess PTUs. For example, a resource that has deployments that total 500 PTUs and a commitment for 300 PTUs will generate hourly overage charges for 200 PTUs.

-## Monitor commitments and prevent unexpected billings

-The manage commitments pane provides a subscription wide overview of all resources with commitments and PTU usage within a given Azure Subscription. Of particular importance interest are:

-## Common Commitment Management Scenarios

-**Discontinue use of provisioned throughput**

-To end use of provisioned throughput, and prevent hourly overage charges after commitment expiration, stop any charges after the current commitments are expired, two steps must be taken:

-1. Set the renewal policy on all commitments to *Don't autorenew*.

-2. Delete the provisioned deployments using the quota.

-**Move a commitment/deployment to a new resource in the same subscription/region**

-It isn't possible in Azure OpenAI Studio to directly *move* a deployment or a commitment to a new resource. Instead, a new deployment needs to be created on the target resource and traffic moved to it. There will need to be a commitment purchased established on the new resource to accomplish this. Because commitments are charged up-front for a 30-day period, it's necessary to time this move with the expiration of the original commitment to minimize overlap with the new commitment and ΓÇ£double-billingΓÇ¥ during the overlap.

-There are two approaches that can be taken to implement this transition.

-**Option 1: No-Overlap Switchover**

-This option requires some downtime, but requires no extra quota and generates no extra costs.

-| Steps | Notes |

-|-|-|

-|Set the renewal policy on the existing commitment to expire| This will prevent the commitment from renewing and generating further charges |

-|Before expiration of the existing commitment, delete its deployment | Downtime will start at this point and will last until the new deployment is created and traffic is moved. You'll minimize the duration by timing the deletion to happen as close to the expiration date/time as possible.|

-|After expiration of the existing commitment, create the commitment on the new resource|Minimize downtime by executing this and the next step as soon after expiration as possible.|

-|Create the deployment on the new resource and move traffic to it||

-**Option 2: Overlapped Switchover**

-This option has no downtime by having both existing and new deployments live at the same time. This requires having quota available to create the new deployment, and will generate extra costs for the duration of the overlapped deployments.

-| Steps | Notes |

-|-|-|

-|Set the renewal policy on the existing commitment to expire| Doing so prevents the commitment from renewing and generating further charges.|

-|Before expiration of the existing commitment:<br>1. Create the commitment on the new resource.<br>2. Create the new deployment.<br>3. Switch traffic<br>4. Delete existing deployment| Ensure you leave enough time for all steps before the existing commitment expires, otherwise overage charges will be generated (see next section) for options. |

-If the final step takes longer than expected and will finish after the existing commitment expires, there are three options to minimize overage charges.

-Both paying for an overage and resetting the original commitment will generate charges beyond the original expiration date. Paying overage charges might be cheaper than a new one-month commitment if you only need a day or two to complete the move. Compare the costs of both options to find the lowest-cost approach.

-### Move the deployment to a new region and or subscription

-The same approaches apply in moving the commitment and deployment within the region, except that having available quota in the new location will be required in all cases.

-### View and edit an existing resource

-In Azure OpenAI Studio, select **Quota** > **Provisioned** > **Manage commitments** and select a resource with an existing commitment to view/change it.

-* **Asynchronous synthesis of long audio**: Use the [batch synthesis API](batch-synthesis.md) (Preview) to asynchronously synthesize text to speech files longer than 10 minutes (for example, audio books or lectures). Unlike synthesis performed via the Speech SDK or Speech to text REST API, responses aren't returned in real-time. The expectation is that requests are sent asynchronously, responses are polled for, and synthesized audio is downloaded when the service makes it available.

-Use the following decision tree to determine which migration path is right for you.

-Follow these steps to change the Minimum TLS cipher suite:

-1. Browse to your app in the [Azure portal](https://portal.azure.com/)

-1. In the left menu, select **configuration** and then select the **General settings** tab.

-1. Under __Minimum Inbound TLS Cipher Suite__, select **change**, and then select the **Minimum TLS Cipher Suite**.

-1. Select **Ok**.

-1. Select **Save** to save the changes.

-End-to-end (E2E) TLS encryption is available in Standard App Service plans and higher. Front-end intra-cluster traffic between App Service front-ends and the workers running application workloads can now be encrypted. Below is a simple diagram to help you understand how it works.

-Follow these steps to enable end-to-end TLS encryption:

-1. Browse to your app in the [Azure portal](https://portal.azure.com/)

-1. In the left menu, select **configuration** and then select the **General settings** tab.

-1. Under __End-to-end TLS encryption__, select **on**.

-1. Save the changes.

-> [!NOTE]

-> The NSG for the delegated subnet can only use the default rules for incoming traffic. For example: AllowVNetInBound, AllowAzureLoadBalancerInBound, and DenyAllInbound. No other incoming NSG rule is supported.

-This article explains various Automation services offered in the Azure environment. These services can automate business and operational processes and solve integration problems amongst multiple services, systems, and processes. Automation services can define input, action, activity to be performed, conditions, error handling, and output generation. Using these services you can run various activities on a schedule or do a manual demand-based execution. Each service has its unique advantages and target audience.

- - Azure Automanage (for machine configuration and management.)

- - Azure Policy Guest Config (to take an action when there's a change in the compliance state of resource.)

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

- - Azure Functions or Azure Automation. (Azure Logic app has over 400+ connectors to other services, including Azure Automation and Azure Functions, which could be used to meet complex automation scenarios.)

-We've introduced a new language named [Bicep](../azure-resource-manager/bicep/overview.md) that offers the same capabilities as ARM templates but with a syntax that's easier to use. Each Bicep file is automatically converted to an ARM template during deployment. If you're considering infrastructure as code options, we recommend Bicep. For more information, see [What is Bicep?](../azure-resource-manager/bicep/overview.md)

- | Create, manage, and update infrastructure resources, such as virtual machines, networks, storage accounts, containers and so on. </br> </br> Deploy apps, add tags, assign policies, assign role-based access control all declaratively as code and integrated with your CI\CD tools. </br> </br> Manage multiple environments such as production, non-production, and disaster recovery. </br> </br> Deploy resources consistently and reliably at a scale. | Application Developers, Infrastructure Administrators, DevOps Engineers using Azure for the first time or using Azure as their primary cloud. </br> </br> IT Engineer\Cloud Architect responsible for cloud infrastructure deployment. |

- Azure Blueprints (Preview) define a repeatable set of Azure resources that implements and adheres to an organization's standards, patterns, and requirements. Blueprints are a declarative way to orchestrate the deployment of various resource templates and other artifacts such as, Role assignments, Policy assignments, ARM templates and Resource groups. [Learn more](../governance/blueprints/overview.md).

-Azure Automation orchestrates repetitive processes using graphical, PowerShell, and Python runbooks in the cloud or hybrid environments. It provides a persistent shared assets including variables, connections, objects that allow orchestration of complex jobs. [Learn more](./automation-runbook-gallery.md).

-There are more than 3,000 modules in the PowerShell Gallery, and the PowerShell community continues to grow. Azure Automation based on PowerShell modules can work with multiple applications and vendors, both 1st party and 3rd party. As more application vendors release PowerShell modules for integration, extensibility and automation tasks, you could use an existing PowerShell script as-is to execute it as a PowerShell runbook in an automation account without making any changes.

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

-You can configure desired the state of your machines to discover and correct configuration drift. [Learn more](./automation-dsc-overview.md).

-**Update management** : Assess compliance of servers and can schedule update installation on your machines. [Learn more](./update-management/overview.md).

- | Detect and alert on software, services, file and registry changes to your machines, vigilant on everything installed in your servers. </br> </br> Assess and install updates on your servers using Azure Update management. </br> </br> Configure the desired state of your servers and ensure they stay compliant. | </br> </br> Central IT\Infrastructure Administrators\Auditors looking for regulatory requirements at scale and ensuring end state of severs looks as desired, patched and audited. |

-Replaces repetitive, day-to-day operational tasks with an exception-only management model, where a healthy, steady-state of VM is equal to hands-free management. [Learn more](../automanage/index.yml).

- - You can intelligently onboard virtual machines to select best practices Azure services.

- - It allows you to configure each service per Azure best practices automatically.

- - It supports customization of best practice services through VM Best practices template for Dev\Test and Production workload.

- - You can monitor for drift and correct it when detected.

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

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

-Azure Policy based Guest configuration is the next iteration of Azure Automation State configuration. [Learn more](../governance/machine-configuration/remediation-options.md).

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

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

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

- | Respond to system alerts, service alerts, or high CPU/memory alerts from 1st party or 3rd party monitoring tools like Splunk or ServiceNow, create ServiceNow tickets basis alerts and so on. </br> </br> Hybrid automation scenarios where you can manage automation on on-premises servers such as SQL Server, Active Directory and so on based on an external event.</br> </br> Azure resource life-cycle management and governance that includes Resource provisioning, deprovisioning, adding correct tags, locks, NSGs and so on based on Azure monitor alerts. | IT administrators, System administrators, IT operations administrators who are skilled at using PowerShell or Python based scripting. |

-Provides a serverless event-driven compute platform for automation that allows you to write code to react to critical events from various sources, third-party services, and on-premises systems. For example, an HTTP trigger without worrying about the underlying platform. [Learn more](../azure-functions/functions-overview.md).

- - You can use a variety of languages to write functions in a language of your choice such as C#, Java, JavaScript, PowerShell, or Python and focus on specific pieces of code. Functions runtime is an open source.

- - You should avoid large, and long-running functions that can cause unexpected timeout issues. [Learn more](../azure-functions/functions-best-practices.md?tabs=csharp#write-robust-functions).

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

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

- - Allows you to build smart integrations between 1st party and 3rd party apps, services and systems running across on-premises, hybrid and cloud native.

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

- - Runs only in the cloud.

- - Provides a large collection of ready made actions and triggers.

- | Schedule and send email notifications using Office 365 when a specific event happens. For example, a new file is uploaded. </br> </br> Route and process customer orders across on-premises systems and cloud services. </br></br> Move uploaded files from an SFTP or FTP server to Azure Storage. </br> </br> Monitor tweets, analyze the sentiment, and create alerts or tasks for items that need review. | The Pro integrators and developers, IT professionals who would want to use low code/no code option for Advanced integration scenarios to external systems or APIs. |

-Orchestrates repetitive processes using graphical, PowerShell, and Python runbooks in the cloud or hybrid environment. It provides persistent shared assets, including variables, connections, and objects that allows orchestration of complex jobs. [Learn more](./overview.md).

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

-Provides a serverless event-driven compute platform for automation that allows you to write code to react to critical events from various sources, third-party services, and on-premises systems. For example, an HTTP trigger without worrying about the underlying platform [Learn more](../azure-functions/functions-overview.md).

- - You can use a variety of languages to write functions in a language of your choice such as C#, Java, JavaScript, PowerShell, or Python and focus on specific pieces of code. Functions runtime is an open source.

- - You should avoid large, and long-running functions that can cause unexpected timeout issues. [Learn more](../azure-functions/functions-best-practices.md?tabs=csharp#write-robust-functions).

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

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

-## Version 1.44 - July 2024

-| **SCVMM** | You need an SCVMM management server running version 2019 or later.<br/><br/> A private cloud or a host group with a minimum free capacity of 32 GB of RAM, 4 vCPUs with 100 GB of free disk space. <br/><br/> A VM network with internet access, directly or through proxy. Appliance VM will be deployed using this VM network.<br/><br/> Only Static IP allocation is supported; Dynamic IP allocation using DHCP isn't supported. Static IP allocation can be performed by one of the following approaches:<br><br> 1. **VMM IP Pool**: Follow [these steps](/system-center/vmm/network-pool?view=sc-vmm-2022&preserve-view=true) to create a VMM Static IP Pool and ensure that the Static IP Pool has at least three IP addresses. If your SCVMM server is behind a firewall, all the IPs in this IP Pool and the Control Plane IP should be allowed to communicate through WinRM ports. The default WinRM ports are 5985 and 5986. <br> <br> 2. **Custom IP range**: Ensure that your VM network has three continuous free IP addresses. If your SCVMM server is behind a firewall, all the IPs in this IP range and the Control Plane IP should be allowed to communicate through WinRM ports. The default WinRM ports are 5985 and 5986. If the VM network is configured with a VLAN, the VLAN ID is required as an input. Azure Arc Resource Bridge requires internal and external DNS resolution to the required sites and the on-premises management machine for the Static gateway IP and the IP address(es) of your DNS server(s) are needed. <br/><br/> A library share with write permission for the SCVMM admin account through which Resource Bridge deployment is going to be performed.|

-| **SCVMM** | You need an SCVMM management server running version 2019 or later.<br/><br/> A private cloud or a host group with a minimum free capacity of 32 GB of RAM, 4 vCPUs with 100 GB of free disk space. <br/><br/> A VM network with internet access, directly or through proxy. Appliance VM will be deployed using this VM network.<br/><br/> Only Static IP allocation is supported; Dynamic IP allocation using DHCP isn't supported. Static IP allocation can be performed by one of the following approaches:<br><br> 1. **VMM IP Pool**: Follow [these steps](/system-center/vmm/network-pool?view=sc-vmm-2022&preserve-view=true) to create a VMM Static IP Pool and ensure that the Static IP Pool has at least three IP addresses. If your SCVMM server is behind a firewall, all the IPs in this IP Pool and the Control Plane IP should be allowed to communicate through WinRM ports. The default WinRM ports are 5985 and 5986. <br> <br> 2. **Custom IP range**: Ensure that your VM network has three continuous free IP addresses. If your SCVMM server is behind a firewall, all the IPs in this IP range and the Control Plane IP should be allowed to communicate through WinRM ports. The default WinRM ports are 5985 and 5986. If the VM network is configured with a VLAN, the VLAN ID is required as an input. Azure Arc Resource Bridge requires internal and external DNS resolution to the required sites and the on-premises management machine for the Static gateway IP and the IP address(es) of your DNS server(s) are needed. <br/><br/> A library share with write permission for the SCVMM admin account through which Resource Bridge deployment is going to be performed. |

->If you're trying to enable Arc for Azure VMware Solution (AVS) private cloud, see [Deploy Arc-enabled VMware vSphere for Azure VMware Solution private cloud](../../azure-vmware/deploy-arc-for-azure-vmware-solution.md).

-description: Learn how to use Microsoft Entra ID with Azure Cache for Redis.

-# Use Microsoft Entra ID for cache authentication

-Azure Cache for Redis offers two methods to [authenticate](cache-configure.md#authentication) to your cache instance: Access keys and Microsoft Entra ID

-Azure Cache for Redis offers a password-free authentication mechanism by integrating with [Microsoft Entra ID)](/azure/active-directory/fundamentals/active-directory-whatis). This integration also includes [role-based access control](/azure/role-based-access-control/) functionality provided through [access control lists (ACLs)](https://redis.io/docs/management/security/acl/) supported in open source Redis.

-To use the ACL integration, your client application must assume the identity of a Microsoft Entra entity, like service principal or managed identity, and connect to your cache. In this article, you learn how to use your service principal or managed identity to connect to your cache, and how to grant your connection predefined permissions based on the Microsoft Entra artifact being used for the connection.

-| **Tier** | Basic, Standard, Premium | Enterprise, Enterprise Flash |

-| **Availability** | Yes | No |

-> Once a connection is established using Microsoft Entra token, client applications must periodically refresh Microsoft Entra token before expiry, and send an `AUTH` command to Redis server to avoid disruption of connections. For more information, see [Configure your Redis client to use Microsoft Entra ID](#configure-your-redis-client-to-use-microsoft-entra-id).

-## Enable Microsoft Entra ID authentication on your cache

-1. In the Azure portal, select the Azure Cache for Redis instance where you'd like to configure Microsoft Entra token-based authentication.

-1. Select **Authentication** from the Resource menu.

-1. In the working pane, select **Enable Microsoft Entra Authentication**.

-1. Select **Enable Microsoft Entra Authentication**, and enter the name of a valid user. The user you enter is automatically assigned _Data Owner Access Policy_ by default when you select **Save**. You can also enter a managed identity or service principal to connect to your cache instance.

- :::image type="content" source="media/cache-azure-active-directory-for-authentication/cache-enable-microsoft-entra.png" alt-text="Screenshot showing authentication selected in the resource menu and the enable Microsoft Entra authentication checked.":::

-1. A popup dialog box displays asking if you want to update your configuration, and informing you that it takes several minutes. Select **Yes.**

- > Once the enable operation is complete, the nodes in your cache instance reboots to load the new configuration. We recommend performing this operation during your maintenance window or outside your peak business hours. The operation can take up to 30 minutes.

-For information on using Microsoft Entra ID with Azure CLI, see the [references pages for identity](/cli/azure/redis/identity).

-Using Microsoft Entra ID is the secure way to connect your cache. We recommend using Microsoft Entra ID and disabling access keys.

-When you disable access key Authentication for a cache, all existing client connections are terminated, whether they use access keys or Microsoft Entra ID auth-based. You're advised to follow the recommended Redis client best practices to implement proper retry mechanisms for reconnecting MS Entra-based connections, if any.

-If you have a cache where access keys are used, and you want to disable access keys, follow this procedure.

-1. In the Azure portal, select the Azure Cache for Redis instance where you'd like to disable access keys.

-1. Select **Authentication** from the Resource menu.

-1. In the working pane, selectΓÇ»**Access keys**.

- :::image type="content" source="media/cache-azure-active-directory-for-authentication/cache-disable-access-keys.png" alt-text="Screenshot showing access keys in the working pane with a red box around Disable Access Key Authentication. ":::

-1. You're asked to confirm that you want to update your configuration. SelectΓÇ»**Yes**.

-> When the **Disable Access Key Authentication**" setting is changed for a cache, all existing client connections, using access keys or Microsoft Entra ID, are terminated. Follow the best practices to implement proper retry mechanisms for reconnecting MS Entra-based connections. For more information, see [Connection resilience](cache-best-practices-connection.md).

-## Using data access configuration with your cache

-If you would like to use a custom access policy instead of Redis Data Owner, go to the **Data Access Configuration** on the Resource menu. For more information, see [Configure a custom data access policy for your application](cache-configure-role-based-access-control.md#configure-a-custom-data-access-policy-for-your-application).

-1. In the Azure portal, select the Azure Cache for Redis instance where you'd like to add to the Data Access Configuration.

-1. Select **Data Access Configuration** from the Resource menu.

-1. Select **Add** and choose **New Redis User**.

-1. On the **Access Policy** tab, select one the available policies in the table: **Data Owner**, **Data Contributor**, or **Data Reader**. Then, select the **Next:Redis Users**.

-1. Choose either the **User or service principal** or **Managed Identity** to determine how to assign access to your Azure Cache for Redis instance. If you select **User or service principal**, and you want to add a _user_, you must first [enable Microsoft Entra Authentication](#enable-microsoft-entra-id-authentication-on-your-cache).

-1. Then, select **Select members** and select **Select**. Then, select **Next : Review + Assign**.

- :::image type="content" source="media/cache-azure-active-directory-for-authentication/cache-select-members.png" alt-text="Screenshot showing members to add as New Redis Users.":::

-1. A dialog box displays a popup notifying you that upgrading is permanent and might cause a brief connection blip. Select **Yes.**

- > Once the enable operation is complete, the nodes in your cache instance reboots to load the new configuration. We recommend performing this operation during your maintenance window or outside your peak business hours. The operation can take up to 30 minutes.

-## Configure your Redis client to use Microsoft Entra ID

-Because most Azure Cache for Redis clients assume that a password and access key are used for authentication, you likely need to update your client workflow to support authentication using Microsoft Entra ID. In this section, you learn how to configure your client applications to connect to Azure Cache for Redis using a Microsoft Entra token.

-### Microsoft Entra Client Workflow

-1. Configure your client application to acquire a Microsoft Entra token for scope, `https://redis.azure.com/.default` or `acca5fbb-b7e4-4009-81f1-37e38fd66d78/.default`, using the [Microsoft Authentication Library (MSAL)](/azure/active-directory/develop/msal-overview).

-1. Update your Redis connection logic to use following `User` and `Password`:

- - `Password` = Microsoft Entra token that you acquired using MSAL

-1. Ensure that your client executes a Redis [AUTH command](https://redis.io/commands/auth/) automatically before your Microsoft Entra token expires using:

-The library [`Microsoft.Azure.StackExchangeRedis`](https://www.nuget.org/packages/Microsoft.Azure.StackExchangeRedis) is an extension of `StackExchange.Redis` that enables you to use Microsoft Entra ID to authenticate connections from a Redis client application to an Azure Cache for Redis. The extension manages the authentication token, including proactively refreshing tokens before they expire to maintain persistent Redis connections over multiple days.

-This [code sample](https://github.com/Azure/Microsoft.Azure.StackExchangeRedis) demonstrates how to use the `Microsoft.Azure.StackExchangeRedis` NuGet package to connect to your Azure Cache for Redis instance using Microsoft Entra ID.

-The following table includes links to code samples, which demonstrate how to connect to your Azure Cache for Redis instance using a Microsoft Entra token. A wide variety of client libraries are included in multiple languages.

-| **Client library** | **Language** | **Link to sample code**|

-| redis-py | Python | [redis-py code Sample](https://aka.ms/redis/aad/sample-code/python) |

-Now that you have configured Redis User and Data access policy for configuring role based access control, you need to update your client workflow to support authenticating using a specific user/password. To learn how to configure your client application to connect to your cache instance as a specific Redis User, see [Configure your Redis client to use Microsoft Entra ID](cache-azure-active-directory-for-authentication.md#configure-your-redis-client-to-use-microsoft-entra-id).

-The Azure Functions Python worker requires a specific set of libraries. You can also use these libraries in your functions, but they aren't a part of the Python standard. If your functions rely on any of these libraries, they might be unavailable to your code when it's running outside of Azure Functions. You'll find a detailed list of dependencies in the "install\_requires" section of the [*setup.py*](https://github.com/Azure/azure-functions-python-worker/blob/dev/setup.py#L282) file.

-The default _target executions per instance_ values come from the SDKs used by the Azure Functions extensions. You don't need to make any changes for target-based scaling to work.

- - **Alert frequency of more than 5 minutes**: While the condition continues to be met, a notification is sent between the configured frequency and double the frequency. For example, for an alert rule with a frequency of 15 minutes, a notification is sent sometime between 15 to 30 minutes.

- [Azure Advisor](../../advisor/advisor-overview.md) warns you about this behavior. It adds a recommendation about the affected log search alert rule. The category used is 'High Availability' with medium impact and a description of 'Repair your log alert rule to ensure monitoring'.

-### Unsupported SDKs

-* Network Dependency Requests made by your app XHR and Fetch (fetch collection is disabled by default) requests, include information on:

- * Url of dependency source

- * Command & Method used to request the dependency

- * Duration of the request

- * Result code and success status of the request

- * ID (if any) of user making the request

- * Correlation context (if any) where request is made

-We recommend that you use our SDKs and use the [SDK API](./api-custom-events-metrics.md). There are variants of the SDK for various [platforms](./app-insights-overview.md#supported-languages). These SDKs handle processes like buffering, compression, throttling, and retries. However, the [ingestion schema](https://github.com/microsoft/ApplicationInsights-dotnet/tree/master/BASE/Schem) are public.

-Application Insights doesn't handle sensitive data by default, as long as you don't put sensitive data in URLs as plain text and ensure your custom code doesn't collect personal or other sensitive details. During development and testing, check the sent data in your IDE and browser's debugging output windows.

-For archived information on this topic, see [Data collection, retention, and storage in Application Insights](/previous-versions/azure/azure-monitor/app/data-retention-privacy).

-Application Insights is billed through the Log Analytics workspace into which its log data ingested.

-The default Pay-as-you-go Log Analytics pricing tier includes 5 GB per month of free data allowance per billing account.

-Learn more about [Azure Monitor logs pricing options](https://azure.microsoft.com/pricing/details/monitor/).

-Yes, you may incur more network costs, which vary depending on the region the telemetry is coming from and where it's going.

-### Microsoft Q&A questions forum

-Post general questions to the Microsoft Q&A [answers forum](/answers/topics/24223/azure-monitor.html).

-Review dedicated [troubleshooting articles](/troubleshoot/azure/azure-monitor/welcome-azure-monitor) for Application Insights.

-If your language and platform are supported, select the corresponding link in the [Supported environments, languages, and resource providers table](#supported-environments-languages-and-resource-providers) for more detailed information. In many cases, autoinstrumentation is enabled by default.

-> If your hosting environment or resource provider is not listed in the following table, autoinstrumentation is not supported. You can manually instrument your code using Application Insights SDKs or Azure Monitor OpenTelemetry Distros. For more information, see [Data Collection Basics of Azure Monitor Application Insights](opentelemetry-overview.md).

-## JavaScript (Web) SDK Loader Script injection by configuration

-When using supported Software Development Kits (SDKs), you can enable SDK injection in configuration to automatically inject JavaScript (Web) SDK Loader Script onto each page.

- | Language

- | : |

- | [ASP.NET Core](./asp-net-core.md?tabs=netcorenew%2Cnetcore6#enable-client-side-telemetry-for-web-applications) |

- | [Node.js](./nodejs.md#browser-sdk-loader) |

- | [Java](./java-standalone-config.md#browser-sdk-loader-preview) |

-For other methods to instrument your application with the Application Insights JavaScript SDK, see [Get started with the JavaScript SDK](./javascript-sdk.md).

-> Good news! We're making it even easier to enable JavaScript. Check out where [JavaScript (Web) SDK Loader Script injection by configuration is available](./codeless-overview.md#javascript-web-sdk-loader-script-injection-by-configuration)!

-## Ingestion from a private AKS cluster

-## Private link ingestion for remote write

-### Existing AKS Cluster

-**Use default Log Analytics workspace**

-**Use existing Log Analytics workspace**

-### New AKS cluster

-## Cluster using legacy authentication

-# Configuration of Azure Monitor edge pipeline

-[Azure Monitor pipeline](./pipeline-overview.md) is a data ingestion pipeline providing consistent and centralized data collection for Azure Monitor. The [edge pipeline](./pipeline-overview.md#edge-pipeline) enables at-scale collection, and routing of telemetry data before it's sent to the cloud. It can cache data locally and sync with the cloud when connectivity is restored and route telemetry to Azure Monitor in cases where the network is segmented and data cannot be sent directly to the cloud. This article describes how to enable and configure the edge pipeline in your environment.

-The Azure Monitor edge pipeline is a containerized solution that is deployed on an [Arc-enabled Kubernetes cluster](../../azure-arc/kubernetes/overview.md) and leverages OpenTelemetry Collector as a foundation. The following diagram shows the components of the edge pipeline. One or more data flows listen for incoming data from clients, and the pipeline extension forwards the data to the cloud, using the local cache if necessary.

-The pipeline configuration file defines the data flows and cache properties for the edge pipeline. The [DCR](./pipeline-overview.md#data-collection-rules) defines the schema of the data being sent to the cloud pipeline, a transformation to filter or modify the data, and the destination where the data should be sent. Each data flow definition for the pipeline configuration specifies the DCR and stream within that DCR that will process that data in the cloud pipeline.

-> Private link is supported by edge pipeline for the connection to the cloud pipeline.

-The following components and configurations are required to enable the Azure Monitor edge pipeline. If you use the Azure portal to configure the edge pipeline, then each of these components is created for you. With other methods, you need to configure each one.

-Edge pipeline is supported on the following Kubernetes distributions:

-Edge pipeline is supported in the following Azure regions:

-The following tables and diagrams describe the detailed steps and components in the process for collecting data using the edge pipeline and passing it to the cloud pipeline for storage in Azure Monitor. Also included in the tables is the configuration required for each of those components.

-| 4. | Cloud pipeline accepts the incoming data. | The DCR includes a schema definition for the incoming stream that must match the schema of the data coming from the edge pipeline. |

-[Network segmentation](/azure/architecture/networking/guide/network-level-segmentation) is a model where you use software defined perimeters to create a different security posture for different parts of your network. In this model, you may have a network segment that can't connect to the internet or to other network segments. The edge pipeline can be used to collect data from these network segments and send it to the cloud pipeline.

-Before you configure the data collection process for the edge pipeline, you need to create a table in the Log Analytics workspace to receive the data. This must be a custom table since built-in tables aren't currently supported. The schema of the table must match the data that it receives, but there are multiple steps in the collection process where you can modify the incoming data, so you the table schema doesn't need to match the source data that you're collecting. The only requirement for the table in the Log Analytics workspace is that it has a `TimeGenerated` column.

-Edge devices in some environments may experience intermittent connectivity due to various factors such as network congestion, signal interference, power outage, or mobility. In these environments, you can configure the edge pipeline to cache data by creating a [persistent volume](https://kubernetes.io) in your cluster. The process for this will vary based on your particular environment, but the configuration must meet the following requirements:

-Following are the steps required to create and configure the components required for the Azure Monitor edge pipeline using Azure CLI.

-The following ARM template creates the [data collection endpoint (DCE)](./data-collection-endpoint-overview.md) required for the edge pipeline to connect to the cloud pipeline. You can use an existing DCE if you already have one in the same region. Replace the properties in the following table before deploying the template.

-The DCR is stored in Azure Monitor and defines how the data will be processed when it's received from the edge pipeline. The edge pipeline configuration specifies the `immutable ID` of the DCR and the `stream` in the DCR that will process the data. The `immutable ID` is automatically generated when the DCR is created.

-| - `outputStream` | Specifies the destination table in the Log Analytics workspace. The table must already exist in the workspace. For custom tables, prefix the table name with *Custom-*. Built-in tables are not currently supported with edge pipeline. |

-The edge pipeline configuration defines the details of the edge pipeline instance and deploy the data flows necessary to receive and send telemetry to the cloud.

-| `dataCollectionEndpointUrl` | URL of the DCE where the edge pipeline will send the data. You can locate this in the Azure portal by navigating to the DCE and copying the **Logs Ingestion** value. |

-You can deploy all of the required components for the Azure Monitor edge pipeline using the single ARM template shown below. Edit the parameter file with specific values for your environment. Each section of the template is described below including sections that you must modify before using it.

-Click on the entry for **\<pipeline name\>-external-service** and note the IP address and port in the **Endpoints** column. This is the external IP address and port that your clients will send data to.

-Each client requires the external IP address of the pipeline. Use the following command to retrieve this address:

-If the application producing logs is external to the cluster, copy the *external-ip* value of the service *nginx-controller-service* with the load balancer type. If the application is on a pod within the cluster, copy the *cluster-ip* value. If the external-ip field is set to *pending*, you will need to configure an external IP for this ingress manually according to your cluster configuration.

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

- - Logs for VM2, excluding SecurityEvent and SecurityBaseline, in WS2.

-| Azure Active Directory | [AADDomainServicesDNSAuditsGeneral](/azure/azure-monitor/reference/tables/AADDomainServicesDNSAuditsGeneral)<br> [AADDomainServicesDNSAuditsDynamicUpdates](/azure/azure-monitor/reference/tables/AADDomainServicesDNSAuditsDynamicUpdates)<br>[AADServicePrincipalSignInLogs](/azure/azure-monitor/reference/tables/AADServicePrincipalSignInLogs) |

-* Volume quotas are indexed against `maxfiles` limits. Once a volume has surpassed a `maxfiles` limit, you cannot reduce the volume size below the quota that corresponds to that `maxfiles` limit. For more information and specific limits, see [`maxfiles` limits](azure-netapp-files-resource-limits.md#maxfiles-limits-).

-| Maximum number of files in a single directory | *Approximately* 4 million. <br> See [Determine if a directory is approaching the limit size](#directory-limit). | No |

-| Maximum number of files `maxfiles` per volume | See [`maxfiles`](#maxfiles) | Yes |

-## Determine if a directory is approaching the limit size <a name="directory-limit"></a>

-You can use the `stat` command from a client to see whether a directory is approaching the maximum size limit for directory metadata (320 MB). If you reach the maximum size limit for a single directory for Azure NetApp Files, the error `No space left on device` occurs.

-For a 320-MB directory, the number of blocks is 655,360, with each block size being 512 bytes. (That is, 320x1024x1024/512.) This number translates to approximately 4 million files maximum for a 320-MB directory. However, the actual number of maximum files might be lower, depending on factors such as the number of files with non-ASCII characters in the directory. As such, you should use the `stat` command as follows to determine whether your directory is approaching its limit.

-Examples:

-```console

-[makam@cycrh6rtp07 ~]$ stat bin

-File: 'bin'

-Size: 4096 Blocks: 8 IO Block: 65536 directory

-[makam@cycrh6rtp07 ~]$ stat tmp

-File: 'tmp'

-Size: 12288 Blocks: 24 IO Block: 65536 directory

-

-[makam@cycrh6rtp07 ~]$ stat tmp1

-File: 'tmp1'

-Size: 4096 Blocks: 8 IO Block: 65536 directory

-```

-## `Maxfiles` limits <a name="maxfiles"></a>

-Azure NetApp Files volumes have a value called `maxfiles` that refers to the maximum number of files and folders (also known as inodes) a volume can contain. When the `maxfiles` limit is reached, clients receive "out of space" messages when attempting to create new files or folders. If you experience this issue, contact Microsoft technical support.

-The `maxfiles` limit for an Azure NetApp Files volume is based on the size (quota) of the volume, where the service dynamically adjusts the `maxfiles` limit for a volume based on its provisioned size and uses the following guidelines.

- - If a file is less than 64 bytes in size, it's stored in the inode itself and doesn't use additional capacity. This capacity is only used when files are actually allocated to the volume.

- - Files larger than 64 bytes do consume additional capacity on the volume. For instance, if there are one million files greater than 64 bytes in an Azure NetApp Files volume, then approximately 274 MiB of capacity would belong to the inodes.

-The following table shows examples of the relationship `maxfiles` values based on volume sizes for regular volumes.

-| Volume size | Estimated maxfiles limit |

-| - | - |

-| 0 ΓÇô 683 GiB | 21,251,126 |

-| 1 TiB (1,073,741,824 KiB) | 31,876,709 |

-| 10 TiB (10,737,418,240 KiB) | 318,767,099 |

-| 50 TiB (53,687,091,200 KiB) | 1,593,835,519 |

-| 100 TiB (107,374,182,400 KiB) | 2,147,483,632 |

-The following table shows examples of the relationship `maxfiles` values based on volume sizes for large volumes.

-| Volume size | Estimated maxfiles limit |

-| - | - |

-| 50 TiB (53,687,091,200 KiB) | 1,593,835,512 |

-| 100 TiB (107,374,182,400 KiB) | 3,187,671,024 |

-| 200 TiB (214,748,364,800 KiB) | 6,375,342,024 |

-| 500 TiB (536,870,912,000 KiB) | 15,938,355,048 |

-To see the `maxfiles` allocation for a specific volume size, check the **Maximum number of files** field in the volumeΓÇÖs overview pane.

-You can't set `maxfiles` limits for data protection volumes via a quota request. Azure NetApp Files automatically increases the `maxfiles` limit of a data protection volume to accommodate the number of files replicated to the volume. When a failover happens on a data protection volume, the `maxfiles` limit remains the last value before the failover. In this situation, you can submit a `maxfiles` [quota request](#request-limit-increase) for the volume.

-1. Go to **New Support Request** under **Support + troubleshooting**.

-2. Under the **Problem description** tab, provide the required information:

-3. Under the **Additional details** tab, select **Enter details** in the Request Details field.

-4. To request limit increase, provide the following information in the Quota Details window that appears:

-5. Select **Save and continue**. Select **Review + create** to create the request.

-See [Resource limits for Azure NetApp Files](azure-netapp-files-resource-limits.md#directory-limit) for the limit and calculation.

-No, Azure NetApp Files volumes and capacity pool do not auto-grow upon filling up. See [Cost model for Azure NetApp Files](azure-netapp-files-cost-model.md).

-No, the destination volume of a replication does not count towards hard volume quota.

-No. Azure NetApp Files is not supported by Azure Storage Explorer.

-| BCP338 | Error | Failed to evaluate parameter "{parameterName}": {message} |

-| BCP0346 | Error | Expected a test identifier at this location. |

-| BCP0347 | Error | Expected a test path string at this location. |

-[Bicep CLI version 0.21.X or higher](./install.md) is required to use this compile-time import feature. The experimental flag `compileTimeImports` must be enabled from the [Bicep config file](./bicep-config.md#enable-experimental-features).

-Only user-defined data types that bear the `@export()` decorator can be imported to other templates. Currently, this decorator can only be used on `type` statements.

-The initial number of connections defaults to 5 and is configurable using the `InitialHubServerConnectionCount` option in the SignalR Service SDK. For more information, see [configuration](signalr-howto-use.md#configure-options).

-While the application server is connected to the SignalR service, the Azure SignalR service may send load-balancing messages to the server. Then, the SDK starts new server connections to the service for better performance. Messages to and from clients are multiplexed into these connections.

-1. A client sends a negotiate request to the application server.

-The Azure SignalR Service acts as a logical transport layer between application server and clients. All persistent connections are offloaded to SignalR Service. As a result, the application server only needs to handle the business logic in the hub class, without worrying about client connections.

-| Server-side call management (Call Automation)* | ✔️ |

-| Add/Remove VoIP participants to an in-progress call | ❌ | ✔️ | ✔️ |

-| Get list of participants who joined the in-progress call | ❌ | ✔️ | ✔️ |

-| Send announcements to participants | ❌ | ❌ | ✔️* |

-This tutorial uses [this ARM template](https://raw.githubusercontent.com/Azure-Samples/aci-confidential-hello-world/main/template.json?token=GHSAT0AAAAAAB5B6SJ7VUYU3G6MMQUL7KKKY7QBZBA) as an example. To view the source code for this application, see [Azure Container Instances Confidential Hello World](https://aka.ms/ccacihelloworld).

-> The `ccePolicy` parameter under `confidentialComputeProperties` is blank. You'll fill it in after you generate the policy later in the tutorial.

- "defaultValue": "mcr.microsoft.com/aci/aci-confidential-helloworld:v1",

- az confcom acipolicygen -a .\template.json --print-policy

- When this command finishes, a Base64 string generated as output should appear in the following format. This string is the CCE policy that you copy and paste into your ARM template as the value of the `ccePolicy` property.

- ```output

- cGFja2FnZSBwb2xpY3kKCmFwaV9zdm4gOj0gIjAuOS4wIgoKaW1wb3J0IGZ1dHVyZS5rZXl3b3Jkcy5ldmVyeQppbXBvcnQgZnV0dXJlLmtleXdvcmRzLmluCgpmcmFnbWVudHMgOj0gWwpdCgpjb250YWluZXJzIDo9IFsKICAgIHsKICAgICAgICAiY29tbWFuZCI6IFsiL3BhdXNlIl0sCiAgICAgICAgImVudl9ydWxlcyI6IFt7InBhdHRlcm4iOiAiUEFUSD0vdXNyL2xvY2FsL3NiaW46L3Vzci9sb2NhbC9iaW46L3Vzci9zYmluOi91c3IvYmluOi9zYmluOi9iaW4iLCAic3RyYXRlZ3kiOiAic3RyaW5nIiwgInJlcXVpcmVkIjogdHJ1ZX0seyJwYXR0ZXJuIjogIlRFUk09eHRlcm0iLCAic3RyYXRlZ3kiOiAic3RyaW5nIiwgInJlcXVpcmVkIjogZmFsc2V9XSwKICAgICAgICAibGF5ZXJzIjogWyIxNmI1MTQwNTdhMDZhZDY2NWY5MmMwMjg2M2FjYTA3NGZkNTk3NmM3NTVkMjZiZmYxNjM2NTI5OTE2OWU4NDE1Il0sCiAgICAgICAgIm1vdW50cyI6IFtdLAogICAgICAgICJleGVjX3Byb2Nlc3NlcyI6IFtdLAogICAgICAgICJzaWduYWxzIjogW10sCiAgICAgICAgImFsbG93X2VsZXZhdGVkIjogZmFsc2UsCiAgICAgICAgIndvcmtpbmdfZGlyIjogIi8iCiAgICB9LApdCmFsbG93X3Byb3BlcnRpZXNfYWNjZXNzIDo9IHRydWUKYWxsb3dfZHVtcF9zdGFja3MgOj0gdHJ1ZQphbGxvd19ydW50aW1lX2xvZ2dpbmcgOj0gdHJ1ZQphbGxvd19lbnZpcm9ubWVudF92YXJpYWJsZV9kcm9wcGluZyA6PSB0cnVlCmFsbG93X3VuZW5jcnlwdGVkX3NjcmF0Y2ggOj0gdHJ1ZQoKCm1vdW50X2RldmljZSA6PSB7ICJhbGxvd2VkIiA6IHRydWUgfQp1bm1vdW50X2RldmljZSA6PSB7ICJhbGxvd2VkIiA6IHRydWUgfQptb3VudF9vdmVybGF5IDo9IHsgImFsbG93ZWQiIDogdHJ1ZSB9CnVubW91bnRfb3ZlcmxheSA6PSB7ICJhbGxvd2VkIiA6IHRydWUgfQpjcmVhdGVfY29udGFpbmVyIDo9IHsgImFsbG93ZWQiIDogdHJ1ZSB9CmV4ZWNfaW5fY29udGFpbmVyIDo9IHsgImFsbG93ZWQiIDogdHJ1ZSB9CmV4ZWNfZXh0ZXJuYWwgOj0geyAiYWxsb3dlZCIgOiB0cnVlIH0Kc2h1dGRvd25fY29udGFpbmVyIDo9IHsgImFsbG93ZWQiIDogdHJ1ZSB9CnNpZ25hbF9jb250YWluZXJfcHJvY2VzcyA6PSB7ICJhbGxvd2VkIiA6IHRydWUgfQpwbGFuOV9tb3VudCA6PSB7ICJhbGxvd2VkIiA6IHRydWUgfQpwbGFuOV91bm1vdW50IDo9IHsgImFsbG93ZWQiIDogdHJ1ZSB9CmdldF9wcm9wZXJ0aWVzIDo9IHsgImFsbG93ZWQiIDogdHJ1ZSB9CmR1bXBfc3RhY2tzIDo9IHsgImFsbG93ZWQiIDogdHJ1ZSB9CnJ1bnRpbWVfbG9nZ2luZyA6PSB7ICJhbGxvd2VkIiA6IHRydWUgfQpsb2FkX2ZyYWdtZW50IDo9IHsgImFsbG93ZWQiIDogdHJ1ZSB9CnNjcmF0Y2hfbW91bnQgOj0geyAiYWxsb3dlZCIgOiB0cnVlIH0Kc2NyYXRjaF91bm1vdW50IDo9IHsgImFsbG93ZWQiIDogdHJ1ZSB9CnJlYXNvbiA6PSB7ImVycm9ycyI6IGRhdGEuZnJhbWV3b3JrLmVycm9yc30K

- ```

-2. Save the changes to your local copy of the ARM template.

- If you deploy to hardware that doesn't support a TEE (for example, by choosing a region where Container Instances Confidential isn't available), no attestation report appears.

-* [Confidential Hello World application](https://aka.ms/ccacihelloworld)

-* The Azure container registry must have [Public Access set to either 'Select networks' or 'None'](../container-registry/container-registry-access-selected-networks.md). To set the Azure container registry's Public Access to 'All networks', visit ACI's article on [how to authenticate with ACR with service principal based authentication](container-instances-using-azure-container-registry.md).

-This article helps you better understand Azure cost and usage data included in Cost Management. It explains how frequently data is processed, collected, shown, and closed. You're billed for Azure usage monthly. Although billing cycles are monthly periods, cycle start and end dates vary by subscription type. How often Cost Management receives usage data varies based on different factors. Such factors include how long it takes to process the data and how frequently Azure services emit usage to the billing system.

-Historical data for credit-based and pay-in-advance offers might not match your invoice. Some Azure pay-as-you-go, MSDN, and Visual Studio offers can have Azure credits and advanced payments applied to the invoice. The historical data shown in Cost Management is based on your estimated consumption charges only. Cost Management historical data doesn't include payments and credits. Historical data shown for the following offers might not match exactly with your invoice.

-description: Overview of DNS hosting service on Microsoft Azure. Host your domain on Microsoft Azure.

-# What is Azure DNS?

-Azure DNS is a hosting service for DNS domains that provides name resolution by using Microsoft Azure infrastructure. By hosting your domains in Azure, you can manage your DNS records by using the same credentials, APIs, tools, and billing as your other Azure services.

-You can't use Azure DNS to buy a domain name. For an annual fee, you can buy a domain name by using [App Service domains](../app-service/manage-custom-dns-buy-domain.md#buy-and-map-an-app-service-domain) or a third-party domain name registrar. Your domains then can be hosted in Azure DNS for record management. For more information, see [Delegate a domain to Azure DNS](dns-domain-delegation.md).

-The following features are included with Azure DNS.

-## Reliability and performance

-DNS domains in Azure DNS are hosted on Azure's global network of DNS name servers. Azure DNS uses anycast networking. Each DNS query is answered by the closest available DNS server to provide fast performance and high availability for your domain.

-## Security

- Azure DNS is based on Azure Resource Manager, which provides features such as:

-* [Azure role-based access control (Azure RBAC)](../azure-resource-manager/management/overview.md) to control who has access to specific actions for your organization.

-* [Activity logs](../azure-resource-manager/management/overview.md) to monitor how a user in your organization modified a resource or to find an error when troubleshooting.

-* [Resource locking](../azure-resource-manager/management/lock-resources.md) to lock a subscription, resource group, or resource. Locking prevents other users in your organization from accidentally deleting or modifying critical resources.

-For more information, see [How to protect DNS zones and records](dns-protect-zones-recordsets.md).

-## DNSSEC

-Azure DNS does not currently support DNSSEC. In most cases, you can reduce the need for DNSSEC by consistently using HTTPS/TLS in your applications. If DNSSEC is a critical requirement for your DNS zones, you can host these zones with third-party DNS hosting providers.

-## Ease of use

- Azure DNS can manage DNS records for your Azure services and provide DNS for your external resources as well. Azure DNS is integrated in the Azure portal and uses the same credentials, support contract, and billing as your other Azure services.

-DNS billing is based on the number of DNS zones hosted in Azure and on the number of DNS queries received. To learn more about pricing, see [Azure DNS pricing](https://azure.microsoft.com/pricing/details/dns/).

-Your domains and records can be managed by using the Azure portal, Azure PowerShell cmdlets, and the cross-platform Azure CLI. Applications that require automated DNS management can integrate with the service by using the REST API and SDKs.

-## Customizable virtual networks with private domains

-Azure DNS also supports private DNS domains. This feature allows you to use your own custom domain names in your private virtual networks rather than the Azure-provided names available today.

-For more information, see [Use Azure DNS for private domains](private-dns-overview.md).

-## Alias records

-Azure DNS supports alias record sets. You can use an alias record set to refer to an Azure resource, such as an Azure public IP address, an Azure Traffic Manager profile, or an Azure Content Delivery Network (CDN) endpoint. If the IP address of the underlying resource changes, the alias record set seamlessly updates itself during DNS resolution. The alias record set points to the service instance, and the service instance is associated with an IP address.

-Also, you can now point your apex or naked domain to a Traffic Manager profile or CDN endpoint using an alias record. An example is contoso.com.

-For more information, see [Overview of Azure DNS alias records](dns-alias.md).

-* To learn about DNS zones and records, see [DNS zones and records overview](dns-zones-records.md).

-* To learn how to create a zone in Azure DNS, see [Create a DNS zone](./dns-getstarted-portal.md).

-* For frequently asked questions about Azure DNS, see the [Azure DNS FAQ](dns-faq.yml).

-* [Learn module: Introduction to Azure DNS](/training/modules/intro-to-azure-dns).

-Azure DNS Private Resolver requires an [Azure Virtual Network](../virtual-network/virtual-networks-overview.md). When you create an Azure DNS Private Resolver inside a virtual network, one or more [inbound endpoints](#inbound-endpoints) are established that can be used as the destination for DNS queries. The resolver's [outbound endpoint](#outbound-endpoints) processes DNS queries based on a [DNS forwarding ruleset](#dns-forwarding-rulesets) that you configure. DNS queries that are initiated in networks linked to a ruleset can be sent to other DNS servers.

-No. Azure currently supports reverse DNS only for IPv4 PublicIpAddress resources and Cloud Services.

-The Domain Name System (DNS) is responsible for translating (resolving) a service name to an IP address. Azure DNS is a hosting service for domains and provides naming resolution using the Microsoft Azure infrastructure. Azure DNS not only supports internet-facing DNS domains, but it also supports private DNS zones.

-> As a best practice, do not use a *.local* domain for your private DNS zone. Not all operating systems support this.

-No. If MACsec is configured and a key mismatch occurs, you lose connectivity to Microsoft. In other traffic doesn't fall back to an unencrypted connection, exposing your data.

-* In order to create the connection from the ExpressRoute circuit to the target ExpressRoute virtual network gateway, the number of address spaces advertised from the local or peered virtual networks needs to be equal to or less than **200**. Once the connection has been successfully created, you can add more address spaces, up to 1,000, to the local or peered virtual networks.

- :::image type="content" source="media/premium-migrate/firewall-overview-migrate.png" alt-text="Migrate to firewall policy":::

-When you map an existing domain that is in production, there are things consider. While you're registering your custom domain in the Azure portal, a brief period of downtime for the domain may occur. To avoid interruption of web traffic, map your custom domain to your Front Door default frontend host with the Azure afdverify subdomain first to create a temporary CNAME mapping. Your users can access your domain without interruption when the DNS mapping occurs.

-3. Create a CNAME record entry for your custom domain and complete the fields as shown in the following table (field names may vary):

- - Host: Enter the subdomain of your custom domain to use, including the afdverify subdomain name. For example, afdverify.www.

-After you've registered your custom domain, you can then add it to your Front Door.

-After you've completed the registration of your custom domain, verify that the custom domain references your default Front Door frontend host.

-If you've verified that the afdverify subdomain has been successfully mapped to your Front Door, you can then map the custom domain directly to your default Front Door frontend host.

-3. Create a CNAME record entry for your custom domain and complete the fields as shown in the following table (field names may vary):

-5. If you're previously created a temporary afdverify subdomain CNAME record, delete it.

-1. Go to your DNS provider, delete the CNAME record for the custom domain or update the CNAME record for the custom domain to a non Front Door endpoint.

-The client and server perform a TLS handshake using the TLS certificate you've configured for your custom domain name, or by using the Front Door certificate when the `Host` header ends with `*.azurefd.net`.

-If your domain has enabled the Web Application Firewall, WAF rules are evaluated.

-If your frontend has enabled the Web Application Firewall, WAF rules are evaluated.

-If a rule has been violated, Front Door returns an error to the client and the request processing stops.

-If you have defined [rule sets](front-door-rules-engine.md) for the route, they're executed in the order they're configured. [Rule sets can override the origin group](front-door-rules-engine-actions.md#RouteConfigurationOverride) specified in a route. Rule sets can also trigger a redirection response to the request instead of forwarding it to an origin.

-If you have defined [rules engines](front-door-rules-engine.md) for the route, they're executed in the order they're configured. [Rules engines can override the backend pool](front-door-rules-engine-actions.md#route-configuration-overrides) specified in a routing rule. Rules engines can also trigger a redirection response to the request instead of forwarding it to a backend.

-## Forward request to origin

-## Forward request to backend

-* Support server variables to dynamically change the request header, response headers or URL rewrite paths/query strings. For example, when a new page load or when a form gets posted. Server variable is currently supported in **[rule set actions](front-door-rules-engine-actions.md)** only.

-Rule sets handle requests at the Front Door edge. When a request arrives at your Front Door endpoint, WAF is processed first, followed by the settings configured in route. Those settings include the rule set associated to the route. Rule sets are processed in the order they appear under the routing configuration. Rules in a rule set also get processed in the order they appear. In order for all the actions in each rule to run, all the match conditions within a rule have to be met. If a request doesn't match any of the conditions in your rule set configuration, then only the default route settings get applied.

-* *Action*: An action dictates how Front Door handles the incoming requests based on the matching conditions. You can modify caching behaviors, modify request headers, response headers, set URL rewrite and URL redirection. *Server variables are supported with Action*. A rule can contain up to five actions. A full list of actions can be found in [Rule set actions](front-door-rules-engine-actions.md).

-For information about quota limits, refer to [Front Door limits, quotas and constraints](../azure-resource-manager/management/azure-subscription-service-limits.md#azure-front-door-standard-and-premium-service-limits).

-Rules engine handles requests at the edge. When a request enters your Azure Front Door (classic) endpoint, WAF is processed first, followed by the Rules engine configuration associated with your frontend domain. If a Rules engine configuration gets processed, that means a match condition has been met. In order for all actions in each rule to be processed, all the match conditions within a rule has to be met. If a request doesn't match any of the conditions in your Rules engine configuration, then the default routing configuration is processed.

-Azure Front Door supports URL rewrite to change the request path being routed to your origin. URL rewrite allows you to set conditions to make sure the URL or the specified headers gets rewritten only when certain conditions get met. These conditions are based on the request and response information.

-With this feature, you can redirect your end users to a different origin based on their device types, or the type of file requested. The URL rewrite action can be found in a rule set configuration.

-The **source pattern** is the URL path in the initial request you want to replace. Currently, source pattern uses a prefix-based match. To match all URL paths, you can define a forward slash (`/`) as the source pattern value.

-For the source pattern in a URL rewrite action, only the path after the *patterns to match* in the route configuration is considered. For example, you have the following incoming URL format `contoso.com/pattern-to-match/source-pattern`, only `/source-pattern` gets considered by the rule set as the source pattern to be rewritten. The format of the out going URL after URL rewrite gets applied is `contoso.com/pattern-to-match/destination`.

-For situation, when you need to remove the `/pattern-to-match` segment of the URL, set the **origin path** for the origin group in route configuration to `/`.

-The destination path used to replace the source pattern. For example, if the request URL path is `contoso.com/foo/1.jpg`, the source pattern is `/foo/`, and the destination is `/bar/`, the content gets served from `contoso.com/bar/1.jpg` from the origin.

-Preserve unmatched path allows you to append the remaining path after the source pattern to the new path. When preserve unmatched path is set to **No** (default), the remaining path after the source pattern gets removed.

-Azure Front Door (classic) supports URL rewrite by configuring a **Custom forwarding path** when configuring the forward routing type rule. By default, if only a forward slash (`/*`) is defined, Front Door copies the incoming URL path to the URL used in the forwarded request. The host header used in the forwarded request is as configured for the selected backend. For more information, see [Backend host header](origin.md#origin-host-header).

-The robust part of URL rewrite is the custom forwarding path copies any part of the incoming path that matches the wildcard path to the forwarded path.

-The following table shows an example of an incoming request and the corresponding forwarded path when using a custom forwarding path of `/fwd/` for a match path with a wildcard. The **a/b/c** part of the path represents the portion replacing the wildcard.

-The first column in the following table shows examples of incoming requests and the second column shows what would be the **most-specific** matching route defined. The next three columns in the table are examples of *Custom forwarding paths*.

-For example, the second row reads, for an incoming request of `www.contoso.com/sub`, if the custom forwarding path is `/`, then the forwarded path would be `/sub`. If the custom forwarding path was `/fwd/`, then the forwarded path is `/fwd/sub`. The **emphasized** parts of the paths represent the portions that are part of the wildcard match.

-There are extra optional settings you can also specify for any given routing rule settings:

-* **Cache configuration** - If disabled or not specified, requests that match to this routing rule doesn't attempt to use cached content and instead always fetch from the backend. For more information, see [caching with Azure Front Door](front-door-caching.md).

- * **Endpoint hostname** - A deterministic DNS name that helps prevent subdomain takeover. This name is used to access your resources through your Azure Front Door at the domainΓÇ»`<endpointname>-hash.z01.azurefd.net`.

- * **Domains** - Select one or more domains that have been validated and isn't associated to another route. For more information, see [add a custom domain](standard-premium/how-to-add-custom-domain.md).

- * **Patterns to match** - Configure all URL path patterns that this route accepts. For example, you can set the pattern to match to `/images/*` to accept all requests on the URL `www.contoso.com/images/*`. Azure Front Door determines the traffic based on exact match first. If no paths match exactly, then Front Door looks for a wildcard path that matches. If no routing rules are found with a matching path, then the request get rejected and returns a 400: Bad Request error HTTP response. Patterns to match paths are not case sensitive, meaning paths with different casing are treated as duplicates. For example, you have a host using the same protocol with paths `/FOO` and `/foo`. These paths are considered duplicates, and aren't allowed in the *Patterns to match* field.

- * **WAF Policy** - Select an existing or create a new WAF policy. When you select an existing WAF policy, it must be the same tier as the Front Door profile. For more information, see [configure WAF policy for Front Door](../web-application-firewall/afds/waf-front-door-create-portal.md).

-Origin timeout is the amount of time Azure Front Door waits until it considers the connection to origin has timed out. You can set this value on the overview page of the Azure Front Door profile. This value is applied to all endpoints in the profile.

-When you enable Private Link to your origin in Azure Front Door Premium, Front Door creates a private endpoint on your behalf from an Azure Front Door managed regional private network. You'll receive an Azure Front Door private endpoint request at the origin pending your approval.

-After you enable an origin for Private Link and approve the private endpoint connection, it can take a few minutes for the connection to be established. During this time, requests to the origin will receive an Azure Front Door error message. The error message will go away once the connection is established.

-Once your request is approved, a private IP address gets assigned from the Azure Front Door managed virtual network. Traffic between your Azure Front Door and your origin will communicate using the established private link over the Microsoft backbone network. Incoming traffic to your origin is now secured when arriving at your Azure Front Door.

-Within a single Azure Front Door profile, if two or more Private Link enabled origins are created with the same set of Private Link, resource ID and group ID, then for all such origins only one private endpoint gets created. Connections to the backend can be enabled using this private endpoint. This setup means you only have to approve the private endpoint once because only one private endpoint gets created. If you create more Private Link enabled origins using the same set of Private Link location, resource ID and group ID, you won't need to approve anymore private endpoints.

-For example, a single private endpoint gets created for all the different origins across different origin groups but in the same Azure Front Door profile as shown in the below table:

-When an Azure Front Door profile gets deleted, private endpoints associated with the profile will also get deleted.

-If AFD-Profile-1 gets deleted, then the PE1 private endpoint across all the origins will also be deleted.

-* If AFD-Profile-1 gets deleted, all private endpoints from PE1 through to PE4 will be deleted.

-* Deleting a Front Door profile won't affect private endpoints created for a different Front Door profile.

- :::image type="content" source="./media/private-link/delete-multiple-profiles.png" alt-text="Diagram showing Azure Front Door profile getting deleted won't affect private endpoints in other Front Door profiles.":::

- * If AFD-Profile-2 gets deleted, only PE5 will be removed.

- * If AFD-Profile-3 gets deleted, only PE6 will be removed.

- * If AFD-Profile-4 gets deleted, only PE7 will be removed.

- * If AFD-Profile-5 gets deleted, only PE8 will be removed.

-| US Gov Arizona |||

-| US Gov Texas |||

-* Application Gateway (Preview only. Please do not put production workloads)

-* Review [Secure your origin with Private Link](../private-link.md) to understand how Private Link works with Azure Front Door.

-1. Select an existing or create a new origin group to add an internal load balancer origin.

-1. The *connection state* should change to **Approved**. It may take a couple of minutes for the connection to fully establish. You can now access your internal load balancer from Azure Front Door.

-* Send the request through Azure Front Door and see if you're getting any 503 responses. If not, the problem may not be a timeout issue. Create a support request to troubleshoot the issue further.

-* The backend server returns a certificate that doesn't match the FQDN of the Azure Front Door backend pool.

- - Check if the Azure web app is configured with IP-based SSL instead of being SNI based. If the web app is configured as IP based, it should be changed to SNI.

-* You created a DNS mapping for a custom domain to the frontend host that you configured. Sending a request to the custom domain host name returns an HTTP 400 status code. It doesn't appear to route to the backend that you configured.

-Azure Front Door users the origin host name as the SNI header during SSL handshake. Since the origin is configured as an IP address, the failure can be caused by one of the following reasons:

-* Certificate name check is enabled in the Front Door origin configuration. It's recommended to leave this setting enabled. Certificate name check requires the origin host name to match the certificate name or one of the entries in the subject alternative names extension.

-* If certificate name check is disabled, then the cause is likely due to the origin certificate logic rejecting any requests that don't have a valid host header in the request that matches the certificate.

-description: This article describes the billing model for Azure Front Door and compares the pricing for the Standard, Premium and (classic) tiers.

-Azure Front Door has three tiers: Standard, Premium, and (classic). This article describes the billing model for Azure Front Door and compares the pricing for the Standard, Premium and (classic) tiers. When migrating from Azure Front Door (classic) to Standard or Premium, we recommend you do a cost analysis to understand the pricing differences between the tiers. We show you how to evaluate cost that you can apply your environment.

- | Base fee | - If you need managed WAF rules, bot protection, or Private Link: **$330/month** </br> - If you only need custom WAF rules: **$35/month** |

-| Egress from Azure Front Door edge to origin | $0 | $0.72= 4.5GB * $0.16/GB |

-| Ingress from client to Azure Front Door edge | $0.05 = 4.5GB * $0.01 | $0 |

-| Ingress from origin to Azure Front Door edge | $900 = 0.1 TB * $ 0/GB + 7.5TB * $ 0.12/GB | $0 |

-In this comparison, Azure Front Door Premium is 1.7x more expensive than Azure Front Door (classic) because of the higher base fee for each profile. The outbound data transfer is 45% less for Azure Front Door Premium compared to Azure Front Door (classic). With Premium tier, you don't have to pay for route rules which account for $7,700 of the total cost.

-Machine configuration uses DSC version 3 with PowerShell version 7. DSC version 3 can coexist with

-> [!NOTE]

-> New Azure Montitor integration is in Public Preview across all regions where HDInsight is available.

-To use the Dapr pluggable components, define the component spec for each of the APIs and then [register this to the cluster](https://docs.dapr.io/operations/components/pluggable-components-registration/). The Dapr components listen to a Unix domain socket placed on the shared volume. The Dapr runtime connects with each socket and discovers all services from a given building block API that the component implements.

-> | `metadata.name` | The component name is important and is how a Dapr application references the component. |

-> | `metadata.annotations` | Component annotations used by Dapr sidecar injector, defining the image location and required volume mounts

-> | `spec.type` | [The type of the component](https://docs.dapr.io/operations/components/pluggable-components-registration/#define-the-component), which needs to be declared exactly as shown |

-> | `spec.metadata.keyPrefix` | Defines the key prefix used when communicating to the statestore backend. See the [Dapr documentation](https://docs.dapr.io/developing-applications/building-blocks/state-management/howto-share-state) for more information |

-> | `spec.metadata.hostname` | The MQTT broker hostname. Defaults to `aio-mq-dmqtt-frontend` |

-> | `spec.metadata.tcpPort` | The MQTT broker port number. Default is `8883` |

-> | `spec.metadata.useTls` | Define if TLS is used by the MQTT broker. Defaults to `true` |

-> | `spec.metadata.caFile` | The certificate chain path for validating the MQTT broker. Required if `useTls` is `true`. This file must be mounted in the pod with the specified volume name |

-> | `spec.metadata.satAuthFile ` | The Service Account Token (SAT) file is used to authenticate the Dapr components with the MQTT broker. This file must be mounted in the pod with the specified volume name |

-Now that you have deployed the Dapr components, you can [Use Dapr to develop distributed applications](howto-develop-dapr-apps.md).

-1. To package the application into a container, run the following command:

-The following [Deployment](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/) definition contains the volumes required to deploy the application along with the required containers. This deployment utilizes the Dapr sidecar injector to automatically add the pluggable component pod.

-The yaml contains both a ServiceAccount, used to generate SATs for authentication with MQTT broker and the Dapr application Deployment.

-To create the yaml file, use the following definitions:

-> | `volumes.mqtt-client-token` | The System Authentication Token used for authenticating the Dapr pluggable components with the MQTT broker |

-> | `volumes.aio-ca-trust-bundle` | The chain of trust to validate the MQTT broker TLS cert. This defaults to the test certificate deployed with Azure IoT Operations |

-> | `containers.mq-dapr-app` | The Dapr application container you want to deploy |

- name: mq-dapr-app

- replicas: 1

- app: mq-dapr-app

- app: mq-dapr-app

- dapr.io/app-id: "mq-dapr-app"

- The workload pod should report all pods running after a short interval, as shown in the following example output:

- pod/dapr-workload created

- dapr-workload 3/3 Running 0 30s

-If the application doesn't start or you see the pods in `CrashLoopBackoff`, the logs for `daprd` are most helpful. The `daprd` is a container that automatically deploys with your Dapr application.

-Run the following command to view the logs:

-kubectl logs dapr-workload daprd

-[MQTTnet](https://dotnet.github.io/MQTTnet/) is an open-source, high performance .NET library for MQTT based communication. This article uses a Kubernetes service account token and MQTTnet to connect to MQTT broker. You should use service account tokens to connect to in-cluster clients.

-1. Creates an MQTT client using the `MQTTFactory` class:

-1. The following Kubernetes pod specification mounts the service account token to the specified path on the container file system. The mounted token is used as the password with well-known username `K8S-SAT`:

- string token_path = "/var/run/secrets/tokens/mqtt-client-token";

- static async Task<int> MainAsync()

- {

- ...

- // Read SAT Token

- var satToken = File.ReadAllText(token_path);

-1. All options for the MQTT client are bundled in the class named `MqttClientOptions`. It's possible to fill options manually in code via the properties but you should use the `MqttClientOptionsBuilder` as advised in the [client](https://github.com/dotnet/MQTTnet/wiki/Client) documentation. The following code shows how to use the builder with the following options:

- # Create TCP based options using the builder amd connect to broker

- .WithTcpServer(broker, 1883)

- .WithClientId("sampleid")

- .WithCredentials("K8S-SAT", satToken)

- .Build();

-1. After setting up the MQTT client options, a connection can be established. The following code shows how to connect with a server. You can replace the *CancellationToken.None* with a valid *CancellationToken*, if needed.

- var response = await mqttClient.ConnectAsync(mqttClientOptions, CancellationToken.None);

-1. MQTT messages can be created using the properties directly or via using `MqttApplicationMessageBuilder`. This class has some useful overloads that allow dealing with different payload formats. The API of the builder is a fluent API. The following code shows how to compose an application message and publish them to a topic called *sampletopic*:

- Console.WriteLine("The MQTT client published a message.");

-The `serviceAccountName` field in the pod configuration must match the service account associated with the token being used. Also, note the `serviceAccountToken.expirationSeconds` is set to **86400 seconds**, and once it expires, you need to reload the token from disk. This logic isn't currently implemented in the sample.

- labels:

- app: publisher

- volumes:

- # SAT token used to authenticate between the application and the MQTT broker

- - name: mqtt-client-token

- projected:

- sources:

- - serviceAccountToken:

- path: mqtt-client-token

- audience: aio-mq-dmqtt

- expirationSeconds: 86400

-

- # Certificate chain for the application to validate the MQTT broker

- - name: aio-mq-ca-cert-chain

- configMap:

- name: aio-mq-ca-cert-chain

- - name: mqtt-client-dotnet

- image: ghcr.io/azure-samples/explore-iot-operations/mqtt-client-dotnet:latest

- imagePullPolicy: IfNotPresent

- volumeMounts:

- - name: mqtt-client-token

- mountPath: /var/run/secrets/tokens

- - name: aio-mq-ca-cert-chain

- mountPath: /certs/aio-mq-ca-cert/

- env:

- - name: IOT_MQ_HOST_NAME

- value: "aio-mq-dmqtt-frontend"

- - name: IOT_MQ_PORT

- value: "8883"

- - name: IOT_MQ_TLS_ENABLED

- value: "true"

-The token is mounted into the container at the path specified in `containers[].volumeMount.mountPath`

-1. When data is receiving on the topic, it's forwarded to the MQTT broker state store.

-1. Every **10 seconds**, it fetches the data from the state store and calculates the *min*, *max*, *mean*, *median*, and *75th percentile* values on any sensor data timestamped in the last **30 seconds**.

-1. Data older than **30 seconds** is expired from the state store.

-1. The result is published to the `sensor/window_data` topic in JSON format.

- kubectl get pods -n azure-iot-operations

- NAME READY STATUS RESTARTS AGE

- ...

- mq-event-driven-dapr 3/3 Running 0 30s

-1. Patch BrokerListener to allow unauthenticated connection, to simplify injection of simulated data:

- ```bash

- kubectl patch BrokerListener listener -n azure-iot-operations --type=json -p='[{ "op": "add", "path": "/spec/ports/1", "value": {"port":1883} }]'

- ```

-1. Deploy the simulator from the Explore IoT Operations repository:

-1. Open a shell to the mosquitto client pod:

-The above tutorial uses a prebuilt container of the Dapr application. If you would like to modify and build the code yourself, follow these steps:

-1. Change to the Dapr tutorial directory in the [Explore IoT Operations](https://github.com/Azure-Samples/explore-iot-operations) repository:

-If the application doesn't start or you see the pods in `CrashLoopBackoff`, the logs for `daprd` are most helpful. The `daprd` is a container that is automatically deployed with your Dapr application.

-Run the following command to view the logs:

-kubectl logs dapr-workload daprd

- | `--simulate-pc` | | Include the OPC PLC simulator that ships with the OPC UA connector. |

-To update identity type from SAI to UAI|SAI, you can change type from "user_assigned" to "system_assigned, user_assigned".

-## When should I use Azure Migrate application and code assessment?

-## How to use Azure Migrate application and code assessment for Java

-### Download

-### Get started with appcat

-Unzip the zip file in a folder of your choice. You then get the following directory structure:

-## Discover technology usage and Cloud readiness without an Azure service in mind

-## Assess a Java application

-This release contains the following fixes to the known issues previously on 6.3.0.8, and includes a set of new rules. For more information, see below.

-# Customer intent - overview of the options for assessing an existing VMware deployment for migration

-We're pleased to announce the June 2024 maintenance of the Azure Database for MySQL Flexible Server. This maintenance updates all existing 8.0.34 and, after, engine version servers to the 8.0.37 engine version, along with several security improvements and known issue fixes.

- | Availability Zone | Select **None**. Instead, you can select the zone of the moved resources if applicable. |

- machine.openshift.io/cluster-api-cluster: XXX-XXX-XXX

- machine.openshift.io/cluster-api-cluster: XXX-XXX-XXX

- machine.openshift.io/cluster-api-machineset: XXX-XXX-XXX-XXX-XXX

- machine.openshift.io/cluster-api-cluster: XXX-XXX-XXX

- machine.openshift.io/cluster-api-machineset: XXX-XXX-XXX-XXX-XXX

- node-role.kubernetes.io/<role>: ""

- sku: XXX_XX

- version: XX.XX.XXX

- internalLoadBalancer: ""

- location: useast

- networkResourceGroup: XX-XXXXXX

- publicLoadBalancer: XXX-XXX-XXX

- resourceGroup: aro-fq5v3vye

- sshPrivateKey: ""

- sshPublicKey: ""

- subnet: XXX-XXX

- vnet: XXX-XXX

- zone: "X"

-1. If any other NfApps have DependsOn references to the old user cert-manager NfApp, these will need to be removed.

-2. If any other NfApps reference the old user cert-manager namespace value, this will need to be changed to the new azurehybridnetwork namespace value.

-| Availability zone | [A separated group of datacenters within a region.][availability-zones-overview] Each availability zone is independent of the others, with its own power, cooling, and networking infrastructure. [Many regions support availability zones.][azure-regions-with-availability-zone-support] |

-| Paired regions |A relationship between two Azure regions. [Some Azure regions][azure-region-pairs] are connected to another defined region to enable specific types of multi-region solutions. [Newer Azure regions aren't paired.][regions-with-availability-zones-and-no-region-pair] |

-This article shows how to delete blobs using the [Azure Storage client module for Go](https://pkg.go.dev/github.com/Azure/azure-sdk-for-go/sdk/storage/azblob#section-readme). If you've enabled [soft delete for blobs](soft-delete-blob-overview.md), you can restore deleted blobs during the retention period.

-This article shows how to delete blobs with the [Azure Storage client library for Java](/jav), you can restore deleted blobs during the retention period.

-To delete a blob, call one of these methods:

-This article shows how to delete blobs with the [Azure Storage client library for JavaScript](https://www.npmjs.com/package/@azure/storage-blob). If you've enabled [soft delete for blobs](soft-delete-blob-overview.md), you can restore deleted blobs during the retention period.

-This article shows how to delete blobs using the [Azure Storage client library for Python](/python/api/overview/azure/storage). If you've enabled [soft delete for blobs](soft-delete-blob-overview.md), you can restore deleted blobs during the retention period.

-This article shows how to delete blobs with the [Azure Storage client library for JavaScript](https://www.npmjs.com/package/@azure/storage-blob). If you've enabled [soft delete for blobs](soft-delete-blob-overview.md), you can restore deleted blobs during the retention period.

-This article shows how to delete blobs with the [Azure Storage client library for .NET](/dotnet/api/overview/azure/storage). If you've enabled [soft delete for blobs](soft-delete-blob-overview.md), you can restore deleted blobs during the retention period.

-To delete a blob, call either of these methods:

-| Maximum request rate (Max IOPS) | <ul><li>20,000</li><li>1,000 or 100 requests per 100 ms, default</li></ul> | <ul><li>Baseline IOPS: 3000 + 1 IOPS per GiB, up to 102,400</li><li>IOPS bursting: Max (10,000, 3x IOPS per GiB), up to 102,400</li></ul> |

-| Throughput (ingress + egress) for a single file share (MiB/sec) | <ul><li>Up to storage account limits</li><li>Up to 60 MiB/sec, default</li></ul> | 100 + CEILING(0.04 * ProvisionedStorageGiB) + CEILING(0.06 * ProvisionedStorageGiB) |

-description: Create an Azure Synapse workspace using Azure CLI by following the steps in this guide.

-# Quickstart: Create an Azure synapse workspace with Azure CLI

-In this quickstart, you learn to create a Synapse workspace by using the Azure CLI.

- > The Azure Synapse workspace needs to be able to read and write to the selected ADLS Gen2 account. In addition, for any storage account that you link as the primary storage account, you must have enabled **hierarchical namespace** at the creation of the storage account, as described on the [Create a Storage Account](../storage/common/storage-account-create.md?tabs=azure-portal#create-a-storage-account) page.

-## Create an Azure Synapse workspace using the Azure CLI

-1. Define necessary environment variables to create resources for Azure Synapse workspace.

- | Environment Variable Name | DescriptionΓÇ»|

- |StorageAccountName| Name for your existing ADLS Gen2 storage account.|

- |StorageAccountResourceGroup| Name of your existing ADLS Gen2 storage account resource group. |

- |SynapseResourceGroup| Choose a new name for your Azure Synapse resource group. |

- |SynapseWorkspaceName| Choose a unique name for your new Azure Synapse Workspace. |

-1. Create a resource group as a container for your Azure Synapse workspace:

-1. Create an Azure Synapse Workspace:

-1. Get Web and Dev URL for Azure Synapse Workspace:

-1. Create a Firewall Rule to allow your access to Azure Synapse Workspace from your machine:

-1. Open the Azure Synapse Workspace Web URL address stored in environment variable `WorkspaceWeb` to access your workspace:

- [  ](media/quickstart-create-synapse-workspace-cli/create-workspace-cli-1.png#lightbox)

-1. Once deployed, additional permissions are required.

-Follow the steps below to delete the Azure Synapse workspace.

-> Deleting an Azure Synapse workspace will remove the analytics engines and the data stored in the database of the contained SQL pools and workspace metadata. It will no longer be possible to connect to the SQL or Apache Spark endpoints. All code artifacts will be deleted (queries, notebooks, job definitions and pipelines).

-> Deleting the workspace will **not** affect the data in the Data Lake Store Gen2 linked to the workspace.

-If you want to delete the Azure Synapse workspace, complete the following command:

-## Next steps

-description: Create an Azure Synapse workspace using Azure PowerShell by following the steps in this guide.

-# Quickstart: Create an Azure synapse workspace with Azure PowerShell

-In this quickstart, you learn to create a Synapse workspace using Azure PowerShell.

- > The Azure Synapse workspace needs to be able to read and write to the selected ADLS Gen2

- > account. For any storage account that you link as the primary storage account, you must enable

- > **hierarchical namespace** at the creation of the storage account as described in

- > [Create a storage account](../storage/common/storage-account-create.md?tabs=azure-powershell#create-a-storage-account).

-If you choose to use PowerShell locally, this article requires that you install the Az PowerShell module and connect to your Azure account using the [Connect-AzAccount](/powershell/module/az.accounts/connect-azaccount) cmdlet. For more information about installing the Az PowerShell module, see [Install Azure PowerShell](/powershell/azure/install-azure-powershell).

-> While the **Az.Synapse** PowerShell module is in preview, you must install it separately using the `Install-Module` cmdlet. After this PowerShell module becomes generally available, it will be part of future Az PowerShell module releases and available by default from within Azure Cloud Shell.

-## Create an Azure Synapse workspace using Azure PowerShell

-1. Define necessary environment variables to create resources for Azure Synapse workspace.

- | StorageAccountName | Name for your existing ADLS Gen2 storage account. |

- | StorageAccountResourceGroup | Name of your existing ADLS Gen2 storage account resource group. |

- | SynapseResourceGroup | Choose a new name for your Azure Synapse resource group. |

- | SynapseWorkspaceName | Choose a unique name for your new Azure Synapse Workspace. |

- | ClientIP | Public IP Address of the system you're running PowerShell from. |

-1. Create a resource group as a container for your Azure Synapse workspace:

-1. Create an Azure Synapse Workspace:

-1. Get Web and Dev URL for Azure Synapse Workspace:

-1. Create a Firewall Rule to allow your access to Azure Synapse Workspace from your machine:

-1. Open the Azure Synapse Workspace Web URL address stored in environment variable `WorkspaceWeb` to

- 

-1. Once deployed, additional permissions are required.

-Follow the steps below to delete the Azure Synapse workspace.

-> Deleting an Azure Synapse workspace will remove the analytics engines and the data stored in the

-> database of the contained SQL pools and workspace metadata. It will no longer be possible to

-> connect to the SQL or Apache Spark endpoints. All code artifacts will be deleted (queries,

-> notebooks, job definitions and pipelines). Deleting the workspace will **not** affect the data in

-> the Data Lake Store Gen2 linked to the workspace.

-If the Azure Synapse workspace created in this article isn't needed, you can delete it by running

-the following example.

-## Next steps

-description: Create an Synapse workspace by following the steps in this guide.

-# Quickstart: Create a Synapse workspace

-This quickstart describes the steps to create an Azure Synapse workspace by using the Azure portal.

-## Create a Synapse workspace

-1. Open the [Azure portal](https://portal.azure.com), and at the top search for **Synapse**.

-1. In the **Basics** tab, give the workspace a unique name. We'll use **mysworkspace** in this document

-1. You need an ADLSGEN2 account to create a workspace. The simplest choice is to create a new one. If you want to re-use an existing one you'll need to perform some additional configuration.

-1. OPTION 1 Creating a new ADLSGEN2 account

- 1. Under **Select Data Lake Storage Gen 2 / Account Name**, click **Create New** and provide a global unique name, such as **contosolake**.

- 1. Under **Select Data Lake Storage Gen 2 / File system name**, click **File System** and name it **users**.

-1. OPTION 2 See the [**Prepare a Storage Account**](#prepare-an-existing-storage-account-for-use-with-azure-synapse-analytics) instructions at the bottom of this document.

-1. Your Azure Synapse workspace will use this storage account as the "primary" storage account and the container to store workspace data. The workspace stores data in Apache Spark tables. It stores Spark application logs under a folder called **/synapse/workspacename**.

-> After creating your Azure Synapse workspace, you will not be able to move the workspace to another Microsoft Entra tenant. If you do so through subscription migration or other actions, you may lose access to the artifacts within the workspace.

-After your Azure Synapse workspace is created, you have two ways to open Synapse Studio:

-* Open your Synapse workspace in the [Azure portal](https://portal.azure.com). On the top of the **Overview** section, select **Launch Synapse Studio**.

-* Go to the `https://web.azuresynapse.net` and sign in to your workspace.

-1. Navigate to an existing ADLSGEN2 storage account

-1. Select **Add** > **Add role assignment** to open the Add role assignment page.

-1. Assign the following role. For detailed steps, see [Assign Azure roles using the Azure portal](../role-based-access-control/role-assignments-portal.yml).

- | Members | your user name |

- 

-1. You can give the container any name. In this document, we'll name the container **users**.

-Managed identities for your Azure Synapse workspace might already have access to the storage account. Follow these steps to make sure:

-1. Select **Add** > **Add role assignment** to open the Add role assignment page.

-1. Assign the following role. For detailed steps, see [Assign Azure roles using the Azure portal](../role-based-access-control/role-assignments-portal.yml).

- 

-## Next steps

-* [Use serverless SQL pool](quickstart-sql-on-demand.md)

-description: Learn how to create a Synapse workspace by using Azure Resource Manager template (ARM template).

-# Quickstart: Create an Azure Synapse workspace using an ARM template

-This Azure Resource Manager (ARM) template will create an Azure Synapse workspace with underlying Data Lake Storage. The Azure Synapse workspace is a securable collaboration boundary for analytics processes in Azure Synapse Analytics.

-If your environment meets the prerequisites and you're familiar with using ARM templates, select the **Deploy to Azure** button. The template will open in the Azure portal.

-To create an Azure Synapse workspace, a user must have **Azure Contributor** role and **User Access Administrator** permissions, or the **Owner** role in the subscription. For detailed steps, see [Assign Azure roles using the Azure portal](../role-based-access-control/role-assignments-portal.yml).

-1. Select the following image to sign in to Azure and open the template. This template creates a Synapse workspace.

- :::image type="content" source="~/reusable-content/ce-skilling/azure/media/template-deployments/deploy-to-azure-button.svg" alt-text="Button to deploy the Resource Manager template to Azure." border="false" link="https://portal.azure.com/#create/Microsoft.Template/uri/https%3A%2F%2Fraw.githubusercontent.com%2FAzure-Samples%2FSynapse%2Fmaster%2FManage%2FDeployWorkspace%2Fazuredeploy.json":::

- - **Resource group**: Select **Create new** and enter a unique name for the resource group and select **OK**. A new resource group will facilitate resource clean up.

- - **Region**: Select a region. For example, **Central US**.

-1. Once deployed, additional permissions are required.

-## Next steps

-To learn more about Azure Synapse Analytics and Azure Resource Manager,

-This article provides a guide to start using Azure Update Manager (for update management) for virtual machines that are currently using Microsoft Configuration Manager (MCM).

-Before initiating migration, you need to understand mapping between System Center components and equivalent services in Azure.

-| System Center Configuration Manager (SCCM), now called Microsoft Configuration Manager (MCM) | Azure Update Manager, </br> Change Tracking and Inventory, </br> Guest Config, </br> Azure Automation, </br> Desired State Configuration (DSC), </br> Defender for Cloud |

-| Public | 1.0.2311.2004 | [MMR extension](https://aka.ms/avdmmr/msi) |

-## Attaching a VM to a Virtual Machine Scale Set

-> You can only attach Virtual Machines (VMs) to a Virtual Machine Scale Set in **Flexible orchestration mode**. For more information, see [Orchestration modes for Virtual Machine Scale Sets](./virtual-machine-scale-sets-orchestration-modes.md).

-There are times where you need to attach a virtual machine to a Virtual Machine Scale Set to benefit from the scale, availability, and flexibility that comes with scale sets. There are two ways to attach VMs to scale sets: manually create a new standalone VM in the scale set or attach an existing VM to the scale set.

-### Attach a new VM to a Virtual Machine Scale Set

-1. Select **Create**

-### Exceptions to attaching a new VM to a Virtual Machine Scale Set

-### Attach an existing VM to a Virtual Machine Scale Set (Preview)

-#### Enroll in the Preview

-Register for the `SingleFDAttachDetachVMToVmss` feature flag using the [az feature register](/cli/azure/feature#az-feature-register) command:

-```azurecli-interactive

-az feature register --namespace "Microsoft.Compute" --name "SingleFDAttachDetachVMToVmss"

-```

-It takes a few minutes for the feature to register. Verify the registration status by using the [az feature show](/cli/azure/feature#az-feature-register) command:

-```azurecli-interactive

-az feature show --namespace "Microsoft.Compute" --name "SingleFDAttachDetachVMToVmss"

-```

-5. The **Attach to a VMSS** blade will appear on the right side of the page. Select the scale set you'd like to attach the VM to in the **Select a VMSS dropdown**.

-### Limitations for attaching an existing VM to a scale set

-## Detaching a VM from a Virtual Machine Scale Set (Preview)

-> [!NOTE]

-> Detaching VMs created by the scale set will require the VM to be `Stopped` before the detach. VMs that were previously attached to the scale set can be detached while running.

-2. If your VM was created by the scale set, ensure the VM is `Stopped`. If the VM was created as a standalone VM, you can continue regardless of if the VM is `Running` or `Stopped`.

-### Limitations for detaching a VM from a scale set

-## Moving VMs between scale sets (Preview)

-1. [Detach](#detaching-a-vm-from-a-virtual-machine-scale-set-preview) the VM from scale set A.

-2. Once the detach completes, [attach](#attach-an-existing-vm-to-a-virtual-machine-scale-set-preview) the VM to scale set B.

-The limitations for VMs to be [attached](#limitations-for-attaching-an-existing-vm-to-a-scale-set) or [detached](#limitations-for-detaching-a-vm-from-a-scale-set) to or from a scale set remain the same.

-### Attach an existing VM to an existing scale set troubleshooting (Preview)

-| Referenced Virtual Machine Scale Set '{vmssName}' does not support attaching an existing Virtual Machine to it. For more information, see https://aka.ms/vmo/attachdetach. | The subscription isn't enrolled in the VM Attach Detach Preview. | Ensure that your subscription is enrolled in the feature. Reference the [documentation](#enroll-in-the-preview) to check if you're enrolled. |

-| Referenced Virtual Machine Scale Set '{vmssName}' does not support attaching an existing Virtual Machine to it because the Virtual Machine Scale Set has more than 1 fault domains. For more information, see https://aka.ms/vmo/attachdetach. | `VmssDoesNotSupportAttachingExistingVMMultiFD`: The attach of the VM failed because the VM was trying to attach to a scale set with a platform fault domain count of more than 1.| VMs can only be attached to scale sets with a `platform fault domain count` of 1. Try attaching to a scale set with a platform fault domain count of 1, rather than a scale set with a platform fault domain count of more than 1. |

-| Referenced Virtual Machine '{vmName}' belongs to a proximity placement group (PPG) and attaching to a Virtual Machine Scale Set is not supported. For more information, see https://aka.ms/vmo/attachdetach. | `VmssDoesNotSupportAttachingPPGVM`: The attach of the VM failed because the VM is part of a Proximity Placement Group. | VMs from a Proximity Placement Group can't be attached to a scale set. [Remove the VM from the Proximity Placement Group](../virtual-machines/windows/proximity-placement-groups.md#move-an-existing-vm-out-of-a-proximity-placement-group) and then try to attach to the scale set. See the documentation to learn about how to move a VM out of a Proximity Placement Group. |

-### Detach a VM from a scale set troubleshooting (Preview)

-| Virtual Machine Scale Set does not support detaching of Virtual Machines from it. For more information, see https://aka.ms/vmo/attachdetach. | The subscription isn't enrolled in the VM Attach Detach Preview. | Ensure that your subscription is enrolled in the feature. Reference the [documentation](#enroll-in-the-preview) to check if you're enrolled. |

-| Virtual Machine Scale Set '{vmssName}' does not support detaching an existing Virtual Machine from it because the Virtual Machine Scale Set has more than 1 fault domains. For more information, see https://aka.ms/vmo/attachdetach. | The detach of the VM failed because the scale set it's in has more than 1 platform fault domain. | VMs can only be detached from scale sets with a `platform fault domain count` of 1. |

-| Virtual Machine was created with a Virtual Machine Scale Set association and must be deallocated before being detached. Deallocate the virtual machine and ensure that the resource is in deallocated power state before retrying detach operation. For more information, see https://aka.ms/vmo/attachdetach. | `VmssDoesNotSupportDetachNonDeallocatedVM`: Virtual Machines created by the Virtual Machine Scale Set with Flexible Orchestration Mode must be deallocated before being detached from the scale set. | Deallocate the VM and ensure that the resource is in a `deallocated` power state before retrying the detach operation. |

-> [!IMPORTANT]

-> The **Reimage** and **Restart** repair actions are currently in PREVIEW.

-> See the [Supplemental Terms of Use for Microsoft Azure Previews](https://azure.microsoft.com/support/legal/preview-supplemental-terms/) for legal terms that apply to Azure features that are in beta, preview, or otherwise not yet released into general availability. Some aspects of this feature may change prior to general availability (GA).

-Enabling automatic instance repairs for Azure Virtual Machine Scale Sets helps achieve high availability for applications by maintaining a set of healthy instances. If an unhealthy instance is found by [Application Health extension](./virtual-machine-scale-sets-health-extension.md) or [Load balancer health probes](../load-balancer/load-balancer-custom-probe-overview.md), automatic instance repairs will attempt to recover the instance by triggering repair actions such as deleting the unhealthy instance and creating a new one to replace it, reimaging the unhealthy instance (Preview), or restarting the unhealthy instance (Preview).

-The `repairAction` setting for Reimage (Preview) and Restart (Preview) is supported for compute API versions 2021-11-01 or higher.

-> [!CAUTION]

-> The `repairAction` setting, is currently under PREVIEW and not suitable for production workloads. To preview the **Restart** and **Reimage** repair actions, you must register your Azure subscription with the AFEC flag `AutomaticRepairsWithConfigurableRepairActions` and your compute API version must be 2021-11-01 or higher.

-> For more information, see [feature registration](#feature-registration).

-There are three available repair actions for automatic instance repairs ΓÇô Replace, Reimage (Preview), and Restart (Preview). The default repair action is Replace, but you can switch to Reimage (Preview) or Restart (Preview) by enrolling in the preview and modifying the `repairAction` setting under `automaticRepairsPolicy` object.

-| Replace | No | No | No | No | No |

-## Feature Registration

-Before configuring `repairAction` setting under `automaticRepairsPolicy`, register the feature providers to your subscription.

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

-```azurecli-interactive

-az feature register --name AutomaticRepairsWithConfigurableRepairActions --namespace Microsoft.Compute

-```

-### [Azure PowerShell](#tab/powershell-3)

-```azurepowershell-interactive

-Register-AzProviderFeature -FeatureName "AutomaticRepairsWithConfigurableRepairActions" -ProviderNamespace "Microsoft.Compute"

-```

-> [!CAUTION]

-> The `repairAction` setting, is currently under PREVIEW and not suitable for production workloads. To preview the **Restart** and **Reimage** repair actions, you must register your Azure subscription with the AFEC flag `AutomaticRepairsWithConfigurableRepairActions` and your compute API version must be 2021-11-01 or higher.

-> For more information, see [feature registration](#feature-registration).

-| Add/remove existing VM to the group | No | No | No |

-Unlike other managed disks, the performance of Premium SSD v2 disks can be configured independently of its size by using the Azure CLI and PowerShell. Making adjustments to disk performance by using the Azure portal is not currently supported. You can adjust the performance of a Premium SSD v2 disk four times within a 24 hour period.

-Currently, adjusting disk performance is only supported with the Azure CLI or Azure PowerShell module.

-The price of an Azure Ultra Disk is determined by the combination of how large the disk is (its size) and what performance you select (IOPS and throughput) for your disk. If you share an Ultra Disk between multiple VMs that can affect its price as well. The following sections focus on these factors as they relate to the price of your Ultra Disk. For more information on how these factors work, see the [Ultra disks](disks-types.md#ultra-disks) section of the [Azure managed disk types](disks-types.md) article.

-The size of your Ultra Disk also determines what performance caps your disk has. You have granular control of how much IOPS and throughput your disk has, up to that size's performance cap. Pricing increases as you increase your disk's size, and when you set higher IOPS and throughput. Ultra Disks offer up to 32 TiB per region per subscription by default, but support higher size by request. To request an increase in size, request a quota increase or contact Azure Support.

-Premium Storage: Supported<br>

-Premium Storage caching: Supported<br>

-Premium Storage: Supported<br>

-Premium Storage caching: Supported<br>

-Premium Storage: Supported<br>

-Premium Storage caching: Supported<br>

-> Eviction rates are quoted _per hour_. For example, an eviction rate of 10% means a VM has a 10% chance of being evicted within the next hour, based on historical eviction data of the last 28 days.

-First create a resource group for all the resources created in this article with [az group create](/cli/azure/group). The following example creates a resource group in the *eastus* location:

- --name myResourceGroup \

- --location eastus

- --resource-group myResourceGroup \

- --name myAsgWebServers \

- --location eastus

- --resource-group myResourceGroup \

- --name myAsgMgmtServers \

- --location eastus

-Create a network security group with [az network nsg create](/cli/azure/network/nsg). The following example creates a network security group named *myNsg*:

- --resource-group myResourceGroup \

- --name myNsg

-Create a security rule with [az network nsg rule create](/cli/azure/network/nsg/rule). The following example creates a rule that allows traffic inbound from the internet to the *myWebServers* application security group over ports 80 and 443:

- --resource-group myResourceGroup \

- --nsg-name myNsg \

- --destination-asgs "myAsgWebServers" \

-The following example creates a rule that allows traffic inbound from the Internet to the *myMgmtServers* application security group over port 22:

- --resource-group myResourceGroup \

- --nsg-name myNsg \

- --destination-asgs "myAsgMgmtServers" \

-In this article, SSH (port 22) is exposed to the internet for the *myAsgMgmtServers* VM. For production environments, instead of exposing port 22 to the internet, it's recommended that you connect to Azure resources that you want to manage using a [VPN](../vpn-gateway/vpn-gateway-about-vpngateways.md?toc=%2fazure%2fvirtual-network%2ftoc.json) or [private](../expressroute/expressroute-introduction.md?toc=%2fazure%2fvirtual-network%2ftoc.json) network connection.

-Create a virtual network with [az network vnet create](/cli/azure/network/vnet). The following example creates a virtual named *myVirtualNetwork*:

- --name myVirtualNetwork \

- --resource-group myResourceGroup \

-Add a subnet to a virtual network with [az network vnet subnet create](/cli/azure/network/vnet/subnet). The following example adds a subnet named *mySubnet* to the virtual network and associates the *myNsg* network security group to it:

- --vnet-name myVirtualNetwork \

- --resource-group myResourceGroup \

- --name mySubnet \

- --network-security-group myNsg

-Create a VM with [az vm create](/cli/azure/vm). The following example creates a VM that will serve as a web server. The `--asgs myAsgWebServers` option causes Azure to make the network interface it creates for the VM a member of the *myAsgWebServers* application security group.

-The `--nsg ""` option is specified to prevent Azure from creating a default network security group for the network interface Azure creates when it creates the VM. To streamline this article, a password is used. Keys are typically used in production deployments. If you use keys, you must also configure SSH agent forwarding for the remaining steps. For more information, see the documentation for your SSH client. Replace `<replace-with-your-password>` in the following command with a password of your choosing.

-adminPassword="<replace-with-your-password>"

- --resource-group myResourceGroup \

- --name myVmWeb \

- --vnet-name myVirtualNetwork \

- --subnet mySubnet \

- --asgs myAsgWebServers \

- --admin-password $adminPassword

- "id": "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/myResourceGroup/providers/Microsoft.Compute/virtualMachines/myVmWeb",

- "location": "eastus",

- "publicIpAddress": "13.90.242.231",

- "resourceGroup": "myResourceGroup"

-Take note of the **publicIpAddress**. This address is used to access the VM from the internet in a later step. Create a VM to serve as a management server:

- --resource-group myResourceGroup \

- --name myVmMgmt \

- --vnet-name myVirtualNetwork \

- --subnet mySubnet \

- --asgs myAsgMgmtServers \

- --admin-password $adminPassword

-The VM takes a few minutes to create. After the VM is created, note the **publicIpAddress** in the returned output. This address is used to access the VM in the next step. Don't continue with the next step until Azure finishes creating the VM.

-Use the command that follows to create an SSH session with the *myVmMgmt* VM. Replace *\<publicIpAddress>* with the public IP address of your VM. In the example above, the IP address is *13.90.242.231*.

-```bash

-ssh azureuser@<publicIpAddress>

-When prompted for a password, enter the password you entered in [Create VMs](#create-virtual-machines).

-The connection succeeds, because port 22 is allowed inbound from the Internet to the *myAsgMgmtServers* application security group that the network interface attached to the *myVmMgmt* VM is in.

-Use the following command to SSH to the *myVmWeb* VM from the *myVmMgmt* VM:

-ssh azureuser@myVmWeb

-The connection succeeds because a default security rule within each network security group allows traffic over all ports between all IP addresses within a virtual network. You can't SSH to the *myVmWeb* VM from the Internet because the security rule for the *myAsgWebServers* doesn't allow port 22 inbound from the Internet.

-Use the following commands to install the nginx web server on the *myVmWeb* VM:

-The *myVmWeb* VM is allowed outbound to the Internet to retrieve nginx because a default security rule allows all outbound traffic to the Internet. Exit the *myVmWeb* SSH session, which leaves you at the `username@myVmMgmt:~$` prompt of the *myVmMgmt* VM. To retrieve the nginx welcome screen from the *myVmWeb* VM, enter the following command:

-curl myVmWeb

-Logout of the *myVmMgmt* VM. To confirm that you can access the *myVmWeb* web server from outside of Azure, enter `curl <publicIpAddress>` from your own computer. The connection succeeds, because port 80 is allowed inbound from the Internet to the *myAsgWebServers* application security group that the network interface attached to the *myVmWeb* VM is in.

-az group delete --name myResourceGroup --yes

-Azure routes traffic between subnets by default. You may instead, choose to route traffic between subnets through a VM, serving as a firewall, for example. To learn how, see [Create a route table](tutorial-create-route-table-cli.md).

-description: In this article, you learn how to limit and restrict network access to Azure resources, such as Azure Storage and Azure SQL Database, with virtual network service endpoints using the Azure CLI.

-Before creating a virtual network, you have to create a resource group for the virtual network, and all other resources created in this article. Create a resource group with [az group create](/cli/azure/group). The following example creates a resource group named *myResourceGroup* in the *eastus* location.

- --name myResourceGroup \

- --name myVirtualNetwork \

- --resource-group myResourceGroup \

- --subnet-name Public \

-Create an additional subnet in the virtual network with [az network vnet subnet create](/cli/azure/network/vnet/subnet). In this example, a service endpoint for *Microsoft.Storage* is created for the subnet:

- --vnet-name myVirtualNetwork \

- --resource-group myResourceGroup \

- --name Private \

-Create a network security group with [az network nsg create](/cli/azure/network/nsg). The following example creates a network security group named *myNsgPrivate*.

- --resource-group myResourceGroup \

- --name myNsgPrivate

-Associate the network security group to the *Private* subnet with [az network vnet subnet update](/cli/azure/network/vnet/subnet). The following example associates the *myNsgPrivate* network security group to the *Private* subnet:

- --vnet-name myVirtualNetwork \

- --name Private \

- --resource-group myResourceGroup \

- --network-security-group myNsgPrivate

- --resource-group myResourceGroup \

- --nsg-name myNsgPrivate \

- --resource-group myResourceGroup \

- --nsg-name myNsgPrivate \

- --resource-group myResourceGroup \

- --nsg-name myNsgPrivate \

- --resource-group myResourceGroup \

- --resource-group myResourceGroup \

- --name my-file-share \

-By default, storage accounts accept network connections from clients in any network. To limit access to selected networks, change the default action to *Deny* with [az storage account update](/cli/azure/storage/account). Once network access is denied, the storage account is not accessible from any network.

- --resource-group myResourceGroup \

-Allow network access to the storage account from the *Private* subnet with [az storage account network-rule add](/cli/azure/storage/account/network-rule).

- --resource-group myResourceGroup \

- --vnet-name myVirtualNetwork \

- --subnet Private

-Create a VM in the *Public* subnet with [az vm create](/cli/azure/vm). If SSH keys do not already exist in a default key location, the command creates them. To use a specific set of keys, use the `--ssh-key-value` option.

- --resource-group myResourceGroup \

- --name myVmPublic \

- --vnet-name myVirtualNetwork \

- --subnet Public \

- "id": "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/myResourceGroup/providers/Microsoft.Compute/virtualMachines/myVmPublic",

- "publicIpAddress": "13.90.242.231",

- "resourceGroup": "myResourceGroup"

-Take note of the **publicIpAddress** in the returned output. This address is used to access the VM from the internet in a later step.

- --resource-group myResourceGroup \

- --name myVmPrivate \

- --vnet-name myVirtualNetwork \

- --subnet Private \

-SSH into the *myVmPrivate* VM. Replace *\<publicIpAddress>* with the public IP address of your *myVmPrivate* VM.

-ssh <publicIpAddress>

-sudo mkdir /mnt/MyAzureFileShare

-sudo mount --types cifs //<storage-account-name>.file.core.windows.net/my-file-share /mnt/MyAzureFileShare --options vers=3.0,username=<storage-account-name>,password=<storage-account-key>,dir_mode=0777,file_mode=0777,serverino

-You receive the `user@myVmPrivate:~$` prompt. The Azure file share successfully mounted to */mnt/MyAzureFileShare*.

-You receive no replies, because the network security group associated to the *Private* subnet does not allow outbound access to public IP addresses other than the addresses assigned to the Azure Storage service.

-Exit the SSH session to the *myVmPrivate* VM.

-Use the following command to create an SSH session with the *myVmPublic* VM. Replace `<publicIpAddress>` with the public IP address of your *myVmPublic* VM:

-ssh <publicIpAddress>

-sudo mkdir /mnt/MyAzureFileShare

-Attempt to mount the Azure file share to the directory you created. This article assumes you deployed the latest version of Ubuntu. If you are using earlier versions of Ubuntu, see [Mount on Linux](../storage/files/storage-how-to-use-files-linux.md?toc=%2fazure%2fvirtual-network%2ftoc.json) for additional instructions about mounting file shares. Before running the following command, replace `<storage-account-name>` with the account name and `<storage-account-key>` with the key you retrieved in [Create a storage account](#create-a-storage-account):

-sudo mount --types cifs //storage-account-name>.file.core.windows.net/my-file-share /mnt/MyAzureFileShare --options vers=3.0,username=<storage-account-name>,password=<storage-account-key>,dir_mode=0777,file_mode=0777,serverino

-Access is denied, and you receive a `mount error(13): Permission denied` error, because the *myVmPublic* VM is deployed within the *Public* subnet. The *Public* subnet does not have a service endpoint enabled for Azure Storage, and the storage account only allows network access from the *Private* subnet, not the *Public* subnet.

-Exit the SSH session to the *myVmPublic* VM.

-Access is denied and you receive a *This request is not authorized to perform this operation* error, because your computer is not in the *Private* subnet of the *MyVirtualNetwork* virtual network.

-az group delete --name myResourceGroup --yes

-If you have multiple virtual networks in your account, you may want to connect two virtual networks together so the resources within each virtual network can communicate with each other. To learn how, see [Connect virtual networks](tutorial-connect-virtual-networks-cli.md).

-description: Learn how to set up a Microsoft Entra tenant for P2S OpenVPN authentication and register multiple apps in Microsoft Entra ID to allow different access for different users and groups.

-# Configure P2S for access based on users and groups - Microsoft Entra ID authentication - manual app registration

-When you use Microsoft Entra ID as the authentication method for point-to-site (P2S), you can configure P2S to allow different access for different users and groups. This article helps you set up a Microsoft Entra tenant for P2S Microsoft Entra authentication and create and register multiple VPN apps in Microsoft Entra ID to allow different access for different users and groups. For more information about P2S protocols and authentication, see [About point-to-site VPN](point-to-site-about.md).

-Considerations:

-* You can't create this type of granular access if you have only one VPN gateway.

-* To assign different users and groups different access, register multiple apps with Microsoft Entra ID and then link them to different VPN gateways.

-* Microsoft Entra ID authentication is supported only for OpenVPN® protocol connections and requires the Azure VPN Client.

-<a name='azure-ad-tenant'></a>

-## Microsoft Entra tenant

-The steps in this article require a Microsoft Entra tenant. If you don't have a Microsoft Entra tenant, you can create one using the steps in the [Create a new tenant](../active-directory/fundamentals/active-directory-access-create-new-tenant.md) article. Note the following fields when creating your directory:

-* Organizational name

-* Initial domain name

-<a name='create-azure-ad-tenant-users'></a>

-## Create Microsoft Entra tenant users

-1. Create two accounts in the newly created Microsoft Entra tenant. For steps, see [Add or delete a new user](../active-directory/fundamentals/add-users-azure-active-directory.md).

- * Global administrator account

- * User account

- The global administrator account is used to grant consent to the Azure VPN app registration. The user account can be used to test OpenVPN authentication.

-1. Assign one of the accounts the **Global administrator** role. For steps, see [Assign user roles with Microsoft Entra ID](/entra/fundamentals/users-assign-role-azure-portal).

-## Authorize the Azure VPN application

-## Register additional applications

-In this section, you can register additional applications for various users and groups. Repeat the steps to create as many applications that are needed for your security requirements.

-* You must have more than one VPN gateway to configure this type of granular access.

-* Each application is associated to a different VPN gateway and can have a different set of users.

-### Add a scope

-1. In the Azure portal, select **Microsoft Entra ID**.

-1. In the left pane, select **App registrations**.

-1. At the top of the **App registrations** page, select **+ New registration**.

-1. On the **Register an application** page, enter the **Name**. For example, MarketingVPN or Group1. You can always change the name later.

- * Select the desired **Supported account types**.

- * At the bottom of the page, click **Register**.

-1. Once the new app has been registered, in the left pane, click **Expose an API**. Then click **+ Add a scope**.

- * On the **Add a scope** page, leave the default **Application ID URI**.

- * Click **Save and continue**.

-1. The page returns back to the **Add a scope** page. Fill in the required fields and ensure that **State** is **Enabled**.

- :::image type="content" source="./media/openvpn-azure-ad-tenant-multi-app/add-scope.png" alt-text="Screenshot of Microsoft Entra ID add a scope page." lightbox="./media/openvpn-azure-ad-tenant-multi-app/add-scope.png":::

-1. When you're done filling out the fields, click **Add scope**.

-### Add a client application

-1. On the **Expose an API** page, click **+ Add a client application**.

-1. On the **Add a client application** page, for **Client ID**, enter the following values depending on the cloud:

- * Azure Public: `41b23e61-6c1e-4545-b367-cd054e0ed4b4`

- * Azure Government: `51bb15d4-3a4f-4ebf-9dca-40096fe32426`

- * Azure Germany: `538ee9e6-310a-468d-afef-ea97365856a9`

- * Microsoft Azure operated by 21Vianet: `49f817b6-84ae-4cc0-928c-73f27289b3aa`

-1. Select the checkbox for the **Authorized scopes** to include. Then, click **Add application**.

- :::image type="content" source="./media/openvpn-azure-ad-tenant-multi-app/add-application.png" alt-text="Screenshot of Microsoft Entra ID add client application page." lightbox="./media/openvpn-azure-ad-tenant-multi-app/add-application.png":::

-1. Click **Add application**.

-### Copy Application (client) ID

-When you enable authentication on the VPN gateway, you'll need the **Application (client) ID** value in order to fill out the Audience value for the point-to-site configuration.

-1. Go to the **Overview** page.

-1. Copy the **Application (client) ID** from the **Overview** page and save it so that you can access this value later. You'll need this information to configure your VPN gateways.

- :::image type="content" source="./media/openvpn-azure-ad-tenant-multi-app/client-id.png" alt-text="Screenshot showing Client ID value." lightbox="./media/openvpn-azure-ad-tenant-multi-app/client-id.png":::

-## Assign users to applications

-Assign the users to your applications. If you're specifying a group, the user must be a direct member of the group. Nested groups aren't supported.

-1. Go to your Microsoft Entra ID and select **Enterprise applications**.

-1. From the list, locate the application you registered and click to open it.

-1. Click **Properties**. On the **Properties** page, verify that **Enabled for users to sign in** is set to **Yes**. If not, change the value to **Yes**.

-1. For **Assignment required**, change the value to **Yes**. For more information about this setting, see [Application properties](../active-directory/manage-apps/application-properties.md#enabled-for-users-to-sign-in).

-1. If you've made changes, click **Save** to save your settings.

-1. In the left pane, click **Users and groups**. On the **Users and groups** page, click **+ Add user/group** to open the **Add Assignment** page.

-1. Click the link under **Users and groups** to open the **Users and groups** page. Select the users and groups that you want to assign, then click **Select**.

-1. After you finish selecting users and groups, click **Assign**.

-## Configure authentication for the gateway

-> [!IMPORTANT]

-> [!INCLUDE [Entra ID note for portal pages](../../includes/vpn-gateway-entra-portal-note.md)]

-In this step, you configure P2S Microsoft Entra authentication for the virtual network gateway.

-1. Go to the virtual network gateway. In the left pane, click **Point-to-site configuration**.

- :::image type="content" source="./media/openvpn-azure-ad-tenant-multi-app/enable-authentication.png" alt-text="Screenshot showing point-to-site configuration page." lightbox="./media/openvpn-azure-ad-tenant-multi-app/enable-authentication.png":::

- Configure the following values:

- * **Address pool**: client address pool

- * **Tunnel type:** OpenVPN (SSL)

- * **Authentication type**: Microsoft Entra ID

- For **Microsoft Entra ID** values, use the following guidelines for **Tenant**, **Audience**, and **Issuer** values.

- * **Tenant**: `https://login.microsoftonline.com/{TenantID}`

- * **Audience ID**: Use the value that you created in the previous section that corresponds to **Application (client) ID**. Don't use the application ID for "Azure VPN" Microsoft Entra Enterprise App - use application ID that you created and registered. If you use the application ID for the "Azure VPN" Microsoft Entra Enterprise App instead, this grants all users access to the VPN gateway (which would be the default way to set up access), instead of granting only the users that you assigned to the application that you created and registered.

- * **Issuer**: `https://sts.windows.net/{TenantID}` For the Issuer value, make sure to include a trailing **/** at the end.

-1. Once you finish configuring settings, click **Save** at the top of the page.

-## Download the Azure VPN Client profile configuration package

-In this section, you generate and download the Azure VPN Client profile configuration package. This package contains the settings that you can use to configure the Azure VPN Client profile on client computers.

-## Next steps

-* To connect to your virtual network, you must configure the Azure VPN client on your client computers. See [Configure a VPN client for P2S VPN connections](point-to-site-entra-vpn-client-windows.md).

-* For frequently asked questions, see the **Point-to-site** section of the [VPN Gateway FAQ](vpn-gateway-vpn-faq.md#P2S).

-This article assumes that you already have a Microsoft Entra tenant and the permissions to create an Enterprise Application, typically the Cloud Application administrator role or higher. For more information, see [Create a new tenant in Microsoft Entra ID](/entra/fundamentals/create-new-tenant) and [Assign user roles with Microsoft Entra ID](/entra/fundamentals/users-assign-role-azure-portal).