Optimize user experience in Amazon WorkSpaces across AWS Regions

Providing a consistent end user experience is important for productivity, especially during disruptive events. By preparing for failure, you can enable users to continue working as normal without having to learn new business processes. Amazon WorkSpaces, a persistent desktop solution deployed in an AWS Region, offers the Multi-Region Resilience (MRR) feature to help deploy WorkSpaces in multiple Regions for business continuity and disaster recovery.

In this blog post, we’ll demonstrate how to incorporate Microsoft FSLogix CloudCache for data replication and Amazon Route 53 to automatically switch to standby Amazon WorkSpaces. This solution is designed for Amazon WorkSpaces using the Auto-Stop running mode. It does not apply to Always-On WorkSpaces.

Amazon FSx for Windows File Server is an excellent option for storing FSLogix Cloud Cache user profile data. Amazon FSx is a fully managed service that integrates with AWS Backup, offers Multi-AZ deployment options to increase high availability, integrates with Microsoft Active Directory, and provides flexibility to scale file system size or performance as user needs change.

Overview of solution

When the user connects to their primary WorkSpace, their profile data gets created in the FSLogix Cloud Cache locations, both in primary and secondary Regions. These locations on separate WorkSpaces are continuously updated with user profile data when the profile is updated. If the primary Amazon WorkSpaces fails, the Amazon Route 53 service will redirect WorkSpaces connections to the secondary Region (Standby WorkSpaces), and the user’s profile from the secondary Region’s Cloud Cache location will be used.

Later, when the primary WorkSpace is restored, the user’s WorkSpaces connection is routed back to the primary Region, and the primary Region’s FSLogix Cloud Cache is updated from the secondary Region’s FSLogix Cloud Cache. This ensures that the end user experience is optimized during disruptive events.

Figure 1: Complete Overview of Solution Architecture

Prerequisites

• An AWS account.
• An Amazon WorkSpaces environment with MRR feature enabled (This blog uses AWS Managed Microsoft AD configured with Multi-Region replication for demonstration).
• VPCs across Multi-Regions are connected either via AWS Transit Gateway or VPC Peering
• Amazon FSx for Windows File Server in both primary and secondary Regions. (To store FSLogic Cloud cache)

• Check that you meet all entitlement requirements for FSLogix

• An AD Connector in the Primary Region to prevent FSLogix image creation failure. (AD Connector is made available to you free of charge to use with WorkSpaces)

• An AD Connector for Secondary Region. (Replicated MAD directory can be registered with WorkSpaces by configuring an AD Connector (ADC) to point to your replicated Domain Controllers)

• RSAT-enabled administrative machines to configure FSLogix in both primary and secondary Regions
• A registered/owned Route 53 domain. This can be replaced by any another DNS registrar

Important Note

Primary Region represents all resources used in the main production environment whereas, Secondary Region represents all resources for the DR environment. The primary Region will contain the following services:

• Amazon WorkSpaces
• AWS Managed Microsoft AD
• FSx for Windows File Server
• Access to the RSAT management instance as a domain admin
• An AWS AD Connector associated with the imaging WorkSpace.
• A Route 53 health check configured against a CloudWatch alarm is used to simulate a failover in this architecture.
• AWS Transit Gateway or VPC Peering (to connect VPCs across Region)

The Secondary Region will contain the following services for the DR resources:

• Amazon WorkSpaces
• AWS Managed Microsoft AD (replicated domain controller)
• An AWS AD Connector (replicated MAD Regions cannot be directly registered with WorkSpaces, however a replicated MAD directory can be registered with WorkSpaces by configuring an AD Connector (ADC) to point to your replicated Domain Controllers.)
• FSx for Windows File Server
• Separate RSAT management instance.
• AWS Transit Gateway or VPC Peering (to connect VPCs across Regions)

Walkthrough

Configure Failover Monitoring
In this step, we control how users are routed between the primary and secondary Regions. WorkSpaces users connect to their WorkSpace via a connection alias defined in a Route 53 failover record. A CloudWatch alarm monitors the maintenance mode of the WorkSpace in the primary Region. When maintenance mode is enabled, users are redirected to the WorkSpace in the secondary Region.

Figure 2: Failover Monitoring Components

In this blog post, we will create an Amazon SNS topic to receive notifications from the CloudWatch alarm. The SNS topic is used as the notification channel, but no email or SMS subscriptions will be configured, as this is for demonstration purposes only.

Step 1. Create a connection alias

1. In the WorkSpaces console select Account Settings and choose Create connection alias
2. Under Connection string enter the FQDN such as example.com. In this blog example.com is the registered zone in Route 53
3. Select Create connection alias to complete the alias creation
4. Select the alias, choose Actions and select Associate/disassociate
5. Under Select a directory select the directory containing the workspaces in the primary Region and select Associate to complete directory association
6. Repeat steps 1-5 for the secondary Region. The connection alias in the secondary Region must match the alias in the primary Region
7. In both Regions select the alias and get the value of the Connection identifier. This will be used later when creating the failover record

Step 2: Configure the CloudWatch alarm

1. In the SNS console create a standard SNS topic
2. In the CloudWatch alarms console select Create alarm. Search for in the primary Region and select the This metric applies to WorkSpaces that are configured with an AutoStop running mode. If you have maintenance enabled for your WorkSpaces, this metric captures the number of WorkSpaces that are currently under maintenance
3. Change the Period to 1 minute. This will reduce RPO times as our alarm is now being monitored every minute
4. Select Greater/Equal and change the value of Define the threshold value to 1. Select Next
5. Choose the SNS topic created in step 1 and select Next
6. Choose an alarm name, select Next and choose Create alarm

Step 3: Configure the Route 53 health check

1. In the Route 53 health check console select Create health check
2. Under What to monitor, select State of CloudWatch alarm. Change the CloudWatch Region to the primary Region, select the alarm created in step 2. and choose Next
3. Select Create health check to complete the health check creation

Important Note
When failover is initiated by the CloudWatch alarm, all WorkSpaces will failover to the secondary region. If you want to manually decide to failover between regions, do not configure automated failover as outlined in Step 4.

Step 4: Create the Route 53 failover record

1. In the Route 53 console select your hosted zone and choose Create record.
2. Change the record name to match your connection alias
3. Change the record type to TXT
4. In the Value box use the connection identifier from the primary Region
5. Change the Routing policy to failover
6. Change the Failover record type to Primary
7. Change Health check ID to the health check created in step 3.1
8. Under Record ID select an identifier for the record. For example, this could be Primary Region
9. Select Add another record
10. Repeat steps 4.1-4.5 using the Connection identifier from the secondary Region

• Change the Failover record type to Secondary for the secondary record
• Under Record ID for the secondary Region select an identifier for the record. For example, this could be Secondary Region
• Select Create records to complete the Route 53 record creation process

To confirm that records works as expected, we use the Resolve-DnsName cmdlet as follows:

Resolve-DNSName workspaces.example.com -type TXT

Figure 3: PowerShell Command Showing Default Region

In the WorkSpaces console select the Workspace in the primary Region used for the CloudWatch alarm. Select Actions, choose Modify state, select Maintenance and choose Save. When the Route 53 health check reports alarm, we can confirm that the DNS traffic gets routed to the secondary Region:

Figure 4: PowerShell Command Showing Failover Region During Disaster Recovery

For further information on Cross Region Redirection please refer to our documentation .

Configure FSx for Windows profile share and permissions

1. Connect to the RSAT management instance. Note, your user account must be a member of the AWS FSx Delegated Administrators group if using AWS Managed Microsoft AD
2. Update the variable names to include the DNS name and Powershell remote endpoint of the file system in the primary Region

   $FSxDNSName = "FSX_DNS_NAME" 
   $FSxRemotePowerShellEndpoint="FSX_POWERSHELL_ENDPOINT" 
   $Credential = Get-Credential

3. Open PowerShell and execute the commands. When prompted for credentials use a user that is a member of the AWS Delegated FSx Administrators group
   
   Figure 5: PowerShell Implementation of Solution 
4. Execute the following commands to create the Profiles directory and turn that folder into a network share

   New-Item -Path "\\$FSxDNSName\D$" -Name Profiles -ItemType Directory
   $RootShareName = "Profiles"
   Invoke-Command -ConfigurationName FSxRemoteAdmin -ComputerName $FSxRemotePowerShellEndpoint -Credential $Credential -scriptblock {New-FSxSmbShare -Name $Using:RootShareName -Path "D:\$Using:RootShareName" -Description "FSLogix Profiles Share" -Credential $Using:Credential}
   Invoke-Command -ConfigurationName FSxRemoteAdmin -ComputerName $FSxRemotePowerShellEndpoint -Credential $Credential -scriptblock {Grant-FSxSmbShareAccess -Name $Using:RootShareName -AccountName Everyone -AccessRight Full -Force}
   

5. Open fsmgmt.msc Select Action -> Connect to another computer
6. Enter the FSx DNS Name
7. Open the context (right-click) menu, select the Profiles Share -> Properties -> Security -> Advanced and select Disable inheritance, then Apply. When prompted to Convert inherited permissions into explicit permissions on this object, select Apply
8. Apply the following NTFS folder permissions required by FSLogix software. In this example POC_WorkSpacesUsers is the FSLogix WorkSpaces profile user group for this solution. Members of this group will have their user profiles stored in VHD format and stored on the Profiles network share hosted on FSx for Windows

Repeat steps 1-8 for the file system in the secondary Region.Configure Active Directory and WorkSpaces images

Active Directory configuration:

1. Create the necessary Organizational Units (OUs) and user/group accounts
2. Configure the FSLogix group policies in the POCOU-WorkSpacesPrimary and POCOU-WorkSpacesSecondary OUs

The blog uses the following environment to demonstrate the solution:

Domain – awsblog.com running on AWS Managed Active Directory.

Organizational unit list:

More details on how to update the Amazon WorkSpaces OU can be found here.

 Active Directory users and groups:

The AD structure will appear as follows:

Figure 7: Overview of Solution Active Directory Objects

Active Directory Permissions:

1. Create the OU architecture and user accounts
2. Make bloguser a member of POC_WorkSpacesUsers group
3. For AWS Managed AD make POC_FSxAdmins a member of the AWS Delegated FSx Administrators group

Group Policies To Configure FSLogix:

1. Download the FSLogix software
2. Unzip the software and copy it to your active directory SYSVOL folder. For AWS Managed AD the process is

• Create the PolicyDefinitions folder in: \\%USERDOMAIN%\SYSVOL\%USERDOMAIN%\Policies\PolicyDefinitions
• Create the en-US folder if it does not exist already: \\%USERDOMAIN%\SYSVOL\%USERDOMAIN%\Policies\PolicyDefinitions\en-US
• Copy fslogix.adml to \\%USERDOMAIN%\SYSVOL\%USERDOMAIN%\Policies\PolicyDefinitions\en-US
• Copy fslogix.admx to \\%USERDOMAIN%\SYSVOL\%USERDOMAIN%\Policies\PolicyDefinitions

Refer to this section in the FSLogix documentation for further information for on-premise domains.

3. Create a GPO for POCOU-WorkSpacesPrimary and configure the following policies. The CCD Locations setting must have the updated FSx DNS name from the primary and secondary Region

   -	Computer Configuration > Policies > Administrative Templates > FSLogix > VHD Compact Disk – Enabled
   -	Computer Configuration > Policies > Administrative Templates > FSLogix > Profile Containers > Delete Local Profile When VHD Should Apply – Enabled
   -	Computer Configuration > Policies > Administrative Templates > FSLogix > Profile Containers > Enabled – Enabled
   -	Computer Configuration > Policies > Administrative Templates > FSLogix > Profile Containers > Is Dynamic (VHD) – Enabled
   -	Computer Configuration > Policies > Administrative Templates > FSLogix > Profile Containers > Profile Type - Normal Profile
   -	Computer Configuration > Policies > Administrative Templates > FSLogix > Profile Containers > Cloud Cache > CCD Locations - type=smb,connectionString=\\<FSX_DNS_PRIMARY>.awsblog.com\Profiles;type=smb,connectionString=\\<FSX_DNS_SECONDARY>.awsblog.com\Profiles
   -	Computer Configuration > Policies > Administrative Templates > FSLogix > Profile Containers > Clear Cache on Logoff – Enabled
   -	Computer Configuration > Policies > Administrative Templates > FSLogix > Profile Containers > Container and Directory Naming > Flip Flop Profile Directory Name – Enabled
   -	Computer Configuration > Policies > Administrative Templates > FSLogix > Profile Containers > Container and Directory Naming > Volume Type (VHD or VHDX) - VHDX
   

   
   Figure 8: Permissions Configured in gpmc.msc

4. Link the GPO to POCOU-WorkSpacesPrimary
5. Create a second GPO for POCOU-WorkSpacesSecondary and configure the same policies as in step 3. Change the value of the CCD Locations setting by swapping the DNS paths
   Computer Configuration > Policies > Administrative Templates > FSLogix > Profile Containers > Cloud Cache > CCD Locations ->

   type=smb,connectionString=\\<FSX_DNS_SECONDARY>.awsblog.com\Profiles;type=smb,connectionString=\\<FSX_DNS_PRIMARY>.awsblog.com\Profiles

6. Link the second GPO to POCOU-WorkSpacesSecondary

WorkSpaces image configuration and deployment

Create a WorkSpaces instance from a public image:

1. Open the Amazon WorkSpaces console
2. Select a public image to create a base WorkSpaces instance
3. Start the WorkSpaces instance and connect using WorkSpaces Client

Install the FSLogix agent on the base instance:

1. Following the steps in the guide Install the FSLogix agent

Create a custom image and copy it to the secondary Region:

1. Create a custom image
2. Once the custom image is created, copy the image to the secondary Region

Create bundles in both Regions using the custom image:

1. Create a bundle in the primary Region from the image
2. Create a bundle in the secondary Region from the copied image

Create AutoStop WorkSpaces for the test user in both the Regions using the FSLogix bundle:

1. Create an AutoStop WorkSpace for bloguser in both the primary and secondary Regions using the FSLogix bundle.

Testing the solution:

1. Start the WorkSpace for the bloguser in the primary Region
2. Force the primary WorkSpace into maintenance mode, causing the failover to the secondary Region
3. Verify that the user can connect to the secondary WorkSpace and access the same user profile
4. Restore the primary WorkSpace and observe the user profile being synchronized back to the primary Region

Figure 9: File Transferred to Disaster Recovery Region Using FSLogix Cloud Cache

Clean up

To clean up the resources created in this blog post, follow these steps:

1. Delete the WorkSpaces in both the primary and secondary Regions
2. Delete the bundles in both Regions
3. Delete the custom image in both Regions
4. Delete the FSx file systems in both Regions
5. Delete the Route 53 failover records
6. Delete the CloudWatch alarm and SNS topic
7. Delete the AD Connector resources in both Regions
8. Delete the Organizational Units and user/group accounts from Active Directory

Conclusion

In this blog post, you learned how to configure a consistent WorkSpaces experience between primary and secondary Regions for users, in case of a Region failure, using FSLogix Cloud Cache. This solution is designed for Amazon WorkSpaces using the Auto-Stop running mode and does not apply to Always-On WorkSpaces.

For more details about Amazon WorkSpaces, Amazon FSx for Windows File Server, Amazon Route 53, and Microsoft FSLogix, refer to the provided links.

Best Practices for Deploying Amazon WorkSpaces

Amazon FSx for Windows File Server

Amazon Route 53

FSLogix documentation

	Peter-John is a Senior Cloud Support Engineer at the AWS office in Cape Town. As an AWS accredited subject matter expert, he specializes in supporting enterprise customers using AppStream 2.0 and FSx for Windows. With extensive experience helping organizations maximize their use of these AWS services, Peter-John is known for his deep technical knowledge and customer-centric approach.
	Rohit Gulati is a Sr. Cloud Support Engineer and Subject Matter Expert in Amazon WorkSpaces and AWS Directory Services based in Dublin, Ireland. Rohit has experience in Enterprise Infrastructure for over 14 years including 6 years with AWS.
	Reyaad Parker is a Cloud Support Engineer for the AWS Enterprise Applications team with over 5 years of experience. Based in Cape Town, South Africa Reyaad has become a go-to resource for complex FSx for ONTAP deployments and troubleshooting. He is continuously expanding his expertise and honing his skills to stay ahead of the curve in the rapidly evolving cloud computing landscape.