+ Title: Capacity metrics - Azure API Management | Microsoft Docs

+description: This article explains the capacity metrics in Azure API Management and how to make informed decisions about whether to scale an instance.

+API Management provides [Azure Monitor metrics](api-management-howto-use-azure-monitor.md#view-metrics-of-your-apis) to detect use of system capacity, helping you troubleshoot gateway problems and make informed decisions whether to [scale or upgrade](upgrade-and-scale.md) an API Management instance to accommodate more load.

+This article explains the capacity metrics and how they behave, shows how to access capacity metrics in the Azure portal, and suggests when to consider scaling or upgrading your API Management instance.

+> This article introduces how to monitor and scale your Azure API Management instance based on capacity metrics. However, when an instance *reaches* its capacity, it won't throttle to prevent overload. Instead, it will act like an overloaded web server: increased latency, dropped connections, and timeout errors. API clients should be ready to handle these issues as they do with other external services, for example by using retry policies.

+To follow the steps in this article, you must have an API Management instance in one of the tiers that supports capacity metrics. For more information, see [Create an Azure API Management instance](get-started-create-service-instance.md).

+## Available capacity metrics

+Different capacity metrics are available in the [v2 service tiers](v2-service-tiers-overview.md) and classic tiers.

+#### [v2 tiers](#tab/v2-tiers)

+In the v2 tiers, the following metrics are available:

+* **CPU Percentage of Gateway** - The percentage of CPU capacity used by the gateway units.

+* **Memory Percentage of Gateway** - The percentage of memory capacity used by the gateway units.

+Available aggregations for these metrics are as follows.

+* **Avg** - Average percentage of capacity used across gateway processes in every [unit](upgrade-and-scale.md) of an API Management instance.

+* **Max** - Percentage of capacity in gateway process with the greatest consumption.

+#### [Classic tiers](#tab/classic)

+In the Developer, Basic, Standard, and Premium tiers, the **Capacity** metric is available for making decisions about scaling or upgrading an API Management instance. Its construction is complex and imposes certain behavior.

+Available aggregations for this metric are as follows.

+* **Avg** - Average percentage of capacity used across gateway processes in every [unit](upgrade-and-scale.md) of an API Management instance.

+* **Max** - Percentage of capacity in gateway process with the greatest consumption.

+### What the Capacity metric indicates

+**Capacity** is an indicator of load on an API Management instance. It reflects usage of resources (CPU, memory) and network queue lengths.

+In real life capacity metrics can be impacted by many variables, for example:

+The more complex operations on the requests are, the higher the capacity consumption is. For example, complex transformation policies consume much more CPU than a simple request forwarding. Slow backend service responses increase it, too.

+> Capacity metrics are not direct measures of the number of requests being processed.

+Capacity metrics can also spike intermittently or be greater than zero even if no requests are being processed. It happens because of system- or platform-specific actions and should not be taken into consideration when deciding whether to scale an instance.

+Although capacity metrics are designed to surface problems with your API Management instance, there are cases when problems won't be reflected in changes in these metrics. Additionally, low capacity metrics don't necessarily mean that your API Management instance isn't experiencing any problems.

+## Use the Azure portal to examine capacity metrics

+Access metrics in the portal to understand how much capacity is used over time.

+#### [v2 tiers](#tab/v2-tiers)

+1. Navigate to your API Management instance in the [Azure portal](https://portal.azure.com/).

+1. In the left menu, under **Monitoring**, select **Metrics**.

+1. Select the **CPU Percentage of Gateway** or **Memory Percentage of Gateway** metric from the available metrics. Choose the default **Avg** aggregation or select the **Max** aggregation to see the peak usage.

+1. Pick a desired timeframe from the top bar of the section.

+> [!IMPORTANT]

+> Currently, the **Capacity** metric also appears in the portal for instances in v2 tiers. However, it's not supported for use in the v2 tiers and shows a value of 0.

+> [!NOTE]

+> You can set a [metric alert](api-management-howto-use-azure-monitor.md#set-up-an-alert-rule) to let you know when something unexpected is happening. For example, get notifications when your API Management instance has exceeded its expected peak CPU or Memory usage for more than 20 minutes.

+

+#### [Classic tiers](#tab/classic)

+1. In the left menu, under **Monitoring**, select **Metrics**.

+1. Select the **Capacity** metric from the available metrics and leave the default **Avg** aggregation.

+1. To split the metric by location, from the section at the top, select **Apply splitting** and then select **Location**.

+1. Pick a desired timeframe from the top bar of the section.

+> [!IMPORTANT]

+> Currently, the **CPU Percentage of Gateway** and **Memory Consumption of Gateway** metrics also appear in the portal for instances in classic tiers. However, they're not supported for use in classic tiers and show a value of 0.

+> [!NOTE]

+> * You can set a [metric alert](api-management-howto-use-azure-monitor.md#set-up-an-alert-rule) to let you know when something unexpected is happening. For example, get notifications when your API Management instance has exceeded its expected peak capacity for more than 20 minutes.

+> * You can use Azure Monitor [autoscaling](api-management-howto-autoscale.md) to automatically add an Azure API Management unit. Scaling operation can take around 30 minutes, so you should plan your rules accordingly.

+> * In multi-region deployments, only scaling the primary location is allowed.

+Use capacity metrics for making decisions whether to scale an API Management instance to accommodate more load. The following are general considerations:

+## Related content

+- [Plan and manage costs for API Management](plan-manage-costs.md)

+API Management emits [metrics](../azure-monitor/essentials/data-platform-metrics.md) every minute, giving you near real-time visibility into the state and health of your APIs. The following are the most frequently used metrics. For a list of all available metrics, see [supported metrics](../azure-monitor/essentials/metrics-supported.md#microsoftapimanagementservice).

+* **Capacity** - helps you make decisions about upgrading/downgrading your API Management services. The metric is emitted per minute and reflects the estimated gateway capacity at the time of reporting. The metric ranges from 0-100 calculated based on gateway resources such as CPU and memory utilization and other factors.

+ > [!TIP]

+ > In the [v2 service tiers](v2-service-tiers-overview.md), API Management replaced the capacity metric with separate CPU and memory utilization metrics. These metrics can also be used for scaling decisions and troubleshooting. [Learn more](api-management-capacity.md)

+> The following metrics have been retired: Total Gateway Requests, Successful Gateway Requests, Unauthorized Gateway Requests, Failed Gateway Requests, Other Gateway Requests. Please migrate to the Requests metric which provides equivalent functionality.

+* Capacity metric - replaced by CPU Percentage of Gateway and Memory Percentage of Gateway metrics

+ <content type="content type string" validate-as="json | xml | soap" schema-id="schema id" schema-ref="#/local/reference/path" action="ignore | prevent | detect" allow-additional-properties="true | false" case-insensitive-property-names="true | false"/>

+| case-insensitive-property-names | Boolean. For a JSON schema, specifies whether to compare property names of JSON objects without regard to case. <br> - `true`: compare property names case insensitively. <br> - `false`: compare property names case sensitively. | No | false |

+ * **Asymmetric** - The following encryption algortithms are supported: PS256, RS256, RS512, ES256.

+#customer intent: As a developer, I want to learn how to deploy a Spring Boot web app to Azure App Service and connect to an Cosmos DB instance with the MongoDB API.

+zone_pivot_groups: app-service-portal-azd

+In this tutorial, you learn how to build, configure, and deploy a secure Spring Boot application in Azure App Service that connects to a MongoDB database in Azure (actually, a Cosmos DB database with MongoDB API). When you're finished, you'll have a Java SE application running on Azure App Service on Linux.

+**To complete this tutorial, you'll need:**

+* An Azure account with an active subscription. If you don't have an Azure account, you [can create one for free](https://azure.microsoft.com/free/java/).

+* A GitHub account. you can also [get one for free](https://github.com/join).

+* Knowledge of Java with Spring Framework development.

+* **(Optional)** To try GitHub Copilot, a [GitHub Copilot account](https://docs.github.com/copilot/using-github-copilot/using-github-copilot-code-suggestions-in-your-editor). A 30-day free trial is available.

+* An Azure account with an active subscription. If you don't have an Azure account, you [can create one for free](https://azure.microsoft.com/free/java).

+* [Azure Developer CLI](/azure/developer/azure-developer-cli/install-azd) installed. You can follow the steps with the [Azure Cloud Shell](https://shell.azure.com) because it already has Azure Developer CLI installed.

+* Knowledge of Java with Spring Framework development.

+* **(Optional)** To try GitHub Copilot, a [GitHub Copilot account](https://docs.github.com/copilot/using-github-copilot/using-github-copilot-code-suggestions-in-your-editor). A 30-day free trial is available.

+## Skip to the end

+You can quickly deploy the sample app in this tutorial and see it running in Azure. Just run the following commands in the [Azure Cloud Shell](https://shell.azure.com), and follow the prompt:

+mkdir msdocs-spring-boot-mongodb-sample-app

+cd msdocs-spring-boot-mongodb-sample-app

+azd init --template msdocs-spring-boot-mongodb-sample-app

+azd up

+## 1. Run the sample

+First, you set up a sample data-driven app as a starting point. For your convenience, the [sample repository](https://github.com/Azure-Samples/msdocs-spring-boot-mongodb-sample-app), includes a [dev container](https://docs.github.com/codespaces/setting-up-your-project-for-codespaces/adding-a-dev-container-configuration/introduction-to-dev-containers) configuration. The dev container has everything you need to develop an application, including the MongoDB database, cache, and all environment variables needed by the sample application. The dev container can run in a [GitHub codespace](https://docs.github.com/en/codespaces/overview), which means you can run the sample on any computer with a web browser.

+ :::column span="2":::

+ **Step 1:** In a new browser window:

+ 1. Sign in to your GitHub account.

+ 1. Navigate to [https://github.com/Azure-Samples/msdocs-spring-boot-mongodb-sample-app/fork](https://github.com/Azure-Samples/msdocs-spring-boot-mongodb-sample-app/fork).

+ 1. Unselect **Copy the main branch only**. You want all the branches.

+ 1. Select **Create fork**.

+ :::column-end:::

+ :::column:::

+ :::image type="content" source="./media/tutorial-java-spring-cosmosdb/azure-portal-run-sample-application-1.png" alt-text="A screenshot showing how to create a fork of the sample GitHub repository." lightbox="./media/tutorial-java-spring-cosmosdb/azure-portal-run-sample-application-1.png":::

+ :::column-end:::

+ :::column span="2":::

+ **Step 2:** In the GitHub fork:

+ 1. Select **main** > **starter-no-infra** for the starter branch. This branch contains just the sample project and no Azure-related files or configuration.

+ 1. Select **Code** > **Create codespace on starter-no-infra**.

+ The codespace takes a few minutes to set up.

+ :::column-end:::

+ :::column:::

+ :::image type="content" source="./media/tutorial-java-spring-cosmosdb/azure-portal-run-sample-application-2.png" alt-text="A screenshot showing how to create a codespace in GitHub." lightbox="./media/tutorial-java-spring-cosmosdb/azure-portal-run-sample-application-2.png":::

+ :::column-end:::

+ :::column span="2":::

+ **Step 3:** In the codespace terminal:

+ 1. Run `mvn package spring-boot:run`.

+ 1. When you see the notification `Your application running on port 8080 is available.`, select **Open in Browser**.

+ You should see the sample application in a new browser tab.

+ To stop the Jetty server, type `Ctrl`+`C`.

+ :::column-end:::

+ :::column:::

+ :::image type="content" source="./media/tutorial-java-spring-cosmosdb/azure-portal-run-sample-application-3.png" alt-text="A screenshot showing how to run the sample application inside the GitHub codespace." lightbox="./media/tutorial-java-spring-cosmosdb/azure-portal-run-sample-application-3.png":::

+ :::column-end:::

+> [!TIP]

+> You can ask [GitHub Copilot](https://docs.github.com/copilot/using-github-copilot/using-github-copilot-code-suggestions-in-your-editor) about this repository. For example:

+>

+> * *@workspace What does this project do?*

+> * *@workspace How does the app connect to the database?*

+> * *@workspace What does the .devcontainer folder do?*

+Having issues? Check the [Troubleshooting section](#troubleshooting).

+## 2. Create App Service and Cosmos DB

+First, you create the Azure resources. The steps used in this tutorial create a set of secure-by-default resources that include App Service and Azure Cosmos DB. For the creation process, you specify:

+* The **Name** for the web app. It's used as part of the DNS name for your app in the form of `https://<app-name>-<hash>.<region>.azurewebsites.net`.

+* The **Region** to run the app physically in the world. It's also used as part of the DNS name for your app.

+* The **Runtime stack** for the app. It's where you select the version of Java to use for your app.

+* The **Hosting plan** for the app. It's the pricing tier that includes the set of features and scaling capacity for your app.

+* The **Resource Group** for the app. A resource group lets you group (in a logical container) all the Azure resources needed for the application.

+Sign in to the [Azure portal](https://portal.azure.com/) and follow these steps to create your Azure App Service resources.

+ :::column span="2":::

+ **Step 1:** In the Azure portal:

+ 1. Enter "web app database" in the search bar at the top of the Azure portal.

+ 1. Select the item labeled **Web App + Database** under the **Marketplace** heading.

+ You can also navigate to the [creation wizard](https://portal.azure.com/?feature.customportal=false#create/Microsoft.AppServiceWebAppDatabaseV3) directly.

+ :::column-end:::

+ :::column:::

+ :::image type="content" source="./media/tutorial-java-spring-cosmosdb/azure-portal-create-app-cosmosdb-1.png" alt-text="A screenshot showing how to use the search box in the top tool bar to find the Web App + Database creation wizard." lightbox="./media/tutorial-java-spring-cosmosdb/azure-portal-create-app-cosmosdb-1.png":::

+ :::column-end:::

+ :::column span="2":::

+ **Step 2:** In the **Create Web App + Database** page, fill out the form as follows.

+ 1. *Resource Group*: Select **Create new** and use a name of **msdocs-spring-cosmosdb-tutorial**.

+ 1. *Region*: Any Azure region near you.

+ 1. *Name*: **msdocs-spring-cosmosdb-XYZ** where *XYZ* is any three random characters. This name must be unique across Azure.

+ 1. *Runtime stack*: **Java 21**.

+ 1. *Java web server stack*: **Java SE (Embedded Web Server)**.

+ 1. *Engine*: **Cosmos DB API for MongoDB**. Cosmos DB is a fully managed NoSQL, relational, and vector database as a service on Azure.

+ 1. *Hosting plan*: **Basic**. When you're ready, you can [scale up](manage-scale-up.md) to a production pricing tier later.

+ 1. Select **Review + create**.

+ 1. After validation completes, select **Create**.

+ :::column-end:::

+ :::column:::

+ :::image type="content" source="./media/tutorial-java-spring-cosmosdb/azure-portal-create-app-cosmosdb-2.png" alt-text="A screenshot showing how to configure a new app and database in the Web App + Database wizard." lightbox="./media/tutorial-java-spring-cosmosdb/azure-portal-create-app-cosmosdb-2.png":::

+ :::column-end:::

+ :::column span="2":::

+ **Step 3:** The deployment takes a few minutes to complete. Once deployment completes, select the **Go to resource** button. You're taken directly to the App Service app, but the following resources are created:

+ - **Resource group**: The container for all the created resources.

+ - **App Service plan**: Defines the compute resources for App Service. A Linux plan in the *Basic* tier is created.

+ - **App Service**: Represents your app and runs in the App Service plan.

+ - **Virtual network**: Integrated with the App Service app and isolates back-end network traffic.

+ - **Azure Cosmos DB**: Accessible only from behind its private endpoint. A database is created for you on the database account.

+ - **Private DNS zones**: Enable DNS resolution of the database server and the Redis cache in the virtual network.

+ :::column-end:::

+ :::column:::

+ :::image type="content" source="./media/tutorial-java-spring-cosmosdb/azure-portal-create-app-cosmosdb-3.png" alt-text="A screenshot showing the deployment process completed." lightbox="./media/tutorial-java-spring-cosmosdb/azure-portal-create-app-cosmosdb-3.png":::

+ :::column-end:::

+Having issues? Check the [Troubleshooting section](#troubleshooting).

+## 3. Secure connection secrets

+The creation wizard generated the connectivity string for you already as [app settings](configure-common.md#configure-app-settings). However, it's In this step, you learn where to find the app settings, and how you can create your own.

+App settings are one way to keep connection secrets out of your code repository. When you're ready to move your secrets to a more secure location, you can use [Key Vault references](app-service-key-vault-references.md) instead.

+ :::column span="2":::

+ **Step 1:** In the App Service page,

+ 1. In the left menu, select **Settings > Environment variables**.

+ 1. Next to **AZURE_COSMOS_CONNECTIONSTRING**, select **Show value**.

+ This connection string lets you connect to the Cosmos DB database secured behind a private endpoint. However, the secret is saved directly in the App Service app, which isn't the best. You'll change this.

+ :::column-end:::

+ :::column:::

+ :::image type="content" source="./media/tutorial-java-spring-cosmosdb/azure-portal-secure-connection-secrets-1.png" alt-text="A screenshot showing how to see the value of an app setting." lightbox="./media/tutorial-java-spring-cosmosdb/azure-portal-secure-connection-secrets-1.png":::

+ :::column-end:::

+ :::column span="2":::

+ **Step 2:** Create a key vault for secure management of secrets.

+ 1. In the top search bar, type "*key vault*", then select **Marketplace** > **Key Vault**.

+ 1. In **Resource Group**, select **msdocs-spring-cosmosdb-tutorial**.

+ 1. In **Key vault name**, type a name that consists of only letters and numbers.

+ 1. In **Region**, set it to the sample location as the resource group.

+ :::column-end:::

+ :::column:::

+ :::image type="content" source="./media/tutorial-java-spring-cosmosdb/azure-portal-secure-connection-secrets-2.png" alt-text="A screenshot showing how to create a key vault." lightbox="./media/tutorial-java-spring-cosmosdb/azure-portal-secure-connection-secrets-2.png":::

+ :::column-end:::

+ :::column span="2":::

+ **Step 3:**

+ 1. Select the **Networking** tab.

+ 1. Unselect **Enable public access**.

+ 1. Select **Create a private endpoint**.

+ 1. In **Resource Group**, select **msdocs-spring-cosmosdb-tutorial**.

+ 1. In **Key vault name**, type a name that consists of only letters and numbers.

+ 1. In **Region**, set it to the sample location as the resource group.

+ 1. In the dialog, in **Location**, select the same location as your App Service app.

+ 1. In **Resource Group**, select **msdocs-spring-cosmosdb-tutorial**.

+ 1. In **Name**, type **msdocs-spring-cosmosdb-XYZVvaultEndpoint**.

+ 1. In **Virtual network**, select **msdocs-spring-cosmosdb-XYZVnet**.

+ 1. In **Subnet**, **msdocs-spring-cosmosdb-XYZSubnet**.

+ 1. Select **OK**.

+ 1. Select **Review + create**, then select **Create**. Wait for the key vault deployment to finish. You should see "Your deployment is complete."

+ :::column-end:::

+ :::column:::

+ :::image type="content" source="./media/tutorial-java-spring-cosmosdb/azure-portal-secure-connection-secrets-3.png" alt-text="A screenshot showing how secure a key vault with a private endpoint." lightbox="./media/tutorial-java-spring-cosmosdb/azure-portal-secure-connection-secrets-3.png":::

+ :::column-end:::

+ :::column span="2":::

+ **Step 4:**

+ 1. In the top search bar, type *msdocs-spring-cosmosdb*, then the App Service resource called **msdocs-spring-cosmosdb-XYZ**.

+ 1. In the App Service page, in the left menu, select **Settings > Service Connector. There's already a connector, which the app creation wizard created for you.

+ 1. Select checkbox next to the connector, then select **Edit**.

+ 1. In the **Basics** tab, set **Client type** to **SpringBoot**. This option creates the Spring Boot specific environment variables for you.

+ 1. Select the **Authentication** tab.

+ 1. Select Store Secret in Key Vault.

+ 1. Under **Key Vault Connection**, select **Create new**.

+ A **Create connection** dialog is opened on top of the edit dialog.

+ :::column-end:::

+ :::column:::

+ :::image type="content" source="./media/tutorial-java-spring-cosmosdb/azure-portal-secure-connection-secrets-4.png" alt-text="A screenshot showing how to edit a service connector with a key vault connection." lightbox="./media/tutorial-java-spring-cosmosdb/azure-portal-secure-connection-secrets-4.png":::

+ :::column-end:::

+ :::column span="2":::

+ **Step 5:** In the **Create connection** dialog for the Key Vault connection:

+ 1. In **Key Vault**, select the key vault you created earlier.

+ 1. Select **Review + Create**. You should see that **System assigned managed identity** is set to **Selected**.

+ 1. When validation completes, select **Create**.

+ :::column-end:::

+ :::column:::

+ :::image type="content" source="./media/tutorial-java-spring-cosmosdb/azure-portal-secure-connection-secrets-5.png" alt-text="A screenshot showing how to configure a key vault service connector." lightbox="./media/tutorial-java-spring-cosmosdb/azure-portal-secure-connection-secrets-5.png":::

+ :::column-end:::

+ :::column span="2":::

+ **Step 6:** You're back in the edit dialog for **defaultConnector**.

+ 1. In the **Authentication** tab, wait for the key vault connector to be created. When it's finished, the Key Vault Connection dropdown automatically selects it.

+ 1. Select **Next: Networking**.

+ 1. Select **Configure firewall rules to enable access to target service**. If you see the message, "No Private Endpoint on the target service," ignore it. The app creation wizard already secured the Cosmos DB database with a private endpoint.

+ 1. Select **Save**. Wait until the **Update succeeded** notification appears.

+ :::column-end:::

+ :::column:::

+ :::image type="content" source="./media/tutorial-java-spring-cosmosdb/azure-portal-secure-connection-secrets-6.png" alt-text="A screenshot showing the key vault connection selected in the defaultConnector." lightbox="./media/tutorial-java-spring-cosmosdb/azure-portal-secure-connection-secrets-6.png":::

+ :::column-end:::

+ :::column span="2":::

+ **Step 7:** To verify that you secured the secrets:

+ 1. From the left menu, select **Environment variables** again.

+ 1. Make sure that the app setting **spring.data.mongodb.uri** exists. The default connector generated it for you, and your Spring Boot application already uses the variable.

+ 1. Next to the app setting, select **Show value**. The value should be `@Microsoft.KeyValut(...)`, which means that it's a [key vault reference](app-service-key-vault-references.md) because the secret is now managed in the key vault.

+ :::column-end:::

+ :::column:::

+ :::image type="content" source="./media/tutorial-java-spring-cosmosdb/azure-portal-secure-connection-secrets-7.png" alt-text="A screenshot showing how to see the value of the Spring Boot environment variable in Azure." lightbox="./media/tutorial-java-spring-cosmosdb/azure-portal-secure-connection-secrets-7.png":::

+ :::column-end:::

+Having issues? Check the [Troubleshooting section](#troubleshooting).

+## 5. Deploy sample code

+In this step, you configure GitHub deployment using GitHub Actions. It's just one of many ways to deploy to App Service, but also a great way to have continuous integration in your deployment process. By default, every `git push` to your GitHub repository kicks off the build and deploy action.

+Like the Tomcat convention, if you want to deploy to the root context of Tomcat, name your built artifact *ROOT.war*.

+ :::column span="2":::

+ **Step 1:** In the left menu, select **Deployment** > **Deployment Center**.

+ :::column-end:::

+ :::column:::

+ :::image type="content" source="./media/tutorial-java-spring-cosmosdb/azure-portal-deploy-sample-code-1.png" alt-text="A screenshot showing how to open the deployment center in App Service." lightbox="./media/tutorial-java-spring-cosmosdb/azure-portal-deploy-sample-code-1.png":::

+ :::column-end:::

+ :::column span="2":::

+ **Step 2:** In the Deployment Center page:

+ 1. In **Source**, select **GitHub**. By default, **GitHub Actions** is selected as the build provider.

+ 1. Sign in to your GitHub account and follow the prompt to authorize Azure.

+ 1. In **Organization**, select your account.

+ 1. In **Repository**, select **msdocs-spring-boot-mongodb-sample-app**.

+ 1. In **Branch**, select **starter-no-infra**. This is the same branch that you worked in with your sample app, without any Azure-related files or configuration.

+ 1. For **Authentication type**, select **User-assigned identity**.

+ 1. In the top menu, select **Save**. App Service commits a workflow file into the chosen GitHub repository, in the `.github/workflows` directory.

+ By default, the deployment center [creates a user-assigned identity](#i-dont-have-permissions-to-create-a-user-assigned-identity) for the workflow to authenticate using Microsoft Entra (OIDC authentication). For alternative authentication options, see [Deploy to App Service using GitHub Actions](deploy-github-actions.md).

+ :::column-end:::

+ :::column:::

+ :::image type="content" source="./media/tutorial-java-spring-cosmosdb/azure-portal-deploy-sample-code-2.png" alt-text="A screenshot showing how to configure CI/CD using GitHub Actions." lightbox="./media/tutorial-java-spring-cosmosdb/azure-portal-deploy-sample-code-2.png":::

+ :::column-end:::

+ :::column span="3":::

+ **Step 3:**

+ 1. Select the **Logs** tab. See that a new deployment already ran, but the status is **Failed**.

+ 1. Select **Build/Deploy Logs**.

+ A browser tab opens to the **Actions** tab of your forked repository in GitHub. In **Annotations**, you see the error `The string 'java21' is not valid SeVer notation for a Java version`. If you want, select the failed **build** step in the page to get more information.

+ :::column-end:::

+ :::column:::

+ :::image type="content" source="./media/tutorial-java-spring-cosmosdb/azure-portal-deploy-sample-code-3.png" alt-text="A screenshot showing an error in the deployment center's Logs page." lightbox="./media/tutorial-java-spring-cosmosdb/azure-portal-deploy-sample-code-3.png":::

+ :::column-end:::

+ :::column span="2":::

+ **Step 4:** The error shows that something went wrong during the GitHub workflow. To fix it, pull the latest changes into your codespace first. Back in the GitHub codespace of your sample fork, run `git pull origin starter-no-infra`.

+ This pulls the newly committed workflow file into your codespace.

+ :::column-end:::

+ :::column:::

+ :::image type="content" source="./media/tutorial-java-spring-cosmosdb/azure-portal-deploy-sample-code-4.png" alt-text="A screenshot showing git pull inside a GitHub codespace." lightbox="./media/tutorial-java-spring-cosmosdb/azure-portal-deploy-sample-code-4.png":::

+ :::column-end:::

+ :::column span="2":::

+ **Step 5 (Option 1: with GitHub Copilot):**

+ 1. Start a new chat session by selecting the **Chat** view, then selecting **+**.

+ 1. Ask, "*@workspace why do i get the error in GitHub actions: The string 'java21' is not valid SemVer notation for a Java version.*" Copilot might give you an explanation and even give you the link to the workflow file that you need to fix.

+ 1. Open *.github/workflows/starter-no-infra_msdocs-spring-cosmosdb-123.yaml* in the explorer and make the suggested fix.

+ GitHub Copilot doesn't give you the same response every time, you might need to ask more questions to fine-tune its response. For tips, see [What can I do with GitHub Copilot in my codespace?](#what-can-i-do-with-github-copilot-in-my-codespace).

+ :::column-end:::

+ :::column:::

+ :::image type="content" source="media/tutorial-java-spring-cosmosdb/github-copilot-1.png" alt-text="A screenshot showing how to ask a question in a new GitHub Copilot chat session." lightbox="media/tutorial-java-spring-cosmosdb/github-copilot-1.png":::

+ :::column-end:::

+ :::column span="2":::

+ **Step 5 (Option 2: without GitHub Copilot):**

+ 1. Open *.github/workflows/starter-no-infra_msdocs-spring-cosmosdb-123.yaml* in the explorer and find the `setup-java@v4` action.

+ 1. Change the value of `java-version` to `'21'`.

+ :::column-end:::

+ :::column:::

+ :::image type="content" source="./media/tutorial-java-spring-cosmosdb/azure-portal-deploy-sample-code-5.png" alt-text="A screenshot showing a GitHub codespace and the autogenerated workflow file opened." lightbox="./media/tutorial-java-spring-cosmosdb/azure-portal-deploy-sample-code-5.png":::

+ :::column-end:::

+ :::column span="2":::

+ **Step 6:**

+ 1. Select the **Source Control** extension.

+ 1. In the textbox, type a commit message like `Fix error in java-version`. Or, select :::image type="icon" source="media/quickstart-dotnetcore/github-copilot-in-editor.png" border="false"::: and let GitHub Copilot generate a commit message for you.

+ 1. Select **Commit**, then confirm with **Yes**.

+ 1. Select **Sync changes 1**, then confirm with **OK**.

+ :::column-end:::

+ :::column:::

+ :::image type="content" source="./media/tutorial-java-spring-cosmosdb/azure-portal-deploy-sample-code-6.png" alt-text="A screenshot showing the changes being committed and pushed to GitHub." lightbox="./media/tutorial-java-spring-cosmosdb/azure-portal-deploy-sample-code-6.png":::

+ :::column-end:::

+ :::column span="2":::

+ **Step 7:**

+ Back in the Deployment Center page in the Azure portal:

+ 1. Under the **Logs** tab, select **Refresh**. A new deployment run is already started from your committed changes.

+ 1. In the log item for the deployment run, select the **Build/Deploy Logs** entry with the latest timestamp.

+ :::column-end:::

+ :::column:::

+ :::image type="content" source="./media/tutorial-java-spring-cosmosdb/azure-portal-deploy-sample-code-7.png" alt-text="A screenshot showing a successful deployment in the deployment center's Logs page." lightbox="./media/tutorial-java-spring-cosmosdb/azure-portal-deploy-sample-code-7.png":::

+ :::column-end:::

+ :::column span="2":::

+ **Step 8:** You're taken to your GitHub repository and see that the GitHub action is running. The workflow file defines two separate stages, build and deploy. Wait for the GitHub run to show a status of **Complete**.

+ :::column-end:::

+ :::column:::

+ :::image type="content" source="./media/tutorial-java-spring-cosmosdb/azure-portal-deploy-sample-code-8.png" alt-text="A screenshot showing a successful GitHub run." lightbox="./media/tutorial-java-spring-cosmosdb/azure-portal-deploy-sample-code-8.png":::

+ :::column-end:::

+Having issues? Check the [Troubleshooting section](#troubleshooting).

+## 6. Browse to the app

+ :::column span="2":::

+ **Step 1:** In the App Service page:

+ 1. From the left menu, select **Overview**.

+ 1. Select the URL of your app. You can also navigate directly to `https://<app-name>.azurewebsites.net`.

+ :::column-end:::

+ :::column:::

+ :::image type="content" source="./media/tutorial-java-spring-cosmosdb/azure-portal-browse-app-1.png" alt-text="A screenshot showing how to launch an App Service from the Azure portal." lightbox="./media/tutorial-java-spring-cosmosdb/azure-portal-browse-app-1.png":::

+ :::column-end:::

+ :::column span="2":::

+ **Step 2:** Add a few tasks to the list.

+ Congratulations, you're running a web app in Azure App Service, with secure connectivity to Azure Cosmos DB.

+ :::column-end:::

+ :::column:::

+ :::image type="content" source="./media/tutorial-java-spring-cosmosdb/azure-portal-browse-app-2.png" alt-text="A screenshot of the Spring Boot web app with Cosmos DB running in Azure." lightbox="./media/tutorial-java-spring-cosmosdb/azure-portal-browse-app-2.png":::

+ :::column-end:::

+Having issues? Check the [Troubleshooting section](#troubleshooting).

+## 7. Stream diagnostic logs

+Azure App Service captures all messages output to the console to help you diagnose issues with your application. The sample application includes standard Log4j logging statements to demonstrate this capability, as shown in the following snippet:

+ :::column span="2":::

+ **Step 1:** In the App Service page:

+ 1. From the left menu, select **App Service logs**.

+ 1. Under **Application logging**, select **File System**.

+ 1. In the top menu, select **Save**.

+ :::column-end:::

+ :::column:::

+ :::image type="content" source="./media/tutorial-java-spring-cosmosdb/azure-portal-stream-diagnostic-logs-1.png" alt-text="A screenshot showing how to enable native logs in App Service in the Azure portal." lightbox="./media/tutorial-java-spring-cosmosdb/azure-portal-stream-diagnostic-logs-1.png":::

+ :::column-end:::

+ :::column span="2":::

+ **Step 2:** From the left menu, select **Log stream**. You see the logs for your app, including platform logs and logs from inside the container.

+ :::column-end:::

+ :::column:::

+ :::image type="content" source="./media/tutorial-java-spring-cosmosdb/azure-portal-stream-diagnostic-logs-2.png" alt-text="A screenshot showing how to view the log stream in the Azure portal." lightbox="./media/tutorial-java-spring-cosmosdb/azure-portal-stream-diagnostic-logs-2.png":::

+ :::column-end:::

+Learn more about logging in Java apps in the series on [Enable Azure Monitor OpenTelemetry for .NET, Node.js, Python and Java applications](../azure-monitor/app/opentelemetry-enable.md?tabs=java).

+Having issues? Check the [Troubleshooting section](#troubleshooting).

+## 8. Clean up resources

+When you're finished, you can delete all of the resources from your Azure subscription by deleting the resource group.

+ :::column span="2":::

+ **Step 1:** In the search bar at the top of the Azure portal:

+ 1. Enter the resource group name.

+ 1. Select the resource group.

+ :::column-end:::

+ :::column:::

+ :::image type="content" source="./media/tutorial-java-spring-cosmosdb/azure-portal-clean-up-resources-1.png" alt-text="A screenshot showing how to search for and navigate to a resource group in the Azure portal." lightbox="./media/tutorial-java-spring-cosmosdb/azure-portal-clean-up-resources-1.png":::

+ :::column-end:::

+ :::column span="2":::

+ **Step 2:** In the resource group page, select **Delete resource group**.

+ :::column-end:::

+ :::column:::

+ :::image type="content" source="./media/tutorial-java-spring-cosmosdb/azure-portal-clean-up-resources-2.png" alt-text="A screenshot showing the location of the **Delete Resource Group** button in the Azure portal." lightbox="./media/tutorial-java-spring-cosmosdb/azure-portal-clean-up-resources-2.png":::

+ :::column-end:::

+ :::column span="2":::

+ **Step 3:**

+ 1. Confirm your deletion by typing the resource group name.

+ 1. Select **Delete**.

+ 1. Confirm with **Delete** again.

+ :::column-end:::

+ :::column:::

+ :::image type="content" source="./media/tutorial-java-spring-cosmosdb/azure-portal-clean-up-resources-3.png" alt-text="A screenshot of the confirmation dialog for deleting a resource group in the Azure portal." lightbox="./media/tutorial-java-spring-cosmosdb/azure-portal-clean-up-resources-3.png":::

+ :::column-end:::

+## 2. Create Azure resources and deploy a sample app

+In this step, you create the Azure resources and deploy a sample app to App Service on Linux. The steps used in this tutorial create a set of secure-by-default resources that include App Service and Azure Cosmos DB.

+The dev container already has the [Azure Developer CLI](/azure/developer/azure-developer-cli/install-azd) (AZD).

+1. From the repository root, run `azd init`.

+ ```bash

+ azd init --template javase-app-service-cosmos-redis-infra

+ ```

+1. When prompted, give the following answers:

+

+ |Question |Answer |

+ |||

+ |The current directory is not empty. Would you like to initialize a project here in '\<your-directory>'? | **Y** |

+ |What would you like to do with these files? | **Keep my existing files unchanged** |

+ |Enter a new environment name | Type a unique name. The AZD template uses this name as part of the DNS name of your web app in Azure (`<app-name>.azurewebsites.net`). Alphanumeric characters and hyphens are allowed. |

+1. Sign into Azure by running the `azd auth login` command and following the prompt:

+ ```bash

+ azd auth login

+ ```

+1. Create the necessary Azure resources and deploy the app code with the `azd up` command. Follow the prompt to select the desired subscription and location for the Azure resources.

+ ```bash

+ azd up

+ ```

+ The `azd up` command takes about 15 minutes to complete (the Redis cache take the most time). It also compiles and deploys your application code, but you'll modify your code later to work with App Service. While it's running, the command provides messages about the provisioning and deployment process, including a link to the deployment in Azure. When it finishes, the command also displays a link to the deploy application.

+ This AZD template contains files (*azure.yaml* and the *infra* directory) that generate a secure-by-default architecture with the following Azure resources:

+ - **Resource group**: The container for all the created resources.

+ - **App Service plan**: Defines the compute resources for App Service. A Linux plan in the *B1* tier is created.

+ - **App Service**: Represents your app and runs in the App Service plan.

+ - **Virtual network**: Integrated with the App Service app and isolates back-end network traffic.

+ - **Azure Cosmos DB account with MongoDB API**: Accessible only from behind its private endpoint. A database is created for you on the server.

+ - **Azure Cache for Redis**: Accessible only from within the virtual network.

+ - **Key vault**: Accessible only from behind its private endpoint. Used to manage secrets for the App Service app.

+ - **Private DNS zones**: Enable DNS resolution of the Cosmos DB database, the Redis cache, and the key vault in the virtual network.

+ - **Log Analytics workspace**: Acts as the target container for your app to ship its logs, where you can also query the logs.

+Having issues? Check the [Troubleshooting section](#troubleshooting).

+## 3. Verify connection strings

+The AZD template you use generated the connectivity variables for you already as [app settings](configure-common.md#configure-app-settings) and outputs the them to the terminal for your convenience. App settings are one way to keep connection secrets out of your code repository.

+1. In the AZD output, find the app setting `spring.data.mongodb.uri`. Only the setting names are displayed. They look like this in the AZD output:

+ <pre>

+ App Service app has the following app settings:

+ - spring.data.mongodb.uri

+ - spring.data.mongodb.database

+ - spring.redis.host

+ - spring.redis.port

+ - spring.redis.password

+ - spring.redis.database

+ - spring.redis.ssl

+ - spring.cloud.azure.keyvault.secret.credential.managed_identity_enabled

+ - spring.cloud.azure.keyvault.secret.endpoint

+ - azure.keyvault.uri

+ - azure.keyvault.scope

+ </pre>

+ `spring.data.mongodb.uri` contains the connection URI to the Cosmos DB database in Azure. It's a standard Spring Data variable, which your application is already using in the *src/main/resources/application.properties* file.

+1. In the explorer, navigate to *src/main/resources/application.properties* and see that your Spring Boot app is already using the `spring.data.mongodb.uri` variable to access data.

+1. For your convenience, the AZD template output shows you the direct link to the app's app settings page. Find the link and open it in a new browser tab.

+ If you look at the value of `spring.data.mongodb.uri`, it should be `@Microsoft.KeyValut(...)`, which means that it's a [key vault reference](app-service-key-vault-references.md) because the secret is managed in the key vault.

+Having issues? Check the [Troubleshooting section](#troubleshooting).

+## 5. Browse to the app

+1. In the AZD output, find the URL of your app and navigate to it in the browser. The URL looks like this in the AZD output:

+ <pre>

+ Deploying services (azd deploy)

+

+ (Γ£ô) Done: Deploying service web

+ - Endpoint: https://&lt;app-name>.azurewebsites.net/

+ </pre>

+2. Add a few tasks to the list.

+ :::image type="content" source="./media/tutorial-java-spring-cosmosdb/azure-portal-browse-app-2.png" alt-text="A screenshot of the Tomcat web app with MySQL running in Azure showing tasks." lightbox="./media/tutorial-java-spring-cosmosdb/azure-portal-browse-app-2.png":::

+ Congratulations, you're running a web app in Azure App Service, with secure connectivity to Azure Cosmos DB.

+Having issues? Check the [Troubleshooting section](#troubleshooting).

+## 6. Stream diagnostic logs

+Azure App Service can capture console logs to help you diagnose issues with your application. For convenience, the AZD template already [enabled logging to the local file system](troubleshoot-diagnostic-logs.md#enable-application-logging-linuxcontainer) and is [shipping the logs to a Log Analytics workspace](troubleshoot-diagnostic-logs.md#send-logs-to-azure-monitor).

+The sample application includes standard Log4j logging statements to demonstrate this capability, as shown in the following snippet:

+In the AZD output, find the link to stream App Service logs and navigate to it in the browser. The link looks like this in the AZD output:

+<pre>

+Stream App Service logs at: https://portal.azure.com/#@/resource/subscriptions/&lt;subscription-guid>/resourceGroups/&lt;group-name>/providers/Microsoft.Web/sites/&lt;app-name>/logStream

+</pre>

+Learn more about logging in Java apps in the series on [Enable Azure Monitor OpenTelemetry for .NET, Node.js, Python and Java applications](../azure-monitor/app/opentelemetry-enable.md?tabs=java).

+Having issues? Check the [Troubleshooting section](#troubleshooting).

+## 7. Clean up resources

+To delete all Azure resources in the current deployment environment, run `azd down` and follow the prompts.

+azd down

+## Troubleshooting

+- [The portal deployment view for Azure Cosmos DB shows a Conflict status](#the-portal-deployment-view-for-azure-cosmos-db-shows-a-conflict-status)

+- [The deployed sample app doesn't show the tasks list app](#the-deployed-sample-app-doesnt-show-the-tasks-list-app)

+#### The portal deployment view for Azure Cosmos DB shows a Conflict status

+Depending on your subscription and the region you select, you might see the deployment status for Azure Cosmos DB to be `Conflict`, with the following message in Operation details:

+`Sorry, we are currently experiencing high demand in <region> region, and cannot fulfill your request at this time.`

+The error is most likely caused by a limit on your subscription for the region you select. Try choosing a different region for your deployment.

+#### The deployed sample app doesn't show the tasks list app

+If you see a `Hey, Java developers!` page instead of the tasks list app, App Service is most likely still loading the updated container from your most recent code deployment. Wait a few minutes and refresh the page.

+## Frequently asked questions

+- [How much does this setup cost?](#how-much-does-this-setup-cost)

+- [How do I run database migration with the Cosmos DB database behind the virtual network?](#how-do-i-run-database-migration-with-the-cosmos-db-database-behind-the-virtual-network)

+- [How does local app development work with GitHub Actions?](#how-does-local-app-development-work-with-github-actions)

+- [I don't have permissions to create a user-assigned identity](#i-dont-have-permissions-to-create-a-user-assigned-identity)

+#### How much does this setup cost?

+Pricing for the created resources is as follows:

+- The App Service plan is created in **Basic** tier and can be scaled up or down. See [App Service pricing](https://azure.microsoft.com/pricing/details/app-service/linux/).

+- The Azure Cosmos DB account is created in **Serverless** tier and there's a small cost associated with this tier. See [Azure Cosmos DB pricing](https://azure.microsoft.com/pricing/details/cosmos-db/serverless/).

+- The Azure Cache for Redis is created in **Basic** tier with the minimum cache size. There's a small cost associated with this tier. You can scale it up to higher performance tiers for higher availability, clustering, and other features. See [Azure Cache for Redis pricing](https://azure.microsoft.com/pricing/details/cache/).

+- The virtual network doesn't incur a charge unless you configure extra functionality, such as peering. See [Azure Virtual Network pricing](https://azure.microsoft.com/pricing/details/virtual-network/).

+- The private DNS zone incurs a small charge. See [Azure DNS pricing](https://azure.microsoft.com/pricing/details/dns/).

+#### How do I run database migration with the Cosmos DB database behind the virtual network?

+The Java SE container in App Service already has network connectivity to Cosmos DB, but doesn't contain any migration tools or other MongoDB tools. You have a few options:

+- Run database migrations automatically at app start, such as with Hibernate and or Flyway.

+- In the app's [SSH session](configure-language-java-deploy-run.md#linux-troubleshooting-tools), install a migration tool like [Flyway CLI](https://documentation.red-gate.com/fd/command-line-184127404.html), then run the migration script. Remember that the installed tool won't persist after an app restart unless it's in the */home* directory.

+- [Integrate the Azure cloud shell](../cloud-shell/private-vnet.md) with the virtual network and run database migrations from there.

+#### How does local app development work with GitHub Actions?

+Using the autogenerated workflow file from App Service as an example, each `git push` kicks off a new build and deployment run. From a local clone of the GitHub repository, you make the desired updates and push to GitHub. For example:

+```terminal

+git add .

+git commit -m "<some-message>"

+git push origin main

+#### I don't have permissions to create a user-assigned identity

+See [Set up GitHub Actions deployment from the Deployment Center](deploy-github-actions.md#set-up-github-actions-deployment-from-the-deployment-center).

+#### What can I do with GitHub Copilot in my codespace?

+You might notice that the GitHub Copilot chat view was already there for you when you created the codespace. For your convenience, we include the GitHub Copilot chat extension in the container definition (see *.devcontainer/devcontainer.json*). However, you need a [GitHub Copilot account](https://docs.github.com/copilot/using-github-copilot/using-github-copilot-code-suggestions-in-your-editor) (30-day free trial available).

+A few tips for you when you talk to GitHub Copilot:

+- In a single chat session, the questions and answers build on each other and you can adjust your questions to fine-tune the answer you get.

+- By default, GitHub Copilot doesn't have access to any file in your repository. To ask questions about a file, open the file in the editor first.

+- To let GitHub Copilot have access to all of the files in the repository when preparing its answers, begin your question with `@workspace`. For more information, see [Use the @workspace agent](https://github.blog/2024-03-25-how-to-use-github-copilot-in-your-ide-tips-tricks-and-best-practices/#10-use-the-workspace-agent).

+- In the chat session, GitHub Copilot can suggest changes and (with `@workspace`) even where to make the changes, but it's not allowed to make the changes for you. It's up to you to add the suggested changes and test it.

+- [Azure for Java Developers](/java/azure/)

+- [Spring Boot](https://spring.io/projects/spring-boot)

+- [Spring Data for Azure Cosmos DB](/azure/developer/java/spring-framework/configure-spring-boot-starter-java-app-with-cosmos-db)

+- [Azure Cosmos DB](/azure/cosmos-db/introduction) and

+-[App Service Linux](overview.md)

+Learn more about running Java apps on App Service in the developer guide.

+> [Configure a Java app in Azure App Service](configure-language-java-deploy-run.md?pivots=platform-linux)

+ 1. Select **Code** > **Create codespace on starter-no-infra**.

+* The **Name** for the web app. It's the name used as part of the DNS name for your app in the form of `https://<app-name>.azurewebsites.net`.

+* The **Region** to run the app physically in the world. It's also used as part of the DNS name for your app.

+ GitHub Copilot doesn't give you the same response every time, you might need to ask other questions to fine-tune its response. For tips, see [What can I do with GitHub Copilot in my codespace?](#what-can-i-do-with-github-copilot-in-my-codespace)

+- The Tomcat container currently doesn't have the `mysql-client` terminal too. If you want, you must manually install it. Remember that anything you install doesn't persist across app restarts.

+You might notice that the GitHub Copilot chat view was already there for you when you created the codespace. For your convenience, we include the GitHub Copilot chat extension in the container definition (see *.devcontainer/devcontainer.json*). However, you need a [GitHub Copilot account](https://docs.github.com/copilot/using-github-copilot/using-github-copilot-code-suggestions-in-your-editor) (30-day free trial available).

+* Change this code to use the data source jdbc/AZURE_MYSQL_CONNECTIONSTRING_DS.

+> [!Important]

+> Change Tracking and Inventory using Log Analytics agent has retired on **31 August 2024** and we recommend that you use Azure Monitoring Agent as the new supporting agent. Follow the guidelines for [migration from Change Tracking and inventory using Log Analytics to Change Tracking and inventory using Azure Monitoring Agent version](guidance-migration-log-analytics-monitoring-agent.md).

+> [!Important]

+> Change Tracking and Inventory using Log Analytics agent has retired on **31 August 2024** and we recommend that you use Azure Monitoring Agent as the new supporting agent. Follow the guidelines for [migration from Change Tracking and inventory using Log Analytics to Change Tracking and inventory using Azure Monitoring Agent version](guidance-migration-log-analytics-monitoring-agent.md).

+> [!Important]

+> Change Tracking and Inventory using Log Analytics agent has retired on **31 August 2024** and we recommend that you use Azure Monitoring Agent as the new supporting agent. Follow the guidelines for [migration from Change Tracking and inventory using Log Analytics to Change Tracking and inventory using Azure Monitoring Agent version](guidance-migration-log-analytics-monitoring-agent.md).

+> Change Tracking and Inventory using Log Analytics agent has retired on **31 August 2024** and we recommend that you use Azure Monitoring Agent as the new supporting agent. Follow the guidelines for [migration from Change Tracking and inventory using Log Analytics to Change Tracking and inventory using Azure Monitoring Agent version](guidance-migration-log-analytics-monitoring-agent.md).

+> [!Important]

+> You can expect the following if you use the capability using Change Tracking & Inventory Log Analytics Agent.

+> - **Functionality**: The functional capabilities of Change Tracking with Log Analytics agent would continue to work till Feb'2025. However, the support will be limited and can lead to potential issues over time.

+> - **Installation**: The ability to configure Change Tracking & Inventory using MMA/OMS agents will be removed from the Azure portal soon.

+>- **Customer Support**: You will not be able to get support through existing channels for Change Tracking & Inventory with MMA/OMS. Microsoft will provide support on a best effort basis.

+> - **New capabilities and support matrix**: No new capabilities will be added, including functionality for additional Windows or Linux versions.

+> - **File Integrity Monitoring**: Microsoft Defender for Servers Plan 2 will offer a new File Integrity Monitoring (FIM) solution powered by Microsoft Defender for Endpoint (MDE) integration. Microsoft Defender for Cloud recommends disabling FIM over MMA by November 2024 and onboarding your environment to the new FIM version based on Defender for Endpoint. File Integrity Monitoring based on Log Analytics Agent (MMA) is supported till November 2024. [Learn more](https://learn.microsoft.com/azure/defender-for-cloud/prepare-deprecation-log-analytics-mma-agent#migration-from-fim-over-log-analytics-agent-mma).

+> - Azure Automation Update Management has retired on **31 August 2024**. Follow the guidelines for [migration to Azure Update Manager](../../update-manager/guidance-migration-automation-update-management-azure-update-manager.md).

+> - Azure Log Analytics agent, also known as the Microsoft Monitoring Agent (MMA) has [retired in August 2024](https://azure.microsoft.com/updates/were-retiring-the-log-analytics-agent-in-azure-monitor-on-31-august-2024/). Azure Automation Update Management solution relies on this agent and may encounter issues once the agent is retired as it does not work with Azure Monitoring Agent (AMA). Therefore, if you are using the Azure Automation Update Management solution, we recommend that you move to Azure Update Manager for your software update needs. All the capabilities of Azure Automation Update management solution will be available on Azure Update Manager before the retirement date. Follow the [guidance](../../update-center/guidance-migration-automation-update-management-azure-update-manager.md) to move your machines and schedules from Automation Update Management to Azure Update Manager.

+ Title: Create functions in Azure using the Azure Developer CLI

+description: "Learn how to use the Azure Developer CLI (azd) to create resources and deploy the local project to a Flex Consumption plan on Azure."

+zone_pivot_groups: programming-languages-set-functions

+#Customer intent: As a developer, I need to know how to use the Azure Developer CLI to create and deploy my function code securely to a new function app in the Flex Consumption plan in Azure by using azd templates and the azd up command.

+# Quickstart: Create and deploy functions to Azure Functions using the Azure Developer CLI

+In this Quickstart, you use Azure Developer command-line tools to create functions that respond to HTTP requests. After testing the code locally, you deploy it to a new serverless function app you create running in a Flex Consumption plan in Azure Functions.

+The project source uses the Azure Developer CLI (azd) to simplify deploying your code to Azure. This deployment follows current best practices for secure and scalable Azure Functions deployments.

+By default, the Flex Consumption plan follows a _pay-for-what-you-use_ billing model, which means to complete this quickstart incurs a small cost of a few USD cents or less in your Azure account.

+## Prerequisites

+ + If you use another [supported version of Java](supported-languages.md?pivots=programming-language-java#languages-by-runtime-version), you must update the project's pom.xml file.

+ + The `JAVA_HOME` environment variable must be set to the install location of the correct version of the JDK.

+## Initialize the project

+You can use the `azd init` command to create a local Azure Functions code project from a template.

+1. In your local terminal or command prompt, run this `azd init` command in an empty folder:

+

+ ```console

+ azd init --template functions-quickstart-dotnet-azd -e flexquickstart-dotnet

+ ```

+ This command pulls the project files from the [template repository](https://github.com/Azure-Samples/functions-quickstart-dotnet-azd) and initializes the project in the current folder. The `-e` flag sets a name for the current environment. In `azd`, the environment is used to maintain a unique deployment context for your app, and you can define more than one. It's also used in the name of the resource group you create in Azure.

+1. Run this command to navigate to the `http` app folder:

+ ```console

+ cd http

+ ```

+1. Create a file named _local.settings.json_ in the `http` folder that contains this JSON data:

+ ```json

+ {

+ "IsEncrypted": false,

+ "Values": {

+ "AzureWebJobsStorage": "UseDevelopmentStorage=true",

+ "FUNCTIONS_WORKER_RUNTIME": "dotnet-isolated"

+ }

+ }

+ ```

+ This file is required when running locally.

+1. In your local terminal or command prompt, run this `azd init` command in an empty folder:

+

+ ```console

+ azd init --template azure-functions-java-flex-consumption-azd -e flexquickstart-java

+ ```

+ This command pulls the project files from the [template repository](https://github.com/Azure-Samples/azure-functions-java-flex-consumption-azd) and initializes the project in the current folder. The `-e` flag sets a name for the current environment. In `azd`, the environment is used to maintain a unique deployment context for your app, and you can define more than one. It's also used in the name of the resource group you create in Azure.

+1. Run this command to navigate to the `http` app folder:

+ ```console

+ cd http

+ ```

+1. Create a file named _local.settings.json_ in the `http` folder that contains this JSON data:

+ ```json

+ {

+ "IsEncrypted": false,

+ "Values": {

+ "AzureWebJobsStorage": "UseDevelopmentStorage=true",

+ "FUNCTIONS_WORKER_RUNTIME": "java"

+ }

+ }

+ ```

+ This file is required when running locally.

+1. In your local terminal or command prompt, run this `azd init` command in an empty folder:

+

+ ```console

+ azd init --template functions-quickstart-javascript-azd -e flexquickstart-js

+ ```

+ This command pulls the project files from the [template repository](https://github.com/Azure-Samples/functions-quickstart-javascript-azd) and initializes the project in the root folder. The `-e` flag sets a name for the current environment. In `azd`, the environment is used to maintain a unique deployment context for your app, and you can define more than one. It's also used in the name of the resource group you create in Azure.

+1. Create a file named _local.settings.json_ in the root folder that contains this JSON data:

+ ```json

+ {

+ "IsEncrypted": false,

+ "Values": {

+ "AzureWebJobsStorage": "UseDevelopmentStorage=true",

+ "FUNCTIONS_WORKER_RUNTIME": "node"

+ }

+ }

+ ```

+ This file is required when running locally.

+1. In your local terminal or command prompt, run this `azd init` command in an empty folder:

+

+ ```console

+ azd init --template functions-quickstart-powershell-azd -e flexquickstart-ps

+ ```

+ This command pulls the project files from the [template repository](https://github.com/Azure-Samples/functions-quickstart-powershell-azd) and initializes the project in the root folder. The `-e` flag sets a name for the current environment. In `azd`, the environment is used to maintain a unique deployment context for your app, and you can define more than one. It's also used in the name of the resource group you create in Azure.

+1. Run this command to navigate to the `src` app folder:

+ ```console

+ cd src

+ ```

+1. Create a file named _local.settings.json_ in the `src` folder that contains this JSON data:

+ ```json

+ {

+ "IsEncrypted": false,

+ "Values": {

+ "AzureWebJobsStorage": "UseDevelopmentStorage=true",

+ "FUNCTIONS_WORKER_RUNTIME": "powershell",

+ "FUNCTIONS_WORKER_RUNTIME_VERSION": "7.2"

+ }

+ }

+ ```

+ This file is required when running locally.

+1. In your local terminal or command prompt, run this `azd init` command in an empty folder:

+

+ ```console

+ azd init --template functions-quickstart-typescript-azd -e flexquickstart-ts

+ ```

+ This command pulls the project files from the [template repository](https://github.com/Azure-Samples/functions-quickstart-typescript-azd) and initializes the project in the root folder. The `-e` flag sets a name for the current environment. In `azd`, the environment is used to maintain a unique deployment context for your app, and you can define more than one. It's also used in the name of the resource group you create in Azure.

+1. Create a file named _local.settings.json_ in the root folder that contains this JSON data:

+ ```json

+ {

+ "IsEncrypted": false,

+ "Values": {

+ "AzureWebJobsStorage": "UseDevelopmentStorage=true",

+ "FUNCTIONS_WORKER_RUNTIME": "node"

+ }

+ }

+ ```

+ This file is required when running locally.

+1. In your local terminal or command prompt, run this `azd init` command in an empty folder:

+

+ ```console

+ azd init --template functions-quickstart-python-http-azd -e flexquickstart-py

+ ```

+

+ This command pulls the project files from the [template repository](https://github.com/Azure-Samples/functions-quickstart-python-http-azd) and initializes the project in the root folder. The `-e` flag sets a name for the current environment. In `azd`, the environment is used to maintain a unique deployment context for your app, and you can define more than one. It's also used in the name of the resource group you create in Azure.

+1. Create a file named _local.settings.json_ in the root folder that contains this JSON data:

+ ```json

+ {

+ "IsEncrypted": false,

+ "Values": {

+ "AzureWebJobsStorage": "UseDevelopmentStorage=true",

+ "FUNCTIONS_WORKER_RUNTIME": "python"

+ }

+ }

+ ```

+ This file is required when running locally.

+## Create and activate a virtual environment

+In the root folder, run these commands to create and activate a virtual environment named `.venv`:

+### [Linux/macOS](#tab/linux)

+```bash

+python3 -m venv .venv

+source .venv/bin/activate

+```

+If Python didn't install the venv package on your Linux distribution, run the following command:

+```bash

+sudo apt-get install python3-venv

+```

+### [Windows (bash)](#tab/windows-bash)

+```bash

+py -m venv .venv

+source .venv/scripts/activate

+```

+### [Windows (Cmd)](#tab/windows-cmd)

+```shell

+py -m venv .venv

+.venv\scripts\activate

+```

+## Run in your local environment

+1. Run this command from your app folder in a terminal or command prompt:

+ ::: zone pivot="programming-language-csharp, programming-language-powershell,programming-language-python,programming-language-javascript"

+ ```console

+ func start

+ ```

+ ::: zone-end

+ ::: zone pivot="programming-language-java"

+ ```console

+ mvn clean package

+ mvn azure-functions:run

+ ```

+ ::: zone-end

+ ::: zone pivot="programming-language-typescript"

+ ```console

+ npm start

+ ```

+ ::: zone-end

+ When the Functions host starts in your local project folder, it writes the URL endpoints of your HTTP triggered functions to the terminal output.

+1. In your browser, navigate to the `httpget` endpoint, which should look like this URL:

+ <http://localhost:7071/api/httpget>

+1. From a new terminal or command prompt window, run this `curl` command to send a POST request with a JSON payload to the `httppost` endpoint:

+ ```console

+ curl -i http://localhost:7071/api/httppost -H "Content-Type: text/json" -d @testdata.json

+ ```

+ This command reads JSON payload data from the `testdata.json` project file. You can find examples of both HTTP requests in the `test.http` project file.

+1. When you're done, press Ctrl+C in the terminal window to stop the `func.exe` host process.

+5. Run `deactivate` to shut down the virtual environment.

+## Review the code (optional)

+You can review the code that defines the two HTTP trigger function endpoints:

+

+### [`httpget`](#tab/get)

+This `function.json` file defines the `httpget` function:

+This `run.ps1` file implements the function code:

+

+### [`httppost`](#tab/post)

+

+This `function.json` file defines the `httppost` function:

+This `run.ps1` file implements the function code:

+After you verify your functions locally, it's time to publish them to Azure.

+## Create Azure resources

+This project is configured to use the `azd provision` command to create a function app in a Flex Consumption plan, along with other required Azure resources.

+>[!NOTE]

+>This project includes a set of Bicep files that `azd` uses to create a secure deployment to a Flex consumption plan that follows best practices.

+>

+>The `azd up` and `azd deploy` commands aren't currently supported for Java apps.

+1. In the root folder of the project, run this command to create the required Azure resources:

+ ```console

+ azd provision

+ ```

+ The root folder contains the `azure.yaml` definition file required by `azd`.

+ If you aren't already signed-in, you're asked to authenticate with your Azure account.

+1. When prompted, provide these required deployment parameters:

+ | Parameter | Description |

+ | - | - |

+ | _Azure subscription_ | Subscription in which your resources are created.|

+ | _Azure location_ | Azure region in which to create the resource group that contains the new Azure resources. Only regions that currently support the Flex Consumption plan are shown.|

+

+ The `azd provision` command uses your response to these prompts with the Bicep configuration files to create and configure these required Azure resources:

+ + Flex Consumption plan and function app

+ + Azure Storage (required) and Application Insights (recommended)

+ + Access policies and roles for your account

+ + Service-to-service connections using managed identities (instead of stored connection strings)

+ + Virtual network to securely run both the function app and the other Azure resources

+ After the command completes successfully, you can deploy your project code to this new function app in Azure.

+## Deploy to Azure

+You can use Core Tools to package your code and deploy it to Azure from the `target` output folder.

+1. Navigate to the app folder equivalent in the `target` output folder:

+ ```console

+ cd http/target/azure-functions/contoso-functions

+ ```

+

+ This folder should have a host.json file, which indicates that it's the root of your compiled Java function app.

+

+1. Run these commands to deploy your compiled Java code project to the new function app resource in Azure using Core Tools:

+

+ ### [bash](#tab/bash)

+ ```bash

+ APP_NAME=$(azd env get-value AZURE_FUNCTION_NAME)

+ func azure functionapp publish $APP_NAME

+ ```

+ ### [Cmd](#tab/cmd)

+ ```cmd

+ for /f "tokens=*" %i in ('azd env get-value AZURE_FUNCTION_NAME') do set APP_NAME=%i

+ func azure functionapp publish %APP_NAME%

+ ```

+

+ The `azd env get-value` command gets your function app name from the local environment, which is required for deployment using `func azure functionapp publish`. After publishing completes successfully, you see links to the HTTP trigger endpoints in Azure.

+## Deploy to Azure

+This project is configured to use the `azd up` command to deploy this project to a new function app in a Flex Consumption plan in Azure.

+>[!TIP]

+>This project includes a set of Bicep files that `azd` uses to create a secure deployment to a Flex consumption plan that follows best practices.

+1. Run this command to have `azd` create the required Azure resources in Azure and deploy your code project to the new function app:

+ ```console

+ azd up

+ ```

+ The root folder contains the `azure.yaml` definition file required by `azd`.

+ If you aren't already signed-in, you're asked to authenticate with your Azure account.

+1. When prompted, provide these required deployment parameters:

+ | Parameter | Description |

+ | - | - |

+ | _Azure subscription_ | Subscription in which your resources are created.|

+ | _Azure location_ | Azure region in which to create the resource group that contains the new Azure resources. Only regions that currently support the Flex Consumption plan are shown.|

+

+ The `azd up` command uses your response to these prompts with the Bicep configuration files to complete these deployment tasks:

+ + Create and configure these required Azure resources (equivalent to `azd provision`):

+ + Flex Consumption plan and function app

+ + Azure Storage (required) and Application Insights (recommended)

+ + Access policies and roles for your account

+ + Service-to-service connections using managed identities (instead of stored connection strings)

+ + Virtual network to securely run both the function app and the other Azure resources

+ + Package and deploy your code to the deployment container (equivalent to `azd deploy`). The app is then started and runs in the deployed package.

+ After the command completes successfully, you see links to the resources you created.

+## Invoke the function on Azure

+You can now invoke your function endpoints in Azure by making HTTP requests to their URLs using your HTTP test tool or from the browser (for GET requests). When your functions run in Azure, access key authorization is enforced, and you must provide a function access key with your request.

+You can use the Core Tools to obtain the URL endpoints of your functions running in Azure.

+1. In your local terminal or command prompt, run these commands to get the URL endpoint values:

+

+ ### [bash](#tab/bash)

+ ```bash

+ SET APP_NAME=(azd env get-value AZURE_FUNCTION_NAME)

+ func azure functionapp list-functions $APP_NAME --show-keys

+ ```

+ ### [Cmd](#tab/cmd)

+ ```cmd

+ for /f "tokens=*" %i in ('azd env get-value AZURE_FUNCTION_NAME') do set APP_NAME=%i

+ func azure functionapp list-functions %APP_NAME% --show-keys

+ ```

+

+ The `azd env get-value` command gets your function app name from the local environment. Using the `--show-keys` option with `func azure functionapp list-functions` means that the returned **Invoke URL:** value for each endpoint includes a function-level access key.

+1. As before, use your HTTP test tool to validate these URLs in your function app running in Azure.

+## Redeploy your code

+You can run the `azd up` command as many times as you need to both provision your Azure resources and deploy code updates to your function app.

+>[!NOTE]

+>Deployed code files are always overwritten by the latest deployment package.

+Your initial responses to `azd` prompts and any environment variables generated by `azd` are stored locally in your named environment. Use the `azd env get-values` command to review all of the variables in your environment that were used when creating Azure resources.

+## Clean up resources

+When you're done working with your function app and related resources, you can use this command to delete the function app and its related resources from Azure and avoid incurring any further costs:

+```console

+azd down --no-prompt

+```

+>[!NOTE]

+>The `--no-prompt` option instructs `azd` to delete your resource group without a confirmation from you.

+>

+>This command doesn't affect your local code project.

+## Related content

+Running in an App Service Environment (ASE) lets you fully isolate your functions and take advantage of higher numbers of instances than an App Service Plan. To get started, see [Introduction to the App Service Environments](../app-service/environment/overview.md).

+* When the function app isn't at the root of the source repo, make sure that the `pip install` step references the correct location in which to create the `.python_packages` folder. Keep in mind that this location is case sensitive, such as in this command example:

+description: This article describes how to upgrade the VM Insights Dependency Agent using command-line, setup wizard, and other methods.

+Dependency Agent collects data about processes running on the virtual machine and external process dependencies. Updates include bug fixes or support of new features or functionality. This article describes Dependency Agent requirements and how to upgrade it manually or through automation.

+> Dependency Agent sends heartbeat data to the [InsightsMetrics](/azure/azure-monitor/reference/tables/insightsmetrics) table, for which you incur data ingestion charges. This behavior is different from Azure Monitor Agent, which sends agent health data to the [Heartbeat](/azure/azure-monitor/reference/tables/heartbeat) table, which is free from data collection charges.

+> [!div class="checklist"]

+> * Requires the Azure Monitor Agent to be installed on the same machine.

+> * Collects data using a user-space service and a kernel driver on both Windows and Linux.

+> * Supports the same [Windows versions that Azure Monitor Agent supports](../agents/agents-overview.md#supported-operating-systems), except Windows Server 2008 SP2 and Azure Stack HCI. For Linux, see [Dependency Agent Linux support](#dependency-agent-linux-support).

+You can upgrade Dependency Agent for Windows and Linux manually or automatically, depending on the deployment scenario and environment the machine is running in, using these methods:

+| Environment | Installation method | Upgrade method |

+|-||-|

+| Azure VM | Dependency Agent VM extension for [Windows](/azure/virtual-machines/extensions/agent-dependency-windows) and [Linux](/azure/virtual-machines/extensions/agent-dependency-linux) | Agent is automatically upgraded by default unless you configured your Azure Resource Manager template to opt out by setting the property `autoUpgradeMinorVersion` to **false**. The upgrade for minor version where auto upgrade is disabled, and a major version upgrade follow the same method - uninstall and reinstall the extension. |

+| Custom Azure VM images | Manual install of Dependency Agent for Windows/Linux | Updating VMs to the newest version of the agent needs to be performed from the command line running the Windows installer package or Linux self-extracting and installable shell script bundle. |

+| Non-Azure VMs | Manual install of Dependency Agent for Windows/Linux | Updating VMs to the newest version of the agent needs to be performed from the command line running the Windows installer package or Linux self-extracting and installable shell script bundle. |

+> [!NOTE]

+> Dependency Agent is installed automatically when VM Insights is enabled for process and connection data via the [Azure portal](vminsights-enable-portal.md), [PowerShell](vminsights-enable-powershell.md), [ARM template deployment](vminsights-enable-resource-manager.md), or [Azure policy](vminsights-enable-policy.md).

+>

+> If VM Insights is enabled exclusively for performance data, Dependency Agent won't be installed.

+Update the agent on a Windows VM from the command prompt, with a script or other automation solution, or by using the InstallDependencyAgent-Windows.exe Setup Wizard.

+#### Prerequisites

+> [!div class="checklist"]

+> * Download the latest version of the Windows agent from [aka.ms/dependencyagentwindows](https://aka.ms/dependencyagentwindows).

+1. Execute **InstallDependencyAgent-Windows.exe** to start the Setup Wizard.

+1. Follow the **Dependency Agent Setup** wizard to uninstall the previous version of Dependency Agent and then install the latest version.

+1. Sign in on the computer using an account with administrative rights.

+1. Run the following command:

+1. To confirm the upgrade was successful, check the `install.log` for detailed setup information. The log directory is *%Programfiles%\Microsoft Dependency Agent\logs*.

+### Manually install or upgrade Dependency Agent on Linux

+Upgrading from prior versions of Dependency Agent on Linux is supported and performed following the same command as a new installation.

+#### Prerequisites

+> [!div class="checklist"]

+> * Download the latest version of the Linux agent from [aka.ms/dependencyagentlinux](https://aka.ms/dependencyagentlinux) or via curl:

+```bash

+curl -L -o DependencyAgent-Linux64.bin https://aka.ms/dependencyagentlinux

+```

+> [!NOTE]

+> Curl doesn't automatically set execution permissions. You need to manually set them using chmod:

+>

+> ```bash

+> chmod +x DependencyAgent-Linux64.bin

+> ```

+#### From the command line

+1. Sign in on the computer with a user account that has sudo privileges to execute commands as root.

+1. Run the following command:

+ sudo <path>/InstallDependencyAgent-Linux64.bin

+If Dependency Agent fails to start, check the logs for detailed error information. On Linux agents, the log directory is */var/opt/microsoft/dependency-agent/log*.

+## Uninstall Dependency Agent

+> [!NOTE]

+> If Dependency Agent was installed manually, it wonΓÇÖt show in the Azure portal and has to be uninstalled manually. It will only show if it was installed via the [Azure portal](vminsights-enable-portal.md), [PowerShell](vminsights-enable-powershell.md), [ARM template deployment](vminsights-enable-resource-manager.md), or [Azure policy](vminsights-enable-policy.md).

+### Manually uninstall Dependency Agent on Windows

+**Method 1:** In Windows, go to **Add and remove programs**, find Microsoft Dependency Agent, click on the ellipsis to open the context menu, and select **Uninstall**.

+**Method 2:** Use the uninstaller located in the Microsoft Dependency Agent folder, for example, `C:\Program Files\Microsoft Dependency Agent"\Uninstall_v.w.x.y.exe` (where v.w.x.y is the version number).

+### Manually uninstall Dependency Agent on Linux

+1. Sign in on the computer with a user account that has sudo privileges to execute commands as root.

+1. Run the following command:

+ ```bash

+ sudo /opt/microsoft/dependency-agent/uninstall -s

+ ```

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

+If you want to stop monitoring your VMs for a while or remove VM Insights entirely, see [Disable monitoring of your VMs in VM Insights](../vm/vminsights-optout.md).

+These tunables define the starting point where the Linux write-back mechanism begins flushing dirty blocks to stable storage. Redhat defaults to 10% of physical memory, which, on a large memory system, is a significant amount of data to start flushing. With SAS GRID as an example, historically the recommendation was to set `vm.dirty_background` to 1/5 size of `vm.dirty_ratio` or `vm.dirty_bytes`. Considering how aggressively the `vm.dirty_bytes` setting is set for SAS GRID, no specific value is being set here.

+This tunable defines how old a dirty buffer can be before it must be tagged for asynchronously writing out. Take SAS ViyaΓÇÖs CAS workload for example. An ephemeral write-dominant workload found that setting this value to 300 centiseconds (3 seconds) was optimal, with 3000 centiseconds (30 seconds) being the default.

+SAS Viya shares CAS data into multiple small chunks of a few megabytes each. Rather than closing these file handles after writing data to each shard, the handles are left open and the buffers within are memory-mapped by the application. Without a close, there's no flush until the passage of either memory pressure or 30 seconds. Waiting for memory pressure proved suboptimal as did waiting for a long timer to expire. Unlike SAS GRID, which looked for the best overall throughput, SAS Viya looked to optimize write bandwidth.

+When you consider the default virtual memory tunables and the amount of RAM in modern systems, write-back potentially slows down other storage-bound operations from the perspective of the specific client driving this mixed workload. The following symptoms can be expected from an untuned, write-heavy, cache-laden Linux machine.

+```

+# while true; do echo "###" ;date ; egrep "^Cached:|^Dirty:|^Writeback:|file" /proc/meminfo; sleep 5; done`

+```

+You can delete snapshots that you no longer need.

+> You can't undo the snapshot deletion. You can't recover a deleted snapshot.

+* You can't delete a snapshot if it's part of an active file-restore operation or if it's in the process of being cloned.

+1. Go to the **Snapshots** menu of a volume. Select the three dots at the end of the row of the snapshot want to delete. Select **Delete**.

+ 

+2. In the Delete Snapshot window, confirm that you want to delete the snapshot by selecting **Yes**.

+ 

+* [Azure NetApp Files snapshot overview](https://anfcommunity.com/2021/01/31/azure-netapp-files-snapshot-overview/)

+ Cross-zone replication is available in all [AZ-enabled regions](../reliability/availability-zones-service-support.md) with [Azure NetApp Files presence](https://azure.microsoft.com/explore/global-infrastructure/products-by-region/?products=netapp&regions=all&rar=true).

+* [Azure Application Consistent Snapshot tool (AzAcSnap) 8](azacsnap-introduction.md) is now generally available (GA)

+ You might sometimes encounter stale file locks on NFS, SMB, or dual-protocol volumes that need to be cleared. With this new Azure NetApp Files feature, you can now break these locks. You can break file locks for all files in a volume or break all file locks initiated by a specified client.

+ Azure NetApp Files provides ways to quickly restore data from snapshots (mainly at the volume level). See [How Azure NetApp Files snapshots work](snapshots-introduction.md). Options for user file self-restore are available via client-side data copy from the `~snapshot` (Windows) or `.snapshot` (Linux) folders. These operations require data (files and directories) to traverse the network twice (upon read and write). As such, the operations aren't time and resource efficient, especially with large data sets. If you don't want to restore the entire snapshot to a new volume, revert a volume, or copy large files across the network, you can use the single-file snapshot restore feature to restore individual files directly on the service from a volume snapshot without requiring data copy via an external client. This approach drastically reduces recovery time objective (RTO) and network resource usage when restoring large files.

+ Azure NetApp Files online snapshots now support backup of snapshots. With this new backup capability, you can vault your Azure NetApp Files snapshots to cost-efficient and zone redundant Azure storage in a fast and cost-effective way. This approach further protects your data from accidental deletion.

+ Azure NetApp Files now supports AES encryption on LDAP connections to domain controllers (DC) to enable AES encryption for an SMB volume. This feature is currently in preview.

+## Use deployment stacks

+Learn how to manage resource lifecycles with deployment stacks.

+ [<img src="media/learn-bicep/manage-resource-lifecycles-deployment-stacks.svg" width="101" height="120" alt="The trophy for the Manage resource lifecycles with deployment stacks." role="presentation"></img>](/training/modules/manage-resource-lifecycles-deployment-stacks/)

+

+ [Manage resource lifecycles with deployment stacks](/training/modules/manage-resource-lifecycles-deployment-stacks)

+This article describes how to update resources that are deployed as part of a managed application. As the publisher of a managed application, you have management access to resources in the managed resource group in the customer's Azure tenant. To update these resources, you need to sign in to the customer's subscription, find the managed resource group associated with a managed application, and access the resources in the managed resource group. For more information about permissions, see [Publisher and customer permissions](./overview.md#publisher-and-customer-permissions).

+To get the managed applications in a resource group, use the following commands. Replace `<resourceGroupName>` with your resource group name.

+az managedapp list --query "[?contains(resourceGroup,'<resourceGroupName>')]"

+az managedapp list --query "[?contains(resourceGroup,'<resourceGroupName>')].{ managedResourceGroup:managedResourceGroupId }"

+To see the virtual machines in the managed resource group, provide the name of the managed resource group. Replace `<mrgName>` with your managed resource group's name.

+az vm list -g <mrgName> --query "[].{VMName:name,OSType:storageProfile.osDisk.osType,VMSize:hardwareProfile.vmSize}"

+az vm resize --size Standard_D2_v2 --ids $(az vm list -g <mrgName> --query "[].id" -o tsv)

+Get the managed resource group and assign a policy at that scope. The policy **e56962a6-4747-49cd-b67b-bf8b01975c4c** is a built-in policy to specify allowed locations.

+managedGroup=$(az managedapp show --name <app-name> --resource-group <resourceGroupName> --query managedResourceGroupId --output tsv)

+- For an introduction to managed applications, see [Azure Managed Applications overview](overview.md).

+You can move App Service resources to a new resource group or subscription but you need to delete and upload its TLS/SSL certificates to the new resource group or subscription. Also, you can't move a free App Service managed certificate. For that scenario, see [Move with free managed certificates](#move-with-free-managed-certificates).

+ :::image type="content" source="./media/cdn-custom-ssl/cdn-select-custom-domain-endpoint.png" alt-text="Screenshot of endpoints list.":::

+ :::image type="content" source="./media/cdn-custom-ssl/cdn-custom-domain.png" alt-text="Screenshot of the custom domain page with the option to use my own certificate.":::

+ :::image type="content" source="./media/cdn-custom-ssl/cdn-select-cdn-managed-certificate.png" alt-text="Screen shot of the custom domain HTTPS status.":::

+ :::image type="content" source="./media/cdn-custom-ssl/cdn-custom-domain-certificate-deployed.png" alt-text="Screenshot of the custom domains list.":::

+ :::image type="content" source="./media/cdn-custom-ssl/cdn-disable-custom-ssl.png" alt-text="Screenshot of the custom HTTPS dialog.":::

+After the custom domain HTTPS feature is disabled, it can take up to 6-8 hours for it to take effect. When the process is complete, the custom HTTPS status in the Azure portal is changed to **Disabled**. Your custom domain can no longer use HTTPS.

+ > 1. Paths must be specified for purge and must be a relative URL that fit the following [RFC 3986 - Uniform Resource Identifier (URI): Generic Syntax](https://datatracker.ietf.org/doc/html/rfc3986#section-3.3).

+ ```

+ The resource action 'Microsoft.Storage/storageAccounts/write' is disallowed by

+ one or more policies.

+ ```

+ - `*.servicebus.usgovcloudapi.net` for Azure Government Cloud

+### Failed to request a terminal - Accessing Cloud Shell from a network that uses a private DNS resolver

+ Cloud Shell session from a host in a network that has a private DNS Zone for the servicebus

+ domain. This error can also occur if you're using a private on-premises DNS server.

+- **Resolution**: You can add a DNS record for the Azure Relay instance that Cloud Shell uses.

+ `ccon-prod-<region-name>-aci-XX.servicebus.windows.net`. For Azure Government Cloud, the

+ hostname ends with `servicebus.usgovcloudapi.net`.

+ For information about accessing the Developer Tools in other browsers, see

+ [Capture a browser trace for troubleshooting][03].

+ Address: 168.63.129.16

+ 1. Add an A record for the public IP in the Private DNS Zone of your private network. For this

+ > [!NOTE]

+ > This IP address is subject to change periodically. You might need to repeat this process to

+ > discover the new IP address.

+ Alternately, you can deploy your own private Cloud Shell instance. For more information, see

+ [Deploy Cloud Shell in a virtual network][01].

+[03]: /azure/azure-portal/capture-browser-trace

+The Android ecosystem is extensive, encompassing various versions and specialized platforms designed for diverse types of devices. The next table lists the Android platforms currently supported:

+ },

+ "videoConfiguration": {

+ "longerSideLength": <number>, // longerSideLength for video recording

+ "shorterSideLength": <number>, // shorterSideLength for video recording

+ "frameRate": <number>, // frameRate for video recording

+ "bitRate": <number> // bitrate for video recording

+This article includes examples of the ARM and YAML configurations for frequently used Container Apps resources. For a complete list of Container Apps resources see [Azure Resource Manager templates for Container Apps](/azure/templates/microsoft.app/containerapps?pivots=deployment-language-arm-template). The code listed in this article is for example purposes only. For full schema and type information, see the JSON definitions for your required API version.

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

+ export RESOURCE_GROUP=my-resource-group

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

+Use the following steps to create each of the resources necessary to create a container app.

+1. Search for **Container Apps** in the Azure portal and select **Create**.

+1. Enter the following values to *Basics* tab.

+ | Property | Value |

+ |||

+ | **Subscription** | Select your Azure subscription. |

+ | **Resource group** | Select **Create new** link to create a new resource group named **my-resource-group**. |

+ | **Container app name** | Enter **sample-admin-client**. |

+ | **Deployment source** | Select **Container image**. |

+ | **Region** | Select the region nearest you. |

+ | **Container Apps environment** | Select the **Create new** link to create a new environment. |

+1. In the *Create Container Apps environment* window, enter the following values.

+ | Property | Value |

+ |||

+ | **Environment name** | Enter **my-environment**. |

+ | **Zone redundancy** | Select **Disabled**. |

+

+ Select the **Create** button, and then select the **Container** tab.

+

+1. In *Container* tab, enter the following values.

+ | Property | Value |

+ |||

+ | **Name** | Enter **sample-admin-client**. |

+ | **Image source** | Select **Docker Hub or other registries**. |

+ | **Image type** | Select **Public**. |

+ | **Registry login server** | Enter **mcr.microsoft.com**. |

+ | **Image and tag** | Enter **javacomponents/samples/sample-admin-for-spring-client:latest**. |

+

+ Select the **Ingress** tab.

+1. In *Ingress* tab, enter the following and leave the rest of the form with their default values.

+ | Property | Value |

+ |||

+ | **Ingress** | Select **Enabled**. |

+ | **Ingress traffic** | Select **Accept traffic from anywhere**. |

+ | **Ingress type** | Select **HTTP**. |

+ | **Target port** | Enter **8080**. |

+

+ Select **Review + create**.

+1. Once the validation checks pass, select **Create** to create your container app.

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

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

+Now that you have an existing environment and admin client container app, you can create a Java component instance of Admin for Spring.

+1. Go to your container app's environment in the portal.

+1. From the left menu, under *Services* category, select **Services**.

+1. Select **+ Configure** drop down, and select **Java component**.

+1. In the *Configure Java component* panel, enter the following values.

+ | Property | Value |

+ |||

+ | **Java component type** | Select **Admin for Spring**. |

+ | **Java component name** | Enter **admin**. |

+1. Select **Next**.

+1. On the *Review* tab, select **Configure**.

+## Bind your container app to the Admin for Spring Java component

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

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

+1. Go to your container app environment in the portal.

+1. From the left menu, under *Services* category, select **Services**.

+1. From the list, select **admin**.

+1. Under *Bindings*, select the *App name* drop-down and select **sample-admin-client**.

+1. Select the **Review** tab.

+1. Select the **Configure** button.

+1. Return to your container app in the portal and copy the URL of your app to a text editor so you can use it in a coming step.

+The bind operation binds the container app to the Admin for Spring Java component. The container app can now read the configuration values from environment variables, primarily the `SPRING_BOOT_ADMIN_CLIENT_URL` property and connect to the Admin for Spring.

+The binding also injects the following property:

+```bash

+"SPRING_BOOT_ADMIN_CLIENT_INSTANCE_PREFER-IP": "true",

+```

+This property indicates that the Admin for Spring component client should prefer the IP address of the container app instance when connecting to the Admin for Spring server.

+## (Optional) Unbind your container app from the Admin for Spring Java component

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

+To remove a binding from a container app, use the `--unbind` option.

+``` azurecli

+ az containerapp update \

+ --name $APP_NAME \

+ --unbind $JAVA_COMPONENT_NAME \

+ --resource-group $RESOURCE_GROUP

+```

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

+1. Go to your container app environment in the portal.

+1. From the left menu, under *Services* category, select **Services**.

+1. From the list, select **admin**.

+1. Under *Bindings*, find the line for *sample-admin-client* select and select **Delete**.

+1. Select **Next**.

+1. Select the **Review** tab.

+1. Select the **Configure** button.

+## (Optional) Unbind your container app from the Config Server for Spring Java component

+ | **Name** | Enter **my-eureka-client**. |

+## (Optional) Unbind your container app from the Eureka Server for Spring Java component

+| [Launch Your First Java app](https://github.com/spring-projects/spring-petclinic) |A monolithic Java application called PetClinic built with Spring Framework. PetClinic is a well-known sample application provided by the Spring Framework community. |

+When you purchase a reservation, the Azure OpenAI provisioned throughput usage that matches the reservation attributes is no longer charged at the hourly rates.

+When the reservation expires, Azure OpenAI deployments continue to run but are billed at the hourly rate.

+For example, assume that your total consumption of provisioned throughput units is 100 units. You want to purchase a reservation for all of it, so you should purchase 100 of reservation quantity.

+For example, if your usage is for product **SUSE for SAP Linux Enterprise Server** **- 2-4 vCPU VM Support**, you should purchase **SUSE for SAP Linux Enterprise Server** for **2-4 vCPU**.

+### SUSE for SAP Linux Enterprise Server

+|SUSE for SAP Linux Enterprise Server 1-2 vCPUs|797618eb-cecb-59e7-a10e-1ee1e4e62d32|1|D2s_v3|

+|SUSE for SAP Linux Enterprise Server 3-4 vCPUs |1c0fb48a-e518-53c2-ab56-6feddadbb9a3|2|D4s_v3|

+|SUSE for SAP Linux Enterprise Server 5+ vCPUs |3ce5649c-142b-5a59-9b2a-6889da9b56f5|2.41176|D8s_v3|

+## Connectors that is deprecated

+- [Amazon Marketplace Web Service](connector-amazon-marketplace-web-service.md)

+`azd` works with ADE to enable you to create environments from where you're working.

+When `platform.type` is set to `devcenter`, all AZD remote environment state and provisioning uses dev center components. AZD uses one of the infrastructure templates defined in your dev center catalog for resource provisioning. In this configuration, the *infra* folder in your local templates isn't used.

+ - Platform engineers can follow these steps to configure Microsoft Dev Box: [Quickstart: Configure Microsoft Dev Box](quickstart-configure-dev-box-service.md).

+1. Select **New** > **New dev box**.

+

+ > [!Note]

+ > If you encounter a vCPU quota error with a *QuotaExceeded* message, ask your administrator to [request an increased quota limit](/azure/dev-box/how-to-request-quota-increase). If your admin can't increase the quota limit at this time, try selecting another pool with a region close to your location.

+The following example creates an A record called *www* in the zone *contoso.com* in the resource group *MyResourceGroup*. The IP address of the A record is *203.0.113.11*.

+az network dns record-set a add-record --resource-group myresourcegroup --zone-name contoso.com --record-set-name www --ipv4-address 203.0.113.11

+az network dns record-set a add-record --resource-group myresourcegroup --zone-name contoso.com --record-set-name "@" --ipv4-address 203.0.113.11

+az network dns record-set aaaa add-record --resource-group myresourcegroup --zone-name contoso.com --record-set-name test-aaaa --ipv6-address FD00::1

+az network dns record-set ns add-record --resource-group myresourcegroup --zone-name contoso.com --record-set-name test-ns --nsdname ns1.fabrikam.com

+The following example deletes the A record with value '203.0.113.11' from the record set named *www* in the zone *contoso.com*, in the resource group *MyResourceGroup*.

+az network dns record-set a remove-record --resource-group myresourcegroup --zone-name contoso.com --record-set-name "www" --ipv4-address 203.0.113.11

+The following example shows how to modify an 'A' record, from IP address 203.0.113.11 to IP address 203.0.113.22:

+az network dns record-set a add-record --resource-group myresourcegroup --zone-name contoso.com --record-set-name www --ipv4-address 203.0.113.22

+az network dns record-set a remove-record --resource-group myresourcegroup --zone-name contoso.com --record-set-name www --ipv4-address 203.0.113.11

+az network dns record-set ns add-record --resource-group myresourcegroup --zone-name contoso.com --record-set-name "@" --nsdname ns1.fabrikam.com

+* **FIXED** values: This set of reference values is universally recognized and used across OSDU deployments and the energy sector. These values can't be extended or changed except by OSDU community governance updates

+* **OPEN** values: The OSDU community provides an initial list of OPEN values upon which you can extend but not otherwise change

+* **LOCAL** values: The OSDU community provides an initial list of LOCAL values that you can freely change, extend, or entirely replace

+Currently, Azure Data Manager for Energy syncs reference data values at instance creation and at new partition creation for newly created instances after feature enablement. Reference values are synced to those from the OSDU community, corresponding to the OSDU milestone supported by Azure Data Manager for Energy at the time of instance or partition creation. For information on the current milestone supported by and available OSDU service in Azure Data Manager for Energy, refer [OSDU services available in Azure Data Manager for Energy](osdu-services-on-adme.md).

+> [!NOTE]

+> To enable private endpoint, public access must be disabled for Azure Data Manager for Energy. If public access is enabled and private endpoint is created, the instance will only be accessed via private endpoint and not by public access.

+# OSDU&reg; M23 services available on Azure Data Manager for Energy

+Azure Data Manager for Energy is currently compliant with the M23 OSDU® milestone release. Below you'll find an overview of the OSDU&reg; services that are currently available on Azure Data Manager for Energy. This page will be regularly updated as service versions and availability evolve.

+- **Secret (Preview)**: Facilitates the storage and retrieval of various types of secrets in a specified repository(ies) so that secrets can be secure, separated from the secrets in the infrastructure repository, and be managed easily by interfacing applications.

+- **Manifest Ingestion DAG**: Used for ingesting single or multiple metadata artifacts about datasets in Azure Data Manager for Energy instance. Learn more about [Manifest-based ingestion](concepts-manifest-ingestion.md).

+- **CSV Parser DAG**: Helps in parsing CSV files into a format for ingestion and processing.

+- **Reservoir DDMS**

+- **Seismic DDMS v4 APIs**

+- **Rock and Fluid Sample DDMS**

+- **Production DDMS - Historian**

+- **WITSML Parser DAG**

+- **Energistcs Parser DAG (WITSML Parser v2, Resqml Parser, ProdML Parser)**

+- **Geospatial Consumption Zone**

+- **Schema Upgrade**

+- **Wellbore Domain Services Worker**

+## August 2024

+### Compliant with M23 OSDU&reg; release

+Azure Data Manager for Energy has now been upgraded with the supported set of services with the M23 OSDU&reg; milestone release. With this release, you can take advantage of the key improvements made in the OSDU&reg; latest

+ community features and capabilities available in the [OSDU&reg; M23](https://community.opengroup.org/osdu/governance/project-management-committee/-/wikis/M23-Release-Notes) The upgrade with the OSDU&reg; M23 release is limited to the services available and supported and you can refer [here](osdu-services-on-adme.md) for a detailed list of services available and unavailable on Azure Data Manager for Energy. See the [updated API Swaggers here](https://microsoft.github.io/adme-samples/).

+### Syncing Reference Values

+We are releasing a Limited Preview for syncing Reference Values with your Azure Data Manager for Energy data partitions. Note that this feature is currently only available for newly created Azure Data Manager for Energy after feature enablement for your Azure subscription. Learn more about [Reference Values on Azure Data Manager for Energy](concepts-reference-data-values.md).

+## Endpoint validation with CloudEvents v1.0

+CloudEvents v1.0 implements its own abuse protection semantics using the **HTTP OPTIONS** method. You can read more about it [here](https://github.com/cloudevents/spec/blob/v1.0/http-webhook.md#4-abuse-protection). When you use the CloudEvents schema for output, Event Grid uses the CloudEvents v1.0 abuse protection in place of the Event Grid validation event mechanism.

+- **Asynchronous handshake**: In certain cases, you can't return the `validationCode` in response synchronously. For example, if you use a non-Microsoft service (like [`Zapier`](https://zapier.com) or [IFTTT](https://ifttt.com/)), you can't programmatically respond with the validation code.

+- The Event Grid data plane SDKs have classes corresponding to the subscription validation event data and subscription validation response.

+- You must return an **HTTP 200 OK** response status code. **HTTP 202 Accepted** isn't recognized as a valid Event Grid subscription validation response. The HTTP request must complete within 30 seconds. If the operation doesn't finish within 30 seconds, then the operation will be canceled and it's reattempted after 5 seconds. If all the attempts fail, then it's treated as validation handshake error.

+ automatically created with an ID that is the Microsoft Entra ID. For all other

+The Azure Policy remediation task feature is used to bring resources into compliance established from a definition and assignment. Resources that are non-compliant to a [modify](./effect-modify.md) or [deployIfNotExists](./effect-deploy-if-not-exists.md) definition assignment, can be brought into compliance using a remediation task. A remediation task deploys the `deployIfNotExists` template or the `modify` operations to the selected non-compliant resources using the identity specified in the assignment. For more information, see [policy assignment structure](./assignment-structure.md#identity) to understand how the identity is defined and [remediate non-compliant resources tutorial](../how-to/remediate-resources.md#configure-the-managed-identity) to configure the identity.

+Remediation tasks remediate existing resources that aren't compliant. Resources that are newly created or updated that are applicable to a `deployIfNotExists` or `modify` definition assignment are automatically remediated.

+> The Azure Policy service deletes remediation task resources 60 days after their last modification.

+For example, the following JSON shows a policy remediation task for policy definition named `requiredTags` a part of an initiative assignment named `resourceShouldBeCompliantInit` with all default settings.

+ "id": "/subscriptions/{subId}/resourceGroups/ExemptRG/providers/Microsoft.PolicyInsights/remediations/remediateNotCompliant",

+ "apiVersion": "2021-10-01",

+ "name": "remediateNotCompliant",

+ "type": "Microsoft.PolicyInsights/remediations",

+ "properties": {

+ "policyAssignmentId": "/subscriptions/{mySubscriptionID}/providers/Microsoft.Authorization/policyAssignments/resourceShouldBeCompliantInit",

+ "policyDefinitionReferenceId": "requiredTags",

+ "resourceCount": 42,

+ "parallelDeployments": 6,

+ "failureThreshold": {

+ "percentage": 0.1

+ }

+Steps on how to trigger a remediation task at [how to remediate non-compliant resources guide](../how-to/remediate-resources.md). These settings can't be changed after the remediation task begins.

+You use `displayName` and `description` to identify the policy remediation task and provide context for its use. `displayName` has a maximum length of _128_ characters and `description` a maximum length of _512_ characters.

+This field must be the full path name of either a policy assignment or an initiative assignment. `policyAssignmentId` is a string and not an array. This property defines which assignment the parent resource hierarchy or individual resource to remediate.

+If the `policyAssignmentId` is for an initiative assignment, the `policyDefinitionReferenceId` property must be used to specify which policy definition in the initiative the subject resources are to be remediated. As a remediation can only remediate in a scope of one definition, this property is a _string_ and not an array. The value must match the value in the initiative definition in the `policyDefinitions.policyDefinitionReferenceId` field instead of the global identifier for policy definition `Id`.

+Use `resourceCount` to determine how many non-compliant resources to remediate in a given remediation task. The default value is 500, with the maximum number being 50,000. `parallelDeployments` determines how many of those resources to remediate at the same time. The allowed range is between 1 to 30 with the default value being 10.

+Parallel deployments are the number of deployments within a singular remediation task with a maximum of 30. There can be a maximum of 100 remediation tasks running in parallel for a single policy definition or policy reference within an initiative.

+An optional property used to specify whether the remediation task should fail if the percentage of failures exceeds the given threshold. The `failureThreshold` is represented as a percentage number from 0 to 100. By default, the failure threshold is 100%, meaning that the remediation task continues to remediate other resources even if resources fail to remediate.

+## Remediation filters

+An optional property refines what resources are applicable to the remediation task. The allowed filter is resource location. Unless specified, resources from any region can be remediated.

+This property decides how to discover resources that are eligible for remediation. For a resource to be eligible, it must be non-compliant. By default, this property is set to `ExistingNonCompliant`. It could also be set to `ReEvaluateCompliance`, which triggers a new compliance scan for that assignment and remediate any resources that are found non-compliant.

+Once a remediation task is created, `ProvisioningState` and `DeploymentSummary` properties are populated. The `ProvisioningState` indicates the status of the remediation task. Allow values are `Running`, `Canceled`, `Cancelling`, `Failed`, `Complete`, or `Succeeded`. The `DeploymentSummary` is an array property indicating the number of deployments along with number of successful and failed deployments.

+Sample of remediation task that completed successfully:

+ "id": "/subscriptions/{subId}/resourceGroups/ExemptRG/providers/Microsoft.PolicyInsights/remediations/remediateNotCompliant",

+ "Type": "Microsoft.PolicyInsights/remediations",

+ "Name": "remediateNotCompliant",

+ "PolicyAssignmentId": "/subscriptions/{mySubscriptionID}/providers/Microsoft.Authorization/policyAssignments/resourceShouldBeCompliantInit",

+ "policyDefinitionReferenceId": "requiredTags",

+ "resourceCount": 42,

+ "parallelDeployments": 6,

+ "failureThreshold": {

+ "percentage": 0.1

+ },

+ "ProvisioningState": "Succeeded",

+ "DeploymentSummary": {

+ "TotalDeployments": 42,

+ "SuccessfulDeployments": 42,

+ "FailedDeployments": 0

+ },

+- Learn about the [policy definition structure](./definition-structure-basics.md).

+Additionally, the following nonstandard APIs are supported:

+For information on how to specify the version when making requests, see the [API Versioning Documentation](api-versioning-dicom-service.md).

+| | | -- |

+The parameter `study` corresponds to the DICOM attribute `StudyInstanceUID`. If specified, any instance that doesn't belong to the provided study is rejected with a `43265` warning code.

+The following `Accept` header for the response is supported:

+The following `Content-Type` headers are supported:

+| | -- |

+The response payload populates a DICOM dataset with the following elements.

+| | | -- |

+| (0008, 1190) | `RetrieveURL` | The Retrieve URL of the study, if the `StudyInstanceUID` was provided in the store request and at least one instance is successfully stored |

+| (0008, 1198) | `FailedSOPSequence` | The sequence of instances that failed to store |

+| (0008, 1199) | `ReferencedSOPSequence` | The sequence of stored instances |

+Each dataset in the `FailedSOPSequence` has the following elements (if the DICOM file attempting to be stored could be read).

+| | | -- |

+| (0008, 1150) | `ReferencedSOPClassUID` | The SOP class unique identifier of the instance that failed to store |

+| (0008, 1155) | `ReferencedSOPInstanceUID` | The SOP instance unique identifier of the instance that failed to store |

+| (0008, 1197) | `FailureReason` | The reason code why this instance failed to store |

+| (0074, 1048) | `FailedAttributesSequence` | The sequence of `ErrorComment` that includes the reason for each failed attribute |

+Each dataset in the `ReferencedSOPSequence` has the following elements.

+| | | -- |

+| (0008, 1150) | `ReferencedSOPClassUID` | The SOP class unique identifier of the instance that failed to store |

+| (0008, 1155) | `ReferencedSOPInstanceUID` | The SOP instance unique identifier of the instance that failed to store |

+| (0008, 1190) | `RetrieveURL` | The retrieve URL of this instance on the DICOM server |

+| -- | -- |

+| -- | -- |

+| -- | -- |

+| | -| -- |

+| GET | ../studies/{study} | Retrieves all instances within a study |

+| GET | ../studies/{study}/metadata | Retrieves the metadata for all instances within a study |

+| GET | ../studies/{study}/series/{series} | Retrieves all instances within a series |

+| GET | ../studies/{study}/series/{series}/metadata | Retrieves the metadata for all instances within a series |

+| GET | ../studies/{study}/series/{series}/instances/{instance} | Retrieves a single instance |

+| GET | ../studies/{study}/series/{series}/instances/{instance}/metadata | Retrieves the metadata for a single instance |

+| GET | ../studies/{study}/series/{series}/instances/{instance}/frames/{frames} | Retrieves one or many frames from a single instance; To specify more than one frame, use a comma to separate each frame to return. For example, `/studies/1/series/2/instance/3/frames/4,5,6`. |

+| GET | ../studies/{study}/series/{series}/instances/{instance}/frames/{frame}/rendered | Retrieves a single frame rendered into an image format |

+The following `Accept` headers are supported for retrieving instances within a study or a series.

+The following `Accept` headers are supported for retrieving a specific instance:

+The following `Accept` headers are supported for retrieving frames.

+When the requested transfer syntax is different from original file, the original file is transcoded to the requested transfer syntax. The original file needs to be one of the following formats for transcoding to succeed, otherwise transcoding might fail.

+The following `Accept` header is supported for retrieving metadata for a study, a series, or an instance.

+Retrieving metadata doesn't return attributes with the following value representations.

+* Data is unchanged since the last request: the `HTTP 304 (Not Modified)` response is sent with no response body.

+* Data has changed since the last request: the `HTTP 200 (OK)` response is sent with updated ETag. Required data is also returned as part of the body.

+The following `Accept` headers are supported for retrieving a rendered image an instance or a frame.

+In the case that no `Accept` header is specified, the service renders an `image/jpeg` by default.

+The service only supports rendering of a single frame. If rendering is requested for an instance with multiple frames, then by default only the first frame is rendered as an image.

+The `quality` query parameter is also supported. An integer value from `1` to `100` inclusive (1 being worst quality, and 100 being best quality) might be passed as the value for the query parameter. This parameter is used for images rendered as `jpeg`, and is ignored for `png` render requests. If not specified, the parameter defaults to `100`.

+| - | -- |

+| `304 (Not Modified)` | The requested data hasn't been modified since the last request. In this case, content isn't added to the response body. For more information, see the preceding section **Retrieve Metadata Cache Validation (for Study, Series, or Instance)**. |

+| `404 (Not Found)` | The specified DICOM resource couldn't be found, or for a rendered request the instance didn't contain pixel data. |

+| | | - |

+| *Search for Studies* | | |

+| *Search for Series* | | |

+| *Search for Instances* | | |

+The following `Accept` header is supported for searching:

+The following parameters for each query are supported.

+| Key | Support Values | Allowed Count | Description |

+| | | - | -- |

+| `{attributeID}=` | `{value}` | 0...N | Search for attribute/ value matching in query |

+| `includefield=` | `{attributeID}`<br/>`all` | 0...N | The other attributes to return in the response; Both public and private tags are supported.<br/>When `all` is provided. Refer to [Search Response](#search-response) for more information about which attributes are returned for each query type.<br/>If a mixture of `{attributeID}` and `all` is provided, the server defaults to using `all`. |

+| `limit=` | `{value}` | 0..1 | Integer value to limit the number of values returned in the response; <br/>Value can be between the range 1 >= x <= 200, defaulted to 100. |

+| `offset=` | `{value}` | 0..1 | Skip `{value}` results; <br/>If an offset larger than the number of search query results is provided, a `204 (no content)` response is returned. |

+| `fuzzymatching=` | `true` / `false` | 0..1 | If true fuzzy matching is applied to PatientName attribute; It does a prefix word match of any name part inside PatientName value. For example, if PatientName is "John^Doe", then "joh", "do", "jo do", "Doe" and "John Doe" all match. However, "ohn" doesn't match. |

+| -- | -- | | -- | -- | | -- |

+| -- | - | - |

+| Range Query | `StudyDate`/`PatientBirthDate` | `{attributeID}={value1}-{value2}`. For date/time values, we support an inclusive range on the tag, which is mapped to `attributeID >= {value1} AND attributeID <= {value2}`. If `{value1}` isn't specified, all occurrences of dates/times prior to and including `{value2}` are matched. Likewise, if `{value2}` isn't specified, all occurrences of `{value1}` and subsequent dates/times are matched. However, one of these values has to be present. `{attributeID}={value1}-` and `{attributeID}=-{value2}` are valid, however, `{attributeID}=-` is invalid. |

+Tags can be encoded in several ways for the query parameter. We have partially implemented the standard as defined in [PS3.18 6.7.1.1.1](http://dicom.nema.org/medical/dicom/2019a/output/chtml/part18/sect_6.7.html#sect_6.7.1.1.1). The following encodings for a tag are supported.

+| - | - |

+Here's an example query searching for instances:

+The response is an array of DICOM datasets. Depending on the resource, by *default* the following attributes are returned.

+| | -- |

+| | -- |

+| | -- |

+| | -- |

+| | -- |

+The query API returns one of the following status codes in the response.

+| - | -- |

+| `400 (Bad Request)` | The server was unable to perform the query because the query component was invalid. The response body contains details of the failure. |

+* When the target resource is Study/Series, there's a potential for inconsistent study/series level metadata across multiple instances. For example, two instances could have different patientName. In this case, the latest wins, and you can search only on the latest data.

+* Paged results are optimized to return the matched _newest_ instance first, this might result in duplicate records in subsequent pages if newer data matching the query was added.

+* Matching is _not_ case sensitive, and _not_ accent sensitive for PN VR types.

+* Matching is _not_ case sensitive, and _is_ accent sensitive for other string VR types.

+* Only the first value is indexed if a single valued data element incorrectly has multiple values.

+| | - | -- |

+| DELETE | ../studies/{study} | Delete all instances for a specific study |

+| DELETE | ../studies/{study}/series/{series} | Delete all instances for a specific series within a study |

+| DELETE | ../studies/{study}/series/{series}/instances/{instance} | Delete a specific instance within a series |

+The parameters `study`, `series`, and `instance` correspond to the DICOM attributes `StudyInstanceUID`, `SeriesInstanceUID`, and `SopInstanceUID` respectively.

+| - | -- |

+| `204 (No Content)` | When all the SOP instances are deleted |

+| `400 (Bad Request)` | The request was badly formatted |

+| `401 (Unauthorized)` | The client isn't authenticated |

+| `403 (Forbidden)` | The user isn't authorized |

+| `404 (Not Found)` | When the specified series wasn't found within a study, or the specified instance wasn't found within the series |

+|- |- |- |

+|POST| {s}/workitems{?AffectedSOPInstanceUID}| Create a work item |

+|POST| {s}/workitems/{instance}{?transaction}| Update a work item |

+|GET| {s}/workitems{?query*} | Search for work items |

+|GET| {s}/workitems/{instance}| Retrieve a work item |

+|PUT| {s}/workitems/{instance}/state| Change work item state |

+|POST| {s}/workitems/{instance}/cancelrequest | Cancel work item |

+|DELETE | {s}/workitems/{instance}/subscribers/{AETitle} | Delete subscription |

+| | | -- |

+| POST | ../workitems | Create a Workitem |

+> Although the reference table says that SOP Instance UID shouldn't be present, this guidance is specific to the DIMSE protocol and is handled differently in DICOMWeb. The SOP Instance UID should be present in the dataset if not in the URI.

+| | -- |

+There are [four valid Workitem states](https://dicom.nema.org/medical/dicom/current/output/html/part04.html#table_CC.1.1-1).

+This transaction only succeeds against Workitems in the `SCHEDULED` state. Any user can claim ownership of a Workitem by setting its Transaction UID and changing its state to `IN PROGRESS`. From then on, a user can only modify the Workitem by providing the correct Transaction UID. While UPS defines Watch and Event SOP classes that allow cancellation requests and other events to be forwarded, this DICOM service doesn't implement these classes, and so cancellation requests on workitems that are `IN PROGRESS` return a failure. An owned Workitem can be canceled via the [Change Workitem State](#change-workitem-state) transaction.

+| - | -- | |

+| - | -- |

+If the Workitem exists on the origin server, the Workitem is returned in an Acceptable Media Type. The returned Workitem won't contain the Transaction UID (0008,1195) Attribute. This is necessary to preserve the attribute's role as an access lock.

+| - | -- | - |

+| -- | -- |

+| 200 (OK) | Workitem Instance was successfully retrieved. |

+| 400 (Bad Request) | There was a problem with the request. |

+| 401 (Unauthorized) | The client isn't authenticated. |

+| 403 (Forbidden) | The user isn't authorized. |

+| 404 (Not Found) | The Target Workitem wasn't found. |

+* The returned Workitem won't contain the Transaction UID (0008, 1195) attribute of the Workitem, since that should only be known to the Owner.

+To update a Workitem currently in the `SCHEDULED` state, the `Transaction UID` attribute shouldn't be present. For a Workitem in the `IN PROGRESS` state, the request must include the current Transaction UID as a query parameter. If the Workitem is already in the `COMPLETED` or `CANCELED` states, the response is `400 (Bad Request)`.

+| - | - | |

+| -- | -- |

+| `400 (Bad Request)` | There was a problem with the request. For example: (1) The Target Workitem was in the `COMPLETED` or `CANCELED` state. (2) The Transaction UID is missing. (3) The Transaction UID is incorrect. (4) The dataset didn't conform to the requirements. |

+The origin server supports header fields as required in [Table 11.6.3-2](https://dicom.nema.org/medical/dicom/current/output/html/part18.html#table_11.6.3-2).

+A success response has either no payload, or a payload containing a Status Report document.

+If the Workitem exists on the origin server, the Workitem is returned in an Acceptable Media Type. The returned Workitem won't contain the Transaction UID (0008,1195) attribute. This is necessary to preserve this Attribute's role as an access lock as described [here.](https://dicom.nema.org/medical/dicom/current/output/html/part04.html#sect_CC.1.1)

+| - | - | |

+The request payload contains the Change UPS State Data Elements. These data elements are:

+* **Transaction UID (0008, 1195)**. The request payload includes a Transaction UID. The user agent creates the Transaction UID when requesting a transition to the `IN PROGRESS` state for a given Workitem. The user agent provides that Transaction UID in subsequent transactions with that Workitem.

+| -- | -- |

+| `200 (OK)` | The Workitem Instance was successfully retrieved. |

+| `400 (Bad Request)` | The request can't be performed for one of the following reasons. (1) The request isn't valid given the current state of the Target Workitem. (2) The Transaction UID is missing. (3) The Transaction UID is incorrect |

+* A success response has no payload.

+| | -- | |

+The following `Accept` header is supported for searching.

+The following parameters for each query are supported.

+| Key | Support Values | Allowed Count | Description |

+| - | -- | - | -- |

+| `{attributeID}=` | `{value}` | 0...N | Search for attribute/ value matching in query |

+| `includefield=` | `{attributeID}`<br/>`all` | 0...N | The other attributes to return in the response; Only top-level attributes can be included - not attributes that are part of sequences. Both public and private tags are supported. When `all` is provided, see [Search Response](#search-response) for more information about which attributes are returned for each query type. If a mixture of `{attributeID}` and `all` is provided, the server defaults to using 'all'. |

+| `limit=` | `{value}` | 0...1 | Integer value to limit the number of values returned in the response; The Value can be between the range `1 >= x <= 200`, defaulted to `100`. |

+| `offset=` | `{value}` | 0...1 | Skip {value} results; If an offset larger than the number of search query results is provided, a `204 (no content)` response is returned. |

+| `fuzzymatching=` | `true` \| `false` | 0...1 | If true fuzzy matching is applied to any attributes with the Person Name (PN) Value Representation (VR); A prefix word match of any name part inside these attributes is performed. For example, if `PatientName` is `John^Doe`, then `joh`, `do`, `jo do`, `Doe` and `John Doe` all match. However `ohn` does **not** match. |

+We support searching on these attributes.

+|-|

+We support these matching types.

+| -- | - | - |

+| Fuzzy Match | `PatientName` | Matches any component of the name that starts with the value |

+Tags can be encoded in many ways for the query parameter. We partially implemented the standard as defined in [PS3.18 6.7.1.1.1](http://dicom.nema.org/medical/dicom/2019a/output/chtml/part18/sect_6.7.html#sect_6.7.1.1.1). The following encodings for a tag are supported.

+| | - |

+| `{group}{element}` | `00100010` |

+* All attributes in [DICOM PowerShell 3.4 Table CC.2.5-3](https://dicom.nema.org/medical/dicom/current/output/html/part04.html#table_CC.2.5-3) with a Return Key Type of 1 or 2.

+* All attributes in [DICOM PowerShell 3.4 Table CC.2.5-3](https://dicom.nema.org/medical/dicom/current/output/html/part04.html#table_CC.2.5-3) with a Return Key Type of 1C for which the conditional requirements are met.

+* All other Workitem attributes passed as match parameters.

+* All other Workitem attributes passed as `includefield` parameter values.

+The query API returns one of the following status codes in the response.

+| | -- |

+The query API doesn't return `413 (request entity too large)`. If the requested query response limit is outside of the acceptable range, a bad request is returned. Anything requested within the acceptable range is resolved.

+* Matching is _not_ case sensitive, and _not_ accent sensitive for PN VR types.

+* Matching is _not_ case sensitive, and _is_ accent sensitive for other string VR types.

+* If there's a scenario where canceling a Workitem and querying the same Workitem happens at the same time, then the query likely excludes the Workitem that's getting updated, and the response code is `206 (Partial Content)`.

+Using the DicomWebClient, we can now store DICOM files.

+Store instances for a specific study demonstrates how to upload a DICOM file into a specified study.

+The variables are used throughout the rest of the examples.

+The series has two instances (green-square and red-triangle), so the response should return metadata for both instances. Validate that the response has a status code of OK and that both instances of the metadata are returned.

+The response should only return the instance red-triangle. Validate that the response has a status code of OK and that the instance is returned.

+The response should only return the metadata for the instance red-triangle. Validate that the response has a status code of OK and that the metadata is returned.

+The response should return the only frame from the red-triangle. Validate that the response has a status code of OK and that the frame is returned.

+Validate that the response includes one study, and that the response code is OK.

+Validate that the response includes one series, and that the response code is OK.

+Validate that the response includes one series, and that the response code is OK.

+Validate that the response includes one instance, and that the response code is OK.

+Validate that the response includes one instance, and that the response code is OK.

+Validate that the response includes one instance, and that the response code is OK.

+This response deletes the red-triangle instance from the server. If it's successful, the response status code contains no content.

+The response deletes the green-square instance from the server (it's the only element left in the series). If it's successful, the response status code contains no content.

+The response deletes the blue-circle instance from the server (it's the only element left in the series). If it's successful, the response status code contains no content.

+After deploying an instance of the DICOM service, retrieve the URL for your App service.

+The cURL commands each contain at least one, and sometimes two, variables that must be replaced. To simplify running the commands, search and replace the following variables your specific values.

+ * Ensure using forward slashes as separators and end the directory _without_ a trailing forward slash.

+Some programming languages and tools behave differently. For instance, some require you to define your own boundary. For those tools, you might need to use a slightly modified Content-Type header. The following tools can be used successfully.

+Some programming languages and tools behave differently. For instance, some require you to define your own boundary. For those languages and tools, you might need to use a slightly modified Content-Type header. The following tools can be used successfully.

+Some programming languages and tools behave differently. For instance, some require you to define your own boundary. For those tools, you might need to use a slightly modified Content-Type header. The following tools can be used successfully.

+Some programming languages and tools behave differently. For instance, some require you to define your own boundary. For those languages and tools, you might need to use a slightly modified Content-Type header. The following tools can be used successfully.

+> This is a non-standard API that allows the upsert of a single DICOM file.

+Use this method to upload a single DICOM file.

+This request retrieves one or more frames from a single instance, and returns them as a collection of multipart/related bytes. Multiple frames can be retrieved by passing a comma-separated list of frame numbers. All DICOM instances with images have at minimum one frame, which is often simply the image associated with the instance itself.

+> Each of these files represents a single instance and is part of the same study. Also, the green-square and red-triangle are part of the same series, while the blue-circle is in a separate series.

+`DefaultAzureCredential` allows us to use various ways to get tokens to log into the service. In this example, use the `AzureCliCredential` to get a token to log into the service. There are other credential providers such as `ManagedIdentityCredential` and `EnvironmentCredential` that you may use. To use the AzureCliCredential, you need to sign in to Azure from the CLI before running this code. For more information, see [Get access token for the DICOM service using Azure CLI](dicom-get-access-token-azure-cli.md). Alternatively, copy and paste the token retrieved while signing in from the CLI.

+> `DefaultAzureCredential` returns several different Credential objects. We reference the `AzureCliCredential` as the 5th item in the returned collection. This may not always be the case. If not, uncomment the `print(credential.credential)` line. This will list all the items. Find the correct index, recalling that Python uses zero-based indexing.

+`encode_multipart_related` takes a set of fields (in the DICOM case, these libraries are generally Part 10 dam files) and an optional user-defined boundary. It returns both the full body, along with the content_type, which can be used.

+This example demonstrates how to upload a single DICOM file, and it uses Python to preload the DICOM file into memory as bytes. When an array of files is passed to the fields parameter `encode_multipart_related`, multiple files can be uploaded in a single POST. It's sometimes used to upload several instances inside a complete series or study.

+This example demonstrates how to upload multiple DICOM files into the specified study. It uses Python to preload the DICOM file into memory as bytes.

+When an array of files is passed to the fields parameter `encode_multipart_related`, multiple files can be uploaded in a single POST. It's sometimes used to upload a complete series or study.

+All three of the dcm files that uploaded previously are part of the same study, so the response should return all three instances. Validate that the response has a status code of OK and that all three instances are returned.

+The instances are retrieved as binary bytes. You can loop through the returned items and convert the bytes into a file that `pydicom` can read as follows.

+This series has two instances (green-square and red-triangle), so the response should return for both instances. Validate that the response has a status code of OK and that the metadata of both instances are returned.

+Refer to the [DICOM Conformance Statement](dicom-services-conformance-statement-v2.md#supported-search-parameters) for supported DICOM attributes.

+A 204 response code is returned when the deletion is successful. A 404 response code is returned if the items never existed or are already deleted.

+This request deletes the red-triangle instance from the server. If successful, the response status code contains no content.

+This code example deletes the green-square instance from the server (it's the only element left in the series). If successful, the response status code doesn't delete content.

+The DICOM&reg; service allows you to store, review, search, and delete DICOM objects by using a subset of DICOMweb APIs. The DICOMweb APIs are web-based services that follow the DICOM standard. Using these APIs, you can access and manage your organization's DICOM data without requiring complex protocols or formats.

+Refer to the language-specific examples. You can view Postman collection examples in several languages including the following.

+One important caution with Postman and the DICOMweb standard is that Postman only supports uploading DICOM files by using the single-part payload defined in the DICOM standard. This is because Postman can't support custom separators in a multipart/related POST request. For more information, see [Multipart POST not working for me # 576](https://github.com/postmanlabs/postman-app-support/issues/576). All examples in the Postman collection for uploading DICOM documents by using a multipart request are prefixed with **[won't work - see description]**. The examples for uploading by using a single-part request are included in the collection and are prefixed with **Store-Single-Instance**.

+In this article, you'll learn how to enable diagnostic logging in DICOM&reg; service and be able to review some sample queries for these logs. Access to diagnostic logs is essential for any healthcare service where compliance with regulatory requirements is required. The feature in DICOM service that enables diagnostic logs is the [Diagnostic settings](../../azure-monitor/essentials/diagnostic-settings.md) in the Azure portal.

+ [](media/dicom-activity-log.png#lightbox)

+ [](media/add-diagnostic-settings.png#lightbox)

+ [](media/configure-diagnostic-settings.png#lightbox)

+5. Select the **Category** and **Destination** details for accessing the diagnostic logs:

+ * **Archive to a storage account** for auditing or manual inspection. The storage account you want to use needs to already be created.

+ * **Send to partner solution** that you're working with as a partner organization in Azure. For information about potential partner integrations, see [Azure partner solutions documentation](../../partner-solutions/overview.md)

+ > It might take up to 15 minutes for the first Logs to appear in Log Analytics. Also, if the DICOM service is moved from one resource group or subscription to another, update the settings once the move is complete.

+The log schema used differs based on the destination. Log Analytics has a schema that differs from other destinations. Each log type has a different schema.

+The DICOM service returns the following fields in the audit log as seen when streamed outside of Log Analytics.

+| correlationId | String | Correlation ID |

+| operationName | String | Describes the type of operation (for example, Retrieve, Store, Query, etc.) |

+|time | DateTime | Date and time of the event. |

+|resourceId | String | Azure path to the resource. |

+|identity | Dynamic | A generic property bag containing identity information (currently doesn't apply to DICOM). |

+| location | String | The location of the server that processed the request. |

+| uri | String | The request URI. |

+| resultType | String | The available values currently are Started, Succeeded, or Failed. |

+| resultSignature | Int | The HTTP Status Code (for example, 200) |

+| type | String | Type of log (it's always MicrosoftHealthcareApisAuditLog in this case). |

+| level | String | Log level (Informational, Error). |

+The DICOM service returns the following fields in the audit sign-in Log Analytics.

+| CorrelationId | String | Correlation ID |

+| OperationName | String | Describes the type of operation (for example, Retrieve, Store, Query, etc.) |

+| TimeGenerated [UTC] | DateTime | Date and time of the event. |

+| _ResourceId | String | Azure path to the resource. |

+| Identity | Dynamic | A generic property bag containing identity information (currently doesn't apply to DICOM). |

+| Uri | String | The request URI. |

+| ResultType | String | The available values currently are Started, Succeeded, or Failed. |

+| StatusCode | Int | The HTTP Status Code (for example, 200) |

+| Type|String | Type of log (it's always AHDSDicomAuditLogs in this case). |

+| Level | String | Log level (Informational, Error). |

+| TenantId | String | Tenant ID. |

+The DICOM service returns the following fields in the audit log as seen when streamed outside of Log Analytics.

+| correlationId | String | Correlation ID |

+| operationName | String | Describes the type of operation (for example, Retrieve, Store, Query, etc.) |

+| time | DateTime | Date and time of the event. |

+| resultDescription | String | Description of the log entry. An example is a diagnostic log with a validation warning message when storing a file. |

+| resourceId | String | Azure path to the resource. |

+| identity | Dynamic | A generic property bag containing identity information (currently doesn't apply to DICOM). |

+| location | String | The location of the server that processed the request. |

+| properties | String | Additional information about the event in JSON array format. Examples include DICOM identifiers present in the request. |

+| level | String | Log level (Informational, Error). |

+The DICOM service returns the following fields in the audit sign-in Log Analytics.

+| CorrelationId | String | Correlation ID |

+| OperationName | String | Describes the type of operation (for example, Retrieve, Store, Query, etc.) |

+| TimeGenerated | DateTime | Date and time of the event. |

+| Message | String | Description of the log entry. An example is a diagnostic log with a validation warning message when storing a file. |

+| Location | String | The location of the server that processed the request. |

+| Properties | String | Additional information about the event in JSON array format. Examples include DICOM identifiers present in the request. |

+| LogLevel | String | Log level (Informational, Error). |

+1. In the Azure portal, browse to the DICOM service that you want to export from, and select **Identity**.

+Given a *source*, the set of data to be exported, and a *destination* (the location to which data is exported), the endpoint returns a reference to a new, long-running export operation. The duration of this operation depends on the volume of data to be exported. For more information about monitoring progress of export operations, see the [Operation status](#operation-status) section.

+Any errors encountered while attempting to export are recorded in an error log. For more information, see the [Errors](#errors) section.

+| -- | -- | - | -- |

+| -- | -- | - | -- |

+The export API returns a `202` status code when an export operation is started successfully. The body of the response contains a reference to the operation. The value of the `Location` header is the URL for the export operation's status (the same as `href` in the body).

+If there are any user errors exporting a DICOM file, the file is skipped and its corresponding error is logged. This error log is also exported alongside the DICOM files, and the caller can review it. You can find the error log at `<export blob container uri>/<operation ID>/errors.log`.

+Each line of the error log is a JSON object with the following properties. A given error identifier might appear multiple times in the log, as each update to the log is processed *at least once*.

+To use the DICOM&reg; service, users and applications need to prove their identity and permissions by getting an access token. An access token is a string that identifies a user or an application, and grants them permission to access a resource. Using access tokens enhances security by preventing unauthorized access and reducing the need for repeated authentication.

+- **DICOM Data Owner**. Gives full access to DICOM data

+- **DICOM Data Reader**. Allows read and search operations on DICOM data

+The DICOM service uses a `resource` or `Audience`, with uniform resource identifier (URI) equal to the URI of the DICOM server `https://dicom.healthcareapis.azure.com`. You can obtain a token and store it in a variable (named `$token`) with the following command.

+* If prompted on first use, install Azure CLI extensions. For more information, see [Use extensions with the Azure CLI](/cli/azure/azure-cli-extensions-overview).

+You can use a token with the DICOM service [using cURL](dicomweb-standard-apis-curl.md). Following is an example.

+This article describes how to get started using DICOM&reg; data in analytics workloads with Azure Data Factory and Microsoft Fabric.

+1. Enter the storage account details by entering the URL to the storage account manually. You can also select the Azure subscription and storage account from the dropdowns.

+If you created the DICOM service with Azure Data Lake Storage, instead of using the template from the template gallery, you need to use a custom template to include a new `fileName` parameter in the metadata pipeline. To configure the pipeline follow these steps.

+Pipelines are scheduled by _triggers_. There are different types of triggers. _Schedule triggers_ allow pipelines to be triggered to run at specific times of the day, such as every hour, or every day at midnight. _Manual triggers_ trigger pipelines on demand, which means they run whenever you want them to.

+Triggers define when a pipeline runs. They also include [parameters](../../data-factory/how-to-use-trigger-parameterization.md) that are passed to the pipeline execution. The **Copy DICOM Metadata Changes to Delta** template defines parameters that are described in the following table. If no value is supplied during configuration, the listed default value is used for each parameter.

+| -- | -- | - |

+ > * `@trigger().outputs.windowStartTime` and

+ > * `@trigger().outputs.windowEndTime`.

+ > * `@trigger().startTime`.

+You can monitor triggered runs and their associated pipeline runs on the **Monitor** tab. Here, you can browse when each pipeline ran and how long it took to run. You can also potentially debug any problems that arose.

+[Fabric](https://www.microsoft.com/microsoft-fabric) is an all-in-one analytics solution that sits on top of [Microsoft OneLake](/fabric/onelake/onelake-overview). With the use of a [Fabric lakehouse](/fabric/data-engineering/lakehouse-overview), you can manage, structure, and analyze data in OneLake in a single location. Any data outside of OneLake, written to Data Lake Storage Gen2, can be connected to OneLake using shortcuts to take advantage of Fabric's suite of tools.

+1. Enter the **Sub Path** that matches the name of the storage container and folder used by the DICOM service. For example, if you wanted to link to the root folder the Sub Path would be **/dicom/AHDS**. The root folder is always `AHDS`, but you can optionally link to a child folder for a specific workspace or DICOM service instance.

+On the notebook page, the contents of the lakehouse can be viewed on the left side, including newly added tables. At the top of the page, select the language for the notebook. The language can also be configured for individual cells. The following example uses Spark SQL.

+After a few seconds, the results of the query appear in a table underneath the cell like the following example shown. The time might be longer if this Spark query is the first in the session because the Spark context needs to be initialized.

+If you used a template to create the pipeline and created a shortcut to the DICOM file data, you can use the `filePath` column in the `instance` table to correlate instance metadata to the file data.

+- **Backup and migration**. For example, your organization might have many DICOM instances stored in local or on-premises systems, which you want to back up or migrate to the cloud for better security, scalability, and availability. Rather than uploading the data one by one, use bulk import to transfer the data faster and more efficiently.

+- **Machine learning development**. For example, your organization might have a large dataset of DICOM instances that you want to use for training machine learning models. With bulk import, you can upload the data to the DICOM service and then access it from [Microsoft Fabric](get-started-with-analytics-dicom.md), [Azure Machine Learning](/azure/machine-learning/overview-what-is-azure-machine-learning), or other tools.

+### Use the Azure portal

+### Use an Azure Resource Manager template

+Following is an example of how to configure bulk import in an ARM template.

+### Grant write access to the import container

+### Upload DICOM images to the import container

+Data is uploaded to Azure Storage containers in many ways.

+To effectively treat patients, research treatments, diagnose illnesses, or get an overview of a patient's health history, organizations need to integrate data across several sources. The DICOM service enables imaging data to persist in the Microsoft cloud and allows it to reside with electronic health records (EHR) and healthcare device (IoT) data in the same Azure subscription.

+- **Image back-up**. Research institutions, clinics, imaging centers, veterinary clinics, pathology institutions, retailers, or other organizations can use the DICOM service to back up their images with unlimited storage and access. There's no need to de-identify PHI data because the service is validated for PHI compliance.

+- **Worklist Service support**. The DICOM service supports the Push and Pull SOPs of the [Worklist Service (UPS-RS)](https://dicom.nema.org/medical/dicom/current/output/html/part18.html#chapter_11). This service provides access to one Worklist containing Workitems, each of which represents a Unified Procedure Step (UPS) Studies Service.

+- **Change feed**. The DICOM service enables you to access ordered, guaranteed, immutable, read-only logs of all changes that occur in the DICOM service. Client applications can read these logs at any time independently, in parallel, and at their own pace.

+- **Export files**. The DICOM service allows you to [export DICOM data](export-dicom-files.md) in a file format, simplifying the process of using medical imaging in external workflows, such as AI and machine learning.

+Your organization needs an Azure subscription to configure and run the components required for the DICOM service. To simplify management, by default the components are created inside an Azure resource group. Additionally, a Microsoft Entra account is required. For each instance of the DICOM service, Microsoft creates a combination of isolated and multitenant resources.

+The Change Feed capability enables you to go through the history of a DICOM&reg; service and act on the create and delete events.

+The following C# code example shows how to consume Change Feed using the DICOM client package.

+* [Medical imaging server for DICOM](https://github.com/microsoft/dicom-server): An open-source version of the Azure Health Data Services DICOM service managed service.

+* [Integrate clinical and imaging data](https://github.com/microsoft/dicom-server/blob/main/docs/concepts/dicom-cast.md): DICOM cast allows synchronizing the data from the DICOM service to the FHIR&reg; service, which allows healthcare organization to integrate clinical and imaging data. DICOM cast expands the use cases for health data by supporting both a streamlined view of longitudinal patient data, and the ability to effectively create cohorts for medical studies, analytics, and machine learning.

+* [Anonymize DICOM metadata](https://github.com/microsoft/Tools-for-Health-Data-Anonymization/blob/master/docs/DICOM-anonymization.md): A DICOM file not only contains a viewable image but also a header with a large variety of data elements. These meta-data elements include identifiable information about the patient, the study, and the institution. Sharing sensitive data demands proper protection to ensure data safety and maintain patient privacy. The DICOM Anonymization Tool helps anonymize metadata in DICOM files for this purpose.

+* [Connect to a FHIR service from Power Query Desktop](/power-query/connectors/fhir/fhir): After provisioning DICOM service, FHIR service, and synchronizing an imaging study for a given patient via DICOM cast, you can use the POWER Query connector for FHIR to import and shape data from the FHIR server including imaging study resources.

+* [FHIR to Synapse Sync Agent](https://github.com/microsoft/FHIR-Analytics-Pipelines/blob/main/FhirToDataLake/docs/Deploy-FhirToDatalake.md): After you provision a DICOM service, FHIR service and synchronizing imaging study for a given patient via DICOM cast, you can use FHIR to Synapse Sync Agent to perform Analytics and Machine Learning on imaging study data by moving FHIR data to Azure Data Lake in near real time, and making it available to a Synapse workspace.

+* [Azure Health Data Services Workshop](https://github.com/microsoft/azure-health-data-services-workshop): This workshop presents a series of hands-on activities to help users gain new skills working with Azure Health Data Services capabilities. The DICOM service challenge includes deployment of the service, exploration of the core API capabilities, a Postman collection to simplify exploration, and instructions for configuring a ZFP DICOM viewer.

+* [Azure DICOM service with OHIF viewer](https://github.com/microsoft/dicom-ohif): The [OHIF viewer](https://ohif.org/) is an open-source, nondiagnostic DICOM viewer that uses DICOMweb APIs to find and render DICOM images. This project provides the guidance and sample templates for deploying the OHIF viewer and configuring it to integrate with the DICOM service.

+* [Medical Imaging Network Demo Environment](https://github.com/Azure-Samples/azure-health-data-services-samples/tree/main/samples/dicom-demo-env#readme): This hands-on lab/demo highlights how an organization with existing on-premises radiology infrastructure can take the first steps to intelligently moving their data to the cloud, without disruptions to the current workflow.

+- You can't delete only the latest version of a study, or revert back to the original version.

+Bulk update is an asynchronous, long-running operation available at a study's endpoint. The request payload includes one or more studies to update, the set of attributes to update, and the new values for those attributes.

+If the operation fails to start successfully, the response includes information about the failure in the errors list, including UIDs of one or more failing instances.

+| 200 (OK) | Operation | The operation with the specified ID is complete. |

+| 202 (Accepted) | Operation | The operation with the specified ID is running. |

+| 404 (Not Found) | | Operation not found |

+The [Retrieve (WADO-RS)](dicom-services-conformance-statement-v2.md#retrieve-wado-rs) transaction allows you to retrieve both the original and latest version of a study, series, or instance. By default, the latest version of a study, series, or instance is returned. The original version is returned by setting the `msdicom-request-original` header to `true`. An example request follows.

+When you perform a bulk update, the DICOM service updates the requested attributes and two additional metadata fields automatically. Following is the information that is updated automatically.

+| Tag | Attribute name | Description | Value |

+| (0002,0013) | Implementation Version Name | Identifies a version for an Implementation Class UID (0002,0012) | Assembly version of the DICOM service (for example, 0.1.4785) |

+The UID `1.3.6.1.4.1.311.129` is a registered under [Microsoft OID arc](https://oidref.com/1.3.6.1.4.1.311) in IANA.

+| Patient ID | (0010,0020) | Primary hospital identification number or code for the patient |

+| Other Patient IDs| (0010,1000) | Other identification numbers or codes used to identify the patient |

+| Type of Patient ID| (0010,0022) | The type of identifier in this item; Enumerated Values: TEXT RFID BARCODE. Note that the identifier is coded as a string, _not_ as a binary value, regardless of the type. |

+| Other Patient Names| (0010,1001) | Other names used to identify the patient |

+| Patient's Birth Name| (0010,1005) | Patient's birth name |

+| Patient's Mother's Birth Name| (0010,1060) | Birth name of patient's mother |

+| Medical Record Locator | (0010,1090)| An identifier used to find the patient's existing medical record (for example, film jacket). |

+| Patient's Age | (0010,1010) | Age of the Patient |

+| Occupation | (0010,2180) | Occupation of the Patient |

+| Confidentiality Constraint on Patient Data Description | (0040,3001) | Special indication to the modality operator about confidentiality of patient information; For example, that they shouldn't use the patient's name when other patients are present. |

+| Patient's Sex | (0010,0040) | Sex of the named patient |

+| Patient's Address | (0010,1040) | Legal address of the named patient |

+| Branch of Service | (0010,1081) | Branch of the military; The country or regional allegiance might also be included (for example, U.S. Army). |

+| Country of Residence | (0010,2150) | Country where a patient currently resides |

+| Region of Residence | (0010,2152) | Region within patient's country of residence |

+| Patient's Telephone Numbers | (0010,2154) | Telephone numbers at which the patient can be reached |

+| Ethnic Group | (0010,2160) | Ethnic group or race of patient |

+| Patient's Religious Preference | (0010,21F0) | The religious preference of the patient |

+| Responsible Person | (0010,2297) | Name of a person with medical decision making authority for the patient. |

+| Responsible Person Role | (0010,2298) | Relationship of Responsible Person to the patient |

+| Responsible Organization | (0010,2299) | Name of an organization with medical decision making authority for the patient |

+| Patient Species Description | (0010,2201) | The species of the patient |

+| Patient Breed Description | (0010,2292) | The breed of the patient; See Section C.7.1.1.1.1. |

+| Breed Registration Number | (0010,2295) | Identification number of a veterinary patient within the registry |

+| Issuer of Patient ID | (0010,0021) | Identifier of the Assigning Authority (system, organization, agency, or department) that issued the Patient ID |

+| Referring Physician's Name | (0008,0090) | Name of the patient's referring physician |

+| Accession Number | (0008,0050) | A RIS generated number that identifies the order for the Study |

+| Study Description | (0008,1030) | Institution-generated description or classification of the Study (component) performed |

+|Customers accessing the FHIR Service via a private endpoint are experiencing difficulties, specifically receiving a 403 error when making API calls from within the vNet. This problem affects those with FHIR instances created post-August 19th that utilize private link.|August 22,2024 11:00 am PST|Suggested workaround to unblock is 1 Create a Private DNS Zone for azurehealthcareapis.com under the same VNET. 2 Create a new recordset to the targeted FHIR service. | --|

+ "compatPropertyNames":"manufacturer,model,location,environment" <The property values must be in lower case only>,

+A solution uses the model ID identified previously to retrieve the corresponding model definition.

+The `ModelsRepositoryClient` can be configured to query a custom DMR--available through https--and to specify the dependency resolution by using the `ModelDependencyResolution` flag:

+Now that you learned how to integrate IoT Plug and Play models in an IoT solution, some suggested next steps are:

+The data type of a property or telemetry definition specifies the format of the data that a device exchanges with a service. The semantic type provides information about telemetry and properties that an application can use to determine how to process or display a value. Each semantic type has one or more associated units. For example, celsius and fahrenheit are units for the temperature semantic type. IoT Central dashboards and analytics can use the semantic type information to determine how to plot telemetry or property values and display units. To learn how you can use the model parser to read the semantic types, see [Understand the Digital Twins model parser](#understand-the-digital-twins-model-parser).

+Applications, such as IoT Central, use information in the model to dynamically build a UI around the data exchanged with an IoT Plug and Play device. For example, tiles on a dashboard can display names and descriptions for telemetry, properties, and commands.

+After you install the extension, use it to help you author DTDL model files in VS Code:

+A custom solution can use the [Digital Twins model parser](#understand-the-digital-twins-model-parser) to understand the capabilities of a device that implements the model. To learn more, see [Use IoT Plug and Play models in an IoT solution](concepts-model-discovery.md).

+As of February 2024, the Azure Certified Device program is retired. Therefore, Microsoft is no longer accepting submissions of DTDL models to the[Azure IoT plug and play models](https://github.com/Azure/iot-plugandplay-models) repository.

+## Understand the Digital Twins model parser

+The Digital Twins Definition Language (DTDL) is described in the [DTDL Specification](https://github.com/Azure/opendigitaltwins-dtdl/blob/master/README.md). Users can use the _Digital Twins Model Parser_ NuGet package to validate and query a DTDL v2 or v3 model. The DTDL model can be defined in multiple files.

+### Install the DTDL model parser

+The parser is available in NuGet.org with the ID: [DTDLParser](https://www.nuget.org/packages/DTDLParser). To install the parser, use any compatible NuGet package manager such as the one in Visual Studio or in the `dotnet` CLI.

+```bash

+dotnet add package DTDLParser

+```

+> [!NOTE]

+> At the time of writing, the parser version is `1.0.52`.

+### Use the parser to validate and inspect a model

+The DTDLParser is a library that you can use to:

+- Determine whether one or more models are valid according to the language v2 or v3 specifications.

+- Identify specific modeling errors.

+- Inspect model contents.

+A model can be composed of one or more interfaces described in JSON files. You can use the parser to load all the files that define a model and then validate all the files as a whole, including any references between the files.

+The [DTDLParser for .NET](https://github.com/digitaltwinconsortium/DTDLParser) repository includes the following samples that illustrate the use of the parser:

+- [DTDLParserResolveSample](https://github.com/digitaltwinconsortium/DTDLParser/blob/main/samples/DTDLParserResolveSample) shows how to parse an interface with external references, resolve the dependencies using the `Azure.IoT.ModelsRepository` client.

+- [DTDLParserJSInteropSample](https://github.com/digitaltwinconsortium/DTDLParser/blob/main/samples/DTDLParserJSInteropSample) shows how to use the DTDL Parser from JavaScript running in the browser, using .NET JSInterop.

+The DTDLParser for .NET repository also includes a [collection of tutorials](https://github.com/digitaltwinconsortium/DTDLParser/blob/main/tutorials/README.md) that show you how to use the parser to validate and inspect models.

+The model parser API enables many scenarios to automate or validate tasks that depend on DTDL models. For example, you could dynamically build a UI from the information in the model.

+Now that you learned about device modeling, here are some more resources:

+ Title: Migrate from Inbound NAT rules version 1 to version 2

+description: Learn how to migrate Azure Load balancer from inbound NAT rules version 1 to version 2.

+# Migrate from Inbound NAT rules version 1 to version 2

+An [inbound NAT rule](inbound-nat-rules.md) is used to forward traffic from a load balancerΓÇÖs frontend to one or more instances in the backend pool. These rules provide a 1:1 mapping between the load balancerΓÇÖs frontend IP address and backend instances. There are currently two versions of Inbound NAT rules, version 1 and version 2.

+## NAT rule version 1

+[Version 1](inbound-nat-rules.md) is the legacy approach for assigning an Azure Load BalancerΓÇÖs frontend port to each backend instance. Rules are applied to the backend instanceΓÇÖs network interface card (NIC). For Azure Virtual Machine Scale Sets instances, inbound NAT rules are automatically created/deleted as new instances are scaled up/down.

+## NAT rule version 2

+[Version 2](inbound-nat-rules.md) of Inbound NAT rules provide the same feature set as version 1, with extra benefits.

+- Simplified deployment experience and optimized updates.

+ - Inbound NAT rules now target the backend pool of the load balancer and no longer require a reference on the virtual machine's NIC. Previously on version 1, both the load balancer and the virtual machine's NIC needed to be updated whenever the Inbound NAT rule was changed. Version 2 only requires a single call on the load balancerΓÇÖs configuration, resulting in optimized updates.

+- Easily retrieve port mapping between Inbound NAT rules and backend instances.

+ - With the legacy offering, to retrieve the port mapping between an Inbound NAT rule and a virtual machine instance, the rule would need to be correlated with the virtual machine's NIC. Version 2 injects the port mapping between the rule and backend instance directly into the load balancerΓÇÖs configuration.

+## How do I know if IΓÇÖm using version 1 of Inbound NAT rules?

+The easiest way to identify if your deployments are using version 1 of the feature is by inspecting the load balancerΓÇÖs configuration. If either the `InboundNATPool` property or the `backendIPConfiguration` property within the `InboundNATRule` configuration is populated, then the deployment is version 1 of Inbound NAT rules.

+## How to migrate from version 1 to version 2?

+Prior to migrating it's important to review the following information:

+- Migrating to version 2 of Inbound NAT rules causes downtime to active traffic that is flowing through the NAT rules. Traffic flowing through [load balancer rules](components.md) or [outbound rules](components.md) aren't impacted during the migration process.

+- Plan out the max number of instances in a backend pool. Since version 2 targets the load balancerΓÇÖs backend pool, a sufficient number of ports need to be allocated for the NAT ruleΓÇÖs frontend.

+- Each backend instance is exposed on the port configured in the new NAT rule.

+- Multiple NAT rules canΓÇÖt exist if they have an overlapping port range or have the same backend port.

+- NAT rules and load balancing rules canΓÇÖt share the same backend port.

+### Manual Migration

+The following three steps need to be performed to migrate to version 2 of inbound NAT rules

+1. Delete the version 1 of inbound NAT rules on the load balancerΓÇÖs configuration.

+2. Remove the reference to the NAT rule on the virtual machine or virtual machine scale set configuration.

+ 1. All virtual machine scale set instances need to be updated.

+3. Deploy version 2 of Inbound NAT rules.

+### Virtual Machine

+The following steps are used to migrate from version 1 to version 2 of Inbound NAT rules for a virtual machine.

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

+```azurecli

+az network lb inbound-nat-rule delete -g MyResourceGroup --lb-name MyLoadBalancer --name NATruleV1

+az network nic ip-config inbound-nat-rule remove -g MyResourceGroup --nic-name MyNic -n MyIpConfig --inbound-nat-rule MyNatRule

+az network lb inbound-nat-rule create -g MyResourceGroup --lb-name MyLoadBalancer -n MyNatRule --protocol Tcp --frontend-port-range-start 201 --frontend-port-range-end 500 --backend-port 22

+```

+# [PowerShell](#tab/powershell)

+```powershell

+$slb = Get-AzLoadBalancer -Name "MyLoadBalancer" -ResourceGroupName "MyResourceGroup"

+Remove-AzLoadBalancerInboundNatRuleConfig -Name "myinboundnatrule" -LoadBalancer $loadbalancer

+Set-AzLoadBalancer -LoadBalancer $slb

+$nic = Get-AzNetworkInterface -Name "myNIC" -ResourceGroupName "MyResourceGroup"

+$nic.IpConfigurations[0].LoadBalancerInboundNatRule ΓÇ»= $null

+Set-AzNetworkInterface -NetworkInterface $nic

+$slb | Add-AzLoadBalancerInboundNatRuleConfig -Name "NewNatRuleV2" -FrontendIPConfiguration $slb.FrontendIpConfigurations[0] -Protocol "Tcp" -FrontendPortRangeStart 201-FrontendPortRangeEnd 500 -BackendAddressPool $slb.BackendAddressPools[0] -BackendPort 22

+$slb | Set-AzLoadBalancer

+```

+### Virtual Machine Scale Set

+The following steps are used to migrate from version 1 to version 2 of Inbound NAT rules for a virtual machine scale set. It assumes the virtual machine scale set's upgrade mode is set to Manual. For more information, see [Orchestration modes for Virtual Machine Scale Sets in Azure](/azure/virtual-machine-scale-sets/virtual-machine-scale-sets-orchestration-modes)

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

+```azurecli

+az network lb inbound-nat-pool delete ΓÇ»-g MyResourceGroup --lb-name MyLoadBalancer -n MyNatPool

+az vmss update -g MyResourceGroup -n MyVMScaleSet --remove virtualMachineProfile.networkProfile.networkInterfaceConfigurations[0].ipConfigurations[0].loadBalancerInboundNatPools

+az vmss update-instances --instance-ids '*' --resource-group MyResourceGroup --name MyVMScaleSet

+az network lb inbound-nat-rule create -g MyResourceGroup --lb-name MyLoadBalancer -n MyNatRule --protocol Tcp --frontend-port-range-start 201 --frontend-port-range-end 500 --backend-port 22

+```

+# [PowerShell](#tab/powershell)

+```powershell

+# Remove the Inbound NAT rule

+$slb = Get-AzLoadBalancer -Name "MyLoadBalancer" -ResourceGroupName "MyResourceGroup"

+Remove-AzLoadBalancerInboundNatPoolConfig -Name myinboundnatpool -LoadBalancer $slb

+Set-AzLoadBalancer -LoadBalancer $slb

+# Remove the Inbound NAT pool association

+$vmss = Get-AzVmss -ResourceGroupName "MyResourceGroup" -VMScaleSetName "MyVMScaleSet"

+$vmss.VirtualMachineProfile.NetworkProfile.NetworkInterfaceConfigurations[0].IpConfigurations[0].loadBalancerInboundNatPools = $null

+# Upgrade all instances in the VMSS

+Update-AzVmssInstance -ResourceGroupName $resourceGroupName -VMScaleSetName $vmssName -InstanceId "*"

+$slb | Add-AzLoadBalancerInboundNatRuleConfig -Name "NewNatRuleV2" -FrontendIPConfiguration $slb.FrontendIpConfigurations[0] -Protocol "Tcp" -FrontendPortRangeStart 201-FrontendPortRangeEnd 500 -BackendAddressPool $slb.BackendAddressPools[0] -BackendPort 22

+$slb | Set-AzLoadBalancer

+

+## Migration with automation script for Virtual Machine Scale Set

+The migration process will reuse existing backend pools with membership matching the NAT Pools to be migrated; if no matching backend pool is found, the script will exit (without making changes). Alternatively, use the `-backendPoolReuseStrategy` parameter to either always create new backend pools (`NoReuse`) or create a new backend pool if a matching one doesn't exist (`OptionalFirstMatch`). Backend pools and NAT Rule associations can be updated post migration to match your preference.

+### Prerequisites

+Before beginning the migration process, ensure the following prerequisites are met:

+- The load balancer's SKU must be **Standard** to migrate a load balancer's NAT Pools to NAT Rules. To automate this upgrade process, see the steps provided inΓÇ»[Upgrade a Basic Load Balancer to Standard with PowerShell](upgrade-basic-standard-with-powershell.md).

+- The Virtual Machine Scale Sets associated with the target Load Balancer must use either a 'Manual' or 'Automatic' upgrade policy--'Rolling' upgrade policy isn't supported. For more information, seeΓÇ»[Virtual Machine Scale Sets Upgrade Policies](/azure/virtual-machine-scale-sets/virtual-machine-scale-sets-upgrade-policy).

+- Install the latest version ofΓÇ»[PowerShell](/powershell/scripting/install/installing-powershell).

+- Install theΓÇ»[Azure PowerShell modules](/powershell/azure/install-azure-powershell).

+### Install the `AzureLoadBalancerNATPoolMigration` module

+With the following command, install the `AzureLoadBalancerNATPoolMigration` module from the PowerShell Gallery:

+```powershell

+# Install the AzureLoadBalancerNATPoolMigration module

+Install-Module -Name AzureLoadBalancerNATPoolMigration -Scope CurrentUser -Repository PSGallery -Force

+```

+### Upgrade NAT Pools to NAT Rules

+With the `azureLoadBalancerNATPoolMigration` module installed, upgrade your NAT Pools to NAT Rules with the following steps:

+1. Connect to Azure with `Connect-AzAccount`.

+2. Collect the names of the **target load balancer** for the NAT Rules upgrade and its **Resource Group** name.

+3. Run the migration command with your resource names replacing the placeholders of `<loadBalancerResourceGroupName>` and `<loadBalancerName>`:

+ ```powershell

+ # Run the migration command

+

+ Start-AzNATPoolMigration -ResourceGroupName <loadBalancerResourceGroupName> -LoadBalancerName <loadBalancerName>

+

+ ```

+> [!VIDEO 8e203b99-41ff-4454-9cbd-58856708f1c6]

+> [!VIDEO 8e203b99-41ff-4454-9cbd-58856708f1c6]

+> [!NOTE]

+>

+> By default, **FUNCTIONS_WORKER_RUNTIME** app setting for your logic app is **`dotnet`**.

+> Previously, **`node`** was the default value. However, **`dotnet`** is now the default

+> value for all new and existing deployed Arc enabled logic apps, even for apps that had

+> a different value. This change shouldn't affect your workflow's runtime, and everything

+> should work the same way as before. For more information, see the

+> [**FUNCTIONS_WORKER_RUNTIME** app setting](edit-app-settings-host-settings.md#reference-local-settings-json).

+>

+> The **APP_KIND** app setting for your logic app is set to **workflowapp**, but in some scenarios,

+> this app setting is missing, for example, due to Azure Resource Manager templates or other scenarios

+> where the setting might not be included. If certain actions don't work, such as the

+> **Execute JavaScript Code** action or the workflow stops working, check that the

+> **APP_KIND** app setting exists and is set to to **workflowapp**. For more information, see the

+> [**APP_KIND** app setting](edit-app-settings-host-settings.md#reference-local-settings-json).

+ >

+ > The **APP_KIND** app setting for your Standard logic app is set to **workflowApp**, but in some

+ > scenarios, this app setting is missing, for example, due to automation using Azure Resource Manager

+ > templates or other scenarios where the setting isn't included. If certain actions don't work,

+ > such as the **Execute JavaScript Code** action or the workflow stops working, check that the

+ > **APP_KIND** app setting exists and is set to to **workflowApp**. For more information, see the

+ > [**APP_KIND** app setting](edit-app-settings-host-settings.md#reference-local-settings-json).

+ > If you do, try installing the [Azure Functions extension for Visual Studio Code](https://marketplace.visualstudio.com/items?itemName=ms-azuretools.vscode-azurefunctions),

+ > either directly from the Visual Studio Marketplace or from inside Visual Studio Code.

+ > [!NOTE]

+ >

+ > By default, in your **local.settings.json** file, the language worker runtime value for your

+ > Standard logic app is **`dotnet`**. Previously, **`node`** was the default value. However,

+ > **`dotnet`** is now the default value for all new and existing deployed Standard logic apps,

+ > even for apps that had a different value. This change shouldn't affect your workflow's runtime,

+ > and everything should work the same way as before. For more information, see the

+ > [**FUNCTIONS_WORKER_RUNTIME** app setting](edit-app-settings-host-settings.md#reference-local-settings-json).

+ >

+ > The **APP_KIND** app setting for your Standard logic app is set to **workflowApp**, but in some

+ > scenarios, this app setting is missing, for example, due to automation using Azure Resource Manager

+ > templates or other scenarios where the setting isn't included. If certain actions don't work,

+ > such as the **Execute JavaScript Code** action or the workflow stops working, check that the

+ > **APP_KIND** app setting exists and is set to to **workflowApp**. For more information, see the

+ > [**APP_KIND** app setting](edit-app-settings-host-settings.md#reference-local-settings-json).

+| `APP_KIND` | `workflowApp` | Sets the app type for the Azure resource. |

+ Ubuntu | 12.04, 14.04, 16.04, 18.04, 20.04, 22.04

+ Hyper-V (85.8 MB) | [Latest version](https://go.microsoft.com/fwlink/?linkid=2191847) | [!INCLUDE [security-hash-value](includes/security-hash-value.md)]

+> OVA templates are not available for sovereign clouds.

+Linux servers | Red Hat Enterprise Linux 5.1, 5.3, 5.11, 6.x, 7.x, 8.x <br /> Ubuntu 12.04, 14.04, 16.04, 18.04, 20.04, 22.04 <br /> OracleLinux 6.1, 6.7, 6.8, 6.9, 7.2, 7.3, 7.4, 7.5, 7.6, 7.7, 7.8, 7.9, 8, 8.1, 8.3, 8.5 <br /> SUSE Linux 10, 11 SP4, 12 SP1, 12 SP2, 12 SP3, 12 SP4, 15 SP2, 15 SP3 <br /> Debian 7, 8, 9, 10, 11

+[Azure NetApp Files](./relocation-netapp.md)| ✅ | ✅| ❌ |

+ Title: Relocate Azure NetApp Files volume to another region

+description: Learn how to relocate an Azure NetApp Files volume to another region

+ - subject-relocation

+# Relocate Azure NetApp Files volume to another region

+This article covers guidance for relocating [Azure NetApp Files](../azure-netapp-files/azure-netapp-files-introduction.md) volumes to another region.

+## Prerequisites

+Before you begin the relocation planning stage, first review the following prerequisites:

+- The target NetApp account instance should already be created.

+- Source and target regions must be paired regions. To see if they're paired, see [Supported cross-region replication pairs](../azure-netapp-files/cross-region-replication-introduction.md?#supported-region-pairs).

+- Understand all dependent resources. Some of the resources could be:

+ - Microsoft Entra ID

+ - [Virtual Network](./relocation-virtual-network.md)

+ - Azure DNS

+ - [Storage services](./relocation-storage-account.md)

+ - [Capacity pools](../azure-netapp-files/azure-netapp-files-set-up-capacity-pool.md)

+## Prepare

+Before you begin the relocation process, make sure to complete the following preparations:

+- The target Microsoft Entra ID connection must have access to the DNS servers, AD DS Domain Controllers, or Microsoft Entra Domain Services Domain Controllers that are reachable from the delegated subnet in the target region.

+- The network configurations (including separate subnets if needed and IP ranges) should already be planned and prepared

+- Turn off replication procedures to disaster recovery region. If you've established a disaster recovery (DR) solution using replication to a DR region, turn off replication to the DR site before initiating relocation procedures.

+- Understand the following considerations in regards to replication:

+

+ - SMB, NFS, and dual-protocol volumes are supported. Replication of SMB volumes requires a Microsoft Entra ID connection in the source and target NetApp accounts.

+

+ - The replication destination volume is read-only until the entire move is complete.

+

+ - Azure NetApp Files replication doesn't currently support multiple subscriptions. All replications must be performed under a single subscription.

+

+ - There are resource limits for the maximum number of cross-region replication destination volumes. For more information, see [Resource limits for Azure NetApp Files](../azure-netapp-files/azure-netapp-files-resource-limits.md).

+

+## Redeploy

+**To redeploy your NetApp resources:**

+1. [Create the target NetApp account](../azure-netapp-files/azure-netapp-files-create-netapp-account.md).

+1. [Create the target capacity pool](../azure-netapp-files/azure-netapp-files-set-up-capacity-pool.md).

+1. [Delegate a subnet in the target region](../azure-netapp-files/azure-netapp-files-delegate-subnet.md). Azure NetApp Files creates a system route to the delegated subnet. Peering and endpoints can be used to connect to the target as needed.

+1. Create a data replication volume by following the directions in [Create volume replication for Azure NetApp Files](../azure-netapp-files/cross-region-replication-create-peering.md).

+1. [Verify that the health status](../azure-netapp-files/cross-region-replication-display-health-status.md) of replication is healthy.

+## Cleanup

+Once the replication is complete, you can then safely delete the replication peering the source volume.

+To learn how to clean up a replication, see [Delete volume replications or volumes](/azure/azure-netapp-files/cross-region-replication-delete).

+## Related content

+- [Cross-region replication of Azure NetApp Files volumes](../azure-netapp-files/cross-region-replication-introduction.md)

+To learn more about moving resources between regions and disaster recovery in Azure, refer to:

+- [Requirements for Active Directory Connections](/azure/azure-netapp-files/create-active-directory-connections#requirements-for-active-directory-connections)

+

+- [Guidelines for Azure NetApp Files network planning](/azure/azure-netapp-files/azure-netapp-files-network-topologies)

+

+- [Fail over to the destination region](/azure/azure-netapp-files/cross-region-replication-manage-disaster-recovery#fail-over-to-destination-volume)

+- [Move resources to a new resource group or subscription](../azure-resource-manager/management/move-resource-group-and-subscription.md)

+- [Move Azure VMs to another region](../site-recovery/azure-to-azure-tutorial-migrate.md)

+* Minimum required `networkcloud` az-cli extension version: `2.0.b3`

+* Minimum required `networkcloud` az-cli extension version: `2.0.b3`

+[kubernetes-drain]: https://kubernetes.io/docs/tasks/administer-cluster/safely-drain-node/

+> [!IMPORTANT]

+> This guidance applies only to certain releases. Check your version for proper behavior.

+From release 1.0.2728-50 to release Version 2.0.2777-132, AOSM uses cert-manager to store and rotate certificates. As part of this change, AOSM deploys a cert-manager operator, and associate CRDs, in the azurehybridnetwork namespace. Since having multiple cert-manager operators, even deployed in separate namespaces, will watch across all namespaces, only one cert-manager can be effectively run on the cluster.

+ Title: Release notes for Azure Operator Service Manager

+description: Official documentation and tracking for major and minor releases.

+## Release 2.0.2788-135

+* Dependency Versions: Go/1.22.4 Helm/3.15.2

+ Title: Get started with Azure Operator Service Manager Safe Upgrade Practices

+description: Safely execute complex upgrades of CNF workloads on Azure Operator Nexus

+ Title: Control upgrade failure behavior with Azure Operator Service Manager

+description: Learn about recovery behaviors including pause on failure and rollback on failure.

+# Control upgrade failure behavior

+## Overview

+This guide describes the Azure Operator Service Manager (AOSM) upgrade failure behavior features for container network functions (CNFs). These features, as part of the AOSM safe upgrade practices initiative, offer a choice between faster retries, with pause on failure, versus return to starting point, with rollback on failure.

+## Pause on failure

+Any upgrade using AOSM starts with a site network service (SNS) reput opreation. The reput operation processes the network function applications (NfApps) found in the network function design version (NFDV). The reput operation implements the following default logic:

+* NfApps are processed following either updateDependsOn ordering, or in the sequential order they appear.

+* NfApps with parameter "applicationEnabled" set to disable are skipped.

+* NFApps present, but not referenced by the new NFDV are deleted.

+* The execution sequence is paused if any of the NfApp upgrades fail and a rollback is considered.

+* The failure leaves the NF resource in a failed state.

+With pause on failure, AOSM rolls back only the failed NfApp, via the testOptions, installOptions, or upgradeOptions parameters. No action is taken on any NfApps which proceed the failed NfApp. This method allows the end user to troubleshoot the failed NfApp and then restart the upgrade from that point forward. As the default behavior, this method is the most efficient method, but may cause network function (NF) inconsistencies while in a mixed version state.

+## Rollback on failure

+To address risk of mismatched NfApp versions, AOSM now supports NF level rollback on failure. With this option enabled, if an NfApp operation fails, both the failed NfApp, and all prior completed NfApps, can be rolled back to initial version state. This method minimizes, or eliminates, the amount of time the NF is exposed to NfApp version mismatches. The optional rollback on failure feature works as follows:

+* A user initiates an sSNS reput operation and enables rollback on failure.

+* A snapshot of the current NfApp versions is captured and stored.

+* The snapshot is used to determine the individual NfApp actions taken to reverse actions that completed successfully.

+ - "helm install" action on deleted components,

+ - "helm rollback" action on upgraded components,

+ - "helm delete" action on newly installed components

+* NfApp failure occurs, AOSM restores the NfApps to the snapshot version state before the upgrade, with most recent actions reverted first.

+> [!NOTE]

+> * AOSM doesn't create a snapshot if a user doesn't enable rollback on failure.

+> * A rollback on failure only applies to the successfully completed NFApps.

+> - Use the testOptions, installOptions, or upgradeOptions parameters to control rollback of the failed NfApp.

+AOSM returns the following operational status and messages, given the respective results:

+```

+ - Upgrade Succeeded

+ - Provisioning State: Succeeded

+ - Message: <empty>

+```

+```

+ - Upgrade Failed, Rollback Succeeded

+ - Provisioning State: Failed

+ - Message: Application(<ComponentName>) : <Failure Reason>; Rollback succeeded

+```

+```

+ - Upgrade Failed, Rollback Failed

+ - Provisioning State: Failed

+ - Message: Application(<ComponentName>) : <Failure reason>; Rollback Failed (<RollbackComponentName>) : <Rollback Failure reason>

+```

+## How to configure rollback on failure

+The most flexible method to control failure behavior is to extend a new configuration group schema (CGS) parameter, rollbackEnabled, to allow for configuration group value (CGV) control via roleOverrideValues in the NF payload. First, define the CGS parameter:

+```

+{

+ "description": "NF configuration",

+ "type": "object",

+ "properties": {

+ "nfConfiguration": {

+ "type": "object",

+ "properties": {

+ "rollbackEnabled": {

+ "type": "boolean"

+ }

+ },

+ "required": [

+ "rollbackEnabled"

+ ]

+ }

+ }

+}

+```

+> [!NOTE]

+> * If the nfConfiguration isn't provided through the roleOverrideValues parameter, by default the rollback is disabled.

+With the new rollbackEnable parameter defined, the Operator can now provide a run time value, under roleOverrideValues, as part of NF reput payload.

+```

+example:

+{

+ "location": "eastus",

+ "properties": {

+ // ...

+ "roleOverrideValues": [

+ "{\"nfConfiguration\":{\"rollbackEnabled\":true}}",

+ "{\"name\":\"nfApp1\",\"deployParametersMappingRuleProfile\":{\"applicationEnablement\" : \"Disabled\"}}",

+ "{\"name\":\"nfApp2\",\"deployParametersMappingRuleProfile\":{\"applicationEnablement\" : \"Disabled\"}}",

+ //... other nfapps overrides

+ ]

+ }

+}

+```

+> [!NOTE]

+> * Each roleOverrideValues entry overrides the default behavior of the NfAapps.

+> * If multiple entries of nfConfiguration are found in the roleOverrideValues, then the NF reput is returned as a bad request.

+## How to troubleshoot rollback on failure

+### Understand pod states

+Understanding the different pod states is crucial for effective troubleshooting. The following are the most common pod states:

+* Pending: Pod scheduling is in progress by Kubernetes.

+* Running: All containers in the pod are running and healthy.

+* Failed: One or more containers in the pod are terminated with a nonzero exit code.

+* CrashLoopBackOff: A container within the pod is repeatedly crashing and Kubernetes is unable to restart it.

+* ContainerCreating: Container creation is in progress by the container runtime.

+### Check pod status and logs

+First start by checking pod status and logs using a kubectl command:

+```

+$ kubectl get pods

+$ kubectl logs <pod-name>

+```

+The get pods command lists all the pods in the current namespace, along with their current status. The logs command retrieves the logs for a specific pod, allowing you to inspect any errors or exceptions. To troubleshoot networking problems, use the following commands:

+```

+$ kubectl get services

+$ kubectl describe service <service-name>

+```

+The get services command displays all the services in the current namespace. The command provides details about a specific service, including the associated endpoints, and any relevant error messages. If you're encountering issues with PVCs, you can use the following commands to debug them:

+```

+$ kubectl get persistentvolumeclaims

+$ kubectl describe persistentvolumeclaims <pvc-name>

+```

+The "get persistentvolumeclaims" command lists all the PVCs in the current namespace. The describe command provides detailed information about a specific PVC, including the status, associated storage class, and any relevant events or errors.

+|Australia East |&check; |&check; |

+If you don't want to use the PIM functionality, select the **Active** assignment type and **Permanent** assignment duration options. These settings create a role assignment where the principal always has permissions in the role.

+If you're using disks based on Azure Page BLOB Storage or Managed Disks, the statements made in [Considerations for Azure Virtual Machines DBMS deployment for SAP workload](dbms-guide-general.md) apply to deployments with the Db2 DBMS (Database Management System) as well.

+As explained earlier in the general part of the document, quotas on IOPS (I/O operations per second) throughput for Azure disks exist. The exact quotas are depending on the VM type used. A list of VM types with their quotas can be found [here (Linux)](/azure/virtual-machines/sizes) and [here (Windows)](/azure/virtual-machines/sizes).

+Alternatively, you can use Windows Storage Pools, which are only available in Windows Server 2012 and higher as described [Considerations for Azure Virtual Machines DBMS deployment for SAP workload](dbms-guide-general.md). On Linux, you can use LVM or mdadm to create one large logical device over multiple disks.

+Following is a baseline configuration for various sizes and uses of SAP on Db2 deployments from small to x-large.

+>[!IMPORTANT]

+> The VM types listed below are examples that meet the vCPU and memory critiera of each of the categories. The storage configuration is based on Azure premium storage v1. Premium SSD v2 and Azure Ultra disk is fully supported with IBM Db2 as well and can be used for deployments. Use the values for capacity, burst throughput, and burst IOPS to define the Ultra disk or Premium SSD v2 configuration. You can limit the IOPS for the /db2/```<SID>```/log_dir at around 5000 IOPS. Adjust the throughput and IOPS to the specific workload if these baseline recommendations don't meet the requirements

+| VM Size / Examples |Db2 mount point |Azure Premium Disk |# of Disks |IOPS |Through-<br />put [MB/s] |Size [GB] |Burst IOPS |Burst Through-<br />put [GB] | Stripe size | Caching |

+| vCPU: 4 |/db2 |P6 |1 |240 |50 |64 |3,500 |170 || |

+| RAM: ~32 GiB |/db2/```<SID>```/sapdata |P10 |2 |1,000 |200 |256 |7,000 |340 |256<br />KB |ReadOnly |

+| E4(d)s_v5|/db2/```<SID>```/saptmp |P6 |1 |240 |50 |128 |3,500 |170 | ||

+| E4(d)as_v5 |/db2/```<SID>```/log_dir |P6 |2 |480 |100 |128 |7,000 |340 |64<br />KB ||

+| ... |/db2/```<SID>```/offline_log_dir |P10 |1 |500 |100 |128 |3,500 |170 || |

+| VM Size / Examples |Db2 mount point |Azure Premium Disk |# of Disks |IOPS |Through-<br />put [MB/s] |Size [GB] |Burst IOPS |Burst Through-<br />put [GB] | Stripe size | Caching |

+| vCPU: 16 |/db2 |P6 |1 |240 |50 |64 |3,500 |170 || |

+| RAM: ~128 GiB |/db2/```<SID>```/sapdata |P15 |4 |4,400 |500 |1.024 |14,000 |680 |256 KB |ReadOnly |

+| E16(d)s_v5 |/db2/```<SID>```/saptmp |P6 |2 |480 |100 |128 |7,000 |340 |128 KB ||

+| E16(d)as_v5 |/db2/```<SID>```/log_dir |P15 |2 |2,200 |250 |512 |7,000 |340 |64<br />KB ||

+| ... |/db2/```<SID>```/offline_log_dir |P10 |1 |500 |100 |128 |3,500 |170 |||

+| VM Size / Examples |Db2 mount point |Azure Premium Disk |# of Disks |IOPS |Through-<br />put [MB/s] |Size [GB] |Burst IOPS |Burst Through-<br />put [GB] | Stripe size | Caching |

+| vCPU: 32 |/db2 |P6 |1 |240 |50 |64 |3,500 |170 || |

+| RAM: ~256 GiB |/db2/```<SID>```/sapdata |P30 |2 |10,000 |400 |2.048 |10,000 |400 |256 KB |ReadOnly |

+| E32(d)s_v5 |/db2/```<SID>```/saptmp |P10 |2 |1,000 |200 |256 |7,000 |340 |128 KB ||

+| E32(d)as_v5 |/db2/```<SID>```/log_dir |P20 |2 |4,600 |300 |1.024 |7,000 |340 |64<br />KB ||

+| M32ls |/db2/```<SID>```/offline_log_dir |P15 |1 |1,100 |125 |256 |3,500 |170 |||

+| VM Size / Examples |Db2 mount point |Azure Premium Disk |# of Disks |IOPS |Through-<br />put [MB/s] |Size [GB] |Burst IOPS |Burst Through-<br />put [GB] | Stripe size | Caching |

+| vCPU: 64 |/db2 |P6 |1 |240 |50 |64 |3,500 |170 || |

+| RAM: ~512 GiB |/db2/```<SID>```/sapdata |P30 |4 |20,000 |800 |4.096 |20,000 |800 |256 KB |ReadOnly |

+| E64(d)s_v5 |/db2/```<SID>```/saptmp |P15 |2 |2,200 |250 |512 |7,000 |340 |128 KB ||

+| E64(d)as_v5 |/db2/```<SID>```/log_dir |P20 |4 |9,200 |600 |2.048 |14,000 |680 |64<br />KB ||

+| M64ls |/db2/```<SID>```/offline_log_dir |P20 |1 |2,300 |150 |512 |3,500 |170 || |

+Especially for such larger systems it's important to evaluate the infrastructure that the system is currently running on and the resource consumption data of those systems to find the best match of Azure compute and storage infrastructure and configuration.

+| vCPU: =>128 |/db2 |P10 |1 |500 |100 |128 |3,500 |170 || |

+| RAM: =>2,048 GiB |/db2/```<SID>```/sapdata |P40 |4 |30,000 |1.000 |8.192 |30,000 |1.000 |256 KB |ReadOnly |

+| M128s_v2 |/db2/```<SID>```/saptmp |P20 |2 |4,600 |300 |1.024 |7,000 |340 |128 KB ||

+| M176s_2_v3 |/db2/```<SID>```/log_dir |P30 |4 |20,000 |800 |4.096 |20,000 |800 |64<br />KB |Write-<br />Accelerator |

+| M176s_3_v3,<br />M176s_4_v3 |/db2/```<SID>```/offline_log_dir |P30 |1 |5,000 |200 |1.024 |5,000 |200 || |

+#Customer intent: As a security operations (SOC) team member or security administrator, I want to know what operational activities I should plan to do daily, weekly, and monthly with Microsoft Sentinel to help keep my organization's environment secure.

+This article lists the operational activities that we recommend security operations (SOC) teams and security administrators plan for and run as part of their regular security activities with Microsoft Sentinel. For more information about managing your security operations, see [Security operations overview](/security/operations/overview).

+- [Security operations overview](/security/operations/overview)

+- [Implement Microsoft Sentinel and Microsoft Defender XDR for Zero Trust](/security/operations/siem-xdr-overview)

+- [Deployment guide for Microsoft Sentinel](deploy-overview.md)

+While Site Recovery makes a best effort to ensure that capacity is available in the recovery region, it does not guarantee the same. Site Recovery's best effort is backed by a 1-hour RTO SLA. But if you require further assurance and _guaranteed compute capacity,_ then we recommend you to purchase [Capacity Reservations](https://aka.ms/on-demand-capacity-reservations-docs)

+The latest Site Recovery Deployment Planner tool version is 3.0.

+Azure Data Lake Storage converges the capabilities of [Azure Data Lake Storage Gen1](../../data-lake-store/index.yml) with Azure Blob Storage. For example, Data Lake Storage provides file system semantics, file-level security, and scale. Because these capabilities are built on Blob storage, you also get low-cost, tiered storage, with high availability/disaster recovery capabilities.

+Azure Data Lake Storage isn't a dedicated service or account type. Instead, it's implemented as a set of capabilities that you use with the Blob Storage service of your Azure Storage account. You can unlock these capabilities by enabling the hierarchical namespace setting.

+After August 16, 2024, customers can no longer create classic storage accounts.

+After August 31, 2024, you'll no longer be able to manage data in your classic storage accounts through Azure Service Manager and the classic management plane APIs. The data will be preserved but we highly recommend migrating these accounts to Azure Resource Manager to avoid any service interruptions.

+> Both Azure Automation Update Management and the Log Analytics agent it uses [has been retired on 31st August 2024](https://azure.microsoft.com/updates/were-retiring-the-log-analytics-agent-in-azure-monitor-on-31-august-2024/). Therefore, if you are using the Automation Update Management solution, we recommend that you move to Azure Update Manager for your software update needs. Follow the [guidance](guidance-migration-automation-update-management-azure-update-manager.md#migration-scripts) to move your machines and schedules from Automation Update Management to Azure Update Manager.

+ "IPAddress":"198.51.100.122",

+ "Instance0":"203.0.113.186",

+ "Instance1":"203.0.113.195"