I am supporting a customer who has a Server 2003 SBS server.
We recently migrated this customer to a new Exchange 2013 server running on a Server 2012 server.
Some of the mailboxes weren't exported to .PST files before this migration was done and the old Server 2003/Exchange 2003 SBS was demoted.
We still have a copy of the Exchange 2003 .EDB file from the old server and have been using a utility called Kernel for Exchange Server (see the screenshot) which is able to extract individual email accounts and place the contents into Outlook .PST files.
The problem is that there is a very small percentage of emails in two user's email Inboxes and Sent items folder that are in Chinese (instead of English).
This business doesn't have any Chinese employees and have never sent any emails in Chinese.
What can be done to fix this issue?
Please let me know if any further information is needed.

Dani AI

Generated

Short expert summary and next steps.

When a very small subset of items turns into Chinese after an EDB→PST extraction the root cause is almost always either a decoding/charset mismatch in the extractor (mis‑handling of compressed RTF or the message codepage) or localized item-level corruption inside the EDB. Because most messages extracted correctly, the extractor misinterpreting specific MAPI properties (for example compressed RTF vs HTML bodies or the message codepage) is the likeliest cause, not a global language setting.

Recommended non‑destructive troubleshooting plan:

  • Make full file-level copies of the EDB (and STM) and only work on copies.
  • Perform read‑only checks on the copy: eseutil /mh <path\store.edb> then eseutil /g <path\store.edb> to look for header/integrity issues. Do not run destructive repairs on the original file.
  • As suggested, mount the copied database into an Exchange 2003 recovery environment and export mailboxes with Exmerge or by using an Outlook/MAPI export. That method frequently preserves original encodings where offline readers fail.
  • Produce a second PST with a different EDB→PST tool and compare the same problem items. If the alternate tool shows English, the original extractor (Kernel) likely has a decoding bug.
  • Open a PST that shows the bad item in MFCMAPI or a PST viewer and inspect properties such as RTF/HTML body properties and the message codepage (PR_INTERNET_CPID). That comparison often reveals whether the body was stored compressed or the wrong charset was used.
  • If multiple tools reproduce the Chinese text, treat it as item/database corruption and consider professional EDB repair or staged recovery. If only a handful of items are affected and cannot be recovered, re-creating those messages from headers or requesting resend may be faster.

Operational notes: always work from copies, avoid eseutil /p on originals, and supply a single problematic MSG/EML to the extractor vendor for debugging if the defect appears tool‑specific. ’s use of Kernel plus ’s Exmerge suggestion gives a good, practical comparison to isolate whether the fault is the tool or the database.

Recommended Answers

All 2 Replies

It sounds like a bug with the software. If you do not have the original SBS 2003 machine, I think you are out of luck. You can also try restoring from backup after staging a new 2003 server in a separate domain, but I am not sure if that would work either.

It has been hit / miss with 3rd party software that reads the EDB file offline. I think you should try Microsoft Exmerge utility to convert all exchange data into outlook file format. Download from here:
Lots of help here:
https://social.technet.microsoft.com/Forums/en-US/82b432a2-12e7-46f7-b27d-46a1a94c23f7/how-to-get-outlook-recovery?forum=officeitpro
I think it will help you.

Thanks for the advice. Your link was very useful for me! Thank you!

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.