- 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.
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:
- 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.
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.
Opening up Group Policy Management should show you the FSLogix settings available underneath the Administrative Templates client-side extensions (CSE) as below:
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):
VHD location (set to the SMB share where profiles will be stored):
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.
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.
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.
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).
Redirect temporary file folders to local computer: this setting means that the temporary folders for the user do not get saved into the container.
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.
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.
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):
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.
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):
The directory structure will now show only the "enterprise" OneDrive folder.
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.
Want to write for 4sysops? We are looking for new authors.
Tanks for your time for this blog. I installed FSLogix and OneDrive on my RDSHs. Everything is working. But I'm curious with files on demand. Do you know, if files that have been downloaded and are available in the profile, get deleted so they are only available online? Otherwise over time, the storage consumption in the profile could increase. In extrema, it would increase to the 1TB, the user has.
Just want to participate in your experience with this…
With FSLogix once downloaded, the space is not reconciled even if you delete them. If you wish to shrink them, you would need to run maintenance to do this (Jim Moyle has a script that can do this, at https://github.com/FSLogix/Invoke-FslShrinkDisk).
In my experience I haven't seen users go past the 40GB mark for the entire size of their profile, data and Outlook cache. But it is important to size correctly and monitor the utilization.
Have you seen this issue before. I have setup FSlogix Profile Containers, all is working well apart from an error with OneDrive.
A fresh user logs on and completes the initial OneDrive configuration and the user logs off. The user logs on for the 2nd time and OneDrive displays the error “OneDrive isn’t Signed in – Please enter your sign-in info to start syncing again”. Click Ok and OneDrive does sign in. All subsequent logons are fine.
Did you find any solution for this problem?
I installed onedrive and use windows authentication to login and Files on demand on server 2019. Now when i login i cannot access the Onedrive folder because we blocked c: drive access with RES Powerfuse/Ivanti. It is also still using files. Do i need to use folder redirection or how can i solve this?
Thanks for the information.
We had to unrestrict the C drive to be able to access the OneDrive cache, but you can still hide the C: via GPO. Not ideal, but it's the only way other than only accessing it online with no local cache.
I too have concerns over the size of the local cache. There are 2,000 users at my workplace which logon to Citrix (not all at the same time fortunately) and If we give them 100GB profiles, then that works out at 200TBs. The SAN doesn't have that much and with using Office 365 we also have to have caching for Outlook, which could take up a similar amount of disk space. Ironically, moving to the cloud could greatly increase the amount of onprem storage required!
Hi James, great article and works perfectly as described, but of course there is again the need of more. 🙂
I do want/need to use the backup feature of onedrive and the folder redirection from the known folders to onedrive – any clue how this can be made work? Tried it but end up in a synchronisation error – files get synched from the regular desktop up to onedrive but Onedrive folder redirection does not seem to work when FSLogix is enabled – but maybe I just have misconfigured it.
we have only used FSLogix office container in our migration to OneDrive in Citrix environment. Profile is managed by UPM. So will it also work the same way as “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”.