FSLogix Profile Containers: Configuration and Troubleshooting

In a pooled AVD host pool, users land on a different VM almost every session — so their profile can’t live on the host. FSLogix solves this by storing the entire Windows profile in a VHD(X) container on shared storage and mounting it at logon. Get it right and users never notice; get it wrong and it’s your top support ticket.

What FSLogix actually does

FSLogix redirects the user profile into a virtual disk (a .vhdx) held on an SMB share. At logon the container is mounted and grafted onto the local profile so Windows and applications behave as though the profile is local. At logoff it unmounts. The two main components:

• Profile Container — the whole user profile in one VHDX. This is the one you’ll use most.
• Office Container — isolates just the Office/Outlook cache (OST), search index and Teams data; useful when layering with another profile solution.

Choosing storage — the decision that defines performance

FSLogix performance is storage performance. Your realistic options:

Option	Strengths	Watch-outs
Azure Files Premium	Simple, SMB-native, good IOPS, Entra/AD auth	Per-share IOPS ceiling; plan share count for large estates
Azure NetApp Files	Highest performance, low latency at scale	Higher cost; capacity-pool minimums
Storage Spaces Direct VM	Full control	You own the patching, HA and backup — usually not worth it

Core configuration

FSLogix is driven by registry values (usually delivered via Intune, Group Policy or the image). The essentials under HKLM\SOFTWARE\FSLogix\Profiles:

Enabled                 = 1
VHDLocations            = \\<storage-account>.file.core.windows.net\profiles
ProfileType             = 0        ; normal (single mount)
SizeInMBs               = 30000    ; per-profile max size
IsDynamic               = 1        ; grow on demand
FlipFlopProfileDirectoryName = 1   ; %username%%sid% folder naming
DeleteLocalProfileWhenVHDShouldApply = 1

Two settings save the most pain in production: FlipFlopProfileDirectoryName (makes profile folders human-readable) and DeleteLocalProfileWhenVHDShouldApply (prevents stale local profiles from blocking the container mount).

Permissions — get these exactly right

The share needs both share-level and NTFS permissions. The standard model:

• Share-level: the AVD users group gets the Storage File Data SMB Share Contributor role.
• NTFS: users get Create folder / append data, List, Read on the share root — but only Modify on their own folder (Creator Owner).
• Admins retain Full Control for support and cleanup.

The classic failure modes

Symptom	Likely cause
Temporary profile at logon	Container failed to mount — permissions, or a stale local profile
Slow logons	Storage latency/IOPS, oversized profiles, or AV scanning the VHDX
“Profile in use” / locked	Ungraceful logoff left the VHDX attached; needs release or session cleanup
Bloated containers	Teams/Office caches unbounded — cap them and exclude what you can

Sizing and lifecycle

Use dynamic VHDX so containers grow only as needed, set a sane SizeInMBs cap, and have a plan for orphaned profiles (leavers). Cap the Teams and OneDrive caches, and consider an Office Container if Outlook OSTs dominate your profile size.

---

FSLogix is deceptively simple — a VHDX on a share — but profiles, permissions and storage performance are where AVD deployments most often stumble. Nail storage choice, permissions and AV exclusions first, and the rest is tuning.