FSLogix profile container sizing: a reference
Why default sizing guidance falls short
Microsoft's published defaults are a reasonable floor, not a sizing plan. Real profile sizes are driven overwhelmingly by three things: Outlook cached-mode OST size, Teams/Edge cache behaviour, and how aggressively (or not) redirection is configured for the rest. This reference is the working numbers from a 3,500-seat AVD estate, not a vendor datasheet.
Container sizing, observed distribution
| Profile content | Typical footprint | Notes |
|---|---|---|
| Base profile (no Office data) | 200–400 MB | Stays flat once app settings are redirected out |
| Outlook OST, cached mode, 12-month window | 2–8 GB | The single biggest variable — see below |
| Teams cache | 500 MB–2 GB | Grows unless cleaned; see cleanup policy below |
| Edge/Chrome profile cache | 200 MB–1 GB | Redirect to a non-persisted location where policy allows |
Working default: provision containers at 30 GB with dynamic (expandable) VHDX, not fixed. Fixed-size containers were tried first and abandoned — the storage savings didn't justify the operational cost of resizing containers for users who exceeded them mid-shift.
Outlook OST — the setting that matters most
Cached Exchange Mode's sync window is the highest-leverage single setting for both profile size and logon time. Moving the default sync window from "all" to 3 months cut median OST size roughly in half across the estate. This is a policy setting (Cached Exchange Mode sync window via Group Policy / cloud policy), not something FSLogix controls directly — but it's the FSLogix sizing conversation that usually surfaces the need for it, because nobody else is watching container growth.
Storage IOPS budget
Profile containers are read/write-heavy at logon and logoff, lighter during the session. Underprovisioned storage IOPS shows up as slow logon, not as an obvious storage alert — this is the failure mode that's easiest to misdiagnose as "Citrix/AVD is slow" when it's actually the profile store.
- Budget for logon storms: peak concurrent logons × ~20–30 IOPS each as a starting planning number, then validate against your actual storage backend's real sustained IOPS, not its burst rating.
- Azure Files (premium tier) and Azure NetApp Files both worked; the deciding factor in practice was less about raw performance and more about which one the storage team could operate and monitor without the AVD team becoming the de facto storage support desk.
Cleanup policy — don't skip this
Without a cleanup policy, container growth is roughly monotonic — users don't clean up after themselves, and neither does Teams/Edge cache by default. FSLogix's built-in Cache Delete Policy (per-app, scheduled) recovered meaningful space on the Teams and Edge cache specifically; it did very little for Outlook OST size, which is governed by the sync window setting above, not cache cleanup.
The numbers that mattered most, summarised
- Cached Exchange Mode sync window is the highest-leverage setting — fix this before tuning anything else.
- Provision dynamic, not fixed, VHDX containers.
- Size storage IOPS for the logon storm, not average load — this is where "it's slow" tickets actually come from.