Merge pull request #287164 from ankitaduttaMSFT/incu5

incubation set 5

Author: JamesJBarnett

articles/site-recovery/concepts-public-ip-address-with-site-recovery.md

@@ -1,11 +1,9 @@
 ---
 title: Assign public IP addresses after failover with Azure Site Recovery 
 description: Describes how to set up public IP addresses with Azure Site Recovery and Azure Traffic Manager for disaster recovery and migration
-services: site-recovery
 author: ankitaduttaMSFT
-manager: rochakm
 ms.service: azure-site-recovery
-ms.topic: conceptual
+ms.topic: overview
 ms.date: 10/31/2023
 ms.author: ankitadutta
 
@@ -14,7 +12,7 @@ ms.author: ankitadutta
 
 Public IP addresses serve two purposes in Azure. First, they allow inbound communication from Internet resources to Azure resources. Secondly, they enable Azure resources to communicate outbound to the Internet and public-facing Azure services that have an IP address assigned to the resource.
 
-- Allow inbound communication from the Internet to the resource, such as Azure Virtual Machines (VM), Azure Application Gateways, Azure Load Balancers, Azure VPN Gateways, and others. You can still communicate with some resources, such as VMs, from the Internet, if a VM doesn't have a public IP address assigned to it, as long as the VM is part of a load balancer back-end pool, and the load balancer is assigned a public IP address.
+- Allow inbound communication from the Internet to the resource, such as Azure Virtual Machines (VM), Azure Application Gateways, Azure Load Balancers, Azure VPN Gateways, and others. You can still communicate with some resources, such as virtual machines, from the Internet, if a virtual machines doesn't have a public IP address assigned to it, as long as the virtual machines is part of a load balancer back-end pool, and the load balancer is assigned a public IP address.
 - Outbound connectivity to the Internet using a predictable IP address. For example, a virtual machine can communicate outbound to the Internet without a public IP address assigned to it, but its address is network address translated by Azure to an unpredictable public address, by default. Assigning a public IP address to a resource enables you to know which IP address is used for the outbound connection. Though predictable, the address can change, depending on the assignment method chosen. For more information, see [Create a public IP address](../virtual-network/ip-services/virtual-network-public-ip-address.md#create-a-public-ip-address). To learn more about outbound connections from Azure resources, see [Understand outbound connections](../load-balancer/load-balancer-outbound-connections.md?toc=%2fazure%2fvirtual-network%2ftoc.json).
 
 In Azure Resource Manager, a Public IP address is a resource that has its own properties. Some of the resources you can associate a public IP address resource with are:
@@ -33,7 +31,7 @@ Public IP address of the production application **cannot be retained on failover
 The setup is as follows:
 
 - Create a [recovery plan](../site-recovery/site-recovery-create-recovery-plans.md#create-a-recovery-plan) and group your workloads as necessary into the plan.
-- Customize the plan by adding a step to attach a public IP address  using [Azure Automation runbooks](../site-recovery/site-recovery-runbook-automation.md#customize-the-recovery-plan) scripts to the failed over VM.
+- Customize the plan by adding a step to attach a public IP address  using [Azure Automation runbooks](../site-recovery/site-recovery-runbook-automation.md#customize-the-recovery-plan) scripts to the failed over virtual machines.
 
 
 ## Public endpoint switching with DNS level Routing

articles/site-recovery/concepts-traffic-manager-with-site-recovery.md

@@ -1,11 +1,9 @@
 ---
 title: Azure Traffic Manager with Azure Site Recovery | Microsoft Docs
 description: Describes how to use Azure Traffic Manager with Azure Site Recovery for disaster recovery and migration
-services: site-recovery
 author: ankitaduttaMSFT
-manager: rochakm
 ms.service: azure-site-recovery
-ms.topic: conceptual
+ms.topic: concept-article
 ms.date: 12/14/2023
 ms.author: ankitadutta
 

articles/site-recovery/concepts-types-of-failback.md

@@ -1,44 +1,44 @@
 ---
-title: Failback during disaster recovery with Azure Site Recovery | Microsoft Docs
-description: This article provides an overview of various types of failback and caveats to be considered while failing back to on-premises during disaster recovery with the Azure Site Recovery service.
+title: Failback during disaster recovery with Azure Site Recovery
+description: This article provides an overview of different types of failback and important considerations for failing back to on-premises during disaster recovery with Azure Site Recovery.
 ms.service: azure-site-recovery
-ms.topic: conceptual
+ms.topic: overview
 ms.date: 08/07/2019
 ms.author: ankitadutta
 author: ankitaduttaMSFT
 
 ---
 
-# Failback of VMware VMs after disaster recovery to Azure
+# Failback of VMware virtual machines after disaster recovery to Azure
 
-After you have failed over to Azure as part of your disaster recovery process, you can fail back to your on-premises site. There are two different types of failback that are possible with Azure Site Recovery: 
+After failing over to Azure as part of your disaster recovery process, you can fail back to your on-premises site. With Azure Site Recovery, two types of failback are possible: 
 
 - Fail back to the original location 
 - Fail back to an alternate location
 
-If you failed over a VMware virtual machine, you can fail back to the same source on-premises virtual machine if it still exists. In this scenario, only the changes are replicated back. This scenario is known as **original location recovery**. If the on-premises virtual machine does not exist, the scenario is an **alternate location recovery**.
+If you failed over a VMware virtual machine, you can fail back to the same source on-premises virtual machine if it still exists. In this scenario, only the changes are replicated back. This scenario is known as **original location recovery**. If the on-premises virtual machine doesn't exist, the scenario is an **alternate location recovery**.
 
 > [!NOTE]
-> You can only fail back to the original vCenter and Configuration server. You cannot deploy a new Configuration server and fail back using it. Also, you cannot add a new vCenter to the existing Configuration server and failback into the new vCenter.
+> You can only fail back to the original vCenter and Configuration server. You can't deploy a new Configuration server and fail back using it. Also, you cannot add a new vCenter to the existing Configuration server and failback into the new vCenter.
 
 ## Original Location Recovery (OLR)
 If you choose to fail back to the original virtual machine, the following conditions need to be met:
 
 * If the virtual machine is managed by a vCenter server, then the master target's ESX host should have access to the virtual machine's datastore.
-* If the virtual machine is on an ESX host but isn’t managed by vCenter, then the hard disk of the virtual machine must be in a datastore that the master target's host can access.
+* If the virtual machine is on an ESX host but isn’t managed by vCenter, its hard disk must reside in a datastore accessible to the master target's host.
 * If your virtual machine is on an ESX host and doesn't use vCenter, then you should complete discovery of the ESX host of the master target before you reprotect. This applies if you're failing back physical servers, too.
 * You can fail back to a virtual storage area network (vSAN) or a disk that based on raw device mapping (RDM) if the disks already exist and are connected to the on-premises virtual machine.
 
 > [!IMPORTANT]
-> It is important to enable disk.enableUUID= TRUE so that during failback, the Azure Site Recovery service is able to identify the original VMDK on the virtual machine to which the pending changes will be written. If this value is not set to be TRUE, then the service tries to identify the corresponding on-premises VMDK on a best effort basis. If the right VMDK is not found, it creates an extra disk and the data gets written on to that.
+> It is important to enable disk.enableUUID= TRUE so that during failback, the Azure Site Recovery service is able to identify the original VMDK on the virtual machine to which the pending changes are written. If this value is not set to be TRUE, then the service tries to identify the corresponding on-premises VMDK on a best effort basis. If the right VMDK is not found, it creates an extra disk and the data gets written on to that.
 
 ## Alternate location recovery (ALR)
-If the on-premises virtual machine does not exist before reprotecting the virtual machine, the scenario is called an alternate location recovery. The reprotect workflow creates the on-premises virtual machine again. This will also cause a full data download.
+If the on-premises virtual machine doesn't exist before reprotecting the virtual machine, the scenario is called an alternate location recovery. The reprotected workflow creates the on-premises virtual machine again. This also causes a full data download.
 
-* When you fail back to an alternate location, the virtual machine is recovered to the same ESX host on which the master target server is deployed. The datastore that's used to create the disk will be the same datastore that was selected when reprotecting the virtual machine.
-* You can fail back only to a virtual machine file system (VMFS) or vSAN datastore. If you have an RDM, reprotect and failback will not work.
-* Reprotect involves one large initial data transfer that's followed by the changes. This process exists because the virtual machine does not exist on premises. The complete data has to be replicated back. This reprotect will also take more time than an original location recovery.
-* You cannot fail back to RDM-based disks. Only new virtual machine disks (VMDKs) can be created on a VMFS/vSAN datastore.
+* When you fail back to an alternate location, the virtual machine is recovered to the same ESX host on which the master target server is deployed. The datastore that's used to create the disk is the same datastore that was selected when reprotecting the virtual machine.
+* You can fail back only to a virtual machine file system (VMFS) or vSAN datastore. If you have an RDM, reprotect and failback won't work.
+* Reprotect involves one large initial data transfer that's followed by the changes. This process exists because the virtual machine doesn't exist on premises. The complete data has to be replicated back. This reprotect also takes more time than an original location recovery.
+* You can't fail back to RDM-based disks. Only new virtual machine disks (VMDKs) can be created on a VMFS/vSAN datastore.
 
 > [!NOTE]
 > A physical machine, when failed over to Azure, can be failed back only as a VMware virtual machine. This follows the same workflow as the alternate location recovery. Ensure that you discover at least one master target server and the necessary ESX/ESXi hosts to which you need to fail back.

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

@@ -1,7 +1,7 @@
 ---
 title: About failover and failback in Azure Site Recovery - Modernized
 description: Learn about failover and failback in Azure Site Recovery - Modernized.
-ms.topic: conceptual
+ms.topic: overview
 ms.date: 02/13/2024
 ms.author: ankitadutta
 ms.service: azure-site-recovery