FSLogix Profile Containers on RDS: VHDX Setup, Cloud Cache, and Sizing for Multi-Session Hosts

On a Remote Desktop Session Host, roaming profiles and folder redirection were the traditional answer to “users must see the same desktop on every host.” Both are slow, both corrupt state on logoff, and both struggle with applications that write to AppData. FSLogix replaces them with a container approach: each user’s entire profile lives in a single VHDX file, mounted at logon and detached at logoff. The result is faster logons, intact application state, and profiles that survive a host rebuild.

FSLogix is now free for Windows Server and Windows 10/11 multi-session use under Microsoft’s licensing, which makes it the default profile solution for any serious Windows RDS deployment. This guide covers installation, configuration, Cloud Cache, and realistic sizing.

Why Containers Replace Roaming Profiles

A classic roaming profile copies files up at logoff and down at logon. A profile with 2 GB of cached Outlook data means a 2 GB copy each way, every session. A profile container instead mounts a single VHDX directly from a share, so the user’s data is available immediately without a copy step. The difference in logon time on a busy morning is measured in minutes per user.

Containers also fix application compatibility. Modern apps keep their state in %LocalAppData% and %AppData%, which roaming profiles handle poorly. FSLogix captures the full user profile including those paths, so Teams, Edge, and Office activation state follow the user between hosts.

Installing and Licensing FSLogix

Download the FSLogix agent installer from Microsoft and install it on every session host. Two components matter: the FSLogix Apps Services and the profile container driver. After installation, the configuration is registry-based — there is no GUI, which is exactly why it scales cleanly across hosts.

Under the multi-session entitlement, FSLogix requires either a Windows 10/11 Enterprise E3/E5 subscription or an RDS CAL plus the appropriate Windows Server licensing. Confirm your entitlement before rolling out broadly rather than after an audit.

Core Registry Settings for Profile Containers

Enable containers under HKLM\SOFTWARE\FSLogix\Profiles by setting Enabled to 1 and VHDLocations to the UNC path of your profile share, for example \fileserver\profiles$. Add VolumeType set to VHDX and SizeInMBs to your default quota, such as 30720 for a 30 GB profile.

Consider DeleteVHDWhenNotInUse carefully: leaving it off preserves the VHDX for the next logon (fast), while turning it on reclaims space but forces a rebuild. For most deployments, keep the VHDX persistent and manage growth with quotas instead.

Sizing the Profile Share and Storage

Budget for growth: a new user’s container might start around 1–2 GB, but the same profile after a year of Outlook, Teams, and browser cache often reaches 15–25 GB. Reserve at least 1.5x your expected steady-state total as free space, or thin-provision on storage that supports it and monitor aggressively.

The share must live on fast storage. Profile containers are random-read heavy at logon and random-write heavy during the session; a slow SMB share turns a container deployment back into a roaming-profile experience. Put the share on NVMe-backed storage and keep it off the same spindle as backups.

Cloud Cache for Resilience

Cloud Cache keeps a local copy of the container on each host while asynchronously syncing to one or more remote locations. If the profile share becomes unreachable, users continue working from the local copy rather than being locked out. Configure it with CCDLocations pointing at the remote shares and ClearCacheOnLogoff set to 0 for persistence.

The trade-off is local disk consumption: each host holds a cached copy of every profile that has logged on there. Size the host’s cache volume accordingly, and understand that Cloud Cache adds complexity — use it when profile-share availability is a genuine risk, not by default.

Office Container vs. Profile Container

By default FSLogix puts the whole profile in one container. For Microsoft 365 workloads, a separate Office Container can isolate the Office cache and activation data from the rest of the profile. This is useful when you want to reset user settings without forcing a full Office re-download, or when Office cache growth is the dominant storage consumer.

Decide early whether you need the split, because migrating existing containers later is more work than choosing correctly at rollout. Most small deployments are fine with a single profile container.

Testing and Rollout

Pilot on one session host with two or three users, verifying that logon creates the VHDX, that settings persist across hosts, and that logoff detaches cleanly without leaving the file locked. Only then roll out via Group Policy or a machine-level registry push. Combined with a well-sized Windows VPS or RDS host fleet, FSLogix turns profile management from a recurring source of corruption into a background service you rarely think about.

Common Failure Modes and How to Fix Them

The most frequent FSLogix problem is a VHDX that stays locked after a crash, blocking the user from logging on to any host. Enable the VHDXSectorSize and container-cleanup settings, and configure the agent to detect and repair orphaned locks. Stuck locks usually trace back to a session that ended abnormally, so monitoring for “profile in use” errors and clearing them proactively keeps mornings calm.

The second common issue is a profile that grows without bound. A runaway browser cache or a log file in AppData can fill a 30 GB container. Set a maximum size, enable profile-size alerts, and redirect the worst offenders — browser caches and temporary files — out of the container entirely so the profile stays small and logons stay fast.

Group Policy vs. Registry Deployment

FSLogix ships administrative templates you can import into Group Policy, which is the cleanest way to push settings across a fleet. For a handful of hosts, a registry script applied at build time is simpler and equally reliable. Whichever path you choose, keep the configuration identical on every host: a single host with a different VHDLocations value creates a second, orphaned profile and confusing support tickets.

Document the settings in your host build image so every new session host is configured correctly the moment it joins the pool. Consistency across hosts is what makes container profiles feel seamless — the user should never be able to tell which host they landed on.