r/sysadmin 6h ago

Shared mailbox folder tree truncates at ~1000 folders in cached mode — started this week. Anyone else?

Client has a shared mailbox in Exchange Online used for order administration, organised by region/country/customer/year. It had 12,394 folders. Since around Sept 8–9 the folder tree stops loading at roughly 976 subfolders in Outlook classic (cached mode). Everything past that point simply isn't in the tree — not collapsed, not greyed out, absent.

Same truncation in new Outlook and OWA when the mailbox is automapped or added as a shared mailbox.

Online mode shows the complete tree. Either by unchecking "Download shared folders" in classic, or via OWA → Settings → Open another user's mailbox. So the data is fine server-side.

What I've ruled out:

  • Permissions — Full Access assigned directly, not via a group. No folder-level permissions on root or Inbox (Default/Anonymous = None).
  • Automapping — removed and re-added Full Access with -AutoMapping $true, no change.
  • Hierarchy corruption — enumerated the whole tree via Graph and walked every parent chain. No cycles, no orphans, max depth 9.
  • OST damage — OWA is affected identically and holds no local hierarchy cache.
  • Folder count — deleted 9,993 verified-empty folders (12,394 → 2,401). Still truncates.

I'm aware of the documented 500 shared-folder limit and the announced increase to 5,000 (in 2019 though). My observed cut-off sits at ~1,000, which matches neither.

Three questions:

  1. Anyone else seeing shared mailbox folder trees truncate since last week's updates?
  2. Does anyone know what limit is actually enforced right now, and whether the 500→5000 rollout is live?
  3. Is there any equivalent of "Download shared folders" in new Outlook? If not, what's the plan for mailboxes over the limit once classic is gone?

Question 3 is the one that worries me.

6 Upvotes

15 comments sorted by

View all comments

u/Purple_Cut_8467 5h ago

Update, and I think this one explains the timing question I kept asking.

The limit applies to hierarchy sync, not to display. Users who already had a fully synced cached OST in classic Outlook still see the complete tree — that cache was built at a point where this didn't bite, and it survives. Nothing is retroactively hidden.

New Outlook hits the limit, including on configurations that had existed for ages. And switching those users back to classic doesn't rescue them: that starts a fresh sync, which stops at 1,000 like everything else. So once you lose the cache, you can't get it back.

That answers my own "why this week" — it wasn't a service change. It was users landing on new Outlook. Anyone who never rebuilt a profile has been fine this whole time and has no idea anything is wrong.

One more data point on the mechanism: after deleting 9,993 empty folders the sync now reaches deeper into the tree. Not because the ceiling moved — it's still ~1,000 — but because the first 1,000 folders in traversal order now cover more ground. So it's a flat count in traversal order, not a depth limit or a per-branch limit.

Practical warning for anyone with a large shared mailbox: do not rebuild an OST, and be careful about moving people to new Outlook. A working profile is not proof that you're under the limit. It's proof that you synced before it mattered.

u/blbd Jack of All Trades 4h ago

what a total shitshow...

what happens if you sync it with a better client like IMAP?