Merge pull request #220216 from msft-jasonparker/avd-fsl-bcdr

Updated AVD DR page removing reference to Cloud Cache

Author: Stacyrch140

articles/virtual-desktop/TOC.yml

@@ -444,4 +444,4 @@
   - name: Terraform samples
     href: /azure/developer/terraform/configure-azure-virtual-desktop
   - name: Azure compliance offerings
-    href: https://azure.microsoft.com/resources/microsoft-azure-compliance-offerings/
+    href: https://azure.microsoft.com/resources/microsoft-azure-compliance-offerings/

articles/virtual-desktop/disaster-recovery-concepts.md

@@ -65,7 +65,7 @@ The disaster recovery methods we recommend are:
 
 - For personal host pools with dedicated VMs, [replicate VMs using Azure Site Recovery](../site-recovery/azure-to-azure-how-to-enable-replication.md) to another region.
 
-- Configure a separate "disaster recovery" host pool in the secondary region and use FSLogix Cloud Cache to replicate the user profile. During a disaster, you can switch users over to the secondary region.
+- Configure a separate "disaster recovery" host pool in the secondary region. During a disaster, you can switch users over to the secondary region.
 
 We'll go into more detail about the two main methods you can achieve these methods with for shared and personal host pools in the following sections.
 
@@ -75,7 +75,7 @@ In this section, we'll discuss shared (or "pooled") host pools using an active-p
 
 The following diagram shows an example of a deployment with redundant infrastructure in a secondary region. "Redundant" means that a copy of the original infrastructure exists in this other region, and is standard in deployments to provide resiliency for all components. Beneath a single Azure Active Directory, there are two regions: West US and East US. Each region has two session hosts running a multi-session operating system (OS), A server running Azure AD Connect, an Active Directory Domain Controller, an Azure Files Premium File share for FSLogix profiles, a storage account, and a virtual network (VNET). In the primary region, West US, all resources are turned on. In the secondary region, East US, the session hosts in the host pool are either turned off or in drain mode, and the Azure AD Connect server is in staging mode. The two VNETs in both regions are connected by peering.
 
-:::image type="content" source="media/shared-host-pool-recovery.png" alt-text="A diagram of a deployment using the recommended shared host pool disaster recovery strategy described in the previous paragraph.":::
+:::image type="content" source="media/shared-host-pool-recovery-new.png" alt-text="A diagram of a deployment using the recommended shared host pool disaster recovery strategy described in the previous paragraph.":::
 
 In most cases, if a component fails or the primary region isn't available, then the only action the customer needs to perform is to turn on the hosts or remove drain mode in the secondary region to enable end-user connections. This scenario focuses on reducing downtime. However, a redundancy-based disaster recovery plan may cost more due to having to maintain those extra components in the secondary region.
 
@@ -97,15 +97,15 @@ When using this disaster recovery strategy, it's important to keep the following
 
 - Having multiple session hosts online across many regions can impact user experience. The managed network load balancer doesn't account for geographic proximity, instead treating all hosts in a host pool equally.
 
-- Having multiple active user sessions across regions using the same FSLogix cloud cache can corrupt user profiles. We recommend you have only one active Azure Virtual Desktop session using the same FSLogix cloud cache at a time. The service evaluates RemoteApps as multi-session occurrences, and desktops as single-session occurrences, which means you should avoid multiple connections to the same FSLogix profile.
+- During a disaster, users will be creating new profiles in the secondary region. You should store any business- or mission-critical data in OneDrive ([using known folder redirection](/sharepoint/redirect-known-folders)) or Sharepoint. Storing data here will give users quick access to their applications with minor disruption to the user experience.
 
 - Make sure that you configure your virtual machines (VMs) exactly the same way within your host pool. Also, make sure all VMs within your host pool are the same size. If your VMs aren't the same, the managed network load balancer will distribute user connections evenly across all available VMs. The smaller VMs may become resource-constrained earlier than expected compared to larger VMs, resulting in a negative user experience.
 
 - Region availability affects data or workspace monitoring. If a region isn't available, the service may lose all historical monitoring data during a disaster. We recommend using a custom export or dump of historical monitoring data.
 
 - We recommend you update your session hosts at least once every month. This recommendation applies to session hosts you keep turned off for extended periods of time.
 
-- Test your deployment by running a controlled failover at least once every six months.
+- Test your deployment by running a controlled failover at least once every six months. Part of the controlled failover could mean your secondary location becomes primary until the next controlled failover. Changing your secondary location to primary allows users to have nearly identical profiles during a real disaster.
 
 The following table lists deployment recommendations for host pool disaster recovery strategies:
 
@@ -114,7 +114,7 @@ The following table lists deployment recommendations for host pool disaster reco
 | Network           | Create and deploy a secondary virtual network in another region and configure [Azure Peering](../virtual-network/virtual-network-manage-peering.md) with your primary virtual network. |
 | Session hosts     | [Create and deploy an Azure Virtual Desktop shared host pool](create-host-pools-azure-marketplace.md) with multi-session OS SKU and include VMs from other availability zones and another region. |
 | Storage           | Create storage accounts in multiple regions using premium-tier accounts.  |
-| User profile data | Create separate [FSLogix cloud cache GPOs](/fslogix/configure-cloud-cache-tutorial) pointing at separate Azure Files SMB locations using Azure storage accounts in different regions.   |
+| User profile data | Create SMB storage locations in multiple regions.   |
 | Identity          | Active Directory Domain Controllers from the same directory. |
 
 ## Disaster recovery for personal host pools
@@ -148,6 +148,8 @@ When using this disaster recovery strategy, it's important to keep the following
 
 - We recommend you avoid using FSLogix when using a personal host pool configuration.
 
+- Virtual machine provisioning isn't guaranteed in the failover region.
+
 - Run [controlled failover](../site-recovery/azure-to-azure-tutorial-dr-drill.md) and [failback](../site-recovery/azure-to-azure-tutorial-failback.md) tests at least once every six months.
 
 The following table lists deployment recommendations for host pool disaster recovery strategies:

articles/virtual-desktop/disaster-recovery.md

@@ -87,97 +87,6 @@ There are three ways to keep the domain controller available:
    - Use an on-premises Active Directory Domain Controller
    - Replicate Active Directory Domain Controller using [Azure Site Recovery](../site-recovery/site-recovery-active-directory.md)
 
-## Replicating user and app profile data
-
-If you're using profile containers, the next step is to set up data replication to the secondary location.
-
-You have five options to store FSLogix profiles:
-
-   - Storage Spaces Direct (S2D)
-   - Network drives (VM with extra drives)
-   - Azure Files
-   - Azure NetApp Files
-   - Third-party storage services available on the Azure Marketplace
-
-For more information, check out [Storage options for FSLogix profile containers in Azure Virtual Desktop](store-fslogix-profile.md).
-
-If you're setting up disaster recovery for user profiles, then you'll need to either use the storage service to replicate the data to another region or use FSLogix Cloud Cache to manage the replication without using the underlying storage service to replicate the data.
-
-Let's go over the five options for user profile disaster recovery plans in more detail in the following sections.
-
-### Native Azure replication
-
-One way you can set up disaster recovery is to set up native Azure replication. For example, you can set up native replication with  Azure Files Standard storage account replication, Azure NetApp Files replication, or Azure File Sync for file servers.
-    
->[!NOTE]
->NetApp replication is automatic after you first set it up. With Azure Site Recovery plans, you can add pre-scripts and post-scripts to fail over non-VM resources replicate Azure Storage resources.
-
-### Storage Spaces Direct
-
-Another option you can use is Storage Spaces Direct. Since Storage Spaces Direct handles replication across regions internally, you don't need to manually set up the secondary path.
-
-### Network drives (VM with extra drives)
-
-You can use VMs with extra drives for disaster recovery, too. If you replicate the network storage VMs using Azure Site Recovery like the session host VMs, then the recovery keeps the same path, which means you don't need to reconfigure FSLogix.
-
-### Azure Files
-
-Azure Files supports cross-region asynchronous replication that you can specify when you create the storage account. If the asynchronous nature of Azure Files already covers your disaster recovery goals, then you don't need to do extra configuration.
-
-If you need synchronous replication to minimize data loss, then we recommend you use FSLogix Cloud Cache instead.
-
->[!NOTE]
->This section doesn't cover the failover authentication mechanism for Azure Files.
-
-### Azure NetApp Files
-
-You can also use Azure NetApp Files to replicate your Azure resources. Learn more about Azure NetApp Files at [Create replication peering for Azure NetApp Files](../azure-netapp-files/cross-region-replication-create-peering.md).
-
-### FSLogix configuration
-
-The FSLogix agent can support multiple profile locations using the standard [VHDLocations](/fslogix/profile-container-configuration-reference#vhd-locations) option. This method doesn't have anything to do with the Cloud Cache, so if you'd rather use the cache, skip ahead to [FSLogix Cloud Cache](#fslogix-cloud-cache). This option also doesn't replicate data, but instead allows you access to multiple storage providers that the FSLogix agent can look in to find or create your user profile. This option separately requires storage replication so that the profile can be made available in the secondary region.
-
-To configure the registry entries:
-
-1. Open the **Registry Editor**.
-2. Go to **Computer** > **HKEY_LOCAL_MACHINE** > **SOFTWARE** > **FSLogix** > **Profiles**.
-   
-     > [!div class="mx-imgBorder"]
-     > ![A screenshot of the Profiles window in the Registry Editor. VHDLocation is selected.](media/regedit-profiles.png)
-
-3. Right-click on **VHDLocations** and select **Edit Multi-String**.
-
-     > [!div class="mx-imgBorder"]
-     > ![A screenshot of the Edit Multi-String window. The value data lists the Centrual US and East US locations.](media/multi-string-edit.png)
-
-4. In the **Value Data** field, enter the locations you want to use.
-5. When you're done, select **OK**.
-
-If the first location is unavailable, the FSLogix agent will automatically fail over to the second, and so on.
-
-We recommend you configure the FSLogix agent VHDLocation registry setting with both storage locations in both of the Azure locations you've deployed them. To configure the VHDLocation registry setting, you'll need to set up two different group policies. The first group policy is for the session hosts located in the primary region with the corresponding storage locations ordered with the primary first and the secondary second. The second group policy would be for the session hosts in the secondary location with the storage options reversed, so that the secondary storage location is listed first for only the VMs in the secondary or failover site.
-
-For example, let's say your primary session host VMs are in the Central US region, and the profile container is also in the Central US region for performance reasons. In this case, you'd configure the FSLogix agent with a path to the storage in the Central US region listed first. Next, you'd configure the storage service you used in the previous example to replicate to the West US region. Once the path to Central US fails, the agent will try to load the profile in West US instead.
-
-### VHDLocations
-
-VHDLocations contributes to business continuity, but this setting wasn't only designed to be one part of a complete high availability or disaster recovery solution. The VHDLocations setting enables users to use a replicated or new profile in the event of a disaster, keeping users productive even in the event of an outage.
-
-Here's how VHDLocations works, as well as some things you should consider if you plan to make VHDLocations part of your disaster recovery strategy:
-
-- If the primary storage is unavailable for whatever reason and a user signs in, the FSLogix agent won't be able to access the existing user profile from that primary share. The user can still sign in, but FSLogix will either use the profile it finds in the secondary storage location (if you've already replicated it with storage replication) or it'll create a new profile on the secondary share. Because the user is now using either a replicated or new profile, they won’t be using their original profile. When they use this secondary profile, any updates they make will apply only to the secondary profile. They won't be able to access their original profile until the primary storage becomes available again and they sign back in.
-
-- Once the primary storage is available again, the user won't be able to merge changes they made in the secondary or new profile back into the original profile. When a user signs in after the primary share is available again, they will return to using their original profile as it was before the disaster. Any changes they made in the secondary or new profile during the disaster will be lost.
-
-### FSLogix Cloud cache
-
-FSLogix supports replicating user and Office containers from the agent running on the session host itself. While you'll need to deploy multiple storage providers in multiple regions to store the replicated profiles, you won't need to configure the storage service's replication capabilities with multiple entries like you did with the VHDLocations settings in the previous section. However, before you start configuring FSLogix Cloud cache, you should be aware this method requires extra processing and storage space on the session host itself. Make sure you review [Cloud Cache to create resiliency and availability](/fslogix/cloud-cache-resiliency-availability-cncpt) before you get started.
-
-You can configure FSLogix Cloud Cache directly in the registry based on the VHDLocations example in the previous section. However, we recommend you configure the cloud cache using a group policy instead. To create or edit a group policy object, go to **Computer Configuration** > **Administrative Templates** > **FSLogix** > **Profiles Containers (and Office 365 Containers, if necessary) > Cloud Cache - Cloud Cache Locations**. Once you've created or edited your policy object, you'll need to enable it, then list all storage provider locations you want the FSLogix to replicate it to, as shown in the following image. 
-
-> [!div class="mx-imgBorder"]
-> ![A screenshot of the FSLogix Cloud Cache Group Policy Cloud Cache Locations is selected.](media/fslogix-locations.png)
-
 ## Back up your data
 
 You also have the option to back up your data. You can choose one of the following methods to back up your Azure Virtual Desktop data: