Profiles That Eat Themselves

Where the bytes are. Cached Outlook OST files, OneDrive's local sync cache, and Teams cache all live inside the user profile. That is the entire explanation for a 30 GB container that keeps growing: a user with 'mail to keep offline' set to All plus two 20 GB archives can approach the ceiling by themselves, and full OneDrive library sync fills whatever is left.

Priority order:

1. Split Office data out of the profile container. Enable the FSLogix ODFC (Office container) so OST, OneDrive, and Teams caches land in a separate VHDX. The profile container then holds the actual profile and attach time drops sharply, because attach cost scales with the size and metadata of the VHDX being mounted.
2. Reduce 'mail to keep offline' to 3-6 months and stop caching shared mailboxes by default. Search still works: Exchange server-side search returns results for items that are not cached, so users keep the search experience they care about while the OST stays small.
3. Turn on OneDrive Files On-Demand and stop hydrating whole departmental libraries. If a small group genuinely needs full offline copies, give them a larger ODFC on its own share rather than inflating everyone's profile.
4. Set explicit caps (profile 10-20 GB, ODFC sized to measured p95 plus headroom) so a runaway profile is capped and visible instead of silently consuming the share.

What not to do: do not simply raise the container to 60 GB. Dynamic VHDX only grows; deleted files inside do not shrink it, so you buy two months and a slower logon. Also add antivirus exclusions for the VHDX paths, since scanning a mounted container at logon is a classic hidden logon tax.

Timesheet MSIX: use App Attach. It fits the shape of the problem exactly: user-scoped, no drivers, no services that need to start at boot, and it can be attached at logon per user or per group. Different user groups can get different versions without rebuilding the image, and the base image stays clean. Prerequisites: a signed MSIX, the certificate chain trusted in the image, the VHD or CIM staged where hosts can read it, and the package excluded from FSLogix profile capture so per-user registration state does not get baked into the profile.

2013 drafting application: do not use App Attach. It installs a print driver and a licensing service. App Attach cannot deliver kernel-mode components, drivers, or services that must run outside the user's context; packaging it will either fail or produce an app that half-works. Two workable options:

• Bake it into the golden image if one version serves everyone. Simplest, and a print driver in a vetted image is a known quantity. The cost is that every version bump means a new image and a host pool image update.
• Dedicate a host pool if the app is version-sensitive, unstable, or needs different OS settings than the general desktop. Publish it as a RemoteApp so users get a seamless window while the pool stays isolated.

Licensing is the trap. Per-user installs are not possible on pooled multi-session hosts; the app sees a shared machine. Either point the licensing service at a reachable licence server for concurrent licences, or negotiate per-device licensing sized to the number of hosts. Sorting this out after deployment means users get a nag screen in production.

Finally, test the print driver inside a session with the real print server before committing; driver interaction with multi-session is the single most common source of session host crashes in this pattern.

Improves: the immediate failures stop. Users who hit the ceiling stop getting temporary profiles, which is a data-loss risk as well as a support ticket, and profile-attach errors disappear from the log.

Gets worse:

• Dynamic VHDX only grows, so a 60 GB container that fills to 55 GB now takes longer to attach than a 30 GB one, because attach cost tracks size and metadata. You have traded a hard failure for a slower, soft one.
• The share becomes the bottleneck. Premium file share IOPS and throughput are provisioned with the share size, and 260 users arriving in a 45-minute window create a burst that is much more demanding than steady-state. Oversized containers make each mount more expensive at exactly the wrong moment.
• Backup, antivirus scanning, and any container copy get slower and more costly.

Monitor: Azure Files platform metrics on the storage account, with no Log Analytics ingestion cost: SuccessE2ELatency versus SuccessServerLatency (if end-to-end far exceeds server-side, the client or network is the problem), transaction volume, and throttling or server-busy responses. On the host side, logon duration from AVD Insights and per-user container size from the share. From FSLogix operational logs, the attach duration per stage on a sampled set of hosts rather than all of them.

The right answer is both: right-size to measured p95 rather than doubling blindly, and shrink the profile so the ceiling is never approached, which is the ODFC and Outlook cache work from the previous question.