Merge pull request #266126 from ankitaduttaMSFT/1adhoc

added note

Author: prmerger-automator[bot]

articles/site-recovery/failover-failback-overview-modernized.md

@@ -1,8 +1,8 @@
 ---
 title: About failover and failback in Azure Site Recovery - Modernized
-description: Learn about failover and failback in Azure Site Recovery - Modernized
+description: Learn about failover and failback in Azure Site Recovery - Modernized.
 ms.topic: conceptual
-ms.date: 12/04/2023
+ms.date: 02/13/2024
 ms.author: ankitadutta
 ms.service: site-recovery
 author: ankitaduttaMSFT
@@ -45,9 +45,9 @@ To connect to the Azure VMs created after failover using RDP/SSH, there are seve
 **Failover** | **Location** | **Actions**
 --- | --- | ---
 **Azure VM running Windows** | On the on-premises machine before failover | **Access over the internet**: Enable RDP. Make sure that TCP and UDP rules are added for **Public**, and that RDP is allowed for all profiles in **Windows Firewall** > **Allowed Apps**.<br/><br/> **Access over site-to-site VPN**: Enable RDP on the machine. Check that RDP is allowed in the **Windows Firewall** -> **Allowed apps and features**, for **Domain and Private** networks.<br/><br/>  Make sure the operating system SAN policy is set to **OnlineAll**. [Learn more](https://support.microsoft.com/kb/3031135).<br/><br/> Make sure there are no Windows updates pending on the VM when you trigger a failover. Windows Update might start when you failover, and you won't be able to log onto the VM until updates are done.
-**Azure VM running Windows** | On the Azure VM after failover |  [Add a public IP address](/archive/blogs/srinathv/how-to-add-a-public-ip-address-to-azure-vm-for-vm-failed-over-using-asr) for the VM.<br/><br/> The network security group rules on the failed over VM (and the Azure subnet to which it is connected) must allow incoming connections to the RDP port.<br/><br/> Check **Boot diagnostics** to verify a screenshot of the VM. If you can't connect, check that the VM is running, and review [troubleshooting tips](https://social.technet.microsoft.com/wiki/contents/articles/31666.troubleshooting-remote-desktop-connection-after-failover-using-asr.aspx).
+**Azure VM running Windows** | On the Azure VM after failover |  [Add a public IP address](/archive/blogs/srinathv/how-to-add-a-public-ip-address-to-azure-vm-for-vm-failed-over-using-asr) for the VM.<br/><br/> The network security group rules on the failed over VM (and the Azure subnet to which it's connected) must allow incoming connections to the RDP port.<br/><br/> Check **Boot diagnostics** to verify a screenshot of the VM. If you can't connect, check that the VM is running, and review [troubleshooting tips](https://social.technet.microsoft.com/wiki/contents/articles/31666.troubleshooting-remote-desktop-connection-after-failover-using-asr.aspx).
 **Azure VM running Linux** | On the on-premises machine before failover | Ensure that the Secure Shell service on the VM is set to start automatically on system boot.<br/><br/> Check that firewall rules allow an SSH connection to it.
-**Azure VM running Linux** | On the Azure VM after failover | The network security group rules on the failed over VM (and the Azure subnet to which it is connected) need to allow incoming connections to the SSH port.<br/><br/> [Add a public IP address](/archive/blogs/srinathv/how-to-add-a-public-ip-address-to-azure-vm-for-vm-failed-over-using-asr) for the VM.<br/><br/> Check **Boot diagnostics** for a screenshot of the VM.<br/><br/>
+**Azure VM running Linux** | On the Azure VM after failover | The network security group rules on the failed over VM (and the Azure subnet to which it's connected) need to allow incoming connections to the SSH port.<br/><br/> [Add a public IP address](/archive/blogs/srinathv/how-to-add-a-public-ip-address-to-azure-vm-for-vm-failed-over-using-asr) for the VM.<br/><br/> Check **Boot diagnostics** for a screenshot of the VM.<br/><br/>
 
 ## Types of failover
 
@@ -59,7 +59,7 @@ Site Recovery provides different failover options.
 **Planned failover-Hyper-V**  | Used for planned downtime.<br/><br/> Source VMs are shut down. The latest data is synchronized before initiating the failover. | Zero data loss for the planned workflow. | 1. Plan a downtime maintenance window and notify users.<br/><br/> 2. Take user-facing apps offline.<br/><br/> 3. Initiate a planned failover with the latest recovery point. The failover doesn't run if the machine isn't shut down, or if errors are encountered.<br/><br/> 4. After the failover, check that the replica Azure VM is active in Azure.<br/><br/> 5. Commit the failover to finish up. The commit action deletes all recovery points.
 **Failover-Hyper-V** | Usually run if there's an unplanned outage, or the primary site isn't available.<br/><br/> Optionally shut down the VM and synchronize final changes before initiating the failover.  | Minimal data loss for apps. | 1. Initiate your BCDR plan. <br/><br/> 2. Initiate a failover. Specify whether Site Recovery should shut down the VM and synchronize/replicate the latest changes before triggering the failover.<br/><br/> 3. You can failover to many recovery point options, summarized [here](#recovery-point-options).<br/><br/> If you don't enable the option to shut down the VM, or if Site Recovery can't shut it down, the latest recovery point is used.<br/>The failover runs even if the machine can't be shut down.<br/><br/> 4. After failover, you check that the replica Azure VM is active in Azure.<br/> If necessary, you can select a different recovery point from the retention window of 24 hours.<br/><br/> 5. Commit the failover to finish up. The commit action deletes all available recovery points.
 **Failover-VMware** | Usually run if there's an unplanned outage, or the primary site isn't available.<br/><br/> Optionally specify that Site Recovery should try to trigger a shutdown of the VM, and to synchronize and replicate final changes before initiating the failover.  | Minimal data loss for apps. | 1. Initiate your BCDR plan. <br/><br/> 2. Initiate a failover from Site Recovery. Specify whether Site Recovery should try to trigger VM shutdown and synchronize before running the failover.<br/> The failover runs even if the machines can't be shut down.<br/><br/> 3. After the failover, check that the replica Azure VM is active in Azure. <br/>If necessary, you can select a different recovery point from the retention window of 72 hours.<br/><br/> 5. Commit the failover to finish up. The commit action deletes all recovery points.<br/> For Windows VMs, Site Recovery disables the VMware tools during failover.
-**Planned failover-VMware** | You can perform a planned failover from Azure to on-premises. | Since it is a planned failover activity, the recovery point is generated after the planned failover job is triggered. | When the planned failover is triggered, pending changes are copied to on-premises, a latest recovery point of the VM is generated and Azure VM is shut down.<br/><br/> Follow the failover process as discussed [here](vmware-azure-tutorial-failover-failback-modernized.md#planned-failover-from-azure-to-on-premises). Post this, on-premises machine is turned on. After a successful planned failover, the machine will be active in your on-premises environment.
+**Planned failover-VMware** | You can perform a planned failover from Azure to on-premises. | Since it's a planned failover activity, the recovery point is generated after the planned failover job is triggered. | When the planned failover is triggered, pending changes are copied to on-premises, a latest recovery point of the VM is generated and Azure VM is shut down.<br/><br/> Follow the failover process as discussed [here](vmware-azure-tutorial-failover-failback-modernized.md#planned-failover-from-azure-to-on-premises). Post this, on-premises machine is turned on. After a successful planned failover, the machine will be active in your on-premises environment.
 
 ## Failover processing
 
@@ -91,51 +91,53 @@ After failover to Azure, the replicated Azure VMs are in an unprotected state.
 - As a first step to failing back to your on-premises site, you need to start the Azure VMs replicating to on-premises. The reprotection process depends on the type of machines you failed over.
 - After machines are replicating from Azure to on-premises, you can run a failover from Azure to your on-premises site.
 - After machines are running on-premises again, you can enable replication so that they replicate to Azure for disaster recovery.
-- Only disks replicated from on-premises to Azure are replicated back from Azure during re-protect operation. Newly added disks to failed over Azure VM will not be replicated to on-premises machine. 
+- Only disks replicated from on-premises to Azure are replicated back from Azure during reprotect operation. Newly added disks to failed over Azure VM won't be replicated to on-premises machine. 
 - An appliance can have up to 60 disks attached to it. If the VMs being failed back have more than a collective total of 60 disks, or if you're failing back large volumes of traffic, create a separate appliance for failback.
 
 **Planned failover works as follows**:
 
 - To fail back to on-premises, a VM needs at least one recovery point in order to fail back. In a recovery plan, all VMs in the plan need at least one recovery point.
-- As this is a planned failover activity, you are allowed to select the type of recovery point you want to fail back to. We recommend that you use a crash-consistent point.
+- As this is a planned failover activity, you're allowed to select the type of recovery point you want to fail back to. We recommend that you use a crash-consistent point.
 	- There is also an app-consistent recovery point option. In this case, a single VM recovers to its latest available app-consistent recovery point. For a recovery plan with a replication group, each replication group recovers to its common available recovery point.
 	- App-consistent recovery points can be behind in time, and there might be loss in data.
 - During failover from Azure to the on-premises site, Site Recovery shuts down the Azure VMs. When you commit the failover, Site Recovery removes the failed back Azure VMs in Azure.
 
+> [!NOTE]
+> The failover VM boot may take longer on Windows Server 2012 or older versions when using crash consistent recovery points.
 
 ## VMware/physical reprotection/failback
 
 To reprotect and fail back VMware machines and physical servers from Azure to on-premises, ensure that you have a healthy appliance.
 
 **Appliance selection**
 
-- You can select any of the Azure Site Recovery replication appliances registered under a vault to re-protect to on-premises. You do not require a separate Process server in Azure for re-protect operation and a scale-out Master Target server for Linux VMs.
-- Replication appliance doesn’t require additional network connection/ports (as compared with forward protection) during failback. Same appliance can be used for forward and backward protections if it is in healthy state. It should not impact the performance of the replications.
+- You can select any of the Azure Site Recovery replication appliances registered under a vault to reprotect to on-premises. You don't require a separate Process server in Azure for reprotect operation and a scale-out Master Target server for Linux VMs.
+- Replication appliance doesn’t require another network connection/ports (as compared with forward protection) during failback. Same appliance can be used for forward and backward protections if it's in healthy state. It shouldn't impact the performance of the replications.
 - When selecting the appliance, ensure that the target datastore where the source machine is located, is accessible by the appliance. The datastore of the source machine should always be accessible by the appliance. Even if the machine and appliance are located in different ESX servers, as long as the data store is shared between them, reprotection succeeds. 
   > [!NOTE]
-  > - Storage vMotion of replicated items is not supported. Storage vMotion of replication appliance is not supported after re-protect operation.
+  > - Storage vMotion of replicated items is not supported. Storage vMotion of replication appliance is not supported after reprotect operation.
   > - When selecting the appliance, ensure that the target datastore where the source machine is located, is accessible by the appliance.
 
 
-**Re-protect job**
+**Reprotect job**
 
-- If this is a new re-protect operation, then by default, a new log storage account is automatically created by Azure Site Recovery in the target region. Retention disk is not required.
-- In case of Alternate Location Recovery and Original Location Recovery, the original configurations of source machines are retrieved.
+- If this is a new reprotect operation, then by default, a new log storage account is automatically created by Azure Site Recovery in the target region. Retention disk is not required.
+- In Alternate Location Recovery and Original Location Recovery, the original configurations of source machines are retrieved.
   > [!NOTE]
-  > - Static IP address can’t be retained in case of Alternate location re-protect (ALR) or Original location re-protect (OLR).
+  > - Static IP address can’t be retained in case of Alternate location reprotect (ALR) or Original location reprotect (OLR).
   > - fstab, LVMconf would be changed.
 
 
 **Failure**
 
-- Any failed re-protect job can be retried. During retry, you can choose any healthy replication appliance.
+- Any failed reprotect job can be retried. During retry, you can choose any healthy replication appliance.
 
-When you reprotect Azure machines to on-premises, you are notified that you are failing back to the original location, or to an alternate location.
+When you reprotect Azure machines to on-premises, you're notified that you're failing back to the original location, or to an alternate location.
 
 - **Original location recovery**: This fails back from Azure to the same source on-premises machine if it exists. In this scenario, only changes are replicated back to on-premises.
   - **Data store selection during OLR**: The data store attached to the source machine is automatically selected.
 - **Alternate location recovery**: If the on-premises machine doesn't exist, you can fail back from Azure to an alternate location. When you reprotect the Azure VM to on-premises, the on-premises machine is created. Full data replication occurs from Azure to on-premises. [Review](concepts-types-of-failback.md) the requirements and limitations for location failback.
-  - **Data store selection during ALR**: Any data store managed by vCenter on which the appliance is situated and is accessible (read and write permissions) by the appliance can be chosen (original/new). You can choose cache storage account used for re-protection.
+  - **Data store selection during ALR**: Any data store managed by vCenter on which the appliance is situated and is accessible (read and write permissions) by the appliance can be chosen (original/new). You can choose cache storage account used for reprotection.
 
 - After failover is complete, mobility agent in the Azure VM is registered with Site Recovery Services automatically. If registration fails, a critical health issue will be raised on the failed over VM. After issue is resolved, registration is automatically triggered. You can manually complete the registration after resolving the errors.
 
@@ -163,7 +165,7 @@ Once you have initiated the planned failover and it completes successfully, your
 > [Planned failover (modernized)](vmware-azure-tutorial-failover-failback-modernized.md#planned-failover-from-azure-to-on-premises)
 
 > [!div class="nextstepaction"]
-> [Re-protect (modernized)](vmware-azure-tutorial-failover-failback-modernized.md#re-protect-the-on-premises-machine-to-azure-after-successful-planned-failover)
+> [Reprotect (modernized)](vmware-azure-tutorial-failover-failback-modernized.md#re-protect-the-on-premises-machine-to-azure-after-successful-planned-failover)
 
 > [!div class="nextstepaction"]
 > [Cancel failover (modernized)](vmware-azure-tutorial-failover-failback-modernized.md#cancel-planned-failover)