If your Remote Desktop Services farm runs on User Profile Disks, you have probably been told FSLogix is the fix for slow sign-ins, broken Outlook search and profiles that will not load. Sometimes it is. Sometimes the problem is somewhere else, and moving profiles only moves it.
In short: FSLogix profile containers put each user's whole Windows profile in a VHD or VHDX file on an SMB share and attach it at sign-in, so applications see a normal local profile. Microsoft recommends them for Azure Virtual Desktop, and they work on RDS too. You are entitled to use them with a Microsoft 365 E3, E5, Business, F1 or F3 licence, an RDS CAL or SAL, or an AVD per-user access licence, among others. There is no direct migration from User Profile Disks, so plan a cut-over rather than a conversion, and fix storage, antivirus and sizing first.
What a profile container actually is
A Windows profile normally lives in C:\Users\%username%. An FSLogix profile container holds nearly everything under that folder in a single virtual disk file, stored on a network share.
At sign-in, FSLogix attaches that disk and uses a filter driver to redirect the profile at file system level. Microsoft's overview puts the practical point plainly: applications are unaware the profile is on the network, which matters because many of them do not work properly with a remotely stored profile.

What you get from that:
- No copying at sign-in. The disk is mounted, not copied down and back up like a roaming profile.
- A profile that roams between hosts. Users on a pooled host pool can land on a different session host each day and still get their own settings.
- Office data that behaves. Outlook, OneDrive and Teams data sits inside the container rather than being rebuilt every session.
There is also a second container type, ODFC, which holds only Office data. Microsoft's guidance is to use a single profile container unless you have a specific reason to split them, and ODFC is mainly for estates that already run another roaming profile product.
How it differs from User Profile Disks
Microsoft itself makes the comparison: the profile container's function is similar to User Profile Disks, but the underlying method and technology are different. Both store the profile in a virtual disk on a share. The differences that matter in practice:
| User Profile Disks | FSLogix profile containers | |
|---|---|---|
| Scope | Per user, per RDS collection. Roams only within that collection | Not tied to a collection. Works on RDS, AVD and other platforms |
| How it is switched on | For every user in a collection at once | Settings on each machine, by Group Policy or registry |
| Storage | A central SMB share | Any SMB share, including Azure Files and Azure NetApp Files, or Azure page blobs with Cloud Cache |
| Sizing | A size per disk set on the collection | Dynamic by default, up to a maximum you set, with automatic compaction at sign-out |
| Failure handling | No equivalent setting in Microsoft's UPD guidance | Options to block sign-in rather than hand out a temporary profile |
| Azure Virtual Desktop | An RDS collection setting, so not part of AVD | Microsoft's recommended profile solution |
If you only ever run one RDS collection and the profiles behave, that first row is less of a problem than it sounds. It becomes the problem the moment you want a second collection, a mixed estate, or a move towards AVD.
Are you licensed for it?
FSLogix has no licence of its own. Microsoft's prerequisites page lists the licences that make you eligible:
- Microsoft 365 E3 or E5
- Microsoft 365 A3, A5 or Student Use Benefits
- Microsoft 365 F1 or F3
- Microsoft 365 Business
- Windows 10 Enterprise E3 or E5
- Windows 10 Education A3 or A5
- Remote Desktop Services CAL or SAL
- Azure Virtual Desktop per-user access licence
For an RDS estate, the RDS CALs you already need for the farm are on that list. Microsoft also states FSLogix can run in any public or private datacentre or cloud as long as the user is properly licensed, on Windows 10, Windows 11 and Windows Server 2016 through 2025.
Where to put the containers
FSLogix needs an SMB file share and uses the operating system's own SMB client. Beyond that, the storage choice is yours, and it decides most of the user experience.
Size the share for sign-in, not for the working day
Microsoft's example figures are 10 IOPS per user in steady state and 50 IOPS per user at sign-in and sign-out. That is around 1,000 IOPS for 100 users during the day, and around 5,000 when everyone signs in at 9am. Storage that copes at 11am and struggles at 8.55 produces exactly the slow sign-ins users complain about.
Keep it close
Latency between session hosts and the share matters more than raw speed. On AVD, Microsoft says the storage account must be in the same region as the session hosts. On-premises, it should be on the same site.
Azure options
- Azure Files for general purpose use, with Premium, Transaction Optimized, Hot and Cool tiers and redundancy from LRS to GZRS.
- Azure NetApp Files for very high performance, or where you already run NetApp on-premises. Available in selected regions only.
- Azure page blobs, used only with Cloud Cache.
Microsoft's FAQ notes that Cloud Cache is not required for high availability: standard containers on Azure Files with zone-redundant storage are a recommended option. Cloud Cache can also make sign-out noticeably slower, so treat it as a disaster recovery design, not a default.
"Most FSLogix problems are storage, antivirus or sizing problems wearing a profile costume."
The problems people actually hit
Profile locked or temporary profile
A container is a file, and a file that is still open somewhere cannot be attached cleanly. By default FSLogix retries a locked VHD 12 times, five seconds apart. Out of the box, a user who still cannot get their container can end up on a temporary profile, and nothing they change is saved to their container.

Two configuration settings change that: PreventLoginWithFailure and PreventLoginWithTempProfile. Both are off by default. With them on, the user sees a prompt to call support and can only sign out, which is a better outcome than silent data loss.
Concurrent sessions need care. Read-write and read-only behaviour is controlled by ProfileType, all sessions sharing a container should use the same value, and Microsoft states that OneDrive does not support multiple concurrent connections using the same profile under any circumstances.
Antivirus
Microsoft publishes a full exclusion list covering the FSLogix services, drivers, program folders, the VHD and VHDX files on the share and their lock and metadata files. Without them, the documented results include mount delays, service crashes at sign-in and temporary profiles. Check every layer: endpoint, file server and any data loss prevention agent.
Containers filling up
The default maximum container size is 30,000 MB, and containers are dynamic, so they only consume what they use. When a container reaches its maximum, Microsoft's FAQ warns that applications start behaving strangely, and advises planning for at least 30% free space. You can raise the maximum at any time, but lowering the setting will not shrink an existing disk.
VHD disk compaction is on by default and runs at sign-out when at least 20% of the used space is recoverable. It only works on dynamic disks, and it fails if the Optimize Drives service is set to Disabled, which some hardened images do.
Outlook and the OST
Cached Exchange mode on a shared session host used to be the thing everyone turned off. Microsoft's AVD guidance says profile containers resolve the performance issues that historically blocked cached mode. The OutlookCachedMode setting goes further: with Outlook configured for online mode, FSLogix switches cached mode on only while the container is attached, so if FSLogix is ever disabled, Outlook does not start pulling down large OST files.
Size for it. A cached mailbox lives inside the container and counts against its maximum.
The Kerberos encryption change
Microsoft currently carries this warning at the top of its FSLogix pages. The April 2026 Windows Server update changes the default Kerberos encryption type from RC4 to AES-SHA1, and file shares hosting FSLogix containers that have not been upgraded to AES-SHA1 may have access issues once it is applied. If nobody has checked your profile share, check it before you patch, because the symptom is users who cannot load their profiles.
Windows Search
Older guides tell you to enable FSLogix search roaming. Microsoft now states that it is no longer necessary on Windows Server 2019 version 1809 and later, or on Windows 10 and 11 multi-session, so on a current estate leave RoamSearch at its default.
Moving from User Profile Disks
Microsoft's FSLogix FAQ is clear that there is no direct migration path from other roaming profile solutions. That shapes the plan.

- Move data out of the profile first. OneDrive known folder move takes documents, desktop and pictures out of the profile entirely, which is Microsoft's own suggestion. Less in the profile means less to lose and less to carry.
- Build the storage and test sign-in at peak. Size the share to the sign-in figures above, apply the antivirus exclusions, and turn on the failure-handling settings before anyone uses it.
- Pilot with a small group. A fresh profile on a pilot collection shows you which applications keep settings where you did not expect.
- Decide fresh or copied, per group. For smaller cases, the frx utility's copy-profile command copies a local profile into a new container, and profiles over 5 GB need the size set explicitly. For most users, a clean profile with their data already in OneDrive is faster and leaves the accumulated clutter behind.
- Cut over a collection at a time, and keep the UPD share read-only for a short period in case someone needs a file back.
If you are moving to Azure Virtual Desktop at the same time, do not combine the two changes on day one. Get profiles right on the platform you are leaving or the one you are going to, not both at once. Our AVD consultancy covers the AVD side, and the AVD cost quick wins post covers matching FSLogix storage tiers to real demand once you are there.
When to stay on User Profile Disks
FSLogix is not automatically the right answer. Staying put is reasonable when:
- You run a single RDS collection, and users never need to roam outside it.
- Sign-ins are acceptably fast and you are not seeing temporary profiles.
- Outlook and OneDrive work well enough for the way your users actually use them.
- The farm has a known end date, because you are moving to AVD or Windows 365, and a profile migration now would be done twice.
What does not justify staying is "it is working" when nobody has checked the share, the antivirus exclusions or the disk sizes in years. Those are the same problems in either technology.
Where to start
Before you change profile technology, find out what is actually causing the pain. Storage latency at sign-in, missing antivirus exclusions and full disks all follow you to FSLogix if you do not fix them first.
Our Remote Desktop Services work covers the whole estate, profiles included. The fastest route to an answer is the RDS health check: a fixed-price review of the Connection Broker, Session Hosts, Gateway, licensing and user profiles, UPD or FSLogix, with the root causes and a rectification path in the order we would do it.
Frequently asked
Is FSLogix free?
There is no separate FSLogix licence to buy. Microsoft lists the licences that make you eligible to use it, and the list includes Microsoft 365 E3, E5, A3, A5, F1, F3 and Business, Windows 10 Enterprise E3 and E5, Windows 10 Education A3 and A5, the Remote Desktop Services CAL and SAL, and the Azure Virtual Desktop per-user access licence. If your users are covered by one of those, the software itself costs nothing extra. The storage you put the containers on does.
Can I use FSLogix with Remote Desktop Services on-premises?
Yes. Microsoft states that FSLogix may be used in any public or private datacentre or cloud as long as the user is properly licensed, and an RDS CAL or SAL is on the eligibility list. It runs on Windows Server 2016, 2019, 2022 and 2025, so a classic RDS session host farm on your own hardware is a supported place for it. The containers need an SMB file share that sits close to the session hosts.
What is the difference between FSLogix and User Profile Disks?
Both put the user profile in a virtual disk on a file share and attach it at sign-in. The differences are in scope and control. A User Profile Disk is per user and per collection, so it only roams within one RDS collection, and it is switched on for a whole collection at once. An FSLogix profile container is controlled by settings on each machine, can be used across RDS, Azure Virtual Desktop and other platforms, supports Azure Files and Azure NetApp Files as storage, and comes with tools for sizing, compaction, locking behaviour and failure handling that UPD does not have.
How big should an FSLogix profile container be?
The default maximum is 30,000 MB, set by the SizeInMBs setting, and containers are dynamic by default so they only use the disk space they actually need. Microsoft advises planning for at least 30% free space inside the container. You can raise the maximum at any time but you cannot shrink it by lowering the setting. Container size does not affect sign-in time, according to Microsoft's FAQ.
Can I migrate User Profile Disks straight into FSLogix?
Not directly. Microsoft's FAQ says FSLogix does not provide a direct migration path from other roaming profile solutions, and suggests moving user data into OneDrive with known folder move so there is less in the profile to carry. For smaller estates, the frx command-line utility's copy-profile command copies a local profile into a new VHD or VHDX. For most businesses, a fresh profile and a planned cut-over is simpler than a bulk conversion.





