Attachment failures in on-premises Public Folders traced to a mismatched EMSMDB32.DLL version (Office M365 july update)

Question

Posting this because our case was closed by Microsoft Support as "no known issue documented," despite a reproducible file-level defect. Sharing here in case it helps others hitting the same wall — and in case someone from the product team is watching this thread.

Environment: Multi-site enterprise deployment Microsoft 365 Apps for Enterprise via MECM, Outlook connecting to on-premises Exchange Server Public Folders over Outlook Anywhere (RPC/HTTP). Not using Outlook on the web or MAPI/HTTP for these folders. Updates are pushed through standard Click-to-Run servicing. affected build, 16.0.20131.20152, was received through the normal monthly update cycle

Symptom: Starting with Version 2606 (july), users could no longer attach files to items in on-premises Public Folders, including Public Folder calendar items — both existing and newly created items were affected.

Root cause: Comparing file versions inside the Office16 install folder shows EMSMDB32.DLL was not rebuilt alongside the rest of the package in the affected builds — it stayed on an older sub-build while OUTLOOK.EXE and OLMAPI32.DLL moved forward. This creates an internal version mismatch in the RPC/MAPI provider used specifically for on-premises Exchange connections.

In every case, the failure correlates directly with EMSMDB32.DLL remaining at 16.0.20131.20044 instead of matching the rest of the package — including in the Current and SemiAnnuel Channel, confirming this affects each channels built from the 20131.x branch (v.2606), not only Monthly Enterprise.

Workaround: Roll back to Version 2605 (build 16.0.20026.20166 or 16.0.20026.20236), where all three files are version-aligned.

If anyone else is on Exchange on-prem version with Public Folders and hitting attachment failures on 2606, this file comparison is worth running — the symptom can look like a permissions issue but isn't one.

We hope Microsoft will do a patch cause we have 10 000 devices, and rollback (uninstall M365 and reinstall june version) is not the best solution...

Answer 1

Hi @Jonathan, 

Thank you for taking the time to submit the feedback. I've upvoted it to show my appreciation for your effort in documenting and sharing this issue.

Hopefully, this thread and feedback report will gain more visibility within the community and help other users find and reference it when encountering the same issue.

Answer 2

Good day @Jonathan, 

Thank you for taking the time to share such a detailed investigation. As a fellow community member, I genuinely appreciate the level of effort you've put into documenting the environment, affected builds, file version comparisons, and the workaround you've identified. This information may be helpful to other administrators troubleshooting similar behavior. 

While my own environment is nowhere near the scale of yours, I can certainly imagine the impact. With a deployment of around 10,000 devices, a rollback is much more than a simple workaround. Beyond the time required to deploy it, there are also the operational risks, bandwidth consumption, change management considerations, and the potential for introducing inconsistencies across the environment while devices transition between versions. Given those factors, I understand why a large-scale rollback or redeployment would not be an ideal long-term solution. 

Your findings may prove very useful to other administrators who are still using on-premises Exchange Public Folders and encounter similar attachment issues after updating to Version 2606. 

That said, as this is primarily a user-to-user support forum, we're somewhat limited in our ability to bring potential product defects to the attention of the engineering teams. If you haven't already done so, I would strongly encourage submitting your findings through the: Exchange Server · Community

This is an official channel for submitting product feedback, where reports may be reviewed and considered by the relevant Microsoft teams.  

If you do create a feedback entry, it would be greatly appreciated if you could come back and share the link in this thread. That would make it easier for other customers experiencing the same issue to find it, contribute additional data points, and upvote the report, which may help increase its visibility. 

Additionally, you may want to ask whether the existing Microsoft Support case can be reopened or create a new case if necessary, referencing the previous case number. You can request further review based on the reproducible evidence you have gathered and ask whether the case can be escalated to the appropriate support or product group for investigation. 

Given the scale of your environment, you may also ask Support to help evaluate the least disruptive mitigation options available pending further investigation and confirmation.  

Thanks again for sharing your analysis and temporary workaround with the community. Regardless of the eventual outcome, you've already provided information that may save others a significant amount of troubleshooting time.  

I hope the reported behavior receives further review and that appropriate remediation is provided if Microsoft confirms it as a product issue.