Forum Discussion
Exchange SE HU6: PDF attachments truncated to 13 KB via Outlook Desktop — OWA unaffected
We've spent days isolating this and ruled out everything we could touch. The corruption survives agent disabling, Bitdefender removal, and BypassFiltering — and the message tracking logs show exactly where it happens.
Environment: Exchange Server SE, Build 15.2.2562.41 (HU6 / KB5081755), Windows Server 2025
Problem: PDF attachments sent internally via Outlook Desktop (MAPI) arrive corrupted at ~13 KB (original: ~32 KB, no xref/EOF). All PDF sizes, all internal recipients affected. Started 21 May 2026.
Key finding — OWA works, Outlook Desktop doesn't: Sending the identical email via OWA → attachment arrives intact. Outlook Desktop → truncated.
Message tracking proof: Both paths deliver the message at full size (~42 KB) via STOREDRIVER DELIVER. Only the Outlook Desktop delivery shows an additional X-SDDS=0.106 step in the STOREDRIVER latency breakdown. That step does not appear in the OWA delivery. The corruption happens inside that MAPI/TNEF store write step — not in transport.
Systematically ruled out:
- All transport agents disabled → still 13 KB
- Exchange Malware Agent + Set-MalwareFilteringServer -BypassFiltering $true → still 13 KB
- Bitdefender GravityZone fully uninstalled from server → still 13 KB
- EEMS mitigations: only PING1 and M2.1.0 applied, neither affects MAPI delivery
Temporal correlation: Three Windows updates installed 21.05.2026: KB5087051 (.NET Framework 4.8.1), KB5087539 (Windows Server 2025 CU), KB5089717 (Servicing Stack). Exchange SE HU6 (KB5081755) was installed around the same period.
Workaround: Sending via OWA works. Not acceptable long-term.
Has anyone seen this? Is this a known regression in HU6 or KB5087051?
2 Replies
The issue has been independently reproduced on a second Exchange Server SE on-premises environment (confirmed by external consultant). This confirms the bug is not environment-specific.
Root cause narrowed down further:
The corruption is PDF-structure-specific. We tested two PDFs:
- Working: PDF with traditional xref table, 1 object stream → arrives intact
- Broken: PDF using only cross-reference streams (/Type /XRef), 5 object streams (/ObjStm), no traditional xref table → truncated to ~13 KB
We converted the broken PDF using pikepdf (ObjectStreamMode.disable), forcing a traditional xref table and removing all object streams. The converted version (same content, different structure) arrived intact via Outlook Desktop.
Conclusion: The X-SDDS store delivery step in Exchange SE 15.2.2562.41 fails specifically when processing MAPI/TNEF attachments that are PDFs using cross-reference streams without a traditional xref table (compact PDF 1.5 format).
