A Mailbox at 48.6 GB With an Active Litigation Hold
You lead a 12-person team. Your own mailbox sits at 48.6 GB against a 50 GB quota and has sent daily warning messages for two weeks. The team's shared mailbox holds 22 GB of customer threads that three people read daily. The 'Atlas' project has been under litigation hold since March. Two team members routinely drag finished threads into a .pst file stored on their laptops. A tenant-wide retention policy deletes anything older than three years. Finance has approved no new licences this quarter and IT will not raise the quota.
1. How do you relieve the mailbox pressure without compromising the Atlas hold?
Read the worked answer
First, kill the wrong instinct: bulk-deleting old mail does not help much here. Items under a hold or covered by a retention policy are moved to Recoverable Items when deleted, and they continue to consume the mailbox quota until the hold or retention period expires. You would delete the evidence and still be at 48 GB.
Recommended sequence:
- Enable the online archive on your mailbox and apply a retention policy that moves items older than a defined threshold to the archive rather than deleting them. The archive is a separate quota (100 GB on archive-enabled plans, with auto-expanding archive beyond that).
- Confirm scope: archive content remains in scope for eDiscovery and holds, so the Atlas material is still preserved. This is the key difference from a .pst approach.
- Target the real weight. Run a folder-size/usage view to find the largest folders; mail with large attachments (design files, exports) is usually 60–80% of the volume. Move project records to SharePoint/Teams and keep the link in the thread.
- Do it before quota, not at quota. At 50 GB the mailbox stops accepting mail, and 'sent items' failures are easy to miss for a day.
- Track the trend weekly; if the archive fills, that is the licence conversation you take to Finance with numbers.
2. Two team members keep dragging mail into a .pst on their laptops. What is wrong with that, and what do you replace it with?
Read the worked answer
Six distinct problems:
- It leaves the compliance boundary. A PST is not covered by the tenant retention policy, and eDiscovery against the mailbox will not return it. For anything touching Atlas, that is a spoliation risk.
- It defeats the purpose. The stated goal is space; PSTs do free the mailbox, but the archive mailbox achieves the same inside the service, with holds intact. There is no upside to the PST.
- It is fragile. The default PST ceiling is around 50 GB, larger PSTs corrupt more readily, and a PST is a single file on a laptop that may not be backed up or encrypted.
- PST over a network share is unsupported and known to produce corruption and performance problems.
- It is invisible. Nobody knows what is in it, so nobody can answer a discovery request or an audit question.
- It is not a filing system. Project records belong in SharePoint/Teams, where they are searchable and permissioned.
Replace with: online archive for retention-driven ageing; SharePoint/Teams document libraries for project records; retention labels for anything that must be kept for a defined period. If a genuine offline requirement exists, that is a separate business case, not a habit.
3. The team's shared mailbox is at 22 GB and three people work from it daily. Evaluate the current access model and the alternatives.
Read the worked answer
Current model is broadly right if access is granted as Full Access delegation on the shared mailbox (plus Send As if replies must come from the team address). That keeps every thread in one searchable, holdable location and attributes actions to the individual who took them.
Alternatives and why they are worse:
- Forwarding to personal mailboxes. Duplicates every message, replies appear 'on behalf of' or from the wrong address, and copies accumulate in 12 personal mailboxes - all of which are then in scope for eDiscovery. Space is not saved, it is multiplied.
- A distribution group. Has no mailbox, no shared calendar, no shared folder, and no single place to look.
- Everyone keeps their own copy. Returns you to the divergent-versions problem in mail form.
Capacity: the mailbox is well under the 50 GB point where a licence becomes necessary, so no new spend is implied. Watch the trend: 22 GB of customer threads with three daily readers will keep growing. If it approaches the ceiling, the decision is split by function (e.g. support vs. billing) rather than one licensed mega-mailbox, and set a retention label so resolved threads age out predictably.
One control to add now: restrict who can grant Full Access, and review the delegate list quarterly - shared mailbox permissions drift more than any other permission set.