Merge pull request #108999 from davidsmatlak/ds-prcleanup1

Replaces outdated PRs

Author: American-Dipper

articles/site-recovery/azure-to-azure-about-networking.md

@@ -1,5 +1,5 @@
 ---
-title: About networking in Azure VM disaster recovery with Azure Site Recovery 
+title: About networking in Azure VM disaster recovery with Azure Site Recovery
 description: Provides an overview of networking for replication of Azure VMs using Azure Site Recovery.
 services: site-recovery
 author: sujayt
@@ -41,7 +41,7 @@ Typically, networks are protected using firewalls and network security groups (N
 If you are using a URL-based firewall proxy to control outbound connectivity, allow these Site Recovery URLs:
 
 
-**URL** | **Details**  
+**URL** | **Details**
 --- | ---
 *.blob.core.windows.net | Required so that data can be written to the cache storage account in the source region from the VM. If you know all the cache storage accounts for your VMs, you can allow access to the specific storage account URLs (Ex: cache1.blob.core.windows.net and cache2.blob.core.windows.net) instead of *.blob.core.windows.net
 login.microsoftonline.com | Required for authorization and authentication to the Site Recovery service URLs.
@@ -50,11 +50,11 @@ login.microsoftonline.com | Required for authorization and authentication to the
 *.vault.azure.net | Allows access to enable replication for ADE-enabled virtual machines via portal
 *.automation.ext.azure.com | Allows enabling auto-upgrade of mobility agent for a replicated item via portal
 
-## Outbound connectivity for IP address ranges
+## Outbound connectivity using Service Tags
 
 If you are using an NSG to control outbound connectivity, these service tags need to be allowed.
 
-- All IP address ranges that correspond to the storage accounts in source region
+- For the storage accounts in source region:
     - Create a [Storage service tag](../virtual-network/security-overview.md#service-tags) based NSG rule for the source region.
     - Allow these addresses so that data can be written to the cache storage account, from the VM.
 - Create a [Azure Active Directory (AAD) service tag](../virtual-network/security-overview.md#service-tags) based NSG rule for allowing access to all IP addresses corresponding to AAD

articles/site-recovery/azure-to-azure-common-questions.md

@@ -68,7 +68,7 @@ Yes, adding new disks to replicated VMs and enabling replication for them is sup
 
 - If you enable protection for the added disks, the warning will disappear after the initial replication.
 - If you don't enable replication for the disk, you can dismiss the warning.
-- If you fail over a VM that has an added disk and replication enabled, there are replication points. The replication points will show the disks that are available for recovery. 
+- If you fail over a VM that has an added disk and replication enabled, there are replication points. The replication points will show the disks that are available for recovery.
 
 For example, let's say a VM has a single disk and you add a new one. There might be a replication point that was created before you added the disk. This replication point will show that it consists of "1 of 2 disks."
 
@@ -188,6 +188,10 @@ You can replicate 16 virtual machines together in a replication group.
 
 Because multi-VM consistency is CPU intensive, enabling it can affect workload performance. Use multi-VM consistency only if machines are running the same workload and you need consistency across multiple machines. For example, if you have two SQL Server instances and two web servers in an application, you should have multi-VM consistency for the SQL Server instances only.
 
+### Can you add an already replicating VM to a replication group?
+
+You can add a VM to a new replication group while enabling replication. You can also add a VM to an existing replication group while enabling replication. However, you cannot add an already replicating VM to a new replication group or existing replication group.
+
 ## Failover
 
 ### How is capacity ensured in the target region for Azure VMs?
@@ -202,7 +206,7 @@ Failover isn't automatic. You can start failovers with a single click in the por
 
 You can't keep the public IP address of the production application after a failover.
 
-When you bring up a workload as part of the failover process, you need to assign an Azure public IP resource to the workload. The Azure public IP resource has to be available in the target region. You can assign the Azure public IP resource manually, or you can automate it with a recovery plan. Learn how to [set up public IP addresses after failover](concepts-public-ip-address-with-site-recovery.md#public-ip-address-assignment-using-recovery-plan).  
+When you bring up a workload as part of the failover process, you need to assign an Azure public IP resource to the workload. The Azure public IP resource has to be available in the target region. You can assign the Azure public IP resource manually, or you can automate it with a recovery plan. Learn how to [set up public IP addresses after failover](concepts-public-ip-address-with-site-recovery.md#public-ip-address-assignment-using-recovery-plan).
 
 ### Can I keep a private IP address during a failover?
 
@@ -290,7 +294,7 @@ Yes, you can purchase [reserved Azure VMs](https://azure.microsoft.com/pricing/r
 
 ### Is replication data sent to the Site Recovery service?
 
-No, Site Recovery doesn't intercept replicated data, and it doesn't have any information about what's running on your VMs. Only the metadata needed to orchestrate replication and failover is sent to the Site Recovery service.  
+No, Site Recovery doesn't intercept replicated data, and it doesn't have any information about what's running on your VMs. Only the metadata needed to orchestrate replication and failover is sent to the Site Recovery service.
 
 Site Recovery is ISO 27001:2013, 27018, HIPAA, and DPA certified. The service is undergoing SOC2 and FedRAMP JAB assessments.
 

articles/site-recovery/azure-to-azure-how-to-reprotect.md

@@ -74,7 +74,7 @@ When you trigger a reprotect job, and the target VM and disks don't exist, the f
 
 #### Estimated time to do the reprotection
 
-In most cases, Azure Site Recovery doesn’t replicate the complete data to the source region.
+In most cases, Azure Site Recovery doesn't replicate the complete data to the source region.
 The following conditions determine how much data is replicated:
 
 1. If the source VM data is deleted, corrupted, or inaccessible for some reason, such as a resource group change/delete, then during reprotection a complete initial replication will happen because there's no data available on the source region to use.
@@ -85,6 +85,10 @@ The following conditions determine how much data is replicated:
 |Source region has 1 VM with 1 TB standard disk.<br/>Only 127 GB data is used, and the rest of the disk is empty.<br/>Disk type is standard with 60 MiB/S throughput.<br/>No data change after failover.| Approximate time: 45 minutes – 1.5 hours.<br/>During reprotection, Site Recovery will populate the checksum of all data that will take 127 GB/ 45 MBs, approximately 45 minutes.<br/>Some overhead time is required for Site Recovery to auto scale, approximately 20-30 minutes.<br/>No Egress charges. |
 |Source region has 1 VM with 1 TB standard disk.<br/>Only 127 GB data is used and rest of the disk is empty.<br/>Disk type is standard with 60 MiB/S throughput.<br/>45 GB data changes after failover.| Approximate time: 1 hour – 2 hours.<br/>During reprotection, Site Recovery will populate the checksum of all data that will take 127 GB/ 45 MBs, approximately 45 minutes.<br/>Transfer time to apply changes of 45 GB that is 45 GB/ 45 MBps, approximately 17 minutes.<br/>Egress charges would be for 45 GB data changes, not for the checksum. |
 
+When the VM is re-protected after failing back to the primary region (i.e., if the VM is re-protected from primary region to DR region), the target VM and associated NIC(s) are deleted.
+
+When the VM is re-protected from the DR region to the primary region, we do not delete the erstwhile primary VM and associated NIC(s).
+
 ## Next steps
 
 After the VM is protected, you can initiate a failover. The failover shuts down the VM in the secondary region and creates and boots the VM in the primary region, with brief downtime during this process. We recommend you choose an appropriate time for this process and that you run a test failover before initiating a full failover to the primary site. [Learn more](site-recovery-failover.md) about Azure Site Recovery failover.