FSLogix Profile Containers and ODFC
In pooled AVD environments, users lose their profile every time they log off. FSLogix fixes this by storing profiles in VHD(X) files that follow users between session hosts. Learn how Profile Containers and Office Data File Containers work, when to use each, and how to configure them.
Why FSLogix exists
Think of it as a portable locker for your stuff.
Imagine you work in an office where you never sit at the same desk twice. Every morning, you get a random desk — completely empty. Your photos, files, browser bookmarks, everything is gone. That would be awful, right?
FSLogix gives each user a personal locker (a virtual hard disk). When you sit down at any desk, the locker opens and all your stuff appears — your desktop, your Outlook emails, your browser favourites. When you leave, the locker locks and waits for you to sit at any other desk tomorrow.
The profile problem in pooled environments
Without FSLogix in a pooled host pool, here is what happens:
- User logs into session host VM-01 and gets a new local profile
- They configure Outlook, set a wallpaper, save files to the desktop
- User logs off — the profile is deleted (non-persistent)
- Next day, user logs into session host VM-03 (load balancer assigned a different VM)
- They get another blank profile — all yesterday’s work and settings are gone
🎧 Mia’s nightmare: “Before FSLogix, Dr. Patel called the help desk every Monday morning. Her Outlook had to rebuild the OST cache from scratch — a 4-minute process before she could read a single email. Multiply that by 12 clinics and 200 clinicians. We were drowning in tickets.”
FSLogix eliminates this entirely. The profile VHD(X) follows the user regardless of which session host they land on.
Profile Container — the full package
A Profile Container captures the entire user profile in a single VHD(X) file:
- Desktop, Documents, Downloads, Pictures
- AppData (application settings, browser data, cached credentials)
- Outlook OST file and search index
- Teams cache
- OneDrive hydration state
- Start menu layout and taskbar customisations
- Registry hives (NTUSER.DAT)
How it works
- User signs in to a session host
- FSLogix checks the configured VHDLocations network path
- FSLogix finds (or creates) the user’s VHD(X) file
- The VHD(X) is mounted to the session host
- Windows profile path is redirected to the mounted disk
- User sees their full profile — as if it were local
- At sign-out, the VHD(X) is cleanly unmounted
🏢 Raj’s migration: “TerraStack was running Citrix with roaming profiles. Sign-in took 90 seconds. We switched to FSLogix Profile Containers and dropped to 15 seconds. Andrea, the CIO, thought I was exaggerating until she timed it herself.”
Office Data File Container (ODFC)
The Office Data File Container (ODFC) stores only Microsoft Office data in a separate VHD(X):
- Outlook OST file and search index
- Teams cache and meeting data
- OneDrive cache and hydration state
- OneNote notebooks cache
- Office activation data
Everything else (desktop files, browser data, app settings) stays in the regular profile.
When to use ODFC instead of Profile Container
| Scenario | Recommendation |
|---|---|
| Standard AVD pooled deployment | Profile Container (default, simplest) |
| Already have a profile solution (UPM, UE-V) and only need Office roaming | ODFC only |
| Need Office data to roam but want profiles managed separately | ODFC only |
| Want both complete profile AND separate Office data management | Profile Container + ODFC together |
| Feature | Profile Container | ODFC |
|---|---|---|
| What it stores | Entire user profile (everything) | Only Microsoft Office data |
| VHD(X) contents | Desktop, Documents, AppData, Outlook, Teams, registry | Outlook OST, Teams cache, OneDrive cache, OneNote |
| Default size | 30 GB | 30 GB |
| Registry key | Enabled = 1 under Profiles key | Enabled = 1 under ODFC key |
| Storage path key | VHDLocations | VHDLocations (under ODFC key) |
| Use with other profile solutions | No — it IS the profile solution | Yes — pair with UPM, UE-V, or other roaming |
| Typical use case | Most AVD deployments (recommended default) | Hybrid scenarios with existing profile management |
| Can run together | Yes — ODFC stores Office data in a separate VHD | Yes — supplements Profile Container or other solutions |
Exam tip: Profile Container is the default recommendation
Unless the question specifically mentions an existing profile management solution (Citrix UPM, Microsoft UE-V) that needs to be retained, the answer is almost always Profile Container alone. ODFC is the niche choice — used when you already have a working profile solution and just need to add Office data roaming on top. Using Profile Container + ODFC together is an advanced exception for specific dual-container scenarios, not the default recommendation.
If the exam says “new AVD deployment” — think Profile Container alone. If it says “existing profile solution, need to add Outlook and Teams roaming” — think ODFC.
Configuring FSLogix — the key registry settings
FSLogix is configured through registry keys under HKLM\SOFTWARE\FSLogix\Profiles (for Profile Container) or HKLM\SOFTWARE\FSLogix\ODFC (for ODFC).
| Registry Value | Type | What It Does | Example |
|---|---|---|---|
| Enabled | DWORD | Turns FSLogix on (1) or off (0) | 1 |
| VHDLocations | MULTI_SZ | Network path(s) where VHD(X) files are stored | \\storageaccount.file.core.windows.net\profiles |
| SizeInMBs | DWORD | Maximum size of the VHD(X) file | 30000 (30 GB) |
| VolumeType | REG_SZ | VHD or VHDX format | VHDX |
| FlipFlopProfileDirectoryName | DWORD | Puts username first in folder name (1 = SID_username becomes username_SID) | 1 |
| ProfileType | DWORD | Controls concurrent access behaviour | 0 |
| DeleteLocalProfileWhenVHDShouldApply | DWORD | Removes cached local profiles when FSLogix should take over | 1 |
VHD vs VHDX format
| Feature | VHD | VHDX |
|---|---|---|
| Max size | 2 TB | 64 TB |
| Corruption resilience | Lower — no journal | Higher — metadata journaling |
| Performance | Standard | Better I/O performance |
| Recommendation | Legacy only | Always use VHDX |
Set
VolumeTypetoVHDX— there is no reason to use VHD in new deployments.
ProfileType — concurrent access
| Value | Behaviour | When to Use |
|---|---|---|
| 0 | Normal profile (default) — single concurrent connection, read-write | Default for most pooled environments |
| 1 | Read-write only — if the VHD is locked by another session, user gets a temporary local profile | When you want strict read-write-only access |
| 2 | Read-only only — profile cannot be written to | Specific lockdown scenarios |
| 3 | Try read-write, fall back to read-only if VHD is locked | Multi-session concurrent access (e.g., user logged into two hosts) |
Deep dive: FlipFlopProfileDirectoryName
By default, FSLogix names profile directories as SID_Username (e.g., S-1-5-21-xxx_rpatel). Setting FlipFlopProfileDirectoryName = 1 changes this to Username_SID (e.g., rpatel_S-1-5-21-xxx).
Why does this matter? When browsing the file share to troubleshoot, finding a user’s profile by username is much faster than searching by SID. Microsoft recommends enabling this setting — it is purely a naming convention change with no functional impact.
NTFS permissions for profile shares
Getting permissions right is critical for security and functionality:
On the Azure Files share or SMB share:
| Identity | Share Permission | NTFS Permission |
|---|---|---|
| Creator Owner | — | Modify (this folder, subfolders, files) |
| Domain Users / AVD users group | Storage File Data SMB Share Contributor | Modify (this folder only) |
| Administrators | Storage File Data SMB Share Elevated Contributor | Full Control |
The key principle: each user has Modify access to their own profile folder only. Other users cannot read or access anyone else’s profile VHD(X). FSLogix creates the user’s folder on first sign-in with the correct permissions inherited from Creator Owner.
Profile container sizing
The default 30 GB is a starting point. Adjust based on workload:
| Workload Type | Recommended Size | Why |
|---|---|---|
| Task workers (data entry, call centre) | 10-15 GB | Small profiles, minimal Office data |
| Knowledge workers (M365 heavy) | 30 GB (default) | Outlook OST, OneDrive cache, Teams |
| Power users (developers, analysts) | 50-100 GB | Large datasets, multiple app caches |
| Healthcare (Mia’s clinicians) | 20-30 GB | Moderate Outlook use, clinical app settings |
🎧 Mia’s sizing lesson: “We started at 30 GB for everyone. Then we found night-shift nurses only used 3 GB, but radiologists hit 25 GB from PACS viewer caches. We created two groups with different SizeInMBs policies. Support tickets dropped by half.”
Mia is deploying FSLogix for Horizons Health Group's pooled AVD environment. This is a new deployment with no existing profile management. She wants complete profile roaming for all clinicians. What should she configure?
Raj is configuring FSLogix for TerraStack's pooled host pool. He wants profiles stored on an Azure Files share at \\\\terrastack.file.core.windows.net\\profiles using VHDX format with a 50 GB limit. Which registry values must he set under HKLM\\SOFTWARE\\FSLogix\\Profiles?
Which NTFS permission model is correct for an FSLogix profile share?
Next up: FSLogix Cloud Cache and Application Masking — add high availability to profiles with Cloud Cache and control which apps users see with application masking.