+To register an application in your Azure AD B2C tenant, you can use the following steps:

+Your application is registered to call the protected web API. A user authenticates with Azure AD B2C to use the application. The application obtains an authorization grant from Azure AD B2C to access the protected web API.

+Some libraries, like [MSAL.js 1.x](https://github.com/AzureAD/microsoft-authentication-library-for-js/tree/dev/lib), only support the [implicit grant flow](implicit-flow-single-page-application.md) or your application is implemented to use implicit flow. In these cases, Azure AD B2C supports the [OAuth 2.0 implicit flow](implicit-flow-single-page-application.md). The implicit grant flow allows the application to get **ID** and **Access** tokens. Unlike the authorization code flow, implicit grant flow doesn't return a **Refresh token**.

+> [!WARNING]

+> Microsoft recommends you do *not* use the implicit grant flow. The recommended way of supporting SPAs is [OAuth 2.0 Authorization code flow (with PKCE)](./authorization-code-flow.md). Certain configurations of this flow requires a very high degree of trust in the application, and carries risks that are not present in other flows. You should only use this flow when other more secure flows aren't viable. For more information, see the [security concerns with implicit grant flow](/entra/identity-platform/v2-oauth2-implicit-grant-flow#security-concerns-with-implicit-grant-flow).

+You can enable implicit grant flow for two reasons, when youΓÇÖre using MSAL.js version 1.3 or earlier version or when you use an app registration to [test a user flow for testing purposes](add-sign-up-and-sign-in-policy.md?pivots=b2c-user-flow#test-the-user-flow).

+Use these steps to enable implicit grant flow for your app:

+1. Select the app registration you created.

+1. Under **Manage**, select **Authentication**.

+> [!NOTE]

+> If your app uses MSAL.js 2.0 or later, don't enable implicit grant flow as MSAL.js 2.0+ supports the [OAuth 2.0 Authorization code flow (with PKCE)](./authorization-code-flow.md). If you enable implicit grant to test a user flow, make sure you disable the implicit grant flow settings before you deploy your app to production.

+- [Register a web application](tutorial-register-applications.md).

+- [Register a web application](tutorial-register-applications.md).

+- [Register a web application](tutorial-register-applications.md).

+

+- [Register a web application](tutorial-register-applications.md).

+- [Register a web application](tutorial-register-applications.md).

+- [Register a web application](tutorial-register-applications.md).

+- [Register a web application](tutorial-register-applications.md).

+- [Register a web application](tutorial-register-applications.md).

+[Implicit flow](implicit-flow-single-page-application.md) | GA | GA | Allows users to sign in to single-page applications. The app gets tokens directly without performing a back-end server credential exchange. <br> **Note:** The recommended flow for supporting SPAs is [OAuth 2.0 Authorization code flow (with PKCE)](./authorization-code-flow.md).|

+- `passwordValidityPeriodInDays` is the length of time in days that a password remains valid before it must be changed.

+## Related content

+Set up a [self-service password reset](add-password-reset-policy.md).

+> [!WARNING]

+> Microsoft recommends you do *not* use the implicit grant flow. The recommended way of supporting SPAs is [OAuth 2.0 Authorization code flow (with PKCE)](./authorization-code-flow.md). Certain configurations of this flow requires a very high degree of trust in the application, and carries risks that are not present in other flows. You should only use this flow when other more secure flows aren't viable. For more information, see the [security concerns with implicit grant flow](/entra/identity-platform/v2-oauth2-implicit-grant-flow#security-concerns-with-implicit-grant-flow).

+See the code sample: [Sign-in with Azure AD B2C in a JavaScript SPA](https://github.com/AzureAD/microsoft-authentication-library-for-js/tree/dev/samples/msal-browser-samples/VanillaJSTestApp2.0/app/b2c).

+### Register a web application

+Complete the steps in [Tutorial: Register a web application in Azure Active Directory B2C](tutorial-register-applications.md?tabs=app-reg-ga) article.

+To use this app registration to test the user flow, you need to enable implicit grant flow:

+1. Select the app registration you created.

+1. Under **Manage**, select **Authentication**.

+1. Under **Implicit grant and hybrid flows**, select both the **Access tokens (used for implicit flows)** and **ID tokens (used for implicit and hybrid flows)** check boxes.

+1. Select **Save**.

+> [!NOTE]

+> If you enable implicit grant to test a user flow, make sure you disable the implicit grant flow settings before you deploy your app to production.

+ a. For **Application**, select the app that you registered.

+ b. For **Reply URL**, select the redirect URL that you added to your app. For testing purposes, select `https://jwt.ms`.

+* [Get started with custom policies in Azure AD B2C](tutorial-create-user-flows.md?pivots=b2c-custom-policy)

+You can enable implicit grant flow to use this app registration to [test a user flow for testing purposes](add-sign-up-and-sign-in-policy.md?pivots=b2c-user-flow#test-the-user-flow).

+1. Select the app registration you created.

+1. Under **Manage**, select **Authentication**.

+1. Under **Implicit grant and hybrid flows**, select both the **Access tokens (used for implicit flows)** and **ID tokens (used for implicit and hybrid flows)** check boxes.

+> [!NOTE]

+> If you enable implicit grant to test a user flow, make sure you disable the implicit grant flow settings before you deploy your app to production.

+### Register a web application

+Complete the steps in [Tutorial: Register a web application in Azure Active Directory B2C](tutorial-register-applications.md?tabs=app-reg-ga) article.

+* [Build web apps by using OpenID Connect](openid-connect.md)

+You can enable implicit grant flow to use this app registration to [test a user flow for testing purposes](add-sign-up-and-sign-in-policy.md?pivots=b2c-user-flow#test-the-user-flow).

+1. Select the app registration you created.

+1. Under **Manage**, select **Authentication**.

+> [!NOTE]

+> If you enable implicit grant to test a user flow, make sure you disable the implicit grant flow settings before you deploy your app to production.

+Learn how to [Create user flows in Azure Active Directory B2C](tutorial-create-user-flows.md)

+ Title: Register a single-page app in Azure Active Directory B2C

+Some libraries, like [MSAL.js 1.x](https://github.com/AzureAD/microsoft-authentication-library-for-js/tree/dev/lib), only support the implicit grant flow or your applications is implemented to use implicit flow. In these cases, Azure AD B2C supports the [OAuth 2.0 implicit flow](implicit-flow-single-page-application.md). The implicit grant flow allows the application to get **ID** and **Access** tokens from the authorize endpoint. Unlike the authorization code flow, implicit grant flow doesn't return a **Refresh token**.

+## Enable the implicit grant flow

+You can enable implicit grant flow for two reasons, when youΓÇÖre using MSAL.js version 1.3 or earlier version or when you use an app registration to [test a user flow for testing purposes](add-sign-up-and-sign-in-policy.md?pivots=b2c-user-flow#test-the-user-flow).

+Use these steps to enable implicit grant flow for your app:

+1. Select the app registration you created.

+1. Under **Manage**, select **Authentication**.

+> [!NOTE]

+> If your app uses MSAL.js 2.0 or later, don't enable implicit grant flow as MSAL.js 2.0+ supports the [OAuth 2.0 Authorization code flow (with PKCE)](./authorization-code-flow.md). If you enable implicit grant to test a user flow, make sure you disable the implicit grant flow settings before you deploy your app to production.

+## Migrate from the implicit grant flow

+If you've an existing application that uses the implicit flow, we recommend that you migrate to use the authorization code flow with PKCE by using a framework that supports it, such as [MSAL.js 2.0+](https://github.com/AzureAD/microsoft-authentication-library-for-js/tree/dev/lib/msal-browser).

+1. Select **+ Add a platform** again. Select **Single-page application** agaain.

+1. On the **Configure single-page application** page, enter the following redirect URI, substituting the name of your API Management instance, and select **Configure**:

+|`<as per need>`|Any|`<Public and Private frontend IPs>`|`<listener ports>`|TCP|Allow|

+> On September 30, 2027, the Azure Automanage Best Practices service will be retired. As a result, attempting to create a new configuration profile or onboarding a new subscription to the service will result in an error. Learn more [here](https://aka.ms/automanagemigration/) about how to migrate to Azure Policy before that date.

+> [!IMPORTANT]

+> On September 30, 2027, the Azure Automanage Best Practices service will be retired. As a result, attempting to create a new configuration profile or onboarding a new subscription to the service will result in an error. Learn more [here](https://aka.ms/automanagemigration/) about how to migrate to Azure Policy before that date.

+> [!IMPORTANT]

+- A user assigned managed identity that you want to use to connect to your Azure Cache for Redis instance.

+1. Once your Redis cache instance is created, navigate to the **Authentication** tab. Select the user assigned managed identity you want to use to connect to your Redis cache instance, then select **Save**.

+1. Alternatively, you can navigate to Data Access Configuration on the Resource menu to create a new Redis user with your user assigned managed identity to connect to your cache.

+1. Take note of the user name for your Redis user from the portal. You use this user name with the AKS workload.

+## Run sample locally

+To run this sample locally, configure your user principal as a Redis User on your Redis instance. The code sample will use your user principal through (DefaultAzureCredential)[https://learn.microsoft.com/en-us/dotnet/azure/sdk/authentication/?tabs=command-line#use-defaultazurecredential-in-an-application] to connect to Redis instance.

+## Configure your AKS cluster

+Follow these [steps](/azure/aks/workload-identity-deploy-cluster) to configure a workload identity for your AKS cluster. Complete the following steps:

+ - Enable OIDC issuer and workload identity

+ - Skip the step to create user assigned managed identity if you already created your managed identity. If you create a new managed identity, ensure that you create a new Redis User for your managed identity and assign appropriate data access permissions.

+ - Create a Kubernetes Service account annotated with the client ID of your user assigned managed identity

+ - Create a federated identity credential for your AKS cluster.

+## Configure your workload that connects to Azure Cache for Redis

+Next, set up the AKS workload to connect to Azure Cache for Redis after you configure the AKS cluster.

+1. Download the code for the [sample app](https://github.com/Azure-Samples/azure-cache-redis-sample/connect-from-aks).

+1. Build and push docker image to your Azure Container Registry using [az acr build](/cli/azure/acr#az-acr-build) command.

+ ```bash

+ az acr build --image sample/connect-from-aks-sample:1.0 --registry yourcontainerregistry --file Dockerfile .

+ ```

+1. Attach your container registry to your AKS cluster using following command:

+ ```bash

+ az aks update --name clustername --resource-group mygroup --attach-acr youracrname

+ ```

+## Deploy your workload

+1. Use the portal to copy the resource group and cluster name for your AKS cluster. To configure _kubectl_ to connect to your AKS cluster, use the following command with your resource group and cluster name:

+ ```bash

+ az aks get-credentials --resource-group myResourceGroup --name myClusterName

+ ```

+1. Verify that you're able to connect to your cluster by running the following command:

+ ```bash

+ kubectl get nodes

+ ```

+ You should see similar output showing the list of your cluster nodes.

+ ```bash

+ NAME STATUS ROLES AGE VERSION

+ aks-agentpool-21274953-vmss000001 Ready agent 1d v1.29.7

+ aks-agentpool-21274953-vmss000003 Ready agent 1d v1.29.7

+ aks-agentpool-21274953-vmss000006 Ready agent 1d v1.29.7

+ ```

+## Run your workload

+1. The following code describes the pod specification file that you use to run our workload. Take note that the pod has the label _azure.workloadidentity/use: "true"_ and is annotated with _serviceAccountName_ as required by AKS workload identity. When using access key authentication, replace the value of AUTHENTICATION_TYPE, REDIS_HOSTNAME and REDIS_ACCESSKEY environment variables.

+ ```yml

+ apiVersion: v1

+ kind: Pod

+ name: entrademo-pod

+ azure.workload.identity/use: "true" # Required. Only pods with this label can use workload identity.

+ serviceAccountName: workload-identity-sa

+ - name: entrademo-container

+ image: youracr.azurecr.io/connect-from-aks-sample:1.0

+ imagePullPolicy: Always

+ command: ["dotnet", "ConnectFromAKS.dll"]

+ memory: "256Mi"

+ cpu: "500m"

+ requests:

+ memory: "128Mi"

+ cpu: "250m"

+ - name: AUTHENTICATION_TYPE

+ value: "MANAGED_IDENTITY" # change to ACCESS_KEY to authenticate using access key

+ - name: REDIS_HOSTNAME

+ value: "your redis hostname"

+ - name: REDIS_ACCESSKEY

+ value: "your access key"

+ - name: REDIS_PORT

+ value: "6380"

+ restartPolicy: Never

+

+ ```

+1. Save this file as podspec.yaml and then apply it to your AKS cluster by running the folloWing command:

+ ```bash

+ kubectl apply -f podspec.yaml

+ ```

+ You get a response indicating your pod was created:

+ ```bash

+ pod/entrademo-pod created

+ ```

+1. To test the application, run the following command to check if the pod is running:

+ ```bash

+ kubectl get pods

+ ```

+ You see your pod running successfully like:

+ ```bash

+ NAME READY STATUS RESTARTS AGE

+ entrademo-pod 0/1 Completed 0 42s

+ ```

+1. Because this tutorial is a console app, you need to check the logs of the pod to verify that it ran as expected using this command.

+ ```bash

+ kubectl logs entrademo-app

+ ```

+ You see the following logs that indicate your pod successfully connected to your Redis instance using user assigned managed identity

+ ```bash

+ Connecting with managed identity..

+ Retrieved value from Redis: Hello, Redis!

+ Success! Previous value: Hello, Redis!

+ ```

+## Clean up your cluster

+kubectl delete pod entrademo-pod

+- [Quickstart: Deploy and configure workload identity on an Azure Kubernetes Service (AKS) cluster](/azure/aks/workload-identity-deploy-cluster)

+- [Azure Cache for Redis Entra ID Authentication](/azure/azure-cache-for-redis/cache-azure-active-directory-for-authentication)

+>AKS backup currently doesn't delete and recreate resources in the target cluster if they already exist. If you attempt to restore Persistent Volumes in the original location, delete the existing Persistent Volumes, and then do the restore operation.

+description: Learn how to prevent unused subscriptions from getting automatically blocked or deleted due to inactivity.

+# customer intent: As a billing administrator, I want to prevent my subscriptions from getting blocked or deleted.

+>[!NOTE]

+> This article only applies to Microsoft Online Service Program (MOSP) and Cloud Solution Provider (CSP) subscriptions.

+> [!IMPORTANT]

+> Azure Data Box Disk is now generally available in a hardware-encrypted option in select countries and regions. These Data Box Disk self-encrypting drives (SEDs) are very well suited for data transfers from Linux systems and support similar data transfer rates to BitLocker-encrypted Data Box Disks on Windows and are popular with some of our automotive customers building ADAS capabilities.

+### Ingestion of data from Data Box

+Azure providers and non-Azure providers can ingest data from Azure Data Box. The Azure services that provide data ingestion from Azure Data Box include:

+- **SharePoint Online** - use Azure Data Box and the SharePoint Migration Tool (SPMT) to migrate your file share content to SharePoint Online. Using Data Box, you remove the dependency on your WAN link to transfer the data. For more information, see [Use the Azure Data Box Heavy to migrate your file share content to SharePoint Online](data-box-heavy-migrate-spo.md).

+- **Azure File Sync** - replicates files from your Data Box to an Azure file share, enabling you to centralize your file services in Azure while maintaining local access to your data. For more information, see [Deploy Azure File Sync](../storage/file-sync/file-sync-deployment-guide.md).

+- **HDFS stores** - migrate data from an on-premises Hadoop Distributed File System (HDFS) store of your Hadoop cluster into Azure Storage using Data Box. For more information, see [Migrate from on-premises HDFS store to Azure Storage with Azure Data Box](../storage/blobs/data-lake-storage-migrate-on-premises-hdfs-cluster.md).

+- **Azure Backup** - allows you to move large backups of critical enterprise data through offline mechanisms to an Azure Recovery Services Vault. For more information, see [Azure Backup overview](../backup/backup-overview.md).

+You can use your Data Box data with many non-Azure service providers. For instance:

+- **[Veeam](https://helpcenter.veeam.com/docs/backup/hyperv/osr_adding_data_box.html?ver=100)** - allows you to back up and replicate large amounts of data from your Hyper-V machine to your Data Box.

+

+| Europe | <ul><li>West Europe</li><li>North Europe</li><li>UK South</li><li>UK West</li><li>France Central</li><li>France South</li><li>Germany North</li><li>Germany West Central</li><li>Sweden Central</li><li>Sweden South</li><li>Switzerland North</li><li>Switzerland West</li><li>Norway East</li><li>Norway West</li><li>Italy North</li><li>Poland Central</li></ul> |

+| Asia | <ul><li>East Asia</li><li>Southeast Asia</li><li>Central India</li><li>South India</li><li>Japan West</li><li>Korea South</li><li>UAE North</li><li>UAE Central</li></ul> |

+The Azure Firewall integration helps analysts perform detailed investigations of the malicious traffic intercepted by the IDPS feature of their firewalls across their entire fleet using natural language questions in the Copilot for Security standalone experience.

+1. In the prompt bar, select the **Sources** icon.

+ :::image type="content" source="media/firewall-copilot/copilot-prompts-bar-sources.png" alt-text="Screenshot of the prompt bar in Microsoft Copilot for Security with the Sources icon highlighted.":::

+ In the **Manage sources** pop-up window that appears, confirm that the **Azure Firewall** toggle is turned on, then close the window. No additional configuration is necessary, as long as structured logs are being sent to a Log Analytics workspace and you have the right RBAC permissions, Copilot will find the data it needs to answer your questions.

+

+ :::image type="content" source="media/firewall-copilot/azure-firewall-plugin.png" alt-text="Screenshot showing the Azure Firewall plugin.":::

+ > [!NOTE]

+ > Some roles can turn the toggle on or off for plugins like Azure Firewall. For more information, see [Manage plugins in Microsoft Copilot for Security](/copilot/security/manage-plugins?tabs=securitycopilotplugin).

+> The Microsoft Threat Intelligence plugin is another source that Copilot for Security may use to provide threat intelligence for IDPS signatures.

+- [What is Microsoft Copilot for Security?](/copilot/security/microsoft-security-copilot)

+The following are examples of using Fast Healthcare Interoperability Resources (FHIR&reg;) search operations, including search parameters and modifiers, chain and reverse chain search, composite search, viewing the next entry set for search results, and searching with a `POST` request. For more information about search, see [Overview of FHIR Search](overview-of-search.md).

+`_include` searches across resources for the ones that include the specified parameter of the resource. For example, you can search across `MedicationRequest` resources to find only the ones that include information about the prescriptions for a specific patient, which is the `reference` parameter `patient`. The following example pulls all the `MedicationRequests` and all patients that are referenced from the `MedicationRequests`.

+`_elements` narrows down the search result to a subset of fields to reduce the response size by omitting unnecessary data. The parameter accepts a comma-separated list of base elements.

+From this request, you get a bundle of patients where each resource only includes the identifiers and the patient's active status. Resources in this response contain a `meta.tag` value of `SUBSETTED` to indicate that they're an incomplete set of results.

+`:not` allows you to find resources where an attribute isn't true. For example, you could search for patients where the gender isn't female.

+`:missing` returns all resources that don't have a value for the specified element when the value is `true`, and returns all the resources that contain the specified element when the value is `false`. For simple data type elements, `:missing=true` matches on all resources where the element is present with extensions but has an empty value. The following example shows how to find all `Patient` resources that are missing information on birth date.

+`:contains` is used for `string` parameters and searches for resources with partial matches of the specified value anywhere in the string within the field being searched. `contains` isn't case sensitive and allows character concatenating. For example:

+This request would return all `Patient` resources with `address` fields that have values that contain the string "Meadow". This means you could have addresses that include values such as "Meadowers" or "59 Meadow ST" returned as search results.

+Another common use of a regular search (not a chained search) is finding all encounters for a specific patient. `Patient`s often have one or more `Encounter`s with a subject. The following searches for all `Encounter` resources for a `Patient` with the provided `id`.

+Using chained search, you can find all the `Encounter` resources that match a particular piece of `Patient` information, such as the `birthdate`.

+This would allow searching `Encounter` resources across all patients that have the specified birth date value.

+This would return all `Patient` resources that have "Sarah" as the `generalPractitioner` and have a `generalPractitioner` that has the address with the state WA. In other words, if a patient had Sarah from the state NY and Bill from the state WA both referenced as the patient's `generalPractitioner`, both are returned.

+For scenarios in which the search has to be an `AND` operation that covers all conditions as a group, refer to the example in [**Composite search**](#composite-search).

+Chain search lets you search for resources based on the properties of resources they refer to. Using reverse chain search allows you to do it the other way around. You can search for resources based on the properties of resources that refer to them, using `_has` parameter. For example, an `Observation` resource has a search parameter `patient` referring to a Patient resource. Use the following to find all Patient resources referenced by `Observation` with a specific `code`.

+This request returns Patient resources referred by `Observation` with the code `527`.

+In addition, reverse chain search can have a recursive structure. For example, the following searches for all patients that have `Observation` where the observation has an audit event from a specific user `janedoe`.

+To search for resources that meet multiple conditions at once, use a composite search that joins a sequence of single parameter values with a symbol `$`. The result would be the intersection of the resources that match all of the conditions specified by the joined search parameters. Such search parameters are called composite search parameters, and they define a new parameter that combines the multiple parameters in a nested structure. For example, the following search finds all `DiagnosticReport` resources that contain `Observation` with a potassium value less than or equal to 9.2.

+The maximum number of entries that can be returned per a single search query is 1000. If more than 1,000 entries that match the search query, you can use the following procedure to see entries greater than 1000.<br>

+Use the continuation token `url` value in `searchset`, as in the following `Bundle` result.

+Then do a GET request for the provided URL under the field `relation: next`.

+This returns the next set of entries for your search result. The `searchset` is the complete set of search result entries, and the continuation token `url` is the link provided by the server for you to retrieve entries that don't show up in the first 1000.

+All of the search examples previously mentioned used `GET` requests. You can also do search operations using `POST` requests using `_search`.

+This request returns `Patient` resources with the `id` value of 45. As with GET requests, the server determines which of the set of resources meets the condition, and returns a bundle resource in the HTTP response.

+Another example of searching using POST where the query parameters are submitted as a form body is as follows.

+page lists the **compliance domains** and **security controls** for Azure API for FHIR&reg;. You can

+Substitutable Medical Applications and Reusable Technologies ([SMART on FHIR&reg;](https://docs.smarthealthit.org/)) is a healthcare standard through which applications can access clinical information through a data store. It adds a security layer based on open standards including OAuth2 and OpenID Connect, to FHIR interfaces to enable integration with EHR systems. Using SMART on FHIR provides important benefits, including:

+The following tutorials describe steps to enable SMART on FHIR applications with FHIR Service.

+- [Register a public client application in Microsoft Entra ID](/azure/healthcare-apis/azure-api-for-fhir/register-public-azure-ad-client-app)

+ - After registering the application, make note of the `applicationId` for the client application.

+- Ensure you have access to an Azure Subscription of FHIR service to create resources and add role assignments.

+Follow the steps listed under [Manage Users: Assign Users to Role](../../role-based-access-control/role-assignments-portal.yml). Any user added to role - "FHIR SMART User" is able to access the FHIR Service if their requests comply with the SMART on FHIR implementation Guide, such as request having access token, which includes a `fhirUser` claim and a clinical scopes claim. The access granted to the users in this role will be limited by the resources associated to their `fhirUser` compartment and the restrictions in the clinical scopes.

+[Follow the steps](https://aka.ms/azure-health-data-services-smart-on-fhir-sample) found in Azure Health Data and AI Samples OSS. This enables integration of FHIR server with other Azure Services (such as APIM, Azure functions and more).

+> Samples are open-source code, and you should review the information and licensing terms on GitHub before using it. They are not part of Azure Health Data Service and are not supported by Microsoft Support. These samples can be used to demonstrate how Azure Health Data Services and other open-source tools can be used together to demonstrate ONC (g)(10) compliance using Microsoft Entra ID as the identity provider workflow.

+> This is another path to SMART on FHIR (Enhanced) as mentioned. SMART on FHIR Proxy option only enables an EHR launch sequence.

+If you do have administrative privileges, complete the following steps to grant admin consent to yourself directly. (You can also grant admin consent to yourself later when you're prompted in the app.) You can complete the same steps to add other users as owners, so they can view and edit this app registration.

+To enable the SMART on FHIR proxy in the **Authentication** settings for your Azure API for FHIR instance, select the **SMART on FHIR proxy** check box.

+Because of this two-step relay of the authentication code, you need to set the reply URL (callback) for your Microsoft Entra client application to a URL that is a combination of the reply URL for the SMART on FHIR proxy and the reply URL for the SMART on FHIR app. The combined reply URL takes the following form.

+In the reply, `aHR0cHM6Ly9sb2NhbGhvc3Q6NTAwMS9zYW1wbGVhcHAvaW5kZXguaHRtbA` is a URL-safe, base64-encoded version of the reply URL for the SMART on FHIR app. For the SMART on FHIR app launcher, when the app is running locally, the reply URL is `https://localhost:5001/sampleapp/https://docsupdatetracker.net/index.html`.

+You can generate the combined reply URL by using a script like the following.

+Add the reply URL to the public client application that you created earlier for Microsoft Entra ID.

+To test the Azure API for FHIR and the SMART on FHIR proxy, you need to have at least one patient in the database. If you haven't interacted with the API yet, and you don't have data in the database, see [Access the FHIR service using Postman](./../fhir/use-postman.md) to load a patient. Make a note of the ID of a specific patient.

+You can clone the GitHub repository and go to the application by using the following commands.

+We recommend that you use the `dotnet user-secrets` feature.

+Use this command to run the application.

+After you start the SMART on FHIR app launcher, you can point your browser to `https://localhost:5001`, where you should see the following screen.

+When you enter **Patient**, **Encounter**, or **Practitioner** information, notice that the **Launch context** is updated. When you're using the Azure API for FHIR, the launch context is simply a JSON document that contains information about patient, practitioner, and more. This launch context is base64 encoded and passed to the SMART on FHIR app as the `launch` query parameter. According to the SMART on FHIR specification, this variable is opaque to the SMART on FHIR app and passed on to the identity provider.

+The SMART on FHIR proxy uses this information to populate fields in the token response. The SMART on FHIR app *can* use these fields to control which patient it requests data for and how it renders the application on the screen. The SMART on FHIR proxy supports the following fields.

+Notice that the SMART on FHIR app launcher updates the **Launch URL** information at the bottom of the page.<br>

+Select **Launch** to start the sample app.

+HL7 Fast Healthcare Interoperability Resources (FHIR&reg;) defines a standard and interoperable way to store and exchange healthcare data. Even within the base FHIR specification, it can be helpful to define other rules or extensions based on the context that FHIR is being used. For such context-specific uses of FHIR, **FHIR profiles** are used for the extra layer of specifications. [FHIR profile](https://www.hl7.org/fhir/profiling.html) allows you to narrow down and customize resource definitions using constraints and extensions.

+A profile sets additional context on the resource that's represented as a `StructureDefinition` resource. A `StructureDefinition` defines a set of rules on the content of a resource or data type, such as what elements a resource has and what values these elements can take.

+Some examples of how profiles can modify the base resource are:

+A `StructureDefinition` is identified by its canonical URL: `http://hl7.org/fhir/StructureDefinition/{profile}`.

+Here are some examples.

+When a resource conforms to a profile, the profile is specified inside the `profile` element of the resource. Following is an example of the beginning of a `Patient` resource, which has the profile http://hl7.org/fhir/us/carin-bb/StructureDefinition/C4BB-Patient.

+Profiles are specified by various Implementation Guides (IGs). The following is a list of common IGs. For more information, visit the specific IG site to learn more about the IG and the profiles defined within it.

+> The Azure API for FHIR by default does not store any profiles from implementation guides. You will need to load them into the Azure API for FHIR.

+For example, if you'd like to store the `us-core-allergyintolerance` profile, you'd use the following rest command with the US Core allergy intolerance profile in the body. We included a snippet of this profile for the example.

+For more examples, see the [US Core sample REST file](https://github.com/microsoft/fhir-server/blob/main/docs/rest/PayerDataExchange/USCore.http) on the open-source site that walks through storing US Core profiles. To get the most up-to-date profiles, you should get the profiles directly from HL7 and the implementation guide that defines them.

+For example, use the following if you want to view a US Core Goal resource profile.

+This returns the `StructureDefinition` resource for US Core Goal profile, which starts like the following.

+Azure API for FHIR doesn't return `StructureDefinition` instances for the base profiles, but they can be found in the HL7 website.

+The `Capability Statement` lists all possible behaviors of Azure API for FHIR. Azure API for FHIR updates the capability statement with details of the stored profiles in the following forms.

+For example, if you save a US Core Patient profile, which starts like the following.

+You're returned a `CapabilityStatement` that includes the following information on the US Core Patient profile you uploaded to Azure API for FHIR.

+A terminology service is a set of functions that can perform operations on medical ΓÇ£terminologies" such as validating codes, translating codes, expanding value sets, and other operations.<br>

+The Azure API for FHIR service doesn't support terminology service. Information for supported operations (`$`), resource types, and interactions can be found in the service's `CapabilityStatement`. Resource types `ValueSet`, `StructureDefinition` and `CodeSystem` are supported with basic create, read, update, and delete (CRUD) operations and Search (as defined in the `CapabilityStatement`), as well as being leveraged by the system for use in `$validate`.

+ValueSets can contain a complex set of rules and external references. Today, the service only considers the pre-expanded inline codes. Customers need to upload supported ValueSets to the FHIR server before utilizing the `$validate` operation. The `ValueSet` resources must be uploaded to the FHIR server, using PUT or conditional update, as mentioned in the [storing profiles](#storing-profiles) section.

+In this article, you learned about FHIR profiles. Next, you can learn how you can use `$validate` to ensure that resources conform to these profiles.

+* **Do** use large files while ingesting data. The optimal NDJSON file size for import is 50 MB or larger (or 20,000 resources or more, with no upper limit). Combining smaller files into larger ones can enhance performance.

+You need an Azure account with an [IoT Hub](../iot-hub/iot-concepts-and-iot-hub.md) and Microsoft Azure portal or Azure CLI to interact with devices via your IoT Hub. Follow the next steps to get started:

+- Install the Device Update agent on the device. See [how to](device-update-agent-provisioning.md#on-iot-edge-enabled-devices).

+Follow the below steps to update Azure IoT Edge on Ubuntu Server 22.04 x64 by configuring a source repository. The tools and concepts in this tutorial still apply even if you plan to use a different OS platform configuration.

+5. Monitor results of the package update by following these [steps](device-update-ubuntu-agent.md#monitor-the-update-deployment).

+ Title: Device Update for Azure IoT Hub tutorial using the Ubuntu Server 22.04 x64 package agent | Microsoft Docs

+description: Get started with Device Update for Azure IoT Hub by using the Ubuntu Server 22.04 x64 package agent.

+# Tutorial: Device Update for Azure IoT Hub using the package agent on Ubuntu Server 22.04 x64

+This tutorial walks you through updating Azure IoT Edge on Ubuntu Server 22.04 x64 by using the Device Update package agent. Although the tutorial demonstrates installing the Microsoft Defender for IoT, by using similar steps you could update other packages, such as the IoT Edge itself or the container engine it uses.

+For convenience, this tutorial uses a [cloud-init](/azure/virtual-machines/linux/using-cloud-init)-based [Azure Resource Manager template](../azure-resource-manager/templates/overview.md) to help you quickly set up an Ubuntu 22.04 LTS VM(Virtual Machine). It installs both the Azure IoT Edge runtime and the Device Update package agent. Then it automatically configures the device with provisioning information by using the device connection string for an IoT Edge device (prerequisite) that you supply. The Resource Manager template also avoids the need to start an SSH session to complete setup.

+ [](https://portal.azure.com/#create/Microsoft.Template/uri/https%3A%2F%2Fraw.githubusercontent.com%2Fazure%2Fiotedge-vm-deploy%2Fmain%2FedgeDeploy.json).

+ * **Ubuntu OS Version**: The version of the Ubuntu OS to be installed on the base virtual machine. Leave the default value unchanged because it is set to Ubuntu 22.04-LTS already.

+1. Verify that the deployment is completed successfully. Allow a few minutes after deployment completes for the post-installation and configuration to finish installing IoT Edge and the device package update agent.

+ A virtual machine resource should be deployed into the selected resource group. Note the machine name, which is in the format `vm-0000000000000`. Also note the associated **DNS name**, which is in the format `<dnsLabelPrefix>`.`<location>`.cloudapp.azure.com.

+1. Install the Device update agent on the VM.

+ sudo apt-get install deviceupdate-agent

+2. Open the configuration details (See how to [set up configuration file here](device-update-configuration-file.md) with the command below. Set your connectionType as 'AIS' and connectionData as empty string. Note that all values with the 'Place value here' tag must be set. See [Configuring a Device Update agent](./device-update-configuration-file.md#example-du-configjson-file-contents).

+ sudo nano /etc/adu/du-config.json

+1. Go to [Device Update releases](https://github.com/Azure/iot-hub-device-update/releases) in GitHub and select the **Assets** dropdown list. Download `Tutorial_IoTEdge_PackageUpdate.zip` by selecting it. Extract the contents of the folder to discover a sample APT manifest (sample-defender-iot-apt-manifest.json) and its corresponding import manifest (sample-defender-iot--importManifest.json).

+You've now completed a successful end-to-end package update by using Device Update for IoT Hub on an Ubuntu Server 22.04 x64 device.

+* For **Windows servers** and web apps discovery, create an account (local or domain) that has administrator permissions on the servers. To discover SQL Server instances and databases, the Windows or SQL Server account must be a member of the sysadmin server role or have [these permissions](./migrate-support-matrix-vmware.md#configure-the-custom-login-for-sql-server-discovery) for each SQL Server instance. Learn how to [assign the required role to the user account](/sql/relational-databases/security/authentication-access/server-level-roles).

+ Title: "Tutorial: Install the Slurm Workload Manager on Azure Modeling and Simulation Workbench"

+description: "Learn how to install the Slurm Workload Manager in the Azure Modeling and Simulation Workbench."

+#CustomerIntent: As an administrator, I want to learn how to install, setup, and configure the Slurm workload manager in the Azure Modeling and Simulation Workbench.

+# Tutorial: Install the Slurm workload manager in the Azure Modeling and Simulation Workbench

+The [Slurm](https://slurm.schedmd.com/overview.html) Workload Manager is a scheduler used in microelectronics design and other high-performance computing scenarios to manage jobs across compute clusters. The Modeling and Simulation Workbench can be deployed with a range of high-performance virtual machines (VM) ideal for large, compute-intensive workloads. Slurm clusters consist of a *controller node* that manages, stages, and schedules jobs bound for the *compute nodes*. Compute nodes are where the actual workloads are performed. A *node* is an individual element of the cluster, such as a VM.

+The Slurm installation package is already available on all Modeling and Simulation Workbench Chamber VMs. This tutorial shows you how to create VMs for your Slurm cluster and install Slurm.

+In this tutorial, you learn how to:

+> [!div class="checklist"]

+>

+> * Create a cluster for Slurm

+> * Create an inventory of VMs

+> * Designate controller and compute nodes and install Slurm on each

+If you donΓÇÖt have an Azure subscription, [create a free account](https://azure.microsoft.com/free/?WT.mc_id=A261C142F).

+## Prerequisites

+## Sign in to the Azure portal and navigate to your workbench

+If you aren't already signed into the Azure portal, go to [portal.azure.com](https://portal.azure.com). Navigate to your workbench, then to the chamber you want to create your Slurm cluster.

+## Create a cluster for Slurm

+Slurm requires one node to serve as the controller and a set of compute nodes where workloads execute. The controller is traditionally a modestly sized VM. The controller isn't used for computational workloads and is left deployed between jobs, while the compute nodes themselves are typically sized for a specific task and often deleted after the job. Learn about the different VMs available in Modeling and Simulation Workbench on the [VM Offerings page](./concept-vm-offerings.md).

+### Create the Slurm controller node

+1. From the chamber overview page, select **Chamber VM** from the **Settings** menu, then either the **+ Create** button on action menu along the top or the blue **Create chamber VM** button in center of the page.

+ :::image type="content" source="media/tutorial-slurm/create-chamber-vm.png" alt-text="Screenshot of chamber VM overview page with Chamber VM in Settings and the create options on the page highlighted by red outlines." lightbox="media/tutorial-slurm/create-chamber-vm.png":::

+1. On the **Create chamber VM** page:

+ * Enter a **Name** for the VM. We recommend choosing a name that indicates it's the controller node.

+ * Select a VM size. For the controller, you can select the smallest VM available. The *D4s_v4* is currently the smallest.

+ * Leave the **Chamber VM image type** and **Chamber VM count** as the default of *Semiconductor* and *1*.

+ * Select **Review + create**.

+ :::image type="content" source="media/tutorial-slurm/configure-create-chamber-vm.png" alt-text="Screenshot of create chamber VM page with the name and VM size textboxes and the create button highlighted in red outline.":::

+1. After the validation check passes, select the **Create** button.

+Once the VM deploys, it's available in the connector desktop dashboard.

+### Create a Slurm compute cluster

+A *cluster* is a collection of VMs, individually referred to as *nodes* that perform the actual work. The compute nodes have their workloads dispatched and managed by the controller node. Similar to the steps you took when you created the controller, return to the **Chamber VM** page to create a cluster. The Modeling and Simulation Workbench allows you to create multiple, identical VMs in a single step.

+1. On the **Create chamber VM** page:

+ * Enter a **Name** for the VM cluster. Use a name that identifies these VMs as compute nodes. For example, include the word "node" or the type of workload somewhere in the name.

+ * Select a VM appropriately sized for the workload. Refer to the [VM Offerings](concept-vm-offerings.md) page for guidance on VM offerings, capabilities, features, and sizes.

+ * Leave the **Chamber VM image type** as the default of *Semiconductor*.

+ * In the **Chamber VM count** box, enter the number of nodes required.

+ * Select **Review + create**.

+1. After the validation check passes, select the **Create** button.

+VMs are deployed in parallel and appear in the dashboard. It isn't typically necessary to individually access worker nodes, however you can ssh to worker nodes in the same chamber if needed. In the next steps, you'll configure the compute nodes from the controller.

+### Connect to the controller node desktop

+Slurm installation is performed from the controller node.

+1. Navigate to the connector. From the **Settings** menu of the chamber, select **Connector**. Select the sole connector that appears in the resource list.

+ :::image type="content" source="media/tutorial-slurm/connector-overview.png" alt-text="Screenshot of connector overview page with Connector in Settings and the target connector highlighted with a red rectangle.":::

+1. From the connector page, select the **Desktop dashboard** URL.

+ :::image type="content" source="media/tutorial-slurm/connector-desktop-dashboard-url.png" alt-text="Screenshot of connector overview page with desktop dashboard URL highlighted in red rectangle.":::

+1. The desktop dashboard opens. Select your controller VM.

+## Create an inventory of VMs

+Slurm installation requires that you have a technical inventory of the compute nodes and as host names.

+### Get a list of deployed VMs

+Configuring Slurm requires an inventory of nodes. From the controller node:

+1. Open a terminal in your desktop by selecting the terminal icon from the menu bar at the top.

+ :::image type="content" source="media/tutorial-slurm/open-terminal.png" alt-text="Screenshot of desktop with terminal button highlighted in red.":::

+1. Execute the following commands to print a list of all VMs in the chamber. In this example, we have one controller and five nodes. The command prints the IP addresses in the first column and the hostnames in the second. From the naming, you can see the controller node and the compute nodes.

+ ```bash

+ ip=$(hostname -i | cut -d'.' -f1-3)

+ for i in {1..254}; do host "$ip.$i" | grep -v "not found" | awk -F'[. ]' '{print $4"."$3"."$2"."$1" "$10}'; done

+ ```

+ Your output will be similar to:

+ ```bash

+ 10.163.4.4 wrkldvmslurmcont29085dd

+ 10.163.4.5 wrkldvmslurm-nod0aef63d

+ 10.163.4.6 wrkldvmslurm-nod10870ad

+ 10.163.4.7 wrkldvmslurm-node4689c2

+ 10.163.4.8 wrkldvmslurm-noddfe3a7c

+ 10.163.4.9 wrkldvmslurm-nod034b970

+ ```

+1. Create a file with just the worker nodes, one host per line and call it *slurm_worker.txt*. For the remaining steps of this tutorial, use this list to configure the compute nodes from your controller. In some steps, the nodes need to be in a comma-delimited format. In those instances, we use a command-line shortcut to format the list without having to create a new file. To create *slurm_worker.txt*, remove the IP addresses in the first column, and the controller node which is listed first.

+### Gather technical specifications about the compute nodes

+Assuming that you created all the worker nodes in your cluster using the same VM, choose any node to retrieve technical information about the platform. In this example, we use `head` to grab the first host name in the compute node list and using `ssh` send the `lscpu` command to be executed:

+```bash

+$ ssh `head -1 ./slurm_worker.txt` lscpu

+The authenticity of host 'wrkldvmslurm-nod034b970 (10.163.4.9)' can't be established.

+ECDSA key fingerprint is SHA256:1I2zBg8N/1c0LBRfa+fOvpAoKe90OIr0FvgqwFSfoc0.

+Are you sure you want to continue connecting (yes/no/[fingerprint])? yes

+Warning: Permanently added 'wrkldvmslurm-nod034b970,10.163.4.9' (ECDSA) to the list of known hosts.

+Architecture: x86_64

+CPU op-mode(s): 32-bit, 64-bit

+Byte Order: Little Endian

+CPU(s): 4

+On-line CPU(s) list: 0-3

+Thread(s) per core: 2

+Core(s) per socket: 2

+Socket(s): 1

+NUMA node(s): 1

+Vendor ID: GenuineIntel

+CPU family: 6

+Model: 85

+Model name: Intel(R) Xeon(R) Platinum 8272CL CPU @ 2.60GHz

+Stepping: 7

+CPU MHz: 2593.907

+BogoMIPS: 5187.81

+Virtualization: VT-x

+Hypervisor vendor: Microsoft

+Virtualization type: full

+L1d cache: 32K

+L1i cache: 32K

+L2 cache: 1024K

+L3 cache: 36608K

+NUMA node0 CPU(s): 0-3

+Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss ht syscall nx pdpe1gb rdtscp lm constant_tsc rep_good nopl xtopology cpuid pni pclmulqdq vmx ssse3 fma cx16 pcid sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch invpcid_single tpr_shadow vnmi ept vpid ept_ad fsgsbase bmi1 hle avx2 smep bmi2 erms invpcid rtm avx512f avx512dq rdseed adx smap clflushopt clwb avx512cd avx512bw avx512vl xsaveopt xsavec xgetbv1 xsaves avx512_vnni arch_capabilities

+```

+You'll be asked by the ssh client to verify the ECDSA key fingerprint of the remote machines. Take note of the following parameters:

+* **CPU(s)**

+* **Socket(s)**

+* **Core(s) per socket**

+* **Thread(s) per core**

+Slurm also requires an estimate of available memory on the compute nodes. To obtain the available memory of a worker node, execute the `free` command on any of the compute nodes from your controller and note the **available** memory reported in the output. Again, we use the first worker node in our list using the `head` command submitted via `ssh`.

+```bash

+$ ssh `head -1 ./slurm_worker.txt` free

+ total used free shared buff/cache available

+Mem: 16139424 1433696 7885256 766356 6820472 13593564

+Swap: 0 0 0

+```

+Note the available memory listed in the **available** column.

+## Install Slurm on your cluster

+### Prerequisite: Install MariaDB

+Slurm requires the MySql fork MariaDB to be installed from the Red Hat repository before installation. Azure maintains a private Red Hat repository mirror and chamber VMs have access to this repository. Install and configure MariaDB with the following commands:

+```bash

+sudo yum install -y mariadb-server

+sudo systemctl start mariadb

+sudo systemctl enable mariadb

+mysql_secure_installation

+```

+The *mysql_secure_installation* script asks for more configuration.

+* The default database password isn't set. Hit <kbd>Enter</kbd> when asked for current password.

+* Enter *Y* when asked to set root password. Create a new, secure root password for MariaDB, take note of it for later, then reenter to confirm. You need this password when you configure the Slurm controller in the following step.

+* Enter *Y* for the remaining questions for:

+ * Reloading privileged tables

+ * Removing anonymous users

+ * Disabling remote root login

+ * Removing tests databases

+ * Reloading privilege tables

+### Install Slurm on the controller

+The Modeling and Simulation Workbench provides a setup script to speed installation. It requires the parameters you collected earlier in this tutorial. Replace the placeholders with the parameters you collected. Execute these commands on the controller node. The \<clusternodes\> placeholder is a comma-separated, no space list of hostnames. The examples include a shortcut to do so, reformatting your compute node list in *slurm_worker.txt* into the proper comma-delimited format. The argument of the *sdwChamberSlurm.sh* script is as follows:

+```bash

+sudo /usr/sdw/slurm/sdwChamberSlurm.sh CONTROLLER <databaseSecret> <clusterNodes> <numberOfCpus> <numberOfSockets> <coresPerSocket> <threadsPerCore> <availableMemory>

+```

+For this example, we use the list of nodes we created in the previous steps and substitute our values collected during discovery. The `paste` command is used to reformat the list of worker nodes into the comma-delimited format without needing to create a new file.

+```bash

+sudo /usr/sdw/slurm/sdwChamberSlurm.sh CONTROLLER <databasepassword> `paste -d, -s ./slurm_nodes.txt` 4 1 2 2 13593564

+```

+The output should be similar to:

+```bash

+Last metadata expiration check: 4:00:15 ago on Thu 03 Oct 2024 01:52:40 PM UTC.

+Package bzip2-devel-1.0.6-26.el8.x86_64 is already installed.

+Package gcc-8.5.0-18.2.el8_8.x86_64 is already installed..

+...

+Installed:

+ slurm-24.05.0-1.el8.x86_64 slurm-slurmctld-24.05.0-1.el8.x86_64 slurm-slurmdbd-24.05.0-1.el8.x86_64

+Complete!

+[INFO] Slurm Controller successfully installed.

+[INFO] Slurm Config successfully updated.

+[INFO] slurmdbd successfully started.

+[INFO] slurmctld successfully started.

+```

+> [!TIP]

+> If your installation shows any [ERROR] message in these steps, check that you haven't mistyped or misplaced any parameter. Review your information and repeat the step.

+### Install Slurm on compute nodes

+Slurm must now be installed on the compute nodes. To ease this task, use your home directory which is mounted on all VMs, to ease distribution of files and scripts used.

+From your user account, copy the *munge.key* file to your home directory.

+```bash

+cd

+sudo cp /etc/munge/munge.key .

+```

+Create a script named *node-munge.sh* to set up each node's **munge** settings. This script should be in your home directory.

+```bash

+$ cat > node-munge.sh <<END

+#!/bin/bash

+mkdir -p /etc/munge

+yum install -y munge

+cp munge.key /etc/munge/munge.key

+chown -R munge:munge /etc/munge/munge.key

+END

+```

+Using the same file of the node hostnames that you previously used, execute the bash script you created on the node.

+```bash

+for host in `cat ./slurm_nodes.txt`; do ssh $host sudo sh ~/node-munge.sh; done

+```

+Your output should be similar to:

+```bash

+Last metadata expiration check: 4:02:25 ago on Thu 03 Oct 2024 09:35:58 PM UTC.

+Dependencies resolved.

+================================================================================

+ Package

+ Arch Version Repository Size

+================================================================================

+Installing:

+ munge x86_64 0.5.13-2.el8 rhel-8-for-x86_64-appstream-eus-rhui-rpms 122 k

+...

+Running transaction

+ Preparing : 1/1

+ Running scriptlet: munge-0.5.13-2.el8.x86_64 1/1

+ Installing : munge-0.5.13-2.el8.x86_64 1/1

+ Running scriptlet: munge-0.5.13-2.el8.x86_64 1/1

+ Verifying : munge-0.5.13-2.el8.x86_64 1/1

+Installed products updated.

+Installed:

+ munge-0.5.13-2.el8.x86_64

+Complete!

+```

+> [!IMPORTANT]

+> After configuring the compute nodes, be sure to delete the *munge.key* file from your home directory.

+## Validate installation

+To validate that Slurm installed successfully, a Chamber Admin can execute the `sinfo` command on any Slurm node, either on the controller or on a compute node.

+```bash

+$ sinfo

+PARTITION AVAIL TIMELIMIT NODES STATE NODELIST

+chamberSlurmPartition1* up infinite 5 idle wrkldvmslurm-nod0aef63d,wrkldvmslurm-nod034b970...

+```

+You can validate execution on compute nodes by sending a simple command using the `srun` command.

+```shell

+$ srun --nodes=6 hostname && srun sleep 30

+wrkldvmslurm-nod034b970

+wrkldvmslurm-nod0aef63d

+wrkldvmslurm-nod10870ad

+```

+If a job shows as *queued*, run `squeue` to list the job queue.

+```shell

+$ squeue

+ JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON)

+ 12 ChamberSl sleep jane.doe R 0:11 1 nodename1

+$ scontrol show job

+JobId=11 JobName=hostname

+ UserId=jane.doe(2982) GroupId=jane.doe(2982) MCS_label=N/A

+ Priority=4294901749 Nice=0 Account=(null) QOS=(null)

+ JobState=COMPLETED Reason=None Dependency=(null)

+ ...

+ NodeList=nodename[1-3]

+ BatchHost=nodename1

+ NumNodes=3 NumCPUs=48 NumTasks=3 CPUs/Task=1 ReqB:S:C:T=0:0:*:*

+ ...

+ Command=hostname

+ WorkDir=/mount/sharedhome/jane.doe

+ Power=

+

+JobId=12 JobName=sleep

+ UserId=jane.doe(2982) GroupId=jane.doe(2982) MCS_label=N/A

+ Priority=429490148 Nice=0 Account=(null) QOS=(null)

+ JobState=COMPLETED Reason=None Dependency=(null)

+ ...

+ NodeList=nodename1

+ BatchHost=nodename1

+ NumNodes=1 NumCPUs=16 NumTasks=1 CPUs/Task=1 ReqB:S:C:T=0:0:*:*

+ ...

+ Command=sleep

+ WorkDir=/mount/sharedhome/jane.doe

+ Power=

+```

+## Troubleshooting

+If a node's state is reported as *down* or *drain*, the `scontrol` command can restart it. Follow that with the `sinfo` command to verify activation.

+```bash

+$ sudo -u slurm scontrol update nodename=nodename1,nodename2 state=resume

+$ sinfo

+PARTITION AVAIL TIMELIMIT NODES STATE NODELIST

+chamberSlurmPartition1* up infinite 3 idle nodename[1-3]

+```

+## Related content

+* [Slurm Workload Manager](https://slurm.schedmd.com/overview.html)

+* [Slurm Workload Manager Quick Start Administrator Guide](https://slurm.schedmd.com/quickstart_admin.html)

+* [Slurm Workload Manager configuration](https://slurm.schedmd.com/slurm.conf.html)

+* [Slurm Accounting Storage configuration](https://slurm.schedmd.com/slurmdbd.conf.html)

+* [VM Offerings on Modeling and Simulation Workbench](./concept-vm-offerings.md)

+* [Create chamber storage](./how-to-guide-manage-chamber-storage.md)

+* [Create shared storage](./how-to-guide-manage-shared-storage.md)

+- An existing Azure Virtual Network and subnet. For more information, see [Quickstart: Create a virtual network using the Azure portal](../virtual-network/quick-create-portal.md).

+ - The example virtual network that is used in this article is named *vnet-1*.

+ - The example subnet is named *subnet-1*.

+ - The example NAT gateway is named *nat-gateway*.

+- An existing Azure Virtual Network and subnet. For more information, see [Quickstart: Create a virtual network using the Azure portal](../virtual-network/quick-create-portal.md).

+ - The example virtual network that is used in this article is named *vnet-1*.

+ - The example subnet is named *subnet-1*.

+ - The example NAT gateway is named *nat-gateway*.

+- An existing Azure Virtual Network and subnet. For more information, see [Quickstart: Create a virtual network using the Azure portal](../virtual-network/quick-create-portal.md).

+ - The example virtual network that is used in this article is named *vnet-1*.

+ - The example subnet is named *subnet-1*.

+ - The example NAT gateway is named *nat-gateway*.

+- An existing Azure Virtual Network a subnet. For more information, see [Quickstart: Create a virtual network using the Azure portal](../virtual-network/quick-create-portal.md).

+ - The example virtual network that is used in this article is named *vnet-1*.

+ - The example subnet is named *subnet-1*.

+ - The example NAT gateway is named *nat-gateway*.

+1. Select **+ Create**.

+1. Enter or select the following information in the **Basics** tab of **Create network address translation (NAT) gateway**.

+ | Setting | Value |

+ | - | -- |

+ | **Project details** | |

+ | Subscription | Select your subscription. |

+ | Resource group | Select your resource group or select **Create new** to create a new resource group. |

+ | **Instance details** | |

+ | NAT gateway name | Enter *nat-gateway*. |

+ | Region | Select your region. This example uses **East US 2**. |

+ | Availability zone | Select **No Zone**. For more information about NAT gateway availability, see [NAT gateway and availability zones](nat-availability-zones.md). |

+ | TCP idle timeout (minutes) | Select the default of **4**. |

+ - To create a new public IP for the NAT gateway, select **Create a new public IP address**. Enter *public-ip-nat* in **Name**. Select **OK**.

+ - To create a new public IP prefix for the NAT gateway, select **Create a new public IP prefix**. Enter *public-ip-prefix-nat* in **Name**. Select a **Prefix size**. Select **OK**.

+1. Select your virtual network. In this example, select **vnet-1** in the dropdown list.

+1. Select the checkbox next to **subnet-1**.

+ Name = 'public-ip-nat'

+ ResourceGroupName = 'test-rg'

+ Name = 'vnet-1'

+ ResourceGroupName = 'test-rg'

+ Name = 'public-ip-nat'

+ ResourceGroupName = 'test-rg'

+ ResourceGroupName = 'test-rg'

+ Name = 'nat-gateway'

+ IdleTimeoutInMinutes = '4'

+ Name = 'subnet-1'

+ AddressPrefix = '10.0.0.0/24'

+ Name = 'public-ip-prefix-nat'

+ ResourceGroupName = 'test-rg'

+ Name = 'vnet-1'

+ ResourceGroupName = 'test-rg'

+ Name = 'public-ip-prefix-nat'

+ ResourceGroupName = 'test-rg'

+ ResourceGroupName = 'test-rgNAT'

+ Name = 'nat-gateway'

+ IdleTimeoutInMinutes = '4'

+ Name = 'subnet-1'

+ AddressPrefix = '10.0.0.0/24'

+ --resource-group test-rg \

+ --name public-ip-nat \

+ --resource-group test-rg \

+ --name nat-gateway \

+ --public-ip-addresses public-ip-nat \

+ --idle-timeout 4

+ --resource-group test-rg \

+ --vnet-name vnet-1 \

+ --name subnet-1 \

+ --nat-gateway nat-gateway

+ --resource-group test-rg \

+ --name public-ip-prefix-nat

+ --resource-group test-rg \

+ --name nat-gateway \

+ --public-ip-prefixes public-ip-prefix-nat \

+ --resource-group test-rg \

+ --vnet-name vnet-1 \

+ --name subnet-1 \

+ --nat-gateway nat-gateway

+1. Select **nat-gateway**.

+1. Select **nat-gateway**.

+Use [Set-AzVirtualNetworkSubnetConfig](/powershell/module/az.network/set-azvirtualnetworksubnetconfig) to remove the NAT gateway association from the subnet by setting the value to $null. Use [Set-AzVirtualNetwork](/powershell/module/az.network/set-azvirtualnetwork) to update the virtual network configuration.

+```azurepowershell

+# Specify the resource group and NAT gateway name

+$resourceGroupName = "test-rg"

+# Specify the virtual network name and subnet name

+$virtualNetworkName = "vnet-1"

+$subnetName = "subnet-1"

+# Get the virtual network

+$vnet = @{

+ Name = $virtualNetworkName

+ ResourceGroupName = $resourceGroupName

+}

+$virtualNetwork = Get-AzVirtualNetwork @vnet

+# Get the subnet

+$subnet = $virtualNetwork.Subnets | Where-Object {$_.Name -eq $subnetName}

+# Remove the NAT gateway association from the subnet

+$subnet.NatGateway = $null

+# Update the subnet configuration

+$subConfig = @{

+ Name = $subnetName

+ VirtualNetwork = $virtualNetwork

+ AddressPrefix = $subnet.AddressPrefix

+}

+Set-AzVirtualNetworkSubnetConfig @subConfig

+# Update the virtual network

+Set-AzVirtualNetwork -VirtualNetwork $virtualNetwork

+```

+Use [Remove-AzNatGateway](/powershell/module/az.network/remove-aznatgateway) to delete the NAT gateway resource.

+```azurepowershell

+# Specify the resource group and NAT gateway name

+$resourceGroupName = "test-rg"

+$natGatewayName = "nat-gateway"

+$nat = @{

+ Name = $natGatewayName

+ ResourceGroupName = $resourceGroupName

+}

+Remove-AzNatGateway @nat

+```

+ΓÇéΓÇéΓÇéΓÇéΓÇéΓÇé--resource-group test-rg \

+ΓÇéΓÇéΓÇéΓÇéΓÇéΓÇé--vnet-name vnet-1 \

+ΓÇéΓÇéΓÇéΓÇéΓÇéΓÇé--name subnet-1 \

+ --name nat-gateway \

+ --resource-group test-rg

+```bicep

+@description('Name of resource group')

+param location string = resourceGroup().location

+var existingVNetName = 'vnet-1'

+var existingSubnetName = 'subnet-1'

+resource vnet 'Microsoft.Network/virtualNetworks@2023-05-01' existing = {

+ name: existingVNetName

+}

+output vnetid string = vnet.id

+resource updatedsubnet01 'Microsoft.Network/virtualNetworks/subnets@2023-06-01' = {

+ parent: vnet

+ name: existingSubnetName

+ properties: {

+ addressPrefix: vnet.properties.subnets[0].properties.addressPrefix

+ }

+}

+```

+ | Resource group | Select your resource group. The example uses **test-rg**. |

+ | Name | Enter *public-ip-nat2*. |

+1. Select **nat-gateway**.

+In this example, the existing IP address associated with the NAT gateway is named *public-ip-nat*. Replace this value with an array that contains both public-ip-nat and a new IP address. If you have multiple IP addresses already configured, you must also add them to the array.

+ Name = 'public-ip-nat2'

+ ResourceGroupName = 'test-rg'

+ Name = 'nat-gateway'

+ ResourceGroupName = 'test-rg'

+ Name = 'public-ip-nat'

+ ResourceGroupName = 'test-rg'

+ Name = 'public-ip-nat2'

+ ResourceGroupName = 'test-rg'

+To remove a public IP from a NAT gateway, create an array object that *doesn't* contain the IP address you want to remove. For example, you have a NAT gateway configured with two public IP addresses. You want to remove one of the IP addresses. The IP addresses associated with the NAT gateway are named public-ip-nat and public-ip-nat2. To remove public-ip-nat2, create an array object for the PowerShell command that contains *only* public-ip-nat. When you apply the command, the array is reapplied to the NAT gateway, and public-ip-nat is the only associated public IP address.

+ Name = 'nat-gateway'

+ ResourceGroupName = 'test-rg'

+ Name = 'public-ip-nat'

+ ResourceGroupName = 'test-rg'

+ Name = 'public-ip-nat2'

+ ResourceGroupName = 'test-rg'

+In this example, the existing public IP address associated with the NAT gateway is named *public-ip-nat*.

+ --resource-group test-rg \

+ --name public-ip-nat2 \

+ --name nat-gateway \

+ --resource-group test-rg \

+ --public-ip-addresses public-ip-nat public-ip-nat2

+Use [az network nat gateway update](/cli/azure/network/nat/gateway#az-network-nat-gateway-update) to remove a public IP address from the NAT gateway. The Azure CLI command replaces the values. It doesn't remove a value. To remove a public IP address, include any IP address in the command that you want to keep. Omit the value that you want to remove. For example, you have a NAT gateway configured with two public IP addresses. You want to remove one of the IP addresses. The IP addresses associated with the NAT gateway are named public-ip-nat and public-ip-nat2. To remove public-ip-nat2, omit the name of the IP address from the command. The command reapplies the IP addresses listed in the command to the NAT gateway. It removes any IP address not listed.

+ --name nat-gateway \

+ --resource-group test-rg \

+ --public-ip-addresses public-ip-nat

+ | Resource group | Select your resource group. This example uses **test-rg**. |

+ | Name | Enter *public-ip-prefix-nat*. |

+1. Select **nat-gateway**.

+In this example, the existing public IP prefix associated with the NAT gateway is named *public-ip-prefix-nat*. Replace this value with an array that contains both public-ip-prefix-nat and a new IP address prefix. If you have multiple IP prefixes already configured, you must also add them to the array.

+ Name = 'public-ip-prefix-nat2'

+ ResourceGroupName = 'test-rg'

+ Name = 'nat-gateway'

+ ResourceGroupName = 'test-rg'

+ Name = 'public-ip-prefix-nat'

+ ResourceGroupName = 'test-rg'

+ Name = 'public-ip-prefix-nat2'

+ ResourceGroupName = 'test-rg'

+To remove a public IP prefix from a NAT gateway, create an array object that *doesn't* contain the IP address prefix that you want to remove. For example, you have a NAT gateway configured with two public IP prefixes. You want to remove one of the IP prefixes. The IP prefixes associated with the NAT gateway are named public-ip-prefix-nat and public-ip-prefix-nat2. To remove public-ip-prefix-nat2, create an array object for the PowerShell command that contains *only* public-ip-prefix-nat. When you apply the command, the array is reapplied to the NAT gateway, and public-ip-prefix-nat is the only prefix associated.

+ Name = 'nat-gateway'

+ ResourceGroupName = 'test-rg'

+ Name = 'public-ip-prefix-nat'

+ ResourceGroupName = 'test-rg'

+ Name = 'public-ip-prefix-nat2'

+ ResourceGroupName = 'test-rg'

+In this example, the existing public IP prefix associated with the NAT gateway is named *public-ip-prefix-nat*.

+ --resource-group test-rg \

+ --name public-ip-prefix-nat2

+ --name nat-gateway \

+ --resource-group test-rg \

+ --public-ip-prefixes public-ip-prefix-nat public-ip-prefix-nat2

+Use [az network nat gateway update](/cli/azure/network/nat/gateway#az-network-nat-gateway-update) to remove a public IP prefix from the NAT gateway. The Azure CLI command replaces the values. It doesn't remove a value. To remove a public IP prefix, include any prefix in the command that you wish to keep. Omit the one you want to remove. For example, you have a NAT gateway configured with two public IP prefixes. You want to remove one of the prefixes. The IP prefixes associated with the NAT gateway are named public-ip-prefix-nat and public-ip-prefix-nat2. To remove public-ip-prefix-nat2, omit the name of the IP prefix from the command. The command reapplies the IP prefixes listed in the command to the NAT gateway. It removes any IP address not listed.

+ --name nat-gateway \

+ --resource-group test-rg \

+ --public-ip-prefixes public-ip-prefix-nat

+### Analytics

+[Azure Stream Analytics - Stream Analytics jobs](../stream-analytics/copy-job.md?toc=/azure/operational-excellence/toc.json)| ✅ | ✅| ❌ |

+[Azure Stream Analytics - Stream Analytics cluster](../stream-analytics/move-cluster.md?toc=/azure/operational-excellence/toc.json)|✅ | ✅| ❌ |

+[Power BI](/power-bi/admin/service-admin-region-move?toc=/azure/operational-excellence/toc.json)| ✅ |❌ | ❌ |

+### Compute

+| Product | Relocation | Relocation with data migration | Resource Mover |

+| | | | |

+[Azure App Service](../app-service/manage-move-across-regions.md?toc=/azure/operational-excellence/toc.json)|✅ | ❌| ❌ |

+[Azure Batch](../batch/account-move.md?toc=/azure/operational-excellence/toc.json)|✅ | ✅| ❌ |

+[Azure Functions](relocation-functions.md)|✅ |❌ | ❌ |

+[Azure Static Web Apps](./relocation-static-web-apps.md) | ✅ |❌ | ❌ |

+### Containers

+| Product | Relocation | Relocation with data migration | Resource Mover |

+[Azure Functions](relocation-functions.md)|✅ |❌ | ❌ |

+[Azure Kubernetes Service](relocation-kubernetes-service.md)|✅ |✅ | ❌ |

+### Databases

+| Product | Relocation | Relocation with data migration | Resource Mover |

+| | | | |

+[Azure Cache for Redis](../azure-cache-for-redis/cache-moving-resources.md?toc=/azure/operational-excellence/toc.json)| ✅ | ❌| ❌ |

+### Integration

+| Product | Relocation |Relocation with data migration | Resource Mover |

+| | | | |

+[Azure API Management](../api-management/api-management-howto-migrate.md?toc=/azure/operational-excellence/toc.json)| ✅ | ✅| ❌ |

+[Azure Logic apps](../logic-apps/move-logic-app-resources.md?toc=/azure/operational-excellence/toc.json)| ✅| ❌ | ❌ |

+### Internet of Things

+| Product | Relocation |Relocation with data migration | Resource Mover |

+| | | | |

+[Azure API Management](../api-management/api-management-howto-migrate.md?toc=/azure/operational-excellence/toc.json)| ✅ | ✅| ❌ |

+[Azure Cosmos DB](relocation-cosmos-db.md)|✅ | ✅| ❌ |

+[Azure IoT Hub](/azure/iot-hub/iot-hub-how-to-clone?toc=/azure/operational-excellence/toc.json)| ✅ | ✅| ❌ |

+### Management and governance

+| Product | Relocation |Relocation with data migration | Resource Mover |

+[Azure Backup](relocation-backup.md)| ✅ | ❌| ❌ |

+[Azure Monitor - Log Analytics](./relocation-log-analytics.md)| ✅| ❌ | ❌ |

+[Azure Site Recovery (Recovery Services vaults)](relocation-site-recovery.md)| ✅ | ✅| ❌ |

+### Networking

+| Product | Relocation |Relocation with data migration | Resource Mover |

+| | | | |

+[Azure Application Gateway and Web Application Firewall](relocation-app-gateway.md)| ✅ | ❌| ❌ |

+[Azure Load Balancer](../load-balancer/move-across-regions-external-load-balancer-portal.md)| ✅ | ✅| ❌ |

+[Azure Private Link Service](./relocation-private-link.md) | ✅| ❌ | ❌ |

+[Azure Virtual Network](./relocation-virtual-network.md)| ✅| ❌ | ✅ |

+[Azure Virtual Network - Network Security Groups](./relocation-virtual-network-nsg.md)|✅ |❌ | ✅ |

+### Security

+| Product | Relocation |Relocation with data migration | Resource Mover |

+| | | | |

+[Azure Firewall](./relocation-firewall.md)|❌ | ✅| ❌ |

+[Azure Application Gateway and Web Application Firewall](relocation-app-gateway.md)| ✅ | ❌| ❌ |

+[Azure Key Vault](./relocation-key-vault.md)| ✅ | ✅| ❌ |

+[Managed identities for Azure resources](relocation-storage-account.md)| ✅| ❌ | ❌ |

+### Storage

+| Product | Relocation |Relocation with data migration | Resource Mover |

+| | | | |

+[Azure Backup](relocation-backup.md)| ✅ | ❌| ❌ |

+[Azure Storage Account](relocation-storage-account.md)| ✅ | ✅| ❌ |

+> | Virtual Machines: LSv3-series |

+The next step is to create Azure files in the storage account. Azure files use a provisioned model for premium file shares. In a provisioned business model, you proactively specify to Azure files what your storage requirements are, rather than being billed based on what you use. To understand more about this model, see [Provisioned model](../../storage/files/understanding-billing.md#provisioned-v1-model). In this example, we create two Azure files: frsinput (256 GB) and frsoutput (256 GB) for the SAP BOBI file store.

+* The minimum share size is 100 GiB. You only pay for the [capacity of the provisioned shares](../../storage/files/understanding-billing.md#provisioned-v1-model).

+* The minimum share size is 100 GiB. You only pay for the [capacity of the provisioned shares](../../storage/files/understanding-billing.md#provisioned-v1-model).

+* The minimum share size is 100 GiB. You pay for only the [capacity of the provisioned shares](../../storage/files/understanding-billing.md#provisioned-v1-model).

+|

+| [Entrust Root Certification Authority G2](http://web.entrust.com/root-certificates/entrust_g2_ca.cer) | 4a538c28<br>8CF427FD790C3AD166068DE81E57EFBB932272D4 |

+| [Microsoft RSA Root Certificate Authority 2017](https://www.microsoft.com/pkiops/certs/Microsoft%20RSA%20Root%20Certificate%20Authority%202017.crt) | 0x1ed397095fd8b4b347701eaabe7f45b3<br>73A5E64A3BFF8316FF0EDCCC618A906E4EAE4D74 |

+| [DigiCert Cloud Services CA-1](https://crt.sh/?d=3439320284) | 0f171a48c6f223809218cd2ed6ddc0e8<br>B3F6B64A07BB9611F47174407841F564FB991F29 |

+| [DigiCert TLS RSA SHA256 2020 CA1](https://crt.sh/?d=3427370830) | 0a3508d55c292b017df8ad65c00ff7e4<br>6938FD4D98BAB03FAADB97B34396831E3780AEA1 |

+| [Entrust Certification Authority - L1K](http://aia.entrust.net/l1k-chain256.cer) | 0ee94cc30000000051d37785<br>F21C12F46CDB6B2E16F09F9419CDFF328437B2D7 |

+| [Entrust Certification Authority - L1M](http://aia.entrust.net/l1m-chain256.cer) | 61a1e7d20000000051d366a6<br>CC136695639065FAB47074D28C55314C66077E90 |

+| [Microsoft ECC TLS Issuing AOC CA 01](https://crt.sh/?d=4789656467) | 0x33000000282bfd23e7d1add707000000000028<br>30AB5C33EB4B77D4CBFF00A11EE0A7507D9DD316 |

+| [Microsoft ECC TLS Issuing AOC CA 02](https://crt.sh/?d=4814787086) | 0x33000000290f8a6222ef6a5695000000000029<br>3709CD92105D074349D00EA8327F7D5303D729C8 |

+| [Microsoft ECC TLS Issuing EOC CA 01](https://crt.sh/?d=4814787088) | 0x330000002a2d006485fdacbfeb00000000002a<br>5FA13B879B2AD1B12E69D476E6CAD90D01013B46 |

+| [Microsoft ECC TLS Issuing EOC CA 02](https://crt.sh/?d=4814787085) | 0x330000002be6902838672b667900000000002b<br>58A1D8B1056571D32BE6A7C77ED27F73081D6E7A |

+| [Microsoft RSA TLS Issuing AOC CA 01](https://crt.sh/?d=4789678141) | 0x330000002ffaf06f6697e2469c00000000002f<br>4697FDBED95739B457B347056F8F16A975BAF8EE |

+| [Microsoft RSA TLS Issuing AOC CA 02](https://crt.sh/?d=4814787092) | 0x3300000030c756cc88f5c1e7eb000000000030<br>90ED2E9CB40D0CB49A20651033086B1EA2F76E0E |

+| [Microsoft RSA TLS Issuing EOC CA 01](https://crt.sh/?d=4814787098) | 0x33000000310c4914b18c8f339a000000000031<br>A04D3750DEBFCCF1259D553DBEC33162C6B42737 |

+| [Microsoft RSA TLS Issuing EOC CA 02](https://crt.sh/?d=4814787087) | 0x3300000032444d7521341496a9000000000032<br>697C6404399CC4E7BB3C0D4A8328B71DD3205563 |

+| Γöö [DigiCert Cloud Services CA-1](https://crt.sh/?d=3439320284) | 0f171a48c6f223809218cd2ed6ddc0e8<br>B3F6B64A07BB9611F47174407841F564FB991F29 |

+| Γöö [DigiCert TLS RSA SHA256 2020 CA1](https://crt.sh/?d=3427370830) | 0a3508d55c292b017df8ad65c00ff7e4<br>6938FD4D98BAB03FAADB97B34396831E3780AEA1 |

+| [**Entrust Root Certification Authority G2**](http://web.entrust.com/root-certificates/entrust_g2_ca.cer) | 4a538c28<br>8CF427FD790C3AD166068DE81E57EFBB932272D4 |

+| Γöö [Entrust Certification Authority - L1K](http://aia.entrust.net/l1k-chain256.cer) | 0ee94cc30000000051d37785<br>F21C12F46CDB6B2E16F09F9419CDFF328437B2D7 |

+| Γöö [Entrust Certification Authority - L1M](http://aia.entrust.net/l1m-chain256.cer) | 61a1e7d20000000051d366a6<br>CC136695639065FAB47074D28C55314C66077E90 |

+| Γöö [Microsoft ECC TLS Issuing AOC CA 01](https://crt.sh/?d=4789656467) |33000000282bfd23e7d1add707000000000028<br>30AB5C33EB4B77D4CBFF00A11EE0A7507D9DD316 |

+| Γöö [Microsoft ECC TLS Issuing AOC CA 02](https://crt.sh/?d=4814787086) |33000000290f8a6222ef6a5695000000000029<br>3709CD92105D074349D00EA8327F7D5303D729C8 |

+| Γöö [Microsoft ECC TLS Issuing EOC CA 01](https://crt.sh/?d=4814787088) |330000002a2d006485fdacbfeb00000000002a<br>5FA13B879B2AD1B12E69D476E6CAD90D01013B46 |

+| Γöö [Microsoft ECC TLS Issuing EOC CA 02](https://crt.sh/?d=4814787085) |330000002be6902838672b667900000000002b<br>58A1D8B1056571D32BE6A7C77ED27F73081D6E7A |

+| Γöö [Microsoft RSA TLS Issuing AOC CA 02](https://crt.sh/?d=4814787092) |3300000030c756cc88f5c1e7eb000000000030<br>90ED2E9CB40D0CB49A20651033086B1EA2F76E0E |

+| Γöö [Microsoft RSA TLS Issuing EOC CA 01](https://crt.sh/?d=4814787098) |33000000310c4914b18c8f339a000000000031<br>A04D3750DEBFCCF1259D553DBEC33162C6B42737 |

+| Γöö [Microsoft RSA TLS Issuing EOC CA 02](https://crt.sh/?d=4814787087) |3300000032444d7521341496a9000000000032<br>697C6404399CC4E7BB3C0D4A8328B71DD3205563 |

+Microsoft updated Azure services to use TLS certificates from a different set of Root Certificate Authorities (CAs) on February 15, 2021, to comply with changes set forth by the C) for additional information.

+- October 8, 2024: Removed the following CAs and CDP endpoints: crl.microsoft.com, mscrl.microsoft.com, and ocsp.msocsp.com.

+ | Certificate Authority | Serial Number<br>Thumbprint |

+ |- |- |

+ |[Baltimore CyberTrust Root](https://cacerts.digicert.com/BaltimoreCyberTrustRoot.crt) | 0x20000b9<br>D4DE20D05E66FC53FE1A50882C78DB2852CAE474 |

+ |[Microsoft RSA TLS CA 01](https://crt.sh/?d=3124375355) | 0x0f14965f202069994fd5c7ac788941e2<br>703D7A8F0EBF55AAA59F98EAF4A206004EB2516A |

+ |[Microsoft RSA TLS CA 02](https://crt.sh/?d=3124375356) | 0x0fa74722c53d88c80f589efb1f9d4a3a<br>B0C2D2D13CDD56CDAA6AB6E2C04440BE4A429C75 |

+ |[Microsoft Azure ECC TLS Issuing CA 01](https://www.microsoft.com/pki/certs/Microsoft%20Azure%20ECC%20TLS%20Issuing%20CA%2001.cer)|0x09dc42a5f574ff3a389ee06d5d4de440<br>92503D0D74A7D3708197B6EE13082D52117A6AB0|

+- July 17, 2023: Added 16 new subordinate Certificate Authorities.

+- February 7, 2023: Added eight new subordinate Certificate Authorities.

+zone_pivot_group_filename: service-connector/zone-pivot-groups.json

+zone_pivot_groups: aks-authtype

+Create a service connection between your AKS cluster and your SQL database using Microsoft Entra Workload ID

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

+1. In the [Azure portal](https://portal.azure.com/), navigate to your AKS cluster resource.

+2. Select **Settings** > **Service Connector (Preview)** > **Create**.

+3. On the **Basics** tab, configure the following settings:

+ * **Kubernetes namespace**: Select **default**.

+ * **Service type**: Select **SQL Database**.

+ * **Connection name**: Use the connection name provided by Service Connector or enter your own connection name.

+ * **Subscription**: Select the subscription that includes the Azure SQL Database service.

+ * **SQL server**: Select your SQL server.

+ * **SQL database**: Select your SQL database.

+ * **Client type**: The code language or framework you use to connect to the target service, such as **Python**.

+

+ :::image type="content" source="media/tutorial-ask-sql/create-connection.png" alt-text="Screenshot of the Azure portal showing the form to create a new connection to a SQL database in AKS.":::

+4. Select **Next: Authentication**. On the **Authentication** tab, select **Workload Identity** and choose one **User assigned managed identity**.

+5. Select **Next: Networking** > **Next: Review + create** >**Create On Cloud Shell**.

+6. The Cloud Shell will be launched and execute the commands to create a connection. You may need to confirm some configuration changes during the command processing. Once command runs successfully, it will show connection information, and you can click refresh button in **Service Connector** pane to show the latest result.

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

+Create a service connection to the SQL database using the [`az aks connection create sql`](/cli/azure/aks/connection/create#az-aks-connection-create-sql) command. You can run this command in two different ways:

+

+ * generate the new connection step by step.

+

+ ```azurecli-interactive

+ az aks connection create sql

+ ```

+

+ * generate the new connection at once. Make sure you replace the following placeholders with your own information: `<source-subscription>`, `<source_resource_group>`, `<cluster>`, `<target-subscription>`, `<target_resource_group>`, `<server>`, `<database>`, and `<***>`.

+

+ ```azurecli-interactive

+ az aks connection create sql \

+ --source-id /subscriptions/<source-subscription>/resourceGroups/<source_resource_group>/providers/Microsoft.ContainerService/managedClusters/<cluster> \

+ --target-id /subscriptions/<target-subscription>/resourceGroups/<target_resource_group>/providers/Microsoft.Sql/servers/<server>/databases/<database> \

+ --workload-identity /subscriptions/<identity-subscription>/resourcegroups/<resource_group>/providers/Microsoft.ManagedIdentity/userAssignedIdentities/<identity_name>

+ ```

+> [!WARNING]

+> Microsoft recommends that you use the most secure authentication flow available. The authentication flow described in this procedure requires a very high degree of trust in the application, and carries risks that are not present in other flows. You should only use this flow when other more secure flows, such as managed identities, aren't viable. Select the authentication method *[Workload ID (Recommended)](tutorial-python-aks-sql-database-connection-string.md?pivots=workload-id#create-a-new-connection)*.

+Create a service connection between your AKS cluster and your SQL database using a connection string

+| Customer-managed planned failover (preview) | Storage account | The storage service endpoints for the primary and secondary regions are available, and you want to perform disaster recovery testing. <br></br> The storage service endpoints for the primary region are available, but another service is preventing your workloads from functioning properly.<br><br>To proactively prepare for large-scale disasters, such as a hurricane, that might affect a region. | [No](#anticipate-data-loss-and-inconsistencies) | [Yes <br> *(In preview)*](#hierarchical-namespace-hns) |

+Planned failover can be utilized in multiple scenarios including planned disaster recovery testing, a proactive approach to large scale disasters, or to recover from nonstorage related outages.

+Microsoft might initiate a regional failover in extreme circumstances, such as a catastrophic disaster that impacts an entire geo region. During these events, no action on your part is required. If your storage account is configured for RA-GRS or RA-GZRS, your applications can read from the secondary region during a Microsoft-managed failover. However, you don't have write access to your storage account until the failover process is complete.

+| **Storage Actions** | Supported¹ | Supported¹ |

+¹ If you initiate a customer-managed planned or unplanned failover, storage tasks can't operate on the account until it fails back to the original primary region. [Learn more](../../reliability/reliability-storage-actions.md#cross-region-disaster-recovery-and-business-continuity).

+Storage account failovers are a temporary solution used to develop and test your disaster recovery (DR) plans, or to recover from a service outage. Failover shouldn't be used as part of your data migration strategy. For information about how to migrate your storage accounts, see [Azure Storage migration overview](storage-migration-overview.md).

+After a failover is complete, clients can once again read and write Azure Storage data in the new primary region. However, the Azure Storage resource provider doesn't fail over, so resource management operations must still take place in the primary region. If the primary region is unavailable, you aren't be able to perform management operations on the storage account.

+Because the Azure Storage resource provider doesn't fail over, the [Location](/dotnet/api/microsoft.azure.management.storage.models.trackedresource.location) property will return the original primary location after the failover is complete.

+<br>

+<iframe width="560" height="315" src="

+https://www.youtube-nocookie.com/embed/lcQfwWsck58?si=I92_-lGOLcr4pUSk"

+title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen></iframe>

+| Windows Server 2025 | Azure, Datacenter, Essentials, Standard, and IoT | Full and Core |

+**Windows Server 2025, Windows Server 2022, Windows Server 2019, and Windows Server 2016**

+Data Deduplication is supported irrespective of whether cloud tiering is enabled or disabled on one or more server endpoints on the volume for Windows Server 2016, Windows Server 2019, Windows Server 2022 and Windows Server 2025. Enabling Data Deduplication on a volume with cloud tiering enabled lets you cache more files on-premises without provisioning more storage.

+- If a server running Windows Server 2012 R2 with the Azure File Sync agent installed is upgraded to Windows Server 2016, Windows Server 2019, Windows Server 2022, or Windows Server 2025, the following steps must be performed to support Data Deduplication and cloud tiering on the same volume:

+ - Download the Azure File Sync agent for the new server operating system version (Windows Server 2016, Windows Server 2019, Windows Server 2022, or Windows Server 2025).

+| V19 Release - [KB5040924](https://support.microsoft.com/topic/e44fc142-8a24-4dea-9bf9-6e884b4b342e)| 19.1.0.0 | September 3, 2024 | Supported |

+| V16 Release | 16.0.0.0 - 16.2.0.0 | N/A | Not Supported - Agent versions expired on October 7, 2024 |

+**Support for Windows Server 2025**

+The Azure File Sync agent is now supported on Windows Server 2025.

+Another latency indicator to look that for might suggest a problem is an increased frequency or abnormal spikes in **Success Server Latency**. This is commonly due to throttling due to exceeding the Azure Files [scale limits](storage-files-scale-targets.md) for standard file shares, or an under-provisioned [Azure Files Premium Share](understanding-billing.md#provisioned-v1-model).

+NFS Azure file shares are only offered on premium file shares, which store data on solid-state drives (SSD). The IOPS and throughput of NFS shares scale with the provisioned capacity. See the [provisioned model](understanding-billing.md#provisioned-v1-model) section of the **Understanding billing** article to understand the formulas for IOPS, IO bursting, and throughput. The average IO latencies are low-single-digit-millisecond for small IO size, while average metadata latencies are high-single-digit-millisecond. Metadata heavy operations such as untar and workloads like WordPress might face additional latencies due to the high number of open and close operations.

+If you're taking snapshots of Azure file shares, there are differences in how Reservations work for standard versus premium file shares. If you're taking snapshots of standard file shares, then the snapshot differentials count against the Reservation and are billed as part of the normal used storage meter. However, if you're taking snapshots of premium file shares, then the snapshots are billed using a separate meter and don't count against the Reservation.

+- [The provisioned model for premium Azure file shares](understanding-billing.md#provisioned-v1-model)

+- [The provisioned model for premium Azure file shares](understanding-billing.md#provisioned-v1-model)

+- Premium share performance is bound by provisioned share size (IOPS/egress/ingress) and single file limits. For details, see [Understanding provisioning for premium file shares](understanding-billing.md#provisioned-v1-model).

+| Billing model | <ul><li>[Provisioned capacity for premium file shares](./understanding-billing.md#provisioned-v1-model)</li><li>[Pay-as-you-go for standard file shares](./understanding-billing.md#pay-as-you-go-model)</li></ul> | [Provisioned capacity](./understanding-billing.md#provisioned-v1-model) |

+description: Learn about the scalability and performance targets for Azure Files and Azure File Sync, including file share storage, IOPS, and throughput.

+[Azure Files](storage-files-introduction.md) offers fully managed file shares in the cloud that are accessible via the Server Message Block (SMB) and Network File System (NFS) file system protocols. This article discusses the scalability and performance targets for Azure Files and Azure File Sync.

+| Management model | Billing model | Media tier | Redundancy | SMB | NFS |

+|-|-|-|-|:-:|:-:|

+| Microsoft.Storage | Provisioned v2 | HDD (standard) | Local (LRS) |  |  |

+| Microsoft.Storage | Provisioned v2 | HDD (standard) | Zone (ZRS) |  |  |

+| Microsoft.Storage | Provisioned v2 | HDD (standard) | Geo (GRS) |  |  |

+| Microsoft.Storage | Provisioned v2 | HDD (standard) | GeoZone (GZRS) |  |  |

+| Microsoft.Storage | Provisioned v1 | SSD (premium) | Local (LRS) |  |  |

+| Microsoft.Storage | Provisioned v1 | SSD (premium) | Zone (ZRS) |  | |

+| Microsoft.Storage | Pay-as-you-go | HDD (standard) | Local (LRS) |  |  |

+| Microsoft.Storage | Pay-as-you-go | HDD (standard) | Zone (ZRS) |  |  |

+| Microsoft.Storage | Pay-as-you-go | HDD (standard) | Geo (GRS) |  |  |

+| Microsoft.Storage | Pay-as-you-go | HDD (standard) | GeoZone (GZRS) |  |  |

+- **FileStorage storage accounts**: FileStorage storage accounts allow you to deploy Azure file shares with a provisioned billing model. FileStorage accounts can only be used to store Azure file shares; no other storage resources (blob containers, queues, tables, etc.) can be deployed in a FileStorage account.

+- **General purpose version 2 (GPv2) storage accounts**: GPv2 storage accounts allow you to deploy pay-as-you-go file shares on HDD-based hardware. In addition to storing Azure file shares, GPv2 storage accounts can store other storage resources such as blob containers, queues, or tables.

+| Attribute | SSD provisioned v1 | HDD provisioned v2 | HDD pay-as-you-go |

+|-|-|-|-|

+| Storage account kind | FileStorage | FileStorage | StorageV2 |

+| SKUs | <ul><li>Premium_LRS</li><li>Premium_ZRS</li></ul> | <ul><li>StandardV2_LRS</li><li>StandardV2_ZRS</li><li>StandardV2_GRS</li><li>StandardV2_GZRS</li></ul> | <ul><li>Standard_LRS</li><li>Standard_ZRS</li><li>Standard_GRS</li><li>Standard_GZRS</li></ul> |

+| Number of storage accounts per region per subscription | 250 | 250 | 250 |

+| Maximum storage capacity | 100 TiB | 4 PiB | 5 PiB |

+| Maximum number of file shares | 1024 (recommended to use 50 or fewer) | 50 | Unlimited (recommended to use 50 or fewer) |

+| Maximum IOPS | 102,400 IOPS | 50,000 IOPS | 20,000 IOPS |

+| Maximum throughput | 10,340 MiB / sec | 5,120 MiB / sec | <ul><li>Select regions:<ul><li>Ingress: 7,680 MiB / sec</li><li>Egress: 25,600 MiB / sec</li></ul></li><li>Default:<ul><li>Ingress: 3,200 MiB / sec</li><li>Egress: 6,400 MiB / sec</li></ul></li></ul> |

+| Maximum number of virtual network rules | 200 | 200 | 200 |

+| Maximum number of IP address rules | 200 | 200 | 200 |

+| Management read operations | 800 per 5 minutes | 800 per 5 minutes | 800 per 5 minutes |

+| Management write operations | 10 per second/1200 per hour | 10 per second/1200 per hour | 10 per second/1200 per hour |

+| Management list operations | 100 per 5 minutes | 100 per 5 minutes | 100 per 5 minutes |

+#### Selected regions with increased maximum throughput for HDD pay-as-you-go

+The following regions have an increased maximum throughput for HDD pay-as-you-go storage accounts (StorageV2):

+- East Asia

+- Southeast Asia

+- Australia East

+- Brazil South

+- Canada Central

+- China East 2

+- China North 3

+- North Europe

+- West Europe

+- France Central

+- Germany West Central

+- Central India

+- Japan East

+- Jio India West

+- Korea Central

+- Norway East

+- South Africa North

+- Sweden Central

+- UAE North

+- UK South

+- Central US

+- East US

+- East US 2

+- US Gov Virginia

+- US Gov Arizona

+- North Central US

+- South Central US

+- West US

+- West US 2

+- West US 3

+| Attribute | SSD provisioned v1 | HDD provisioned v2 | HDD pay-as-you-go |

+| Storage provisioning unit | 1 GiB | 1 GiB | N/A |

+| IOPS provisioning unit | N/A | 1 IO / sec | N/A |

+| Throughput provisioning unit | N/A | 1 MiB / sec | N/A |

+| Minimum storage size | 100 GiB (provisioned) | 32 GiB (provisioned) | 0 bytes |

+| Maximum storage size | 100 TiB | 256 TiB | 100 TiB |

+| Maximum number of files | Unlimited | Unlimited | Unlimited |

+| Maximum IOPS | 102,400 IOPS (dependent on provisioning) | 50,000 IOPS (dependent on provisioning) | 20,000 IOPS |

+| Maximum throughput | 10,340 MiB / sec (dependent on provisioning) | 5,120 IOPS (dependent on provisioning) | Up to storage account limits |

+| Maximum number of share snapshots | 200 snapshots | 200 snapshots | 200 snapshots |

+| Maximum filename length³ (full pathname including all directories, file names, and backslash characters) | 2,048 characters | 2,048 characters | 2,048 characters |

+| Maximum length of individual pathname component² (in the path \A\B\C\D, each letter represents a directory or file that is an individual component) | 255 characters | 255 characters | 255 characters |

+| Hard link limit (NFS only) | 178 | N/A | N/A |

+| Maximum number of SMB Multichannel channels | 4 | N/A | N/A |

+| Maximum number of stored access policies per file share | 5 | 5 | 5 |

+³ Azure Files enforces certain [naming rules](/rest/api/storageservices/naming-and-referencing-shares--directories--files--and-metadata#directory-and-file-names) for directory and file names.

+| Attribute | SSD provisioned v1 | HDD provisioned v2 | HDD pay-as-you-go |

+| Maximum file size | 4 TiB | 4 TiB | 4 TiB |

+| Maximum data IOPS per file | 8,000 IOPS | 1,000 IOPS | 1,000 IOPS |

+| Maximum throughput per file | 1,024 MiB / sec | 60 MiB / sec | 60 MiB / sec |

+| Maximum concurrent handles for root directory | 10,000 handles | 10,000 handles | 10,000 handles |

+| Maximum concurrent handles per file and directory | 2,000 handles | 2,000 handles | 2,000 handles |

+ - **Provisioned capacity**: For premium file shares only, the provisioned capacity is the amount that you'll be billed for regardless of actual usage. This field is only available in a **FileStorage** storage account type. The IOPS and throughput available on a premium file share are based on the provisioned capacity, so you can provision more capacity to get more performance. The minimum size for a premium file share is 100 GiB. For more information on how to plan for a premium file share, see [provisioning premium file shares](understanding-billing.md#provisioned-v1-model).

+Premium file shares offer a provisioning model that guarantees the following performance profile based on share size. For more information, see the [provisioned v1 model](understanding-billing.md#provisioned-v1-model). Burst credits accumulate in a burst bucket whenever traffic for your file share is below baseline IOPS. Earned credits are used later to enable bursting when operations would exceed the baseline IOPS.

+- **Workload duration and frequency:** Short (minutes) and infrequent (hourly) workloads will be less likely to achieve the upper performance limits of standard file shares compared to long-running, frequently occurring workloads. On premium file shares, workload duration is helpful when determining the correct performance profile to use based on the provisioning size. Depending on how long the workload needs to [burst](understanding-billing.md#provisioned-v1-bursting) for and how long it spends below the baseline IOPS, you can determine if you're accumulating enough bursting credits to consistently satisfy your workload at peak times. Finding the right balance will reduce costs compared to over-provisioning the file share. A common mistake is to run performance tests for only a few minutes, which is often misleading. To get a realistic view of performance, be sure to test at a sufficiently high frequency and duration.

+description: Learn how to interpret the provisioned and pay-as-you-go billing models for Azure Files. Understand total cost of ownership, storage reservations, and burst credits.

+Azure Files supports two different media tiers of storage, SSD and HDD, which allow you to tailor your file shares to the performance and price requirements of your scenario:

+- **SSD (premium)**: file shares hosted on solid-state drives (SSDs) provide consistent high performance and low latency, within single-digit milliseconds for most IO operations.

+- **HDD (standard)**: file shares host on hard disk drives (HDDs) provide cost-effective storage for general purpose use.

+Azure Files has multiple pricing models including provisioned and pay-as-you-go options:

+- **Provisioned billing models**: In a provisioned billing model, the primary costs of the file share are based on the amount of storage, IOPS (input and output operations per second), and throughput you provision when you create or update your file share, regardless of how much you use. Azure Files has two different provisioned models *provisioned v2* and *provisioned v1*.

+ - **Provisioned v2**: In the provisioned v2 model, you have the ability to separately provision storage, IOPS, and throughput, although we provide a recommendation for you to help you with first time provisioning.

+ - **Provisioned v1**: In the provisioned v1 model, you provision the amount of storage you need for the share while IOPS and throughput are determined based on how much storage you provision. The provisioned v1 model for Azure Files is only available for SSD file shares.

+

+- **Pay-as-you-go billing model**: In a pay-as-you-go model, the cost of the file share is based on how much you use the share, in the form of used storage, transaction, and data transfer costs. The pay-as-you-go model for Azure Files is only available for HDD file shares. We recommend using the provisioned v2 model for new HDD file share deployments.

+

+This article explains the billing models for Azure Files work to help you understand your monthly Azure Files bill. For Azure Files pricing information, see [Azure Files pricing page](https://azure.microsoft.com/pricing/details/storage/files/).

+| Management model | Billing model | Media tier | Redundancy | SMB | NFS |

+|-|-|-|-|:-:|:-:|

+| Microsoft.Storage | Provisioned v2 | HDD (standard) | Local (LRS) |  |  |

+| Microsoft.Storage | Provisioned v2 | HDD (standard) | Zone (ZRS) |  |  |

+| Microsoft.Storage | Provisioned v2 | HDD (standard) | Geo (GRS) |  |  |

+| Microsoft.Storage | Provisioned v2 | HDD (standard) | GeoZone (GZRS) |  |  |

+| Microsoft.Storage | Provisioned v1 | SSD (premium) | Local (LRS) |  |  |

+| Microsoft.Storage | Provisioned v1 | SSD (premium) | Zone (ZRS) |  | |

+| Microsoft.Storage | Pay-as-you-go | HDD (standard) | Local (LRS) |  |  |

+| Microsoft.Storage | Pay-as-you-go | HDD (standard) | Zone (ZRS) |  |  |

+| Microsoft.Storage | Pay-as-you-go | HDD (standard) | Geo (GRS) |  |  |

+| Microsoft.Storage | Pay-as-you-go | HDD (standard) | GeoZone (GZRS) |  |  |

+Although the base-2 units of measure are commonly used by most operating systems and tools to measure storage quantities, they're frequently mislabeled as the base-10 units, which you might be more familiar with: KB, MB, GB, and TB. Although the reasons for the mislabeling vary, the common reason why operating systems like Windows mislabel the storage units is because many operating systems began using these acronyms before they were standardized by the IEC (International Electrotechnical Commission), BIPM (International Bureau of Weights and Measures), and NIST (US National Institute of Standards and Technology).

+- **How do you pay for storage, IOPS, and bandwidth?** Most cloud solutions have models that align with the principles of either provisioned storage, such as price determinism and simplicity, or pay-as-you-go storage, which can optimize costs by only charging you for what you actually use. Of particular interest for provisioned models are minimum provisioned share size, the provisioning unit, and the ability to increase and decrease provisioning.

+- **What do you need to manage?** With Azure Files, the basic unit of management is a storage account. Other solutions might require extra management, such as operating system updates or virtual resource management such as VMs, disks, and network IP addresses.

+## Provisioned v2 model

+The provisioned v2 model for Azure Files pairs predictability of total cost of ownership with flexibility, allowing you to create a file share that meets your exact storage and performance requirements. When you create a new provisioned v2 file share, you specify how much storage, IOPS, and throughput your file share needs. The amount of each quantity that you provision determines your total bill.

+The amount of storage, IOPS, and throughput you provision are the guaranteed limits of your file share's usage. For example, if you provision a 2 TiB share and upload 2 TiB of data to your share, your share will be full and you will not be able to add more data unless you increase the size of your share, or delete some of the data. Credit-based IOPS bursting provides added flexibility around usage, on a best-effort basis, while credits remain.

+The amount of storage, IOPS, and throughput you provision can be dynamically scaled up or down as your needs change, however, you can only decrease a provisioned quantity only after 24 hours have elapsed since your last quantity increase. Storage, IOPS, and throughput changes are effective within a few minutes after a provisioning change.

+By default, when you create a new file share using the provisioned v2 model, we provide a recommendation for how many IOPS and how much throughput you need based on the amount of provisioned storage you specify. Although these recommendations are based on typical customer usage for that amount of provisioned storage for that media tier in Azure Files, you may find that your workload requires more or less IOPS and throughput than the "typical file share", and you can optionally provision more or less IOPS and throughput depending on your individual file share requirements.

+### Availability

+The provisioned v2 model is provided for file shares in storage accounts with the *FileStorage* storage account kind. At present, the following subset of storage account SKUs are available:

+| Storage account kind | Storage account SKU | Type of file share available |

+|-|-|-|

+| FileStorage | StandardV2_LRS | HDD provisioned v2 file shares with the Local (LRS) redundancy specified. |

+| FileStorage | StandardV2_ZRS | HDD provisioned v2 file shares with the Zone (ZRS) redundancy specified. |

+| FileStorage | StandardV2_GRS | HDD provisioned v2 file shares with the Geo (GRS) redundancy specified. |

+| FileStorage | StandardV2_GZRS | HDD provisioned v2 file shares with the GeoZone (GZRS) redundancy specified. |

+Currently, these SKUs are generally available in a limited subset of regions:

+- France Central

+- France South

+- Australia East

+- Australia Southeast

+- East Asia

+- Southeast Asia

+### Provisioning detail

+When you create a provisioned v2 file share, you specify the provisioned capacity for the file share in terms of storage, IOPS, and throughput. File shares are limited based on the following attributes:

+| Item | HDD value |

+|-|-|

+| Storage provisioning unit | 1 GiB |

+| IOPS provisioning unit | 1 IO / sec |

+| Throughput provisioning unit | 1 MiB / sec |

+| Minimum provisioned storage per file share | 32 GiB |

+| Minimum provisioned IOPS per file share | 500 IOPS |

+| Minimum provisioned throughput per file share | 60 MiB / sec |

+| Maximum provisioned storage per file share | 256 TiB (262,144 GiB) |

+| Maximum provisioned IOPS per file share | 50,000 IOPS |

+| Maximum provisioned throughput per file share | 5,120 MiB / sec |

+| Maximum provisioned storage per storage account | 4 PiB (4,194,304 GiB) |

+| Maximum provisioned IOPS per storage account | 50,000 IOPS |

+| Maximum provisioned throughput per storage account | 5,120 MiB / sec |

+| Maximum number of file shares per storage account | 50 file shares |

+By default, we recommended IOPS and throughput provisioning based on the provisioned storage you specify. These recommendation formulas are based on typical customer usage for that amount of provisioned storage for that media tier in Azure Files:

+| Formula name | HDD formula |

+|-|-|

+| IOPS recommendation | `MIN(MAX(1000 + 0.2 * ProvisionedStorageGiB, 500), 50000)` |

+| Throughput recommendation | `MIN(MAX(60 + 0.02 * ProvisionedStorageGiB, 60), 5120)` |

+Depending on your individual file share requirements, you may find that you require more or less IOPS or throughput than our recommendations, and can optionally override these recommendations with your own values as desired.

+### Provisioned v2 bursting

+Credit-based IOPS bursting provides added flexibility around IOPS usage. This flexibility is best used as a buffer against unanticipated IO-spikes. For established IO patterns, we recommend provisioning for IO peaks.

+Burst IOPS credits accumulate whenever traffic for your file share is below provisioned (baseline) IOPS. Whenever a file share's IOPS usage exceeds the provisioned IOPS and there are available burst IOPS credits, the file share can burst up to the maximum allowed burst IOPS limit. File shares can continue to burst as long as there are credits remaining, but this is based on the number of burst credits accrued. Each IO beyond provisioned IOPS consumes one credit. Once all credits are consumed, the share returns to the provisioned IOPS. IOPS against the file share don't have to do anything special to use bursting. Bursting operates on a best effort basis.

+Share credits have three states:

+- Accruing, when the file share is using less than the provisioned IOPS.

+- Declining, when the file share is using more than the provisioned IOPS and in the bursting mode.

+- Constant, when the files share is using exactly the provisioned IOPS and there are either no credits accrued or used.

+A new file share starts with the full number of credits in its burst bucket. Burst credits don't accrue if the share IOPS fall below the provisioned limit due to throttling by the server. The following formulas are used to determine the burst IOPS limit and the number of credits possible for a file share:

+| Item | HDD formula |

+|-|-|

+| Burst IOPS limit | `MIN(MAX(3 * ProvisionedIOPS, 5000), 50000)` |

+| Burst IOPS credits | `(BurstLimit - ProvisionedIOPS) * 3600` |

+The following table illustrates a few examples of these formulas for various provisioned IOPS amounts:

+| Provisioned IOPS | HDD burst IOPS limit | HDD burst credits |

+|-|-|-|

+| 500 | Up to 5,000 | 16,200,000 |

+| 1,000 | Up to 5,000 | 14,400,000 |

+| 3,000 | Up to 9,000 | 21,600,000 |

+| 5,000 | Up to 15,000 | 36,000,000 |

+| 10,000 | Up to 30,000 | 72,000,000 |

+| 25,000 | Up to 50,000 | 90,000,000 |

+| 50,000 | Up to 50,000 | 0 |

+### Provisioned v2 snapshots

+Azure Files supports snapshots, which are similar to volume shadow copies (VSS) on Windows File Server. For more information on share snapshots, see [Overview of snapshots for Azure Files](storage-snapshots-files.md).

+Snapshots are always differential from the live share and from each other. In the provisioned v2 billing model, if the total differential size of all snapshots fits within the excess provisioned storage space of the file share, there is no extra cost for snapshot storage. If the size of the live share data plus the differential snapshot data is greater than the provisioned storage of the share, the excess used capacity of the snapshots is billed against the **Overflow Snapshot Usage** meter. The formula for determining the amount of overflow is: `MAX((LiveShareUsedGiB + SnapshotDifferentialUsedGiB) - ProvisionedStorageGiB, 0)`

+Some value-added services for Azure Files use snapshots as part of their value proposition. See [value-added services for Azure Files](#value-added-services) for more information.

+### Provisioned v2 soft-delete

+Deleted file shares in storage accounts with soft-delete enabled are billed based on the used storage capacity of the deleted share for the duration of the soft-delete period. To ensure that a deleted file share can always be restored, the provisioned storage, IOPS, and throughput of the share count against the storage account's limits until the file share is purged, however are not billed. For more information on soft-delete, see [How to enable soft delete on Azure file shares](storage-files-enable-soft-delete.md).

+### Provisioned v1 billing meters

+File shares provisioned using the provisioned v2 billing model are billed against the following five billing meters:

+- **Provisioned Storage**: The amount of storage provisioned in GiB.

+- **Provisioned IOPS**: The amount of IOPS (IO / sec) provisioned.

+- **Provisioned Throughput MiBPS**: The amount of throughput provisioned in MiB / sec.

+- **Overflow Snapshot Usage**: Any amount of differential snapshot usage in GiB that does not fit within the provisioned storage capacity. See [provisioned v2 snapshots](#provisioned-v2-snapshots) for more information.

+- **Soft-Deleted Usage**: Used storage capacity in GiB for soft-deleted file shares. See [provisioned v2 soft-delete](#provisioned-v2-soft-delete) for more information.

+Consumption against the provisioned v2 billing meters are emitted hourly in terms of hourly units. For example, for a share with 1024 GiB provisioned, you should see:

+- 1,024 units against the **Provisioned Storage** meter for an individual hour.

+- 24,576 units against the **Provisioned Storage** meter if aggregated for a day.

+- A variable number of units if aggregated for a month depending on the number of days in the month:

+ - 28 day month (normal February): 688,128 units against the **Provisioned Storage** meter.

+ - 29 day month (leap year February): 712,704 units against the **Provisioned Storage** meter.

+ - 30 day month: 737,280 units against the **Provisioned Storage** meter.

+ - 31 day month: 761,856 units against the **Provisioned Storage** meter.

+## Provisioned v1 model

+The provisioned v1 method provides storage, IOPS and throughput in a fixed ratio to each other, similar to how storage is purchased in an on-premises storage solution. When you create a new provisioned v1 file share, you specify how much storage your share needs, and IOPS and throughput are computed values. The provisioned v1 model for Azure Files is only available for SSD file shares.

+The amount of storage you provision determines the guaranteed storage, IOPS, and throughput limits of your file share's usage. For example, if you provision a 2 TiB share and upload 2 TiB of data to your share, your share will be full and you will not be able to add more data unless you increase the size of your share, or delete some of the data. Credit-based IOPS bursting provides added flexibility around usage, on a best-effort basis, while credits remain.

+Unlike purchasing storage on-premises, provisioned v1 file shares can be dynamically scaled up or down as your needs change, however, you can only decrease the provisioned storage only after 24 hours have elapsed since your last storage increase. Storage, IOPS, and throughput changes are effective within a few minutes after a provisioning change.

+### Availability

+The provisioned v1 model is provided for SSD file shares in storage accounts with the *FileStorage* storage account kind:

+| Storage account kind | Storage account SKU | Type of file share available |

+|-|-|-|

+| FileStorage | Premium_LRS | SSD provisioned v1 file share with the Local (LRS) redundancy specified. |

+| FileStorage | Premium_ZRS | SSD provisioned v1 file share with the Zone (ZRS) redundancy specified. |

+SSD file shares using the provisioned v1 model are generally available in most Azure regions. See [Azure products by region](https://azure.microsoft.com/explore/global-infrastructure/products-by-region) for more information.

+### Provisioning detail

+When you create a provisioned v1 file share, you specify how much storage your share needs. Each GiB that you provision entitles you to more IOPS and throughput in a fixed ratio. File shares are limited based on the following attributes:

+| Storage provisioning unit | 1 GiB |

+| Minimum provisioned storage per file share | 100 GiB |

+| Maximum provisioned storage per file share | 100 TiB (102,400 GiB) |

+| Maximum provisioned storage per storage account | 100 TiB (102,400 GiB) |

+The amount of IOPS and throughput provisioned on the share are determined by the following formulas:

+| Item | Formula |

+|-|-|

+| Computed provisioned (baseline) IOPS | `MIN(3000 + 1 * ProvisionedStorageGiB, 102400)` |

+| Computed provisioned throughput (MiB / sec) | `100 + CEILING(0.04 * ProvisionedStorageGiB) + CEILING(0.06 * ProvisionedStorageGiB)` |

+Depending on your individual file share requirement, you may find that you require more IOPS or throughput than our provisioning formulas provide. In this case, you will need to provision more storage to get the required IOPS or throughput.

+### Provisioned v1 bursting

+Credit-based IOPS bursting provides added flexibility around IOPS usage. This flexibility is best used as a buffer against unanticipated IO-spikes. For established IO patterns, we recommend provisioning for IO peaks.

+Burst IOPS credits accumulate whenever traffic for your file share is below provisioned (baseline) IOPS. Whenever a file share's IOPS usage exceeds the provisioned IOPS and there are available burst IOPS credits, the file share can burst up to the maximum allowed burst IOPS limit. File shares can continue to burst as long as there are credits remaining, but this is based on the number of burst credits accrued. Each IO beyond provisioned IOPS consumes one credit. Once all credits are consumed, the share returns to the provisioned IOPS. IOPS against the file share don't have to do anything special to use bursting. Bursting operates on a best effort basis.

+Share credits have three states:

+- Accruing, when the file share is using less than the provisioned IOPS.

+- Declining, when the file share is using more than the provisioned IOPS and in the bursting mode.

+- Constant, when the files share is using exactly the provisioned IOPS and there are either no credits accrued or used.

+A new file share starts with the full number of credits in its burst bucket. Burst credits don't accrue if the share IOPS fall below the provisioned limit due to throttling by the server. The following formulas are used to determine the burst IOPS limit and the number of credits possible for a file share:

+| Item | Formula |

+|-|-|

+| Burst limit | `MIN(MAX(3 * ProvisionedStorageGiB, 10000), 102400)` |

+The following table illustrates a few examples of these formulas for the provisioned share sizes:

+Effective file share performance is subject to machine network limits, available network bandwidth, IO sizes, and parallelism, among many other factors. To achieve maximum benefit from parallelization, we recommend enabling [SMB Multichannel](files-smb-protocol.md#smb-multichannel) on SSD file shares. Refer to [SMB performance](smb-performance.md) and [performance troubleshooting guide](/troubleshoot/azure/azure-storage/files-troubleshoot-performance?toc=/azure/storage/files/toc.json) for some common performance issues and workarounds.

+### Provisioned v1 snapshots

+Azure Files supports snapshots, which are similar to volume shadow copies (VSS) on Windows File Server. For more information on share snapshots, see [Overview of snapshots for Azure Files](storage-snapshots-files.md).

+Snapshots are always differential from the live share and from each other. In the provisioned v1 billing model, the total differential size is billed against a usage meter, regardless of how much provisioned storage is unused. The used snapshot storage meter has a reduced price over the provisioned storage price.

+### Provisioned v1 soft-delete

+Deleted file shares in storage accounts with soft-delete enabled are billed based on the used storage capacity of the deleted share for the duration of the soft-delete period. The soft-deleted usage storage capacity is emitted against the used snapshot storage meter. For more information on soft-delete, see [How to enable soft delete on Azure file shares](storage-files-enable-soft-delete.md).

+### Provisioned v1 billing meters

+File shares provisioned using the provisioned v1 billing model are billed against the following two meters:

+- **Premium Provisioned**: The amount of storage provisioned in GiB.

+- **Premium Snapshots**: The amount of used snapshots and used soft-deleted capacity.

+Consumption against the provisioned v1 billing meters are emitted hourly in terms of monthly units. For example, for a share with 1024 GiB provisioned, you should see:

+- A variable number of units for an individual hour depending on the number of days in the month:

+ - 28 day month (normal February): 1.5238 units against the **Premium Provisioned** meter.

+ - 29 day month (leap year February): 1.4713 units against the **Premium Provisioned** meter.

+ - 30 day month: 1.4222 units against the **Premium Provisioned** meter.

+ - 31 day month: 1.3763 units against the **Premium Provisioned** meter.

+- A variable number of units if aggregated for a day depending on the number of days in the month:

+ - 28 day month (normal February): 36.5714 units against the **Premium Provisioned** meter.

+ - 29 day month (leap year February): 35.3103 units against the **Premium Provisioned** meter.

+ - 30 day month: 34.1333 units against the **Premium Provisioned** meter.

+ - 31 day month: 33.0323 units against the **Premium Provisioned** meter.

+- 1024 units against the **Premium Provisioned** meter if aggregated for a month.

+In the pay-as-you-go model, the amount you pay is determined by how much you use, rather than based on a provisioned amount. At a high level, you pay a cost for the amount of logical data stored, and you're also charged for transactions based on your usage of that data. Pay-as-you-go billing model can be difficult to plan for as part of a budgeting process, because the model is driven by end-user consumption. We therefore recommend using the [provisioned v2 model](#provisioned-v2-model) for new file share deployments. The pay-as-you-go model is only available for HDD file shares.

+### Availability

+The pay-as-you-go model is provided for HDD file shares in storage accounts with the *StorageV2* or *Storage* storage account kind:

+| Storage account kind | Storage account SKU | Type of file share available |

+|-|-|-|

+| StorageV2 or Storage | Standard_LRS | HDD pay-as-you-go file share with the Local (LRS) redundancy specified. |

+| StorageV2 or Storage | Standard_ZRS | HDD pay-as-you-go file share with the Zone (ZRS) redundancy specified. |

+| StorageV2 or Storage | Standard_GRS | HDD pay-as-you-go file share with the Geo (GRS) redundancy specified. |

+| StorageV2 or Storage | Standard_GZRS | HDD pay-as-you-go file share with the GeoZone (GZRS) redundancy specified. |

+HDD file shares using the pay-as-you-go model are generally available in all Azure regions.

+### Differences in access tiers

+When you create a HDD file share, you pick between the following access tiers: transaction optimized, hot, and cool. All three access tiers are stored on the exact same storage hardware. The main difference for these three access tiers is their data at-rest storage prices, which are lower in cooler tiers, and the transaction prices, which are higher in the cooler tiers. This means:

+- Transaction optimized, as the name implies, optimizes the price for high IOPS (transaction) workloads. Transaction optimized has the highest data at-rest storage price, but the lowest transaction prices.

+If you put an infrequently accessed workload in the transaction optimized access tier, you'll pay almost nothing for the few times in a month that you make transactions against your share. However, you'll pay a high amount for the data storage costs. If you moved this same share to the cool access tier, you'd still pay almost nothing for the transaction costs, simply because you're infrequently making transactions for this workload. However, the cool access tier has a much cheaper data storage price. Selecting the appropriate access tier for your use case allows you to considerably reduce your costs.

+Similarly, if you put a highly accessed workload in the cool access tier, you'll pay a lot more in transaction costs, but less for data storage costs. This can lead to a situation where the increased costs from the transaction prices increase outweigh the savings from the decreased data storage price, leading you to pay more money on cool than you would have on transaction optimized. For some usage levels, it's possible that the hot access tier will be the most cost efficient, and the cool access tier will be more expensive than transaction optimized.

+Your workload and activity level will determine the most cost efficient access tier for your pay-as-you-go file share. In practice, the best way to pick the most cost efficient access tier involves looking at the actual resource consumption of the share (data stored, write transactions, etc.). For pay-as-you-go file shares, we recommend starting in the transaction optimized tier during the initial migration into Azure Files, and then picking the correct access tier based on usage after the migration is complete. Transaction usage during migration is not typically indicative of normal transaction usage.

+> NFS 4.1 is only available for SSD file shares, which use a provisioned billing model. Transactions buckets don't affect billing for provisioned file shares.

+### Switching between access tiers

+Although you can change a pay-as-you-go file share between the three access tiers, the best practice to optimize costs after the initial migration is to pick the most cost optimal access tier to be in, and stay there unless your access pattern changes. This is because changing the access tier of a standard file share results in additional costs as follows:

+- Transactions: When you move a share from a hotter access tier to a cooler access tier, you'll incur the cooler access tier's write transaction charge for each file in the share. Moving a file share from a cooler access tier to a hotter access tier will incur the cooler access tier's read transaction charge for each file in the share.

+- Data retrieval: If you're moving from the cool access tier to hot or transaction optimized, you'll incur a data retrieval charge based on the size of data moved. Only the cool access tier has a data retrieval charge.

+The following table illustrates the cost breakdown of moving access tiers:

+| Access tier | Transaction optimized (destination) | Hot (destination) | Cool (destination) |

+Although there's no formal limit on how often you can change the access tier of your file share, your share will take time to transition based on the amount of data in your share. You can't change the access tier of the share while the file share is transitioning between access tiers. Changing the access tier of the file share doesn't impact regular file share access.

+### Choosing an access tier

+Regardless of how you migrate existing data into Azure Files, we recommend initially creating the file share in transaction optimized access tier due to the large number of transactions incurred during migration. After your migration is complete and you've operated for a few days or weeks with regular usage, you can plug your transaction counts into the [pricing calculator](https://azure.microsoft.com/pricing/calculator/) to figure out which access tier is best suited for your workload.

+Because pay-as-you-go file shares only show transaction information at the storage account level, using the storage metrics to estimate which access tier is cheaper at the file share level is an imperfect science. If possible, we recommend deploying only one file share in each storage account to ensure full visibility into billing.

+### Pay-as-you-go snapshots

+Azure Files supports snapshots, which are similar to volume shadow copies (VSS) on Windows File Server. For more information on share snapshots, see [Overview of snapshots for Azure Files](storage-snapshots-files.md).

+Snapshots are always differential from the live share and from each other. In the pay-as-you-go billing model,the total differential size is billed against the normal used storage meter. This means that you won't see a separate line item on your bill representing snapshots for your pay-as-you-go storage account. This also means that differential snapshot usage counts against reservations that are purchased for pay-as-you-go file shares.

+### Pay-as-you-go soft-delete

+Deleted file shares in storage accounts with soft-delete enabled are billed based on the used storage capacity of the deleted file share for the duration of the soft-delete period. The soft-deleted used storage capacity is emitted against the normal used storage meter. This means that you won't see a separate line item on your bill representing soft-deleted file shares for your pay-as-you-go storage account. This also means that soft-deleted file share usage counts against reservations that are purchased for pay-as-you-go file shares.

+### Pay-as-you-go billing meters

+File shares created using the pay-as-you-go billing model are billed against the following meters:

+- **Data Stored**: The used storage including the live shares, differential snapshots, and soft-deleted file shares in GiB.

+- **Metadata**: The size of the file system metadata associated with files and directories such as access control lists (ACLs) and other properties in GiB. This billing meter is only used for file shares in the hot or cool access tiers.

+- **Write Operations**: The number of write transaction buckets (1 bucket = 10,000 transactions).

+- **List Operations**: The number of list transaction buckets (1 bucket = 10,000 transactions).

+- **Read Operations**: The number of read transaction buckets (1 bucket = 10,000 transactions).

+- **Other Operations** / **Protocol Operations**: The number of other transaction buckets (1 bucket = 10,000 transactions).

+- **Data Retrieval**: The amount of data read from the file share in GiB. This meter is only used for file shares in the cool access tier.

+- **Geo-Replication Data Transfer**: If the file share has the Geo or GeoZone redundancy, the amount of data written to the file share replicated to the secondary region in GiB.

+Consumption against the **Data Stored** and **Metadata** billing meters are emitted hourly in terms of monthly units. For example, for a share with 1024 used GiB, you should see:

+- A variable number of units for an individual hour depending on the number of days in the month:

+ - 28 day month (normal February): 1.5238 units against the **Data Stored** meter.

+ - 29 day month (leap year February): 1.4713 units against the **Data Stored** meter.

+ - 30 day month: 1.4222 units against the **Data Stored** meter.

+ - 31 day month: 1.3763 units against the **Data Stored** meter.

+- A variable number of units if aggregated for a day depending on the number of days in the month:

+ - 28 day month (normal February): 36.5714 units against the **Data Stored** meter.

+ - 29 day month (leap year February): 35.3103 units against the **Data Stored** meter.

+ - 30 day month: 34.1333 units against the **Data Stored** meter.

+ - 31 day month: 33.0323 units against the **Data Stored** meter.

+- 1024 units against the **Data Stored** meter if aggregated for a month.

+Consumption against the other meters (ex. **Write Operations** or **Data Retrieval**) are emitted hourly, but since they aren't emitted in terms of a timeframe, don't have any special unit transformations to be aware of.

+## Provisioned/quota, logical size, and physical size

+Azure Files tracks three distinct quantities with respect to share capacity:

+- **Provisioned size or quota**: With both provisioned and pay-as-you-go file shares, you specify the maximum size that the file share is allowed to grow to. In provisioned file shares, this value is called the provisioned size. Whatever amount you provision is what you pay for, regardless of how much you actually use. In pay-as-you-go file shares, this value is called quota and doesn't directly affect your bill. Provisioned size is a required field for provisioned file shares. For pay-as-you-go file shares, if provisioned size isn't directly specified, the share will default to the maximum value supported by the storage account (100 TiB).

+- **Logical size**: The logical size of a file share or file relates to how big it is without considering how it's actually stored, where storage optimizations might be applied. The logical size of the file is how many KiB/MiB/GiB would be transferred over the wire if you copied it to a different location. In both provisioned and pay-as-you-go file shares, the total logical size of the file share is used for enforcement against provisioned size/quota. In pay-as-you-go file shares, the logical size is the quantity used for the data at-rest usage billing. Logical size is referred to as "size" in the Windows properties dialog for a file/folder and as "content length" by Azure Files metrics.

+- **Physical size**: The physical size of the file relates to the size of the file as encoded on disk. This might align with the file's logical size, or it might be smaller, depending on how the file has been written to by the operating system. A common reason for the logical size and physical size to be different is by using [sparse files](/windows/win32/fileio/sparse-files). The physical size of the files in the share is used for snapshot billing, although allocated ranges are shared between snapshots if they are unchanged (differential storage).

+- **Transaction costs for the value-added service.** Some value-added services have their own concept of transactions on top of the Azure Files billing model selected. These transactions will show up on your bill under the value-added service's charges; however, they relate directly to how you use the value-added service with your file share.

+- **Azure Files costs for using a value-added service.** Azure Files doesn't directly charge customers for adding value-added services, but as part of adding value to the Azure file share, the value-added service might increase the costs that you see on your Azure file share. This is easy to see with pay-as-you-go file shares, because of transaction charges. If the value-added service does transactions against the file share on your behalf, they will show up in your Azure Files transaction bill even though you didn't directly do those transactions yourself. This applies to provisioned file shares as well, although it might be less noticeable. Transactions against provisioned file shares from value-added services count against your provisioned IOPS numbers, meaning that value-added services might require provisioning more storage to have enough IOPS or throughput available for your workload.

+ - **Differential costs from Azure file share snapshots.** Azure Backup automates taking Azure file share snapshots on an administrator-defined schedule. Snapshots are always differential; however, the added cost added depends on the length of time snapshots are kept and the amount of churn on the file share during that time. This dictates how different the snapshot is from the live file share and therefore how much extra data is stored by Azure Files.

+ - **Transaction costs from restore operations.** Restore operations from the snapshot to the live share will cause transactions. For standard file shares, this means that reads from snapshots/writes from restores are billed as normal file share transactions. For provisioned file shares, these operations are counted against the provisioned IOPS for the file share.

+The main cost from Microsoft Defender for Storage is an extra set of transaction costs that the product levies on top of the transactions that are done against the Azure file share. Although these costs are based on the transactions incurred in Azure Files, they aren't part of the billing for Azure Files, but rather are part of the Microsoft Defender pricing. Microsoft Defender for Storage charges a transaction rate even on provisioned file shares, where Azure Files includes transactions as part of IOPS provisioning. The current transaction rate can be found on [Microsoft Defender for Cloud pricing page](https://azure.microsoft.com/pricing/details/defender-for-cloud/) under the *Microsoft Defender for Storage* table row.

+## Reservations

+Azure Files supports reservations (also referred to as *reserved instances*) for the provisioned v1 and pay-as-you-go models. Reservations enable you to achieve a discount on storage by pre-committing to storage utilization. You should consider purchasing reserved instances for any production workload, or dev/test workloads with consistent footprints. When you purchase a Reservation, you must specify the following dimensions:

+- **Capacity size**: Reservations can be for either 10 TiB or 100 TiB, with more significant discounts for purchasing a higher capacity Reservation. You can purchase multiple Reservations, including Reservations of different capacity sizes to meet your workload requirements. For example, if your production deployment has 120 TiB of file shares, you could purchase one 100 TiB Reservation and two 10 TiB Reservations to meet the total storage capacity requirements.

+- **Term**: You can purchase reservations for either a one-year or three-year term, with more significant discounts for purchasing a longer Reservation term.

+- **Tier**: The tier of Azure Files for the Reservation. Reservations currently are available for the premium (SSD), hot (HDD), and cool (HDD) tiers.

+- **Location**: The Azure region for the Reservation. Reservations are available in a subset of Azure regions.

+- **Redundancy**: The storage redundancy for the Reservation. Reservations are supported for all redundancies Azure Files supports, including LRS, ZRS, GRS, and GZRS.

+- **Billing frequency**: Indicates how often the account is billed for the Reservation. Options include *Monthly* or *Upfront*.

+Once you purchase a Reservation, it will automatically be consumed by your existing storage utilization. If you use more storage than you have reserved, you'll pay list price for the balance not covered by the Reservation. Transaction, bandwidth, data transfer, and metadata storage charges aren't included in the Reservation.

+There are differences in how Reservations work with Azure file share snapshots for pay-as-you-go and provisioned v1 file shares. If you're taking snapshots of pay-as-you-go file shares, then the snapshot differentials count against the Reservation and are billed as part of the normal used storage meter. However, if you're taking snapshots of provisioned v1 file shares, then the snapshots are billed using a separate meter and don't count against the Reservation.

+For more information on how to purchase Reservations, see [Optimize costs for Azure Files with Reservations](files-reserve-capacity.md).

+## See also

+| Watermarking | _{:::image type="icon" source="media/yes.svg" border="false":::} | _{:::image type="icon" source="media/yes.svg" border="false":::} | _{:::image type="icon" source="media/no.svg" border="false":::} | _{:::image type="icon" source="media/yes.svg" border="false":::} | _{:::image type="icon" source="media/yes.svg" border="false":::} | _{:::image type="icon" source="media/yes.svg" border="false":::} | _{:::image type="icon" source="media/yes.svg" border="false":::} |

+| Feature | Windows<br />(MSI) | macOS | iOS/<br />iPadOS | Android/<br />Chrome OS | Web browser |

+|--|:-:|:-:|:-:|:-:|:-:|

+| Screen capture protection | _{:::image type="icon" source="media/yes.svg" border="false":::} | _{:::image type="icon" source="media/yes.svg" border="false":::} | _{:::image type="icon" source="media/no.svg" border="false":::} | _{:::image type="icon" source="media/no.svg" border="false":::} | _{:::image type="icon" source="media/no.svg" border="false":::} |

+| Watermarking | _{:::image type="icon" source="media/yes.svg" border="false":::} | _{:::image type="icon" source="media/yes.svg" border="false":::} | _{:::image type="icon" source="media/yes.svg" border="false":::} | _{:::image type="icon" source="media/yes.svg" border="false":::} | _{:::image type="icon" source="media/yes.svg" border="false":::} |

+ Title: Use Microsoft OneDrive with a RemoteApp - Azure Virtual Desktop

+| `windows.cloud.microsoft` | TCP | 443 | Connection center | All |

+| `windows.cloud.microsoft` | TCP | 443 | Connection center | All |

+ - Android/Chrome OS (preview)

+## September 2024

+In September 2024, we made the following changes to the documentation:

+- Updated [Enable GPU acceleration for Azure Virtual Desktop](graphics-enable-gpu-acceleration.md) for the support of the High Efficiency Video Coding (HEVC), also known as H.265, which is in preview.

+- Updated [Use Microsoft OneDrive with a RemoteApp](onedrive-remoteapp.md), which is generally available.

+- Published a new article where you can learn [What's new in the Azure Virtual Desktop SxS Network Stack](whats-new-sxs.md).

+ Title: What is IP address management (IPAM) in Azure Virtual Network Manager?

+description: Learn about IP address management (IPAM) in Azure Virtual Network Manager and how it can help you manage IP addresses in your virtual networks.

+# What is IP address management (IPAM) in Azure Virtual Network Manager?

+In this article, you learn about the IP address management (IPAM) feature in Azure Virtual Network Manager and how it can help you manage IP addresses in your virtual networks. With Azure Virtual Network Manager's IP address management, you can create pools for IP address planning, automatically assign nonoverlapping classless inter-domain routing (CIDR) addresses to Azure resources, and prevent address space conflicts across on-premises and multicloud environments.

+## What is IP address management (IPAM)?

+In Azure Virtual Network Manager, IP address management (IPAM) helps you centrally manage IP addresses in your virtual networks using IP address pools. The following are some key features of IPAM in Azure Virtual Network

+## How does IPAM work in Azure Virtual Network Manager?

+The IPAM feature in Azure Virtual Network Manager works through the following key components:

+- Delegating IPAM permissions

+IPAM allows network administrators to plan and organize IP address usage by creating pools with address spaces and respective sizes. These pools act as containers for groups of CIDRs, enabling logical grouping for specific networking purposes. You can create a structured hierarchy of pools, dividing a larger pool into smaller, more manageable pools, aiding in more granular control and organization of your network's IP address space.

+There are two types of pools in IPAM:

+When it comes to allocation, you can assign Azure resources with CIDRs, such as virtual networks, to a specific pool. This helps in identifying which CIDRs are currently in use. There's also the option to allocate static CIDRs to a pool, useful for occupying CIDRs that are either not currently in use within Azure or are part of Azure resources not yet supported by the IPAM service. Allocated CIDRs are released back to the pool if the associated resource is removed or deleted, ensuring efficient utilization and management of the IP space.

+### Delegating permissions for IPAM

+With IPAM, you can delegate permission to other users to utilize the IP address pools, ensuring controlled access and management while democratizing pool allocation. These permissions allow users to see the pools they have access to, aiding in choosing the right pool for their needs.

+## Permission requirements for IPAM in Azure Virtual Network Manager

+When using IPAM, the **IPAM Pool User** role alone is sufficient for delegation. During the public preview, you also need to grant **Network Manager Read** access to ensure full discoverability of IP address pools and virtual networks across the Network Manager's scope. Without this role, users with only the **IPAM Pool User** role won't see available pools and virtual networks.

+- When virtual networks are associated with an IP address management pool, peering sync can show as out of sync, even though peering is functioning correctly.

+- When a virtual network is moved to a different subscription, the references in IPAM aren't updated, leading to inconsistent management status.

+- When multiple requests for the same virtual network are made, it can result in duplicate allocations entries.

+- When entering an IP address space, the address space entered must be a valid address range (valid starting address and valid size), else a failure is encountered when sending a request. Currently, the portal doesn't validate CIDR input prior to sending requests.

+Azure Virtual Network Manager allows you to manage IP addresses by creating and assigning IP address pools to your virtual networks. This article shows you how to create and assign IP address pools to your virtual networks with IP address management (IPAM) in Azure Virtual Network Manager.

+## Delegating permissions for IP address management (IPAM)

+> [What is IP address management (IPAM) in Azure Virtual Network Manager](./concept-ip-address-management.md)

+ * [Cloud Application Administrator role](/entra/identity/role-based-access-control/permissions-reference#cloud-application-administrator)

+ The Cloud Application Administrator role 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 **Cloud Application Administrator** role. For steps, see [Assign administrator and non-administrator roles to users with Microsoft Entra ID](/azure/active-directory-b2c/tenant-management-read-tenant-name).

+Locate and unzip the VPN client profile configuration package you generated and downloaded (listed in the [Prerequisites](#prerequisites)). Open the **AzureVPN** folder. In this folder, you'll see either the **azurevpnconfig_aad.xml** file or the **azurevpnconfig.xml** file, depending on whether your P2S configuration includes multiple authentication types. The .xml file contains the settings you use to configure the VPN client profile.

+For more information, see [Configure P2S VPN Gateway for Microsoft Entra ID authentication](point-to-site-entra-gateway.md).

+For information about working with certificates, see [Generate and export certificates](vpn-gateway-certificates-point-to-site.md).

+Unzip the file to view the folders. When you configure macOS native clients, you use the files in the **Generic** folder. The Generic folder is present if IKEv2 was configured on the gateway. If you don't see the Generic folder, check the following items, then generate the zip file again.

+* Verify that the gateway isn't configured with the Basic SKU. The VPN Gateway Basic SKU doesnΓÇÖt support IKEv2. You'll have to rebuild the gateway with the appropriate SKU and tunnel type if you want macOS clients to connect.

+You'll need both the root certificate and the child certificate installed on your Mac. The child certificate must be exported with the private key and must contain all certificates in the certification path.

+1. Copy the root certificate file (the .cer file) - to your Mac. Double-click the certificate. Depending on your operating system, the certificate will either automatically install, or you'll see the **Add Certificates** page.

+The client certificate (.pfx file) is used for authentication and is required. Typically, you can just click the client certificate to install. For more information about how to install a client certificate, see [Install a client certificate](point-to-site-how-to-vpn-client-install-azure-cert.md).

+### Verify certificates are installed

+Use the steps in the [Mac User Guide](https://support.apple.com/guide/mac-help/set-up-a-vpn-connection-on-mac-mchlp2963/mac) that are appropriate for your operating system version to add a VPN client profile configuration with the following settings.

+* Select **IKEv2** as the VPN type.

+* For **Display Name**, select a friendly name for the profile.

+* For both **Server Address** and **Remote ID**, use the value from the **VpnServer** tag in the **VpnSettings.xml** file.

+ :::image type="content" source="./media/point-to-site-vpn-client-cert-mac/vpn-server.png" alt-text="Screenshot to click Select." lightbox="./media/point-to-site-vpn-client-cert-mac/vpn-server.png":::

+* For **Authentication** settings, select **Certificate**.

+* For the **Certificate**, choose the child certificate you want to use for authentication. If you have multiple certificates, you can select **Show Certificate** to see more information about each certificate.

+* For **Local ID**, type the name of the child certificate that you selected.

+Once you finished configuring the VPN client profile, save the profile.

+The steps to connect are specific to the macOS operating system version. Refer to the [Mac User Guide](https://support.apple.com/guide/mac-help/set-up-a-vpn-connection-on-mac-mchlp2963/mac). Select the operating system version that you're using and follow the steps to connect.

+Once the connection has been established, the status shows as **Connected**. The IP address is allocated from the VPN client address pool.