Merge pull request #314223 from MicrosoftDocs/main

Auto Publish – main to live - 2026-04-03 11:00 UTC

Author: learn-build-service-prod[bot]

articles/backup/backup-azure-arm-restore-vms.md

@@ -248,7 +248,7 @@ If CRR is enabled, you can view the backup items in the secondary region.
 
 The secondary region restore user experience is similar to the primary region restore user experience. When configuring details in the Restore Configuration pane to configure your restore, you're  prompted to provide only secondary region parameters.
 
-Currently, secondary region [RPO](azure-backup-glossary.md#recovery-point-objective-rpo) is _36 hours_. This is because the RPO in the primary region is _24 hours_ and can take up to _12 hours_ to replicate the backup data from the primary to the secondary region.
+For Azure VM backups, the secondary region [RPO](azure-backup-glossary.md#recovery-point-objective-rpo) can be up to _36 hours_ in the worst case. With the Standard policy, the primary region RPO is up to _24 hours_, and replication to the secondary region can take up to _12 hours_. With the Enhanced policy, more frequent local recovery point creation can improve the best-case achievable secondary region RPO. However, because vaulting is daily, the worst-case secondary region RPO can still be up to _36 hours_.
 
 :::image type="content" source="./media/backup-azure-arm-restore-vms/secondary-region-restore.png" alt-text="{alt-text}":::Screenshot shows how to start secondary region restore of a VM. ":::
 

articles/backup/backup-azure-vm-backup-faq.yml

@@ -457,7 +457,7 @@ sections:
 
       - question: When Vault is configured with CRR, what happens to the secondary data if the primary region fails?
         answer: |
-          Backup data fully replicated to the secondary region before the failure of the primary region will remain intact. This remains the case even after the primary region has recovered from the failure. In other words, the virtual machine can be recovered in the secondary region with the data it had before the failure as per the replication schedule. Note that the RPO for the secondary region is 36 hours i.e., data takes approximately 36 hours to be fully replicated from primary to the secondary region.
+          Backup data fully replicated to the secondary region before the failure of the primary region remains intact. This remains true even after the primary region recovers from the failure. In other words, the virtual machine can be recovered in the secondary region with the data it had before the failure, based on the replication schedule. For Azure VM backups, the secondary region RPO can be up to 36 hours in the worst case. With the Standard policy, this is based on up to 24 hours in the primary region plus up to 12 hours for replication to the secondary region. With the Enhanced policy, more frequent local recovery point creation can improve the best-case achievable secondary region RPO, but the worst-case can still be up to 36 hours.
 
       - question: When I update the backup policy, why is the expiry time not getting updated immediately?
         answer: |

articles/backup/backup-azure-vms-introduction.md

@@ -47,7 +47,9 @@ Azure Backup takes snapshots according to the backup schedule.
 
 If you have opted for application or file-system-consistent backups, the VM needs to have a backup extension installed to coordinate for the snapshot process. For [*agentless multi-disk crash-consistent* backups](backup-azure-vms-agentless-multi-disk-crash-consistent-overview.md), the VM agent is not required for snapshots.
 
-- **Windows VMs:** For Windows VMs, the Backup service coordinates with VSS to take an app-consistent snapshot of the VM disks.  By default, Azure Backup takes a full VSS backup (it truncates the logs of application such as SQL Server at the time of backup to get application level consistent backup).  If you're using a SQL Server database on Azure VM backup, then you can modify the setting to take a VSS Copy backup (to preserve logs). For more information, see [this article](./backup-azure-vms-troubleshoot.md#troubleshoot-vm-snapshot-issues).
+- **Windows VMs:** For Windows VMs, Azure Backup coordinates with VSS to take an application-consistent snapshot. For VMs running SQL Server, Azure VM Backup triggers a VSS Full (Copy-Only) backup by default to avoid affecting the SQL backup chain used by other backup tools. Copy-Only backups do not truncate SQL Server transaction logs. If you require log truncation (and understand the impact on the SQL backup chain), you can opt in to a VSS Full (Non-Copy-Only) backup by using the UseVssFullBackup registry setting. For more information, see [this article](./backup-azure-vms-troubleshoot.md#troubleshoot-vm-snapshot-issues).
+>[!Note]
+> Azure VM Backup is a VM-level backup. If you need database-level point-in-time recovery using transaction logs, use [Azure Backup for SQL Server in Azure VM (workload backup)](backup-azure-sql-database.md).
 
 - **Linux VMs:** To take app-consistent snapshots of Linux VMs, use the Linux pre-script and post-script framework to write your own custom scripts to ensure consistency.
 

articles/backup/backup-azure-vms-troubleshoot.md

@@ -556,17 +556,16 @@ Verify the VM Agent version on Windows VMs:
 
 ## Troubleshoot VM snapshot issues
 
-VM backup relies on issuing snapshot commands to underlying storage. Not having access to storage or delays in a snapshot task run can cause the backup job to fail. The following conditions can cause snapshot task failure:
+VM backup relies on issuing snapshot commands to underlying storage. Lack of storage access or delays during a snapshot task run can cause the backup job to fail. The following conditions can cause snapshot task failure:
+* **VMs with SQL Server configured can experience snapshot delays** when Azure VM Backup interacts with the SQL Server VSS Writer. For Windows VMs running SQL Server, Azure VM Backup currently triggers a VSS Full (Copy-Only) backup by default to avoid impacting SQL Server differential and transaction log backup chains used by other backup tools. Copy-Only VSS backups do not truncate SQL Server transaction logs.
 
-* **VMs with SQL Server backup configured can cause snapshot task delay**. To avoid that, currently VM backup creates a VSS full backup (Copy-Only) on Windows VMs. If you need a VSS Full backup (Non-copy Only) then add the following registry key on the Windows VM:
+If you explicitly require a VSS Full (Non-Copy-Only) backup, which can truncate SQL Server transaction logs and may affect the SQL backup chain, configure the following registry key on the Windows VM:
 
    ```console
-   REG ADD "HKLM\SOFTWARE\Microsoft\BcdrAgent" /v UseVSSCopyBackup /t REG_SZ /d True /f   
+REG ADD "HKLM\SOFTWARE\Microsoft\BcdrAgent" /v UseVssFullBackup /t REG_SZ /d True /f
    ```
 
-  >[!Note]
-  >Setting UseVSSCopyBackup = True enables VSS Copy-Only backups. This ensures that snapshots aren't delayed and that any log chains managed by other backup products (such as SQL Server log backups) are not broken.
-  If the key is set to False or not present, Azure Backup defaults to VSS Full backups, which may truncate application logs to achieve application-consistent backups.
+If UseVssFullBackup is set to False or not present, Azure VM Backup continues to use VSS Full (Copy-Only) backups by default.
 
 * **VM status is reported incorrectly because the VM is shut down in RDP**. If you used the remote desktop to shut down the virtual machine, verify that the VM status in the portal is correct. If the status isn't correct, use the **Shutdown** option in the portal VM dashboard to shut down the VM.
 * **The VM runs at high CPU or memory**. If the virtual machine runs at high memory or CPU usage, more than 90 percent, your snapshot task is queued and delayed. Eventually it times out. If this issue happens, try an on-demand backup.

articles/backup/backup-create-recovery-services-vault.md

@@ -52,7 +52,7 @@ Before you begin, consider the following information:
 - A list of supported managed types and regions is available in the [Support matrix for Azure Backup](backup-support-matrix.md#cross-region-restore).
 - Cross Region Restore incurs extra charges for use. After you enable Cross Region Restore, it might take up to 48 hours for the backup items to be available in secondary regions. [Learn more about pricing](https://azure.microsoft.com/pricing/details/backup/).
 - Cross Region Restore currently can't be reverted to GRS or LRS after the protection starts for the first time.
-- Currently, the recovery point objective (RPO) for the secondary region is 36 hours. The RPO in the primary region is 24 hours and can take up to 12 hours to replicate the backup data from the primary to the secondary region.
+- Secondary region recovery point objective (RPO) can vary by workload type and policy. For Azure VM backups, the secondary region RPO can be up to 36 hours in the worst case. With the Standard policy, the primary region RPO is up to 24 hours, and replication to the secondary region can take up to 12 hours. With the Enhanced policy, more frequent local recovery point creation can improve the best-case achievable secondary region RPO, but the worst-case can still be up to 36 hours. For workload-specific guidance, see the relevant restore documentation.
 - Permissions are required to use Cross Region Restore. For more information, see [Use Azure role-based access control (RBAC) to manage Azure Backup recovery points](backup-rbac-rs-vault.md#minimum-role-requirements-for-azure-vm-backup).
 
 A vault created with GRS redundancy includes the option to configure Cross Region Restore. Every GRS vault has a banner that links to the documentation.

articles/data-factory/connector-salesforce-service-cloud.md

@@ -7,7 +7,7 @@ author: jianleishen
 ms.subservice: data-movement
 ms.topic: how-to
 ms.custom: synapse
-ms.date: 09/04/2025
+ms.date: 03/23/2026
 ---
 
 # Copy data from and to Salesforce Service Cloud V2 using Azure Data Factory or Azure Synapse Analytics
@@ -205,6 +205,7 @@ To copy data from Salesforce Service Cloud, set the source type in the copy acti
 | type | The type property of the copy activity source must be set to **SalesforceServiceCloudV2Source**. | Yes |
 | query | Use the custom query to read data. You can only use [Salesforce Object Query Language (SOQL)](https://developer.salesforce.com/docs/atlas.en-us.soql_sosl.meta/soql_sosl/sforce_api_calls_soql.htm) query. If query is not specified, all the data of the Salesforce object specified in "objectApiName/reportId" in dataset will be retrieved. | No (if "objectApiName/reportId" in the dataset is specified) |
 | includeDeletedObjects | Indicates whether to query the existing records, or query all records including the deleted ones. If not specified, the default behavior is false. <br>Allowed values: **false** (default), **true**. | No |
+| preserveScaleFromSchema | Indicates whether to enable decimal scale rounding or not according to the decimal scale definition in the schema. Rounding only happens when property is set to true. If not specified, the default behavior is false. For example, if a column is defined as decimal(18,3) in the schema, the value 123.123789 is rounded to 123.124 when this option is enabled. <br>Allowed values: **false** (default), **true**. | No |
 | partitionOption | Provide capability to automatically detect and apply the optimal partitioning algorithm to optimize for read throughput when applicable. You are recommended to specify `AutoDetect` for long-running copy that can benefit from multi-threaded reads. The default value is `AutoDetect`. | No |
 
 > [!IMPORTANT]
@@ -236,6 +237,7 @@ To copy data from Salesforce Service Cloud, set the source type in the copy acti
                 "type": "SalesforceServiceCloudV2Source",
                 "query": "SELECT Col_Currency__c, Col_Date__c, Col_Email__c FROM AllDataType__c",
                 "includeDeletedObjects": false,
+                "preserveScaleFromSchema": false,
                 "partitionOption": "AutoDetect"
             },
             "sink": {
@@ -334,7 +336,7 @@ The following table shows the release stage and change logs for different versio
 | Version  | Release stage           | Change log |
 | :------- | :---------------------- |:---------- |
 | Salesforce Service Cloud V1 | Removed | Not applicable. |
-| Salesforce Service Cloud V2 | GA version available | • Support OAuth2ClientCredentials authentication instead of the basic authentication. <br><br> • Support SOQL query only.<br><br>• Support report by selecting a report ID.<br><br>• Support `partitionOption` in the copy activity source. <br><br>• `readBehavior` is replaced with `includeDeletedObjects` in the copy activity source or the lookup activity.|
+| Salesforce Service Cloud V2 | GA version available | • Support OAuth2ClientCredentials authentication instead of the basic authentication. <br><br> • Support SOQL query only.<br><br>• Support report by selecting a report ID.<br><br>• Support `partitionOption` in the copy activity source. <br><br>• Support `preserveScaleFromSchema` in the copy activity source. <br><br>• `readBehavior` is replaced with `includeDeletedObjects` in the copy activity source or the lookup activity.|
 
 ### <a name="upgrade-the-salesforce-service-cloud-linked-service"></a> Upgrade the Salesforce Service Cloud connector
 
@@ -348,6 +350,8 @@ Here are steps that help you upgrade your Salesforce Service Cloud connector:
 
 1. Support `partitionOption` in the copy activity source. For the detailed configuration, see [Salesforce Service Cloud as a source type](connector-salesforce-service-cloud.md#salesforce-service-cloud-as-a-source-type).
 
+1. Support `preserveScaleFromSchema` in the copy activity source. For the detailed configuration, see [Salesforce Service Cloud as a source type](connector-salesforce-service-cloud.md#salesforce-service-cloud-as-a-source-type).
+
 1. `readBehavior` is replaced with `includeDeletedObjects` in the copy activity source or the lookup activity. For the detailed configuration, see [Salesforce Service Cloud as a source type](connector-salesforce-service-cloud.md#salesforce-service-cloud-as-a-source-type).
 
 

articles/data-factory/connector-salesforce.md

@@ -7,7 +7,7 @@ author: jianleishen
 ms.subservice: data-movement
 ms.topic: how-to
 ms.custom: synapse
-ms.date: 09/04/2025
+ms.date: 03/23/2026
 ---
 
 # Copy data from and to Salesforce V2 using Azure Data Factory or Azure Synapse Analytics
@@ -249,6 +249,7 @@ To copy data from Salesforce, set the source type in the copy activity to **Sale
 | type | The type property of the copy activity source must be set to **SalesforceV2Source**. | Yes |
 | query | Use the custom query to read data. You can only use [Salesforce Object Query Language (SOQL)](https://developer.salesforce.com/docs/atlas.en-us.soql_sosl.meta/soql_sosl/sforce_api_calls_soql.htm) query. If query isn't specified, all the data of the Salesforce object specified in "objectApiName/reportId" in dataset is retrieved. | No (if "objectApiName/reportId" in the dataset is specified) |
 | includeDeletedObjects | Indicates whether to query the existing records, or query all records including the deleted ones. If not specified, the default behavior is false. <br>Allowed values: **false** (default), **true**.   | No |
+| preserveScaleFromSchema | Indicates whether to enable decimal scale rounding or not according to the decimal scale definition in the schema. Rounding only happens when property is set to true. If not specified, the default behavior is false. For example, if a column is defined as decimal(18,3) in the schema, the value 123.123789 is rounded to 123.124 when this option is enabled. <br>Allowed values: **false** (default), **true**. | No |
 | partitionOption | Provide capability to automatically detect and apply the optimal partitioning algorithm to optimize for read throughput when applicable. You are recommended to specify `AutoDetect` for long-running copy that can benefit from multi-threaded reads. The default value is `AutoDetect`. | No |
 
 > [!IMPORTANT]
@@ -280,6 +281,7 @@ To copy data from Salesforce, set the source type in the copy activity to **Sale
                 "type": "SalesforceV2Source",
                 "query": "SELECT Col_Currency__c, Col_Date__c, Col_Email__c FROM AllDataType__c",
                 "includeDeletedObjects": false,
+                "preserveScaleFromSchema": false,
                 "partitionOption": "AutoDetect"
             },
             "sink": {
@@ -378,7 +380,7 @@ The following table shows the release stage and change logs for different versio
 | Version  | Release stage           | Change log |
 | :------- | :---------------------- |:---------- |
 | Salesforce V1 | Removed | Not applicable. | 
-| Salesforce V2 | GA version available | • Support OAuth2ClientCredentials authentication instead of the basic authentication. <br><br> • Support SOQL query only.<br><br>• Support report by selecting a report ID.<br><br>• Support `partitionOption` in the copy activity source. <br><br>• `readBehavior` is replaced with `includeDeletedObjects` in the copy activity source or the lookup activity.|
+| Salesforce V2 | GA version available | • Support OAuth2ClientCredentials authentication instead of the basic authentication. <br><br> • Support SOQL query only.<br><br>• Support report by selecting a report ID.<br><br>• Support `partitionOption` in the copy activity source.<br><br>• Support `preserveScaleFromSchema` in the copy activity source. <br><br>• `readBehavior` is replaced with `includeDeletedObjects` in the copy activity source or the lookup activity.|
 
 ### <a name="upgrade-the-salesforce-linked-service"></a> Upgrade the Salesforce connector from V1 to V2
 
@@ -392,6 +394,8 @@ Here are steps that help you upgrade your Salesforce connector:
 
 1. Support `partitionOption` in the copy activity source. For the detailed configuration, see [Salesforce as a source type](connector-salesforce.md#salesforce-as-a-source-type).
 
+1. Support `preserveScaleFromSchema` in the copy activity source. For the detailed configuration, see [Salesforce as a source type](connector-salesforce.md#salesforce-as-a-source-type).
+
 1. `readBehavior` is replaced with `includeDeletedObjects` in the copy activity source or the lookup activity. For the detailed configuration, see [Salesforce as a source type](connector-salesforce.md#salesforce-as-a-source-type).
 
 ## Related content

articles/migrate/deploy-appliance-script.md

@@ -33,8 +33,8 @@ You can use the script to deploy the Azure Migrate appliance on an existing serv
 
 Scenario | Requirements
 --- | ---
-VMware | Windows Server 2019 or Windows Server 2022, with 32 GB of memory, eight vCPUs, around 80 GB of disk storage.
-Hyper-V | Windows Server 2019 or Windows Server 2022, with 16 GB of memory, eight vCPUs, around 80 GB of disk storage.
+VMware | Windows Server 2022 or Windows Server 2025, with 32 GB of memory, eight vCPUs, around 80 GB of disk storage.
+Hyper-V | Windows Server 2022 or Windows Server 2025, with 16 GB of memory, eight vCPUs, around 80 GB of disk storage.
 
 - The server also needs an external virtual switch. It requires a static or dynamic IP address. 
 - Before you deploy the appliance, review detailed appliance requirements for [VMware](migrate-appliance.md#appliance---vmware) and [Hyper-V](migrate-appliance.md#appliance---hyper-v).