This isn't you. This is Microsoft putting its foot on the hose.
What you're seeing is service-side throttling / temporary blocking after a long-running Content Search export. Three days of processing followed by a successful PST download is exactly the kind of pattern that trips their internal abuse and load-protection systems.
The ugly truth: eDiscovery exports are fragile, stateful, and easily locked.
Let's cut through it.
What that message actually means
"The request is blocked" with a long Z-timestamped token
That token is not an error you can fix client-side. It's a backend gate closing. Common triggers:
- Very large exports (multi-GB PSTs)
- Multiple export attempts in a short window
- Long-running Content Search jobs (yours ran 3 days - that's a red flag internally)
- Sequential PST downloads without cooldown
- Microsoft Purview / Security portal backend refresh or role sync lag
Once triggered, every export request gets blocked, even new ones, until the throttle expires.
Refreshing, logging out, different browser - all useless.
What to do right now (in order)
1. Stop trying to export
Every retry extends the block window. Walk away from the button.
Minimum wait:
- 2-6 hours (often enough)
- Worst case: 24 hours
Yes, that's grim. It's how the system works.
2. Check whether the export job itself is complete
Go to:
Microsoft Purview eDiscovery Content search Exports
If the export shows:
- Completed good, the data exists
- Partially completed you may need to split later
- Failed different problem (less likely given first PST worked)
Do not delete the export unless it's genuinely broken.
3. When it unblocks, do this differently (important)
You've already proven the search works. Now you need to reduce blast radius.
Split the export:
Create new exports with:
- Date ranges (e.g. 3-6 months at a time)
- Mailbox subsets
- Content types separated (mail vs archive vs OneDrive)
Smaller exports = fewer throttles.
4. If it's still blocked after 24 hours
At that point, it's no longer "normal throttling".
You have two options:
Option A - Soft reset
- Sign in with a different Global Admin / eDiscovery Manager
- Same tenant, different identity
- Often bypasses the lock
Option B - Microsoft Support (unfortunately)
Open a ticket and include:
- Time the block started
- That you successfully downloaded one PST
- The full block token string
- Confirmation it affects all exports
They can manually clear the backend flag. Frontline support won't know this - escalate early.
Hard truth (worth knowing for the future)
Microsoft 365 eDiscovery is not built for massive, continuous exports. It's built for:
- Legal holds
- One-off investigations
- Audits
For migrations, restructures, or bulk archival (which I suspect you're doing, given your past Exchange work), this tool is the wrong hammer.
Long-term, better options are:
- Staged exports over time
- Graph + compliance APIs
- Third-party tooling designed for bulk extraction
- Or server-side mailbox moves + journaling where possible
The platform rewards patience and punishes urgency.
Bottom line
- You hit a temporary backend block
- You did nothing wrong
- Retrying makes it worse
- Wait, then split exports aggressively
- If still blocked after 24h, escalate with the token
If you want, tell me:
- Approx size of the total export
- Number of mailboxes
- Whether this is legal, migration, or archival work
I can help you design a throttle-resistant export strategy so this doesn't happen again - quieter, slower, but unstoppable.
