acrofix

Author: Ankita Dutta

articles/site-recovery/site-recovery-citrix-xenapp-and-xendesktop.md

@@ -10,4 +10,4 @@ ms.author: ankitadutta
 ---
 # End of support for disaster recovery of Citrix workloads
 
-As of March 2020, Citrix has announced deprecation and end-of-support for public cloud hosted workloads. Therefore, we do not recommend using Site Recovery for protecting Citrix workloads.
+As of March 2020, Citrix announced the deprecation and end-of-support for public cloud hosted workloads. Therefore, we don't recommend using Site Recovery for protecting Citrix workloads.

articles/site-recovery/site-recovery-sharepoint.md

@@ -4,7 +4,7 @@ description: This article describes how to set up disaster recovery for a multi-
 author: ankitaduttaMSFT
 ms.service: azure-site-recovery
 ms.topic: how-to
-ms.date: 09/06/2024
+ms.date: 09/10/2024
 ms.author: ankitadutta
 
 ---
@@ -23,7 +23,6 @@ A good disaster recovery solution should allow modeling of recovery plans around
 
 This article describes in detail how to protect a SharePoint application using [Azure Site Recovery](site-recovery-overview.md). This article will cover best practices for replicating a three tier SharePoint application to Azure, how you can do a disaster recovery drill, and how you can failover the application to Azure.
 
-You can watch the below video about recovering a multi-tier application to Azure.
 
 ## Prerequisites
 
@@ -38,7 +37,7 @@ Before you start, make sure you understand the following:
 
 ## SharePoint architecture
 
-SharePoint can be deployed on one or more servers using tiered topologies and server roles to implement a farm design that meets specific goals and objectives. A typical large, high-demand SharePoint server farm that supports a high number of concurrent users and a large number of content items use service grouping as part of their scalability strategy. This approach involves running services on dedicated servers, grouping these services together, and then scaling out the servers as a group. The following topology illustrates the service and server grouping for a three tier SharePoint server farm. Please refer to SharePoint documentation and product line architectures for detailed guidance on different SharePoint topologies. You can find more details about SharePoint 2013 deployment in [this document](/SharePoint/sharepoint-server).
+SharePoint can be deployed on one or more servers using tiered topologies and server roles to implement a farm design that meets specific goals and objectives. A typical large, high-demand SharePoint server farm that supports a high number of concurrent users and a large number of content items use service grouping as part of their scalability strategy. This approach involves running services on dedicated servers, grouping these services together, and then scaling out the servers as a group. The following topology illustrates the service and server grouping for a three tier SharePoint server farm. Refer to SharePoint documentation and product line architectures for detailed guidance on different SharePoint topologies. You can find more details about SharePoint 2013 deployment in [this document](/SharePoint/sharepoint-server).
 
 
 
@@ -61,13 +60,13 @@ Site Recovery is application-agnostic and should work with any version of ShareP
 
 ### Things to keep in mind
 
-If you are using a shared disk-based cluster as any tier in your application then you will not be able to use Site Recovery replication to replicate those virtual machines. You can use native replication provided by the application and then use a [recovery plan](site-recovery-create-recovery-plans.md) to failover all tiers.
+If you're using a shared disk-based cluster as any tier in your application, then you wn't be able to use Site Recovery replication to replicate those virtual machines. You can use native replication provided by the application and then use a [recovery plan](site-recovery-create-recovery-plans.md) to failover all tiers.
 
 ## Replicating virtual machines
 
 Follow [this guidance](./vmware-azure-tutorial.md) to start replicating the virtual machine to Azure.
 
-* Once the replication is complete, make sure you go to each virtual machine of each tier and select same availability set in 'Replicated item > Settings > Properties > Compute and Network'. For example, if your web tier has 3 VMs, ensure all the 3 VMs are configured to be part of same availability set in Azure.
+* Once the replication is complete, make sure you go to each virtual machine of each tier and select same availability set in 'Replicated item > Settings > Properties > Compute and Network'. For example, if your web tier has 3 virtual machines, ensure all the 3 virtual machines are configured to be part of same availability set in Azure.
 
 	![Set-Availability-Set](./media/site-recovery-sharepoint/select-av-set.png)
 
@@ -79,7 +78,7 @@ Follow [this guidance](./vmware-azure-tutorial.md) to start replicating the virt
 
 ### Network properties
 
-* For the App and Web tier VMs, configure network settings in Azure portal so that the VMs get attached to the right DR network after failover.
+* For the App and Web tier virtual machines, configure network settings in Azure portal so that the virtual machines get attached to the right DR network after failover.
 
 	![Select Network](./media/site-recovery-sharepoint/select-network.png)
 
@@ -103,29 +102,29 @@ In the Traffic Manager profile, [create the primary and recovery endpoints](../t
 
 Host a test page on a specific port (for example, 800) in the SharePoint web tier in order for Traffic Manager to automatically detect availability post failover. This is a workaround in case you cannot enable anonymous authentication on any of your SharePoint sites.
 
-[Configure the Traffic Manager profile](../traffic-manager/traffic-manager-configure-priority-routing-method.md) with the below settings.
+[Configure the Traffic Manager profile](../traffic-manager/traffic-manager-configure-priority-routing-method.md) with the following settings:
 
 * Routing method - 'Priority'
 * DNS time to live (TTL) - '30 seconds'
 * Endpoint monitor settings - If you can enable anonymous authentication, you can give a specific website endpoint. Or, you can use a test page on a specific port (for example, 800).
 
 ## Creating a recovery plan
 
-A recovery plan allows sequencing the failover of various tiers in a multi-tier application, hence, maintaining application consistency. Follow the below steps while creating a recovery plan for a multi-tier web application. [Learn more about creating a recovery plan](site-recovery-runbook-automation.md#customize-the-recovery-plan).
+A recovery plan allows sequencing the failover of various tiers in a multi-tier application, hence, maintaining application consistency. Follow the given steps while creating a recovery plan for a multi-tier web application. [Learn more about creating a recovery plan](site-recovery-runbook-automation.md#customize-the-recovery-plan).
 
 ### Adding virtual machines to failover groups
 
-1. Create a recovery plan by adding the App and Web tier VMs.
-2. Click on 'Customize' to group the VMs. By default, all VMs are part of 'Group 1'.
+1. Create a recovery plan by adding the App and Web tier virtual machines.
+2. Click on 'Customize' to group the virtual machines. By default, all virtual machines are part of 'Group 1'.
 
 	![Customize RP](./media/site-recovery-sharepoint/rp-groups.png)
 
-3. Create another Group (Group 2) and move the Web tier VMs into the new group. Your App tier VMs should be part of 'Group 1' and Web tier VMs should be part of 'Group 2'. This is to ensure that the App tier VMs boot up first followed by Web tier VMs.
+3. Create another Group (Group 2) and move the Web tier virtual machines into the new group. Your App tier virtual machines should be part of 'Group 1' and Web tier virtual machines should be part of 'Group 2'. This is to ensure that the App tier virtual machines boot up first followed by Web tier virtual machines.
 
 
 ### Adding scripts to the recovery plan
 
-You can deploy the most commonly used Azure Site Recovery scripts into your Automation account clicking the 'Deploy to Azure' button below. When you are using any published script, ensure you follow the guidance in the script.
+You can deploy the most commonly used Azure Site Recovery scripts into your Automation account clicking the 'Deploy to Azure' button. When you are using any published script, ensure you follow the guidance in the script.
 
 [![Deploy to Azure](https://azurecomcdn.azureedge.net/mediahandler/acomblog/media/Default/blog/c4803408-340e-49e3-9a1f-0ed3f689813d.png)](https://aka.ms/asr-automationrunbooks-deploy)
 
@@ -143,37 +142,38 @@ You can deploy the most commonly used Azure Site Recovery scripts into your Auto
 
 3. Add a manual step to update the DNS records to point to the new farm in Azure.
 
-	* For internet facing sites, no DNS updates are required post failover. Follow the steps described in the 'Networking guidance' section to configure Traffic Manager. If the Traffic Manager profile has been set up as described in the previous section, add a script to open dummy port (800 in the example) on the Azure VM.
+	* For internet facing sites, no DNS updates are required post failover. Follow the steps described in the 'Networking guidance' section to configure Traffic Manager. If the Traffic Manager profile has been set up as described in the previous section, add a script to open dummy port (800 in the example) on the Azure virtual machine.
 
-	* For internal facing sites, add a manual step to update the DNS record to point to the new Web tier VM’s load balancer IP.
+	* For internal facing sites, add a manual step to update the DNS record to point to the new Web tier virtual machine’s load balancer IP.
 
 4. Add a manual step to restore search application from a backup or start a new search service.
 
-5. For restoring Search service application from a backup, follow below steps.
+5. For restoring Search service application from a backup, follow these steps:
 
 	* This method assumes that a backup of the Search Service Application was performed before the catastrophic event and that the backup is available at the DR site.
 	* This can easily be achieved by scheduling the backup (for example, once daily) and using a copy procedure to place the backup at the DR site. Copy procedures could include scripted programs such as AzCopy (Azure Copy) or setting up DFSR (Distributed File Services Replication).
 	* Now that the SharePoint farm is running, navigate the Central Administration, 'Backup and Restore' and select Restore. The restore interrogates the backup location specified (you may need to update the value). Select the Search Service Application backup you would like to restore.
 	* Search is restored. Keep in mind that the restore expects to find the same topology (same number of servers) and same hard drive letters assigned to those servers. For more information, see ['Restore Search service application in SharePoint 2013'](/SharePoint/administration/restore-a-search-service-application) document.
 
 
-6. For starting with a new Search service application, follow below steps.
+6. For starting with a new Search service application, follow these steps:
 
 	* This method assumes that a backup of the “Search Administration” database is available at the DR site.
 	* Since the other Search Service Application databases are not replicated, they need to be re-created. To do so, navigate to Central Administration and delete the Search Service Application. On any servers which host the Search Index, delete the index files.
 	* Re-create the Search Service Application and this re-creates the databases. It is recommended to have a prepared script that re-creates this service application since it is not possible to perform all actions via the GUI. For example, setting the index drive location and configuring the search topology are only possible by using SharePoint PowerShell cmdlets. Use the Windows PowerShell cmdlet Restore-SPEnterpriseSearchServiceApplication and specify the log-shipped and replicated Search Administration database, Search_Service__DB. This cmdlet gives the search configuration, schema, managed properties, rules, and sources and creates a default set of the other components.
 	* Once the Search Service Application has be re-created, you must start a full crawl for each content source to restore the Search Service. You lose some analytics information from the on-premises farm, such as search recommendations.
 
-7. Once all the steps are completed, save the recovery plan and the final recovery plan will look like following.
+7. Once all the steps are completed, save the recovery plan and the final recovery plan looks like following:
 
 	![Saved RP](./media/site-recovery-sharepoint/saved-rp.png)
 
 ## Doing a test failover
+
 Follow [this guidance](site-recovery-test-failover-to-azure.md) to do a test failover.
 
 1.	Go to Azure portal and select your Recovery Service vault.
-2.	Click on the recovery plan created for SharePoint application.
-3.	Click on 'Test Failover'.
+2.	Select the recovery plan created for SharePoint application.
+3.	Select **Test Failover**.
 4.	Select recovery point and Azure virtual network to start the test failover process.
 5.	Once the secondary environment is up, you can perform your validations.
 6.	Once the validations are complete, you can click 'Cleanup test failover' on the recovery plan and the test failover environment is cleaned.

articles/site-recovery/vmware-azure-set-up-process-server-scale.md

@@ -5,27 +5,27 @@ author: ankitaduttaMSFT
 ms.service: azure-site-recovery
 ms.topic: how-to
 ms.author: ankitadutta
-ms.date: 09/06/2024
+ms.date: 09/11/2024
 ---
 
-# Scale with additional process servers
+# Scale with extra process servers
 
-By default, when you're replicating VMware VMs or physical servers to Azure using [Site Recovery](site-recovery-overview.md), a process server is installed on the configuration server machine, and is used to coordinate data transfer between Site Recovery and your on-premises infrastructure. To increase capacity and scale out your replication deployment, you can add additional standalone process servers. This article describes how to setup a scale-out process server.
+By default, when you're replicating VMware VMs or physical servers to Azure using [Site Recovery](site-recovery-overview.md), a process server is installed on the configuration server machine, and is used to coordinate data transfer between Site Recovery and your on-premises infrastructure. To increase capacity and scale out your replication deployment, you can add an extra standalone process servers. This article describes how to set up a scale-out process server.
 
 ## Before you start
 
 ### Capacity planning
 
-Make sure you've performed [capacity planning](site-recovery-plan-capacity-vmware.md) for VMware replication. This helps you to identify how and when you should deploy additional process servers.
+Ensure to perform [capacity planning](site-recovery-plan-capacity-vmware.md) for VMware replication. This helps you to identify how and when you should deploy extra process servers.
 
-From 9.24 version, guidance is added during selection of process server for new replications. Process server will be marked Healthy, Warning and Critical based on certain criteria. To understand different scenarios that can influence state of process server, review the [process server alerts](vmware-physical-azure-monitor-process-server.md#process-server-alerts).
+From 9.24 version, guidance is added during selection of process server for new replications. Process server is marked *Healthy*, *Warning*, and *Critical* based on certain criteria. To understand different scenarios that can influence state of process server, review the [process server alerts](vmware-physical-azure-monitor-process-server.md#process-server-alerts).
 
 > [!NOTE]
 > Use of a cloned Process Server component is not supported. Follow the steps in this article for each PS scale-out.
 
 ### Sizing requirements 
 
-Verify the sizing requirements summarized in the table. In general, if you have to scale your deployment to more than 200 source machines, or you have a total daily churn rate of more than 2 TB, you need additional process servers to handle the traffic volume.
+Verify the sizing requirements summarized in the table. In general, if you have to scale your deployment to more than 200 source machines, or you have a total daily churn rate of more than 2 TB, you need extra process servers to handle the traffic volume.
 
 | **Additional process server** | **Cache disk size** | **Data change rate** | **Protected machines** |
 | --- | --- | --- | --- |