- :::image type="content" source="media/leave-the-organization/external-user-leave-settings.png" alt-text="Screenshot showing External user leave settings in the portal.":::

-If you donΓÇÖt have Azure Active Directory, create a [free account](https://azure.microsoft.com/free/?WT.mc_id=A261C142F) before you begin.

-You need two or more test email accounts that you can send the invitations to. The accounts must be from outside your organization. You can use any type of account, including social accounts such as gmail.com or outlook.com addresses.

-Learn how to find and fix [single sign-on](what-is-single-sign-on.md) issues for applications in Azure Active Directory (Azure AD) that use SAML-based single sign-on.

-1. In the left blade, select **Azure Active Directory**, and then select **Enterprise applications**.

-1. From the list of enterprise applications, select the application for which you want to test single sign-on, and then from the options on the left select **Single sign-on**.

-1. In the **Test single sign-on** blade, use your corporate credentials to sign in to the target application. You can sign in as the current user or as a different user. If you sign in as a different user, a prompt will ask you to authenticate.

-1. When an error occurs, the extension redirects you back to the Azure AD **Test single sign-on** blade.

-1. On the **Test single sign-on** blade, select **Download the SAML request**.

-1. You'll see a **Fix it** button to automatically update the configuration in Azure AD to resolve the issue. If you don't see this button, then the sign-in issue isn't due to a misconfiguration on Azure AD.

-1. Go back to Azure AD and find the **Test single sign-on** blade.

-You might sign in successfully and then see an error on the application's page. This occurs when Azure AD issued a token to the application, but the application doesn't accept the response.

- - If the My Apps Secure Sign-in extension is installed, from the **Test single sign-on** blade, select **download the SAML response**.

-Now that single sign-on is working to your application, you could [Automate user provisioning and de-provisioning to SaaS applications](../app-provisioning/user-provisioning.md) or [get started with Conditional Access](../conditional-access/app-based-conditional-access.md).

- The public key should be stored in an X.509 certificate file in .cer format.

-1. Go to the **Azure Active Directory > Enterprise applications** blade and then select the application that you wish to configure token encryption for.

-1. Set the value for the `tokenEncryptionKeyId` attribute.

-# [PowerShell](#tab/azure-powershell)

-## March 2023

-### Updated articles

-> To learn more about Oracle Fusion ERP's SCIM endpoint, refer to [REST API for Common Features in Oracle Applications Cloud](https://docs.oracle.com/en/cloud/saas/applications-common/18b/farca/https://docsupdatetracker.net/index.html).

- "issuer": "https://token.actions.githubusercontent.com/",

-It can take more than one hour for the App Service Environment to be created.

-| &#9679; Windows Server 2022 (including Server Core) <br> &#9679; Windows Server 2019 (including Server Core) <br> &#9679; Windows Server 2016, version 1709, and 1803 (excluding Server Core) <br> &#9679; Windows Server 2012, 2012 R2 (excluding Server Core) <br> &#9679; Windows 10 Enterprise (including multi-session) and Pro | &#9679; Debian GNU/Linux 8, 9, 10, and 11 <br> &#9679; Ubuntu 18.04 LTS, 20.04 LTS, and 22.04 LTS <br> &#9679; SUSE Linux Enterprise Server 15.2, and 15.3 <br> &#9679; Red Hat Enterprise Linux Server 7, and 8ΓÇ»</br> *Hybrid Worker extension would follow support timelines of the OS vendor.|

-| &#9679; Windows Server 2022 (including Server Core) <br> &#9679; Windows Server 2019 (including Server Core) <br> &#9679; Windows Server 2016, version 1709 and 1803 (excluding Server Core) <br> &#9679; Windows Server 2012, 2012 R2 (excluding Server Core) <br> &#9679; Windows 10 Enterprise (including multi-session) and Pro| &#9679; Debian GNU/Linux 8,9,10, and 11 <br> &#9679; Ubuntu 18.04 LTS, 20.04 LTS, and 22.04 LTS <br> &#9679; SUSE Linux Enterprise Server 15.2, and 15.3 <br> &#9679; Red Hat Enterprise Linux Server 7, and 8 </br> *Hybrid Worker extension would follow support timelines of the OS vendor.ΓÇ»|

-|[Prometheus alerts](alerts-types.md#prometheus-alerts)|Prometheus alerts are used for alerting on the performance and health of Kubernetes clusters, including Azure Kubernetes Service (AKS). The alert rules are based on PromQL, which is an open-source query language.|

-description: Learn how to use the voluntary migration tool to migrate your classic alert rules.

-# Use the voluntary migration tool to migrate your classic alert rules

-As [previously announced](monitoring-classic-retirement.md), classic alerts in Azure Monitor are retired for public cloud users, though still in limited use until **31 May 2021**. Classic alerts for Azure Government cloud and Azure China 21Vianet will retire on **29 February 2024**.

-A migration tool is available in the Azure portal to customers who used classic alert rules and who want to trigger migration themselves. This article explains how to use the migration tool.

-## Before you migrate

-The migration process converts classic alert rules to new, equivalent alert rules, and creates action groups. In preparation, be aware of the following points:

- > [!NOTE]

- > The migration process won't impact the evaluation of your classic alert rules. They'll continue to run and send alerts until they're migrated and the new alert rules take effect.

-## How to use the migration tool

-To trigger the migration of your classic alert rules in the Azure portal, follow these steps:

-1. In [Azure portal](https://portal.azure.com), select **Monitor**.

-1. Select **Alerts**, and then select **Manage alert rules** or **View classic alerts**.

-1. Select **Migrate to new rules** to go to the migration landing page. This page shows a list of all your subscriptions and their migration status:

- 

- All subscriptions that can be migrated by using the tool are marked as **Ready to migrate**.

- > [!NOTE]

- > The migration tool is rolling out in phases to all the subscriptions that use classic alert rules. In the early phases of the rollout, you might see some subscriptions marked as not ready for migration.

-1. Select one or more subscriptions, and then select **Preview migration**.

- The resulting page shows the details of classic alert rules that will be migrated for one subscription at a time. You can also select **Download the migration details for this subscription** to get the details in a CSV format.

- 

-1. Specify one or more email addresses to be notified of migration status. You'll receive email when the migration is complete or if any action is needed from you.

-1. Select **Start Migration**. Read the information shown in the confirmation dialog box and confirm that you're ready to start the migration process.

- > [!IMPORTANT]

- > After you initiate migration for a subscription, you won't be able to edit or create classic alert rules for that subscription. This restriction ensures that no changes to your classic alert rules are lost during migration to the new rules. Although you won't be able to change your classic alert rules, they'll still continue to run and to provide alerts until they've been migrated. After the migration is complete for your subscription, you can't use classic alert rules anymore.

- 

-1. When migration is complete, or if action is required from you, you'll receive an email at the addresses that you provided earlier. You can also periodically check the status at the migration landing page in the portal.

-## Frequently asked questions

-### Why is my subscription listed as not ready for migration?

-The migration tool is rolling out to customers in phases. In the early phases, most or all of your subscriptions might be marked as **Not ready for migration**.

-When a subscription becomes ready for migration, the subscription owner will receive an email message stating that the tool is available. Keep an eye out for this message.

-### Who can trigger the migration?

-Users who have the Monitoring Contributor role assigned to them at the subscription level can trigger the migration. [Learn more about Azure role-based access control for the migration process](alerts-understand-migration.md#who-can-trigger-the-migration).

-### How long will the migration take?

-Migration is completed for most subscriptions in under an hour. You can keep track of the migration progress on the migration landing page. During the migration, be assured that your alerts are still running either in the classic alerts system or in the new one.

-### What can I do if I run into a problem during migration?

-See the [troubleshooting guide](alerts-understand-migration.md#common-problems-and-remedies) for help with problems you might face during migration. If any action is needed from you to complete the migration, you'll be notified at the email addresses you provided when you set up the tool.

-## Next steps

-> | backupvaults | [**Yes**](../../backup/backup-vault-overview.md#use-azure-portal-to-move-backup-vault-to-a-different-resource-group) | [**Yes**](../../backup/backup-vault-overview.md#use-azure-portal-to-move-backup-vault-to-a-different-subscription) | No |

-Before you create a Backup vault, choose the storage redundancy of the data in the vault, and then create the Backup vault with that storage redundancy and the location. Learn more about [creating a Backup vault](backup-vault-overview.md#create-a-backup-vault).

-Here, we're creating a Backup vault *TestBkpVault* in *West US* region under the resource group *testBkpVaultRG*. Use the `New-AzDataProtectionBackupVault` cmdlet to create a Backup vault. Learn more about [creating a Backup vault](backup-vault-overview.md#create-a-backup-vault).

-Learn [how to create a Backup vault](backup-vault-overview.md#create-a-backup-vault).

-Before creating a Backup vault, choose the storage redundancy of the data within the vault. Then proceed to create the Backup vault with that storage redundancy and the location. In this article, we'll create a Backup vault _TestBkpVault_, in the region _westus_, under the resource group _testBkpVaultRG_. Use the [az dataprotection vault create](/cli/azure/dataprotection/backup-vault#az-dataprotection-backup-vault-create) command to create a Backup vault. Learn more about [creating a Backup vault](./backup-vault-overview.md#create-a-backup-vault).

-Before creating a backup vault, choose the storage redundancy of the data within the vault. Then proceed to create the backup vault with that storage redundancy and the location. In this article, we will create a backup vault _TestBkpVault_ in region _westus_, under the resource group _testBkpVaultRG_. Use the [New-AzDataProtectionBackupVault](/powershell/module/az.dataprotection/new-azdataprotectionbackupvault) command to create a backup vault.Learn more about [creating a Backup vault](./backup-vault-overview.md#create-a-backup-vault).

-Before you create a Backup vault, choose the storage redundancy of the data within the vault. Then proceed to create the Backup vault with that storage redundancy and the location. In this article, we'll create a Backup vault _TestBkpVault_, in the region _westus_, under the resource group _testBkpVaultRG_. Use the [az dataprotection vault create](/cli/azure/dataprotection/backup-vault#az-dataprotection-backup-vault-create) command to create a Backup vault. Learn more about [creating a Backup vault](./backup-vault-overview.md#create-a-backup-vault).

-Before creating a backup vault, choose the storage redundancy of the data within the vault. Then proceed to create the backup vault with that storage redundancy and the location. In this article, we will create a backup vault "TestBkpVault" in "westus" region under the resource group "testBkpVaultRG". Use the [New-AzDataProtectionBackupVault](/powershell/module/az.dataprotection/new-azdataprotectionbackupvault) command to create a backup vault.Learn more about [creating a Backup vault](./backup-vault-overview.md#create-a-backup-vault).

-1. In the **Basics** tab, provide subscription, resource group, backup vault name, region, and backup storage redundancy. Continue by selecting **Review + create**. Learn more about [creating a Backup vault](./backup-vault-overview.md#create-a-backup-vault).

-In this article, we'll create a Backup vault _TestBkpVault_, in the region _westus_, under the resource group _testBkpVaultRG_. Use the [az dataprotection vault create](/cli/azure/dataprotection/backup-vault#az-dataprotection-backup-vault-create) command to create a Backup vault. Learn more about [creating a Backup vault](./backup-vault-overview.md#create-a-backup-vault).

-In this article, we'll create a Backup vault *TestBkpVault*, in *westus* region, under the resource group *testBkpVaultRG*. Use the [New-AzDataProtectionBackupVault](/powershell/module/az.dataprotection/new-azdataprotectionbackupvault) command to create a Backup vault. Learn more about [creating a Backup vault](./backup-vault-overview.md#create-a-backup-vault).

-**Cross Subscription (preview)** | You can use cross-subscription restore to restore Azure managed VMs in different subscriptions.<br><br> You can restore Azure VMs or disks to any subscription from restore points. This is one of the Azure role-based access control (RBAC) capabilities. <br><br> This feature is available for the following options:<br> - [Create a VM](./backup-azure-arm-restore-vms.md#create-a-vm) <br> - [Restore disks](./backup-azure-arm-restore-vms.md#restore-disks) <br><br> Cross-subscription restore is unsupported for [snapshots](backup-azure-vms-introduction.md#snapshot-creation) and [secondary region](backup-azure-arm-restore-vms.md#restore-in-secondary-region) restores. It's also unsupported for [unmanaged VMs](backup-azure-arm-restore-vms.md#restoring-unmanaged-vms-and-disks-as-managed), [encrypted Azure VMs](backup-azure-vms-introduction.md#encryption-of-azure-vm-backups), and [trusted launch VMs](backup-support-matrix-iaas.md#tvm-backup).

-## Create a Backup vault

-A Backup vault is a management entity that stores recovery points created over time and provides an interface to perform backup related operations. These include taking on-demand backups, performing restores, and creating backup policies.

-To create a Backup vault, follow these steps.

-### Sign in to Azure

-Sign in to the [Azure portal](https://portal.azure.com).

-### Create Backup vault

-1. Type **Backup vaults** in the search box.

-2. Under **Services**, select **Backup vaults**.

-3. On the **Backup vaults** page, select **Add**.

-4. On the **Basics** tab, under **Project details**, make sure the correct subscription is selected and then choose **Create new** resource group. Type *myResourceGroup* for the name.

- 

-5. Under **Instance details**, type *myVault* for the **Backup vault name** and choose your region of choice, in this case *East US* for your **Region**.

-6. Now choose your **Storage redundancy**. Storage redundancy cannot be changed after protecting items to the vault.

-7. We recommend that if you're using Azure as a primary backup storage endpoint, continue to use the default **Geo-redundant** setting.

-8. If you don't use Azure as a primary backup storage endpoint, choose **Locally redundant**, which reduces the Azure storage costs. Learn more about [geo](../storage/common/storage-redundancy.md#geo-redundant-storage) and [local](../storage/common/storage-redundancy.md#locally-redundant-storage) redundancy.

- 

-9. Select the Review + create button at the bottom of the page.

- 

-## Delete a Backup vault

-This section describes how to delete a Backup vault. It contains instructions for removing dependencies and then deleting a vault.

-### Before you start

-You can't delete a Backup vault with any of the following dependencies:

-If you try to delete the vault without removing the dependencies, you'll encounter the following error messages:

->Cannot delete the Backup vault as there are existing backup instances or backup policies in the vault. Delete all backup instances and backup policies that are present in the vault and then try deleting the vault.

-Ensure that you cycle through the **Datasource type** filter options in **Backup center** to not miss any existing Backup Instance or policy that needs to be removed, before being able to delete the Backup Vault.

-

-### Proper way to delete a vault

->[!WARNING]

->The following operation is destructive and can't be undone. All backup data and backup items associated with the protected server will be permanently deleted. Proceed with caution.

-To properly delete a vault, you must follow the steps in this order:

- - Go to **Backup Instances** in the left navigation bar. All items listed here must be deleted first.

-After you've completed these steps, you can continue to delete the vault.

-### Delete the Backup vault

-When there are no more items in the vault, select **Delete** on the vault dashboard. You'll see a confirmation text asking if you want to delete the vault.

-

-1. Select **Yes** to verify that you want to delete the vault. The vault is deleted. The portal returns to the **New** service menu.

-## Monitor and manage the Backup vault

-This section explains how to use the Backup vault **Overview** dashboard to monitor and manage your Backup vaults. The overview pane contains two tiles: **Jobs** and **Instances**.

-

-### Manage Backup instances

-In the **Jobs** tile, you get a summarized view of all backup and restore related jobs in your Backup vault. Selecting any of the numbers in this tile allows you to view more information on jobs for a particular datasource type, operation type, and status.

-

-### Manage Backup jobs

-In the **Backup Instances** tile, you get a summarized view of all backup instances in your Backup vault. Selecting any of the numbers in this tile allows you to view more information on backup instances for a particular datasource type and protection status.

-

-## Move a Backup vault across Azure subscriptions/resource groups

-This section explains how to move a Backup vault (configured for Azure Backup) across Azure subscriptions and resource groups using the Azure portal.

->[!Note]

->You can also move Backup vaults to a different resource group or subscription using [PowerShell](/powershell/module/az.resources/move-azresource) and [CLI](/cli/azure/resource#az-resource-move).

-### Supported regions

-The vault move across subscriptions and resource groups is supported in all public and national regions.

-### Use Azure portal to move Backup vault to a different resource group

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

-1. Open the list of Backup vaults and select the vault you want to move.

- The vault dashboard displays the vault details.

- :::image type="content" source="./media/backup-vault-overview/vault-dashboard-to-move-to-resource-group-inline.png" alt-text="Screenshot showing the dashboard of the vault to be moved to another resource group." lightbox="./media/backup-vault-overview/vault-dashboard-to-move-to-resource-group-expanded.png":::

-1. In the vault **Overview** menu, click **Move**, and then select **Move to another resource group**.

- :::image type="content" source="./media/backup-vault-overview/select-move-to-another-resource-group-inline.png" alt-text="Screenshot showing the option for moving the Backup vault to another resource group." lightbox="./media/backup-vault-overview/select-move-to-another-resource-group-expanded.png":::

- >[!Note]

- >Only the admin subscription has the required permissions to move a vault.

-1. In the **Resource group** drop-down list, select an existing resource group or select **Create new** to create a new resource group.

- The subscription remains the same and gets auto-populated.

- :::image type="content" source="./media/backup-vault-overview/select-existing-or-create-resource-group-inline.png" alt-text="Screenshot showing the selection of an existing resource group or creation of a new resource group." lightbox="./media/backup-vault-overview/select-existing-or-create-resource-group-expanded.png":::

-1. On the **Resources to move** tab, the Backup vault that needs to be moved will undergo validation. This process may take a few minutes. Wait till the validation is complete.

- :::image type="content" source="./media/backup-vault-overview/move-validation-process-to-move-to-resource-group-inline.png" alt-text="Screenshot showing the Backup vault validation status." lightbox="./media/backup-vault-overview/move-validation-process-to-move-to-resource-group-expanded.png":::

-1. Select the checkbox **I understand that tools and scripts associated with moved resources will not work until I update them to use new resource IDs** to confirm, and then select **Move**.

-

- >[!Note]

- >The resource path changes after moving vault across resource groups or subscriptions. Ensure that you update the tools and scripts with the new resource path after the move operation completes.

-Wait till the move operation is complete to perform any other operations on the vault. Any operations performed on the Backup vault will fail if performed while move is in progress. When the process is complete, the Backup vault should appear in the target resource group.

->[!Important]

->If you encounter any error while moving the vault, refer to the [Error codes and troubleshooting section](#error-codes-and-troubleshooting).

-### Use Azure portal to move Backup vault to a different subscription

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

-1. Open the list of Backup vaults and select the vault you want to move.

-

- The vault dashboard displays the vault details.

- :::image type="content" source="./media/backup-vault-overview/vault-dashboard-to-move-to-another-subscription-inline.png" alt-text="Screenshot showing the dashboard of the vault to be moved to another Azure subscription." lightbox="./media/backup-vault-overview/vault-dashboard-to-move-to-another-subscription-expanded.png":::

-1. In the vault **Overview** menu, click **Move**, and then select **Move to another subscription**.

- :::image type="content" source="./media/backup-vault-overview/select-move-to-another-subscription-inline.png" alt-text="Screenshot showing the option for moving the Backup vault to another Azure subscription." lightbox="./media/backup-vault-overview/select-move-to-another-subscription-expanded.png":::

- >[!Note]

- >Only the admin subscription has the required permissions to move a vault.

-1. In the **Subscription** drop-down list, select an existing subscription.

- For moving vaults across subscriptions, the target subscription must reside in the same tenant as the source subscription. To move a vault to a different tenant, see [Transfer subscription to a different directory](../role-based-access-control/transfer-subscription.md).

-1. In the **Resource group** drop-down list, select an existing resource group or select **Create new** to create a new resource group.

- :::image type="content" source="./media/backup-vault-overview/select-existing-or-create-resource-group-to-move-to-other-subscription-inline.png" alt-text="Screenshot showing the selection of an existing resource group or creation of a new resource group in another Azure subscription." lightbox="./media/backup-vault-overview/select-existing-or-create-resource-group-to-move-to-other-subscription-expanded.png":::

-1. On the **Resources to move** tab, the Backup vault that needs to be moved will undergo validation. This process may take a few minutes. Wait till the validation is complete.

- :::image type="content" source="./media/backup-vault-overview/move-validation-process-to-move-to-another-subscription-inline.png" alt-text="Screenshot showing the validation status of Backup vault to be moved to another Azure subscription." lightbox="./media/backup-vault-overview/move-validation-process-to-move-to-another-subscription-expanded.png":::

-1. Select the checkbox **I understand that tools and scripts associated with moved resources will not work until I update them to use new resource IDs** to confirm, and then select **Move**.

-

- >[!Note]

- >The resource path changes after moving vault across resource groups or subscriptions. Ensure that you update the tools and scripts with the new resource path after the move operation completes.

-Wait till the move operation is complete to perform any other operations on the vault. Any operations performed on the Backup vault will fail if performed while move is in progress. When the process completes, the Backup vault should appear in the target Subscription and Resource group.

->[!Important]

->If you encounter any error while moving the vault, refer to the [Error codes and troubleshooting section](#error-codes-and-troubleshooting).

-### Error codes and troubleshooting

-Troubleshoot the following common issues you might encounter during Backup vault move:

-#### BackupVaultMoveResourcesPartiallySucceeded

-**Cause**: You may face this error when Backup vault move succeeds only partially.

-**Recommendation**: The issue should get resolved automatically within 36 hours. If it persists, contact Microsoft Support.

-#### BackupVaultMoveResourcesCriticalFailure

-**Cause**: You may face this error when Backup vault move fails critically.

-**Recommendation**: The issue should get resolved automatically within 36 hours. If it persists, contact Microsoft Support.

-#### UserErrorBackupVaultResourceMoveInProgress

-**Cause**: You may face this error if you try to perform any operations on the Backup vault while itΓÇÖs being moved.

-**Recommendation**: Wait till the move operation is complete, and then retry.

-#### UserErrorBackupVaultResourceMoveNotAllowedForMultipleResources

-**Cause**: You may face this error if you try to move multiple Backup vaults in a single attempt.

-**Recommentation**: Ensure that only one Backup vault is selected for every move operation.

-#### UserErrorBackupVaultResourceMoveNotAllowedUntilResourceProvisioned

-**Cause**: You may face this error if the vault is not yet provisioned.

-**Recommendation**: Retry the operation after some time.

-#### BackupVaultResourceMoveIsNotEnabled

-**Cause**: Resource move for Backup vault is currently not supported in the selected Azure region.

-**Recommendation**: Ensure that you've selected one of the supported regions to move Backup vaults. See [Supported regions](#supported-regions).

-#### UserErrorCrossTenantMSIMoveNotSupported

-**Cause**: This error occurs if the subscription with which resource is associated has moved to a different Tenant, but the Managed Identity is still associated with the old Tenant.

-**Recommendation**: Remove the Managed Identity from the existing Tenant; move the resource and add it again to the new one.

-### Perform Cross Region Restore using Azure portal

-Follow these steps:

-1. Sign in to [Azure portal](https://portal.azure.com/).

-1. [Create a new Backup vault](backup-vault-overview.md#create-backup-vault) or choose an existing Backup vault, and then enable Cross Region Restore by going to **Properties** > **Cross Region Restore (Preview)**, and choose **Enable**.

- :::image type="content" source="./media/backup-vault-overview/enable-cross-region-restore-for-postgresql-database.png" alt-text="Screenshot shows how to enable Cross Region Restore for PostgreSQL database." lightbox="./media/backup-vault-overview/enable-cross-region-restore-for-postgresql-database.png":::

-1. Go to the Backup vaultΓÇÖs **Overview** pane, and then [configure a backup for PostgreSQL database](backup-azure-database-postgresql.md).

-1. Once the backup is complete in the primary region, it can take up to *12 hours* for the recovery point in the primary region to get replicated to the secondary region.

- To check the availability of recovery point in the secondary region, go to the **Backup center** > **Backup Instances** > **Filter to Azure Database for PostgreSQL servers**, filter **Instance Region** as *Secondary Region*, and then select the required Backup Instance.

- :::image type="content" source="./media/backup-vault-overview/check-availability-of-recovery-point-in-secondary-region.png" alt-text="Screenshot shows how to check availability for the recovery points in the secondary region." lightbox="./media/backup-vault-overview/check-availability-of-recovery-point-in-secondary-region.png":::

-1. The recovery points available in the secondary region are now listed.

- Choose **Restore to secondary region**.

- :::image type="content" source="./media/backup-vault-overview/initiate-restore-to-secondary-region.png" alt-text="Screenshot shows how to initiate restores to the secondary region." lightbox="./media/backup-vault-overview/initiate-restore-to-secondary-region.png":::

- You can also trigger restores from the respective backup instance.

- :::image type="content" source="./media/backup-vault-overview/trigger-restores-from-respective-backup-instance.png" alt-text="Screenshot shows how to trigger restores from the respective backup instance." lightbox="./media/backup-vault-overview/trigger-restores-from-respective-backup-instance.png":::

-1. Select **Restore to secondary region** to review the target region selected, and then select the appropriate recovery point and restore parameters.

-1. Once the restore starts, you can monitor the completion of the restore operation under **Backup Jobs** of the Backup vault by filtering **Jobs workload type** to *Azure Database for PostgreSQL servers* and **Instance Region** to *Secondary Region*.

- :::image type="content" source="./media/backup-vault-overview/monitor-postgresql-restore-to-secondary-region.png" alt-text="Screenshot shows how to monitor the postgresql restore to the secondary region." lightbox="./media/backup-vault-overview/monitor-postgresql-restore-to-secondary-region.png":::

-For instructions on how to create a Backup vault, see the [Backup vault documentation](backup-vault-overview.md#create-a-backup-vault).

- Continue by selecting **Review + create**. Learn more about [creating a Backup vault](./backup-vault-overview.md#create-a-backup-vault).

-For more information see [What's new in MABS](backup-mabs-whats-new-mabs.md).

-The face ID is a unique identifier string for each detected face in an image. Note that Face ID requires limited access approval, which you can apply for by filling out the [intake form](https://aka.ms/facerecognition). For more information, see the Face [limited access page](/legal/cognitive-services/computer-vision/limited-access-identity?context=%2Fazure%2Fcognitive-services%2Fcomputer-vision%2Fcontext%2Fcontext). You can request a face ID in your [Face - Detect](https://westus.dev.cognitive.microsoft.com/docs/services/563879b61984550e40cbbe8d/operations/563879b61984550f30395236) API call.

-* **Accessories**. Whether the given face has accessories. This attribute returns possible accessories including headwear, glasses, and mask, with confidence score between zero and one for each accessory.

- For more details on how to use these values, see the [Head pose how-to guide](./how-to/use-headpose.md).

-* **Makeup**. Whether the face has makeup. This attribute returns a Boolean value for eyeMakeup and lipMakeup.

-* **Mask**. Whether the face is wearing a mask. This attribute returns a possible mask type, and a Boolean value to indicate whether nose and mouth are covered.

-* **Occlusion**. Whether there are objects blocking parts of the face. This attribute returns a Boolean value for eyeOccluded, foreheadOccluded, and mouthOccluded.

-* The minimum detectable face size is 36 x 36 pixels in an image that is no larger than 1920 x 1080 pixels. Images with larger than 1920 x 1080 pixels have a proportionally larger minimum face size. Reducing the face size might cause some faces not to be detected, even if they are larger than the minimum detectable face size.

-Some input images with JPEG format might contain orientation information in Exchangeable image file format (Exif) metadata. If Exif orientation is available, images will be automatically rotated to the correct orientation before sending for face detection. The face rectangle, landmarks, and head pose for each detected face will be estimated based on the rotated image.

-To properly display the face rectangle and landmarks, you need to make sure the image is rotated correctly. Most of image visualization tools will auto-rotate the image according to its Exif orientation by default. For other tools, you might need to apply the rotation using your own code. The following examples show a face rectangle on a rotated image (left) and a non-rotated image (right).

-* **Shutter Angle**: Some cameras specify shutter angle instead of shutter speed. You should use a lower shutter angle if possible. This will result in clearer video frames.

-OCR traditionally started as a machine-learning based technique for extracting text from in-the-wild and non-document images like product labels, user generated images, screenshots, street signs, and posters. For several scenarios that including running OCR on single images that are not text-heavy, you need a fast, synchronous API or service. This allows OCR to be embedded in near real-time user experiences to enrich content understanding and follow-up user actions with fast turn-around times.

-## What is Computer Vision v4.0 Read OCR (preview)

-You can analyze images to provide insights about their visual features and characteristics. All of the features in the list below are provided by the Analyze Image API. Follow a [quickstart](./quickstarts-sdk/image-analysis-client-library-40.md) to get started.

-|**Model customization** (v4.0 preview only)|You can create and train custom models to do image classification or object detection. Bring your own images, label them with custom tags, and Image Analysis will train a model customized for your use case.|[Model customization](./concept-model-customization.md)|

-|**Generate image captions** | Generate a caption of an image in human-readable language, using complete sentences. Computer Vision's algorithms generate captions based on the objects identified in the image. <br/><br/>The version 4.0 image captioning model is a more advanced implementation and works with a wider range of input images. It is only available in the following geographic regions: East US, France Central, Korea Central, North Europe, Southeast Asia, West Europe, West US. <br/><br/>Version 4.0 also lets you use dense captioning, which generates detailed captions for individual objects that are found in the image. The API returns the bounding box coordinates (in pixels) of each object found in the image, plus a caption. You can use this functionality to generate descriptions of separate parts of an image.<br/><br/>:::image type="content" source="Images/description.png" alt-text="Photo of cows with a simple description on the right.":::| [Generate image captions (v3.2)](concept-describing-images.md)<br/>[(v4.0 preview)](concept-describe-images-40.md)|

-|**Detect objects** |Object detection is similar to tagging, but the API returns the bounding box coordinates for each tag applied. For example, if an image contains a dog, cat and person, the Detect operation will list those objects together with their coordinates in the image. You can use this functionality to process further relationships between the objects in an image. It also lets you know when there are multiple instances of the same tag in an image. <br/><br/>:::image type="content" source="Images/detect-objects.png" alt-text="Photo of an office with a rectangle drawn around a laptop.":::| [Detect objects (v3.2)](concept-object-detection.md)<br/>[(v4.0 preview)](concept-object-detection-40.md)

-|**Get the area of interest / smart crop** |Analyze the contents of an image to return the coordinates of the *area of interest* that matches a specified aspect ratio. Computer Vision returns the bounding box coordinates of the region, so the calling application can modify the original image as desired. <br/><br/>The version 4.0 smart cropping model is a more advanced implementation and works with a wider range of input images. It is only available in the following geographic regions: East US, France Central, Korea Central, North Europe, Southeast Asia, West Europe, West US. | [Generate a thumbnail (v3.2)](concept-generating-thumbnails.md)<br/>[(v4.0 preview)](concept-generate-thumbnails-40.md)|

-OCR or Optical Character Recognition is also referred to as text recognition or text extraction. Machine-learning based OCR techniques allow you to extract printed or handwritten text from images, such as posters, street signs and product labels, as well as from documents like articles, reports, forms, and invoices. The text is typically extracted as words, text lines, and paragraphs or text blocks, enabling access to digital version of the scanned text. This eliminates or significantly reduces the need for manual data entry.

-Intelligent Document Processing (IDP) uses OCR as its foundational technology to additionally extract structure, relationships, key-values, entities, and other document-centric insights with an advanced machine-learning based AI service like [Form Recognizer](../../applied-ai-services/form-recognizer/overview.md). Form Recognizer includes a document-optimized version of **Read** as its OCR engine while delegating to other models for higher-end insights. If you are extracting text from scanned and digital documents, use [Form Recognizer Read OCR](../../applied-ai-services/form-recognizer/concept-read.md).

-Microsoft's **Read** OCR engine is composed of multiple advanced machine-learning based models supporting [global languages](./language-support.md). This allows them to extract printed and handwritten text including mixed languages and writing styles. **Read** is available as cloud service and on-premises container for deployment flexibility. With the latest preview, it's also available as a synchronous API for single, non-document, image-only scenarios with performance enhancements that make it easier to implement OCR-assisted user experiences.

-Both **Read** versions available today in Computer Vision support several languages for printed and handwritten text. OCR for printed text includes support for English, French, German, Italian, Portuguese, Spanish, Chinese, Japanese, Korean, Russian, Arabic, Hindi, and other international languages that use Latin, Cyrillic, Arabic, and Devanagari scripts. OCR for handwritten text includes support for English, Chinese Simplified, French, German, Italian, Japanese, Korean, Portuguese, and Spanish languages.

-| [Optical Character Recognition (OCR)](overview-ocr.md)|The Optical Character Recognition (OCR) service extracts text from images. You can use the new Read API to extract printed and handwritten text from photos and documents. It uses deep-learning-based models and works with text on a variety of surfaces and backgrounds. These include business documents, invoices, receipts, posters, business cards, letters, and whiteboards. The OCR APIs support extracting printed text in [several languages](./language-support.md). Follow the [OCR quickstart](quickstarts-sdk/client-library.md) to get started.|

- - For the Read API, the dimensions of the image must be between 50 x 50 and 10000 x 10000 pixels.

-description: In this tutorial, you will step through a sample app that uses Custom Vision as part of a logo detection scenario. Learn how Custom Vision is used with other components to deliver an end-to-end application.

-In this tutorial, you'll explore a sample app that uses Custom Vision as part of a larger scenario. The AI Visual Provision app, a Xamarin.Forms app for mobile platforms, analyzes camera pictures of Azure service logos and then deploys the actual services to the user's Azure account. Here you'll learn how it uses Custom Vision in coordination with other components to deliver a useful end-to-end application. You can run the whole app scenario for yourself, or you can complete only the Custom Vision part of the setup and explore how the app uses it.

-This tutorial will show you how to:

-If you want to use the provided web app, clone or download the app's source code from the [AI Visual Provision](https://github.com/Microsoft/AIVisualProvision) repository on GitHub. Open the *Source/VisualProvision.sln* file in Visual Studio. Later on, you'll edit some of the project files so you can run the app.

-Sign in to the [Custom Vision website](https://customvision.ai/) and create a new project. Specify an Object Detection project and use the Logo domain; this will let the service use an algorithm optimized for logo detection.

-## Add Computer Vision

-The Custom Vision service is optimized to quickly recognize major differences between images, so you can start prototyping your model with a small amount of data. 50 images per label are generally a good start. However, the service is not optimal for detecting subtle differences in images (for example, detecting minor cracks or dents in quality assurance scenarios).

-Additionally, you can choose from several variations of the Custom Vision algorithm that are optimized for images with certain subject material&mdash;for example, landmarks or retail items. See [Select a domain](select-domain.md) for more information.

-The Custom Vision Service is available as a set of native SDKs as well as through a web-based interface on the [Custom Vision portal](https://customvision.ai/). You can create, test, and train a model through either interface or use both together.

-As a part of Azure, Custom Vision Service has components that are maintained across multiple regions. Service zones and regions are used by all of our services to provide continued service to our customers. For more information on zones and regions, see [Azure regions](../../availability-zones/az-overview.md). If you need additional information or have any issues, please [contact support](/answers/topics/azure-custom-vision.html).

-| [Speech to text](speech-container-stt.md) | Transcribes continuous real-time speech or batch audio recordings with intermediate results. | Latest: 3.14.0<br/><br/>For all supported versions and locales, see the [Microsoft Container Registry (MCR)](https://mcr.microsoft.com/product/azure-cognitive-services/speechservices/speech-to-text/tags) and [JSON tags](https://mcr.microsoft.com/v2/azure-cognitive-services/speechservices/speech-to-text/tags/list).|

-| [Custom speech to text](speech-container-cstt.md) | Using a custom model from the [Custom Speech portal](https://speech.microsoft.com/customspeech), transcribes continuous real-time speech or batch audio recordings into text with intermediate results. | Latest: 3.14.0<br/><br/>For all supported versions and locales, see the [Microsoft Container Registry (MCR)](https://mcr.microsoft.com/product/azure-cognitive-services/speechservices/custom-speech-to-text/tags) and [JSON tags](https://mcr.microsoft.com/v2/azure-cognitive-services/speechservices/speech-to-text/tags/list). |

-| [Neural text to speech](speech-container-ntts.md) | Converts text to natural-sounding speech by using deep neural network technology, which allows for more natural synthesized speech. | Latest: 2.13.0<br/><br/>For all supported versions and locales, see the [Microsoft Container Registry (MCR)](https://mcr.microsoft.com/product/azure-cognitive-services/speechservices/neural-text-to-speech/tags) and [JSON tags](https://mcr.microsoft.com/v2/azure-cognitive-services/speechservices/neural-text-to-speech/tags/list). |

-If you're using [ExpressRoute](../expressroute/expressroute-introduction.md) on-premises for public peering or Microsoft peering, you'll need to identify the NAT IP addresses. For public peering, each ExpressRoute circuit by default uses two NAT IP addresses. Each is applied to Azure service traffic when the traffic enters the Microsoft Azure network backbone. For Microsoft peering, the NAT IP addresses that are used are either customer provided or are provided by the service provider. To allow access to your service resources, you must allow these public IP addresses in the resource IP firewall setting. To find your public peering ExpressRoute circuit IP addresses, [open a support ticket with ExpressRoute](https://portal.azure.com/#blade/Microsoft_Azure_Support/HelpAndSupportBlade/overview) via the Azure portal. Learn more about [NAT for ExpressRoute public and Microsoft peering.](../expressroute/expressroute-nat.md#nat-requirements-for-azure-public-peering)

-We create a [private DNS zone](../dns/private-dns-overview.md) attached to the VNet with the necessary updates for the private endpoints, by default. However, if you're using your own DNS server, you may need to make additional changes to your DNS configuration. The section on [DNS changes](#dns-changes-for-private-endpoints) below describes the updates required for private endpoints.

-When you create a private endpoint, the DNS CNAME resource record for the Cognitive Services resource is updated to an alias in a subdomain with the prefix '*privatelink*'. By default, we also create a [private DNS zone](../dns/private-dns-overview.md), corresponding to the '*privatelink*' subdomain, with the DNS A resource records for the private endpoints.

-If you are using a custom DNS server on your network, clients must be able to resolve the fully qualified domain name (FQDN) for the Cognitive Services resource endpoint to the private endpoint IP address. Configure your DNS server to delegate your private link subdomain to the private DNS zone for the VNet.

-For more information on configuring your own DNS server to support private endpoints, refer to the following articles:

-Azure Content Safety automatically encrypts your data when it's persisted to the cloud. The encryption protects your data and helps you meet your organizational security and compliance commitments. This article covers how Azure Content Safety handles encryption of data at rest.

-> [!IMPORTANT]

-> For blocklist name, only MMK encryption is applied by default. Using CMK or not will not change this behavior. All the other data will use either MMK or CMK depending on what you've selected.

-## From the community

-See examples and get inspired by what's being done in the community of Azure Communication Services users.

-### Extend Azure Communication Services with Power Platform Connectors

-Listen to Azure Communication Services PMs Tomas Chladek and David de Matheu talk about how to connect your Azure Communication Services app to Microsoft Teams, and extend it with the Microsoft Power Platform.

-[Watch the video](https://www.youtube.com/watch?v=-TPI293h0mY&t=3s&pp=ygUcYXp1cmUgY29tbXVuaWNhdGlvbiBzZXJ2aWNlcw%3D%3D)

-[Read the Power Pages documentation](https://learn.microsoft.com/power-pages/configure/component-framework)

-[Read the tutorial on integrating with Teams](https://aka.ms/mscloud-acs-teams-tutorial)

-### Integrate Azure Communication Services calling into a React App

-Learn how to create an app using Azure Communication services front-end components in React.

-[Watch the video](https://www.youtube.com/watch?v=ZyBNYblzISs&pp=ygUcYXp1cmUgY29tbXVuaWNhdGlvbiBzZXJ2aWNlcw%3D%3D)

-[View the Microsoft Cloud Integrations repo](https://github.com/microsoft/microsoftcloud)

-[Read the tutorial on integrating with Teams](https://aka.ms/mscloud-acs-teams-tutorial)

-[Read more about the UI Library](https://aka.ms/acs-ui-library)

-### Dynamically create an Azure Communication Services identity and token

-Learn how an external developer can get a token that allows your app to join a teams meeting through Azure Communication Services.

-[Watch the video](https://www.youtube.com/watch?v=OgE72PGq6TM&pp=ygUcYXp1cmUgY29tbXVuaWNhdGlvbiBzZXJ2aWNlcw%3D%3D)

-[Read more about Microsoft Cloud Integrations](https://aka.ms/microsoft-cloud)

-[View the Microsoft Cloud Integrations repo](https://github.com/microsoft/microsoftcloud)

-[Read the tutorial on integrating with Teams](https://aka.ms/mscloud-acs-teams-tutorial)

-[Read more about the UI Library](https://aka.ms/acs-ui-library)

-[Read the documentation on Azure Functions](https://aka.ms/msazure--functions)

-[View the Graph Explorer](https://aka.ms/ge)

-### Deploy an Azure Communication Services app to Azure

-Learn how to quickly and easily deploy your Azure Communication Services app to Azure.

-[Watch the video](https://www.youtube.com/watch?v=JYs5CPyu2Io&pp=ygUcYXp1cmUgY29tbXVuaWNhdGlvbiBzZXJ2aWNlcw%3D%3D)

-[Read more about Microsoft Cloud Integrations](https://aka.ms/microsoft-cloud)

-[View the Microsoft Cloud Integrations repo](https://github.com/microsoft/microsoftcloud)

-[Read the tutorial on integrating with Teams](https://aka.ms/mscloud-acs-teams-tutorial)

-[Read more about the UI Library](https://aka.ms/acs-ui-library)

-[Read the documentation on Azure Functions](https://aka.ms/msazure--functions)

-[View the Graph Explorer](https://aka.ms/ge)

-<br>

-<br>

-<br>

-## New features

-Get detailed information on the latest Azure Communication Services feature launches.

-### Email service now generally available

-Azure Communication Services announces the general availability of our Email service. Email is powered by Exchange Online and meets the security and privacy requirements of enterprises.

-[Read about ACS Email](https://techcommunity.microsoft.com/t5/azure-communication-services/simpler-faster-azure-communication-services-email-now-generally/ba-p/3788541)

-### View of April's new features

-In April, we launched a host of new features, including:

-* Troubleshooting capability in UI library for native

-* Toll-free verification

-* SMS insights dashboard

-* and others...

-[View the complete list](https://techcommunity.microsoft.com/t5/azure-communication-services/azure-communication-services-april-2023-feature-updates/ba-p/3786509) of all new features added to Azure Communication Services in April.

-<br>

-## Blog posts and case studies

-Go deeper on common scenarios and learn more about how customers are using advanced Azure Communication

-Services features.

-### ABN AMRO case study

-ABN AMRO used Azure Communication Services to make it easier for customers to get financial advice from anywhere. And they boosted their NPS in the process!

-[Read the full story](https://customers.microsoft.com/story/1607768338625418317-abnamro-bankingandcapitalmarkets-microsofteams)

-### Get insights from customer interactions with Azure Communication Services and OpenAI

-Use the gold mine of customer conversations to automatically generate customer insights and create better customer experiences.

-[Read the full blog post](https://techcommunity.microsoft.com/t5/azure-communication-services/get-insights-from-customer-interactions-with-azure-communication/ba-p/3783858)

-[Read about the Azure OpenAI service](https://azure.microsoft.com/products/cognitive-services/openai-service/)

-### Latest updates to the UI library

-Get up-to-date on the latest additions to the Azure Communication Services UI library. UI library makes it easier to create custom applications with only a few lines of code.

-[Read the full blog post](https://techcommunity.microsoft.com/t5/azure-communication-services/build-communication-apps-for-microsoft-teams-users-with-azure/ba-p/3775688)

-[View the UI Library documentation](https://azure.github.io/communication-ui-library/)

-Enjoy all of these new features. Be sure to check back here periodically for more news and updates on all of the new capabilities we've added to our platform! For a complete list of new features and bug fixes, visit our [releases page](https://github.com/Azure/Communication/releases) on GitHub.

-## 6. Register your deployment's domain name in Active Directory

-Azure Cosmos DB distributes your data across logical and physical partitions based on your partition key to enable horizontal scaling. With hierarchical partition keys, or subpartitoning, you can now configure up to a three level hierarchy for your partition keys to further optimize data distribution and enable higher scale.

-If you use synthetic keys today or have scenarios where partition keys can exceed 20 GB of data, subpartitioning can help. With this feature, logical partition key prefixes can exceed 20 GB and 10,000 RU/s, and queries by prefix are efficiently routed to the subset of partitions with the data.

-## Guidance on choosing hierarchical partition keys

-Hierarchical partition keys are highly recommended to users that may have multi-tenant applications. This recommendation exists because hierarchical partitions allow users to scale beyond the logical partition key limit of 20 GB. If your current partition key or a single partition key is frequently hitting 20 GB, hierarchical partitions are a great choice for your workload. When choosing your hierarchical partition keys, it's important to keep the following general partitioning concepts in mind depending on your workload:

-For all containers, **each level** of the full path (starting with the very **first level**) of your hierarchical partition key should:

-For large read-heavy workloads, we recommend choosing hierarchical partition keys that appear frequently in your queries. For example, a workload that frequently runs queries to filter out specific user sessions in a multi-tenant application can benefit from hierarchical partition keys of TenantId, UserId, and SessionId in that order. Queries can be efficiently routed to only the relevant physical partitions by including the partition key in the filter predicate. For more information on partition keys for read-heavy workloads, see the [partitioning overview](partitioning-overview.md).

-Suppose you have a multi-tenant scenario where you store event information for users in each tenant. This event information could include event occurrences including, but not limited to, as sign-in, clickstream, or payment events.

-In a real world scenario, some tenants can grow large with thousands of users, while the many other tenants are smaller with a few users. Partitioning by **/TenantId** may lead to exceeding Azure Cosmos DB's 20-GB storage limit on a single logical partition, while partitioning by **/UserId** makes all queries on a tenant cross-partition. Both approaches have significant downsides.

-Using a synthetic partition key that combines **TenantId** and **UserId** adds complexity to the application. Additionally, the synthetic partition key queries for a tenant are still cross-partition, unless all users are known and specified in advance.

-With hierarchical partition keys, we can partition first on **TenantId**, and then **UserId**. If you expect the **TenantId** and **UserId** combination to produce partitions that exceed 20 GB, you can even partition further down to another level, such as **SessionId**. The overall depth can't exceed three levels. When a physical partition exceeds 50 GB of storage, Azure Cosmos DB automatically splits the physical partition so that roughly half of the data is on one physical partition, and half on the other. Effectively, subpartitioning means that a single TenantId can exceed 20 GB of data, and it's possible for a TenantId's data to span multiple physical partitions.

-Queries that specify either the **TenantId**, or both **TenantId** and **UserId** is efficiently routed to only the subset of physical partitions that contain the relevant data. Specifying the full or prefix subpartitioned partition key path effectively avoids a full fan-out query. For example, if the container had 1000 physical partitions, but a particular **TenantId** was only on five of them, the query would only be routed to the smaller number of relevant physical partitions.

-If your container has a property that has a large range of possible values, it's likely a great partition key choice for the last level of your hierarchy. One possible example of this type of property is the **item ID**. The system property item ID exists in every item in your container. Adding item ID as another level guarantees that you can scale beyond the logical partition key limit of 20 GB. You can scale beyond this limit for the first or first and second level of keys.

-For example, suppose we have a container for a multi-tenant workload partitioned by `TenantId` and `UserId`. If it's possible for a single combination of `TenantId` and `UserId` to exceed 20 GB, then partitioning with three levels of keys, where the third level key has high cardinality is recommended. An example of this scenario is if the third level key is a GUID with naturally high cardinality. It's unlikely that the combination of TenantId, UserId, and a GUID exceeds 20 GB, so the combination of TenantId and UserId can effectively scale beyond 20 GB.

-For more information on choosing item ID as a partition key, visit our [partitioning documentation.](partitioning-overview.md).

-## Getting started

-> Working with containers that use hierarchical partition keys is supported only in following SDK versions. You must use a supported SDK to create new containers with hierarchical partition keys and to perform CRUD/query operations on the data.

-> If you would like to use an SDK or connector that isn't currently supported, please file a request on our [community forum](https://feedback.azure.com/d365community/forum/3002b3be-0d25-ec11-b6e6-000d3a4f0858).

-| **.NET SDK v3** | *>= 3.33.0* | <https://www.nuget.org/packages/Microsoft.Azure.Cosmos/3.33.0/> |

-| **Java SDK v4** | *>= 4.42.0* | <https://github.com/Azure/azure-sdk-for-jav#4420-2023-03-17/> |

-| **JavaScript SDK v3** | *3.17.4-beta.1* | <https://www.npmjs.com/package/@azure/cosmos/v/3.17.4-beta.1/> |

-## Create a container with hierarchical partition keys

-To get started, create a new container using a predefined list of subpartitioning key paths up to three levels of depth.

-### Using the portal

-The simplest way to create a container and specify hierarchical partition keys is with the Azure portal.

-1. Navigate to the existing Azure Cosmos DB for NoSQL account page.

-1. From the Azure Cosmos DB for NoSQL account page, select the **Data Explorer** navigation menu option.

- :::image type="content" source="media/hierarchical-partition-keys/data-explorer-menu-option.png" lightbox="media/hierarchical-partition-keys/data-explorer-menu-option.png" alt-text="Screenshot of the page for a new Azure Cosmos DB for NoSQL account with the Data Explorer option highlighted.":::

-1. In the **Data Explorer**, select the **New Container** option.

- :::image type="content" source="media/hierarchical-partition-keys/new-container-option.png" lightbox="media/hierarchical-partition-keys/new-container-option.png" alt-text="Screenshot of the New Container option within the Data Explorer.":::

-1. In the **New Container** dialog, specify `/TenantId` for the partition key field. Enter any value for the remaining fields (database, container, throughput, etc.).

- > We are using `/TenantId` as an example here. You can specify any key for the first level when implementing hierarchical partition keys on your own containers.

-1. Select **Add Hierarchical Partition Key** twice.

-1. For the second and third tiers of subpartitioning, specify `/UserId` and `/SessionId` respectively.

-### Using an SDK

-When creating a new container using the SDK, define a list of subpartitioning key paths up to three levels of depth. Use the list of subpartition keys when configuring the properties of the new container.

-// Create container properties object

-// Create container - subpartitioned by TenantId -> UserId -> SessionId

-//Create a partition key definition object with Kind("MultiHash") and Version V2

-// Create container properties object

-// Create throughput properties object

-// Create container - subpartitioned by TenantId -> UserId -> SessionId

-## Using Azure Resource Manager templates

-The Azure Resource Manager template for a subpartitioned container is mostly identical to a standard container with the only key difference being the value of the ``properties/partitionKey`` path. For more information about creating an Azure Resource Manager template for an Azure Cosmos DB resource, see [the Azure Resource Manager template reference for Azure Cosmos DB](/azure/templates/microsoft.documentdb/databaseaccounts).

-Configure the ``partitionKey`` object with the following values to create a subpartitioned container.

-| **paths** | List of hierarchical partition keys (max three levels of depth) |

-| **kind** | ``MultiHash`` |

-| **version** | ``2`` |

-### Example partition key definition

-For example, assume we have a hierarchical partition key composed of **TenantId -> UserId -> SessionId**. The ``partitionKey`` object would be configured to include all three values in the **paths** property, a **kind** value of ``MultiHash``, and a **version** value of ``2``.

-For more information about the ``partitionKey`` object, see [ContainerPartitionKey specification](/azure/templates/microsoft.documentdb/databaseaccounts/sqldatabases/containers#containerpartitionkey).

-## Using the Azure Cosmos DB emulator

-You can test the subpartitioning feature using the latest version of the local emulator for Azure Cosmos DB. To enable subparitioning on the emulator, start the emulator from the installation directory with the ``/EnablePreview`` flag.

-## Use the SDKs to work with containers with hierarchical partition keys

-Once you have a container with hierarchical partition keys, use the previously specified versions of the .NET or Java SDKs to perform operations and execute queries on that container.

-There are two options to add a new item to a container with hierarchical partition keys enabled.

-// Create new item

-// Pass in the object and the SDK will automatically extract the full partition key path

-// Create new item

-// Pass in the object and the SDK will automatically extract the full partition key path

-#### Manually specify path

-The ``PartitionKeyBuilder`` class in the SDK can construct a value for a previously defined hierarchical partition key path. Use this class when adding a new item to a container that has subpartitioning enabled.

-> At scale, it is often more performant to specify the full partition key path even if the SDK can extract the path from the object.

-// Create new item object

-// Create new item object

-Key/value lookups (point reads) are performed in a manner similar to a non-subpartitioned container. For example, assume we have a hierarchical partition key composed of **TenantId -> UserId -> SessionId**. The unique identifier for the item is a Guid, represented as a string that serves as a unique document transaction identifier. To perform a point read on a single item, pass in the ``id`` property of the item and the full value for the partition key including all three components of the path.

-#### [.NET SDK v3](#tab/net-v3)

-#### [Java SDK v4](#tab/java-v4)

-The SDK code to run a query on a subpartitioned container is identical to running a query on a non-subpartitioned container.

-When the query specifies all values of the partition keys in the ``WHERE`` filter or a prefix of the key hierarchy, the SDK automatically routes the query to the corresponding physical partitions. Queries that provide only the "middle" of the hierarchy are cross partition queries.

-For example, assume we have a hierarchical partition key composed of **TenantId -> UserId -> SessionId**. The components of the query's filter determines if the query is a single-partition, targeted cross-partition, or fan out query.

-| ``SELECT * FROM c WHERE c.TenantId = 'Microsoft' AND c.UserId = '8411f20f-be3e-416a-a3e7-dcd5a3c1f28b' AND c.SessionId = '0000-11-0000-1111'`` | Routed to the **single logical and physical partition** that contains the data for the specified values of ``TenantId``, ``UserId`` and ``SessionId``. |

-| ``SELECT * FROM c WHERE c.TenantId = 'Microsoft' AND c.UserId = '8411f20f-be3e-416a-a3e7-dcd5a3c1f28b'`` | Routed to only the **targeted subset of logical and physical partition(s)** that contain data for the specified values of ``TenantId`` and ``UserId``. This query is a targeted cross-partition query that returns data for a specific user in the tenant. |

-| ``SELECT * FROM c WHERE c.TenantId = 'Microsoft'`` | Routed to only the **targeted subset of logical and physical partition(s)** that contain data for the specified value of ``TenantId``. This query is a targeted cross-partition query that returns data for all users in a tenant. |

-| ``SELECT * FROM c WHERE c.UserId = '8411f20f-be3e-416a-a3e7-dcd5a3c1f28b'`` | Routed to **all physical partitions**, resulting in a fan-out cross-partition query. |

-| ``SELECT * FROM c WHERE c.SessionId = '0000-11-0000-1111'`` | Routed to **all physical partitions**, resulting in a fan-out cross-partition query. |

-Here's an example of running a query that includes all of the levels of subpartitioning effectively making the query a single-partition query.

-Here's an example of a query including a subset of the levels of subpartitioning effectively making this query a targeted multi-partition query.

-description: Restore a deleted container or database to an existing same Azure Cosmos DB account using Azure portal, PowerShell, or CLI when using continuous backup mode.

-# Restore a deleted container or database into same Azure Cosmos DB account (preview)

-Azure Cosmos DB's point-in-time same account restore feature helps you to recover from an accidental deletion of a container or database. Theis feature restores the deleted database or container to an existing same account in any region where backups exist. The continuous backup mode allows you to restore to any point of time within the last 30 days.

- - If you have an Azure subscription, [create a new account](nosql/how-to-create-account.md?tabs=azure-portal).

- - If you don't have an Azure subscription, create a [free account](https://azure.microsoft.com/free/?WT.mc_id=A261C142F) before you begin.

- - Alternatively, you can [try Azure Cosmos DB free](try-free.md) before you commit.

-Use the Azure portal, Azure CLI, Azure PowerShell, or an Azure Resource Manager template to restore a deleted container or database into an same account.

-Use the Azure portal to restore a deleted container or database (including child containers).

-1. Navigate to the [Azure portal](https://portal.azure.com/).

-1. Navigate to your Azure Cosmos DB account and open the **Point In Time Restore** page.

- > [!NOTE]

- > The restore page in Azure portal is only populated if you have the `Microsoft.DocumentDB/locations/restorableDatabaseAccounts/*/read` permission. To learn more about this permission, see [backup and restore permissions](continuous-backup-restore-permissions.md).

-1. Switch to the **Restore to same account** tab.

- :::image type="content" source="medi\in-account-switch.png" alt-text="Screenshot of the options to restore a database or container to the same account.":::

-1. In the **Database** field, enter a search query to filter the event feed to relevant deletion events for either a container or database.

- :::image type="content" source="medi/event-filter.png" alt-text="Screenshot of the event filter showing deletion events for containers and databases.":::

- :::image type="content" source="medi/date-filter.png" alt-text="Screenshot of the start and end date filters further filtering down deletion events.":::

- > [!NOTE]

- > The **Start** filter is limited to at most 30 days before the present date.

-1. Select **Refresh** to update the list of events on different resource types with your filters applied.

-1. Verify the time and select **Restore** to start restoration of the selected resource that was previously deleted.

- :::image type="content" source="medi/restore-confirmation.png" alt-text="Screenshot of the confirmation dialog prior to a restore operation.":::

- > [!IMPORTANT]

- > No more than three restore operations can be active at any given time on the same account. Deleting the source account while a restore operation is in-progress could result in the failure of the restore operation.

- > [!NOTE]

- > The event feed will display certain resources as **"Not restorable"**. The feel will provide more information why the resource cannot be restored.In most cases, you will be required to restore the parent database before you can restore any of its child containers.

-1. After initiating a restore operation, track the operation using the notifications area of the Azure portal. The notification provides the status of the resource being restored. While restore is in progress, the status of the container is **Creating**. After the restore operation completes, the status will change to **Online**.

-Use Azure CLI to restore a deleted container or database (including child containers).

-1. Retrieve a list of all live and deleted restorable database accounts using [`az cosmosdb restorable-database-account list`](/cli/azure/cosmosdb/restorable-database-account#az-cosmosdb-restorable-database-account-list).

-1. Use [`az cosmosdb sql restorable-database list`](/cli/azure/cosmosdb/sql/restorable-database#az-cosmosdb-sql-restorable-database-list) to list all restorable versions of databases for live accounts.

- > [!NOTE]

- > Listing all the restorable database deletion events allows you to choose the right database in a scenario where the actual time of existence is unknown. If the event feed contains the **Delete** operation type in its response, then itΓÇÖs a deleted database and it can be restored within the same account. The restore timestamp can be set to any timestamp before the deletion timestamp and within the retention window.

-1. Use [`az cosmosdb sql restorable-container list`](/cli/azure/cosmosdb/sql/restorable-container#az-cosmosdb-sql-restorable-container-list) to list all the versions of restorable containers within a specific database.

- > [!NOTE]

- > Listing all the restorable database deletion events allows you allows you to choose the right container in a scenario where the actual time of existence is unknown. If the event feed contains the **Delete** operation type in its response, then itΓÇÖs a deleted container and it can be restored within the same account. The restore timestamp can be set to any timestamp before the deletion timestamp and within the retention window.

-1. Trigger a restore operation for a deleted database using [`az cosmosdb sql database restore`](/cli/azure/cosmosdb/sql/database#az-cosmosdb-sql-database-restore).

-1. Trigger a restore operation for a deleted container using [`az cosmosdb sql container restore`](/cli/azure/cosmosdb/sql/container#az-cosmosdb-sql-container-restore).

-1. Retrieve a list of all live and deleted restorable database accounts using [`az cosmosdb restorable-database-account list`](/cli/azure/cosmosdb/restorable-database-account#az-cosmosdb-restorable-database-account-list).

-1. Use [`az cosmosdb mongodb restorable-database list`](/cli/azure/cosmosdb/mongodb/restorable-database#az-cosmosdb-mongodb-restorable-database-list) to list all restorable versions of databases for live accounts.

-1. Use [`az cosmosdb mongodb restorable-collection list`](/cli/azure/cosmosdb/mongodb/restorable-collection#az-cosmosdb-mongodb-restorable-collection-list) to list all the versions of restorable collections within a specific database.

-1. Trigger a restore operation for a deleted database using [`az cosmosdb mongodb database restore`](/cli/azure/cosmosdb/mongodb/database#az-cosmosdb-mongodb-database-restore).

-1. Trigger a restore operation for a deleted collection using [`az cosmosdb mongodb collection restore`](/cli/azure/cosmosdb/mongodb/collection#az-cosmosdb-mongodb-collection-restore).

-1. Retrieve a list of all live and deleted restorable database accounts using [`az cosmosdb restorable-database-account list`](/cli/azure/cosmosdb/restorable-database-account#az-cosmosdb-restorable-database-account-list).

-1. Use [`az cosmosdb gremlin restorable-database list`](/cli/azure/cosmosdb/gremlin/restorable-database#az-cosmosdb-gremlin-restorable-database-list) to list all restorable versions of databases for live accounts.

-1. Use [`az cosmosdb gremlin restorable-graph list`](/cli/azure/cosmosdb/gremlin/restorable-graph#az-cosmosdb-gremlin-restorable-graph-list) to list all the versions of restorable graphs within a specific database.

-1. Trigger a restore operation for a deleted database using [`az cosmosdb gremlin database restore`](/cli/azure/cosmosdb/gremlin/database#az-cosmosdb-gremlin-database-restore).

-1. Trigger a restore operation for a deleted graph using [`az cosmosdb gremlin graph restore`](/cli/azure/cosmosdb/gremlin/graph#az-cosmosdb-gremlin-graph-restore).

-1. Retrieve a list of all live and deleted restorable database accounts using [`az cosmosdb restorable-database-account list`](/cli/azure/cosmosdb/restorable-database-account#az-cosmosdb-restorable-database-account-list).

-1. Use [`az cosmosdb table restorable-table list`](/cli/azure/cosmosdb/table/restorable-table#az-cosmosdb-table-restorable-table-list) to list all restorable versions of tables for live accounts.

-1. Trigger a restore operation for a deleted table using [`az cosmosdb table restore`](/cli/azure/cosmosdb/table#az-cosmosdb-table-restore).

-Use Azure PowerShell to restore a deleted container or database (including child containers).

-1. Retrieve a list of all live and deleted restorable database accounts using [`Get-AzCosmosDBRestorableDatabaseAccount`](/powershell/module/az.cosmosdb/get-azcosmosdbrestorabledatabaseaccount).

- > [!NOTE]

- > There are `CreationTime` or `DeletionTime` fields for the account. These same fields exist for regions too. These times allow you to choose the right region and a valid time range to use when restoring a resource.

-1. Use [`Get-AzCosmosDBSqlRestorableDatabase`](/powershell/module/az.cosmosdb/get-azcosmosdbsqlrestorabledatabase) to list all restorable versions of databases for live accounts.

- > [!NOTE]

- > Listing all the restorable database deletion events allows you to choose the right database in a scenario where the actual time of existence is unknown. If the event feed contains the **Delete** operation type in its response, then itΓÇÖs a deleted database and it can be restored within the same account. The restore timestamp can be set to any timestamp before the deletion timestamp and within the retention window.

-1. Use [`Get-AzCosmosDBSqlRestorableContainer`](/powershell/module/az.cosmosdb/get-azcosmosdbsqlrestorablecontainer) list all the versions of restorable containers within a specific database.

- > [!NOTE]

- > Listing all the restorable database deletion events allows you allows you to choose the right container in a scenario where the actual time of existence is unknown. If the event feed contains the **Delete** operation type in its response, then itΓÇÖs a deleted container and it can be restored within the same account. The restore timestamp can be set to any timestamp before the deletion timestamp and within the retention window.

-1. Trigger a restore operation for a deleted database with `Restore-AzCosmosDBSqlDatabase`.

-1. Trigger a restore operation for a deleted container with `Restore-AzCosmosDBSqlContainer`.

-1. Retrieve a list of all live and deleted restorable database accounts using [`Get-AzCosmosDBRestorableDatabaseAccount`](/powershell/module/az.cosmosdb/get-azcosmosdbrestorabledatabaseaccount).

- > [!NOTE]

- > There are `CreationTime` or `DeletionTime` fields for the account. These same fields exist for regions too. These times allow you to choose the right region and a valid time range to use when restoring a resource.

-1. Use [`Get-AzCosmosdbMongoDBRestorableDatabase`](/powershell/module/az.cosmosdb/get-azcosmosdbmongodbrestorabledatabase) to list all restorable versions of databases for live accounts.

-1. Use [`Get-AzCosmosDBMongoDBRestorableCollection`](/powershell/module/az.cosmosdb/get-azcosmosdbmongodbrestorablecollection) to list all the versions of restorable collections within a specific database.

-1. Trigger a restore operation for a deleted database with `Restore-AzCosmosDBMongoDBDatabase`.

-1. Trigger a restore operation for a deleted collection with `Restore-AzCosmosDBMongoDBCollection`.

-1. Retrieve a list of all live and deleted restorable database accounts using [`Get-AzCosmosDBRestorableDatabaseAccount`](/powershell/module/az.cosmosdb/get-azcosmosdbrestorabledatabaseaccount).

- > [!NOTE]

- > There are `CreationTime` or `DeletionTime` fields for the account. These same fields exist for regions too. These times allow you to choose the right region and a valid time range to use when restoring a resource.

-1. Use [`Get-AzCosmosdbGremlinRestorableDatabase`](/powershell/module/az.cosmosdb/get-azcosmosdbgremlinrestorabledatabase) to list all restorable versions of databases for live accounts.

-1. Use [`Get-AzCosmosdbGremlinRestorableGraph`](/powershell/module/az.cosmosdb/get-azcosmosdbgremlinrestorablegraph) to list all the versions of restorable graphs within a specific database.

-1. Trigger a restore operation for a deleted database with `Restore-AzCosmosDBGremlinDatabase`.

-1. Trigger a restore operation for a deleted graph with `Restore-AzCosmosDBGremlinGraph`.

-1. Retrieve a list of all live and deleted restorable database accounts using [`Get-AzCosmosDBRestorableDatabaseAccount`](/powershell/module/az.cosmosdb/get-azcosmosdbrestorabledatabaseaccount).

- > [!NOTE]

- > There are `CreationTime` or `DeletionTime` fields for the account. These same fields exist for regions too. These times allow you to choose the right region and a valid time range to use when restoring a resource.

-1. Use [`Get-AzCosmosdbTableRestorableTable`](/powershell/module/az.cosmosdb/get-azcosmosdbtablerestorabletable) to list all restorable versions of tables for live accounts.

-1. Trigger a restore operation for a deleted table with `Restore-AzCosmosDBTable`.

-You can restore deleted containers and databases using an Azure Resource Manager template.

-1. Create or locate an Azure Cosmos DB resource in your template. Here's a generic example of a resource.

-1. Update the Azure Cosmos DB resource in your template by:

- - Setting `properties.createMode` to `restore`.

- - Defining a `properties.restoreParameters` object.

- - Setting `properties.restoreParameters.restoreTimestampInUtc` to a UTC timestamp.

- - Setting `properties.restoreParameters.restoreSource` to the **instance identifier** of the account that is the source of the restore operation.

- > [!NOTE]

- > Use [`az cosmosdb restorable-database-account list`](/cli/azure/cosmosdb/restorable-database-account#az-cosmosdb-restorable-database-account-list) to retrieve a list of instance identifiers for all live and deleted restorable database accounts.

-1. Deploy the template using [`az deployment group create`](/cli/azure/deployment/group#az-deployment-group-create).

-When a point-in-time restore is triggered for a deleted container or database, the operation is identified as an **InAccount** restore operation on the resource.

-To get a list of restore operations for a specific resource, filter the Activity Log of the account using the search filter `InAccount Restore Deleted` and a time filter. The resulting list includes the `UserPrincipalName` field that identifies the user that triggered the restore operation. For more information on how to access activity logs, see [Auditing point-in-time restore actions](audit-restore-continuous.md#audit-the-restores-that-were-triggered-on-a-live-database-account).

-### [Azure CLI / Azure PowerShell / Azure Resource Manager template](#tab/azure-cli+azure-powershell+azure-resource-manager)

-At present portal is used for getting the activity log of the account using the search filter `InAccount Restore Deleted` and a time filter.

-description: Copy container data between containers within an account in Azure Cosmos DB.

-# Intra-account container copy jobs in Azure Cosmos DB (Preview)

-You can perform offline container copy within an Azure Cosmos DB account using container copy jobs.

-You may need to copy data within your Azure Cosmos DB account if you want to achieve any of these scenarios:

-* Change the [granularity at which throughput is provisioned - from database to container](set-throughput.md) and vice-versa.

-* Rename a container/database.

-* Adopt new features that are only supported on new containers.

-Intra-account container copy jobs can be [created and managed using CLI commands](how-to-container-copy.md).

-To get started with intra-account offline container copy for NoSQL and Cassandra API accounts, register for **"Intra-account offline container copy (Cassandra & NoSQL)"** preview feature flag from the ['Preview Features'](access-previews.md) list in the Azure portal. Once the registration is complete, the preview is effective for all Cassandra and API for NoSQL accounts in the subscription.

-To get started with intra-account offline container copy for Azure Cosmos DB for MongoDB accounts, register for **"Intra-account offline container copy (MongoDB)"** preview feature flag from the ['Preview Features'](access-previews.md) list in the Azure portal. Once the registration is complete, the preview is effective for all API for MongoDB accounts in the subscription.

-## How to do container copy?

-1. Create the target Azure Cosmos DB container with the desired settings (partition key, throughput granularity, RUs, unique key, etc.).

-2. Stop the operations on the source container by pausing the application instances or any clients connecting to it.

-3. [Create the container copy job](how-to-container-copy.md).

-4. [Monitor the progress of the container copy job](how-to-container-copy.md#monitor-the-progress-of-a-container-copy-job) and wait until it's completed.

-5. Resume the operations by appropriately pointing the application or client to the source or target container copy as intended.

-Intra-account container copy jobs perform offline data copy using the source container's incremental change feed log.

-* The platform allocates server-side compute instances for the Azure Cosmos DB account.

-* These instances are allocated when one or more container copy jobs are created within the account.

-* The container copy jobs run on these instances.

-* A single job is executed across all instances at any time.

-* The instances are shared by all the container copy jobs running within the same account.

-* The platform may deallocate the instances if they're idle for >15 mins.

-> We currently only support offline container copy jobs. So, we strongly recommend to stop performing any operations on the source container prior to beginning the container copy. Item deletions and updates done on the source container after beginning the copy job may not be captured. Hence, continuing to perform operations on the source container while the container job is in progress may result in additional or missing data on the target container.

-## Factors affecting the rate of a container copy job

-* Source container/database throughput setting.

-* Target container/database throughput setting.

- > [!TIP]

- > Set the target container throughput to at least two times the source container's throughput.

-* Server-side compute instances allocated to the Azure Cosmos DB account for performing the data transfer.

- > [!IMPORTANT]

- > The default SKU offers two 4-vCPU 16-GB server-side instances per account.

-Container copy jobs don't work with accounts having following capabilities enabled. You will need to disable these features before running the container copy jobs.

-### Account Configurations

-### Is there an SLA for the container copy jobs?

-Container copy jobs are currently supported on best-effort basis. We don't provide any SLA guarantees for the time taken to complete these jobs.

-Yes, you can create multiple jobs within the same account. The jobs run consecutively. You can [list all the jobs](how-to-container-copy.md#list-all-the-container-copy-jobs-created-in-an-account) created within an account and monitor their progress.

-The container copy job runs in the write region. If there are accounts configured with multi-region writes, the job runs in one of the regions from the list.

-The account's write region may change in the rare scenario of a region outage or due to manual failover. In such a scenario, incomplete container copy jobs created within the account would fail. You would need to recreate these failed jobs. Recreated jobs would then run in the new (current) write region.

-| **Americas** | **Europe and Africa** | **Asia Pacific** |

-| South Central US | UK South | |

-| West Central US | UK West | |

-| West US | West Europe |

-| West US 2 | |

-## Known/common issues

-* Error - Owner resource doesn't exist

- If the job creation fails with the error *"Owner resource doesn't exist"*, it means that the target container wasn't created or was mis-spelt.

- Make sure the target container is created before running the job as specified in the [overview section.](#how-to-do-container-copy)

- If the request fails with error Unauthorized (401), this could happen because Local Authorization is disabled, see [disable local auth](how-to-setup-rbac.md#use-azure-resource-manager-templates). Container copy jobs use primary key to authenticate and if local authorization is disabled, the job creation fails. You need to enable local authorization for container copy jobs to work.

- This error can occur due to internal server issues. To resolve this issue, contact Microsoft support by raising a **New Support Request** from the Azure portal. Set the Problem Type as **'Data Migration'** and Problem subtype as **'Intra-account container copy'**.

- ```

-

-* You can learn [how to create, monitor and manage container copy jobs within Azure Cosmos DB account using CLI commands](how-to-container-copy.md).

-description: Learn about Azure Cosmos DB for MongoDB 4.2 server version supported features and syntax. Learn about the database commands, query language support, datatypes, aggregation pipeline commands, and operators supported.

-# Azure Cosmos DB for MongoDB (4.2 server version): supported features and syntax

-Azure Cosmos DB is Microsoft's globally distributed multi-model database service, offering [multiple database APIs](../choose-api.md). You can communicate with the Azure Cosmos DB for MongoDB using any of the open-source MongoDB client [drivers](https://docs.mongodb.org/ecosystem/drivers). The Azure Cosmos DB for MongoDB enables the use of existing client drivers by adhering to the MongoDB [wire protocol](https://docs.mongodb.org/manual/reference/mongodb-wire-protocol).

-By using the Azure Cosmos DB for MongoDB, you can enjoy the benefits of the MongoDB you're used to, with all of the enterprise capabilities that Azure Cosmos DB provides: [global distribution](../distribute-data-globally.md), [automatic sharding](../partitioning-overview.md), availability and latency guarantees, encryption at rest, backups, and much more.

-## Protocol Support

-The supported operators and any limitations or exceptions are listed below. Any client driver that understands these protocols should be able to connect to Azure Cosmos DB for MongoDB. When you create Azure Cosmos DB for MongoDB accounts, the 3.6+ versions of accounts have the endpoint in the format `*.mongo.cosmos.azure.com` whereas the 3.2 version of accounts has the endpoint in the format `*.documents.azure.com`.

-> This article only lists the supported server commands, and excludes client-side wrapper functions. Client-side wrapper functions such as `deleteMany()` and `updateMany()` internally utilize the `delete()` and `update()` server commands. Functions utilizing supported server commands are compatible with the Azure Cosmos DB for MongoDB.

-Azure Cosmos DB for MongoDB provides comprehensive support for MongoDB query language constructs. Below you can find the detailed list of currently supported operations, operators, stages, commands, and options.

-Azure Cosmos DB for MongoDB supports the following database commands:

-> Multi-document transactions are only supported within a single non-sharded collection. Cross-collection and cross-shard multi-document transactions are not yet supported in the API for MongoDB.

-## <a name="aggregation-pipeline"></a>Aggregation pipeline

-> The `$lookup` aggregation does not yet support the [uncorrelated subqueries](https://docs.mongodb.com/manual/reference/operator/aggregation/lookup/#join-conditions-and-uncorrelated-sub-queries) feature introduced in server version 3.6. You will receive an error with a message containing `let is not supported` if you attempt to use the `$lookup` operator with `let` and `pipeline` fields.

-> The API for MongoDB does not support comparison expressions with an array literal in the query.

-Azure Cosmos DB for MongoDB supports documents encoded in MongoDB BSON format. Versions 4.0 and higher (4.0+) enhance the internal usage of this format to improve performance and reduce costs. Documents written or updated through an endpoint running 4.0+ benefit from this optimization.

-In an [upgrade scenario](upgrade-version.md), documents written prior to the upgrade to version 4.0+ won't benefit from the enhanced performance until they're updated via a write operation through the 4.0+ endpoint.

-16-MB document support raises the size limit for your documents from 2 MB to 16 MB. This limit only applies to collections created after this feature has been enabled. Once this feature is enabled for your database account, it can't be disabled. This feature isn't compatible with the Azure Synapse Link feature and/or Continuous Backup.

-Enabling 16 MB can be done in the features tab in the Azure portal or programmatically by [adding the `EnableMongo16MBDocumentSupport` capability](how-to-configure-capabilities.md).

-We recommend enabling Server Side Retry and avoiding wildcard indexes to ensure requests with larger documents succeed. If necessary, raising your DB/Collection RUs may also help performance.

-| `Partial` | Only supported with unique indexes |

-| `text` | No (Not supported. Use $regex instead.) |

-In the $regex queries, left-anchored expressions allow index search. However, using 'i' modifier (case-insensitivity) and 'm' modifier (multiline) causes the collection scan in all expressions.

-When there's a need to include '$' or '|', it's best to create two (or more) regex queries. For example, given the following original query: `find({x:{$regex: /^abc$/})`, it has to be modified as follows:

-The first part will use the index to restrict the search to those documents beginning with ^abc and the second part will match the exact entries. The bar operator '|' acts as an "or" function - the query `find({x:{$regex: /^abc |^def/})` matches the documents in which field 'x' has values that begin with "abc" or "def". To utilize the index, it's recommended to break the query into two different queries joined by the $or operator: `find( {$or : [{x: $regex: /^abc/}, {$regex: /^def/}] })`.

-When you use the `findOneAndUpdate` operation, sort operations on a single field are supported, but sort operations on multiple fields aren't supported.

-## Client-side field level encryption

-Client-level field encryption is a driver feature and is compatible with the API for MongoDB. Explicit encryption - were the driver explicitly encrypts each field when written is supported. Automatic encryption isn't supported. Explicit decryption and automatic decryption is supported.

-The mongocryptd shouldn't be run since it isn't needed to perform any of the supported operations.

-Azure Cosmos DB supports automatic, native replication at the lowest layers. This logic is extended out to achieve low-latency, global replication as well. Azure Cosmos DB doesn't support manual replication commands.

-## Retryable Writes

-The Retryable writes feature enables MongoDB drivers to automatically retry certain write operations. The feature results in more stringent requirements for certain operations, which match MongoDB protocol requirements. With this feature enabled, update operations, including deletes, in sharded collections will require the shard key to be included in the query filter or update statement.

-For example, with a sharded collection, sharded on key ΓÇ£countryΓÇ¥: To delete all the documents with the field **city** = `"NYC"`, the application will need to execute the operation for all shard key (country) values if the Retryable writes feature is enabled.

-> Retryable writes does not support bulk unordered writes at this time. If you would like to perform bulk writes with retryable writes enabled, perform bulk ordered writes.

-To enable the feature, [add the `EnableMongoRetryableWrites` capability](how-to-configure-capabilities.md) to your database account. This feature can also be enabled in the features tab in the Azure portal.

-Azure Cosmos DB supports automatic, server-side sharding. It manages shard creation, placement, and balancing automatically. Azure Cosmos DB doesn't support manual sharding commands, which means you don't have to invoke commands such as addShard, balancerStart, moveChunk etc. You only need to specify the shard key while creating the containers or querying the data.

-## Time-to-live (TTL)

-Azure Cosmos DB supports a time-to-live (TTL) based on the timestamp of the document. TTL can be enabled for collections from the [Azure portal](https://portal.azure.com).

-#### Custom Time-To-Live (TTL)

-This feature provides the ability to set a customer TTL on any one field in a collection.

-On a collection with TTL enabled on a field:

-Acceptable types are: BSON date type and numeric types (integer, long, double) which will be interpreted as a unix milliseconds timestamp, for the purpose of expiration.

-##### Limitations of Custom TTL

-##### Configuration

-This feature can be enabled by updating the account capability "EnableTtlOnCustomPath". Refer [how to configure capabilities](../../cosmos-db/mongodb/how-to-configure-capabilities.md)

-#### To set up the TTL:

-## User and role management

-Azure Cosmos DB doesn't yet support users and roles. However, Azure Cosmos DB supports Azure role-based access control (Azure RBAC) and read-write and read-only passwords/keys that can be obtained through the [Azure portal](https://portal.azure.com) (Connection String page).

-## Write Concern

-Some applications rely on a [Write Concern](https://docs.mongodb.com/manual/reference/write-concern/), which specifies the number of responses required during a write operation. Due to how Azure Cosmos DB handles replication in the background, all writes are automatically Quorum by default. Any write concern specified by the client code is ignored. Learn more in [Using consistency levels to maximize availability and performance](../consistency-levels.md).

- - If all you know is the number of vCores and servers in your existing database cluster, read about [estimating request units using vCores or vCPUs](../convert-vcore-to-request-unit.md).

- - If you know typical request rates for your current database workload, read about [estimating request units using Azure Cosmos DB capacity planner](estimate-ru-capacity-planner.md).

-description: Learn how to configure your API for MongoDB account capabilities

-Capabilities are features that can be added or removed to your API for MongoDB account. Many of these features affect account behavior so it's important to be fully aware of the effect a capability will have before enabling or disabling it. Several capabilities are set on API for MongoDB accounts by default, and can't be changed or removed. One example is the EnableMongo capability. This article will demonstrate how to enable and disable a capability.

-| `DisableRateLimitingResponses` | Allows Mongo API to retry rate-limiting requests on the server-side until max-request-timeout | Yes |

-| `EnableMongoRoleBasedAccessControl` | Enable support for creating Users/Roles for native MongoDB role-based access control | No |

-| `EnableMongoRetryableWrites` | Enables support for retryable writes on the account | Yes |

-| `EnableMongo16MBDocumentSupport` | Enables support for inserting documents upto 16 MB in size | No |

-| `EnableUniqueCompoundNestedDocs` | Enables support for compound and unique indexes on nested fields, as long as the nested field is not an array. | No |

-| `EnableTtlOnCustomPath` | Provides the ability to set a custom TTL on any one field in a collection | No |

-| `EnablePartialUniqueIndex` | Enables support for unique partial index which allows you more flexibility to specify exactly which fields in documents you'd like to index. | No |

-1. Retrieve your existing account capabilities by using [**az cosmosdb show**](/cli/azure/cosmosdb#az-cosmosdb-show):

- You should see a capability section similar to this output:

- Review the default capability. In this example, we have just `EnableMongo`.

-1. Set the new capability on your database account. The list of capabilities should include the list of previously enabled capabilities, since only the explicitly named capabilities will be set on your account. For example, if you want to add the capability `DisableRateLimitingResponses`, you would use the [**az cosmosdb update**](/cli/azure/cosmosdb#az-cosmosdb-update) command with the `--capabilities` parameter:

- > The list of capabilities must always specify all capabilities you wish to enable, inclusively. This includes capabilities already enabled for the account. In this example, the `EnableMongo` capability was already enabled, so both the `EnableMongo` and `DisableRateLimitingResponses` capabilities must be specified.

- > If you're using PowerShell and receive an error using the command above, try using a PowerShell array instead to list the capabilities:

-1. Retrieve your existing account capabilities by using **az cosmosdb show**:

- You should see a capability section similar to this output:

- Observe each of these capabilities. In this example, we have `EnableMongo` and `DisableRateLimitingResponses`.

-1. Remove the capability from your database account. The list of capabilities should include the list of previously enabled capabilities you want to keep, since only the explicitly named capabilities will be set on your account. For example, if you want to remove the capability `DisableRateLimitingResponses`, you would use the **az cosmosdb update** command:

- > If you're using PowerShell and receive an error using the command above, try using a PowerShell array instead to list the capabilities:

- - If all you know is the number of vCores and servers in your existing database cluster, read about [estimating request units using vCores or vCPUs](../convert-vcore-to-request-unit.md).

- - If you know typical request rates for your current database workload, read about [estimating request units using Azure Cosmos DB capacity planner](estimate-ru-capacity-planner.md).

-description: Use vector indexing and search to integrate AI-based applications in Azure Cosmos DB for MongoDB vCore

-# Using vector search on embeddings in Azure Cosmos DB for MongoDB vCore

-Use Vector Search in Azure Cosmos DB for MongoDB vCore to seamlessly integrate your AI-based applications, including apps built using [Azure OpenAI embeddings](../../../cognitive-services/openai/tutorials/embeddings.md), with your data stored in Azure Cosmos DB. Vector search enables you to efficiently store, index, and query high dimensional vector data stored directly in Azure Cosmos DB for MongoDB vCore, eliminating the need to transfer your data to more expensive alternatives for vector search capabilities.

-## What is Vector search?

-Vector search is a method that helps you find similar items based on their data characteristics rather than exact matches on a property field. This technique is useful in applications such as searching for similar text, finding related images, making recommendations, or even detecting anomalies. It works by taking the vector representations (lists of numbers) of your data that you have created using an ML model, or an embeddings API. Examples of embeddings APIs could be [Azure OpenAI Embeddings](/azure/cognitive-services/openai/how-to/embeddings) or [Hugging Face on Azure](https://azure.microsoft.com/solutions/hugging-face-on-azure/). It then measures the distance between the data vectors and your query vector. The data vectors that are closest to your query vector are the ones that are found to be most similar semantically.

-By integrating vector search capabilities natively, you can now unlock the full potential of your data in applications built on top of the OpenAI API. You can also create custom-built solutions that use vector embeddings.

-## Create a vector index

-To create a vector index, use the following createIndex Spec template:

-| `index_name` | `string` | Unique name of the index. |

-| `path_to_property` | `string` | Path to the property containing the vector. This path can be a top-level property or a `dot-notation` path to the property. If a `dot-notation` path is used, then all the nonleaf elements can't be arrays. |

-| `kind` | `string` | Type of vector index to create. Currently, `vector-ivf` is the only supported index option. |

-| `numLists` | `integer` | This integer is the number of clusters the IVF index uses to group the vector data. It's recommended that numLists are set to `rowCount()/1000` for up to a million rows and `sqrt(rowCount)` for more than a million rows. |

-| `similarity` | `string` | Similarity metric to use with the IVF index. Possible options are `COS` (cosine distance), `L2` (Euclidean distance) or `IP` (inner product) |

-| `dimensions` | `integer` | Number of dimensions for vector similarity. The maximum number of supported dimensions is `2000`. |

-In the following examples, we walk through examples on how to index vectors, add documents with vector properties, perform a vector search, and retrieve the index configuration.

-### Create a vectorIndex

-This command creates a `vector-ivf` index against the "vectorContent" property in the documents stored in the specified collection, `exampleCollection`. The `cosmosSearchOptions` property specifies the parameters for the IVF vector index. If your document has the vector stored in a nested property, you can set this property using a dot-notation path. For example, `text.vectorContent` if `vectorContent` is a subproperty of `text`.

-## Adding vectors to your database

-To add vectors to your database's collection, you first need to create the embeddings using your own model, [Azure OpenAI Embeddings](https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/cognitive-services/openai/tutorials/embeddings.md), or another API (such as [Hugging Face on Azure](https://azure.microsoft.com/solutions/hugging-face-on-azure/)). In this example, new documents are added with sample embeddings:

-### Performing a vector search

-To perform a vector search, use the `$search` aggregation pipeline stage in a MongoDB query. To use the `cosmosSearch` index, we have introduced a new `cosmosSearch` operator.

-### Query a vectorIndex using $search

-Continuing with the above example, create another vector, `queryVector`. Vector search measures the distance between `queryVector` and the vectors in the `vectorContent` path of your documents. You can set the number of results the search returns by setting the parameter `k`, which is set to `2` here.

-In this example, a vector search is performed using `queryVector` as an input via the Mongo shell. The search result is a list of the two most similar items to the query vector, sorted by their similarity scores.

-To retrieve your vector index definition from the collection, use the `listIndexes` command.

-In this example, the vectorIndex is returned along with all the cosmosSearch parameters used to create the index

-* Supported distance metrics: L2 (Euclidean), inner product, and cosine.

-* Supported indexing methods: IVFFLAT.

-* Indexing vectors up to 2,000 dimensions in size.

-* Indexing applies to only one vector per document.

-This guide demonstrated how to create a vector index, add documents with vector data, perform a similarity search, and retrieve the index definition. By using vector search, you can efficiently store, index, and query high-dimensional vector data directly in Azure Cosmos DB for MongoDB vCore. Vector search enables you to unlock the full potential of your data with vector embeddings, and empowers you to build more accurate, efficient, and powerful applications.

-description: Overview of common change feed design patterns

-The Azure Cosmos DB change feed enables efficient processing of large datasets with a high volume of writes. Change feed also offers an alternative to querying an entire dataset to identify what has changed. This document focuses on common change feed design patterns, design tradeoffs, and change feed limitations.

-* Triggering a notification or a call to an API when an item is inserted, updated or deleted.

-* Real-time stream processing for IoT or real-time analytics processing on operational data.

-* Data movement such as synchronizing with a cache, a search engine, a data warehouse, or cold storage.

-The Azure Cosmos DB change feed can simplify scenarios that need to trigger a notification or send a call to an API based on a certain event. You can use the [Change Feed Processor](change-feed-processor.md) to automatically poll your container for changes and call an external API each time there's a write, update or delete.

-You can also selectively trigger a notification or send a call to an API based on specific criteria. For example, if you're reading from the change feed using [Azure Functions](change-feed-functions.md), you can put logic into the function to only send a notification if a condition is met. While the Azure Function code would execute for each change, the notification would only be sent if the condition is met.

-The Azure Cosmos DB change feed can be used for real-time stream processing for IoT or real-time analytics processing on operational data.

-For example, you might receive and store event data from devices, sensors, infrastructure and applications, and process these events in real time, using [Spark](../../hdinsight/spark/apache-spark-overview.md). The following image shows how you can implement a lambda architecture using the Azure Cosmos DB change feed:

-Data written to Azure Cosmos DB shows up in the change feed and is retained until deleted when reading with [latest version mode](change-feed-modes.md#latest-version-change-feed-mode). Message queues typically have a maximum retention period. For example, [Azure Event Hubs](https://azure.microsoft.com/services/event-hubs/) offers a maximum data retention of 90 days.

-### Querying ability

-In addition to reading from an Azure Cosmos DB container's change feed, you can also run SQL queries on the data stored in Azure Cosmos DB. The change feed isn't a duplication of data already in the container but rather just a different mechanism of reading the data. Therefore, if you read data from the change feed, it's always consistent with queries of the same Azure Cosmos DB container.

-Azure Cosmos DB offers up to 99.999% read and write availability. Unlike many message queues, Azure Cosmos DB data can be easily globally distributed and configured with an [RTO (Recovery Time Objective)](../consistency-levels.md#rto) of zero.

-After processing items in the change feed, you can build a materialized view and persist aggregated values back in Azure Cosmos DB. If you're using Azure Cosmos DB to build a game, you can, for example, use change feed to implement real-time leaderboards based on scores from completed games.

-* Update a cache, search index, or data warehouse with data stored in Azure Cosmos DB.

-* Perform zero down-time migrations to another Azure Cosmos DB account or another Azure Cosmos DB container with a different logical partition key.

-* Implement an application-level data tiering and archival. For example, you can store "hot data" in Azure Cosmos DB and age out "cold data" to other storage systems such as [Azure Blob Storage](../../storage/common/storage-introduction.md).

-), you can read from your container's change feed as a source for this data replication. Real-time data replication with the change feed can only guarantee eventual consistency. You can [monitor how far the Change Feed Processor lags behind](how-to-use-change-feed-estimator.md) in processing changes in your Azure Cosmos DB container.

-The [event sourcing pattern](/azure/architecture/patterns/event-sourcing) involves using an append-only store to record the full series of actions on that data. Azure Cosmos DB's change feed is a great choice as a central data store in event sourcing architectures where all data ingestion is modeled as writes (no updates or deletes). In this case, each write to Azure Cosmos DB is an "event" meaning there's a full record of past events in the change feed. Typical uses of the events published by the central event store are for maintaining materialized views or for integration with external systems. Because there's no time limit for retention in the [change feed latest version mode](change-feed-modes.md#latest-version-change-feed-mode), you can replay all past events by reading from the beginning of your Azure Cosmos DB container's change feed. You can even have [multiple change feed consumers subscribe to the same container's change feed](how-to-create-multiple-cosmos-db-triggers.md#optimizing-containers-for-multiple-triggers).

-Azure Cosmos DB is a great central append-only persistent data store in the event sourcing pattern because of its strengths in horizontal scalability and high availability. In addition, the change Feed Processor library offers an ["at least once"](change-feed-processor.md#error-handling) guarantee, ensuring that you don't miss processing any events.

-The change feed has multiple modes that each have important limitations that you should understand. There are several areas to consider when designing an application that uses the change feed in either [latest version mode](change-feed-modes.md#latest-version-change-feed-mode) or [all versions and deletes mode](change-feed-modes.md#all-versions-and-deletes-change-feed-mode-preview).

-In latest version mode, only the most recent change for a given item is included in the change feed. When processing changes, you read the latest available item version. If there are multiple updates to the same item in a short period of time, it's possible to miss processing intermediate updates. If you would like to replay past individual updates to an item, you can model these updates as a series of writes instead or use all versions and deletes mode.

-All versions and deletes mode provides a full operation log of every item version from all operations. This means no intermediate updates are missed as long as they occurred within the continuous backup retention period configured on the account.

-The change feed latest version mode doesn't capture deletes. If you delete an item from your container, it's also removed from the change feed. The most common method of handling deletes is adding a soft marker on the items that are being deleted. You can add a property called "deleted" and set it to "true" at the time of deletion. This document update shows up in the change feed. You can set a TTL on this item so that it can be automatically deleted later.

-Deletes are captured in all versions and deletes mode without needing to set a soft delete marker. You also get metadata indicating if the delete was from a TTL expiration or not.

-The change feed in latest version mode has an unlimited retention. As long as an item exists in your container it's available in the change feed.

-All versions and deletes mode only allows you to read changes that occurred within the continuous backup retention period configured on the account. This means that if your account is configured with a seven day retention period, you can't read changes from eight days ago. If your application needs to track all updates from the beginning of the container, latest version mode might be a better fit.

-All change feed modes have a guaranteed order within a partition key value but not across partition key values. You should select a partition key that gives you a meaningful order guarantee.

-For example, consider a retail application using the event sourcing design pattern. In this application, different user actions are each "events", which are modeled as writes to Azure Cosmos DB. Imagine if some example events occurred in the following sequence:

-1. Customer adds Item A to their shopping cart

-2. Customer adds Item B to their shopping cart

-3. Customer removes Item A from their shopping cart

-4. Customer checks out and shopping cart contents are shipped

-A materialized view of current shopping cart contents is maintained for each customer. This application must ensure that these events are processed in the order in which they occur. If for example, the cart checkout were to be processed before Item A's removal, it's likely that the customer would have had Item A shipped, as opposed to the desired Item B. In order to guarantee that these four events are processed in order of their occurrence, they should fall within the same partition key value. If you select **username** (each customer has a unique username) as the partition key, you can guarantee that these events show up in the change feed in the same order in which they're written to Azure Cosmos DB.

-* [Change feed overview](../change-feed.md)

-* [Change feed modes](change-feed-modes.md)

-* [Options to read change feed](read-change-feed.md)

-* Trying to do capacity planning for a migration to Azure Cosmos DB? You can use information about your existing database cluster for capacity planning.

- * If all you know is the number of vCores and servers in your existing database cluster, read about [estimating request units using vCores or vCPUs](../convert-vcore-to-request-unit.md)

- * If you know typical request rates for your current database workload, read about [estimating request units using Azure Cosmos DB capacity planner](estimate-ru-with-capacity-planner.md)

-description: Overview of Azure Cosmos DB change feed modes

-There are two change feed modes in Azure Cosmos DB. Each mode offers the same core functionality with differences including the operations captured in the feed, metadata available for each change, and retention period of changes. You can consume the change feed in different modes across multiple applications for the same Azure Cosmos DB container to fit the requirements of each workload.

-> [!Note]

-> Do you have any feedback about change feed modes? We want to hear it! Feel free to share feedback directly with the Azure Cosmos DB engineering team: cosmoschangefeed@microsoft.com

-Latest version mode is a persistent record of changes to items from creates and updates. You get the latest version of each item in the container. For example, if an item is created and then updated before you read the change feed, only the updated version appears in the change feed. Deletes aren't captured as changes, and when an item is deleted it's no longer be available in the feed. Latest version change feed mode is enabled by default and is compatible with all Azure Cosmos DB accounts except API for Table and API for PostgreSQL. This mode was previously the default way to consume the change feed.

-All versions and deletes mode (preview) is a persistent record of all changes to items from create, update, and delete operations. You get a record of each change to items in the order that it occurred, including intermediate changes to an item between change feed reads. For example, if an item is created and then updated before you read the change feed, both the create and the update versions of the item appear in the change feed. To read from the change feed in all versions and deletes mode, you must have [continuous backups](../continuous-backup-restore-introduction.md) configured for your Azure Cosmos DB account. Turning on continuous backups creates the all versions and deletes change feed. You can only read changes that occurred within the continuous backup period when using this change feed mode. This mode is only compatible with Azure Cosmos DB for NoSQL accounts. Learn more about how to [sign up for the preview](#getting-started).

- Latest version mode provides an easy way to process both real time and historic changes to items in a container with the ability to go back to changes from the beginning of the container.

-The following are scenarios well suited to this mode:

-* Real time processing of changes to items in a container resulting from create and update operations.

-The all versions and deletes change feed mode enables new scenarios for change feed, and simplifies others. You can read every change that occurred to items even in cases where multiple changes occurred between change feed reads, identify the operation type of changes being processed, and get changes resulting from deletes.

-A few common scenarios this mode enables and enhances are:

-* Real-time transfer of data between two locations without having to implement a soft delete.

-* Triggering alerts on delete operations, for example, auditing scenarios.

-* The change feed includes insert and update operations made to items within the container.

-* This mode of change feed doesn't log deletes. You can capture deletes by setting a "soft-delete" flag within your items instead of deleting them directly. For example, you can add an attribute in the item called "deleted" with the value "true" and then set a TTL on the item. The change feed captures it as an update and the item is automatically deleted when the TTL expires. Alternatively, you can set a finite expiration period for your items with the [TTL capability](time-to-live.md). With this solution, you have to process the changes within a shorter time interval than the TTL expiration period.

-* Only the most recent change for a given item is included in the change feed. Intermediate changes may not be available.

-* Changes can be synchronized from any point-in-time, and there's no fixed data retention period for which changes are available.

-* You can't filter the change feed for a specific type of operation. One possible alternative, is to add a "soft marker" on the item for updates and filter based on that when processing items in the change feed.

-* The starting point to read change feed can be from the beginning of the container, from a point in time, from "now", or from a specific checkpoint. The precision of the start time is ~5 secs.

-* The change feed includes insert, update and delete operations made to items within the container. Deletes from TTL expirations are also captured.

-* Metadata is provided to determine the change type, including if a delete was due to a TTL expiration or not.

-* Change feed items come in the order of their modification time. Deletes from TTL expirations aren't guaranteed to appear in the feed immediately after the item expires. They appear when the item is purged from the container.

-* All changes that occurred within the retention window set for continuous backups on the account are able to be read. Attempting to read changes that occurred outside of the retention window results in an error. For example, if your container was created eight days ago and your continuous backup period retention period is seven days, then you can only read changes from the last seven days.

-* The change feed starting point can be from "now" or from a specific checkpoint within your retention period. You can't read changes from the beginning of the container or from a specific point in time using this mode.

-## Working with the change feed

-| **Method to read change feed** | **.NET** | **Java** | **Python** | **Node/JS** |

-| | | | | | | |

-### Parsing the response object

-In latest version mode, the default response object is an array of items that have changed. Each item contains the standard metadata for any Azure Cosmos DB item including `_etag` and `_ts` with the addition of a new property `_lsn`.

-The `_etag` format is internal and you shouldn't take dependency on it because it can change anytime. `_ts` is a modification or a creation timestamp. You can use `_ts` for chronological comparison. `_lsn` is a batch ID that is added for change feed only that represents the transaction ID. Many items may have same `_lsn`. ETag on FeedResponse is different from the `_etag` you see on the item. `_etag` is an internal identifier and it's used for concurrency control. The `_etag` property represents the version of the item, whereas the ETag property is used for sequencing the feed.

-| **Method to read change feed** | **.NET** | **Java** | **Python** | **Node/JS** |

-| | | | | | | |

-> Regardless of the [connection mode](sdk-connection-modes.md#available-connectivity-modes) configured in your application, all requests made with all versions and deletes change feed will use Gateway mode.

-### Getting started

-Before submitting your request, ensure that you have at least one Azure Cosmos DB account in the subscription. This account may be an existing account or a new one you've created to try out the preview feature. If you have no accounts in the subscription when the Azure Cosmos DB team receives your request, it will be declined, as there are no accounts to apply the feature to.

-The Azure Cosmos DB team will review your request and contact you via email to confirm which account(s) in the subscription you want to enroll in the preview. To use the preview, you must have [continuous backups](../continuous-backup-restore-introduction.md) configured for your Azure Cosmos DB account. Continuous backups can be enabled either before or after being admitted to the preview, but they must be enabled before attempting to read from the change feed in all versions and deletes mode.

-### Parsing the response object

-The response object is an array of items representing each change with the following shape:

- <This is the current version of the item that changed. All of the properties of your item will appear here. This will be empty for delete operations.>

- <This is the previous version of the item that changed. If the change was a delete operation, the item that was deleted will appear here. This will be empty for create and replace operations.>

- "lsn": <This is a number representing the batch id. Many items may have the same lsn.>,

- "previousImageLSN" : <This is a number representing the batch id of the change prior to this one.>,

- "timeToLiveExpired" : <For delete changes, it will be 'true' if it was deleted due to a TTL expiration or 'false' if not.>,

- "crts": <This is a number representing the Conflict Resolved Timestamp. It has the same format as _ts.>

-* Continuous backups are required to use this change feed mode, the [limitations](../continuous-backup-restore-introduction.md#current-limitations) of which can be found in the documentation.

-* The ability to start reading the change feed from the beginning or select a start time based on a past timestamp isn't currently supported. You may either start from "now" or from a previous [lease](change-feed-processor.md#components-of-the-change-feed-processor) or [continuation token](change-feed-pull-model.md#saving-continuation-tokens).

-* Accounts using [Private Endpoints](../how-to-configure-private-endpoints.md) aren't supported.

-You can now proceed to learn more about change feed in the following articles:

-description: Learn how to use the Azure Cosmos DB Change Feed Processor to read the change feed, the components of the change feed processor

-The main benefit of change feed processor is its fault-tolerant behavior that assures an "at-least-once" delivery of all the events in the change feed.

-There are four main components of implementing the change feed processor:

-* **The monitored container:** The monitored container has the data from which the change feed is generated. Any inserts and updates to the monitored container are reflected in the change feed of the container.

-* **The lease container:** The lease container acts as a state storage and coordinates processing the change feed across multiple workers. The lease container can be stored in the same account as the monitored container or in a separate account.

-* **The compute instance**: A compute instance hosts the change feed processor to listen for changes. Depending on the platform, it could be represented by a VM, a kubernetes pod, an Azure App Service instance, or an actual physical machine. It has a unique identifier referenced as the *instance name* throughout this article.

-* **The delegate:** The delegate is the code that defines what you, the developer, want to do with each batch of changes that the change feed processor reads.

-To further understand how these four elements of change feed processor work together, let's look at an example in the following diagram. The monitored container stores items and uses 'City' as the partition key. The partition key values are distributed in ranges (each range representing a [physical partition](../partitioning-overview.md#physical-partitions)) that contain items.

-There are two compute instances and the change feed processor is assigning different ranges to each instance to maximize compute distribution, each instance has a unique and different name.

-Each range is being read in parallel and its progress is maintained separately from other ranges in the lease container through a *lease* document. The combination of the leases represents the current state of the change feed processor.

-## Implementing the change feed processor

-The change feed processor in .NET is currently only available for [latest version mode](change-feed-modes.md#latest-version-change-feed-mode). The point of entry is always the monitored container, from a `Container` instance you call `GetChangeFeedProcessorBuilder`:

-Where the first parameter is a distinct name that describes the goal of this processor and the second name is the delegate implementation that handles changes.

-An example of a delegate is:

-Afterwards, you define the compute instance name or unique identifier with `WithInstanceName`, which should be unique and different in each compute instance you're deploying, and finally, which is the container to maintain the lease state with `WithLeaseContainer`.

-1. If there are no changes, sleep for a predefined amount of time (customizable with `WithPollInterval` in the Builder) and go to #1.

-1. If there are changes, send them to the **delegate**.

-1. When the delegate finishes processing the changes **successfully**, update the lease store with the latest processed point in time and go to #1.

-The change feed processor is resilient to user code errors. If your delegate implementation has an unhandled exception (step #4), the thread processing that particular batch of changes stops, and a new thread is eventually created. The new thread checks the latest point in time the lease store has saved for that range of partition key values, and restarts from there, effectively sending the same batch of changes to the delegate. This behavior continues until your delegate processes the changes correctly and it's the reason the change feed processor has an "at least once" guarantee. Consuming the change feed in an Eventual consistency level can also result in duplicate events in-between subsequent change feed read operations. For example, the last event of one read operation could appear as the first event of the next operation.

-> There is only one scenario where a batch of changes will not be retried. If the failure happens on the first ever delegate execution, the lease store has no previous saved state to be used on the retry. On those cases, the retry would use the [initial starting configuration](#starting-time), which might or might not include the last batch.

-To prevent your change feed processor from getting "stuck" continuously retrying the same batch of changes, you should add logic in your delegate code to write documents, upon exception, to an errored-message queue. This design ensures that you can keep track of unprocessed changes while still being able to continue to process future changes. The errored-message queue might be another Azure Cosmos DB container. The exact data store doesn't matter, simply that the unprocessed changes are persisted.

-In addition, you can use the [change feed estimator](how-to-use-change-feed-estimator.md) to monitor the progress of your change feed processor instances as they read the change feed or use the [life cycle notifications](#life-cycle-notifications) to detect underlying failures.

-## Life-cycle notifications

-The change feed processor lets you hook to relevant events in its [life cycle](#processing-life-cycle), you can choose to be notified to one or all of them. The recommendation is to at least register the error notification:

-* Register a handler for `WithErrorNotification` to be notified when the current host encounters an exception during processing, being able to distinguish if the source is the user delegate (unhandled exception) or an error the processor is encountering trying to access the monitored container (for example, networking issues).

-A single change feed processor deployment unit consists of one or more compute instances with the same `processorName` and lease container configuration but different instance name each. You can have many deployment units where each one has a different business flow for the changes and each deployment unit consisting of one or more instances.

-For example, you might have one deployment unit that triggers an external API anytime there's a change in your container. Another deployment unit might move data, in real time, each time there's a change. When a change happens in your monitored container, all your deployment units get notified.

-As mentioned before, within a deployment unit you can have one or more compute instances. To take advantage of the compute distribution within the deployment unit, the only key requirements are:

-* All instances should have the same `processorName`.

-If these three conditions apply, then the change feed processor distributes all the leases in the lease container across all running instances of that deployment unit and parallelizes compute using an equal distribution algorithm. A lease is owned by one instance at a given time, so the number of instances shouldn't be greater than the number of leases.

-The number of instances can grow and shrink, and the change feed processor will dynamically adjust the load by redistributing accordingly.

-Moreover, the change feed processor can dynamically adjust to containers scale due to throughput or storage increases. When your container grows, the change feed processor transparently handles these scenarios by dynamically increasing the leases and distributing the new leases among existing instances.

-By default, when a change feed processor starts the first time, it initializes the leases container, and start its [processing life cycle](#processing-life-cycle). Any changes that happened in the monitored container before the change feed processor is initialized for the first time aren't detected.

-It's possible to initialize the change feed processor to read changes starting at a **specific date and time**, by passing an instance of a `DateTime` to the `WithStartTime` builder extension:

-The change feed processor will be initialized for that specific date and time and start reading the changes that happened after.

-In other scenarios like data migrations or analyzing the entire history of a container, we need to read the change feed from **the beginning of that container's lifetime**. To do that, we can use `WithStartTime` on the builder extension, but passing `DateTime.MinValue.ToUniversalTime()`, which would generate the UTC representation of the minimum `DateTime` value, like so:

-The change feed processor will be initialized and start reading changes from the beginning of the lifetime of the container.

-> These customization options only work to setup the starting point in time of the change feed processor. Once the leases container is initialized for the first time, changing them has no effect.

- [!code-java[](~/azure-cosmos-java-sql-api-samples/src/main/java/com/azure/cosmos/examples/changefeed/SampleChangeFeedProcessor.java?name=Delegate)]

->[!NOTE]

-> In the above we pass a variable `options` of type `ChangeFeedProcessorOptions`, which can be used to set various values including `setStartFromBeginning`:

-The delegate implementation for reading the change feed in [all versions and deletes mode](change-feed-modes.md#all-versions-and-deletes-change-feed-mode-preview) is similar, but instead of calling `.handleChanges()` you call `.handleAllVersionsAndDeletesChanges()`. All versions and deletes mode is in preview and is available in Java SDK version >= `4.42.0`. An example is:

- [!code-java[](~/azure-cosmos-java-sql-api-samples/src/main/java/com/azure/cosmos/examples/changefeed/SampleChangeFeedProcessorForAllVersionsAndDeletesMode.java?name=Delegate)]

-

-In either change feed mode, you can assign this to a `changeFeedProcessorInstance`, passing parameters of compute instance name (`hostName`), the monitored container (here called `feedContainer`) and the `leaseContainer`. We then start the change feed processor:

- [!code-java[](~/azure-cosmos-java-sql-api-samples/src/main/java/com/azure/cosmos/examples/changefeed/SampleChangeFeedProcessor.java?name=StartChangeFeedProcessor)]

-> The above code snippets are taken from samples in GitHub. You can find the sample for [latest version mode here](https://github.com/Azure-Samples/azure-cosmos-java-sql-api-samples/blob/main/src/main/java/com/azure/cosmos/examples/changefeed/SampleChangeFeedProcessor.java) or [all versions and deletes mode here](https://github.com/Azure-Samples/azure-cosmos-java-sql-api-samples/blob/main/src/main/java/com/azure/cosmos/examples/changefeed/SampleChangeFeedProcessorForAllVersionsAndDeletesMode.java).

-1. If there are no changes, sleep for a predefined amount of time (customizable with `options.setFeedPollDelay` in the Builder) and go to #1.

-1. If there are changes, send them to the **delegate**.

-1. When the delegate finishes processing the changes **successfully**, update the lease store with the latest processed point in time and go to #1.

-The change feed processor is resilient to user code errors. If your delegate implementation has an unhandled exception (step #4), the thread processing that particular batch of changes is stopped, and a new thread is created. The new thread checks the latest point in time the lease store has saved for that range of partition key values, and restart from there, effectively sending the same batch of changes to the delegate. This behavior continues until your delegate processes the changes correctly and it's the reason the change feed processor has an "at least once" guarantee. Consuming the change feed in an Eventual consistency level can also result in duplicate events in-between subsequent change feed read operations. For example, the last event of one read operation could appear as the first event of the next operation.

-> There is only one scenario where a batch of changes will not be retried. If the failure happens on the first ever delegate execution, the lease store has no previous saved state to be used on the retry. On those cases, the retry would use the [initial starting configuration](#starting-time), which might or might not include the last batch.

-To prevent your change feed processor from getting "stuck" continuously retrying the same batch of changes, you should add logic in your delegate code to write documents, upon exception, to an errored-message. This design ensures that you can keep track of unprocessed changes while still being able to continue to process future changes. The errored-message might be another Azure Cosmos DB container. The exact data store doesn't matter, simply that the unprocessed changes are persisted.

-In addition, you can use the [change feed estimator](how-to-use-change-feed-estimator.md) to monitor the progress of your change feed processor instances as they read the change feed.

-A single change feed processor deployment unit consists of one or more compute instances with the same lease container configuration, the same `leasePrefix`, but different `hostName` name each. You can have many deployment units where each one has a different business flow for the changes and each deployment unit consisting of one or more instances.

-For example, you might have one deployment unit that triggers an external API anytime there's a change in your container. Another deployment unit might move data, in real time, each time there's a change. When a change happens in your monitored container, all your deployment units get notified.

-As mentioned before, within a deployment unit you can have one or more compute instances. To take advantage of the compute distribution within the deployment unit, the only key requirements are:

-If these three conditions apply, then the change feed processor distributes all the leases in the lease container across all running instances of that deployment unit and parallelizes compute using an equal distribution algorithm. A lease is owned by one instance at a given time, so the number of instances shouldn't be greater than the number of leases.

-The number of instances can grow and shrink, and the change feed processor will dynamically adjust the load by redistributing accordingly. Deployment units can share the same lease container, but they should each have a different `leasePrefix`.

-Moreover, the change feed processor can dynamically adjust to containers scale due to throughput or storage increases. When your container grows, the change feed processor transparently handles these scenarios by dynamically increasing the leases and distributing the new leases among existing instances.

-By default, when a change feed processor starts the first time, it initializes the leases container, and start its [processing life cycle](#processing-life-cycle). Any changes that happened in the monitored container before the change feed processor was initialized for the first time won't be detected.

-> Modifying the starting time of the change feed processor is not available when you are using [all versions and deletes mode](change-feed-modes.md#all-versions-and-deletes-change-feed-mode-preview). Currently, you must use the default start time.

-It's possible to initialize the change feed processor to read changes starting at a **specific date and time**, by setting `setStartTime` in `options`. The change feed processor will be initialized for that specific date and time and start reading the changes that happened after.

-In our sample, we set `setStartFromBeginning` to `false`, which is the same as the default value. In other scenarios like data migrations or analyzing the entire history of a container, we need to read the change feed from **the beginning of that container's lifetime**. To do that, we can set `setStartFromBeginning` to `true`. The change feed processor will be initialized and start reading changes from the beginning of the lifetime of the container.

-> These customization options only work to setup the starting point in time of the change feed processor. Once the leases container is initialized for the first time, changing them has no effect.

-Change feed read operations on the monitored container consume [request units](../request-units.md). Make sure your monitored container isn't experiencing [throttling](troubleshoot-request-rate-too-large.md), it adds delays in receiving change feed events on your processors.

-Operations on the lease container (updating and maintaining state) consume [request units](../request-units.md). The higher the number of instances using the same lease container, the higher the potential request units consumption is. Make sure your lease container isn't experiencing [throttling](troubleshoot-request-rate-too-large.md), it adds delays in receiving change feed events and can even stop processing completely.

-## Sharing the lease container

-You can share the lease container across multiple [deployment units](#deployment-unit), each deployment unit would be listening to a different monitored container or have a different `processorName`. With this configuration, each deployment unit would maintain an independent state on the lease container. Review the [request unit consumption on the lease container](#change-feed-and-provisioned-throughput) to make sure the provisioned throughput is enough for all the deployment units.

-There are three key configurations that can affect the change feed processor behavior, in all cases, they'll affect the [request unit consumption on the lease container](#change-feed-and-provisioned-throughput). These configurations can be changed during the creation of the change feed processor but should be used carefully:

-* Lease Acquire: By default every 17 seconds. A host will periodically check the state of the lease store and consider acquiring leases as part of the [dynamic scaling](#dynamic-scaling) process. This process is done by executing a Query on the lease container. Reducing this value makes rebalancing and acquiring leases faster but increase [request unit consumption on the lease container](#change-feed-and-provisioned-throughput).

-* Lease Expiration: By default 60 seconds. Defines the maximum amount of time that a lease can exist without any renewal activity before it's acquired by another host. When a host crashes, the leases it owned will be picked up by other hosts after this period of time plus the configured renewal interval. Reducing this value will make recovering after a host crash faster, but the expiration value should never be lower than the renewal interval.

-* Lease Renewal: By default every 13 seconds. A host owning a lease will periodically renew it even if there are no new changes to consume. This process is done by executing a Replace on the lease. Reducing this value lowers the time required to detect leases lost by host crashing but increase [request unit consumption on the lease container](#change-feed-and-provisioned-throughput).

-The change feed processor can be hosted in any platform that supports long running processes or tasks:

-* A continuous running [Azure WebJob](/training/modules/run-web-app-background-task-with-webjobs/).

-* A process in an [Azure Virtual Machine](/azure/architecture/best-practices/background-jobs#azure-virtual-machines).

-* A background job in [Azure Kubernetes Service](/azure/architecture/best-practices/background-jobs#azure-kubernetes-service).

-* A serverless function in [Azure Functions](/azure/architecture/best-practices/background-jobs#azure-functions).

-* An [ASP.NET hosted service](/aspnet/core/fundamentals/host/hosted-services).

-While change feed processor can run in short lived environments because the lease container maintains the state, the startup cycle of these environments adds delay to receiving the notifications (due to the overhead of starting the processor every time the environment is started).

-You can now proceed to learn more about change feed processor in the following articles:

-* [Using the change feed estimator](how-to-use-change-feed-estimator.md)

-description: Learn how to use the Azure Cosmos DB change feed pull model to read the change feed and the differences between the pull model and Change Feed Processor

-With the change feed pull model, you can consume the Azure Cosmos DB change feed at your own pace. Similar to the [change feed processor](change-feed-processor.md), you can use the change feed pull model to parallelize the processing of changes across multiple change feed consumers.

-## Comparing with change feed processor

-Many scenarios can process the change feed using either the [change feed processor](change-feed-processor.md) or the pull model. The pull model's continuation tokens and the change feed processor's lease container are both "bookmarks" for the last processed item, or batch of items, in the change feed.

-However, you can't convert continuation tokens to a lease (or vice versa).

-> In most cases when you need to read from the change feed, the simplest option is to use the [change feed processor](change-feed-processor.md).

-Here's some key differences between the change feed processor and pull model:

-|Feature | Change feed processor| Pull model |

-| Keeping track of current point in processing change feed | Lease (stored in an Azure Cosmos DB container) | Continuation token (stored in memory or manually persisted) |

-| Polling for future changes | Automatically checks for changes based on user-specified `WithPollInterval` | Manual |

-| Behavior where there are no new changes | Automatically wait `WithPollInterval` and recheck | Must check status and manually recheck |

-| Process changes from entire container | Yes, and automatically parallelized across multiple threads/machines consuming from the same container| Yes, and manually parallelized using FeedRange |

-| Process changes from just a single partition key | Not supported | Yes|

-> Unlike when reading using the change feed processor, you must explicitly handle cases where there are no new changes.

-## Working with the pull model

-To process the change feed using the pull model, create a `FeedIterator`. When you initially create a `FeedIterator`, you must specify a required `ChangeFeedStartFrom` value, which consists of both the starting position for reading changes and the desired `FeedRange`. The `FeedRange` is a range of partition key values and specifies the items that can be read from the change feed using that specific `FeedIterator`. You must also specify a required `ChangeFeedMode` value for the mode in which you want to process changes: [latest version](change-feed-modes.md#latest-version-change-feed-mode) or [all versions and deletes](change-feed-modes.md#all-versions-and-deletes-change-feed-mode-preview). Use either `ChangeFeedMode.LatestVersion` or `ChangeFeedMode.AllVersionsAndDeletes` to indicate which mode you want to read change feed in. When using all versions and deletes mode, you must select a change feed start from value of either `Now()` or from a specific continuation token.

-You can optionally specify `ChangeFeedRequestOptions` to set a `PageSizeHint`. When set, this property sets the maximum number of items received per page. If operations in the monitored collection are performed through stored procedures, transaction scope is preserved when reading items from the change feed. As a result, the number of items received could be higher than the specified value so that the items changed by the same transaction are returned as part of one atomic batch.

-Here's an example for obtaining a `FeedIterator` in latest version mode that returns entity objects, in this case a `User` object:

-All versions and deletes mode is in preview and can be used with preview .NET SDK versions >= `3.32.0-preview`. Here's an example for obtaining a `FeedIterator` in all versions and deletes mode that returns dynamic objects:

-> [!Note]

-> In latest version mode, you will receive objects that represent the item that changed with some [extra metadata](change-feed-modes.md#parsing-the-response-object). All versions and deletes mode returns a different data model, and you can find more information [here](change-feed-modes.md#parsing-the-response-object-1).

-### Consuming the change feed with streams

-The `FeedIterator` for both change feed modes comes in two flavors. In addition to the examples that return entity objects, you can also obtain the response with `Stream` support. Streams allow you to read data without having it first deserialized, saving on client resources.

-Here's an example for obtaining a `FeedIterator` in latest version mode that returns a `Stream`:

-### Consuming an entire container's changes

-If you don't supply a `FeedRange` to a `FeedIterator`, you can process an entire container's change feed at your own pace. Here's an example, which starts reading all changes starting at the current time using latest version mode:

-Because the change feed is effectively an infinite list of items encompassing all future writes and updates, the value of `HasMoreResults` is always true. When you try to read the change feed and there are no new changes available, you receive a response with `NotModified` status. In the above example, it's handled by waiting 5 seconds before rechecking for changes.

-### Consuming a partition key's changes

-In some cases, you may only want to process a specific partition key's changes. You can obtain a `FeedIterator` for a specific partition key and process the changes the same way that you can for an entire container.

-### Using FeedRange for parallelization

-Here's an example showing how to obtain a list of ranges for your container:

-When you obtain of list of FeedRanges for your container, you'll get one `FeedRange` per [physical partition](../partitioning-overview.md#physical-partitions).

-Using a `FeedRange`, you can then create a `FeedIterator` to parallelize the processing of the change feed across multiple machines or threads. Unlike the previous example that showed how to obtain a `FeedIterator` for the entire container or a single partition key, you can use FeedRanges to obtain multiple FeedIterators, which can process the change feed in parallel.

-In the case where you want to use FeedRanges, you need to have an orchestrator process that obtains FeedRanges and distributes them to those machines. This distribution could be:

-* Using `FeedRange.ToJsonString` and distributing this string value. The consumers can use this value with `FeedRange.FromJsonString`.

-* If the distribution is in-process, passing the `FeedRange` object reference.

-Here's a sample that shows how to read from the beginning of the container's change feed using two hypothetical separate machines that are reading in parallel:

-### Saving continuation tokens

-You can save the position of your `FeedIterator` by obtaining the continuation token. A continuation token is a string value that keeps of track of your FeedIterator's last processed changes and allows the `FeedIterator` to resume at this point later. The continuation token, if specified, takes precedence over the start time and start from beginning values. The following code reads through the change feed since container creation. After no more changes are available, it will persist a continuation token so that change feed consumption can be later resumed.

-As long as the Azure Cosmos DB container still exists, a FeedIterator's continuation token never expires.

-To process the change feed using the pull model, create a `Iterator<FeedResponse<JsonNode>> responseIterator`. When creating `CosmosChangeFeedRequestOptions`, you must specify where to start reading the change feed from and pass the desired `FeedRange`. The `FeedRange` is a range of partition key values that specifies the items that can be read from the change feed.

-If you want to read the change feed in [all versions and deletes mode](change-feed-modes.md#all-versions-and-deletes-change-feed-mode-preview), you must also specify `allVersionsAndDeletes()` when creating the `CosmosChangeFeedRequestOptions`. All versions and deletes mode doesn't support processing the change feed from the beginning or from a point in time. You must either process changes from now or from a continuation token. All versions and deletes mode is in preview and is available in Java SDK version >= `4.42.0`.

-### Consuming an entire container's changes

-If you specify `FeedRange.forFullRange()`, you can process an entire container's change feed at your own pace. You can optionally specify a value in `byPage()`. When set, this property sets the maximum number of items received per page.

-> All of the below code snippets are taken from a samples in GitHub. You can find the latest version mode sample [here](https://github.com/Azure-Samples/azure-cosmos-java-sql-api-samples/blob/main/src/main/java/com/azure/cosmos/examples/changefeedpull/SampleChangeFeedPullModel.java) and the all versions and deletes mode sample [here](https://github.com/Azure-Samples/azure-cosmos-java-sql-api-samples/blob/main/src/main/java/com/azure/cosmos/examples/changefeedpull/SampleChangeFeedPullModelForAllVersionsAndDeletesMode.java).

-Here is an example for obtaining a `responseIterator` in latest version mode:

- [!code-java[](~/azure-cosmos-java-sql-api-samples/src/main/java/com/azure/cosmos/examples/changefeedpull/SampleChangeFeedPullModel.java?name=FeedResponseIterator)]

-Here is an example for obtaining a `responseIterator` in all versions and deletes mode:

- [!code-java[](~/azure-cosmos-java-sql-api-samples/src/main/java/com/azure/cosmos/examples/changefeedpull/SampleChangeFeedPullModelForAllVersionsAndDeletesMode.java?name=FeedResponseIterator)]

-We can then iterate over the results. Because the change feed is effectively an infinite list of items encompassing all future writes and updates, the value of `responseIterator.hasNext()` is always true. Here is an example in latest version mode, which reads all changes starting from the beginning. Each iteration persists a continuation token after processing all events, and will pick up from the last processed point in the change feed. This is handled using `createForProcessingFromContinuation`:

- [!code-java[](~/azure-cosmos-java-sql-api-samples/src/main/java/com/azure/cosmos/examples/changefeedpull/SampleChangeFeedPullModel.java?name=AllFeedRanges)]

-### Consuming a partition key's changes

-In some cases, you may only want to process a specific partition key's changes. You can process the changes for a specific partition key in the same way that you can for an entire container. Here's an example using latest version mode:

- [!code-java[](~/azure-cosmos-java-sql-api-samples/src/main/java/com/azure/cosmos/examples/changefeedpull/SampleChangeFeedPullModel.java?name=PartitionKeyProcessing)]

-### Using FeedRange for parallelization

-Here's an example using latest version mode showing how to obtain a list of ranges for your container:

- [!code-java[](~/azure-cosmos-java-sql-api-samples/src/main/java/com/azure/cosmos/examples/changefeedpull/SampleChangeFeedPullModel.java?name=GetFeedRanges)]

-Using a `FeedRange`, you can then parallelize the processing of the change feed across multiple machines or threads. Unlike the previous example that showed how to process changes for the entire container or a single partition key, you can use FeedRanges to process the change feed in parallel.

-In the case where you want to use FeedRanges, you need to have an orchestrator process that obtains FeedRanges and distributes them to those machines. This distribution could be:

-* Using `FeedRange.toString()` and distributing this string value.

-* If the distribution is in-process, passing the `FeedRange` object reference.

-Here's a sample using latest version mode that shows how to read from the beginning of the container's change feed using two hypothetical separate machines that are reading in parallel:

- [!code-java[](~/azure-cosmos-java-sql-api-samples/src/main/java/com/azure/cosmos/examples/changefeedpull/SampleChangeFeedPullModel.java?name=Machine1)]

- [!code-java[](~/azure-cosmos-java-sql-api-samples/src/main/java/com/azure/cosmos/examples/changefeedpull/SampleChangeFeedPullModel.java?name=Machine2)]

-* [Overview of change feed](../change-feed.md)

-* [Using the change feed processor](change-feed-processor.md)

-* [Trigger Azure Functions](change-feed-functions.md)

-1. To handle the changes, you no longer need an implementation of `IChangeFeedObserver`, instead you need to [define a delegate](change-feed-processor.md#implementing-the-change-feed-processor). The delegate can be a static Function or, if you need to maintain state across executions, you can create your own class and pass an instance method as delegate.

-description: Efficiently query a base container with predefined filters using Materialized views for Azure Cosmos DB for NoSQL.

-> The materialized view feature of Azure Cosmos DB for NoSQL is currently in preview. You can enable this feature using the Azure portal. This preview is provided without a service-level agreement. At this time, materialized views are not recommended for production workloads. Certain features of this preview may not be supported or may have constrained capabilities. For more information, see [supplemental terms of use for Microsoft Azure previews](https://azure.microsoft.com/support/legal/preview-supplemental-terms/).

-Many times applications are required to make queries that don't specify the partition key. In these cases, the queries could scan through all data for a small result set. The queries end up being expensive as they end up inadvertently executing as a cross-partition query.

-Materialized views, when defined, help provide a means to efficiently query a base container in Azure Cosmos DB with filters that don't include the partition key. When users write to the base container, the materialized view is built automatically in the background. This view can have a different partition key for efficient lookups. The view also only contains fields explicitly projected from the base container. This view is a read-only table.

-Materialized views have many benefits that include, but aren't limited to:

-Use the Azure CLI to enable the materialized views feature either with a native command or a REST API operation on your Cosmos DB for NoSQL account.

-1. Navigate to your API for NOSQL account.

-1. Sign-in to the Azure CLI.

- > [!NOTE]

- > For more information on installing the Azure CLI, see [how to install the Azure CLI](/cli/azure/install-azure-cli).

- # Variable for Subscription

-1. Create a new JSON file named **capabilities.json** with the capabilities manifest.

-1. Enable the preview materialized views feature for the account using the REST API and [`az rest`](/cli/azure/reference-index#az-rest) with an HTTP `PATCH` verb.

-1. Navigate to your API for NoSQL account.

-1. On the **Materialized Views Builder** page, configure the SKU and number of instances for the builder.

- > [!NOTE]

- > This resource menu option and page will only appear when the Materialized Views feature is enabled for the account.

-1. Create a new JSON file named **builder.json** with the builder manifest.

-1. Enable the materialized views builder for the account using the REST API and `az rest` with an HTTP `PUT` verb.

-1. Wait for a couple of minutes and check the status using `az rest` again with the HTTP `GET` verb. The status in the output should now be `Running`:

-You get the flexibility to configure the view builder's compute instances based on your latency and lag requirements to hydrate the views. From a technical stand point, this compute layer helps manage connections between partitions in a more efficient manner even when the data size is large and the number of partitions is high.

-The compute containers are shared among all materialized views within an Azure Cosmos DB account. Each provisioned compute container spawns off multiple tasks that read the change feed from base container partitions and writes data to the target materialized view\[s\]. The compute container transforms the data per the materialized view definition for each materialized view in the account.

-Once your account and Materialized View Builder is set up, you should be able to create Materialized views using REST API.

-1. Use the Azure portal, Azure SDK, Azure CLI, or REST API to create a source container with `/accountId` as the partition key path. Name this source container **mv-src**.

- > [!NOTE]

- > `/accountId` is only used as an example in this article. For your own containers, select a partition key that works for your solution.

-1. Insert a few items in the source container. To better understand this Getting Started, make sure that the items mandatorily have `accountId`, `fullName`, and `emailAddress` fields. A sample item could look like this:

- > [!NOTE]

- > In this example, you populate the source container with sample data. You can also create a materialized view from an empty source container.

-1. Now, create a materialized view named **mv-target** with a partition key path that is different from the source container. For this example, specify `/emailAddress` as the partition key path for the **mv-target** container.

- 1. First, we create a definition manifest for a materialized view and save it in a JSON file named **definition.json**.

- > [!NOTE]

- > In the template, notice that the partitionKey path is set as `/emailAddress`. We also have more parameters to specify the source collection and the definition to populate the materialized view.

-1. Now, make a REST API call to create the materialized view as defined in the **mv_definition.json** file. Use the Azure CLI to make the REST API call.

- 1. Create a variable for the name of the materialized view and source database name.

- 1. Make a REST API call to create the materialized view.

- 1. Check the status of the materialized view container creation using the REST API:

-Once the materialized view is created, the materialized view container automatically syncs changes with the source container. Try executing CRUD operations in the source container and observe the same changes in the mv container.

-> Materialized View containers are read-only container for the end-user so they can only be modified automatically by the Materialized View Builders.

-There are a few limitations with the Cosmos DB NoSQL API Materialized View Feature while in preview:

-In addition to the above limitations, consider the following extra limitations:

- - Materialized views can't be enabled on an account that has availability zone enabled regions.

- - Adding a new region with an availability zone isn't supported once `enableMaterializedViews` is set to `true` on the account.

- - Materialized views aren't automatically restored with the restore process. You'll need to re-create the materialized views after the restore process is complete. Then, you should configure `enableMaterializedViews` on their restored account before creating the materialized views and builders again.

-|`FeedOptions.PartitionKeyRangeId`|Removed. Same outcome can be obtained from using [FeedRange](change-feed-pull-model.md#using-feedrange-for-parallelization) as input to the query method.|

-|`ChangeFeedOptions.PartitionKeyRangeId`|`FeedRange` - In order to achieve parallelism reading the change feed [FeedRanges](change-feed-pull-model.md#using-feedrange-for-parallelization) can be used. It's no longer a required parameter, you can [read the Change Feed for an entire container](change-feed-pull-model.md#consuming-an-entire-containers-changes) easily now.|

-|`ChangeFeedOptions.PartitionKey`|`FeedRange.FromPartitionKey` - A FeedRange representing the desired Partition Key can be used to [read the Change Feed for that Partition Key value](change-feed-pull-model.md#consuming-a-partition-keys-changes).|

-|`ChangeFeedOptions.RequestContinuation`|`ChangeFeedStartFrom.Continuation` - The change feed iterator can be stopped and resumed at any time by [saving the continuation and using it when creating a new iterator](change-feed-pull-model.md#saving-continuation-tokens).|

-|`ChangeFeedOptions.MaxItemCount`|`ChangeFeedRequestOptions.PageSizeHint` - The change feed iterator can be stopped and resumed at any time by [saving the continuation and using it when creating a new iterator](change-feed-pull-model.md#saving-continuation-tokens).|

-|`IDocumentQuery.HasMoreResults` |`response.StatusCode == HttpStatusCode.NotModified` - The change feed is conceptually infinite, so there could always be more results. When a response contains the `HttpStatusCode.NotModified` status code, it means there are no new changes to read at this time. You can use that to stop and [save the continuation](change-feed-pull-model.md#saving-continuation-tokens) or to temporarily sleep or wait and then call `ReadNextAsync` again to test for new changes. |

-Computed properties in Azure Cosmos DB have values derived from existing item properties but aren't persisted in items themselves. These properties are scoped to a single item and can be referenced in queries as if they were persisted properties. Computed properties make it easier to write complex query logic once and reference it many times. You can add a single index on these properties or use them as part of a composite index for increased performance.

-> [!Note]

-> Do you have any feedback about computed properties? We want to hear it! Feel free to share feedback directly with the Azure Cosmos DB engineering team: cosmoscomputedprops@microsoft.com

-## Computed property definition

-It's strongly recommended that computed properties are named in such a way that there's no collision with a persisted property name. To avoid overlapping property names, you can add a prefix or suffix to all computed property names. This article uses the prefix `cp_` in all name definitions.

-> Defining a computed property with the same name as a persisted property won't give an error, but it may lead to unexpected behavior.

-> Regardless of whether the computed property is indexed, values from persisted properties that share a name with a computed property won't be included in the index.

-> Queries will always use the computed property instead of the persisted property, with the exception of the persisted property being returned instead of the computed property if there is a wildcard projection in the SELECT clause.

-> This is because wildcard projection does not automatically include computed properties.

-## Creating computed properties

-During the preview, computed properties must be created using the .NET v3 or Java v4 SDK. Once the computed properties have been created, you can execute queries that reference them using any method including all SDKs and Data Explorer in the Azure portal.

-|**SDK** |**Supported version** |**Notes** |

-|.NET SDK v3 |>= [3.34.0-preview](https://www.nuget.org/packages/Microsoft.Azure.Cosmos/3.34.0-preview) |Computed properties are currently only available in preview package versions. |

-|Java SDK v4 |>= [4.46.0](https://mvnrepository.com/artifact/com.azure/azure-cosmos/4.46.0) |Computed properties are currently under preview version. |

-### Create computed properties using the SDK

-You can either create a new container with computed properties defined, or add them to an existing container.

- // Update container with changes

-// Update container with changes

-> Every time you update container properties, the old values are overwritten.

-> If you have existing computed properties and want to add new ones, ensure you add both new and existing computed properties to the collection.

-## Using computed properties in queries

-Computed properties can be referenced in queries the same way as persisted properties. Values for computed properties that aren't indexed are evaluated during runtime using the computed property definition. If a computed property is indexed, the index is used in the same way as it is for persisted properties, and the computed property is evaluated on an as needed basis. It's recommended you [add indexes on your computed properties](#indexing-computed-properties) for the best cost and performance.

-These examples use the quickstart products dataset in [Data Explorer](../../data-explorer.md). Launch the quick start to get started and load the dataset in a new container.

-Here's a sample item:

-If computed properties need to be projected, they must be explicitly referenced. Wildcard projections like `SELECT *` return all persisted properties, but don't include computed properties.

-Let's take an example computed property definition to convert the property `name` to lowercase.

-This property could then be projected in a query.

-Computed properties can be referenced in filter predicates like any persisted properties. It's recommended to add any relevant single or composite indexes when using computed properties in filters.

-Let's take an example computed property definition to calculate a 20 percent price discount.

-This property could then be filtered on to ensure that only products where the discount would be less than $50 are returned.

-Let's take an example computed property definition that finds the primary category for each item from the `categoryName` property.

-You can then group by `cp_primaryCategory` to get the count of items in each primary category.

-> While you could also achieve this query without using computed properties, using the computed properties greatly simplifies writing the query and allows for increased performance because `cp_primaryCategory` can be indexed. Both [SUBSTRING()](./substring.md) and [INDEX_OF()](./index-of.md) require a [full scan](../../index-overview.md#index-usage) of all items in the container, but if you index the computed property then the entire query can be served from the index instead. The ability to serve the query from the index instead of relying on a full scan increases performance and lowers query RU costs.

-As with persisted properties, computed properties can be referenced in the ORDER BY clause and need to be indexed for the query to succeed. Using computed properties, you can ORDER BY the result of complex logic or system functions, which opens up many new query scenarios using Azure Cosmos DB.

-Let's take an example computed property definition that gets the month out of the `_ts` value.

-Before you can ORDER BY `cp_monthUpdated`, you must add it to your indexing policy. Once your indexing policy is updated, you can order by the computed property.

-## Indexing computed properties

-Computed properties aren't indexed by default and aren't covered by wildcard paths in the [indexing policy](../../index-policy.md). You can add single or composite indexes on computed properties in the indexing policy the same way you would add indexes on persisted properties. It's recommended to add relevant indexes to all computed properties as they're most beneficial in increasing performance and reducing RUs when they're indexed. When computed properties are indexed, actual values are evaluated during item write operations to generate and persist index terms.

-There are a few considerations for indexing computed properties including:

-> All computed properties are defined at the top level of the item so the path is always `/<computed property name>`.

-Add a single index for a computed property named `cp_myComputedProperty`.

-Add a composite index on two properties where one is computed, `cp_myComputedProperty`, and the other is persisted `myPersistedProperty`.

-## RU consumption

-Adding computed properties to a container does not consume RUs. Write operations on containers that have computed properties defined may see a slight RU increase. If a computed property is indexed, RUs on write operations will increase to reflect the costs for indexing and evaluation of computed property. While in preview, RU charges related to computed properties are subject to change.

-The [change feed pull model](change-feed-pull-model.md) allows you to consume the change feed at your own pace. Changes must be requested by the client and there's no automatic polling for changes. If you want to permanently "bookmark" the last processed change (similar to the push model's lease container), you'll need to [save a continuation token](change-feed-pull-model.md#saving-continuation-tokens).

-* The item is being updated. The change feed can contain multiple operations for the same item. If the item is receiving updates, it can pick up multiple events (one for each update). One easy way to distinguish among different operations for the same item is to track the `_lsn` [property for each change](change-feed-modes.md#parsing-the-response-object). If the properties don't match, the changes are different.

-description: Restore a deleted container or database to a specific point in time in the same Azure Cosmos DB account.

-# Restoring deleted databases/containers in the same account with continuous backup in Azure Cosmos DB (preview)

-The same account restore capability of continuous backup in Azure Cosmos DB allows you to restore the deleted databases or containers within the same existing account. You can perform this restore operation using the [Azure portal](how-to-restore-in-account-continuous-backup.md?tabs=azure-portal&pivots=api-nosql), [Azure CLI](how-to-restore-in-account-continuous-backup.md?tabs=azure-cli&pivots=api-nosql), or [Azure PowerShell](how-to-restore-in-account-continuous-backup.md?tabs=azure-powershell&pivots=api-nosql). This feature helps in recovering the data from accidental deletions of databases or containers.

-You can choose to restore any combination of deleted provisioned throughput containers or shared throughput databases. The specified databases or containers are restored in all the regions present in the account when the restore operation was started. The duration of restoration depends on the amount of data that needs to be restored and the regions where the account is present. Since a parent database must be present before a container can be restored, the database restoration must be done first before restoring the child container.

-For more information on what continuous backup does and doesn't restore, see the [continuous backup introduction](continuous-backup-restore-introduction.md).

-> When the deleted databases or containers are restored within the same account, those resource should be treated as new resources. Existing session or continuation tokens in use from your client applications will become invalid. It is recommended to refresh the locally stored session and continuations tokens before performing further reads or writes on the newly restored resources. Also, It is recommended to restart SDK clients to automatically refresh session and continuations tokens stored in the SDK cache.

-If your application listens to change feed events on the restored database or containers, it should restart the change feed from the beginning after a restore operation. The restored resource will only have the change feed events starting from the lifetime of the resource after restore. All change feed events before the deletion of the resource aren't propagated to the change feed. Similarly, it's also recommended to restart query operations after a restore operation. Existing query operations may have generated continuation tokens, which now become invalid after a restoration operation.

-You can restrict the restore permissions for a continuous backup account to a specific role or principal. For more information on permissions and how to assign them, see [continuous backup and restore permissions](continuous-backup-restore-permissions.md).

-## Understanding container instance identifiers

-When a deleted container gets restored within the same account, the restored container has the same name and resourceId of the original container that was previously deleted. To easily distinguish between the different versions of the container, use the `CollectionInstanceId` field. The `CollectionInstanceId` field differentiates between the different versions of a container. These versions include both the original container that was deleted and the newly restored container. The instance identifier is stored as part of the restore parameters in the restored container's resource definition. The original container, conversely doesn't have restore parameters defined in the resource definition of the container. Each later restored instance of a container has a unique instance identifier.

-| | Instance identifier |

-Azure Cosmos DB's point-in-time restore in same account feature helps you to recover from an accidental delete on a database or a container. This feature restores into any region, where backups existed, within the same account. The continuous backup mode allows you to restore to any point of time within the last 30 days or seven days depending on the configured tier.

-Let's consider two more scenarios:

-description: Learn more about Azure Cosmos DB Serverless performance.

-# Serverless performance

-Azure Cosmos DB Serverless resources have distinct performance characteristics that differ from those provided by provisioned throughput resources. Specifically, serverless containers do not offer any guarantees of predictable throughput or latency. However, the maximum capacity of a serverless container is determined by the data stored within it. We'll explore how this capacity varies with storage in the following section.

-## Changes in request units

-Azure Cosmos DB Serverless offers 5000 RU/s for a container. However, if your workload increases beyond 250 GB or more than five physical partitions, whichever is earlier, then the request units grow linearly with number of underlying physical partitions created in the container. Beyond 5 physical partitions, with every addition of a new physical partition, 1000 RU/s are added to the container's maximum throughput capacity.

-To understand request unit growth with storage, lets look at the table below.

-|::|::|::|::|

-|<=50 GB | 1 | 5000 | 5000 |

-|<=100 GB | 2 | 5000 | 2500 |

-|<=150 GB | 3 | 5000 | 1666 |

-|<=200 GB | 4 | 5000 | 1250 |

-|<=250 GB | 5 | 5000 | 1000 |

-|<=300 GB | 6 | 6000 | 1000 |

-|<=350 GB | 7 | 7000 | 1000 |

-|<=400 GB | 8 | 8000 | 1000 |

-|<= 1 TB | 20 | 20000| 1000 |

-The request units can increase beyond 20000 RU/s for a serverless container if more than 20 partitions are created in the container. It depends on the distribution of logical partition keys in your serverless container.

-> These numbers represent the maximum RU/sec capacity available to a serverless container. However, it's important to note that there are no assurances of predictable throughput or latency. If your container requires such guarantees, it's recommended to use provisioned throughput.

-description: Learn how to use Azure Cosmos DB in a consumption-based manner with the serverless feature and compare it to provisioned throughput.

-# Azure Cosmos DB serverless

-The Azure Cosmos DB serverless offering lets you use your Azure Cosmos DB account in a consumption-based fashion. With serverless, you're only charged for the Request Units (RUs) consumed by your database operations and the storage consumed by your data. Serverless containers can serve thousands of requests per second with no minimum charge and no capacity planning required.

-Every database operation in Azure Cosmos DB has a cost expressed in [Request Units (RUs)](request-units.md). How you're charged for this cost depends on the type of Azure Cosmos DB account you're using:

-## Use-cases

-Azure Cosmos DB serverless best fits scenarios where you expect **intermittent and unpredictable traffic** with long idle times. Because provisioning capacity in such situations isn't required and may be cost-prohibitive, Azure Cosmos DB serverless should be considered in the following use-cases:

- - Bursty, intermittent traffic that is hard to forecast, or

- - Low (<10%) average-to-peak traffic ratio

-For more information, see [choosing between provisioned throughput and serverless](throughput-serverless.md).

-## Using serverless resources

-Serverless is a new Azure Cosmos DB account type, which means that you have to choose between **provisioned throughput** and **serverless** when creating a new account. You must create a new serverless account to get started with serverless. Migrating existing accounts to/from serverless mode isn't currently supported.

-Any container that is created in a serverless account is a serverless container. Serverless containers expose the same capabilities as containers created in provisioned throughput mode, so you read, write and query your data the exact same way. However serverless accounts and containers also have specific characteristics:

- - You can't pass any throughput when creating a serverless container and doing so returns an error.

- - You can't read or update the throughput on a serverless container and doing so returns an error.

- - You can't create a shared throughput database in a serverless account and doing so returns an error.

-## Monitoring your consumption

-If you have used Azure Cosmos DB in provisioned throughput mode before, you find serverless is more cost-effective when your traffic doesn't justify provisioned capacity. The trade-off is that your costs become less predictable because you're billed based on the number of requests your database has processed. Because of the lack of predictability, it's important to keep an eye on your current consumption.

-When browsing the **Metrics** pane of your account, you find a chart named **Request Units consumed** under the **Overview** tab. This chart shows how many Request Units your account has consumed:

-You can find the same chart when using Azure Monitor, as described [here](monitor-request-unit-usage.md). Azure Monitor enables the ability to configure [alerts](../azure-monitor/alerts/alerts-metric-overview.md), which can be used to notify you when your Request Unit consumption has passed a certain threshold.

-Get started with serverless with the following articles:

-| Table action | Tells ADF what to do with the target Delta table in your sink. You can leave it as-is and append new rows, overwrite the existing table definition and data with new metadata and data, or keep the existing table structure but first truncate all rows, then insert the new rows. | no | None, Truncate, Overwrite | truncate, overwrite |

-| Required roles and permissions (subscription-level): | [Contributor](../role-based-access-control/built-in-roles.md#contributor) or [Security Admin](../role-based-access-control/built-in-roles.md#security-admin) | [Owner](../role-based-access-control/built-in-roles.md#owner) |

- > [!IMPORTANT]

- > Baselines and scan history are not migrated.

-

-Defender for Servers offers two plan options that offer different levels of protection and their own cost. You can learn more about Defender for Clouds pricing on [the pricing page](https://azure.microsoft.com/pricing/details/defender-for-cloud/).

-You can enable the Defender for Servers plan on your Azure subscription, AWS account or GCP project to protect all of your resources within that subscription on the Environment settings page.

-**To Enable the Defender for Servers plan**:

-When you enable the Defender for Servers plan, you're then given the option to select which plan you want to enable. There are two plans you can choose from that offer different levels of protections for your resources.

-You can compare what's included in [each plan](plan-defender-for-servers-select-plan.md#plan-features).

-1. Select the relevant Azure subscription, AWS account or GCP project.

-|`-i <INCLUDE>`, `--include <INCLUDE>` | The path to a file that contains the devices and subnet masks you want to include, where `<INCLUDE>` is the path to the file. |

-|`-x EXCLUDE`, `--exclude EXCLUDE` | The path to a file that contains the devices and subnet masks you want to exclude, where `<EXCLUDE>` is the path to the file. |

- Create another desktop session, manually clear the cache for the windowing library, and then restart.

- - [SET_USER_ID](https://dev.mysql.com/doc/refman/8.0/en/privileges-provided.html#priv_set-user-id)

-|Standard_E64ds_v4 | 64 | 504 | 48000 | 86016 | 2400 |

-|Standard_E64ads_v5 | 64 | 504 | 48000 | 86016 | 2400 |

-|Standard_E80ids_v4 | 80 | 504 | 48000 | 86016 | 2400 |

-The maximum IOPS are dependent on the maximum available IOPS per compute size. Refer to the column *Max uncached disk throughput: IOPS/MBps* in the [B-series](../../virtual-machines/sizes-b-series-burstable.md), [Ddsv4-series](../../virtual-machines/ddv4-ddsv4-series.md), and [Edsv4-series](../../virtual-machines/edv4-edsv4-series.md)/ [Edsv5-series](../../virtual-machines/edv5-edsv5-series.md)] documentation.

-To achieve high availability, SAP NetWeaver requires shared storage. GlusterFS is configured in a separate cluster and can be used by multiple SAP systems. Be aware that Red Hat is phasing out Red Hat Gluster Storage. The configuration will be supported for SAP on Azure until it reaches end of life stage as defined in [Red Hat Gluster Storage Life Cycle](https://access.redhat.com/support/policy/updates/rhs).

-[According to SAP over 87% of total global commerce is generated by SAP customers](https://www.sap.com/documents/2017/04/4666ecdd-b67c-0010-82c7-eda71af511fa.html) and more SAP systems are running in the cloud each year. The SAP platform provides a foundation for innovation for many companies and can handle various workloads natively. Explore our integration section further to learn how you can combine the Microsoft Azure ecosystem with your SAP workload to accelerate your business outcomes. Among the scenarios are extensions with Power Platform ("keep the ABAP core clean"), secured APIs with Azure API Management, automated business processes with Logic Apps, enriched experiences with SAP Business Technology Platform, uniform data blending dashboards with the Azure Data Platform and more.

-| [App Development and DevOps](#app-development-and-devops) | Apply best-in-class developer tooling to your SAP app developments and DevOps processes. |

-### App development and DevOps

-> - Support for Zone to Zone disaster recovery is currently limited to the following regions: Southeast Asia, East Asia, Japan East, Korea Central, Australia East, India Central, China North 3, UK South, West Europe, North Europe, Germany West Central, Norway East, France Central, Switzerland North, Sweden Central (Managed Access), South Africa North, Canada Central, US Gov Virginia, Central US, South Central US, East US, East US 2, West US 2, Brazil South, West US 3 and UAE North.

-> - Site Recovery does not move or store customer data out of the region in which it is deployed when the customer is using Zone to Zone Disaster Recovery. Customers may select a Recovery Services Vault from a different region if they so choose. The Recovery Services Vault contains metadata but no actual customer data.

-Typically, Availability Zones are used to deploy VMs in a High Availability configuration. They may be too close to each other to serve as a Disaster Recovery solution in case of natural disaster.

-While these are strong advantages, there is a possibility that Zone to Zone Disaster Recovery may fall short of resilience requirements in the event of a region-wide natural disaster.

-As mentioned above, Zone to Zone Disaster Recovery reduces complexity as it leverages redundant networking concepts across Availability Zones making configuration much simpler. The behavior of networking components in the Zone to Zone Disaster Recovery scenario is outlined below:

-The RTO SLA is the same as that for Site Recovery overall. We promise RTO of up to 2 hours. There is no defined SLA for RPO.

-The Site Recovery team and Azure capacity management team plan for sufficient infrastructure capacity. When you start a failover, the teams also help ensure VM instances that are protected by Site Recovery will deploy to the target zone. Check [here](./azure-to-azure-common-questions.md#capacity) for more FAQs on Capacity.

-To perform a Disaster Recovery drill, please follow the steps outlined [here](./azure-to-azure-tutorial-dr-drill.md).

-18.04 LTS |[9.54](https://support.microsoft.com/topic/update-rollup-67-for-azure-site-recovery-9fa97dbb-4539-4b6c-a0f8-c733875a119f)| 4.15.0-208-generic <br> 4.15.0-209-generic <br> 5.4.0-1105-azure <br> 5.4.0-1106-azure <br> 5.4.0-146-generic <br> 4.15.0-1163-azure <br> 4.15.0-1164-azure <br> 4.15.0-1165-azure <br> 4.15.0-210-generic <br> 4.15.0-211-generic <br> 5.4.0-1107-azure <br> 5.4.0-147-generic <br> 5.4.0-147-generic <br> 5.4.0-148-generic |

-20.04 LTS |[9.54](https://support.microsoft.com/topic/update-rollup-67-for-azure-site-recovery-9fa97dbb-4539-4b6c-a0f8-c733875a119f)| 5.15.0-1035-azure <br> 5.15.0-1036-azure <br> 5.15.0-69-generic <br> 5.4.0-1105-azure <br> 5.4.0-1106-azure <br> 5.4.0-146-generic <br> 5.4.0-147-generic <br> 5.15.0-1037-azure <br> 5.15.0-1038-azure <br> 5.15.0-70-generic <br> 5.15.0-71-generic <br> 5.15.0-72-generic <br> 5.4.0-1107-azure <br> 5.4.0-148-generic |

-22.04 LTS |[9.54](https://support.microsoft.com/topic/update-rollup-67-for-azure-site-recovery-9fa97dbb-4539-4b6c-a0f8-c733875a119f)| 5.15.0-1035-azure <br> 5.15.0-1036-azure <br> 5.15.0-69-generic <br> 5.15.0-70-generic <br> 5.15.0-1037-azure <br> 5.15.0-1038-azure <br> 5.15.0-71-generic <br> 5.15.0-72-generic |

-Debian 10 | [9.54](https://support.microsoft.com/topic/update-rollup-67-for-azure-site-recovery-9fa97dbb-4539-4b6c-a0f8-c733875a119f)| 5.10.0-0.bpo.3-amd64 <br> 5.10.0-0.bpo.3-cloud-amd64 <br> 5.10.0-0.bpo.4-amd64 <br> 5.10.0-0.bpo.4-cloud-amd64 <br> 5.10.0-0.bpo.5-amd64 <br> 5.10.0-0.bpo.5-cloud-amd64 <br> 4.19.0-24-amd64 <br> 4.19.0-24-cloud-amd64 <br> 5.10.0-0.deb10.22-amd64 <br> 5.10.0-0.deb10.22-cloud-amd64" |

-Stream Analytics clusters are billed by Streaming Units (SUs) which represent the amount of CPU and memory resources allocated to your cluster. A Streaming Unit is the same across Standard and Dedicated offerings. You can purchase from 36 to 396 SUs for each cluster, by increments of 36 (36, 72, 108...). A Stream Analytics cluster can serve as the streaming platform for your organization and can be shared by different teams working on various use cases.

-* Scale your cluster between 36 to 396 SUs as your streaming usage increases over time.

-If you don't want any patch installation to be orchestrated by Azure or aren't using custom patching solutions, you must change the patch orchestration option to **Customer Managed Schedules (Preview)** and don't associate a schedule/maintenance configuration to the machine. This will ensure that no patching is performed on the machine until you change it explicitly. For more information, see [User scenarios](prerequsite-for-schedule-patching.md#user-scenarios).

-> Service endpoint routes override any BGP or UDR routes for the address prefix match of an Azure service. For more information, see [troubleshooting with effective routes](diagnose-network-routing-problem.md).

-The Web Application Firewall's (WAF's) Log Scrubbing tool helps you remove sensitive data from your WAF logs. It works by using a rules engine that allows you to build custom rules to identify specific portions of a request that contain sensitive data. Once identified, the tool scrubs that information from your logs and replaces it with _*******_.

-The Web Application Firewall's (WAF's) Log Scrubbing tool helps you remove sensitive data from your WAF logs. It works by using a rules engine that allows you to build custom rules to identify specific portions of a request that contain sensitive information. Once identified, the tool scrubs that information from your logs and replaces it with _*******_.