EDB File Documentation

Summary

An EDB (Exchange Information Store Database) file is the mailbox database of a Microsoft Exchange Server: every user’s e-mail, contacts, calendar and folders held in one large file. It is built on Microsoft’s Extensible Storage Engine (ESE) and is not a file you double-click, because Exchange keeps it open and reads it directly. To pull mail from an offline or orphaned EDB, administrators use Exchange’s own tools (eseutil, New-MailboxExportRequest) or a third-party EDB-to-PST converter.

Technical details

FeatureValue
Full nameExchange Information Store Database (ESE / Extensible Storage Engine)
File extension.edb
MIME typeapplication/octet-stream
Format typeESE B-tree transactional database (binary)
EngineExtensible Storage Engine (ESE), historically “Jet Blue”
DeveloperMicrosoft Corporation
Used byExchange mailbox store; also Windows Search (Windows.edb), Active Directory (ntds.dit)
Open standardNo — proprietary
Byte orderLittle-endian
Magic number (hex)EF CD AB 89 (value 0x89ABCDEF) at offset 4
Header sizeFirst database page; header at least 668 bytes
Page sizeFixed, defined in header (typically 32 KB on modern Exchange)
Companion filesTransaction logs (.log), checkpoint (.chk), legacy stream (.stm)
Native toolseseutil, New-MailboxExportRequest
Related extensions.stm, .log, .pst, .ost
Specificationlearn.microsoft.com/exchange/
File signature (magic bytes)
EF CD AB 89

Offset 4, 4 bytes. This is the little-endian encoding of the 32-bit value 0x89ABCDEF, the ESE database magic number (ulMagic). Bytes 0–3 are a header checksum, so the signature sits at offset 4, not offset 0. The same signature marks every Extensible Storage Engine database, so it identifies “an ESE database” in general; an Exchange mailbox store, the Windows Search index, or an Active Directory ntds.dit, rather than Exchange specifically.

What is an EDB file?

EDB is the database file format of Microsoft Exchange Server, the enterprise mail and calendar platform. An Exchange mailbox database (.edb) is the central store that holds every mailbox assigned to it: all users’ messages, attachments, contacts, calendar items, tasks and folder structure, in a single large file managed by the server. It is built on Microsoft’s Extensible Storage Engine (ESE), historically code-named “Jet Blue”, an indexed, transactional B-tree database engine that also underpins Windows Search and Active Directory.

Because an EDB is a live server database, you do not open it like a document. Exchange keeps the file locked and reads and writes it directly. Administrators only handle an EDB in recovery and migration scenarios: a database left offline after an unclean shutdown, a backup copy, or an orphaned EDB from a decommissioned or crashed server where the original Exchange is gone. The rest of this page explains how the file is structured and what the recovery tools actually do to it.

The ESE engine: pages, B-trees and transactions

ESE stores everything in fixed-size pages. The page size is recorded in the database header and is a multiple of 4 KB; modern Exchange uses 32 KB pages. Every page carries its own checksums so corruption can be detected and, for single-bit errors, corrected: each page holds an ECC (error-correcting code) checksum for single-bit repair plus a higher-fidelity XOR checksum that catches multi-bit damage the ECC would miss. Pages are linked into B-trees, the balanced tree structure that lets ESE find a record in a large table with a small number of page reads.

ESE is transactional: changes are written first to sequential transaction-log files (.log) and only later committed into the .edb pages. A checkpoint file (.chk) records how far the logs have been applied. This write-ahead logging is why the log files are not optional clutter: if the database stops before its in-memory changes are flushed, the missing updates live only in the logs, and replaying them is the only way to bring the database to a consistent state. Deleting the logs of a database that needs them loses those transactions, which can corrupt the store.

The database header and shutdown state

The database header occupies the first page (with a backup copy in the second page) and is at least 668 bytes. It begins with a page checksum in bytes 0–3, followed at offset 4 by the ESE magic number ulMagic, the little-endian value 0x89ABCDEF (bytes EF CD AB 89). The header also records the format version, the page size, and, critically for recovery, the database state: Clean Shutdown or Dirty Shutdown.

eseutil /mh mailbox.edb      # dump header: reports Clean or Dirty Shutdown
eseutil /r E00               # soft recovery: replay logs (prefix E00)
eseutil /p mailbox.edb       # hard repair: LAST resort, can discard data

A Dirty Shutdown means the database was not closed cleanly and still needs its transaction logs replayed. The correct fix is a soft recovery (eseutil /r), which replays the outstanding logs to reach a clean state without losing data. A hard repair (eseutil /p) forcibly discards whatever it cannot fix, so it can lose mailbox data and is a last resort, always run on a copy. The eseutil /mh command reads the header and reports which state the database is in, which is the first diagnostic step for any EDB that will not mount.

Mailbox tables inside the store

Inside the ESE structure, Exchange lays out its own schema of tables. Above the raw pages and B-trees, the store organises mailboxes, the folders within each mailbox, and the messages within each folder, along with attachments and item properties. A message is not a discrete file: its subject, body, recipients and flags are property values spread across the store’s tables and indexed for fast search and retrieval. Older Exchange versions (up to Exchange 2007) paired the .edb with a streaming .stm file that held native-format content such as MIME message bodies; from Exchange 2010 onward that content moved into the EDB and the .stm disappeared.

This internal structure is why an EDB cannot simply be opened and read as a set of e-mail files. Reconstructing a mailbox means walking the ESE tables to reassemble each item from its property values, which is exactly what Exchange’s export tools and third-party EDB readers do.

Getting mail out: export, not rename

Extracting mailboxes from an EDB is an export operation, never a file rename. With a running Exchange server, the database is brought to a clean state if needed (via eseutil), mounted, and then each mailbox is exported to an Outlook PST file with the New-MailboxExportRequest PowerShell cmdlet:

New-MailboxExportRequest -Mailbox "jsmith" `
  -FilePath "\\server\share\jsmith.pst"

When the original Exchange server is gone, Microsoft’s own tools cannot help, because they require Exchange. This is where third-party EDB-to-PST converters and viewers come in: they read an offline .edb directly, walk the ESE tables themselves, and let you browse or export mailboxes to PST, EML, MSG or MBOX. A free read-only viewer is useful for inspecting an orphaned database before committing to a paid export. In every case the workflow is the same: bring the database to a consistent state, then export the mailbox items into a portable mail format.

When an .edb is not an Exchange mailbox

The same .edb extension and the same ESE engine are reused by other Microsoft components, which is a common source of confusion. A file named Windows.edb in ProgramData\Microsoft\Search is the Windows Search index, a rebuildable system file that catalogues local files and content; it is not a mailbox store, and if it grows too large you can rebuild it from Control Panel › Indexing Options. Active Directory’s database, ntds.dit, is another ESE database, managed only by domain-controller tools. All three share the EF CD AB 89 signature because they share the engine, but only the Exchange mailbox store holds e-mail.

Operational risk: logs, locks and sensitive data

An EDB itself is passive data, but the realistic risks are operational rather than malware. It is a live, locked server database: never copy, move or hand-edit an in-use EDB, and never delete its matching .log files, since doing so can corrupt the store and lose every mailbox in it. Always work on a backup copy, and treat eseutil /p as a last resort because a hard repair can drop data. An EDB also contains an entire organisation’s e-mail, so it is highly sensitive and exports should be handled under proper access controls. Download any third-party EDB tool only from the vendor’s official site.

Frequently asked questions

How do I open an EDB file?

You do not open it like a document; it is an Exchange Server database. On a live server, Exchange reads it and you export mailboxes with New-MailboxExportRequest. For an offline or orphaned EDB, use a third-party EDB viewer or an EDB-to-PST converter that reads the database directly and extracts the mail.

How do I convert an EDB to PST?

With a running Exchange, run eseutil if the database is in a dirty shutdown, then New-MailboxExportRequest to export each mailbox to a PST. Without Exchange, an EDB-to-PST tool reads the offline database and writes PST, EML or MSG files.

Is the big Windows.edb on my PC the same thing?

No. Windows.edb is the Windows Search index, a rebuildable system file in ProgramData\Microsoft\Search, not an Exchange mailbox store. If it grows too large, rebuild the index from Control Panel › Indexing Options. It is unrelated to e-mail, though it uses the same ESE engine.

My EDB won't mount, it says “dirty shutdown”. What now?

The database was not closed cleanly. Run eseutil /mh to confirm the state, replay the transaction logs with a soft recovery (eseutil /r), and only as a last resort do a hard repair (eseutil /p), which can lose data. Always work on a backup copy.

References