blockers

Author: Ankita Dutta

articles/site-recovery/site-recovery-sql.md

@@ -31,7 +31,7 @@ SQL Server on an Azure infrastructure as a service (IaaS) virtual machine (VM) o
 SQL Server on an Azure IaaS VM or at on-premises.| [Failover clustering (Always On FCI)](/sql/sql-server/failover-clusters/windows/windows-server-failover-clustering-wsfc-with-sql-server) | The time taken to fail over between the nodes. | Because Always On FCI uses shared storage, the same view of the storage instance is available on failover.
 SQL Server on an Azure IaaS VM or at on-premises.| [Database mirroring (high-performance mode)](/sql/database-engine/database-mirroring/database-mirroring-sql-server) | The time taken to force the service, which uses the mirror server as a warm standby server. | Replication is asynchronous. The mirror database might lag somewhat behind the principal database. The lag is typically small. But it can become large if the principal or mirror server's system is under a heavy load.<br/><br/>Log shipping can be a supplement to database mirroring. It's a favorable alternative to asynchronous database mirroring.
 SQL as platform as a service (PaaS) on Azure.<br/><br/>This deployment type includes single databases and elastic pools. | Active geo-replication | 30 seconds after failover is triggered.<br/><br/>When failover is activated for one of the secondary databases, all other secondaries are automatically linked to the new primary. | RPO of five seconds.<br/><br/>Active geo-replication uses the Always On technology of SQL Server. It asynchronously replicates committed transactions on the primary database to a secondary database by using snapshot isolation.<br/><br/>The secondary data is guaranteed to never have partial transactions.
-SQL as PaaS configured with active geo-replication on Azure.<br/><br/>This deployment type includes a managed instances, elastic pools, and single databases. | Auto-failover groups | RTO of one hour. | RPO of five seconds.<br/><br/>Auto-failover groups provide the group semantics on top of active geo-replication. But the same asynchronous replication mechanism is used.
+SQL as PaaS configured with active geo-replication on Azure.<br/><br/>This deployment type includes managed instances, elastic pools, and single databases. | Auto-failover groups | RTO of one hour. | RPO of five seconds.<br/><br/>Auto-failover groups provide the group semantics on top of active geo-replication. But the same asynchronous replication mechanism is used.
 SQL Server on an Azure IaaS VM or at on-premises.| Replication with Azure Site Recovery | RTO is typically less than 15 minutes. To learn more, read the [RTO SLA provided by Site Recovery](https://azure.microsoft.com/support/legal/sla/site-recovery/v1_2/). | One hour for application consistency and five minutes for crash consistency. If you are looking for lower RPO, use other BCDR technologies.
 
 > [!NOTE]
@@ -154,9 +154,9 @@ Site Recovery replication for SQL Server is covered under the Software Assurance
 
 Site Recovery is application agnostic. Site Recovery can help protect any version of SQL Server that is deployed on a supported operating system. For more, see the [support matrix for recovery](vmware-physical-azure-support-matrix.md#replicated-machines) of replicated machines.
 
-### Does ASR Work with SQL Transactional Replication?
+### Does Azure Site Recovery Work with SQL Transactional Replication?
 
-Due to ASR using file-level copy, SQL cannot guarantee that the servers in an associated SQL replication topology are in sync at the time of ASR failover. This may cause the logreader and/or distribution agents to fail due to LSN mismatch, which can break replication. If you failover the publisher, distributor, or subscriber in a replication topology, you need to rebuild replication. It is recommended to [reinitialize the subscription to SQL Server](/sql/relational-databases/replication/reinitialize-a-subscription).
+Due to Azure Site Recovery using file-level copy, SQL cannot guarantee that the servers in an associated SQL replication topology are in sync at the time of Azure Site Recovery failover. This may cause the log reader and/or distribution agents to fail due to LSN mismatch, which can break replication. If you failover the publisher, distributor, or subscriber in a replication topology, you need to rebuild replication. It is recommended to [reinitialize the subscription to SQL Server](/sql/relational-databases/replication/reinitialize-a-subscription).
 
 
 ## Next steps

articles/site-recovery/site-recovery-test-failover-to-azure.md

@@ -3,7 +3,7 @@ title: Run a test failover (disaster recovery drill) to Azure in Azure Site Reco
 description: Learn about running a test failover from on-premises to Azure, using the Azure Site Recovery service.
 ms.service: azure-site-recovery
 ms.topic: how-to
-ms.date: 12/14/2023
+ms.date: 09/25/2024
 ms.author: ankitadutta
 author: ankitaduttaMSFT
 
@@ -65,7 +65,7 @@ In the following scenarios, failover  requires an extra intermediate step that u
 	* storflt
 	* intelide
 	* atapi
-* VMware VM that don't have DHCP enabled , irrespective of whether they are using DHCP or static IP addresses.
+* VMware VMs that don't have DHCP enabled , irrespective of whether they are using DHCP or static IP addresses.
 
 In all the other cases, no intermediate step is not required, and failover takes significantly less time.
 

articles/site-recovery/site-recovery-vmware-deployment-planner-analyze-report.md

@@ -99,7 +99,7 @@ This result is the total number of cores to be set up before failover or test fa
 ![Required number of Azure cores in the deployment planner](media/site-recovery-vmware-deployment-planner-analyze-report/required-cores-v2a.png)
 
 ### Required on-premises infrastructure
-This figure is the total number of configuration servers and extra process servers to be configured that would suffice to protect all the compatible virtual machines. Depending on the supported [size recommendations for the configuration server](/en-in/azure/site-recovery/site-recovery-plan-capacity-vmware#size-recommendations-for-the-configuration-server), the tool might recommend extra servers. The recommendation is based on the larger of either the per-day churn or the maximum number of protected virtual machines (assuming an average of three disks per virtual machine), whichever is hit first on the configuration server or the extra process server. You'll find the details of total churn per day and total number of protected disks in the "On-premises summary" section.
+This figure is the total number of configuration servers and extra process servers to be configured that would suffice to protect all the compatible virtual machines. Depending on the supported [size recommendations for the configuration server](./site-recovery-plan-capacity-vmware#size-recommendations-for-the-configuration-server.md), the tool might recommend extra servers. The recommendation is based on the larger of either the per-day churn or the maximum number of protected virtual machines (assuming an average of three disks per virtual machine), whichever is hit first on the configuration server or the extra process server. You'll find the details of total churn per day and total number of protected disks in the "On-premises summary" section.
 
 ![Required on-premises infrastructure in the deployment planner](media/site-recovery-vmware-deployment-planner-analyze-report/required-on-premises-components-v2a.png)
 
@@ -165,7 +165,7 @@ You might have a situation where you know that you cannot set a bandwidth of mor
 
 **Log Storage Account Type**: All the replication logs are stored in a standard storage account.
 
-**Suggested Prefix for Storage Account**: The suggested three-character prefix that can be used for naming the cache storage account. You can use your own prefix, but the tool's suggestion follows the [partition naming convention for storage accounts](/en-in/azure/storage/blobs/storage-performance-checklist).
+**Suggested Prefix for Storage Account**: The suggested three-character prefix that can be used for naming the cache storage account. You can use your own prefix, but the tool's suggestion follows the [partition naming convention for storage accounts](../storage/blobs/storage-performance-checklist.md).
 
 **Suggested Log Account Name**: The storage-account name after you include the suggested prefix. Replace the name within the angle brackets (< and >) with your custom input.
 
@@ -219,7 +219,7 @@ For example, if the workload characteristics of a disk put it in the P20 or P30
 
 **Virtual machine Name**: The virtual machine name or IP address that's used in the VMListFile when a report is generated. This column also lists the VMDKs that are attached to the virtual machines. To distinguish vCenter virtual machines with duplicate names or IP addresses, the names include the ESXi host name. The listed ESXi host is the one where the virtual machine was placed when the tool discovered during the profiling period.
 
-**Virtual machine Compatibility**: Indicates why the given virtual machine is incompatible for use with Site Recovery. The reasons are described for each incompatible disk of the virtual machine and, based on published [storage limits](/en-in/azure/storage/common/scalability-targets-standard-account), can be any of the following:
+**Virtual machine Compatibility**: Indicates why the given virtual machine is incompatible for use with Site Recovery. The reasons are described for each incompatible disk of the virtual machine and, based on published [storage limits](../storage/common/scalability-targets-standard-account.md), can be any of the following:
 
 * Wrong data disk size or wrong OS disk size. [Review](vmware-physical-azure-support-matrix.md#azure-vm-requirements) the support limits. 
 * Total virtual machine size (replication + TFO) exceeds the supported storage-account size limit (35 TB). This incompatibility usually occurs when a single disk in the virtual machine has a performance characteristic that exceeds the maximum supported Azure or Site Recovery limits for standard storage. Such an instance pushes the virtual machine into the premium storage zone. However, the maximum supported size of a premium storage account is 35 TB, and a single protected virtual machine cannot be protected across multiple storage accounts. Also note that when a test failover is executed on a protected virtual machine, it runs in the same storage account where replication is progressing. In this instance, set up 2x the size of the disk for replication to progress and test failover to succeed in parallel.

articles/site-recovery/site-recovery-vmware-deployment-planner-run.md

@@ -101,7 +101,7 @@ We have seen that based on the hardware configuration especially RAM size of the
 
 If you have multiple vCenter servers, you need to run one instance of ASRDeploymentPlanner for each vCenter server for profiling.
 
-virtual machine configurations are captured once at the beginning of the profiling operation and stored in a file called VMDetailList.xml. This information is used when the report is generated. Any change in virtual machine configuration (for example, an increased number of cores, disks, or NICs) from the beginning to the end of profiling isn'tcaptured. If a profiled virtual machine configuration has changed during the profiling, in the public preview, here is the workaround to get latest virtual machine details when generating the report:
+Virtual machine configurations are captured once at the beginning of the profiling operation and stored in a file called VMDetailList.xml. This information is used when the report is generated. Any change in virtual machine configuration (for example, an increased number of cores, disks, or NICs) from the beginning to the end of profiling isn'tcaptured. If a profiled virtual machine configuration has changed during the profiling, in the public preview, here is the workaround to get latest virtual machine details when generating the report:
 
 * Back up VMdetailList.xml, and delete the file from its current location.
 * Pass -User and -Password arguments at the time of report generation.
@@ -165,7 +165,7 @@ After profiling is complete, you can run the tool in report-generation mode. The
 | -UseManagedDisks | (Optional) UseManagedDisks - Yes/No. Default is Yes. The number of virtual machines that can be placed into a single storage account is calculated considering whether Failover/Test failover of virtual machines is done on managed disk instead of unmanaged disk. |
 |-SubscriptionId |(Optional) The subscription GUID. This parameter is required when you need to generate the cost estimation report with the latest price based on your subscription, the offer that is associated with your subscription and for your specific target Azure region in the **specified currency**.|
 |-TargetRegion|(Optional) The Azure region where replication is targeted. Since Azure has different costs per region, to generate report with specific target Azure region use this parameter.<br>Default is WestUS2 or the last used target region.<br>Refer to the list of [supported target regions](site-recovery-vmware-deployment-planner-cost-estimation.md#supported-target-regions).|
-|-OfferId|(Optional) The offer associated with the give subscription. Default is MS-AZR-0003P (pay-as-you-go).|
+|-OfferId|(Optional) The offer associated with the given subscription. Default is MS-AZR-0003P (pay-as-you-go).|
 |-Currency|(Optional) The currency in which cost is shown in the generated report. Default is US Dollar ($) or the last used currency.<br>Refer to the list of [supported currencies](site-recovery-vmware-deployment-planner-cost-estimation.md#supported-currencies).|
 
 By default, the tool is configured to profile and generate report up to 1000 virtual machines. You can change limit by changing MaxVMsSupported key value in *ASRDeploymentPlanner.exe.config* file.
@@ -216,7 +216,7 @@ ASRDeploymentPlanner.exe -Operation GenerateReport -Virtualization VMware  -Dire
 ## Percentile value used for the calculation
 **What default percentile value of the performance metrics collected during profiling does the tool use when it generates a report?**
 
-The tool defaults to the 95th percentile values of read/write IOPS, write IOPS, and data churn that are collected during profiling of all the virtual machines. This metric ensures that the 100th percentile spike your virtual machines might see because of temporary events isn'tused to determine your target storage-account and source-bandwidth requirements. For example, a temporary event might be a backup job running once a day, a periodic database indexing or analytics report-generation activity, or other similar short-lived, point-in-time events.
+The tool defaults to the 95th percentile values of read/write IOPS, write IOPS, and data churn that are collected during profiling of all the virtual machines. This metric ensures that the 100th percentile spike your virtual machines might see because of temporary events aren't used to determine your target storage-account and source-bandwidth requirements. For example, a temporary event might be a backup job running once a day, a periodic database indexing or analytics report-generation activity, or other similar short-lived, point-in-time events.
 
 Using 95th percentile values gives a true picture of real workload characteristics, and it gives you the best performance when the workloads are running on Azure. We don't anticipate that you would need to change this number. If you do change the value (to the 90th percentile, for example), you can update the configuration file *ASRDeploymentPlanner.exe.config* in the default folder and save it to generate a new report on the existing profiled data.
 ```xml
@@ -236,7 +236,7 @@ For example, let's say that today your virtual machine fits in a standard storag
 * The resulting increased churn on the virtual machine requires the virtual machine to go to premium storage so that Site Recovery replication can keep pace.
 * So, you have to disable and re-enable protection to a premium storage account.
 
-We strongly recommend that you plan for growth during deployment planning and while the default value is 30 percent. you're the expert on your application usage pattern and growth projections, and you can change this number accordingly while generating a report. Moreover, you can generate multiple reports with various growth factors with the same profiled data and determine what target storage and source bandwidth recommendations work best for you.
+We strongly recommend that you plan for growth during deployment planning and while the default value is 30 percent. You're the expert on your application usage pattern and growth projections, and you can change this number accordingly while generating a report. Moreover, you can generate multiple reports with various growth factors with the same profiled data and determine what target storage and source bandwidth recommendations work best for you.
 
 The generated Microsoft Excel report contains the following information:
 

articles/site-recovery/site-recovery-workload.md

@@ -137,7 +137,7 @@ Use Site Recovery to protect your SAP deployment, as follows:
 
 Use Site Recovery to protect your Internet Information Services (IIS) deployment, as follows:
 
-Azure Site Recovery provides disaster recovery by replicating the critical components in your environment to a cold remote site or a public cloud like Microsoft Azure. Since the virtual machines with the web server and the database are replicated to the recovery site, there's no requirement for a separate backup for configuration files or certificates. The application mappings and bindings dependent on environment variables that are changed post failover can be updated through scripts integrated into the disaster recovery plans. Virtual machines are brought up on the recovery site only during a failover. Azure Site Recovery also helps you orchestrate the end-to-end failover by providing you the following capabilities:
+Azure Site Recovery provides disaster recovery by replicating the critical components in your environment to a cold remote site or a public cloud like Microsoft Azure. Since the virtual machines with the web server and the database are replicated to the recovery site, there's no requirement for a separate backup for configuration files or certificates. The application mappings and bindings dependent on environment variables that are changed post failover can be updated through scripts integrated into the disaster recovery plans. Virtual machines are brought up on the recovery site only during a failover. Azure Site Recovery also helps you orchestrate the end-to-end failover by providing you with the following capabilities:
 
 - Sequencing the shutdown and startup of virtual machines in the various tiers.
 - Adding scripts to allow updates of application dependencies and bindings on the virtual machines after they've started. The scripts can also be used to update the DNS server to point to the recovery site.