1. The scenario
A user on an Azure Virtual Desktop (AVD) session host ran into this. Their Windows profile doesn't live on the session host itself: it lives in an FSLogix profile container, a virtual disk (VHDX) that attaches when they sign in and follows them to whichever host they land on. That's what makes AVD feel seamless; sign in on any host in the pool and your desktop, your files, your settings are all just there, exactly as you left them.
That design is great for roaming users, but it comes with a trade-off worth knowing up front: the profile disk has a fixed size. Nothing in the experience warns you as it fills. There's no slow degradation, no helpful nudge halfway there. It just works, right up until it doesn't.
2. Symptoms
They were getting low disk space warnings in their AVD session, the kind that pop up and get dismissed because the desktop still seems to work. Left alone, though, a full profile disk doesn't stay a quiet background problem. It starts stopping Outlook, OneDrive and Teams from writing their data, and in the worst case it can prevent the profile from loading cleanly at sign-in, turning a disk-space warning into a locked-out user.
3. Investigation
Step 1: Run the usual low-disk checklist. On AVD, the first-pass checks are always the same three questions:
- Is OneDrive Files On-Demand on, and can Free up space release anything?
- Can
%temp%(andC:\Windows\Temp, with admin rights) be cleared? - Most importantly: which disk is actually full? The OS disk (C:) or the FSLogix profile disk?
I was deliberately careful with temp folders here. Users sometimes save real work there without realising it, so on a shared desktop I don't clear them blindly just because the folder name says "temp."
Step 2: Find out which disk is full. This question changes everything about how the rest of the investigation goes. A full C: drive is a session host problem, and it affects every user who happens to land on that host. A full profile disk is one user's problem, and because the disk travels with them, it follows them to every host they sign into. A quick PowerShell check shows every mounted volume and how much room is left on each:
Get-Volume | Sort-Object SizeRemaining |
Format-Table DriveLetter, FileSystemLabel, Size, SizeRemaining
The C: drive came back fine, plenty of headroom. The volume labelled Profile-user01, their FSLogix container, was almost full. That one result settled it: this was a profile problem, not a host problem, and it was going to follow the user wherever they signed in next.
Step 3: Find what's actually using the space. Inside the profile, one item stood out immediately, no digging required. Their Outlook data file (OST) was sitting at 47.56 GB. For context, an OST is just Outlook's local offline copy of a mailbox, meant to be a convenience cache. A few GB is completely normal. Nearly 48 GB is not normal, and a number that size doesn't happen by accident.
Step 4: Ask why the OST is so big. The size didn't line up with the size of their own mailbox at all, not even close, which meant Outlook had to be caching something extra on top of it. Sure enough, they had Full Access permission to a large shared mailbox, and buried in their account's Cached Exchange Mode settings, Download shared folders was ticked:
[Outlook Account Settings]
└── Cached Exchange Mode
├── [X] Use Cached Exchange Mode to download email to an Outlook data file
└── [X] Download shared folders <-- the culprit
With that box ticked, Outlook doesn't just reference the shared mailbox online when needed. It pulls down a full offline copy of it, folder by folder, into the same OST sitting on the profile disk.
4. Root cause
The shared mailbox was being cached into their OST, and the OST lives inside their fixed-size FSLogix profile disk. As the shared mailbox grew over time, so did the OST, and the profile disk filled up with data that never needed to be stored locally in the first place.
It was easy to miss precisely because nothing looked broken from inside Outlook. The shared mailbox opened fine, emails loaded fine, nothing about the day-to-day experience hinted that anything was wrong. The cost was hidden somewhere most users never think to look: a disk they don't even know they have, sitting behind the desktop they use every day.
5. The fix
- Unticked Download shared folders, so the shared mailbox is accessed online instead of cached locally.
- Rebuilt the OST, so Outlook created a fresh, much smaller file containing only the user's own mailbox.
- Moved the user to new Outlook, which doesn't rely on the classic OST model the same way and sidesteps this exact failure mode going forward.
- Confirmed the profile disk had healthy free space again before closing it out.
What I deliberately didn't do: expand the FSLogix disk. It's the obvious first instinct when a disk is full, give it more room, but it would only have bought time. The OST would have kept growing into the new space, and I'd have been back here again in a few months with a bigger, more expensive version of the same problem. Fixing the actual cause meant no disk change was needed at all.
6. Lessons
- Ask "which disk?" first. On AVD with FSLogix, C: and the profile disk are different problems with completely different owners and completely different blast radii.
- A huge OST usually means extra caching. Shared mailboxes and Download shared folders are the first thing worth checking, before anything more exotic.
- Don't reach for disk expansion first. More space hides a growth problem; it doesn't solve one. If the cause is still active, the symptom just comes back later and bigger.
- Be careful with temp folders on shared desktops. Check before you clear. "Temp" is not always as disposable as the name suggests.
If you want this written up step by step with the full diagnostic flow in one place, I put together the complete guide as a PDF.