Sage CRM Exchange Integration “Not Working” in 2025 R2: the Hibernate DTD 403, what’s breaking, and the safest fix

Over the past week, Sage CRM partners and admins have reported a sudden failure in Exchange Online integration on Sage CRM 2025 R2 (and 2025 R1). What started as scattered “is it just us?” grumbling has now turned into a proper forum flare-up — the kind where every refresh produces another thread and someone inevitably threatens to take up pottery instead of IT.

The common thread in the logs is a Hibernate XML mapping reference that’s being resolved at runtime — and failing with HTTP 403 — which can prevent the Exchange Sync Engine from functioning normally. (Community Hub)

Sage has since published an official workaround for Sage CRM 2025 R1 and 2025 R2, validated against the issue. (Community Hub)

What the issue looks like in the real world

Admins typically spot one (or both) of these symptoms:

• Sage CRM Exchange Online sync stops working (appointments/tasks/contacts depending on configuration), often after previously working normally.
• Exchange Sync Engine fails or can’t process sync requests, with errors in Tomcat/engine logs.

A frequently reported log signature includes a failure to read a Hibernate DTD, for example:

• org.dom4j.DocumentException… Server returned HTTP response code: 403 for URL: hibernate.org/hibernate-mapping-3.0.dtd (Community Hub)

That 403 is the clue: the Sync Engine is trying to resolve a DTD over the network and getting blocked.

What’s actually causing it

Sage’s investigation pins the trigger on recent changes in Exchange Online validation behaviour. In short: Exchange Online has become less tolerant of certain XML headers that include malformed or deprecated URLs, and what used to slide through now gets rejected. (Community Hub)

Separately (and more visibly in the logs), the Exchange Sync Engine relies on Hibernate configuration/mapping XML files (notably hibernate.cfg.xml and *.hbm.xml). Those files include legacy DOCTYPE declarations that reference Hibernate DTDs using older host/path variants (with/without www, with missing /dtd/, old SourceForge hostnames, and so on). A community-provided script describes the goal bluntly: correct the DOCTYPE references to avoid network lookups that are now returning 403, and to push Hibernate to use its embedded DTD resolution instead. (Pastebin)

Put together, the situation is roughly:

• Legacy Hibernate DOCTYPE URLs exist in the Sync Engine XML.
• Those URLs can now fail (403) or be treated as invalid in stricter validation paths.
• Exchange Online integration breaks — even though Sage CRM itself didn’t change at the moment the failures began. (Community Hub)

Who is affected (and who is not)

According to Sage:

Affected

• Customers using Exchange Online with the Sage CRM Exchange Sync Engine.
• Systems where Exchange integration previously worked and then stopped. (Community Hub)

Not affected

• On-premise Exchange Server integrations.
• OAuth2-based import of Contacts and Emails (this is separate from the Sync Engine).
• Other Sage CRM email functionality. (Community Hub)

The verified solution (official Sage workaround for 2025 R2)

Sage has published an official workaround for Sage CRM 2025 R1 and 2025 R2. It uses a PowerShell script to update:

• hibernate.cfg.xml
• .hbm.xml

…so that legacy/malformed DTD URLs are corrected. The script also creates .bak backups of any file it changes. (Community Hub)

At a high level, Sage’s supported steps are:

1. Download the Sage-provided zip and place the script on the CRM server. (Community Hub)
2. Edit the script’s $root path to match the Exchange Sync Engine install directory (under Tomcat’s webapps). (Community Hub)
3. Stop the Tomcat service used by the Exchange Sync Engine. (Community Hub)
4. Run the script (as admin). (Community Hub)
5. Clear Tomcat’s work directory (..\\tomcat\\work\\Catalina\\) so cached artefacts don’t keep the old references alive. (Community Hub)
6. Restart the Tomcat service, then validate sync. (Community Hub)

Sage also provides rollback steps (restore the .bak files, clear the work directory, restart). (Community Hub)

The “good Samaritan” script (what it does, and why it worked)

Before the official workaround landed, a community member (Patrice_LT) shared a PowerShell script after diagnosing the Tomcat logs and identifying “bad URL in XML headers”. (Community Hub)

That Pastebin script (dated 2 Feb 2026) scans the Exchange Sync Engine directory for *.hbm.xml and hibernate.cfg.xml, then performs regex replacements to normalise common “faulty” patterns, including:

• https?://hibernate.org/hibernate-mapping-3.0.dtd
• https?://www.hibernate.org/hibernate-mapping-3.0.dtd (missing /dtd/)
• legacy hibernate.sourceforge.net/...

…and rewrites them to the canonical form:

• http://www.hibernate.org/dtd/hibernate-mapping-3.0.dtd (and the equivalent configuration DTD) (Pastebin)

It also:

• Creates .bak backups for modified files
• Prints a clear “stop Tomcat / clear work / restart” reminder at the end (Pastebin)

Important caution: the script explicitly requires the $root path to be changed per environment, otherwise it will scan the wrong folder (or nothing at all). (Pastebin)

Given Sage has now validated and published an official version for 2025 R2, organisations should prefer the Sage-supported script for production use. (Community Hub)

Validation checklist after applying the workaround

Sage recommends confirming that:

• The Exchange integration reconnects successfully in Sage CRM.
• Synchronisation resumes as expected after the Tomcat restart. (Community Hub)

If errors persist, Sage’s admin guidance is to review the relevant log sets depending on sync direction (CRM → Exchange vs Exchange → CRM) and isolate whether failures correlate with specific entity sync operations. (Sage CRM Help Center)

What about Sage CRM 2023/2024 versions?

Sage has stated that testing/validation is ongoing for:

• Sage CRM 2023 R1 / R2
• Sage CRM 2024 R1 / R2 (Community Hub)

Until Sage confirms guidance for those versions, the safest approach is to follow Sage’s official updates rather than improvising in production.

Final thought (with the promised warning label)

This is one of those bugs where the “root cause” isn’t a single villain — it’s more of a committee: legacy XML references, network lookups, stricter validation, and a sync engine that’s understandably grumpy about surprise rule changes.

Or, put less politely: nothing screams “enterprise software” like a mission-critical integration depending on a URL that the internet is free to stop liking at any time.

Need help with your integration? Contact Astech today.

‍