HOWTO: Read unmounted Exchange EDB files.

I was recently asked this question similar to this:

 

How can we search on unmounted EDB files?  Are there any API's that I can use to access the mails in unmounted EDB?

 

There are two answers: 

 

“No” and “It’s a bad idea”.

 

Further:

 

There is no support for accessing unmounted EDB files. There are no Microsoft APIs for doing this. There are third-party APIs on the web.  The format for these files is not really documented and thus is not something you should depend-upon.  If you use a third-party application to access an EDB which is mounted, you may cause corruption or potentially take down Exchange.  Any API which alters data in an EDB is risking causing corruption.  If you choose to still try to read the unmounted EDB file, you should note that you may not get all of the data you are seeking – remember that information may be in the STM file and not the EDB until its data is promoted to the EDB file. 

 

What about recovery of an EDB?

There are some third-party applications which do fixes against an EDB.  These are not supported by Microsoft.  Remember that Exchange 2000 and 2003 have two data stores and not just one. Information is sync'd between the two based upon need.    The process of syncing the data between both databases does cause a performance hit, so only what’s needed is synchronized.  Because of this, the EDB file may not (most likely will not) have all the data needed for a full restore.  Please read the links below and fully understand how the database files which Exchange is driven off of work together.

 

In a production environment, nobody should be attempting to repair an EDB file.  Thats what backup software is for.  Brick-level (item & property) backups are not supported by Microsoft.  Exchange is supported with backup software which uses VSS or the older Exchange Backup API. Also remember that Exchange integrates heavily with AD, so AD should always have its data backed-up.

 

I know that there are a number of third party APIs, backup and recovery programs out there which may work where you have no other path forward.  However, such software/APIs should only be used as a last resort.  Its best to use supported soltuions - which you know will work now and in the future.

 

Microsoft Support can assist with recovering data with supported tools.  So, if you need to recover data, please contact them.

 

How about ESE.DLL or anything else people try to use to get at EDB content:

 

Developers sometimes try to use the ese.dll in order to get at EDB content.  It’s clearly spelled-out in MSDN that it’s not supported to do this.

 

Microsoft support policy for third-party products that modify or extract Exchange database contents

https://support.microsoft.com/en-us/kb/904845

 

I know that one section of the article indicates that you "might" be able to access the store in a read-only mode but there are some major differences in the different implementations of the ESE engine that can get you into some real problems.

Although this is a documented API and is very similar to ESE used with Exchange, it is not designed for use with Exchange and has limitations/differences that can result in problems with the Exchange store. I also suspect that the ESE functionality is going to be newer than the ESENT functionality since ESE/Exchange is continuing to be updated. It would not be surprised if any ESENT based apps that you get to work, fail with future releases since we have no commitment to ensure that ESENT works with Exchange.

The third-party tools and APIs mentioned above may use ese.dll to accomplish what they are doing.  However, it’s not supported or recommended by Microsoft at all. 

 

Here is some homework if you wish to know more:

 

Exchange Storage Architecture

https://technet.microsoft.com/en-us/library/bb124808.aspx 

 

Exchange Transactions and the Exchange Database Overview

https://technet.microsoft.com/en-us/library/aa996118(EXCHG.65).aspx#TheEdbFile 

Also see:

About: Exchange APIs to backup and restore data
https://blogs.msdn.com/b/webdav_101/archive/2015/06/01/about-exchange-apis-to-backup-and-restore.aspx

Please note (11/4/2013):   In the past 20 days there have been eight comment postings by entities portraying themselves as separate companies with Exchange recovery tools which directly read Exchange’s EDB files. This is a lot since I’ve only seen two such comment posts on since I wrote this article five years ago.  Further, two those comments were posted early last Saturday morning for different products which seem to do the same thing.  I can only assume that were all posted by people trying to spread malicious software.  So, I’m going to need to approve all comments on this post from here on.

Comments

• Anonymous
  September 03, 2008
  > There are no Microsoft APIs for doing this Actually, yes, there are - it's called ese.dll, and the APIs are documented on MSDN. (Yes, I did wrote some code that worked on detouched .edb files in the past, for an Exchange backup solution. Apparently, customers really want to be able to browse their Exchange backups and view individual emails without a live Exchange instance).

• Anonymous
  September 04, 2008
  The comment has been removed

• Anonymous
  September 04, 2008
  The comment has been removed

• Anonymous
  September 17, 2008
  Sorry for a delayed reply. I've posted the comment with details at the post you've linked to.

• Anonymous
  December 23, 2008
  Does the store always take responsibility for synching the streams in the EDB and STM?  I read somewhere in the SDK that there are cases when a stream's properties may not be auto-promoted to fields in the EDB, and it is up to the developer to re-write the fields. It's been a few months since I opened the 'SRZ' case with PSS (and got no results), but I do remember that it dealt with a WEBDAV POST, and there is similar documentation in the Exchange SDK in the CDO section.  I'll dig this up if you need me to...

• Anonymous
  December 23, 2008
  Hello Chris; The store will sync info between these stores on an as-needed basis.  Syncing data is very expensive performance wise, so the store only does this when it really needs to. These stores are the backend database and your code should not need to worry about the syncing. However, I have seen a bug in the past where properties were not promoted to the mapi store and a proppatch had to be done to help force the syncing of some properties  - it was a very specific issue though. It sounds like you had run into a similar issue - either that or you were working with some properties which don't get promoted for some reason.   In Exchange 2007, there is just one store - MIME would be generated on the fly as needed and is not kept. Please let me know where you read that you had to update properties because they were not promoted. Thanks, Dan

• Anonymous
  September 01, 2010
  In regards to the post left by  int19h, I've checked the link and your post is not there. Would you be so kind as to share the details once again? Thanks in advance

• Anonymous
  July 13, 2011
  The comment has been removed

• Anonymous
  August 28, 2013
  Sorry Allenseikh, but please don't post advertisements.