Building a Multi-Region Disaster Recovery Environment for Amazon AppStream 2.0

A Little Context

1. Administrators the ability to create or integrate Amazon AppStream 2.0 users with existing organizational home folder and filing structures.
2. Replication of user profile begins when the user logs on to their virtual desktop and Cloud Cache copies the incremental changes to DR location automatically.
3. AppStream 2.0 users can share folders between different AppStream fleets, which was challenging when using S3 for home folders.
4. Terabytes of user profile and other data stored on premise can be accessed securely and remotely using AppStream 2.0 and Amazon FSx File Gateway, which provide seamless read and write activity when files are shared between their on-premises locations and the cloud. Users will have a similar experience inside a virtual desktop as they do on-premise using a physical laptop\device.
5. Fine grained access control of data from a central source such as Active Directory (AD) that integrates with existing onboarding workflows and security folder monitoring tools.
6. Reduces administration by removing the need to maintain a full list of inclusions and exclusions for profile roaming.

Prerequisites

1. Read through Disaster Recovery considerations with Amazon AppStream 2.0 to understand new region scaling limits per account and image considerations.
2. An existing domain joined Amazon AppStream 2.0 fleet in a stopped state and a stack that does not have Application Settings Persistence enabled.
3. Active Directory Services in both Primary (Frankfurt) and Disaster Recovery (DR) region (London). In this blog, I am using AWS Managed AD with multi-region replication enabled. You can also use a self-managed Active Directory installed on an EC2 instance or your on premise Active Directory with network connectivity between the locations.
4. An existing Windows File Server or Amazon FSx For Windows File System used for profile storage, check this blog post for setup instructions.
5. The VPC subnets for Amazon AppStream 2.0 in primary and disaster recovery region, must be able to connect on port 445, to both primary and disaster recovery FSx for Windows File Systems.
6. Both VPCs connected via Transit Gateway or VPC Peering (VPC peering is preferable in most settings).
7. A SAML IdP such, deployed in two or more regions like Okta, which is able to endure a region failure.

Solution Overview

1. Set up file share and folder permissions to store user profile data.
2. Set up share permissions to allow data write and replication over network.
3. Install and configure FSLogix on the Amazon AppStream 2.0 ImageBuilder.
4. Set up the Group Policy to configure FSLogix.
5. Create an Amazon AppStream 2.0 image.
6. Copy the Amazon AppStream 2.0 image to the DR region.
7. Recreate the Amazon AppStream 2.0 Stack configuration in the DR region.
8. Set up your SAML IdP.
9. Test if Disaster Recovery is working as expected.

Deploy the Solution

Step 1: Set Up File and Folder Permissions

1. The first step is to create a folder on both your primary and DR file servers to store your user profile containers, in this blog I will be using FSx for Windows to store my user profile containers. Create a folder on the D drive (D$) of your Primary and DR FSx file servers manually or using this PowerShell command from a domain joined machine.

1. Once the profiles folder has been created, setup the NTFS permissions on the folder as follows:

• CREATOR OWNER – Full Control (Apply onto: Subfolders and Files Only)
• SYSTEM – Full Control (Apply onto: This Folder, Subfolders and Files)
• Administrators (If self-managed AD) – Full Control (Apply onto: This Folder, Subfolders and Files)
• Users – Create Folder/Append Data (Apply to: This Folder Only)
• Users – List Folder/Read Data (Apply to: This Folder Only)
• Users – Read Attributes (Apply to: This Folder Only)
• Users – Traverse Folder/Execute File (Apply to: This Folder Only)
• You can change Users for a domain group containing the target user accounts. This could be the same group, added to the local groups on the ImageBuilder that enable inclusion (or exclusion) of Profile Containers.
• Administrators can be changed to the AWS Delegated Administrators group if using AWS Managed AD and do not have access to domain admins.

  

• Advanced permissions of profiles folder*

Step 2: Set Up Share Permissions

1. Turn the “Profiles” folder on the Primary and DR file server into a network share using the Microsoft snap-in fsmgmt.msc, please follow these steps for detailed instructions.

   

Step 3: Install and Configure FSLogix

1. Open Amazon AppStream 2.0 console choose Images and launch or connect to an existing image builder.
2. When the image builder is ready, log in as the Administrator.
3. Download FSLogix from Microsoft on the image builder and run it. Navigate through the wizard to complete installation.
4. Once installation is complete, execute lusrmgr.msc from a Run prompt to open the Local Users and Groups manager.
5. In this blog, I will not be using Office 365 Containers, As a result, we’re going to remove all members from the group called FSLogix ODFC Include List. Choose Groups and then FSLogix ODFC Include List. Remove “Everyone” from Members and then choose Apply and OK. Step 5 can also be achieved using this PowerShell one liner:

1. FSLogix Profile Include List group is the include list for dynamic profiles. Select the FSLogix Profile Include List group. Remove “Everyone” and modify the list of Members so that your Security Group for AppStream 2.0/FSLogix users is included. Choose Apply and OK.

Step 4: Set Up the Group Policy to Configure FSLogix

1. Copy fslogix.admx in to your Active Directory's Sysvol directoryTypically located at:```powershell
   \%USERDOMAIN%\SYSVOL%USERDOMAIN%\Policies\PolicyDefinitions
2. Next Copy fslogix.adml to```powershell
   \%USERDOMAIN%\SYSVOL%USERDOMAIN%\Policies\PolicyDefinitions\en-US
3. Create a GPO to be linked to the Amazon AppStream 2.0 computer objects. Edit the GPO and enter the settings:
4. Go to Computer configuration > Policies > Administrative Templates > FSLogix > Profile containers. Set Enabled to Enabled
5. Delete Local Profile when FSLogix Profile should apply Enabled (Please use caution with this setting. When the FSLogix Profiles system determines that a user should have a FSLogix profile but a local profile exists, the local profile will be removed and the user is logged on with the FSLogix profile.)
6. Go to Profile Containers > Cloud Cache and set Clear local cache on logoff > Disabled
7. Go to Computer configuration > Policies > Administrative Templates > FSLogix > VHD Compact Disk. This setting can also be listed as Disk Compaction in older versions of FSlogix, see this link for version history 2210.
8. IsDynamic: If enabled, the profile container uses the minimum space on disk regardless of what is specified in SizeInMBs. As your user profile container grows in size, the amount of data on disk will grow up to the size specified in SizeInMBs. Note: When the data is deleted inside the user environment, the VHD(x) file size on disk will automatically shrink if a feature called VHD Disk Compaction is enabled and configured. In older versions of FSlogix, free space would not be reclaimed and users would need to run commands or a script in order to periodically remove empty blocks from a dynamically-expanding virtual hard disk file.
9. Please disable the VHDLocations if you are using it and only enable CCDLocations for Cloud Cache.
10. Cloud Cache locations (no spaces, one line and in this order, replace fsxPrimary.asx.local and fsxDR.asx.local with your storage server DNS names accordingly.)```
    type=smb,connectionString=\fsxPrimary.asx.local\Profiles;type=smb,connectionString=\fsxDR.asx.local\Profiles
11. Swap directory name -> Go to Computer configuration > Policies > Administrative Templates > FSLogix > Profile containers > Container and Directory Naming > Swap directory name components > Check the box (When checked causes new containing directories to be named with the user name first followed by the SID.)
12. Log Settings (Optional): Go to Computer configuration >
    Policies > Administrative Templates > FSLogix >Enable
    Logging
    More details on logging can be found here

Step 5: Create an Amazon AppStream 2.0 Image

1. Finish creating your AppStream 2.0 image using the Image
   Assistant.
2. Once the image is ready, deploy your AppStream 2.0 image to a domain joined fleet in the primary region. Verify that the native “application settings persistence” AppStream 2.0 feature has been disabled on the associated stack.
3. Start the fleet, if your fleet was already running, stop and start the fleet in order to get the new GPO applied at start-up.

Step 6: Copy the Image to the DR Region

1. To copy an image to another AWS Region, launch the AppStream 2.0 console and select the region that contains your existing image. In the navigation pane, choose Images, select your existing image that has FSLogix installed, choose Actions, select Copy, and then pick your target AWS Region. You can also use the CopyImage API to programmatically copy images. Visit Tag and Copy an Image for more information.

Step 7: Recreate the Amazon AppStream 2.0 Configuration in the DR Region

1. Recreate Amazon AppStream 2.0 stack in DR region with the exact same stack name case sensitive. This will allow for easy switch between regions using one IAM role and policy.
2. Create the fleet in the DR region with the same fleet name, case sensitive and using the image that was prepped with FSLogix in Step 3 and copied to DR region.

Step 8: Setup Your SAML IdP

1. In this example, I am using Okta as my SAML Identity provider(IdP). Log in to your IdP admin console. From the left panel, select Applications > Applications. Select Browse App Catalog and search for “AWS Account Federation.” Select the AWS Account Federation app and choose Add Integration.

   

2. Change the Application label to something descriptive to represent your primary region and choose next

   

3. To avoid duplication, follow steps found in blog post Improve the Availability of Existing Okta IAM Federation Setup Using Multi-Region SAML Endpoints.

1. Create an IAM role for SAML 2.0 Federation following Step 2.

1. Replace okta, oktaLondon, eu-west-2, 0123456789 and eu-central-1 with values that match your environment.
2. Edit your Okta user assignments to use the Okta role created in step 8.4. Log into your Okta admin console. From the left panel, select Application > Application. Select the Application, In this blog it is called AppStream Primary, Select Assignments, Edit (pencil icon), Select the correct Role, in my account it is called “oktarole”, edit the users domain (@as2.local) in the UserName field to match the Amazon AppStream 2.0 fleet domain, if needed and Save. Repeat for DR region.

Step 9: Test if DR Is Working As Expected

1. Login to your IdP dashboard, and connect to the Amazon AppStream 2.0
   fleet in your primary region using the okta application tile.
2. Once connected to the fleet, use file explorer to connect to your
   SMB locations```powershell
   \FSxPrimaryDNSName\Profiles

1. Add some files to your Documents folder.

1. Verify profiles sizes have increased in both Primary and DR SMB locations.

1. End the Amazon AppStream 2.0 streaming session.
2. Simulate a region failure by blocking all inbound TCP port 445 to Primary SMB location.
3. Connect to your Okta DR application, in my example the Okta application would be called “AppStream 2.0 DR”.
4. If you have logged in and your documents are all there, it means at this point you have successfully failed over and working in the DR region.
5. Add some more test files to your Documents folder on the DR fleet which will automatically get synced back once the Primary file server port 445 is reachable from the DR fleet.
6. Enable Inbound TCP port 445 for Primary file server SMB location and verify that all the newly added files from DR fleet have synced back to your primary region.
7. After testing, you can stop the fleet in your DR region to save on running costs.

Clean Up:

1. Unlink and delete the FSLogix GPO you created in the section Setup Group Policy to Configure FSLogix. If you want, you can remove the FSLogix Administrative templates you deployed to your central store.
2. Remove users from your AppStream 2.0/FSLogix Active Directory group.
3. Delete your Amazon FSx for Windows File Server file systems in both regions.
4. Delete or stop any AppStream 2.0 fleets, images, stacks, and image builders you have created specifically for this blog.
5. Delete the IAM Roles and SAML Identity providers
6. Delete the Okta Applications created for this blog

Conclusion