Managing OneDrive cache in Citrix Virtual Apps and RDSH environments using FSLogix Profile Containers

• Author
• Recent Posts

James Rankin

James is a consultant from the UK, specializing mainly in end-user computing, Active Directory and client-side monitoring. When not consulting for james-rankin.com, he can often be found blogging, writing technical articles and speaking at conferences and user groups.

Latest posts by James Rankin (see all)

• Can’t uninstall app: Delete or change Windows apps that have been flagged as non-removable - Thu, Mar 16 2023
• FSLogix VHDX compaction: Resize virtual disks - Thu, Dec 1 2022
• Sysinternals Process Monitor: Real-time file system, registry, and process monitoring - Fri, Oct 28 2022

OneDrive on RDSH

OneDrive is rapidly becoming widely adopted within enterprises. Given that it ships as part of the Office 365 subscription, it is seeing massive uptake because it incurs no further cost when compared to other services such as Dropbox, Box, and ShareFile.

For users who work in RDSH environments (with or without Citrix Virtual Apps, a common add-on) where many users log on to the same shared system for their desktop or apps, integrating OneDrive brings a new set of challenges.

Citrix Virtual Apps or RDSH (or even Microsoft's new offering, Windows Virtual Desktop) typically provide their resources from multiuser systems. A single virtual or physical box can service many users simultaneously. Typically, modern RDSH systems (whether running on server operating systems or using Microsoft's new Azure-only multisession Windows 10 variant) service between 10 and 50 users per box, depending on resources. These systems are typically what we call "nonpersistent" in that the devices don't store any of the user's profile information between sessions.

When adding OneDrive as an available application for these types of users, one very specific problem becomes apparent: that of storage. Because OneDrive caches a local copy of the data into the user session, all users now have much larger storage requirements on each server they may potentially hit. Given that OneDrive offers 1 TB of storage to all users, even if they only use a fraction of that, you are talking about a potentially massive overhead required in local storage for each system servicing these users.

Mitigations

The natural reaction is to try to mitigate this first by moving that data off somewhere else, such as a network file share or another file storage service. However, this goes against the grain of OneDrive in that it is supposed to have a locally cached copy you can then synchronize with online storage. Also moving the default folder for large numbers of users can prove to be tricky.

OneDrive Files On Demand is a feature that may help with this so that it only synchronizes files with the local cache upon access. While this is a good starting point, it has two drawbacks. First, the Files On Demand feature requires Windows Server 2019 for those who are servicing their RDSH-based users from server operating systems. Secondly, the users could still access lots of large files during a session and put a strain on the local cache despite using this feature.

Given these storage requirements, enterprises can become unwilling to offer the full-fat OneDrive sync client from within RDSH, Citrix Virtual Apps, or other multiuser shared environments. I have seen many enterprises where OneDrive access is only available using the online web client, which makes for a much less feature-rich experience for the user.

FSLogix Profile Containers

Microsoft acquired FSLogix back in November 2018 with the intention of folding the suite into the Office 365 service. All customers with the following licenses can use FSLogix:

• Microsoft 365 E3/E5
• Microsoft 365 A3/A5/ Student Use Benefit
• Microsoft 365 F1
• Microsoft 365 Business
• Windows 10 Enterprise E3/E5
• Windows 10 Education A3/A5
• Windows 10 Virtual Desktop Access (VDA) per user
• Remote Desktop Services (RDS) Client Access License (CAL)
• RDS Subscriber Access License (SAL)

Customers can use it in the cloud or on premises and on all Windows 7/Server 2008 R2 or newer operating systems.

The Profile Containers solution works in a similar way to Microsoft User Profile Disks (UPD), although the underlying code is different. It mounts the user's profile at logon time to a virtual hard disk (VHD) in a remote location, and the operating system addresses it as local storage. FSLogix has certain features beyond the UPD capabilities, such as being able to address multiple sessions. It captures the user's profile from the root, allowing smooth roaming of the entire user state between sessions running the same profile version.

Because OneDrive synchronizes data into the user profile at %SYSTEMDRIVE%\Users\%USERNAME%\OneDrive, the Profile Container solution also encompasses capturing the OneDrive cache. Therefore, the synchronized data roams around with the user but does not need to resync at next logon to a (potentially) different machine, thus consuming no storage on the multiuser system. The container also captures the OneDrive user-based installation and configuration items, ensuring a seamless transition for the user between sessions.

Of course, OneDrive still needs to store the data somewhere—it just no longer needs to write it to every single device the users can access. So we avoid the temporary storage uplift required on each multiuser system to hold the users' caches and also the requirement to resynchronize at every logon, which can be time-consuming and can affect performance badly. The file share or shares that hold the VHD files still must have enough capacity to hold the users' cached data.

Setting up FSLogix Profile Containers to synchronize OneDrive: file storage

First, you need to set up a Server Message Block (SMB) file share that will hold the VHD files. This does not necessarily need to be a Windows file server; it can be anything addressable as an SMB location. So you can use standard file shares, Azure storage accounts, a Simple Storage Service (S3) storage fronted with a Storage Gateway, Amazon FSx, and so on.

You can configure multiple file shares for resilience, fronted via Distributed File System (DFS) or a load balancer, use FSLogix's native CloudCache feature for replication across multiple targets, and so forth—there are many options around this that are out of scope for this article.

Once you have created the file share to hold the containers, you need to make sure the permissions are correct as below:

Share permissions

• Authenticated Users, Full Control

NTFS permissions on the profile share root

• CREATOR OWNER – Full Control (Apply onto: Subfolders and Files Only)
• SYSTEM – Full Control (Apply onto: This Folder, Subfolders, and Files)
• Administrators – 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)

Once this is done, users should be able to create folders within the profile root and have full control of their created folders only.

Installing the FSLogix software

The next step is to download the FSLogix Apps software and install it into your master image or deploy it to your systems. The setup requires no specific configuration at install time—simply accept the defaults.

Setting up FSLogix Apps

Within the FSLogix install files, there are Group Policy .admx and .adml files used to configure the software. Copy these files into your PolicyDefinitions folder or central store to access the FSLogix Group Policy Object (GPO) settings.

Copying the FSLogix Group Policy files

Opening up Group Policy Management should show you the FSLogix settings available underneath the Administrative Templates client-side extensions (CSE) as below:

FSLogix Group Policy settings

Group Policy configuration

You should configure the following settings to keep the Profile Containers solution as simple as possible. Configure all of these settings within Computer Configuration > Admin Templates > FSLogix > Profile Containers.

Enabled (turns on the Profile Container setting):

Enabled setting

VHD location (set to the SMB share where profiles will be stored):

VHD location

Dynamic VHD(X) allocation: this will expand the profiles as required, enabling administrators to see the actual size users' profiles use rather than committing the entire size at creation time.

Dynamic VHD(X) allocation

Size in MBs: specifies the maximum file size for profiles to grow to (the default is 30 GB)—100 GB is a good maximum (obviously it will not use this unless the user's profile grows to this size). In practice the biggest users I have seen grow to about 30–40 GB, but this can depend entirely on many factors, so you may need to do some sizing based around your available storage and user behavior.

Size in MBs

Swap directory name components: I always recommend using this setting as this stores the profile folders as USERNAME_SID rather than the other way around, making it easier to find user profiles in the list.

Swap directory name components

Virtual disk type: set this to VHDX for best performance (unless you are running older operating systems that do not support the VHDX file type).

Virtual disk type

Redirect temporary file folders to local computer: this setting means that the temporary folders for the user do not get saved into the container.

Redirect temporary file folders to local computer

Once these settings are in place, you will have the basic requirements set up to synchronize OneDrive data. You can explore additional settings as required.

Installing the OneDrive client

You will also need to install the OneDrive sync client onto your master image or target devices. Simply download the OneDrive machine installer from Microsoft and run it on the target devices with the /ALLUSERS switch.

The OneDrive installer

You can also configure OneDrive GPOs as required here. (The one you absolutely must configure is to allow the OneDrive sync client to run!)

I recommend using the silent sign-in option for OneDrive here if possible so the user does not have to provide credentials. It may also be an idea to turn on Files On Demand if you so wish so that only required files are synchronized into the VHD container, reducing the demand on the storage. In my experience, users seem to access less than 35% of the files they have saved into OneDrive.

Testing

If you log on to one of your configured systems, you should see a VHD container created for the user (you can look in the file share to see this, or run Disk Management and see if a VHD is mounted):

VHD container

Disk Management

Once the users sign in to OneDrive, they should see their files synchronizing into their OneDrive folders, but they will use no disk space on the devices they are logged into because it redirects the entire profile to the Profile Container.

OneDrive synchronization

If you log out and log back in to a different device, the OneDrive folder should be immediately available and synchronized, irrespective of whether the user has logged on to that device previously.

One final note is that sometimes you can see within the Explorer directory structure both a "personal" OneDrive folder and an "enterprise" OneDrive folder. If this happens, simply remove the following key from the Registry for the user (Group Policy Preferences would be an ideal way to achieve this):

HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Desktop\Namespace\{018D5C66-4533-4307-9B53-224DE2ED1FE6}

The directory structure will now show only the "enterprise" OneDrive folder.

Summary

FSLogix Profile Containers offer an easy way to avoid the main problems encountered with OneDrive Sync Client in RDSH environments, mainly those around local storage requirements and synchronization issues, with no extra cost.