- Currently, access to this service is granted only by application. You can apply for access to Azure OpenAI by completing the form at <a href="https://aka.ms/oai/access" target="_blank">https://aka.ms/oai/access</a>. Open an issue on this repo to contact us if you have an issue.

-Azure OpenAI Service is powered by a diverse set of models with different capabilities and price points. Model availability varies by region.

-#### Azure Government regions

-The following GPT-4 models are available with [Azure Government](/azure/azure-government/documentation-government-welcome):

-|Model ID | Model Availability |

-|--|--|

-| `gpt-4` (1106-Preview) | US Gov Virginia<br>US Gov Arizona |

-#### Azure Government regions

-The following GPT-3.5 turbo models are available with [Azure Government](/azure/azure-government/documentation-government-welcome):

-|Model ID | Model Availability |

-|--|--|

-| `gpt-35-turbo` (1106-Preview) | US Gov Virginia |

-#### Azure Government regions

-The following Embeddings models are available with [Azure Government](/azure/azure-government/documentation-government-welcome):

-|Model ID | Model Availability |

-|--|--|

-|`text-embedding-ada-002` (version 2) |US Gov Virginia<br>US Gov Arizona |

-* `gpt-35-turbo` (1106) - [region availability](../concepts/models.md#gpt-35-turbo-model-availability)

-* `gpt-35-turbo` (0125) - [region availability](../concepts/models.md#gpt-35-turbo-model-availability)

-* `gpt-4` (1106-Preview) - [region availability](../concepts/models.md#gpt-4-and-gpt-4-turbo-model-availability)

-* `gpt-4` (0125-Preview) - [region availability](../concepts/models.md#gpt-4-and-gpt-4-turbo-model-availability)

-| Max files per Assistant/thread | 20 |

-Global Standard deployments use Azure's global infrastructure, dynamically routing customer traffic to the data center with best availability for the customerΓÇÖs inference requests. This enables more consistent latency for customers with low to medium levels of traffic. Customers with high sustained levels of usage may see more variability in response latency.

-Quota increase requests can be submitted from the [Quotas](./how-to/quota.md) page of Azure OpenAI Studio. Please note that due to overwhelming demand, quota increase requests are being accepted and will be filled in the order they are received. Priority will be given to customers who generate traffic that consumes the existing quota allocation, and your request may be denied if this condition isn't met.

-For other rate limits, please [submit a service request](../cognitive-services-support-options.md?context=/azure/ai-services/openai/context/context).

-> Fast transcription API is only available via the speech to text REST API version 3.3.

-> To compare pricing of [real-time](#real-time-speech-to-text) to [batch transcription](#batch-transcription-api), see [Speech service pricing](https://azure.microsoft.com/pricing/details/cognitive-services/speech-services/).

-## Subscribe your project to the model offering

-For models offered through the Azure Marketplace, you can deploy them to serverless API endpoints to consume their predictions. If it's your first time deploying the model in the project, you have to subscribe your project for the particular model offering from the Azure Marketplace. Each project has its own subscription to the particular Azure Marketplace offering of the model, which allows you to control and monitor spending.

-> [!NOTE]

-> Models offered through the Azure Marketplace are available for deployment to serverless API endpoints in specific regions. Check [Model and region availability for Serverless API deployments](deploy-models-serverless-availability.md) to verify which models and regions are available. If the one you need is not listed, you can deploy to a workspace in a supported region and then [consume serverless API endpoints from a different workspace](deploy-models-serverless-connect.md).

-1. Ensure your account has the **Azure AI Developer** role permissions on the resource group, or that you meet the [permissions required to subscribe to model offerings](#permissions-required-to-subscribe-to-model-offerings).

- 1. On the model's **Details** page, select **Deploy** and then select **Serverless API** to open the deployment wizard.

- 1. Select the project in which you want to deploy your models. Notice that not all the regions are supported.

-1. Once you sign up the project for the particular Azure Marketplace offering, subsequent deployments of the same offering in the same project don't require subscribing again.

-Once you've created a model's subscription, you can deploy the associated model to a serverless API endpoint. The serverless API endpoint provides a way to consume models as an API without hosting them on your subscription, while keeping the enterprise security and compliance organizations need. This deployment option doesn't require quota from your subscription.

-In this article, you create an endpoint with name **meta-llama3-8b-qwerty**.

- 1. From the previous wizard, select **Deploy** (if you've just subscribed the project to the model offer in the previous section), or select **Continue to deploy** (if your deployment wizard had the note *You already have an Azure Marketplace subscription for this project*).

-## Using the serverless API endpoint

-Read more about the [capabilities of this API](../reference/reference-model-inference-api.md#capabilities) and how [you can leverage it when building applications](../reference/reference-model-inference-api.md#getting-started).

-Models deployed as serverless API endpoints are offered through the Azure Marketplace and integrated with Azure AI Studio for use. You can find the Azure Marketplace pricing when deploying or fine-tuning the models.

-Quota is managed per deployment. Each deployment has a rate limit of 200,000 tokens per minute and 1,000 API requests per minute. However, we currently limit one deployment per model per project. Contact Microsoft Azure Support if the current rate limits aren't sufficient for your scenarios.

-## Next step

-> - Currently, PowerShell 7.2 runtime version is supported for both Cloud and Hybrid jobs in all Public regions except Central India, UAE Central, Israel Central, Italy North, Germany North and Gov clouds.

-> Currently, PowerShell 7.2 runtime version is supported for both Cloud and Hybrid jobs in all Public regions except Central India, UAE Central, Israel Central, Italy North, Germany North and Gov clouds.

-description: Use GitHub Actions to automatically update your App Configuration instance when you update your GitHub repository.

-# Sync your GitHub repository to App Configuration

-Teams that want to continue using their existing source control practices can use GitHub Actions to automatically sync their GitHub repository with their App Configuration store. This allows you to make changes to your config files as you normally would, while getting App Configuration benefits like: <br>

-&nbsp;&nbsp;&nbsp;&nbsp;ΓÇó Centralized configuration outside of your code <br>

-&nbsp;&nbsp;&nbsp;&nbsp;ΓÇó Updating configuration without redeploying your entire app <br>

-&nbsp;&nbsp;&nbsp;&nbsp;ΓÇó Integration with services like Azure App Service and Functions.

-A GitHub Actions [workflow](https://docs.github.com/en/actions/learn-github-actions/introduction-to-github-actions#the-components-of-github-actions) defines an automated process in a GitHub repository. The *Azure App Configuration Sync* Action triggers updates to an App Configuration instance when changes are made to the source repository. It uses a YAML (.yml) file found in the `/.github/workflows/` path of your repository to define the steps and parameters. You can trigger configuration updates when pushing, reviewing, or branching app configuration files just as you do with app code.

-The GitHub [documentation](https://docs.github.com/en/actions/learn-github-actions/introduction-to-github-actions) provides in-depth view of GitHub workflows and actions.

-## Enable GitHub Actions in your repository

-To start using this GitHub Action, go to your repository and select the **Actions** tab. Select **New workflow**, then **Set up a workflow yourself**. Finally, search the marketplace for ΓÇ£Azure App Configuration Sync.ΓÇ¥

-> [!div class="mx-imgBorder"]

-> 

-> [!div class="mx-imgBorder"]

-> 

-## Sync configuration files after a push

-This action syncs Azure App Configuration files when a change is pushed to `appsettings.json`. When a developer pushes a change to `appsettings.json`, the App Configuration Sync action updates the App Configuration instance with the new values.

-The first section of this workflow specifies that the action triggers *on* a *push* containing `appsettings.json` to the *main* branch. The second section lists the jobs run once the action is triggered. The action checks out the relevant files and updates the App Configuration instance using the connection string stored as a secret in the repository. For more information about using secrets in GitHub, see [GitHub's article](https://docs.github.com/en/actions/reference/encrypted-secrets) about creating and using encrypted secrets.

-```json

-on:

- push:

- branches:

- - 'main'

- paths:

- - 'appsettings.json'

-

-jobs:

- syncconfig:

- runs-on: ubuntu-latest

- steps:

- # checkout done so that files in the repo can be read by the sync

- - uses: actions/checkout@v1

- - uses: azure/appconfiguration-sync@v1

- with:

- configurationFile: 'appsettings.json'

- format: 'json'

- # Replace <ConnectionString> with the name of the secret in your

- # repository

- connectionString: ${{ secrets.<ConnectionString> }}

- separator: ':'

-```

-## Use strict sync

-By default the GitHub Action does not enable strict mode, meaning that the sync will only add key-values from the configuration file to the App Configuration instance (no key-value pairs will be deleted). Enabling strict mode will mean key-value pairs that aren't in the configuration file are deleted from the App Configuration instance, so that it matches the configuration file. If you are syncing from multiple sources or using Azure Key Vault with App Configuration, you'll want to use different prefixes or labels with strict sync to avoid wiping out configuration settings from other files (see samples below).

-```json

-on:

- push:

- branches:

- - 'main'

- paths:

- - 'appsettings.json'

-

-jobs:

- syncconfig:

- runs-on: ubuntu-latest

- steps:

- # checkout done so that files in the repo can be read by the sync

- - uses: actions/checkout@v1

- - uses: azure/appconfiguration-sync@v1

- with:

- configurationFile: 'appsettings.json'

- format: 'json'

- # Replace <ConnectionString> with the name of the secret in your

- # repository

- connectionString: ${{ secrets.<ConnectionString> }}

- separator: ':'

- label: 'Label'

- prefix: 'Prefix:'

- strict: true

-```

-## Sync multiple files in one action

-If your configuration is in multiple files, you can use the pattern below to trigger a sync when either file is modified. This pattern uses the glob library https://www.npmjs.com/package/glob . Note that if your config file name contains a comma, you can use a backslash to escape the comma.

-```json

-on:

- push:

- branches:

- - 'main'

- paths:

- - 'appsettings.json'

- - 'appsettings2.json'

-jobs:

- syncconfig:

- runs-on: ubuntu-latest

- steps:

- # checkout done so that files in the repo can be read by the sync

- - uses: actions/checkout@v1

- - uses: azure/appconfiguration-sync@v1

- with:

- configurationFile: '{appsettings.json,appsettings2.json}'

- format: 'json'

- # Replace <ConnectionString> with the name of the secret in your repository

- connectionString: ${{ secrets.<ConnectionString> }}

- separator: ':'

-```

-## Sync by prefix or label

-Specifying prefixes or labels in your sync action will sync only that particular set. This is important for using strict sync with multiple files. Depending on how the configuration is set up, either a prefix or a label can be associated with each file and then each prefix or label can be synced separately so that nothing is overwritten. Typically prefixes are used for different applications or services and labels are used for different environments.

-Sync by prefix:

-```json

-on:

- push:

- branches:

- - 'main'

- paths:

- - 'appsettings.json'

-jobs:

- syncconfig:

- runs-on: ubuntu-latest

- steps:

- # checkout done so that files in the repo can be read by the sync

- - uses: actions/checkout@v1

- - uses: azure/appconfiguration-sync@v1

- with:

- configurationFile: 'appsettings.json'

- format: 'json'

- # Replace <ConnectionString> with the name of the secret in your repository

- connectionString: ${{ secrets.<ConnectionString> }}

- separator: ':'

- prefix: 'Prefix::'

-```

-Sync by label:

-```json

-on:

- push:

- branches:

- - 'main'

- paths:

- - 'appsettings.json'

-jobs:

- syncconfig:

- runs-on: ubuntu-latest

- steps:

- # checkout done so that files in the repo can be read by the sync

- - uses: actions/checkout@v1

- - uses: azure/appconfiguration-sync@v1

- with:

- configurationFile: 'appsettings.json'

- format: 'json'

- # Replace <ConnectionString> with the name of the secret in your repository

- connectionString: ${{ secrets.<ConnectionString> }}

- separator: ':'

- label: 'Label'

-```

-## Use a dynamic label on sync

-The following action inserts a dynamic label on each sync, ensuring that each sync can be uniquely identified and allowing code changes to be mapped to config changes.

-The first section of this workflow specifies that the action triggers *on* a *push* containing `appsettings.json` to the *main* branch. The second section runs a job that creates a unique label for the config update based on the commit hash. The job then updates the App Configuration instance with the new values and the unique label for this update.

-```json

-on:

- push:

- branches:

- - 'main'

- paths:

- - 'appsettings.json'

-

-jobs:

- syncconfig:

- runs-on: ubuntu-latest

- steps:

- # Creates a label based on the branch name and the first 8 characters

- # of the commit hash

- - id: determine_label

- run: echo ::set-output name=LABEL::"${GITHUB_REF#refs/*/}/${GITHUB_SHA:0:8}"

- # checkout done so that files in the repo can be read by the sync

- - uses: actions/checkout@v1

- - uses: azure/appconfiguration-sync@v1

- with:

- configurationFile: 'appsettings.json'

- format: 'json'

- # Replace <ConnectionString> with the name of the secret in your

- # repository

- connectionString: ${{ secrets.<ConnectionString> }}

- separator: ':'

- label: ${{ steps.determine_label.outputs.LABEL }}

-```

-## Use Azure Key Vault with GitHub Action

-Developers using Azure Key Vault with AppConfiguration should use two separate files, typically an appsettings.json and a secretreferences.json. The secretreferences.json will contain the url to the key vault secret.

-{

- "mySecret": "{\"uri\":\"https://myKeyVault.vault.azure.net/secrets/mySecret"}"

-}

-The GitHub Action can then be configured to do a strict sync on the appsettings.json, followed by a non-strict sync on secretreferences.json. The following sample will trigger a sync when either file is updated:

-```json

-on:

- push:

- branches:

- - 'main'

- paths:

- - 'appsettings.json'

- - 'secretreferences.json'

-jobs:

- syncconfig:

- runs-on: ubuntu-latest

- steps:

- # checkout done so that files in the repo can be read by the sync

- - uses: actions/checkout@v1

- - uses: azure/appconfiguration-sync@v1

- with:

- configurationFile: 'appsettings.json'

- format: 'json'

- # Replace <ConnectionString> with the name of the secret in your repository

- connectionString: ${{ secrets.<ConnectionString> }}

- separator: ':'

- strict: true

- - uses: azure/appconfiguration-sync@v1

- with:

- configurationFile: 'secretreferences.json'

- format: 'json'

- # Replace <ConnectionString> with the name of the secret in your repository

- connectionString: ${{ secrets.<ConnectionString> }}

- separator: ':'

- contentType: 'application/vnd.microsoft.appconfig.keyvaultref+json;charset=utf-8'

-```

-## Use max depth to limit GitHub Action

-The default behavior for nested JSON attributes is to flatten the entire object. The JSON below defines this key-value pair:

-| Key | Value |

-| | |

-| Object:Inner:InnerKey | InnerValue |

-```json

-{ "Object":

- { "Inner":

- {

- "InnerKey": "InnerValue"

- }

- }

-}

-```

-If the nested object is intended to be the value pushed to the Configuration instance, you can use the *depth* value to stop the flattening at the appropriate depth.

-```json

-on:

- push:

- branches:

- - 'main'

- paths:

- - 'appsettings.json'

-

-jobs:

- syncconfig:

- runs-on: ubuntu-latest

- steps:

- # checkout done so that files in the repo can be read by the sync

- - uses: actions/checkout@v1

- - uses: azure/appconfiguration-sync@v1

- with:

- configurationFile: 'appsettings.json'

- format: 'json'

- # Replace <ConnectionString> with the name of the secret in your

- # repository

- connectionString: ${{ secrets.<ConnectionString> }}

- separator: ':'

- depth: 2

-```

-Given a depth of 2, the example above now returns the following key-value pair:

-| Key | Value |

-| | |

-| Object:Inner | {"InnerKey":"InnerValue"} |

-## Understand action inputs

-Input parameters specify data used by the action during runtime. The following table contains input parameters accepted by App Configuration Sync and the expected values for each. For more information about action inputs for GitHub Actions, see GitHub's [documentation](https://docs.github.com/en/actions/creating-actions/metadata-syntax-for-github-actions#inputs).

-> [!Note]

-> Input IDs are case insensitive.

-| Input name | Required? | Value |

-|-|-|-|

-| configurationFile | Yes | Relative path to the configuration file in the repository. Glob patterns are supported and can include multiple files. |

-| format | Yes | File format of the configuration file. Valid formats are: JSON, YAML, properties. |

-| connectionString | Yes | Read-write connection string for the App Configuration instance. The connection string should be stored as a secret in the GitHub repository, and only the secret name should be used in the workflow. |

-| separator | Yes | Separator used when flattening the configuration file to key-value pairs. Valid values are: . , ; : - _ __ / |

-| prefix | No | Prefix to be added to the start of keys. |

-| label | No | Label used when setting key-value pairs. If unspecified, a null label is used. |

-| strict | No | A boolean value that determines whether strict mode is enabled. The default value is false. |

-| depth | No | Max depth for flattening the configuration file. Depth must be a positive number. The default will have no max depth. |

-| tags | No | Specifies the tag set on key-value pairs. The expected format is a stringified form of a JSON object of the following shape: { [propertyName: string]: string; } Each property name-value becomes a tag. |

-## Next steps

-In this article, you learned about the App Configuration Sync GitHub Action and how it can be used to automate updates to your App Configuration instance. To learn how Azure App Configuration reacts to changes in key-value pairs, continue to the next [article](./concept-app-configuration-event.md).

-App Configuration offers the option to bulk [import](./howto-import-export-data.md) your configuration settings from your current configuration files using either the Azure portal or CLI. You can also use the same options to export key-values from App Configuration, for example between related stores. If youΓÇÖd like to set up an ongoing sync with your repo in GitHub or Azure DevOps, you can use our [GitHub Action](./concept-github-action.md) or [Azure Pipeline Push Task](./push-kv-devops-pipeline.md) so that you can continue using your existing source control practices while getting the benefits of App Configuration.

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

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

-Every request to an Azure App Configuration resource must be authenticated. By default, requests can be authenticated with either Microsoft Entra credentials, or by using an access key. Of these two types of authentication schemes, Microsoft Entra ID provides superior security and ease of use over access keys, and is recommended by Microsoft. To require clients to use Microsoft Entra ID to authenticate requests, you can disable the usage of access keys for an Azure App Configuration resource.

-When you disable access key authentication for an Azure App Configuration resource, any existing access keys for that resource are deleted. Any subsequent requests to the resource using the previously existing access keys will be rejected. Only requests that are authenticated using Microsoft Entra ID will succeed. For more information about using Microsoft Entra ID, see [Authorize access to Azure App Configuration using Microsoft Entra ID](./concept-enable-rbac.md).

-## Disable access key authentication

-Disabling access key authentication will delete all access keys. If any running applications are using access keys for authentication, they will begin to fail once access key authentication is disabled. Enabling access key authentication again will generate a new set of access keys and any applications attempting to use the old access keys will still fail.

-2. Locate the **Access settings** setting under **Settings**.

-3. Set the **Enable access keys** toggle to **Disabled**.

-The capability to disable access key authentication using the Azure CLI is in development.

-2. Locate the **Access settings** setting under **Settings**.

-3. Verify there are no access keys displayed and **Enable access keys** is toggled to **Disabled**.

-To verify access key authentication is disabled for an Azure App Configuration resource in the Azure portal, use the following command. The command will list the access keys for an Azure App Configuration resource and if access key authentication is disabled the list will be empty.

-If access key authentication is disabled, then an empty list will be returned.

-```

-C:\Users\User>az appconfig credential list -g <resource-group> -n <app-configuration-name>

-[]

-```

-This article provides a guide for importing and exporting data with App Configuration. If youΓÇÖd like to set up an ongoing sync with your GitHub repo, take a look at [GitHub Actions](./concept-github-action.md) and [Azure Pipelines tasks](./pull-key-value-devops-pipeline.md).

-You can import or export data using either the [Azure portal](https://portal.azure.com) or the [Azure CLI](./scripts/cli-import.md).

-| **Lastest Redis Version** | Redis 6.0 (GA) | Redis 6.2 (GA) / Redis 7.2 (Preview)|

-Agent based scraping currently has the limitations in the following table:

-To avoid metrics ingestion throttling, you can monitor and set up an alert on the ingestion limits. See [Monitor ingestion limits](../essentials/prometheus-metrics-overview.md#how-can-i-monitor-the-service-limits-and-quota).

- >- Once you deny access, you can still access the vault, but you can't move data to/from networks that don't contain private endpoints. For more information, see [Create private endpoints for Azure Backup](#create-private-endpoints-for-azure-backup).

- >- Denial of public access is currently not supported for vaults that have *Cross Region Restore* enabled.

-The articles in this section are intended for professionals interested in using Nutanix Cloud Clusters (NC2) on Azure.

-Email [NC2-on-Azure Docs](mailto:AzNutanixPM@microsoft.com) to provide input.

-In particular, this article highlights NC2 features.

-### SKUs

-We offer two SKUs: AN36 and AN36P. For specifications, see [SKUs](skus.md).

-On-premises Nutanix environments require the Nutanix customer to support all the hardware and software for running the platform.

-For NC2 on Azure, Microsoft maintains the hardware for the customer.

-For more information, see [NC2 on Azure responsibility matrix](nc2-on-azure-responsibility-matrix.md).

-> [Use cases and supported scenarios](use-cases-and-supported-scenarios.md)

-The following diagram describes the architectural components of the Azure VMware Solution.

-> [Requirements](requirements.md)

-Once you've satisfied the [requirements](requirements.md), go to

-[Nutanix Cloud Clusters

-on Azure Deployment and User Guide](https://portal.nutanix.com/page/documents/details?targetId=Nutanix-Cloud-Clusters-Azure:Nutanix-Cloud-Clusters-Azure) to sign up.

-> [About NC2 on Azure](about-nc2-on-azure.md)

-description: Learn about the features BareMetal Infrastructure offers for NC2 workloads.

-# What is BareMetal Infrastructure for Nutanix Cloud Clusters on Azure?

-In this article, we'll give an overview of the features BareMetal Infrastructure offers for Nutanix workloads.

-Nutanix Cloud Clusters (NC2) on Microsoft Azure provides a hybrid cloud solution that operates as a single cloud, allowing you to manage applications and infrastructure in your private cloud and Azure. With NC2 running on Azure, you can seamlessly move your applications between on-premises and Azure using a single management console. With NC2 on Azure, you can use your existing Azure accounts and networking setup (VPN, VNets, and Subnets), eliminating the need to manage any complex network overlays. With this hybrid offering, you use the same Nutanix software and licenses across your on-premises cluster and Azure to optimize your IT investment efficiently.

-You use the NC2 console to create a cluster, update the cluster capacity (the number of nodes), and delete a Nutanix cluster. After you create a Nutanix cluster in Azure using NC2, you can operate the cluster in the same manner as you operate your on-premises Nutanix cluster with minor changes in the Nutanix command-line interface (nCLI), Prism Element and Prism Central web consoles, and APIs.

-## Supported protocols

-The following protocols are used for different mount points within BareMetal servers for Nutanix workload.

-## Licensing

-You can bring your own on-premises capacity-based Nutanix licenses (CBLs).

-Alternatively, you can purchase licenses from Nutanix or from Azure Marketplace.

-## Operating system and hypervisor

-NC2 runs Nutanix Acropolis Operating System (AOS) and Nutanix Acropolis Hypervisor (AHV).

-This functionality allows mixing of processor generations within an AHV cluster and ensures the ability to live-migrate between hosts.

-AOS abstracts kvm, virsh, qemu, libvirt, and iSCSI from the end-user and handles all backend configuration.

-Thus users can use Prism to manage everything they would want to manage, while not needing to be concerned with low-level management.

-## Next steps

-Learn more:

-> [!div class="nextstepaction"]

-> [Getting started with NC2 on Azure](get-started.md)

-description: Defines who's responsible for what for NC2 on Azure.

-# NC2 on Azure responsibility matrix

-NC2 on Azure implements a shared responsibility model that defines distinct roles and responsibilities of the three parties involved in the offering: the Customer, Microsoft and Nutanix.

-On-premises Nutanix environments require the Nutanix customer to support all the hardware and software for running the platform. For NC2 on Azure, Microsoft maintains the hardware for the customer.

-Microsoft manages the Azure BareMetal specialized compute hardware and its data and control plane platform for underlay network. Microsoft supports if the customers plan to bring their existing Azure Subscription, VNet, vWAN, etc.

-Nutanix covers the life-cycle management of Nutanix software (MCM, Prism Central/Element, etc.) and their licenses.

-**Monitoring and remediation**

-Microsoft continuously monitors the health of the underlay and BareMetal infrastructure. If Microsoft detects a failure, it takes action to repair the failed services.

-description: Learn what you need to run NC2 on Azure, including Azure, Nutanix, networking, and other requirements.

-# Requirements

-This article assumes prior knowledge of the Nutanix stack and Azure services to operate significant deployments on Azure.

-The following sections identify the requirements to use Nutanix Clusters on Azure:

-## Azure account requirements

-* An Azure account with a new subscription

-* A Microsoft Entra directory

-## My Nutanix account requirements

-For more information, see "NC2 on Azure Subscription and Billing" in [Nutanix Cloud Clusters on Azure Deployment and User Guide]

-(https://portal.nutanix.com/page/documents/details?targetId=Nutanix-Cloud-Clusters-Azure:Nutanix-Cloud-Clusters-Azure).

-## Networking requirements

-* Connectivity between your on-premises datacenter and Azure. Both ExpressRoute and VPN are supported.

-* After a cluster is created, you'll need Virtual IP addresses for both the on-premises cluster and the cluster running in Azure.

-* Outbound internet access on your Azure portal.

-* Azure Directory Service resolves the FQDN:

-gateway-external-api.cloud.nutanix.com.

-## Other requirements

-* Minimum of three (or more) Azure Nutanix Ready nodes per cluster

-* Only the Nutanix AHV hypervisor on Nutanix clusters running in Azure

-* Prism Central instance deployed on NC2 on Azure to manage the Nutanix clusters in Azure

-## Next steps

-Learn more:

-> [!div class="nextstepaction"]

-> [Supported instances and regions](supported-instances-and-regions.md)

-description: Learn about SKU options for NC2 on Azure, including core, RAM, storage, and network.

-# SKUs

-This article identifies options associated with SKUs available for NC2 on Azure, including core, RAM, storage, and network.

-## Options

-The following table presents component options for each available SKU.

-| Component |Ready Node for Nutanix AN36|Ready Node for Nutanix AN36P|

-| :- | -: |::|

-|Core|Intel 6140, 36 Core, 2.3 GHz|Intel 6240, 36 Core, 2.6 GHz|

-|vCPUs|72|72|

-|RAM|576 GB|768 GB|

-|Storage|18.56 TB (8 x 1.92 TB SATA SSD, 2x1.6TB NVMe)|20.7 TB (2x750 GB Optane, 6x3.2-TB NVMe)|

-|Network (available bandwidth between nodes)|25 Gbps|25 Gbps|

-## Next steps

-Learn more:

-> [!div class="nextstepaction"]

-> [FAQ](faq.md)

-description: Learn about instances and regions supported for NC2 on Azure.

-# Supported instances and regions

-Learn about instances and regions supported for NC2 on Azure.

-## Supported instances

-Nutanix Clusters on Azure supports:

-* Minimum of three bare metal nodes per cluster.

-* Maximum of 28 bare metal nodes per cluster.

-* Only the Nutanix AHV hypervisor on Nutanix clusters running in Azure.

-* Prism Central instance deployed on Nutanix Clusters on Azure to manage the Nutanix clusters in Azure.

-## Supported regions

-NC2 on Azure supports the following regions using AN36:

-* East US

-* West US 2

-NC2 on Azure supports the following regions using AN36P:

-* North Central US

-* East US 2

-* Southeast Asia

-* Australia East

-* UK South

-* West Europe

-* Germany West Central

-* Japan East

-## Next steps

-Learn more:

-> [!div class="nextstepaction"]

-> [SKUs](skus.md)

-description: Learn about use cases and supported scenarios for NC2 on Azure, including cluster management, disaster recovery, on-demand elasticity, and lift-and-shift.

-# Use cases and supported scenarios

- Learn about use cases and supported scenarios for NC2 on Azure, including cluster management, disaster recovery, on-demand elasticity, and lift-and-shift.

-## Unified management experience - cluster management

-That operations and cluster management be nearly identical to on-premises is critical to customers.

-Customers can update capacity, monitor alerts, replace hosts, monitor usage, and more by combining the respective strengths of Microsoft and Nutanix.

-## Disaster recovery

-Disaster recovery is critical to cloud functionality.

-A disaster can be any of the following:

- ...or anything else that puts your operations at risk.

-When a disaster strikes, the goal of any DR plan is to ensure operations run as normally as possible.

-While the business will be aware of the crisis, ideally, its customers and end-users shouldn't be affected.

-## On-demand elasticity

-Scale up and scale out as you like.

-We provide the flexibility that means you don't have to procure hardware yourself - with just a click of a button you can get additional nodes in the cloud nearly instantly.

-## Lift and shift

-Move applications to the cloud and modernize your infrastructure.

-Applications move with no changes, allowing for flexible operations and minimum downtime.

-> [!div class="nextstepaction"]

-> [Architecture](architecture.md)

-| Windows¹, Linux² | [Network Isolation](#network-isolation) | Network disruption |

-| Supported OS types | Windows, Linux (outbound traffic only) |

-* The agent-based network faults currently only support IPv4 addresses.

-* When running on Windows, the network packet loss fault currently only works with TCP or UDP packets.

-* When running on Linux, this fault only affects **outbound** traffic, not inbound traffic. The fault affects **both inbound and outbound** traffic on Windows environments.

-> [!NOTE]

-> Call Automation currently doesn't support [Rooms](../rooms/room-concept.md) calls.

-| CallConnected | Your applicationΓÇÖs call leg is connected (inbound or outbound) |

-| CallDisconnected | Your applicationΓÇÖs call leg is disconnected |

-| CallTransferAccepted | Your applicationΓÇÖs call leg has been transferred to another endpoint |

-| CallTransferFailed | The transfer of your applicationΓÇÖs call leg failed |

-| AddParticipantSucceeded| Your application added a participant |

-| AddParticipantFailed | Your application was unable to add a participant |

-| CancelAddParticipantSucceeded| Your application canceled adding a participant |

-| CancelAddParticipantFailed | Your application was unable to cancel adding a participant |

-| RemoveParticipantSucceeded| Your application has successfully removed a participant from the call. |

-| RemoveParticipantFailed | Your application was unable to remove a participant from the call. |

-| ParticipantsUpdated | The status of a participant changed while your applicationΓÇÖs call leg was connected to a call |

-### Chat API request metric operations

-The following operations are available on Chat API request metrics:

-| Operation / Route | Description |

-| -- | - |

-| GetChatMessage | Gets a message by message ID. |

-| ListChatMessages | Gets a list of chat messages from a thread. |

-| SendChatMessage | Sends a chat message to a thread. |

-| UpdateChatMessage | Updates a chat message. |

-| DeleteChatMessage | Deletes a chat message. |

-| GetChatThread | Gets a chat thread. |

-| ListChatThreads | Gets the list of chat threads of a user. |

-| UpdateChatThread | Updates a chat thread's properties. |

-| CreateChatThread | Creates a chat thread. |

-| DeleteChatThread | Deletes a thread. |

-| GetReadReceipts | Gets read receipts for a thread. |

-| SendReadReceipt | Sends a read receipt event to a thread, on behalf of a user. |

-| SendTypingIndicator | Posts a typing event to a thread, on behalf of a user. |

-| ListChatThreadParticipants | Gets the members of a thread. |

-| AddChatThreadParticipants | Adds thread members to a thread. If members already exist, no change occurs. |

-| RemoveChatThreadParticipant | Remove a member from a thread. |

-If a request is made to an operation that isn't recognized, you receive a "Bad Route" value response.

-### SMS API requests

-The following operations are available on SMS API request metrics:

-| Operation / Route | Description |

-| -- | - |

-| SMSMessageSent | Sends an SMS message. |

-| SMSDeliveryReportsReceived | Gets SMS Delivery Reports |

-| SMSMessagesReceived | Gets SMS messages. |

-> [!NOTE]

-> Call Automation currently doesn't support [Rooms](../../concepts/rooms/room-concept.md) calls.

-> The Response action works only when you use the Request trigger.

-For example, this list describes some tasks that your workflow can perform when you use the Request trigger and Response action:

-* The logic app workflow where you want to receive the inbound HTTPS request. To start your workflow with a Request trigger, you have to start with a blank workflow. To use the Response action, your workflow must start with the Request trigger.

-The Request trigger creates a manually callable endpoint that handles *only* inbound requests over HTTPS. When the caller sends a request to this endpoint, the Request trigger fires and runs the workflow. For information about how to call this trigger, review [Call, trigger, or nest workflows with HTTPS endpoints in Azure Logic Apps](../logic-apps/logic-apps-http-endpoint.md).

- | **Request Body JSON Schema** | `schema` | No | The JSON schema that describes the properties and values in the incoming request body. The designer uses this schema to generate tokens for the properties in the request. That way, your workflow can parse, consume, and pass along outputs from the Request trigger into your workflow. <br><br>If you don't have a JSON schema, you can generate the schema from a sample payload by using the **Use sample payload to generate schema** capability. |

- 1. In the Request trigger, select **Use sample payload to generate schema**.

- 1. In the Request trigger's title bar, select the ellipses button (**...**).

- > when making a call to the Request trigger, use this encoded version instead: `%25%23`

- | **Request Body JSON Schema** | `schema` | No | The JSON schema that describes the properties and values in the incoming request body. The designer uses this schema to generate tokens for the properties in the request. That way, your workflow can parse, consume, and pass along outputs from the Request trigger into your workflow. <br><br>If you don't have a JSON schema, you can generate the schema from a sample payload by using the **Use sample payload to generate schema** capability. |

- 1. In the Request trigger, select **Use sample payload to generate schema**.

- 1. On the designer, select the Request trigger. On the information pane that opens, select the **Settings** tab.

- > when making a call to the Request trigger, use this encoded version instead: `%25%23`

- > The URL for the Request trigger is associated with your workflow's storage account. This URL

- > the Request trigger also changes to reflect the new storage account. The same workflow has a different URL.

-The following table lists the outputs from the Request trigger:

-When you use the Request trigger to receive inbound requests, you can model the response and send the payload results back to the caller by using the Response built-in action, which works *only* with the Request trigger. This combination with the Request trigger and Response action creates the [request-response pattern](https://en.wikipedia.org/wiki/Request%E2%80%93response). Except for inside Foreach loops and Until loops, and parallel branches, you can add the Response action anywhere in your workflow.

- For simplicity, the following examples show a collapsed Request trigger.

-To test your workflow, send an HTTP request to the generated URL. For example, you can use local tools or apps such as [Insomnia](https://insomnia.rest/) or [Bruno](https://www.usebruno.com/) to send the HTTP request.

-For more information about the trigger's underlying JSON definition and how to call this trigger, see these topics, [Request trigger type](../logic-apps/logic-apps-workflow-actions-triggers.md#request-trigger) and [Call, trigger, or nest workflows with HTTP endpoints in Azure Logic Apps](../logic-apps/logic-apps-http-endpoint.md).

-In a Standard logic app workflow that starts with the Request trigger (but not a webhook trigger), you can use the Azure Functions provision for authenticating inbound calls sent to the endpoint created by that trigger by using a managed identity. This provision is also known as "**Easy Auth**". For more information, review [Trigger workflows in Standard logic apps with Easy Auth](https://techcommunity.microsoft.com/t5/integrations-on-azure-blog/trigger-workflows-in-standard-logic-apps-with-easy-auth/ba-p/3207378).

-As you configure your cluster, you'll carry out these actions:

-| Logs | Log Analytics must be configured with cluster extension; not per-site |

-| `<extensionName>-k8se-envoy` | A front-end proxy layer for all data-plane http requests. It routes the inbound traffic to the correct apps. | 3 | 1 Core | 1536 MB | ReplicaSet |

-| `<extensionName>-k8se-keda-metrics-apiserver` | KEDA Metrics Server | 1 | 1 Core | 1000 MB | ReplicaSet |

-By default, logs from system components are sent to the Azure team. Application logs aren't sent. You can prevent these logs from being transferred by setting `logProcessor.enabled=false` as an extension configuration setting. This configuration setting will also disable forwarding of application to your Log Analytics workspace. Disabling the log processor might affect the time needed for any support cases, and you'll be asked to collect logs from standard output through some other means.

-### Can I deploy the Container Apps extension on an ARM64 based cluster?

-ARM64 based clusters aren't supported at this time.

-<tr><td><code>serverStatus</code></td><td><img src="media/compatibility/yes-icon.svg" alt="Yes"></td><td><img src="media/compatibility/yes-icon.svg" alt="Yes"></td><td><img src="media/compatibility/yes-icon.svg" alt="Yes"></td></tr>

-This article discusses migration away from the [Consumption Usage Details API](/rest/api/consumption/usage-details/list). The Consumption Usage Details API is deprecated. The date that the API will be turned off is still being determined. We recommend that you migrate away from the API as soon as possible.

-If you have a smaller usage details dataset or a scenario that isn't met by Exports, consider using the [Cost Details](/rest/api/cost-management/generate-cost-details-report) report instead. For more information, see [Get small cost datasets on demand](get-small-usage-datasets-on-demand.md).

-Enterprise Agreement customers who are using the Consumption Usage Details API have usage details records of the kind `legacy`. A legacy usage details record is shown below. All Enterprise Agreement customers have records of this kind due to the underlying billing system that's used for them.

-Microsoft Customer Agreement customers that use the Consumption Usage Details API have usage details records of the kind `modern`. A modern usage details record is shown below. All Microsoft Customer Agreement customers have records of this kind due to the underlying billing system that is used for them.

-An full example legacy Usage Details record is shown at [Usage Details - List - REST API (Azure Consumption)](/rest/api/consumption/usage-details/list#billingaccountusagedetailslist-modern)

-# Get started

-This article introduces guidance to help you design a solution for securing and protecting your multicloud environment with Microsoft Defender for Cloud. The guidance can be used by cloud solution and infrastructure architects, security architects and analysts, and anyone else involved in designing a multicloud security solution.

-description: Independent software vendors (ISVs) can integrate their solutions with Microsoft Defender for Cloud to help customers adopt a Zero Trust model and keep their organizations secure.

-# Zero Trust infrastructure and integrations

-Infrastructure comprises the hardware, software, micro-services, networking infrastructure, and facilities required to support IT services for an organization. Zero Trust infrastructure solutions assess, monitor, and prevent security threats to these services.

-Zero Trust infrastructure solutions support the principles of Zero Trust by ensuring that access to infrastructure resources is verified explicitly, access is granted using principles of least privilege access, and mechanisms are in place that assumes breach and look for and remediate security threats in infrastructure.

-This guidance is for software providers and technology partners who want to enhance their infrastructure security solutions by integrating with Microsoft products.

-## Zero Trust integration for Infrastructure guide

-This integration guide includes strategy and instructions for integrating with [Microsoft Defender for Cloud](defender-for-cloud-introduction.md) and its integrated cloud workload protection platform (CWPP), Microsoft Defender for Cloud.

-The guidance includes integrations with the most popular Security Information and Event Management (SIEM), Security Orchestration Automated Response (SOAR), Endpoint Detection and Response (EDR), and IT Service Management (ITSM) solutions.

-### Zero Trust and Defender for Cloud

-Our [Zero Trust infrastructure deployment guidance](/security/zero-trust/deploy/infrastructure) provides key stages of the Zero Trust strategy for infrastructure. Which are:

-1. [Assess compliance with chosen standards and policies](update-regulatory-compliance-packages.yml)

-1. [Harden configuration](recommendations-reference.md) wherever gaps are found

-1. Employ other hardening tools such as [just-in-time (JIT)](just-in-time-access-usage.yml) VM access

-1. Set up [threat detection and protections](/azure/azure-sql/database/threat-detection-configure)

-1. Automatically block and flag risky behavior and take protective actions

-There's a clear mapping from the goals we've described in the [infrastructure deployment guidance](/security/zero-trust/deploy/infrastructure) to the core aspects of Defender for Cloud.

-|Zero Trust goal | Defender for Cloud feature |

-|Assess compliance | In Defender for Cloud, every subscription automatically has the [Microsoft cloud security benchmark (MCSB) security initiative assigned](security-policy-concept.md).<br>Using the [secure score tools](secure-score-security-controls.md) and the [regulatory compliance dashboard](update-regulatory-compliance-packages.yml) you can get a deep understanding of your customer's security posture. |

-| Harden configuration | [Review your security recommendations](review-security-recommendations.md) and [track your secure score improvement overtime](secure-score-access-and-track.md). You can also prioritize which recommendations to remediate based on potential attack paths, by leveraging the [attack path](how-to-manage-attack-path.md) feature. |

-|Employ hardening mechanisms | Least privilege access is one of the three principles of Zero Trust. Defender for Cloud can assist you to harden VMs and network using this principle by leveraging features such as:<br>[Just-in-time (JIT) virtual machine (VM) access](just-in-time-access-overview.md)<br>[Adaptive network hardening](adaptive-network-hardening.md)<br>[Adaptive application controls](adaptive-application-controls.md). |

-|Set up threat detection | Defender for Cloud offers an integrated cloud workload protection platform (CWPP), Microsoft Defender for Cloud.<br>Microsoft Defender for Cloud provides advanced, intelligent, protection of Azure and hybrid resources and workloads.<br>One of the Microsoft Defender plans, Microsoft Defender for servers, includes a native integration with [Microsoft Defender for Endpoint](/microsoft-365/security/defender-endpoint/).<br>Learn more in [Introduction to Microsoft Defender for Cloud](defender-for-cloud-introduction.md). |

-|Automatically block suspicious behavior | Many of the hardening recommendations in Defender for Cloud offer a *deny* option. This feature lets you prevent the creation of resources that don't satisfy defined hardening criteria. Learn more in [Prevent misconfigurations with Enforce/Deny recommendations](./prevent-misconfigurations.md). |

-|Automatically flag suspicious behavior | Microsoft Defenders for Cloud's security alerts are triggered by advanced detections. Defender for Cloud prioritizes and lists the alerts, along with the information needed for you to quickly investigate the problem. Defender for Cloud also provides detailed steps to help you remediate attacks. For a full list of the available alerts, see [Security alerts - a reference guide](alerts-reference.md).|

-### Protect your Azure PaaS services with Defender for Cloud

-With Defender for Cloud enabled on your subscription, and Microsoft Defender for Cloud enabled for all available resource types, you'll have a layer of intelligent threat protection - powered by [Microsoft Threat Intelligence](https://go.microsoft.com/fwlink/?linkid=2128684) - protecting resources in Azure Key Vault, Azure Storage, Azure DNS, and other Azure PaaS services. For a full list, see [What resource types can Microsoft Defender for Cloud secure?](defender-for-cloud-introduction.md).

-### Azure Logic Apps

-### Integrate Defender for Cloud with your SIEM, SOAR, and ITSM solutions

-Microsoft Defender for Cloud can stream your security alerts into the most popular Security Information and Event Management (SIEM), Security Orchestration Automated Response (SOAR), and IT Service Management (ITSM) solutions.

-There are Azure-native tools for ensuring you can view your alert data in all of the most popular solutions in use today, including:

-#### Microsoft Sentinel

-Defender for Cloud natively integrates with [Microsoft Sentinel](../sentinel/overview.md), Microsoft's cloud-native, security information event management (SIEM) and security orchestration automated response (SOAR) solution.

-There are two approaches to ensuring your Defender for Cloud data is represented in Microsoft Sentinel:

-#### Stream alerts with Microsoft Graph Security API

-You can use this API to stream alerts from the **entire tenant** (and data from many other Microsoft Security products) into third-party SIEMs and other popular platforms:

-[Learn more about Microsoft Graph Security API](https://www.microsoft.com/security/business/graph-security-api).

-#### Stream alerts with Azure Monitor

-Use Defender for Cloud's [continuous export](continuous-export.md) feature to connect Defender for Cloud with Azure monitor via Azure Event Hubs and stream alerts into **ArcSight**, **SumoLogic**, Syslog servers, **LogRhythm**, **Logz.io Cloud Observability Platform**, and other monitoring solutions.

-Learn more in [Stream alerts to monitoring solutions](export-to-siem.md).

-This can also be done at the Management Group level using Azure Policy, see [Create continuous export automation configurations at scale](continuous-export.md).

-> [!TIP]

-> To view the event schemas of the exported data types, visit the [Event Hub event schemas](https://aka.ms/ASCAutomationSchemas).

-### Integrate Defender for Cloud with an Endpoint Detection and Response (EDR) solution

-#### Microsoft Defender for Endpoint

-[Microsoft Defender for Endpoint](/microsoft-365/security/defender-endpoint/) is a holistic, cloud-delivered endpoint security solution.

-Defender for Cloud's integrated CWPP for machines, [Microsoft Defender for Servers](plan-defender-for-servers.md), includes an integrated license for [Microsoft Defender for Endpoint](https://www.microsoft.com/security/business/endpoint-security/microsoft-defender-endpoint). Together, they provide comprehensive endpoint detection and response (EDR) capabilities. For more information, see [Protect your endpoints](integration-defender-for-endpoint.md?tabs=linux).

-When Defender for Endpoint detects a threat, it triggers an alert. The alert is shown in Defender for Cloud. From Defender for Cloud, you can also pivot to the Defender for Endpoint console and perform a detailed investigation to uncover the scope of the attack. Learn more about [Microsoft Defender for Endpoint](/microsoft-365/security/defender-endpoint/microsoft-defender-endpoint).

-#### Other EDR solutions

-Defender for Cloud provides hardening recommendations to ensure you're securing your organization's resources according to the guidance of [Azure Security Benchmark](/security/benchmark/azure/introduction). One of the controls in the benchmark relates to endpoint security: [ES-1: Use Endpoint Detection and Response (EDR)](/security/benchmark/azure/security-controls-v2-endpoint-security).

-There are two recommendations in Defender for Cloud to ensure you've enabled endpoint protection and it's running well. These recommendations are checking for the presence and operational health of EDR solutions from:

-Learn more in [Endpoint protection assessment and recommendations in Microsoft Defender for Cloud](endpoint-protection-recommendations-technical.md).

-### Apply your Zero Trust strategy to hybrid and multicloud scenarios

-With cloud workloads commonly spanning multiple cloud platforms, cloud security services must do the same.

-Microsoft Defender for Cloud protects workloads wherever they're running: in Azure, on-premises, Amazon Web Services (AWS), or Google Cloud Platform (GCP).

-#### Integrate Defender for Cloud with on-premises machines

-To secure hybrid cloud workloads, you can extend Defender for Cloud's protections by connecting on-premises machines to [Azure Arc enabled servers](../azure-arc/servers/overview.md).

-Learn about how to connect machines in [Connect your non-Azure machines to Defender for Cloud](quickstart-onboard-machines.md).

-#### Integrate Defender for Cloud with other cloud environments

-To view the security posture of **Amazon Web Services** machines in Defender for Cloud, onboard AWS accounts into Defender for Cloud. This integrates AWS Security Hub and Microsoft Defender for Cloud for a unified view of Defender for Cloud recommendations and AWS Security Hub findings and provides a range of benefits as described in [Connect your AWS accounts to Microsoft Defender for Cloud](quickstart-onboard-aws.md).

-To view the security posture of **Google Cloud Platform** machines in Defender for Cloud, onboard GCP accounts into Defender for Cloud. This integrates GCP Security Command and Microsoft Defender for Cloud for a unified view of Defender for Cloud recommendations and GCP Security Command Center findings and provides a range of benefits as described in [Connect your GCP accounts to Microsoft Defender for Cloud](quickstart-onboard-gcp.md).

-To learn more about Microsoft Defender for Cloud and Microsoft Defender for Cloud, see the complete [Defender for Cloud documentation](index.yml).

- | Microsoft Remote Desktop | a4a365df-50f1-4397-bc59-1a1564b8bb9c | Used to authenticate users to the dev box. <br>Only needed when you configure single sign-on in a provisioning policy. |

-3. On the **New migration project** page, specify a name for the project, in the Source server type selection box, select **Azure Database For MySQL ΓÇô Single Server**, in the Target server type selection box, select **Azure Database For MySQL**, in the **Migration activity type** selection box, select **Online migration**, and then select **Create and run activity**.

- > [!NOTE]

- :::image type="content" source="media/tutorial-azure-mysql-single-to-flex-offline/12-create-project-offline.png" alt-text="Screenshot of a Create a new migration project.":::

-This article provides the properties and schema for communication services advanced messaging events. For an introduction to event schemas, see [Azure Event Grid event schema](event-schema.md).

-| Event type | Description |

-| -- | - |

-| Microsoft.Communication.AdvancedMessageReceived | Published when Communication Service receives a WhatsApp message. |

-| Microsoft.Communication.AdvancedMessageDeliveryStatusUpdated | Published when the WhatsApp sends status of message notification as sent/read/failed. |

-### Microsoft.Communication.AdvancedMessageReceived event

- "id": "fdc64eca-390d-4974-abd6-1a13ccbe3160",

- "topic": "/subscriptions/{subscription-id}/resourcegroups/{resourcegroup-name}/providers/microsoft.communication/communicationservices/acsxplatmsg-test",

- "subject": "advancedMessage/sender/{sender@id}/recipient/00000000-0000-0000-0000-000000000000",

- "to": "00000000-0000-0000-0000-000000000000",

-### Microsoft.Communication.AdvancedMessageDeliveryStatusUpdated event

- "id": "48cd6446-01dd-479f-939c-171c86c46700",

- "topic": "/subscriptions/{subscription-id}/resourcegroups/{resourcegroup-name}/providers/microsoft.communication/communicationservices/acsxplatmsg-test",

- "subject": "advancedMessage/00000000-0000-0000-0000-000000000000/status/Failed",

- "messageId": "00000000-0000-0000-0000-000000000000",

- "id": "48cd6446-01dd-479f-939c-171c86c46700",

- "subject": "advancedMessage/00000000-0000-0000-0000-000000000000/status/Failed",

- "messageId": "00000000-0000-0000-0000-000000000000",

-> [!NOTE]

-> Possible values for `Status` are `Sent`, `Delivered`, `Read` and `Failed`.

-> This quick start provides step-by-step instructions to implement a simple scenario of sending a batch of messages to an Event Grid Namespace Topic and then receiving them. For an overview of the .NET client library, see [Azure Event Grid client library for .NET](https://github.com/Azure/azure-sdk-for-net/blob/Azure.Messaging.EventGrid_4.17.0-beta.1/sdk/eventgrid/Azure.Messaging.EventGridV2/src/Generated/EventGridClient.cs). For more samples, see [Event Grid .NET samples on GitHub](https://github.com/Azure/azure-sdk-for-net/tree/feature/eventgrid/namespaces/sdk/eventgrid/Azure.Messaging.EventGrid/samples).

-ExpressRoute and other hybrid networking services--VPN and vWAN--supports a maximum MTU of 1400 bytes.

-You can configure Azure Firewall Destination Network Address Translation (DNAT) to translate and filter inbound Internet traffic to your subnets. When you configure DNAT, the NAT rule collection action is set to **Dnat**. Each rule in the NAT rule collection can then be used to translate your firewall public IP address and port to a private IP address and port. DNAT rules implicitly add a corresponding network rule to allow the translated traffic. For security reasons, the recommended approach is to add a specific Internet source to allow DNAT access to the network and avoid using wildcards. To learn more about Azure Firewall rule processing logic, see [Azure Firewall rule processing logic](rule-processing.md).

- Management Group when it's created. To avoid the hurdle of finding the Azure AD Global Admins to

- Management Group when it's created. To avoid the hurdle of finding the Azure AD Global Admins to

- Management Group when it's created. To avoid the hurdle of finding the Azure AD Global Admins to

- Management Group when it's created. To avoid the hurdle of finding the Azure AD Global Admins to

- Management Group when it's created. To avoid the hurdle of finding the Azure AD Global Admins to

- Management Group when it's created. To avoid the hurdle of finding the Azure AD Global Admins to

- Management Group when it's created. To avoid the hurdle of finding the Azure AD Global Admins to

- Management Group when it's created. To avoid the hurdle of finding the Azure AD Global Admins to

-**/providers/Microsoft.Management/managementgroups/{_groupId_}**.

- "Microsoft.Management/managementgroups/delete",

- "Microsoft.Management/managementgroups/read",

- "Microsoft.Management/managementgroup/write",

- "Microsoft.Management/managementgroup/subscriptions/delete",

- "Microsoft.Management/managementgroup/subscriptions/write",

-Multi-region replication allows you to extend a managed HSM pool from one Azure region (called a primary) to another Azure region (called a secondary). Once configured, both regions are active, able to serve requests and, with automated replication, share the same key material, roles, and permissions. The closest available region to the application receives and fulfills the request, thereby maximizing read throughput and latency. While regional outages are rare, multi-region replication enhances the availability of mission critical cryptographic keys should one region become unavailable. For more information on SLA, visit [SLA for Azure Key Vault Managed HSM](https://azure.microsoft.com/support/legal/sla/key-vault-managed-hsm/v1_0/).

-When multi-region replication is enabled on a managed HSM, a second managed HSM pool, with three load-balanced HSM partitions, is created in the secondary region. When requests are issued to the Traffic Manager global DNS endpoint `<hsm-name>.managedhsm.azure.net`, the closest available region receives and fulfills the request. While each region individually maintains regional high-availability due to the distribution of HSMs across the region, the traffic manager ensures that even if all partitions of a managed HSM in one region are unavailable due to a catastrophe, requests can still be served by the secondary managed HSM pool.

-| Secondary | Yes | Yes |

-| Primary | Yes | Maybe |

-If the secondary region becomes unavailable, read operations (get key, list keys, all crypto operations, list role assignments) are available if the primary region is alive. Write operations (create and update keys, create and update role assignments, create and update role definitions) are also available.

-Under the hood, DNS resolution handles the redirection of requests to either the primary or secondary region.

-> US Central, US East, US South Central, West US 2, Switzerland North, West Europe, Central India, Canada Central, Canada East, Japan West, Qatar Central, Poland Central and US West Central cannot be extended as a secondary region at this time. Other regions may be unavailable for extension due to capacity limitations in the region.

-Multi-region replication into secondary region incurs extra billing (x2), as a new HSM pool is consumed in the secondary region. For more information, see [Azure Managed HSM pricing](https://azure.microsoft.com/pricing/details/key-vault).

-The [Managed HSM soft-delete feature](soft-delete-overview.md) allows recovery of deleted HSMs and keys however in a multi-region replication enabled scenario, there are subtle differences where the secondary HSM must be deleted before soft-delete can be executed on the primary HSM. Additionally, when a secondary is deleted, it's purged immediately and doesn't go into a soft-delete state that stops all billing for the secondary. You can always extend to a new region as the secondary from the primary if needed.

-The [Azure Private Link feature](private-link.md) allows you to access the Managed HSM service over a private endpoint in your virtual network. You would configure private endpoint on the Managed HSM in the primary region just as you would when not using the multi-region replication feature. For the Managed HSM in the secondary region, it is recommended to create another private endpoint once the Managed HSM in the primary region is replicated to the Managed HSM in the secondary region. This will redirect client requests to the Managed HSM closest to the client location.

-Some scenarios below with examples: Managed HSM in a primary region (UK South) and another Managed HSM in a secondary region (US West Central).

-If creating a new Managed HSM pool and then extending to a secondary, refer to [these instructions](quick-create-cli.md#create-a-managed-hsm) prior to extending. If extending from an already existing Managed HSM pool, then use the following instructions to create a secondary HSM into another region.

-### Add a secondary HSM in another region

-To extend a managed HSM pool to another region, run the following command that will automatically create a second HSM.

-> "ContosoMHSM" in this example is the primary HSM pool name; "australiaeast" is the secondary region into which you are extending it.

-### Remove a secondary HSM in another region

-Once you remove a secondary HSM, the HSM partitions in the other region will be purged. All secondaries must be deleted before a primary managed HSM can be soft-deleted or purged. Only secondaries can be deleted using this command. The primary can only be deleted using the [soft-delete](soft-delete-overview.md#soft-delete-behavior) and [purge](soft-delete-overview.md#purge-protection) commands

-Before you start, make sure to [review and meet the SAP connector requirements](sap.md#prerequisites) for your specific scenario.

-To have your workflow receive IDocs from SAP over XML HTTP, you can use the [Request built-in trigger](../../connectors/connectors-native-reqres.md). This trigger creates an endpoint with a URL where your SAP server can send HTTP POST requests to your workflow. When your workflow receives these requests, the trigger fires and runs the next step in your workflow.

-Next, create an action to send your IDoc to SAP when the workflow's request trigger fires. Based on whether you have a Consumption workflow in multitenant Azure Logic Apps or a Standard workflow in single-tenant Azure Logic Apps, follow the corresponding steps:

-1. In the workflow designer, under the Request trigger, select **New step**.

- 1. In the **Send message to SAP** action, include the body output from the Request trigger.

- 1. From the dynamic content list, under **When a HTTP request is received**, select **Body**. The **Body** field contains the body output from the Request trigger.

- The **Send message to SAP** action now includes the body content from the Request trigger and sends that output to your SAP server, for example:

-1. In the workflow designer, under the Request trigger, select the plus sign (**+**) > **Add an action**.

- 1. From the dynamic content list, under **When a HTTP request is received**, select **Body**. The **Body** field contains the body output from the Request trigger.

- The **[IDoc] Send document to SAP** action now includes the body content from the Request trigger and sends that output to your SAP server, for example:

-For the Consumption workflows that use the SAP managed connector and ISE-versioned SAP connector, if you have to receive replies by using a remote function call (RFC) to Azure Logic Apps from SAP ABAP, you must implement a request and response pattern. To receive IDocs in your workflow when you use the [Request trigger](../../connectors/connectors-native-reqres.md), make sure that the workflow's first action is a [Response action](../../connectors/connectors-native-reqres.md#add-response) that uses the **200 OK** status code without any content. This recommended step immediately completes the SAP Logical Unit of Work (LUW) asynchronous transfer over tRFC, which leaves the SAP CPIC conversation available again. You can then add more actions to your workflow for processing the received IDoc without blocking later transfers.

-1. On the designer toolbar, select **Run Trigger** > **Run** to manually start your workflow.

-1. To simulate a webhook trigger payload, send an HTTP POST request to the endpoint URL that's specified by your workflow's Request trigger. Make sure to include your message content with your request. To send the request, use a local tool or app tool such as [Insomnia](https://insomnia.rest/) or [Bruno](https://www.usebruno.com/).

- For this example, the HTTP POST request sends an IDoc file, which must be in XML format and include the namespace for the SAP action that you selected, for example:

-1. To simulate a webhook trigger payload, send an HTTP POST request to the endpoint URL that's specified by your workflow's Request trigger. Make sure to your message content with your request. To send the request, use a local tool or app such as [Insomnia](https://insomnia.rest/) or [Bruno](https://www.usebruno.com/).

- For this example, the HTTP POST request sends an IDoc file, which must be in XML format and include the namespace for the SAP action that you selected, for example:

- For example, you can send a request with the `Accept-Language` header to your logic app workflow by using the Request trigger named **When a HTTP request is received**. All the actions in your workflow receive the header. Then, SAP uses the specified languages in its system messages, such as BAPI error messages. If you don't pass an `Accept-Language` header at run time, by default, English is used.

-1. Create and open a Consumption or Standard logic app with a blank workflow in the designer. Add the Request trigger.

-1. In the designer, after you add the Request trigger, and before you add the SAP action named **[IDOC] Send document to SAP**, add the action named **Initialize variable** to your workflow.

-1. On the designer toolbar, select **Run Trigger** > **Run** to manually start your workflow.

-1. To simulate a webhook trigger payload, send an HTTP POST request to the endpoint URL that's specified by your workflow's Request trigger. To send the request, use a local tool or app such as [Insomnia](https://insomnia.rest/) or [Bruno](https://www.usebruno.com/).

- For this example, the HTTP POST request sends an IDoc file, which must be in XML format and include the namespace for the SAP action that you selected, for example:

-1. To simulate a webhook trigger payload, send an HTTP POST request to the endpoint URL that's specified by your workflow's Request trigger. To send the request, use a local tool or app such as [Insomnia](https://insomnia.rest/) or [Bruno](https://www.usebruno.com/).

- For this example, the HTTP POST request sends an IDoc file, which must be in XML format and include the namespace for the SAP action that you selected, for example:

-* To test the example workflow in this guide, you need a local tool or app that can send calls to the endpoint created by the Request trigger. For example, you can use local tools such as [Insomnia](https://insomnia.rest/) or [Bruno](https://www.usebruno.com/) to send the HTTP request.

-This example workflow starts with the [built-in Request trigger](../connectors/connectors-native-reqres.md) named **When a HTTP request is received**. This trigger creates an endpoint that other services or logic app workflows can call and waits for those inbound calls or requests to arrive. Built-in operations run natively and directly within the Azure Logic Apps runtime.

-1. By using **request** as the search term, [follow these steps to add the built-in Request trigger named **When a HTTP request is received**](create-workflow-with-trigger-or-action.md?tabs=standard#add-trigger) to your workflow.

- When you save a workflow for the first time, and that workflow starts with a Request trigger, Azure Logic Apps automatically generates a URL for an endpoint that's created by the Request trigger. Later, when you test your workflow, you send a request to this URL, which fires the trigger and starts the workflow run.

-1. On your logic app menu, under **Settings**, select **Networking (preview)**.

-In this example, the workflow runs when the Request trigger receives an inbound request, which is sent to the URL for the endpoint that's created by the trigger. When you saved the workflow for the first time, Azure Logic Apps automatically generated this URL. So, before you can send this request to trigger the workflow, you need to find this URL.

-1. On the workflow designer, select the Request trigger that's named **When a HTTP request is received**.

-1. To test the URL by sending a request and triggering the workflow, open your preferred tool or app, and follow their instructions for creating and sending HTTP requests.

- For this example, use the **GET** method with the copied URL, which looks like the following sample:

-While the example workflow is cloud-based and has only two steps, you can create workflows from hundreds of operations that can connect a wide range of apps, data, services, and systems across cloud, on premises, and hybrid environments. The example workflow starts with the built-in Request trigger and follows with an Office 365 Outlook action. The trigger creates a callable endpoint for the workflow and waits for an inbound HTTPS request from any caller. When the trigger receives a request and fires, the next action runs by sending email to the specified email address along with selected outputs from the trigger.

-1. To test the example workflow in this guide, you need a local tool or app that can send calls to the endpoint created by the Request trigger. For example, you can use local tools such as [Insomnia](https://insomnia.rest/) or [Bruno](https://www.usebruno.com/) to send the HTTP request.

-1. Find the Request trigger named **When an HTTP request is received** by using the search box, and add that trigger to your workflow. For more information, see [Build a workflow with a trigger and actions](create-workflow-with-trigger-or-action.md?tabs=standard#add-trigger).

-1. On the designer, under the Request trigger, select the plus sign (**+**) > **Add an action**.

-To test your logic app workflow, follow these steps to start a debugging session, and find the URL for the endpoint that's created by the Request trigger. You need this URL so that you can later send a request to that endpoint.

-1. Now, find the callback URL for the endpoint on the Request trigger.

- 1. Find the **Callback URL** value, which looks similar to this URL for the example Request trigger:

-1. To test the callback URL by sending a request and triggering the workflow, open your preferred tool or app, and follow their instructions for creating and sending HTTP requests.

- For this example, use the **GET** method with the copied URL, which looks like the following sample:

-When you have a workflow that starts with the Request trigger, you can return a response to the caller that sent a request to your workflow by using the [Request built-in action named **Response**](../connectors/connectors-native-reqres.md).

- If you have a blank workflow, use any trigger that you want to start the workflow. This example uses the Request trigger.

- This example continues with the Request trigger named **When a HTTP request is received**.

- This example continues with the Request trigger named **When a HTTP request is received**.

- This example continues with the Request trigger named **When a HTTP request is received**.

- This example continues with the Request trigger named **When a HTTP request is received**.

-1. To send a call to the Request trigger's URL, which appears in the Request trigger's **HTTP POST URL** property, follow these steps:

- 1. Use a local tool or app such as [Insomnia](https://insomnia.rest/) or [Bruno](https://www.usebruno.com/) to send the HTTP request.

- 1. Send the HTTP request using the **`POST`** method with the URL.

- 1. Include the XML content that you want to encode or decode in the request body.

- This example continues with the Request trigger named **When a HTTP request is received**.

- This example continues with the Request trigger named **When a HTTP request is received**.

-1. To send a call to the Request trigger's URL, which appears in the Request trigger's **HTTP POST URL** property, follow these steps:

- 1. Use a local tool or app such as [Insomnia](https://insomnia.rest/) or [Bruno](https://www.usebruno.com/) to send the HTTP request.

- 1. Send the HTTP request using the **`POST`** method with the URL.

- 1. Include the JSON input to transform, for example:

- ```json

- {

- "devices": "Surface, Mobile, Desktop computer, Monitors",

- "firstName": "Dean",

- "lastName": "Ledet",

- "phone": "(111)0001111"

- }

- ```

-* A logic app workflow where you want to use the request-based trigger to create the callable endpoint. You can start with either a blank workflow or an existing workflow where you can replace the current trigger. This example starts with a blank workflow.

-* To test the URL for the callable endpoint that you create, you'll need a local tool or app such as [Insomnia](https://insomnia.rest/) or [Bruno](https://www.usebruno.com/) to send the HTTP request.

-1. To test the callback URL that you now have for the Request trigger, use a local tool or app such as [Insomnia](https://insomnia.rest/) or [Bruno](https://www.usebruno.com/), and send the request using the method that the Request trigger expects.

- This example uses the `POST` method:

-1. To test the callback URL that you now have for the Request trigger, use a local tool or app such as [Insomnia](https://insomnia.rest/) or [Bruno](https://www.usebruno.com/), and send the request using the method that the Request trigger expects.

- This example uses the `POST` method:

-By default, the Request trigger expects a `POST` request. However, you can specify a different method that the caller must use, but only a single method.

-1. In the Request trigger, open the **Advanced parameters** list, and select **Method**, which adds this property to the trigger.

-1. In the Request trigger, open the **Add new parameter** list, and select **Method**, which adds this property to the trigger.

- These values are passed as name-value pairs in the endpoint's URL. For this option, you need to use the GET method in your Request trigger. In a subsequent action, you can get the parameter values as trigger outputs by using the `triggerOutputs()` function in an expression.

-* [Accept values through a relative path](#relative-path) for parameters in your Request trigger.

-1. In the Request trigger, open the **Advanced parameters**, add the **Method** property to the trigger, and select the **GET** method.

-1. From the Request trigger, copy the workflow URL, and paste the URL into another browser window. In the URL, add the parameter name and value to the URL in the following format, and press Enter.

-1. In the Request trigger, open the **Add new parameter list**, add the **Method** property to the trigger, and select the **GET** method.

-1. From the Request trigger, copy the workflow URL, and paste the URL into another browser window. In the URL, add the parameter name and value following the question mark (`?`) to the URL in the following format, and press Enter.

-1. In the Request trigger, open the **Advanced parameters** list, and select **Relative path**, which adds this property to the trigger.

-1. Under the Request trigger, [follow these general steps to add the action where you want to use the parameter value](create-workflow-with-trigger-or-action.md?tabs=standard#add-action).

- In the Request trigger, the callback URL is updated and now includes the relative path, for example:

-1. To test your callable endpoint, copy the updated callback URL from the Request trigger, paste the URL into another browser window, replace `%7BpostalCode%7D` in the URL with `123456`, and press Enter.

-1. In the Request trigger, open the **Add new parameter** list, and select **Relative path**, which adds this property to the trigger.

-1. Under the Request trigger, [follow these general steps to add the action where you want to use the parameter value](create-workflow-with-trigger-or-action.md?tabs=consumption#add-action).

- In the Request trigger, the callback URL is updated and now includes the relative path, for example:

-1. To test your callable endpoint, copy the updated callback URL from the Request trigger, paste the URL into another browser window, replace `{postalCode}` in the URL with `123456`, and press Enter.

-When you provide a JSON schema in the Request trigger, the workflow designer generates tokens for the properties in that schema. You can then use those tokens for passing data through your workflow.

-In the response body, you can include multiple headers and any type of content. For example, the following response's header specifies that the response's content type is `application/json` and that the body contains values for the `town` and `postalCode` properties, based on the JSON schema described earlier in this topic for the Request trigger.

-To follow this example, you need these items:

-To test your batching solution, post X12 messages to your batch sender logic app from a local tool or app that can send HTTP requests, such as [Insomnia](https://insomnia.rest/) or [Bruno](https://www.usebruno.com/). Soon, you start getting X12 messages in your request bin, either every 10 minutes or in batches of 10, all with the same partition key.

- When you're done, your settings look similar to the following example:

- :::image type="content" source="media/quickstart-create-example-consumption-workflow/create-logic-app-settings.png" alt-text="Screenshot shows Azure portal and logic app resource creation page with details for new logic app." lightbox="media/quickstart-create-example-consumption-workflow/create-logic-app-settings.png":::

- > If you selected an Azure region that supports availability zone redundancy, the **Zone redundancy**

- > section is automatically enabled. This preview section offers the choice to enable availability zone

- > redundancy for your logic app. However, currently supported Azure regions don't include **West US**,

- > so you can ignore this section for this example. For more information, see

- When you're done, the email subject looks like the following example:

-To check that the workflow runs correctly, you can either wait for the trigger to fire based on your specifed schedule, or you can manually run the workflow.

-When you're done with this quickstart, delete the sample logic app resource and any related resources by deleting the resource group that you created for this example.

-You need to have a new or existing Azure virtual network that includes a subnet without any delegations. This subnet is used to deploy and allocate private IP addresses from the virtual network.

-For more information, review the following documentation:

-1. Start your workflow with a built-in trigger that can receive and handle inbound requests, such as the Request trigger or the HTTP + Webhook trigger. This trigger sets up your workflow with a callable endpoint.

-For example, the Request trigger creates an endpoint on your workflow that can receive and handle inbound requests from other callers, including workflows. This endpoint provides a URL that you can use to call and trigger the workflow. For this example, the steps continue with the Request trigger.

-1. After the designer opens, add the Request trigger as the first step in your workflow.

- To trigger the workflow, you call or send a request to this URL.

-1. Make sure that the URL works by calling or sending a request to the URL. You can use any local tool or app that you want for creating and sending HTTP requests, such as [Insomnia](https://insomnia.rest/) or [Bruno](https://www.usebruno.com/).

-1. After the designer opens, add the Request trigger as the first step in your workflow.

-description: Set up availability zones for logic apps with zone redundancy for business continuity and disaster recovery.

-#Customer intent: As a developer, I want to protect logic apps from regional failures by setting up availability zones.

-# Protect logic apps from zonal failures with zone redundancy and availability zones

-To provide resiliency and distributed availability, at least three separate availability zones exist in any Azure region that supports and enables zone redundancy. The Azure Logic Apps platform distributes these zones and logic app workloads across these zones. This capability is a key requirement for enabling resilient architectures and providing high availability if datacenter failures happen in a region. For more information about availability zone redundancy, review [Azure regions and availability zones](../availability-zones/az-overview.md).

-This article provides a brief overview, considerations, and information about how to enable availability zone redundancy in Azure Logic Apps.

-## Considerations

-### [Standard](#tab/standard)

-Availability zone support is available for Standard logic apps, which are powered by Azure Functions extensibility. For more information, see [What is reliability in Azure Functions?](../reliability/reliability-functions.md#availability-zone-support).

-* You can enable availability zone redundancy *only when you create* Standard logic apps, either in a [supported Azure region](../azure-functions/azure-functions-az-redundancy.md#requirements) or in an [App Service Environment v3 (ASE v3) - Windows plans only](../app-service/environment/overview-zone-redundancy.md). Currently, this capability supports only built-in connector operations, not Azure (managed) connector operations.

-* You can enable availability zone redundancy *only for new* Standard logic apps with workflows that run in single-tenant Azure Logic Apps. You can't enable availability zone redundancy for existing Standard logic app workflows.

-* You can enable availability zone redundancy *only at creation time*. No programmatic tool support, such as Azure PowerShell or Azure CLI, currently exists to enable availability zone redundancy after creation.

-### [Consumption (preview)](#tab/consumption)

-Availability zone redundancy is currently in *preview* for Consumption logic apps, which run in multi-tenant Azure Logic Apps. During preview, the following considerations apply:

-* You can enable availability zone redundancy *only for new* Consumption logic app workflows that you create in the following Azure regions, which will expand as available:

- * Australia East

- * Brazil South

- * Canada Central

- * Central India

- * Central US

- * East Asia

- * East US

- * East US 2

- * France Central

- * Germany West Central

- * Japan East

- * Korea Central

- * Norway East

- * South Central US

- * UK South

- * West Europe

- * West US 3

- You have to create these Consumption logic apps *using the Azure portal*. No programmatic tool support, such as Azure PowerShell or Azure CLI, currently exists to enable availability zone redundancy.

-* You can't enable availability zone redundancy for existing Consumption logic app workflows. Any existing Consumption logic app workflows are unaffected until mid-May 2022.

- However, after this time, the Azure Logic Apps team will gradually start to move existing Consumption logic app workflows towards using availability zone redundancy, several Azure regions at a time. The option to enable availability zone redundancy on new Consumption logic app workflows remains available during this time.

-### [Standard](#tab/standard)

- 

- For a tutorial, review [Create Standard logic app workflows with single-tenant Azure Logic Apps in the Azure portal](create-single-tenant-workflows-azure-portal.md).

-1. Under **Zone redundancy**, select **Enabled**.

- At this point, your logic app creation experience appears similar to this example:

- 

-1. Finish creating your logic app workflow.

-1. If you use a firewall and haven't set up access for traffic through the required IP addresses, make sure to complete that [requirement](#prerequisites).

-### [Consumption (preview)](#tab/consumption)

-1. In the [Azure portal](https://portal.azure.com), start creating a Consumption logic app. On the **Create Logic App** page, stop after you select **Consumption** as the plan type for your logic app.

- 

- For a quick tutorial, see [Quickstart: Create an example Consumption logic app workflow in multi-tenant Azure Logic Apps using the Azure portal](quickstart-create-example-consumption-workflow.md).

- After you select **Consumption**, the **Zone redundancy** section and options become available.

- 

-## Next steps

-When you use a customer-managed key, the resources are in your Azure subscription and encrypted with your key. While these resources exist in your subscription, Microsoft manages them. They're automatically created and configured when you create your Azure Machine Learning workspace.

-These Microsoft-managed resources are located in a new Azure resource group that's created in your subscription. This resource group is separate from the resource group for your workspace. It contains the Microsoft-managed resources that your key is used with. The formula for naming the resource group is: `<Azure Machine Learning workspace resource group name><GUID>`.

-The OS disk for each compute node that's stored in Azure Storage is always encrypted with Microsoft-managed keys in Azure Machine Learning storage accounts, and not with customer-managed keys. This compute target is ephemeral, so data that's stored on the OS disk is deleted after the cluster scales down. Clusters typically scale down when no jobs are queued, autoscaling is on, and the minimum node count is set to zero. The underlying virtual machine is deprovisioned, and the OS disk is deleted.

-Your Azure Machine Learning workspace reads and writes data by using its managed identity. This identity is granted access to the resources through a role assignment (Azure role-based access control) on the data resources. The encryption key that you provide is used to encrypt data that's stored on Microsoft-managed resources. It's also used to create indexes for Azure AI Search at runtime.

-Data that previously was stored in CosmosDB in your subscription, is stored in multi-tenant Microsoft-managed resources using document-level encryption using your encryption key. Search indices that were previously stored in Azure AI Search in your subscription, are stored on Microsoft-managed resources that are provisioned dedicated for you per workspace. The cost of the Azure AI search instance is charged under your Azure ML workspace in Azure Cost Management.

-Pipelines metadata that previously was stored in a storage account in a managed resource group, is now stored on the storage account in your subscription that is associated to the Azure Machine Learning workspace. Since this Azure Storage resource is managed separately in your subscription, you are responsible to configure encryption settings on it.

-Set the `enableServiceSideCMKEncryption` when you create a workspace to opt-in for this preview. Preview availability varies by [workspace kind](concept-workspace.md):

-Certain models in the model catalog can be deployed as a serverless API with pay-as-you-go billing. This kind of deployment provides a way to consume models as an API without hosting them on your subscription, while keeping the enterprise security and compliance that organizations need. This deployment option doesn't require quota from your subscription.

-## Subscribe your workspace to the model offering

-For models offered through the Azure Marketplace, you can deploy them to serverless API endpoints to consume their predictions. If it's your first time deploying the model in the workspace, you have to subscribe your workspace for the particular model offering from the Azure Marketplace. Each workspace has its own subscription to the particular Azure Marketplace offering of the model, which allows you to control and monitor spending.

-> [!NOTE]

-> Models offered through the Azure Marketplace are available for deployment to serverless API endpoints in specific regions. Check [Region availability for models in Serverless API endpoints](concept-endpoint-serverless-availability.md) to verify which regions are available. If the one you need is not listed, you can deploy to a workspace in a supported region and then [consume serverless API endpoints from a different workspace](how-to-connect-models-serverless.md).

-1. Ensure your account has the **Azure AI Developer** role permissions on the resource group, or that you meet the [permissions required to subscribe to model offerings](#permissions-required-to-subscribe-to-model-offerings).

-1. Go to your workspace.

- 1. On the model's **Details** page, select **Deploy** and then select **Serverless API** to open the deployment wizard.

-1. Once you sign up the workspace for the particular Azure Marketplace offering, subsequent deployments of the same offering in the same workspace don't require subscribing again.

-Once you've created a model's subscription, you can deploy the associated model to a serverless API endpoint. The serverless API endpoint provides a way to consume models as an API without hosting them on your subscription, while keeping the enterprise security and compliance organizations need. This deployment option doesn't require quota from your subscription.

-In this article, you create an endpoint with name **meta-llama3-8b-qwerty**.

- 1. From the previous wizard, select **Deploy** (if you've just subscribed the workspace to the model offer in the previous section), or select **Continue to deploy** (if your deployment wizard had the note *You already have an Azure Marketplace subscription for this workspace*).

-1. If you need to consume this deployment from a different workspace, or you plan to use prompt flow to build intelligent applications, you need to create a connection to the serverless API deployment. To learn how to configure an existing serverless API endpoint on a new project or hub, see [Consume deployed serverless API endpoints from a different workspace or from Prompt flow](how-to-connect-models-serverless.md).

-## Using the serverless API endpoint

-Read more about the [capabilities of this API](reference-model-inference-api.md#capabilities) and how [you can leverage it when building applications](reference-model-inference-api.md#getting-started).

-Models deployed as a serverless API endpoint are offered through the Azure Marketplace and integrated with Azure Machine Learning for use. You can find the Azure Marketplace pricing when deploying or fine-tuning the models.

-Quota is managed per deployment. Each deployment has a rate limit of 200,000 tokens per minute and 1,000 API requests per minute. However, we currently limit one deployment per model per workspace. Contact Microsoft Azure Support if the current rate limits aren't sufficient for your scenarios.

-description: Learn how to set up AutoML training jobs without a single line of code with Azure Machine Learning automated ML in the Azure Machine Learning studio.

-# Set up no-code AutoML training for tabular data with the studio UI

-In this article, you learn how to set up AutoML training jobs without a single line of code using Azure Machine Learning automated ML in the [Azure Machine Learning studio](overview-what-is-azure-machine-learning.md#studio).

-Automated machine learning, AutoML, is a process in which the best machine learning algorithm to use for your specific data is selected for you. This process enables you to generate machine learning models quickly. [Learn more about how Azure Machine Learning implements automated machine learning](concept-automated-ml.md).

-

-For an end to end example, try the [Tutorial: AutoML- train no-code classification models](tutorial-first-experiment-automated-ml.md).

-For a Python code-based experience, [configure your automated machine learning experiments](how-to-configure-auto-train.md) with the Azure Machine Learning SDK.

-* An Azure subscription. If you don't have an Azure subscription, create a free account before you begin. Try the [free or paid version of Azure Machine Learning](https://azure.microsoft.com/free/) today.

-* An Azure Machine Learning workspace. See [Create workspace resources](quickstart-create-resources.md).

-## Get started

-1. Sign in to [Azure Machine Learning studio](https://ml.azure.com).

-1. Select your subscription and workspace.

-1. Navigate to the left pane. Select **Automated ML** under the **Authoring** section.

-[](media/how-to-use-automated-ml-for-ml-models/nav-pane-expanded.png#lightbox)

- If this is your first time doing any experiments, you see an empty list and links to documentation.

-Otherwise, you see a list of your recent automated ML experiments, including those created with the SDK.

-## Create and run experiment

-1. Select **+ New automated ML job** and populate the form.

-1. Select a data asset from your storage container, or create a new data asset. Data asset can be created from local files, web urls, datastores, or Azure open datasets. Learn more about [data asset creation](how-to-create-data-assets.md).

- >[!Important]

- > Requirements for training data:

- >* Data must be in tabular form.

- >* The value you want to predict (target column) must be present in the data.

- 1. To create a new dataset from a file on your local computer, select **+Create dataset** and then select **From local file**.

- 1. Select **Next** to open the **Datastore and file selection form**. , you select where to upload your dataset; the default storage container that's automatically created with your workspace, or choose a storage container that you want to use for the experiment.

-

- 1. If your data is behind a virtual network, you need to enable the **skip the validation** function to ensure that the workspace can access your data. For more information, see [Use Azure Machine Learning studio in an Azure virtual network](how-to-enable-studio-virtual-network.md).

-

- 1. Select **Browse** to upload the data file for your dataset.

- 1. Review the **Settings and preview** form for accuracy. The form is intelligently populated based on the file type.

- Field| Description

- -|-

- File format| Defines the layout and type of data stored in a file.

- Delimiter| One or more characters for specifying the boundary between separate, independent regions in plain text or other data streams.

- Encoding| Identifies what bit to character schema table to use to read your dataset.

- Column headers| Indicates how the headers of the dataset, if any, will be treated.

- Skip rows | Indicates how many, if any, rows are skipped in the dataset.

-

- Select **Next**.

- 1. The **Schema** form is intelligently populated based on the selections in the **Settings and preview** form. Here configure the data type for each column, review the column names, and select which columns to **Not include** for your experiment.

-

- Select **Next.**

- 1. The **Confirm details** form is a summary of the information previously populated in the **Basic info** and **Settings and preview** forms. You also have the option to create a data profile for your dataset using a profiling enabled compute.

- Select **Next**.

-1. Select your newly created dataset once it appears. You're also able to view a preview of the dataset and sample statistics.

-1. On the **Configure job** form, select **Create new** and enter **Tutorial-automl-deploy** for the experiment name.

-1. Select a target column; this is the column that you would like to do predictions on.

-1. Select a compute type for the data profiling and training job. You can select a [compute cluster](concept-compute-target.md#azure-machine-learning-compute-managed) or [compute instance](concept-compute-instance.md).

-

-1. Select a compute from the dropdown list of your existing computes. To create a new compute, follow the instructions in step 8.

-1. Select **Create a new compute** to configure your compute context for this experiment.

- Field|Description

- |

- Compute name| Enter a unique name that identifies your compute context.

- Virtual machine priority| Low priority virtual machines are cheaper but don't guarantee the compute nodes.

- Virtual machine type| Select CPU or GPU for virtual machine type.

- Virtual machine size| Select the virtual machine size for your compute.

- Min / Max nodes| To profile data, you must specify one or more nodes. Enter the maximum number of nodes for your compute. The default is six nodes for an Azure Machine Learning Compute.

- Advanced settings | These settings allow you to configure a user account and existing virtual network for your experiment.

-

- Select **Create**. Creation of a new compute can take a few minutes.

- Select **Next**.

-1. On the **Task type and settings** form, select the task type: classification, regression, or forecasting. See [supported task types](concept-automated-ml.md#when-to-use-automl-classification-regression-forecasting-computer-vision--nlp) for more information.

- 1. For **classification**, you can also enable deep learning.

- 1. For **forecasting** you can,

-

- 1. Enable deep learning.

- 1. Select *time column*: This column contains the time data to be used.

- 1. Select *forecast horizon*: Indicate how many time units (minutes/hours/days/weeks/months/years) will the model be able to predict to the future. The further into the future the model is required to predict, the less accurate the model becomes. [Learn more about forecasting and forecast horizon](how-to-auto-train-forecast.md).

-1. (Optional) View addition configuration settings: additional settings you can use to better control the training job. Otherwise, defaults are applied based on experiment selection and data.

- Additional configurations|Description

- |

- Primary metric| Main metric used for scoring your model. [Learn more about model metrics](how-to-configure-auto-train.md#primary-metric).

- Enable ensemble stacking | Ensemble learning improves machine learning results and predictive performance by combining multiple models as opposed to using single models. [Learn more about ensemble models](concept-automated-ml.md#ensemble).

- Blocked models| Select models you want to exclude from the training job. <br><br> Allowing models is only available for [SDK experiments](how-to-configure-auto-train.md#supported-algorithms). <br> See the [supported algorithms for each task type](/python/api/azureml-automl-core/azureml.automl.core.shared.constants.supportedmodels).

- Explain best model| Automatically shows explainability on the best model created by Automated ML.

- Positive class label| Label that Automated ML will use to calculate binary metrics.

-

-1. (Optional) View featurization settings: if you choose to enable **Automatic featurization** in the **Additional configuration settings** form, default featurization techniques are applied. In the **View featurization settings**, you can change these defaults and customize accordingly. Learn how to [customize featurizations](#customize-featurization).

- 

-1. The **[Optional] Limits** form allows you to do the following.

- | Option | Description |

- ||--|

- |**Max trials**| Maximum number of trials, each with different combination of algorithm and hyperparameters to try during the AutoML job. Must be an integer between 1 and 1000.

- |**Max concurrent trials**| Maximum number of trial jobs that can be executed in parallel. Must be an integer between 1 and 1000.

- |**Max nodes**| Maximum number of nodes this job can use from selected compute target.

- |**Metric score threshold**| When this threshold value will be reached for an iteration metric the training job will terminate. Keep in mind that meaningful models have correlation > 0, otherwise they are as good as guessing the average Metric threshold should be between bounds [0, 10].

- |**Experiment timeout (minutes)**| Maximum time in minutes the entire experiment is allowed to run. Once this limit is reached the system will cancel the AutoML job, including all its trials (children jobs).

- |**Iteration timeout (minutes)**| Maximum time in minutes each trial job is allowed to run. Once this limit is reached the system will cancel the trial.

- |**Enable early termination**| Select to end the job if the score is not improving in the short term.

-1. The **[Optional] Validate and test** form allows you to do the following.

-a. Specify the type of validation to be used for your training job. If you do not explicitly specify either a `validation_data` or `n_cross_validations` parameter, automated ML applies default techniques depending on the number of rows provided in the single dataset `training_data`.

-| Training data size | Validation technique |

-||--|

-|**Larger than 20,000 rows**| Train/validation data split is applied. The default is to take 10% of the initial training data set as the validation set. In turn, that validation set is used for metrics calculation.

-|**Smaller than 20,000& rows**| Cross-validation approach is applied. The default number of folds depends on the number of rows. <br> **If the dataset is less than 1,000 rows**, 10 folds are used. <br> **If the rows are between 1,000 and 20,000**, then three folds are used.

-b. Provide a test dataset (preview) to evaluate the recommended model that automated ML generates for you at the end of your experiment. When you provide test data, a test job is automatically triggered at the end of your experiment. This test job is only job on the best model that is recommended by automated ML. Learn how to get the [results of the remote test job](#view-remote-test-job-results-preview).

->[!IMPORTANT]

-> Providing a test dataset to evaluate generated models is a preview feature. This capability is an [experimental](/python/api/overview/azure/ml/#stable-vs-experimental) preview feature, and may change at any time.

- * Test data is considered a separate from training and validation, so as to not bias the results of the test job of the recommended model. [Learn more about bias during model validation](concept-automated-ml.md#training-validation-and-test-data).

- * You can either provide your own test dataset or opt to use a percentage of your training dataset. Test data must be in the form of an [Azure Machine Learning TabularDataset](how-to-create-data-assets.md#create-data-assets).

- * The schema of the test dataset should match the training dataset. The target column is optional, but if no target column is indicated no test metrics are calculated.

- * The test dataset shouldn't be the same as the training dataset or the validation dataset.

- * Forecasting jobs don't support train/test split.

-

-

-

-## Customize featurization

-In the **Featurization** form, you can enable/disable automatic featurization and customize the automatic featurization settings for your experiment. To open this form, see step 10 in the [Create and run experiment](#create-and-run-experiment) section.

-The following table summarizes the customizations currently available via the studio.

-Column| Customization

-|

-Feature type| Change the value type for the selected column.

-Impute with| Select what value to impute missing values with in your data.

-

-Select **Finish** to run your experiment. The experiment preparing process can take up to 10 minutes. Training jobs can take an additional 2-3 minutes more for each pipeline to finish running. If you have specified to generate RAI dashboard for the best recommended model, it may take up to 40 minutes.

-> The algorithms automated ML employs have inherent randomness that can cause slight variation in a recommended model's final metrics score, like accuracy. Automated ML also performs operations on data such as train-test split, train-validation split or cross-validation when necessary. So if you run an experiment with the same configuration settings and primary metric multiple times, you'll likely see variation in each experiments final metrics score due to these factors.

-The **Models** tab contains a list of the models created ordered by the metric score. By default, the model that scores the highest based on the chosen metric is at the top of the list. As the training job tries out more models, they're added to the list. Use this to get a quick comparison of the metrics for the models produced so far.

-Drill down on any of the completed models to see training job details.

-You can see model specific performance metric charts on the **Metrics** tab. [Learn more about charts](how-to-understand-automated-ml.md).

-This is also where you can find details on all the properties of the model along with associated code, child jobs, and images.

-## View remote test job results (preview)

-If you specified a test dataset or opted for a train/test split during your experiment setup--on the **Validate and test** form, automated ML automatically tests the recommended model by default. As a result, automated ML calculates test metrics to determine the quality of the recommended model and its predictions.

->[!IMPORTANT]

-> Testing your models with a test dataset to evaluate generated models is a preview feature. This capability is an [experimental](/python/api/overview/azure/ml/#stable-vs-experimental) preview feature, and may change at any time.

-> [!WARNING]

-> This feature is not available for the following automated ML scenarios

-> * [Computer vision tasks](how-to-auto-train-image-models.md)

-> * [Many models and hiearchical time series forecasting training (preview)](how-to-auto-train-forecast.md)

-> * [Forecasting tasks where deep learning neural networks (DNN) are enabled](how-to-auto-train-forecast.md#enable-deep-learning)

-> * [Automated ML jobs from local computes or Azure Databricks clusters](how-to-configure-auto-train.md#compute-to-run-experiment)

-To view the test job metrics of the recommended model,

-

-1. Navigate to the **Models** page, select the best model.

-1. Select the **Test results (preview)** tab.

-1. Select the job you want, and view the **Metrics** tab.

- 

-

-To view the test predictions used to calculate the test metrics,

-1. Navigate to the bottom of the page and select the link under **Outputs dataset** to open the dataset.

- 1. Alternatively, the prediction file can also be viewed/downloaded from the **Outputs + logs** tab, expand the **Predictions** folder to locate your `predicted.csv` file.

-Alternatively, the predictions file can also be viewed/downloaded from the Outputs + logs tab, expand Predictions folder to locate your predictions.csv file.

-The model test job generates the predictions.csv file that's stored in the default datastore created with the workspace. This datastore is visible to all users with the same subscription. Test jobs aren't recommended for scenarios if any of the information used for or created by the test job needs to remain private.

-## Test an existing automated ML model (preview)

->[!IMPORTANT]

-> [!WARNING]

-> This feature is not available for the following automated ML scenarios

-> * [Computer vision tasks](how-to-auto-train-image-models.md)

-> * [Many models and hiearchical time series forecasting training (preview)](how-to-auto-train-forecast.md)

-> * [Forecasting tasks where deep learning neural networks (DNN) are enabled](how-to-auto-train-forecast.md#enable-deep-learning)

-> * [Automated ML runs from local computes or Azure Databricks clusters](how-to-configure-auto-train.md#compute-to-run-experiment)

-After your experiment completes, you can test the model(s) that automated ML generates for you. If you want to test a different automated ML generated model, not the recommended model, you can do so with the following steps.

-1. Select an existing automated ML experiment job.

-1. Navigate to the **Models** tab of the job and select the completed model you want to test.

-1. On the model **Details** page, select the **Test model(preview)** button to open the **Test model** pane.

-1. On the **Test model** pane, select the compute cluster and a test dataset you want to use for your test job.

-1. Select the **Test** button. The schema of the test dataset should match the training dataset, but the **target column** is optional.

-1. Upon successful creation of model test job, the **Details** page displays a success message. Select the **Test results** tab to see the progress of the job.

-1. To view the results of the test job, open the **Details** page and follow the steps in the [view results of the remote test job](#view-remote-test-job-results-preview) section.

- 

-

-## Responsible AI dashboard (preview)

-To better understand your model, you can see various insights about your model using the Responsible Ai dashboard. It allows you to evaluate and debug your best Automated machine learning model. The Responsible AI dashboard will evaluate model errors and fairness issues, diagnose why those errors are happening by evaluating your train and/or test data, and observing model explanations. Together, these insights could help you build trust with your model and pass the audit processes. Responsible AI dashboards can't be generated for an existing Automated machine learning model. It is only created for the best recommended model when a new AutoML job is created. Users should continue to just use Model Explanations (preview) until support is provided for existing models.

-To generate a Responsible AI dashboard for a particular model,

-1. While submitting an Automated ML job, proceed to the **Task settings** section on the left nav bar and select the **View additional configuration settings** option.

-

-2. In the new form appearing post that selection, select the **Explain best model** checkbox.

- 

-3. Proceed to the **Compute** page of the setup form and choose the **Serverless** option for your compute.

- 

-4. Once complete, navigate to the Models page of your Automated ML job, which contains a list of your trained models. Select on the **View Responsible AI dashboard** link:

- 

-The Responsible AI dashboard appears for that model as shown in this image:

- 

-In the dashboard, you'll find four components activated for your Automated MLΓÇÖs best model:

-| Component | What does the component show? | How to read the chart? |

-| - | - | - |

-| [Error Analysis](concept-error-analysis.md) | Use error analysis when you need to: <br> Gain a deep understanding of how model failures are distributed across a dataset and across several input and feature dimensions. <br> Break down the aggregate performance metrics to automatically discover erroneous cohorts in order to inform your targeted mitigation steps. | [Error Analysis Charts](how-to-responsible-ai-dashboard.md) |

-| [Model Overview and Fairness](concept-fairness-ml.md) | Use this component to: <br> Gain a deep understanding of your model performance across different cohorts of data. <br> Understand your model fairness issues by looking at the disparity metrics. These metrics can evaluate and compare model behavior across subgroups identified in terms of sensitive (or nonsensitive) features. | [Model Overview and Fairness Charts](how-to-responsible-ai-dashboard.md#model-overview-and-fairness-metrics) |

-| [Model Explanations](how-to-machine-learning-interpretability.md) | Use the model explanation component to generate human-understandable descriptions of the predictions of a machine learning model by looking at: <br> Global explanations: For example, what features affect the overall behavior of a loan allocation model? <br> Local explanations: For example, why was a customer's loan application approved or rejected? | [Model Explainability Charts](how-to-responsible-ai-dashboard.md#feature-importances-model-explanations) |

-| [Data Analysis](concept-data-analysis.md) | Use data analysis when you need to: <br> Explore your dataset statistics by selecting different filters to slice your data into different dimensions (also known as cohorts). <br> Understand the distribution of your dataset across different cohorts and feature groups. <br> Determine whether your findings related to fairness, error analysis, and causality (derived from other dashboard components) are a result of your dataset's distribution. <br> Decide in which areas to collect more data to mitigate errors that come from representation issues, label noise, feature noise, label bias, and similar factors. | [Data Explorer Charts](how-to-responsible-ai-dashboard.md#data-analysis) |

-5. You can further create cohorts (subgroups of data points that share specified characteristics) to focus your analysis of each component on different cohorts. The name of the cohort that's currently applied to the dashboard is always shown at the top left of your dashboard. The default view in your dashboard is your whole dataset, titled "All data" (by default). Learn more about the [global control of your dashboard here.](how-to-responsible-ai-dashboard.md#global-controls)

->[!IMPORTANT]

-> The ability to copy, edit and submit a new experiment based on an existing experiment is a preview feature. This capability is an [experimental](/python/api/overview/azure/ml/#stable-vs-experimental) preview feature, and may change at any time.

-In scenarios where you would like to create a new experiment based on the settings of an existing experiment, automated ML provides the option to do so with the **Edit and submit** button in the studio UI.

-This functionality is limited to experiments initiated from the studio UI and requires the data schema for the new experiment to match that of the original experiment.

-The **Edit and submit** button opens the **Create a new Automated ML job** wizard with the data, compute and experiment settings prepopulated. You can go through each form and edit selections as needed for your new experiment.

-Once you have the best model at hand, it's time to deploy it as a web service to predict on new data.

->[!TIP]

-> If you are looking to deploy a model that was generated via the `automl` package with the Python SDK, you must [register your model)](./how-to-deploy-online-endpoints.md) to the workspace.

-> Once you're model is registered, find it in the studio by selecting **Models** on the left pane. Once you open your model, you can select the **Deploy** button at the top of the screen, and then follow the instructions as described in **step 2** of the **Deploy your model** section.

-Automated ML helps you with deploying the model without writing code:

-1. You have a couple options for deployment.

- + Option 1: Deploy the best model, according to the metric criteria you defined.

- 1. After the experiment is complete, navigate to the parent job page by selecting **Job 1** at the top of the screen.

- 1. Select the model listed in the **Best model summary** section.

- 1. Select **Deploy** on the top left of the window.

- + Option 2: To deploy a specific model iteration from this experiment.

- 1. Select the desired model from the **Models** tab

- 1. Select **Deploy** on the top left of the window.

-1. Populate the **Deploy model** pane.

- Field| Value

- -|-

- Name| Enter a unique name for your deployment.

- Description| Enter a description to better identify what this deployment is for.

- Compute type| Select the type of endpoint you want to deploy: [*Azure Kubernetes Service (AKS)*](../aks/intro-kubernetes.md) or [*Azure Container Instance (ACI)*](../container-instances/container-instances-overview.md).

- Compute name| *Applies to AKS only:* Select the name of the AKS cluster you wish to deploy to.

- Enable authentication | Select to allow for token-based or key-based authentication.

- Use custom deployment assets| Enable this feature if you want to upload your own scoring script and environment file. Otherwise, automated ML provides these assets for you by default. [Learn more about scoring scripts](how-to-deploy-online-endpoints.md).

- >[!Important]

- > File names must be under 32 characters and must begin and end with alphanumerics. May include dashes, underscores, dots, and alphanumerics between. Spaces are not allowed.

- The *Advanced* menu offers default deployment features such as [data collection](how-to-enable-app-insights.md) and resource utilization settings. If you wish to override these defaults do so in this menu.

- Once deployment begins, the **Model summary** tab appears. See the deployment progress under the **Deploy status** section.

-Now you have an operational web service to generate predictions! You can test the predictions by querying the service from [Power BI's built in Azure Machine Learning support](/power-bi/connect-data/service-aml-integrate?context=azure%2fmachine-learning%2fcontext%2fml-context).

-## Next steps

-* [Understand automated machine learning results](how-to-understand-automated-ml.md).

-* [Learn more about automated machine learning](concept-automated-ml.md) and Azure Machine Learning.

- | `settings.max_concurrency_per_instance` | [Optional] The maximum number of parallel `scoring_script` runs per instance. |

- | `settings.mini_batch_size` | [Optional] The number of files the `scoring_script` can process in one `run()` call. |

- | `settings.output_action` | [Optional] How the output should be organized in the output file. `append_row` will merge all `run()` returned output results into one single file named `output_file_name`. `summary_only` won't merge the output results and will only calculate `error_threshold`. |

- | `settings.output_file_name` | [Optional] The name of the batch scoring output file for `append_row` `output_action`. |

- | `settings.retry_settings.max_retries` | [Optional] The number of max tries for a failed `scoring_script` `run()`. |

- | `settings.retry_settings.timeout` | [Optional] The timeout in seconds for a `scoring_script` `run()` for scoring a mini batch. |

- | `settings.error_threshold` | [Optional] The number of input file scoring failures that should be ignored. If the error count for the entire input goes above this value, the batch scoring job will be terminated. The example uses `-1`, which indicates that any number of failures is allowed without terminating the batch scoring job. |

- | `settings.logging_level` | [Optional] Log verbosity. Values in increasing verbosity are: WARNING, INFO, and DEBUG. |

- | `settings.environment_variables` | [Optional] Dictionary of environment variable name-value pairs to set for each batch scoring job. |

-ms.

-In this tutorial, you'll learn how to:

-**Performance-based** | Assess based on collected dynamic performance data. | Recommended node size in AVS is based on CPU and memory utilization data, along with the settings you specify in the assessment for the node type, storage type, and failure-to-tolerate setting.

-1. In **Servers, databases and web apps** > **Azure Migrate: Discovery and assessment**.

-1. In **Azure Migrate: Discovery and assessment**, select **Assess**.

-1. In **Assess servers** > **Assessment type**, select **Azure VMware Solution (AVS)**.

- - If you discovered servers using an imported CSV file, select **Imported servers**.

-

- Target and pricing settings | **Target location** | The Azure region to which you want to migrate. Azure SQL configuration and cost recommendations are based on the location that you specify.

- Target and pricing settings | **Environment type** | The environment for the SQL deployments to apply pricing applicable to Production or Dev/Test.

- Target and pricing settings | **Offer/Licensing program** |The Azure offer if you're enrolled. Currently, the field is Pay-as-you-go by default, which gives you retail Azure prices. <br/><br/>You can avail additional discount by applying reserved capacity and Azure Hybrid Benefit on top of Pay-as-you-go offer.<br/>You can apply Azure Hybrid Benefit on top of Pay-as-you-go offer and Dev/Test environment. The assessment doesn't support applying Reserved Capacity on top of Pay-as-you-go offer and Dev/Test environment. <br/>If the offer is set to *Pay-as-you-go* and Reserved capacity is set to *No reserved instances*, the monthly cost estimates are calculated by multiplying the number of hours chosen in the VM uptime field with the hourly price of the recommended SKU.

- Target and pricing settings | **Savings options - Azure SQL MI and DB (PaaS)** | Specify the reserved capacity savings option that you want the assessment to consider, helping to optimize your Azure compute cost. <br><br> [Azure reservations](../../cost-management-billing/reservations/save-compute-costs-reservations.md) (1 year or 3 year reserved) are a good option for the most consistently running resources.<br><br> When you select 'None', the Azure compute cost is based on the Pay as you go rate or based on actual usage.<br><br> You need to select pay-as-you-go in offer/licensing program to be able to use Reserved Instances. When you select any savings option other than 'None', the 'Discount (%)' and "VM uptime" settings aren't applicable. The monthly cost estimates are calculated by multiplying 744 hours with the hourly price of the recommended SKU.

- Target and pricing settings | **Savings options - SQL Server on Azure VM (IaaS)** | Specify the savings option that you want the assessment to consider, helping to optimize your Azure compute cost. <br><br> [Azure reservations](../../cost-management-billing/reservations/save-compute-costs-reservations.md) (1 year or 3 year reserved) are a good option for the most consistently running resources.<br><br> [Azure Savings Plan](../../cost-management-billing/savings-plan/savings-plan-compute-overview.md) (1 year or 3 year savings plan) provide additional flexibility and automated cost optimization. Ideally post migration, you could use Azure reservation and savings plan at the same time (reservation is consumed first), but in the Azure Migrate assessments, you can only see cost estimates of 1 savings option at a time. <br><br> When you select 'None', the Azure compute cost is based on the Pay as you go rate or based on actual usage.<br><br> You need to select pay-as-you-go in offer/licensing program to be able to use Reserved Instances or Azure Savings Plan. When you select any savings option other than 'None', the 'Discount (%)' and "VM uptime" settings aren't applicable. The monthly cost estimates are calculated by multiplying 744 hours in the VM uptime field with the hourly price of the recommended SKU.

- Target and pricing settings | **Currency** | The billing currency for your account.

- Target and pricing settings | **Discount (%)** | Any subscription-specific discounts you receive on top of the Azure offer. The default setting is 0%.

- Target and pricing settings | **VM uptime** | Specify the duration (days per month/hour per day) that servers/VMs run. This is useful for computing cost estimates for SQL Server on Azure VM where you're aware that Azure VMs might not run continuously. <br/> Cost estimates for servers where recommended target is *SQL Server on Azure VM* are based on the duration specified. Default is 31 days per month/24 hours per day.

- Target and pricing settings | **Azure Hybrid Benefit** | Specify whether you already have a Windows Server and/or SQL Server license or Enterprise Linux subscription (RHEL and SLES). Azure Hybrid Benefit is a licensing benefit that helps you to significantly reduce the costs of running your workloads in the cloud. It works by letting you use your on-premises Software Assurance-enabled Windows Server and SQL Server licenses on Azure. For example, if you have a SQL Server license and they're covered with active Software Assurance of SQL Server Subscriptions, you can apply for the Azure Hybrid Benefit when you bring licenses to Azure.

- Assessment criteria | **Sizing criteria** | Set to be *Performance-based* by default, which means Azure Migrate collects performance metrics pertaining to SQL instances and the databases managed by it to recommend an optimal-sized SQL Server on Azure VM and/or Azure SQL Database and/or Azure SQL Managed Instance configuration.

- Assessment criteria | **Performance history** | Indicate the data duration on which you want to base the assessment. (Default is one day)

- Assessment criteria | **Percentile utilization** | Indicate the percentile value you want to use for the performance sample. (Default is 95th percentile)

- Assessment criteria | **Comfort factor** | Indicate the buffer you want to use during assessment. This accounts for issues like seasonal usage, short performance history, and likely increases in future usage. For example, consider a comfort factor of 2 for effective utilization of 2 Cores. In this case, the assessment considers the effective cores as 4 cores. Similarly, for the same comfort factor and an effective utilization of 8 GB memory, the assessment considers effective memory as 16 GB.

- Assessment criteria | **Optimization preference** | Specify the preference for the recommended assessment report. Selecting **Minimize cost** would result in the Recommended assessment report recommending those deployment types that have least migration issues and are most cost effective, whereas selecting **Modernize to PaaS** would result in Recommended assessment report recommending PaaS(Azure SQL MI or DB) deployment types over IaaS Azure(VMs), wherever the SQL Server instance is ready for migration to PaaS irrespective of cost.

- Azure SQL Managed Instance sizing | **Service Tier** | Choose the most appropriate service tier option to accommodate your business needs for migration to Azure SQL Managed Instance:<br/><br/>Select *Recommended* if you want Azure Migrate to recommend the best suited service tier for your servers. This can be General purpose or Business critical.<br/><br/>Select *General Purpose* if you want an Azure SQL configuration designed for budget-oriented workloads.<br/><br/>Select *Business Critical* if you want an Azure SQL configuration designed for low-latency workloads with high resiliency to failures and fast failovers.

- Azure SQL Managed Instance sizing | **Instance type** | Defaulted to *Single instance*.

- Azure SQL Managed Instance sizing | **Pricing Tier** | Defaulted to *Standard*.

- SQL Server on Azure VM sizing | **VM series** | Specify the Azure VM series you want to consider for *SQL Server on Azure VM* sizing. Based on the configuration and performance requirements of your SQL Server or SQL Server instance, the assessment recommends a VM size from the selected list of VM series. <br/>You can edit settings as needed. For example, if you don't want to include D-series VM, you can exclude D-series from this list.<br/> As Azure SQL assessments intend to give the best performance for your SQL workloads, the VM series list only has VMs that are optimized for running your SQL Server on Azure Virtual Machines (VMs). [Learn more](/azure/azure-sql/virtual-machines/windows/performance-guidelines-best-practices-checklist?preserve-view=true&view=azuresql#vm-size).

- SQL Server on Azure VM sizing | **Storage Type** | Defaulted to *Recommended*, which means the assessment recommends the best suited Azure Managed Disk based on the chosen environment type, on-premises disk size, IOPS and throughput.

- Azure SQL Database sizing | **Service Tier** | Choose the most appropriate service tier option to accommodate your business needs for migration to Azure SQL Database:<br/><br/>Select **Recommended** if you want Azure Migrate to recommend the best suited service tier for your servers. This can be General purpose or Business critical.<br/><br/>Select **General Purpose** if you want an Azure SQL configuration designed for budget-oriented workloads.<br/><br/>Select **Business Critical** if you want an Azure SQL configuration designed for low-latency workloads with high resiliency to failures and fast failovers.

- Azure SQL Database sizing | **Instance type** | Defaulted to *Single database*.

- Azure SQL Database sizing | **Purchase model** | Defaulted to *vCore*.

- Azure SQL Database sizing | **Compute tier** | Defaulted to *Provisioned*.

- High availability and disaster recovery properties | **Disaster recovery region** | Defaulted to the [cross-region replication pair](../../reliability/cross-region-replication-azure.md#azure-paired-regions) of the Target Location. In the unlikely event that the chosen Target Location doesn't yet have such a pair, the specified Target Location itself is chosen as the default disaster recovery region.

- High availability and disaster recovery properties | **Multi-subnet intent** | Defaulted to Disaster recovery. <br/><br/> Select **Disaster recovery** if you want asynchronous data replication where some replication delays are tolerable. This allows higher durability using geo-redundancy. In the event of failover, data that hasn't yet been replicated may be lost. <br/><br/> Select **High availability** if you desire the data replication to be synchronous and no data loss due to replication delay is allowable. This setting allows assessment to leverage built-in high availability options in Azure SQL Databases and Azure SQL Managed Instances, and availability zones and zone-redundancy in Azure Virtual Machines to provide higher availability. In the event of failover, no data is lost.

- High availability and disaster recovery properties | **Internet Access** | Defaulted to Available.<br/><br/> Select **Available** if you allow outbound internet access from Azure VMs. This allows the use of [Cloud Witness](/azure/azure-sql/virtual-machines/windows/hadr-cluster-quorum-configure-how-to?view=azuresql&preserve-view=true&tabs=powershell) which is the recommended approach for Windows Server Failover Clusters in Azure Virtual Machines. <br/><br/> Select **Not available** if the Azure VMs have no outbound internet access. This requires the use of a Shared Disk as a witness for Windows Server Failover Clusters in Azure Virtual Machines.

- High availability and disaster recovery properties | **Async commit mode intent** | Defaulted to Disaster recovery. <br/><br/> Select **Disaster recovery** if you're using asynchronous commit availability mode to enable higher durability for the data without affecting performance. In the event of failover, data that hasn't yet been replicated may be lost. <br/><br/> Select **High availability** if you're using asynchronous commit data availability mode to improve availability and scale out read traffic. This setting allows assessment to leverage built-in high availability features in Azure SQL Databases, Azure SQL Managed Instances, and Azure Virtual Machines to provide higher availability and scale out.

- - **Not ready for AVS**: The VM won't start in AVS. For example, if the on-premises VMware VM has an external device attached such as a CD-ROM the VMware VMotion operation fails (if using VMware VMotion).

-> Confidence ratings aren't assigned if you create an assessment based on a CSV file.

-description: Learn about networking services in Azure, including connectivity, application protection, application delivery, and network monitoring services.

-The networking services in Azure provide various networking capabilities that can be used together or separately. Select any of the following key capabilities to learn more about them:

-## <a name="connect"></a>Connectivity services

-This section describes services that provide connectivity between Azure resources, connectivity from an on-premises network to Azure resources, and branch to branch connectivity in Azure - Virtual Network (VNet), ExpressRoute, VPN Gateway, Virtual WAN, Virtual network NAT Gateway, Azure DNS, Peering service, Route Server, and Azure Bastion.

-### <a name="avnm"></a>Azure Virtual Network Manager

-[Azure Virtual Network Manager](../../virtual-network-manager/overview.md) is a management service that enables you to group, configure, deploy, and manage virtual networks globally across subscriptions. With Virtual Network Manager, you can define [network groups](../../virtual-network-manager/concept-network-groups.md) to identify and logically segment your virtual networks. Then you can determine the [connectivity](../../virtual-network-manager/concept-connectivity-configuration.md) and [security configurations](../../virtual-network-manager/concept-security-admins.md) you want and apply them across all the selected virtual networks in network groups at once.

-### <a name="expressroute"></a>ExpressRoute

-[ExpressRoute](../../expressroute/expressroute-introduction.md) enables you to extend your on-premises networks into the Microsoft cloud over a private connection facilitated by a connectivity provider. This connection is private. Traffic doesn't go over the internet. With ExpressRoute, you can establish connections to Microsoft cloud services, such as Microsoft Azure, Microsoft 365, and Dynamics 365.

-### <a name="vpngateway"></a>VPN Gateway

-[VPN Gateway](../../vpn-gateway/vpn-gateway-about-vpngateways.md) helps you create encrypted cross-premises connections to your virtual network from on-premises locations, or create encrypted connections between VNets. There are different configurations available for VPN Gateway connections. Some of the main features include:

-* Site-to-site VPN connectivity

-* Point-to-site VPN connectivity

-* VNet-to-VNet VPN connectivity

-The following diagram illustrates multiple site-to-site VPN connections to the same virtual network. To view more connection diagrams, see [VPN Gateway - design](../../vpn-gateway/design.md).

-### <a name="virtualwan"></a>Virtual WAN

-[Azure Virtual WAN](../../virtual-wan/virtual-wan-about.md) is a networking service that brings many networking, security, and routing functionalities together to provide a single operational interface. Connectivity to Azure VNets is established by using virtual network connections. Some of the main features include:

-* Branch connectivity (via connectivity automation from Virtual WAN Partner devices such as SD-WAN or VPN CPE)

-* Site-to-site VPN connectivity

-* Remote user VPN connectivity (point-to-site)

-* Private connectivity (ExpressRoute)

-* Intra-cloud connectivity (transitive connectivity for virtual networks)

-* VPN ExpressRoute inter-connectivity

-* Routing, Azure Firewall, and encryption for private connectivity

-[Azure Bastion](../../bastion/bastion-overview.md) is a service that you can deploy to let you connect to a virtual machine using your browser and the Azure portal, or via the native SSH or RDP client already installed on your local computer. The Azure Bastion service is a fully platform-managed PaaS service that you deploy inside your virtual network. It provides secure and seamless RDP/SSH connectivity to your virtual machines directly from the Azure portal over TLS. When you connect via Azure Bastion, your virtual machines don't need a public IP address, agent, or special client software. There are a variety of different SKU/tiers available for Azure Bastion. The tier you select affects the features that are available. For more information, see [About Bastion configuration settings](../../bastion/configuration-settings.md).

-### <a name="routeserver"></a>Route Server

-[Azure Route Server](../../route-server/overview.md) simplifies dynamic routing between your network virtual appliance (NVA) and your virtual network. It allows you to exchange routing information directly through Border Gateway Protocol (BGP) routing protocol between any NVA that supports the BGP routing protocol and the Azure Software Defined Network (SDN) in the Azure Virtual Network (VNet) without the need to manually configure or maintain route tables.

-### <a name="azurepeeringservice"></a>Peering Service

-[Azure Peering Service](../../peering-service/about.md) enhances customer connectivity to Microsoft cloud services such as Microsoft 365, Dynamics 365, software as a service (SaaS) services, Azure, or any Microsoft services accessible via the public internet.

-## <a name="protect"></a>Application protection services

-This section describes networking services in Azure that help protect your network resources - Protect your applications using any or a combination of these networking services in Azure - DDoS protection, Private Link, Firewall, Web Application Firewall, Network Security Groups, and Virtual Network Service Endpoints.

-### <a name="ddosprotection"></a>DDoS Protection

-[Azure DDoS Protection](../../ddos-protection/manage-ddos-protection.md) provides countermeasures against the most sophisticated DDoS threats. The service provides enhanced DDoS mitigation capabilities for your application and resources deployed in your virtual networks. Additionally, customers using Azure DDoS Protection have access to DDoS Rapid Response support to engage DDoS experts during an active attack.

-Azure DDoS Protection consists of two tiers:

-### <a name="privatelink"></a>Azure Private Link

-[Azure Private Link](../../private-link/private-link-overview.md) enables you to access Azure PaaS Services (for example, Azure Storage and SQL Database) and Azure hosted customer-owned/partner services over a private endpoint in your virtual network.

-Traffic between your virtual network and the service travels through the Microsoft backbone network. Exposing your service to the public internet is no longer necessary. You can create your own private link service in your virtual network and deliver it to your customers.

-### <a name="firewall"></a>Azure Firewall

-[Azure Firewall](../../firewall/overview.md) is a managed, cloud-based network security service that protects your Azure Virtual Network resources. Using Azure Firewall, you can centrally create, enforce, and log application and network connectivity policies across subscriptions and virtual networks. Azure Firewall uses a static public IP address for your virtual network resources allowing outside firewalls to identify traffic originating from your virtual network.

-### <a name="waf"></a>Web Application Firewall

-[Azure Web Application Firewall](../../web-application-firewall/overview.md) (WAF) provides protection to your web applications from common web exploits and vulnerabilities such as SQL injection, and cross site scripting. Azure WAF provides out of box protection from OWASP top 10 vulnerabilities via managed rules. Additionally customers can also configure custom rules, which are customer managed rules to provide extra protection based on source IP range, and request attributes such as headers, cookies, form data fields or query string parameters.

-Customers can choose to deploy [Azure WAF with Application Gateway](../../web-application-firewall/ag/ag-overview.md), which provides regional protection to entities in public and private address space. Customers can also choose to deploy [Azure WAF with Front Door](../../web-application-firewall/afds/afds-overview.md) which provides protection at the network edge to public endpoints.

-### <a name="nsg"></a>Network security groups

-You can filter network traffic to and from Azure resources in an Azure virtual network with a network security group. For more information, see [Network security groups](../../virtual-network/network-security-groups-overview.md).

-### <a name="serviceendpoints"></a>Service endpoints

-[Virtual Network (VNet) service endpoints](../../virtual-network/virtual-network-service-endpoints-overview.md) extend your virtual network private address space and the identity of your VNet to the Azure services, over a direct connection. Endpoints allow you to secure your critical Azure service resources to only your virtual networks. Traffic from your VNet to the Azure service always remains on the Microsoft Azure backbone network.

-## <a name="deliver"></a>Application delivery services

-This section describes networking services in Azure that help deliver applications - Content Delivery Network, Azure Front Door Service, Traffic Manager, Load Balancer, and Application Gateway.

-### <a name="frontdoor"></a>Azure Front Door

-[Azure Front Door](../../frontdoor/front-door-overview.md) enables you to define, manage, and monitor the global routing for your web traffic by optimizing for best performance and instant global failover for high availability. With Front Door, you can transform your global (multi-region) consumer and enterprise applications into robust, high-performance personalized modern applications, APIs, and content that reach a global audience with Azure.

-### <a name="trafficmanager"></a>Traffic Manager

-[Azure Traffic Manager](../../traffic-manager/traffic-manager-routing-methods.md). is a DNS-based traffic load balancer that enables you to distribute traffic optimally to services across global Azure regions, while providing high availability and responsiveness. Traffic Manager provides a range of traffic-routing methods to distribute traffic such as priority, weighted, performance, geographic, multi-value, or subnet.

-The following diagram shows endpoint priority-based routing with Traffic

-For more information about Traffic Manager, see [What is Azure Traffic Manager?](../../traffic-manager/traffic-manager-overview.md)

-### <a name="loadbalancer"></a>Load Balancer

-[Azure Load Balancer](../../load-balancer/load-balancer-overview.md) provides high-performance, low-latency Layer 4 load-balancing for all UDP and TCP protocols. It manages inbound and outbound connections. You can configure public and internal load-balanced endpoints. You can define rules to map inbound connections to back-end pool destinations by using TCP and HTTP health-probing options to manage service availability.

-Azure Load Balancer is available in Standard, Regional, and Gateway SKUs.

-The following picture shows an Internet-facing multi-tier application that utilizes both external and internal load balancers:

-### <a name="applicationgateway"></a>Application Gateway

-[Azure Application Gateway](../../application-gateway/overview.md) is a web traffic load balancer that enables you to manage traffic to your web applications. It's an Application Delivery Controller (ADC) as a service, offering various layer 7 load-balancing capabilities for your applications.

-The following diagram shows url path-based routing with Application Gateway.

-## <a name="monitor"></a>Network monitoring services

-This section describes networking services in Azure that help monitor your network resources - Azure Network Watcher, Azure Monitor Network Insights, Azure Monitor, and ExpressRoute Monitor.

-### <a name="networkwatcher"></a>Azure Network Watcher

-[Azure Network Watcher](../../network-watcher/network-watcher-monitoring-overview.md?toc=%2fazure%2fnetworking%2ftoc.json) provides tools to monitor, diagnose, view metrics, and enable or disable logs for resources in an Azure virtual network. For more information, see [What is Network Watcher?

-### <a name="azuremonitor"></a>Azure Monitor

-[Azure Monitor](../../azure-monitor/overview.md?toc=%2fazure%2fnetworking%2ftoc.json) maximizes the availability and performance of your applications by delivering a comprehensive solution for collecting, analyzing, and acting on telemetry from your cloud and on-premises environments. It helps you understand how your applications are performing and proactively identifies issues affecting them and the resources they depend on. For more information, see [Azure Monitor Overview

-### <a name="expressroutemonitor"></a>ExpressRoute Monitor

-To learn about how to view ExpressRoute circuit metrics, resource logs and alerts, see [ExpressRoute monitoring, metrics, and alerts](../../expressroute/expressroute-monitoring-metrics-alerts.md?toc=%2fazure%2fnetworking%2ftoc.json).

-### <a name="insights"></a>Network Insights

-Azure Monitor for Networks [(Network Insights)](../../network-watcher/network-insights-overview.md?toc=%2fazure%2fnetworking%2ftoc.json).

- provides a comprehensive view of health and metrics for all deployed network resources, without requiring any configuration.

-Xamarin is now deprecated. Xamarin customers should migrate to .NET MAUI, but MAUI is not currently supported by Azure Notification Hubs. MAUI apps can use the native Android Notification Hub SDK or [REST API](firebase-migration-rest.md#step-2-manage-registration-and-installation). It's recommended that Xamarin customers move away from Notification Hubs if they need FCM v1 sends.

-topic: how-to

-description: Bring your own key (BYOK) / Customer-managed key (CMK) deploy instructions for Azure Red Hat OpenShift

-keywords: encryption, byok, aro, cmk, openshift, red hat

-# Customer intent: My security policies dictate that data at rest must be encrypted. Beyond this, the key used to encrypt data must be able to be changed at-will by a person authorized to do so.

-# Encrypt persistent volume claims with a customer-managed key (CMK) on Azure Red Hat OpenShift (ARO) (preview)

-Azure Storage uses server-side encryption (SSE) to automatically [encrypt](../storage/common/storage-service-encryption.md) your data when it is persisted to the cloud. By default, data is encrypted with Microsoft platform-managed keys. For additional control over encryption keys, you can supply your own customer-managed keys to encrypt data in your Azure Red Hat OpenShift clusters.

-> [!NOTE]

-> At this stage, support exists only for encrypting ARO persistent volumes with customer-managed keys. This feature is not presently available for master or worker node operating system disks.

-> [!IMPORTANT]

-> ARO preview features are available on a self-service, opt-in basis. Previews are provided "as is" and "as available," and they are excluded from the service-level agreements and limited warranty. ARO previews are partially covered by customer support on a best-effort basis. As such, these features are not meant for production use.

-## Before you begin

-This article assumes that:

-* You have a pre-existing ARO cluster at OpenShift version 4.4 (or greater).

-* You have the **oc** OpenShift command-line tool, base64 (part of coreutils) and the **az** Azure CLI installed.

-* You are logged in to your ARO cluster using **oc** as a global cluster-admin user (kubeadmin).

-* You are logged in to the Azure CLI using **az** with an account authorized to grant "Contributor" access in the same subscription as the ARO cluster.

-## Limitations

-* Availability for customer-managed key encryption is region-specific. To see the status for a specific Azure region, check [Azure regions][supported-regions].

-* If you wish to use Ultra Disks, you must first enable them on your subscription before getting started.

-## Declare Cluster & Encryption Variables

-You should configure the variables below to whatever may be appropriate for your the ARO cluster in which you wish you enable customer-managed encryption keys:

-```

-aroCluster="mycluster" # The name of the ARO cluster that you wish to enable CMK on. This may be obtained from **az aro list -o table**

-buildRG="mycluster-rg" # The name of the resource group used when you initially built the ARO cluster. This may be obtained from **az aro list -o table**

-desName="aro-des" # Your Azure Disk Encryption Set name. This must be unique in your subscription.

-vaultName="aro-keyvault-1" # Your Azure Key Vault name. This must be unique in your subscription.

-vaultKeyName="myCustomAROKey" # The name of the key to be used within your Azure Key Vault. This is the name of the key, not the actual value of the key that you will rotate.

-```

-## Obtain your subscription ID

-Your Azure subscription ID is used multiple times in the configuration of CMK. Obtain it and store it as a variable:

-```azurecli-interactive

-# Obtain your Azure Subscription ID and store it in a variable

-subId="$(az account list -o tsv | grep True | awk '{print $3}')"

-```

-## Create an Azure Key Vault instance

-An Azure Key Vault instance must be used to store your keys. Create a new Key Vault with purge protection enabled. Then, create a new key within the vault to store your own custom key:

-```azurecli-interactive

-# Create an Azure Key Vault resource in a supported Azure region

-az keyvault create -n $vaultName -g $buildRG --enable-purge-protection true -o table

-# Create the actual key within the Azure Key Vault

-az keyvault key create --vault-name $vaultName --name $vaultKeyName --protection software -o jsonc

-```

-## Create an Azure disk encryption set

-The Azure Disk Encryption Set is used as the reference point for disks in ARO. It is connected to the Azure Key Vault we created in the previous step and will pull customer-managed keys from that location.

-```azurecli-interactive

-# Retrieve the Key Vault Id and store it in a variable

-keyVaultId="$(az keyvault show --name $vaultName --query [id] -o tsv)"

-# Retrieve the Key Vault key URL and store it in a variable

-keyVaultKeyUrl="$(az keyvault key show --vault-name $vaultName --name $vaultKeyName --query [key.kid] -o tsv)"

-# Create an Azure disk encryption set

-az disk-encryption-set create -n $desName -g $buildRG --source-vault $keyVaultId --key-url $keyVaultKeyUrl -o table

-```

-## Grant the Disk Encryption Set access to Key Vault

-Use the disk encryption set we created in the prior steps and grant the disk encryption set access to Azure Key Vault:

-```azurecli-interactive

-# First, find the disk encryption set's Azure Application ID value.

-desIdentity="$(az disk-encryption-set show -n $desName -g $buildRG --query [identity.principalId] -o tsv)"

-# Next, update the Key Vault security policy settings to allow access to the disk encryption set.

-az keyvault set-policy -n $vaultName -g $buildRG --object-id $desIdentity --key-permissions wrapkey unwrapkey get -o table

-# Now, ensure the Disk Encryption Set can read the contents of the Azure Key Vault.

-az role assignment create --assignee $desIdentity --role Reader --scope $keyVaultId -o jsonc

-```

-### Obtain other IDs required for role assignments

-We need to allow the ARO cluster to use the disk encryption set to encrypt the persistent volume claims (PVCs) in the ARO cluster. To do this, we will create a new Managed Service Identity (MSI). We will also set other permissions for the ARO MSI and for the Disk Encryption Set.

-```azurecli-interactive

-# First, get the Azure Application ID of the service principal used in the ARO cluster.

-aroSPAppId="$(az aro show -n $aroCluster -g $buildRG -o tsv --query servicePrincipalProfile.clientId)"

-# Next, get the object ID of the service principal used in the ARO cluster.

-aroSPObjId="$(az ad sp show --id $aroSPAppId -o tsv --query [objectId])"

-# Set the name of the ARO Managed Service Identity.

-msiName="$aroCluster-msi"

-# Create the Managed Service Identity (MSI) required for disk encryption.

-az identity create -g $buildRG -n $msiName -o jsonc

-# Get the ARO Managed Service Identity Azure Application ID.

-aroMSIAppId="$(az identity show -n $msiName -g $buildRG -o tsv --query [clientId])"

-# Get the resource ID for the disk encryption set and the Key Vault resource group.

-buildRGResourceId="$(az group show -n $buildRG -o tsv --query [id])"

-```

-### Implement other role assignments required for CMK encryption

-Apply the required role assignments using the variables obtained in the previous step:

-```azurecli-interactive

-# Ensure the Azure Disk Encryption Set can read the contents of the Azure Key Vault.

-az role assignment create --assignee $desIdentity --role Reader --scope $keyVaultId -o jsonc

-# Assign the MSI AppID 'Reader' permission over the disk encryption set & Key Vault resource group.

-az role assignment create --assignee $aroMSIAppId --role Reader --scope $buildRGResourceId -o jsonc

-# Assign the ARO Service Principal 'Contributor' permission over the disk encryption set & Key Vault Resource Group.

-az role assignment create --assignee $aroSPObjId --role Contributor --scope $buildRGResourceId -o jsonc

-```

-## Create a k8s Storage Class for encrypted Premium & Ultra disks

-Generate storage classes to be used for CMK for Premium_LRS and UltraSSD_LRS disks:

-```azurecli-interactive

-# Premium Disks

-cat > managed-premium-encrypted-cmk.yaml<< EOF

-kind: StorageClass

-apiVersion: storage.k8s.io/v1

-metadata:

- name: managed-premium-encrypted-cmk

-provisioner: kubernetes.io/azure-disk

-parameters:

- skuname: Premium_LRS

- kind: Managed

- diskEncryptionSetID: "/subscriptions/$subId/resourceGroups/$buildRG/providers/Microsoft.Compute/diskEncryptionSets/$desName"

- resourceGroup: $buildRG

-reclaimPolicy: Delete

-allowVolumeExpansion: true

-volumeBindingMode: WaitForFirstConsumer

-EOF

-# Ultra Disks

-cat > managed-ultra-encrypted-cmk.yaml<< EOF

-kind: StorageClass

-apiVersion: storage.k8s.io/v1

-metadata:

- name: managed-ultra-encrypted-cmk

-provisioner: kubernetes.io/azure-disk

-parameters:

- skuname: UltraSSD_LRS

- kind: Managed

- diskEncryptionSetID: "/subscriptions/$subId/resourceGroups/$buildRG/providers/Microsoft.Compute/diskEncryptionSets/$desName"

- resourceGroup: $buildRG

- cachingmode: None

- diskIopsReadWrite: "2000" # minimum value: 2 IOPS/GiB

- diskMbpsReadWrite: "320" # minimum value: 0.032/GiB

-reclaimPolicy: Delete

-allowVolumeExpansion: true

-volumeBindingMode: WaitForFirstConsumer

-EOF

-```

-Next, run this deployment in your ARO cluster to apply the storage class configuration:

-```azurecli-interactive

-# Update cluster with the new storage classes

-oc apply -f managed-premium-encrypted-cmk.yaml

-oc apply -f managed-ultra-encrypted-cmk.yaml

-```

-## Test encryption with customer-managed keys (optional)

-To check if your cluster is using a customer-managed key for PVC encryption, we will create a persistent volume claim using the new storage class. The code snippet below creates a pod and mounts a persistent volume claim using Premium disks.

-```

-# Create a pod which uses a persistent volume claim referencing the new storage class

-cat > test-pvc.yaml<< EOF

-apiVersion: v1

-kind: PersistentVolumeClaim

-metadata:

- name: mypod-with-cmk-encryption-pvc

-spec:

- accessModes:

- - ReadWriteOnce

- storageClassName: managed-premium-encrypted-cmk

- resources:

- requests:

- storage: 1Gi

-kind: Pod

-apiVersion: v1

-metadata:

- name: mypod-with-cmk-encryption

-spec:

- containers:

- - name: mypod-with-cmk-encryption

- image: mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine

- resources:

- requests:

- cpu: 100m

- memory: 128Mi

- limits:

- cpu: 250m

- memory: 256Mi

- volumeMounts:

- - mountPath: "/mnt/azure"

- name: volume

- volumes:

- - name: volume

- persistentVolumeClaim:

- claimName: mypod-with-cmk-encryption-pvc

-EOF

-```

-### Apply the test pod configuration file (optional)

-Execute the commands below to apply the test Pod configuration and return the UID of the new persistent volume claim. The UID will be used to verify the disk is encrypted using CMK.

-```azurecli-interactive

-# Apply the test pod configuration file and set the PVC UID as a variable to query in Azure later.

-pvcUid="$(oc apply -f test-pvc.yaml -o jsonpath='{.items[0].metadata.uid}')"

-# Determine the full Azure Disk name.

-pvName="$(oc get pv pvc-$pvcUid -o jsonpath='{.spec.azureDisk.diskName}')"

-```

-> [!NOTE]

-> On occasion there may be a slight delay when applying role assignments within Microsoft Entra ID. Depending upon the speed that these instructions are executed, the command to "Determine the full Azure Disk name" may not succeed. If this occurs, review the output of **oc describe pvc mypod-with-cmk-encryption-pvc** to ensure that the disk was successfully provisioned. If the role assignment propagation has not completed you may need to *delete* and re-*apply* the Pod & PVC YAML.

-### Verify PVC disk is configured with "EncryptionAtRestWithCustomerKey" (Optional)

-The Pod should create a persistent volume claim that references the CMK storage class. Running the following command will validate that the PVC has been deployed as expected:

-```azurecli-interactive

-# Describe the OpenShift cluster-wide persistent volume claims

-oc describe pvc

-# Verify with Azure that the disk is encrypted with a customer-managed key

-az disk show -n $pvName -g $buildRG -o json --query [encryption]

-```

-<!-- LINKS - external -->

-<!-- LINKS - internal -->

-[az-extension-add]: /cli/azure/extension#az_extension_add

-[az-extension-update]: /cli/azure/extension#az_extension_update

-[best-practices-security]: ../aks/operator-best-practices-cluster-security.md

-[byok-azure-portal]: ../storage/common/customer-managed-keys-configure-key-vault.md

-[customer-managed-keys]: ../virtual-machines/disk-encryption.md#customer-managed-keys

-[key-vault-generate]: ../key-vault/general/manage-with-cli2.md

-[supported-regions]: ../virtual-machines/disk-encryption.md#supported-regions

-> Please note this process is used in emergency situations when all other troubleshooting options using Azure are exhausted. SSH access to these bare metal machines is restricted to users managed via this method from the specified jump host list.

-You can restore the runtime version on a BMM by executing the `reimage` command. This process **redeploys** the runtime image on the target BMM and executes the steps to rejoin the cluster with the same identifiers. This action doesn't affect the tenant workload files on this BMM.

- - Purity Code Level: 6.5.1

-description: Learn the storage appliance software versions supported by Azure Operator Nexus versions

-Minor version releases include new features and improvements. Patch releases are made available frequently and are intended for critical bug fixes within a minor version. Patch releases include fixes for security vulnerabilities or major bugs.

-PurityOS uses the standard [Semantic Versioning](https://semver.org/) versioning scheme for each version:

-* **Minor version numbers** change when functionality updates are made that are backwards compatible to the other minor releases.

-* **Patch version numbers** change when backwards-compatible bug fixes are made.

-We strongly recommend staying up to date with the latest available patches. For example, if your production cluster is on **`6.5.1`**, and **`6.5.4`** is the latest available patch version available for the *6.5* series. You should upgrade to **`6.5.4`** as soon as possible to ensure your cluster is fully patched and supported.

-## Supported Storage Software Versions

-| PurityOS version | Nexus GA | End of support |

-|-||-|

-| 6.1.x | Year 2021 | Jul 2024 |

-| 6.5.1 | Nexus 2403.x | Dec 2025 |

-| 6.5.4 | Nexus 2404.x | Dec 2025 |

-### How does Microsoft notify me of new Kubernetes versions?

-This document is updated periodically with planned dates of the new Storage Software versions supported.

-### What happens when a version reaches end of support?

-When a version reaches end of support, it will no longer receive patches or updates. We recommend upgrading to a supported version as soon as possible.

-If you don't upgrade your storage appliance software, you continue to receive support for the software version you're running until the end of the support period. After that, you'll no longer receive support for your storage appliance. You need to upgrade your cluster to a supported version to continue receiving support.

-* You're asked to upgrade the storage appliance software to a supported version when requesting support.

-This document provides the list of software versioning supported in Release 2404.2 of Azure Operator Nexus.

-| **Instance Cluster AKS** | 1.28.3 | |

-| **Azure Linux** | 2.0.20240301 | |

-| **Purity** | 6.5.1, 6.5.4 | |

-The [SAP RISE certified](https://www.sap.com/dmc/exp/2013_09_adpd/enEN/#/solutions?id=s:33db1376-91ae-4f36-a435-aafa892a88d8) Microsoft Sentinel solution for SAP applications allows you to monitor, detect, and respond to suspicious activities. Microsoft Sentinel guards your critical data against sophisticated cyberattacks for SAP systems hosted on Azure, other clouds, or on-premises infrastructure.

- This diagram shows an example of Microsoft Sentinel connected through an intermediary VM or container to SAP managed SAP system. The intermediary VM or container runs in customer's own subscription with configured SAP data connector agent.

-Note for running Microsoft Sentinel in an SAP RISE/ECS environment:

-This article shows how you can schedule one-time and recurring jobs by creating automated workflows with Azure Logic Apps, rather than with Azure Scheduler. When you create scheduled jobs with Azure Logic Apps, you get the following benefits:

-* Build your job by using a visual designer and [ready-to-use connectors](/connectors/connector-reference/connector-reference-logicapps-connectors) from hundreds of services, such as Azure Blob Storage, Azure Service Bus, Office 365 Outlook, and SAP.

-To learn more, see [What is Azure Logic Apps?](../logic-apps/logic-apps-overview.md) or try creating your first logic app workflow by following the [Quickstart: Create an example Consumption logic app workflow in multi-tenant Azure Logic Apps](../logic-apps/quickstart-create-example-consumption-workflow.md).

-* To trigger your logic app workflow by sending HTTP requests, use a tool such as the [Postman desktop app](https://www.getpostman.com/apps).

-## Schedule one-time jobs

-1. In the [Azure portal](https://portal.azure.com), create a blank logic app workflow using the designer.

- For the basic steps, follow [Create an example Consumption logic app workflow](../logic-apps/quickstart-create-example-consumption-workflow.md).

-1. In the designer search box, enter **when a http request** to find the **Request** trigger. From the **Triggers** list, select the trigger named **When a HTTP request is received**.

- 

-1. For the Request trigger, you can optionally provide a JSON schema, which helps the workflow designer understand the structure for the inputs included in the inbound call to the Request trigger and makes the outputs easier for you to select later in your workflow.

- 1. In the Request trigger, select **Use sample payload to generate schema**.

-1. Under the trigger, select **Next step**.

-1. In the designer search box, enter **delay until**. From the **Actions** list, select the action named **Delay until**.

- This action pauses your logic app workflow until a specified date and time, for example:

-1. Enter the timestamp for when you want to start the logic app's workflow.

- When you click inside the **Timestamp** box, the dynamic content list appears so that you can optionally select an output from the trigger.

-1. Add any other actions you want to run by selecting from [hundreds of ready-to-use connectors](/connectors/connector-reference/connector-reference-logicapps-connectors).

- For example, you can include an HTTP action that sends a request to a URL or actions that work with Storage Queues, Service Bus queues, or Service Bus topics:

-1. When you're done, save your logic app workflow.

- 

- When you save your logic app workflow for the first time, the endpoint URL for your logic app workflow's Request trigger appears in the **HTTP POST URL** box. To trigger your logic app workflow and send inputs to your workflow for processing, send a request to the generated URL as the call destination, for example:

-1. Copy and save the endpoint URL so that you can later send a manual request to trigger your logic app workflow.

-## Start a one-time job

-To manually run or trigger a one-time job, send a call to the endpoint URL for your logic app's Request trigger. In this call, specify the input or payload to send, which you might have described earlier by specifying a schema.

-For example, using the Postman app, you can create a POST request with the settings similar to this sample, and then select **Send** to make the request.

-| **POST** | <*endpoint-URL*> | **raw** <p>**JSON(application/json)** <p>In the **raw** box, enter the payload that you want to send in the request. <p>**Note**: This setting automatically configures the **Headers** values. | **Key**: Content-Type <br>**Value**: application/json |

-|||||

-

-After you send the call, the response from your logic app workflow appears under the **raw** box on the **Body** tab.

-> [!IMPORTANT]

->

-> If you want to cancel the job later, select the **Headers** tab.

-> Find and copy the **x-ms-workflow-run-id** header value in the response.

->

-> 

-In Azure Logic Apps, each one-time job executes as a single workflow run instance. To cancel a one-time job, you can use [Workflow Runs - Cancel](/rest/api/logic/workflowruns/cancel) in the Azure Logic Apps REST API. When you send a call to the trigger, provide the [workflow run ID](#workflow-run-id).

-## Schedule recurring jobs

-1. In the [Azure portal](https://portal.azure.com), create a blank logic app workflow in the designer.

- For the basic steps, follow [Create an example Consumption logic app workflow in multi-tenant Azure Logic Apps](../logic-apps/quickstart-create-example-consumption-workflow.md).

-1. In the designer search box, enter **recurrence**. From the **Triggers** list, select the trigger named **Recurrence**.

- 

- 

- For more information about advanced scheduling options, review [Create and run recurring tasks and workflows with Azure Logic Apps](../connectors/connectors-native-recurrence.md).

-1. Add other actions you want by selecting from [hundreds of ready-to-use connectors](/connectors/connector-reference/connector-reference-logicapps-connectors). Under the trigger, select **Next step**. Find and select the actions you want.

- For example, you can include an HTTP action that sends a request to a URL, or actions that work with Storage Queues, Service Bus queues, or Service Bus topics:

-1. When you're done, save your logic app workflow.

- 

-To control the way that an action tries to rerun in your logic app workflow when intermittent failures happen, you can set the [retry policy](../logic-apps/logic-apps-exception-handling.md#retry-policies) in each action's settings, for example:

-1. Open the action's ellipses (**...**) menu, and select **Settings**.

- 

-1. Select the retry policy that you want. For more information about each policy, review [Retry policies](../logic-apps/logic-apps-exception-handling.md#retry-policies).

- 

-In Azure Scheduler, if the default action fails to run, you can run an alterative action that addresses the error condition. In Azure Logic Apps, you can also perform the same task.

-1. In the workflow designer, above the action that you want to handle, move your pointer over the arrow between steps, and select **Add a parallel branch**.

- 

- 

-1. On the alternative action, open the ellipses (**...**) menu, and select **Configure run after**.

- 

- 

-To learn more about exception handling, see [Handle errors and exceptions - RunAfter property](../logic-apps/logic-apps-exception-handling.md#control-run-after-behavior).

-**Q**: When is Azure Scheduler retiring? <br>

-**A**: As a best practice, always back up your work. Check that the logic app workflows that you created are running as expected before deleting or disabling your Azure Scheduler jobs.

-**Q**: What will happen to my scheduled Azure Web Jobs from Azure Scheduler? <br>

- |||

-* [Create an example Consumption logic app workflow in multi-tenant Azure Logic Apps](../logic-apps/quickstart-create-example-consumption-workflow.md)

-This quickstart helps you get started with [integrated vectorization (preview)](vector-search-integrated-vectorization.md) by using the **Import and vectorize data** wizard in the Azure portal. This wizard calls a user-specified embedding model to vectorize content during indexing and for queries.

-## Preview limitations

-+ Source data is either Azure Blob Storage or OneLake files and shortcuts, using the default parsing mode (one search document per blob or file).

-+ The index schema is nonconfigurable. Source fields include `content` (chunked and vectorized), `metadata_storage_name` for the title, and `metadata_storage_path` for the document key. This key is represented as `parent_id` in the index.

-For fewer limitations or more data source options, try a code-base approach. For more information, see the [integrated vectorization sample](https://github.com/Azure/azure-search-vector-samples/blob/main/demo-python/code/integrated-vectorization/azure-search-integrated-vectorization-sample.ipynb).

-+ For data, either [Azure Blob Storage](/azure/storage/common/storage-account-overview) or a [OneLake lakehouse](search-how-to-index-onelake-files.md).

- Azure Storage must be a standard performance (general-purpose v2) account. Access tiers can be hot, cool, and cold.

-

- Don't use Azure Data Lake Storage Gen2 (a storage account with a hierarchical namespace). This version of the wizard doesn't support Data Lake Storage Gen2.

-+ For vectorization, an [Azure AI services multiservice account](/azure/ai-services/multi-service-resource) or [Azure OpenAI Service](https://aka.ms/oai/access) endpoint with deployments.

- For [multimodal with Azure AI Vision](/azure/ai-services/computer-vision/how-to/image-retrieval), create an Azure AI service in SwedenCentral, EastUS, NorthEurope, WestEurope, WestUS, SoutheastAsia, KoreaCentral, FranceCentral, AustraliaEast, WestUS2, SwitzerlandNorth, or JapanEast. [Check the documentation](/azure/ai-services/computer-vision/how-to/image-retrieval?tabs=csharp) for an updated list.

- You can also use an [Azure AI Studio model catalog](/azure/ai-studio/what-is-ai-studio) (and hub and project) with model deployments.

-+ For indexing and queries, Azure AI Search. It must be in the same region as your Azure AI service. We recommend the Basic tier or higher.

-+ Role assignments or API keys for connections to embedding models and data sources. This article provides instructions for role-based access control (RBAC).

-A free search service supports RBAC on connections to Azure AI Search, but it doesn't support managed identities on outbound connections to Azure Storage or Azure AI Vision. This level of support means you must use key-based authentication on connections between a free search service and other Azure services. For connections that are more secure:

-+ Use the Basic tier or higher.

-+ [Configure a managed identity](search-howto-managed-identities-data-sources.md) and role assignments to admit requests from Azure AI Search on other Azure services.

-> [!NOTE]

-> If you can't progress through the wizard because options aren't available (for example, you can't select a data source or an embedding model), revisit the role assignments. Error messages indicate that models or deployments don't exist, when in fact the real problem is that the search service doesn't have permission to access them.

-## Check for space

-If you're starting with the free service, you're limited to three indexes, three data sources, three skillsets, and three indexers. Make sure you have room for extra items before you begin. This quickstart creates one of each object.

-## Check for service identity

-We recommend role assignments for search service connections to other resources.

-1. On Azure AI Search, [enable RBAC](search-security-enable-roles.md).

-1. Configure your search service to [use a system-assigned or user-assigned managed identity](search-howto-managed-identities-data-sources.md#create-a-system-managed-identity).

-In the following sections, you can assign the search service's managed identity to roles in other services. The sections provide steps for role assignments where applicable.

-## Check for semantic ranking

- > - If you see failures due to lack of capacity (no messaging units available), raise a support ticket with us.

-Using certain Service Bus features require compute utilization that can decrease the expected throughput. Some of these features are -

-If your application uses any of the above features and you aren't receiving the expected throughput, you can review the **CPU usage** metrics and consider scaling up your Service Bus Premium namespace.

-You can also utilize Azure Monitor to [automatically scale the Service Bus namespace](automate-update-messaging-units.md).

-* Use asynchronous operations to take advantage of client-side batching.

-* Leave batched store access enabled. This access increases the overall rate at which messages can be written into the queue.

-* Disable client-side batching. The client immediately sends a message.

-* Disable batched store access. The service immediately writes the message to the store.

-* Use asynchronous operations to take advantage of client-side batching.

-* Leave batched store access enabled. This access increases the overall rate at which messages can be written into the queue or topic.

-* Receivers can use synchronous or asynchronous operations. Given the moderate receive rate of an individual receiver, client-side batching of a Complete request doesn't affect receiver throughput.

-* Leave batched store access enabled. This access reduces the overall load of the entity. It also increases the overall rate at which messages can be written into the queue or topic.

-* Use asynchronous operations to take advantage of client-side batching.

-* Leave batched store access enabled. This access increases the overall rate at which messages can be written into the topic.

-* Use asynchronous operations to take advantage of client-side batching.

-* Leave batched store access enabled. This access increases the overall rate at which messages can be written into the topic.

-Take time to consider the amount of bandwidth a new machine uses before you deploy it to your network. An Azure Storage Mover agent communicates with a source share using the local network, and the Azure Storage service on the wide area network (WAN) link. In both cases, the agent uses all available network bandwidth.

-> [!IMPORTANT]

-> The current Azure Storage Mover agent does not support bandwidth throttling schedules.

-If bandwidth throttling is important to you, create a local virtual network with an internet connection and configure quality of service (QoS) settings. This approach allows you to expose the agent through the virtual network and to locally configure an unauthenticated network proxy server on the agent if needed.

-Azure Stream Analytics stores customer data and other metadata described above. Customer data is stored by Azure Stream Analytics in a single region by default, so this service automatically satisfies in region data residency requirements including those specified in the [Trust Center](https://azuredatacentermap.azurewebsites.net/).

-Stream Analytics automatically employs best-in-class encryption standards across its infrastructure to encrypt and secure your data. You can simply trust Stream Analytics to securely store all your data so that you don't have to worry about managing the infrastructure.

-This setting must be configured at the time of Stream Analytics job creation, and it can't be modified throughout the job's life cycle. Modification or deletion of storage that is being used by your Stream Analytics is not recommended. If you delete your storage account, you will permanently delete all private data assets, which will cause your job to fail.

-Updating or rotating keys to your storage account is not possible using the Stream Analytics portal. You can update the keys using the REST APIs. You can also connect to your job storage account using managed identity authentication with allow trusted services.

-If the storage account you want to use is in an Azure Virtual Network, you must use managed identity authentication mode with **Allow trusted services**. For more information, visit: [Connect Stream Analytics jobs to resources in an Azure Virtual Network (VNet)](connect-job-to-vnet.md).

-1. Select a storage account from your subscription. Note that this setting cannot be modified throughout the life cycle of the job. You also cannot add this option once the job is created.

-1. To authenticate with Managed Identity, select **Managed Identity** from the Authentication mode dropdown. If you choose Managed Identity, you need to add your Stream Analytics job to the storage account's access control list with the *Storage Blob Data Contributor* role. If you do not give your job access, the job will not be able to perform any operations. For more information on how to grant access, see [Use Azure RBAC to assign a managed identity access to another resource](../active-directory/managed-identities-azure-resources/howto-assign-access-portal.md#use-azure-rbac-to-assign-a-managed-identity-access-to-another-resource).

-You may use this feature to enforce any data residency requirements you may have by providing a storage account accordingly.

- Periodic assessment is an update setting on a machine that allows you to enable automatic periodic checking of updates by Update Manager. We recommend that you enable this property on your machines as it allows Update Manager to fetch latest updates for your machines every 24 hours and enables you to view the latest compliance status of your machines. You can enable this setting using update settings flow as detailed [here](manage-update-settings.md#configure-settings-on-a-single-vm) or enable it at scale by using [Policy](periodic-assessment-at-scale.md). Learn more on [Azure VM extensions](overview.md#vm-extensions).

-If scheduled patching is configured on your machine using the Azure Update Manager, the Auto update on the client is disabled. To edit the registry and configure the setting, see [First party updates on Windows](support-matrix.md#first-party-updates-on-windows).

-> Azure Log Analytics agent, also known as the Microsoft Monitoring Agent (MMA) will be [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](guidance-migration-automation-update-management-azure-update-manager.md) to move your machines and schedules from Automation Update Management to Azure Update Manager.

-Update Manager is a unified service to help manage and govern updates for all your machines. You can monitor Windows and Linux update compliance across your deployments in Azure, on-premises, and on other cloud platforms from a single dashboard. You can also use Update Manager to make real-time updates or schedule them within a defined maintenance window.

-You can use Update Manager in Azure to:

-We also offer other capabilities to help you manage updates for your Azure VMs that you should consider as part of your overall update management strategy. To learn more about the options that are available, see the Azure VM [update options](../virtual-machines/updates-maintenance-overview.md).

-Before you enable your machines for Update Manager, make sure that you understand the information in the following sections.

-Update Manager has been redesigned and doesn't depend on Azure Automation or Azure Monitor Logs, as required by the [Azure Automation Update Management feature](../automation/update-management/overview.md). Update Manager offers many new features and provides enhanced functionality over the original version available with Azure Automation. Some of those benefits are listed here:

- - Built as native functionality on Azure compute and the Azure Arc for Servers platform for ease of use.

- - No dependency on Log Analytics and Azure Automation.

- - Azure Policy support.

- - Global availability in all Azure compute and Azure Arc regions.

- - Granular access control at the per-resource level instead of access control at the level of the Azure Automation account and Log Analytics workspace.

- - Update Manager now has Azure Resource Manager-based operations. It allows role-based access control and roles based on Azure Resource Manager in Azure.

- - Ability to take immediate action either by installing updates immediately or scheduling them for a later date.

- - Check updates automatically or on demand.

- - Helps secure machines with new ways of patching, such as [automatic VM guest patching](../virtual-machines/automatic-vm-guest-patching.md) in Azure, [hot patching](../automanage/automanage-hotpatch.md), or custom maintenance schedules.

- - Sync patch cycles in relation to "patch Tuesday," the unofficial term for Microsoft's scheduled security fix release on every second Tuesday of each month.

-The following diagram illustrates how Update Manager assesses and applies updates to all Azure machines and Azure Arc-enabled servers for both Windows and Linux.

-

-To support management of your Azure VM or non-Azure machine, Update Manager relies on a new [Azure extension](../virtual-machines/extensions/overview.md) designed to provide all the functionality required to interact with the operating system to manage the assessment and application of updates. This extension is automatically installed when you initiate any Update Manager operations, such as **Check for updates**, **Install one-time update**, and **Periodic Assessment** on your machine. The extension supports deployment to Azure VMs or Azure Arc-enabled servers by using the extension framework. The Update Manager extension is installed and managed by using:

- Update Manager manages the extension agent installation and configuration. Manual intervention isn't required as long as the Azure VM agent or Azure Arc-enabled server agent is functional. The Update Manager extension runs code locally on the machine to interact with the operating system, and it includes:

-All assessment information and update installation results are reported to Update Manager from the extension and is available for analysis with [Azure Resource Graph](../governance/resource-graph/overview.md). You can view up to the last seven days of assessment data, and up to the last 30 days of update installation results.

-The machines assigned to Update Manager report how up to date they are based on what source they're configured to synchronize with. You can configure [Windows Update Agent (WUA)](/windows/win32/wua_sdk/updating-the-windows-update-agent) on Windows machines to report to [Windows Server Update Services](/windows-server/administration/windows-server-update-services/get-started/windows-server-update-services-wsus) or Microsoft Update, which is by default. You can configure Linux machines to report to a local or public YUM or APT package repository. If the Windows Update Agent is configured to report to WSUS, depending on when WSUS last synchronized with Microsoft Update, the results in Update Manager might differ from what Microsoft Update shows. This behavior is the same for Linux machines that are configured to report to a local repository instead of a public package repository.

-> [!NOTE]

-> WSUS isn't available in Azure China operated by 21 Vianet.

-You can manage your Azure VMs or Azure Arc-enabled servers directly or at scale with Update Manager.

-## Prerequisites

-Along with the following prerequisites, see [Support matrix](support-matrix.md) for Update Manager.

-### Role

-Resource | Role

- |

-|Azure VM | [Azure Virtual Machine Contributor](../role-based-access-control/built-in-roles.md#virtual-machine-contributor) or Azure [Owner](../role-based-access-control/built-in-roles.md#owner)

-Azure Arc-enabled server | [Azure Connected Machine Resource Administrator](../azure-arc/servers/security-identity-authorization.md#identity-and-access-control)

-### Permissions

-You need the following permissions to create and manage update deployments. The table shows the permissions that are needed when you use Update Manager.

-Actions |Permission |Scope |

- | | |

-|Read Azure VM properties | Microsoft.Compute/virtualMachines/read ||

-|Update assessment on Azure VMs |Microsoft.Compute/virtualMachines/assessPatches/action ||

-|Read assessment data for Azure VMs | Microsoft.Compute/virtualMachines/patchAssessmentResults/latest </br> Microsoft.Compute/virtualMachines/patchAssessmentResults/latest/softwarePatches ||

-|Install update on Azure VMs |Microsoft.Compute/virtualMachines/installPatches/action ||

-|Read patch installation data for Azure VMs | Microsoft.Compute/virtualMachines/patchInstallationResults </br> Microsoft.Compute/virtualMachines/patchInstallationResults/softwarePatches ||

-|Read Azure Arc-enabled server properties | Microsoft.HybridCompute/machines/read||

-|Update assessment on Azure Arc-enabled server |Microsoft.HybridCompute/machines/assessPatches/action ||

-|Read assessment data for Azure Arc-enabled server | Microsoft.HybridCompute/machines/patchAssessmentResults </br> Microsoft.HybridCompute/machines/patchAssessmentResults/softwarePatches ||

-|Install update on Azure Arc-enabled server |Microsoft.HybridCompute/machines/installPatches/action ||

-|Read patch installation data for Azure Arc-enabled server | Microsoft.HybridCompute/machines/patchInstallationResults </br> Microsoft.HybridCompute/machines/patchInstallationResults/softwarePatches||

-|Register the subscription for the Microsoft.Maintenance resource provider| Microsoft.Maintenance/register/action | Subscription|

-|Create/modify maintenance configuration |Microsoft.Maintenance/maintenanceConfigurations/write |Subscription/resource group |

-|Create/modify configuration assignments |Microsoft.Maintenance/configurationAssignments/write |Subscription |

-|Read permission for Maintenance updates resource |Microsoft.Maintenance/updates/read |Machine |

-|Read permission for Maintenance apply updates resource |Microsoft.Maintenance/applyUpdates/read |Machine |

-### VM images

-For more information, see the [list of supported operating systems and VM images](support-matrix.md#supported-operating-systems).

- Azure Update Manager supports [specialized images](../virtual-machines/linux/imaging.md#specialized-images) including the VMs created by Azure Migrate, Azure Backup, and Azure Site Recovery.

-## VM extensions

-Azure VM extensions and Azure Arc-enabled VM extensions are available.

-#### [Azure VM extensions](#tab/azure-vms)

-| Operating system| Extension

-|-|-|

-|Windows | Microsoft.CPlat.Core.WindowsPatchExtension|

-|Linux | Microsoft.CPlat.Core.LinuxPatchExtension |

-#### [Azure Arc-enabled VM extensions](#tab/azure-arc-vms)

-| Operating system| Extension

-|-|-|

-|Windows | Microsoft.CPlat.Core.WindowsPatchExtension (Periodic assessment) <br> Microsoft.SoftwareUpdateManagement.WindowsOsUpdateExtension (On-demand operations and Schedule patching) |

-|Linux | Microsoft.SoftwareUpdateManagement.LinuxOsUpdateExtension (On-demand operations and Schedule patching) <br> Microsoft.CPlat.Core.LinuxPatchExtension (Periodic assessment) |

-To view the available extensions for a VM in the Azure portal:

-1. Go to the [Azure portal](https://portal.azure.com) and select a VM.

-1. On the VM home page, under **Settings**, select **Extensions + applications**.

-1. On the **Extensions** tab, you can view the available extensions.

-### Network planning

-To prepare your network to support Update Manager, you might need to configure some infrastructure components.

-For Windows machines, you must allow traffic to any endpoints required by the Windows Update agent. You can find an updated list of required endpoints in [Issues related to HTTP/Proxy](/windows/deployment/update/windows-update-troubleshooting#issues-related-to-httpproxy). If you have a local [WSUS](/windows-server/administration/windows-server-update-services/plan/plan-your-wsus-deployment) deployment, you must also allow traffic to the server specified in your [WSUS key](/windows/deployment/update/waas-wu-settings#configuring-automatic-updates-by-editing-the-registry).

-For Red Hat Linux machines, see [IPs for the RHUI content delivery servers](../virtual-machines/workloads/redhat/redhat-rhui.md#the-ips-for-the-rhui-content-delivery-servers) for required endpoints. For other Linux distributions, see your provider documentation.

-1. See [Prerequisites for Update Manager](./overview.md#prerequisites).

- > If you set the patch mode to **Azure orchestrated** (`AutomaticByPlatform`) but do not enable the **BypassPlatformSafetyChecksOnUserSchedule** flag and do not attach a maintenance configuration to an Azure machine, it's treated as an [automatic guest patching](../virtual-machines/automatic-vm-guest-patching.md)-enabled machine. The Azure platform automatically installs updates according to its own schedule. [Learn more](./overview.md#prerequisites).

-> This article references CentOS, a Linux distribution that is End Of Life (EOL) status. Please consider your use and plan accordingly.

-## Supported update sources

-**Windows**: [Windows Update Agent (WUA)](/windows/win32/wua_sdk/updating-the-windows-update-agent) reports to Microsoft Update by default, but you can configure it to report to [Windows Server Update Services (WSUS)](/windows-server/administration/windows-server-update-services/get-started/windows-server-update-services-wsus). If you configure WUA to report to WSUS, based on the last synchronization from WSUS with Microsoft Update, the results in Update Manager might differ from what Microsoft Update shows.

-To specify sources for scanning and downloading updates, see [Specify intranet Microsoft Update service location](/windows/deployment/update/waas-wu-settings?branch=main#specify-intranet-microsoft-update-service-location). To restrict machines to the internal update service, see [Don't connect to any Windows Update internet locations](/windows-server/administration/windows-server-update-services/deploy/4-configure-group-policy-settings-for-automatic-updates?branch=main#do-not-connect-to-any-windows-update-internet-locations).

-**Linux**: You can configure Linux machines to report to a local or public YUM or APT package repository. The results shown in Update Manager depend on where the machines are configured to report.

-## Supported update types

-The following types of updates are supported.

-### Operating system updates

-Update Manager supports operating system updates for both Windows and Linux.

-Update Manager doesn't support driver updates.

-### Extended Security Updates (ESU) for Windows Server

-Using Azure Update Manager, you can deploy Extended Security Updates for your Azure Arc-enabled Windows Server 2012 / R2 machines. To enroll in Windows Server 2012 Extended Security Updates, follow the guidance on [How to get Extended Security Updates (ESU) for Windows Server 2012 and 2012 R2.](/windows-server/get-started/extended-security-updates-deploy#extended-security-updates-enabled-by-azure-arc)

-### First-party updates on Windows

-By default, the Windows Update client is configured to provide updates only for the Windows operating system. If you enable the **Give me updates for other Microsoft products when I update Windows** setting, you also receive updates for other Microsoft products. Updates include security patches for Microsoft SQL Server and other Microsoft software.

-Use one of the following options to perform the settings change at scale:

- ```powershell

- $ServiceManager = (New-Object -com "Microsoft.Update.ServiceManager")

- $ServiceManager.Services

- $ServiceID = "7971f918-a847-4430-9279-4a52d1efe18d"

- $ServiceManager.AddService2($ServiceId,7,"")

- ```

-> [!NOTE]

-> Run the following PowerShell script on the server to disable first-party updates:

->

-> ```powershell

-> $ServiceManager = (New-Object -com "Microsoft.Update.ServiceManager")

-> $ServiceManager.Services

-> $ServiceID = "7971f918-a847-4430-9279-4a52d1efe18d"

-> $ServiceManager.RemoveService($ServiceId)

-> ```

-### Third party updates

-**Windows**: Update Manager relies on the locally configured update repository to update supported Windows systems, either WSUS or Windows Update. Tools such as [System Center Updates Publisher](/mem/configmgr/sum/tools/updates-publisher) allow you to import and publish custom updates with WSUS. This scenario allows Update Manager to update machines that use Configuration Manager as their update repository with third party software. To learn how to configure Updates Publisher, see [Install Updates Publisher](/mem/configmgr/sum/tools/install-updates-publisher).

-**Linux**: If you include a specific third party software repository in the Linux package manager repository location, it's scanned when it performs software update operations. The package isn't available for assessment and installation if you remove it.

-Update Manager doesn't support managing the Configuration Manager client.

-## Supported regions

-Update Manager scales to all regions for both Azure VMs and Azure Arc-enabled servers. The following table lists the Azure public cloud where you can use Update Manager.

-#### [Azure Public cloud](#tab/public)

-### Azure VMs

-Azure Update Manager is available in all Azure public regions where compute virtual machines are available.

-### Azure Arc-enabled servers

-Azure Update Manager is currently supported in the following regions. It implies that VMs must be in the following regions.

-**Geography** | **Supported regions**

- |

-Africa | South Africa North

-Asia Pacific | East Asia </br> South East Asia

-Australia | Australia East </br> Australia Southeast

-Brazil | Brazil South

-Canada | Canada Central </br> Canada East

-Europe | North Europe </br> West Europe

-France | France Central

-Germany | Germany West Central

-India | Central India

-Japan | Japan East

-Korea | Korea Central

-Norway | Norway East

-Sweden | Sweden Central

-Switzerland | Switzerland North

-UAE | UAE North

-United Kingdom | UK South </br> UK West

-United States | Central US </br> East US </br> East US 2</br> North Central US </br> South Central US </br> West Central US </br> West US </br> West US 2 </br> West US 3

-#### [Azure for US Government](#tab/gov)

-**Geography** | **Supported regions** | **Details**

- | |

-United States | USGovVirginia </br> USGovArizona </br> USGovTexas | For both Azure VMs and Azure Arc-enabled servers </br> For both Azure VMs and Azure Arc-enabled servers </br> For Azure VMs only

-#### [Azure operated by 21Vianet](#tab/21via)

-**Geography** | **Supported regions** | **Details**

- | |

-China | ChinaEast </br> ChinaEast3 </br> ChinaNorth </br> ChinaNorth3 </br> ChinaEast2 </br> ChinaNorth2 | For Azure VMs only </br> For Azure VMs only </br> For Azure VMs only </br> For both Azure VMs and Azure Arc-enabled servers </br> For both Azure VMs and Azure Arc-enabled servers </br> For both Azure VMs and Azure Arc-enabled servers.

-### Support for Azure Update Manager operations

-### Support for all other Azure Update Manager operations

-Azure Update Manager supports the following operations:

-|`0x8024402C`</br>`0x8024401C`</br>`0x8024402F` | Indicates network connectivity problems. Make sure your machine has network connectivity to Update Management. For a list of required ports and addresses, see the [Network planning](overview.md#network-planning) section. |

-For more information, see the [list of permissions list for various resources here](../update-manager/overview.md#permissions).

-## Next steps