What Is an EDB File? The Exchange Mailbox Database, Where It Really Lives and How to Fix It
An EDB file is the database Microsoft Exchange keeps every mailbox in. Jump to your question below, or read it through in order.
An EDB file is the database Microsoft Exchange keeps every mailbox in. Jump to your question below, or read it through in order.
An EDB file is an Exchange database file. Microsoft Exchange Server stores the mailboxes it hosts inside one, so a single file can hold the mail, calendars and contacts of hundreds of people.
It lives on a mail server, not on a desktop. If you found an .edb file on your own laptop, it is almost certainly the Windows Search index instead.
Think of an EDB file as a filing cabinet for a whole company. A PST file holds one person's mail. An EDB file holds everybody's.
Microsoft's own wording is plain. In the Exchange documentation a mailbox database "is stored as an Exchange database (.edb) file". EDB is short for Exchange Database, and you will also hear it called the information store or simply the mailbox database.
That one fact explains most of what follows. The file belongs to a running server, so you cannot double-click it and Outlook cannot mount it. Fixing one works nothing like fixing a desktop mail file.
| File | Lives on | Holds | Opened by |
|---|---|---|---|
.edb | A mail server | Every mailbox on that database | Exchange Server itself |
.pst | Your computer | One person's mail, often the only copy | Outlook, by opening the file |
.ost | Your computer | A cached copy of one mailbox | Outlook, through its own profile |
Read down the middle column and the pattern is clear. An OST file is a copy of one mailbox that sits inside an EDB file somewhere. The EDB file is the original.
This page is written for whoever has to deal with the file. That is usually an administrator with server access. Where a step needs the Exchange Management Shell, it says so and gives the command.
Not every .edb file is an Exchange database. Check the name first. Windows.edb is the Windows Search index and none of the Exchange advice on this page applies to it.
This is the step almost every guide skips, and skipping it is why people end up reading about mail servers when they have a search index problem.
The .edb extension is not owned by Exchange. It belongs to the Extensible Storage Engine, a database engine built into Windows. Microsoft describes ESE as a storage technology that lets applications store and retrieve data from tables. Plenty of Windows components use it, and several of them name their file .edb.
So the extension tells you how the file was built. The file name and the folder tell you what it is for.
| What you have | What it is for | What to do next |
|---|---|---|
Windows.edb | The search index on one computer | Shrink it through Indexing Options. Section 5 |
| An Exchange database | Every mailbox on that database | Find its real path with PowerShell. Section 4 |
DataStore.edb | Windows Update history | Leave it. Windows rebuilds it if you clear the update cache |
edb.chk, E0*.log | Exchange checkpoint and logs | Never delete by hand. Section 3 explains why |
Do not delete an EDB file to free up space. On a server you would be deleting everybody's mail. On a desktop you would be deleting an index Windows is still using, and it will simply rebuild.
If space is the problem, the safe versions of that idea are in the section on shrinking a database and the one on Windows.edb.
An EDB file holds whole mailboxes: mail, attachments, calendars, contacts, tasks and folder permissions. It does not stand alone, because its transaction logs hold changes not yet written into it.
Everything a person sees in Microsoft Outlook when they are connected to the server is in there. Multiply that by every mailbox assigned to the database.
Shared content counts too. A public folder sits in its own database on older servers and inside a mailbox on newer ones. Either way the bytes end up in an EDB file.
Copy an EDB file on its own and you may have copied something incomplete. Exchange writes changes to transaction logs first and folds them into the database afterwards.
| File | What it is | Safe to delete |
|---|---|---|
.edb | The database itself | Never |
E0*.log | Transaction logs, changes not yet committed | Only after a successful full backup |
edb.chk | The checkpoint, marking how far the logs have been applied | Never by hand |
A database that shut down cleanly has everything it needs. One that did not still has changes sitting in the logs, and removing those logs loses them for good. That is the single most common way an EDB file gets damaged by the person trying to help it.
There is no one fixed path. Microsoft's documented default is %ExchangeInstallPath%Mailbox\<DB name>\<DB name>.edb. Run Get-MailboxDatabase to get the real path on your server.
Search for this and you will find the same hardcoded path on page after page, usually ending in Exchange Server\V15\Mailbox. It is a reasonable guess. It is not the answer.
Microsoft's reference for the New-MailboxDatabase command states the default plainly. The database goes to %ExchangeInstallPath%Mailbox\<Mailbox DB Name>\<Mailbox DB Name>.edb, and that applies from Exchange 2010 all the way to Exchange Server Subscription Edition.
Read that carefully. The path follows wherever Exchange was installed. Many administrators put Exchange and its databases on a separate volume on purpose, so a path starting C:\Program Files is wrong on those servers from day one.
One line of PowerShell in the Exchange Management Shell gives you the true path of every database in the organization. Microsoft confirms that running it with no parameters returns information about all mailbox databases.
V15 does not mean Exchange 2013. Exchange 2013, 2016 and 2019 all use V15 in the install path. Guides that read V15 as a version number get the vintage of the server wrong.
Windows.edb is the Windows Search index, not email. Microsoft documents it at %ProgramData%\Microsoft\Search\Data\Applications\Windows.
If you arrived here after finding a multi-gigabyte .edb file eating your disk, this is your section. It has nothing to do with Exchange.
Windows Search keeps its index in a single ESE database called Windows.edb. It grows with the amount of content Windows has been told to index, and it can reach several gigabytes without anything being wrong.
Microsoft names one cause directly. When Windows Search indexes an Outlook PST archive, Windows.edb grows in proportion to the size of that PST. Point the indexer at a 20 GB archive and the index swells to match.
So the fix is not to delete the file. It is to stop indexing the thing that filled it.
Deleting Windows.edb by hand is not the answer. Windows Search rebuilds it immediately, so you get the same file back and a slow machine while it works. Rebuilding through Indexing Options does the same job in a supported way.
Exchange supports a database of roughly 16 TB. Microsoft's best practice is far lower: 200 GB on a standalone server, 2 TB where the database has copies in an availability group.
People ask for the maximum size and get a number that does not help them. Exchange will carry a database far bigger than you should ever give it.
Microsoft publishes both figures, and they apply to Exchange 2016, Exchange 2019 and Exchange Server SE alike. The supported ceiling is about 16 terabytes. The recommended size is a fraction of that, and the reason is restore time rather than the format.
| Setup | Supported | Best practice |
|---|---|---|
| Standalone, no database copies | ~16 TB | 200 GB or less |
| With copies in an availability group | ~16 TB | 2 TB or less |
Microsoft also says to provision disk for 120 percent of your calculated maximum database size. A database that exactly fills its volume has nowhere to grow and nowhere to be maintained.
The question worth asking is not how large the file may be. It is how long your company can sit without email while you restore it. Size the database to fit that answer and the rest follows.
This one catches people out because it looks like corruption and is not. Exchange Standard Edition has a default database size limit of 1,024 GB. Enterprise Edition has no default limit at all.
The Exchange store checks database sizes on a schedule. When a Standard Edition database passes the limit, Exchange dismounts it on purpose. Mail stops, and nothing in the file is actually damaged.
Microsoft's stated resolution is a licence, not a registry edit. To get full availability group functionality back you buy an Enterprise Edition licence and apply it to the server.
There is a documented registry workaround that mounts the database again. Treat it as a way to buy time, not a fix. Get the database GUID from Get-MailboxDatabase first.
You cannot open an EDB file by double-clicking it and Outlook cannot mount one. An Exchange database is read by the Exchange server that owns it, or restored into a recovery database.
Older guides tell you to right-click the file and pick Open With. That advice has never worked. Windows has no handler for the format, and no desktop mail program can mount an Exchange database.
What you do instead depends on whether the server that owns the file still runs.
The server still works? Open the mailbox, not the file. Grant yourself access to the mailbox you need and open it in Outlook or on the web. The database is already mounted and doing its job.
Only the file is left? Mount it as a recovery database. Exchange can mount an orphaned EDB file alongside the live ones so you can pull mailboxes out of it.
This is the supported way to read an EDB file that is no longer attached to a live mailbox. It needs an Exchange server to do the work, but it needs no extra software.
.edb file and its logs to the recovery server. Always work on a copy.ESEUTIL /MH <database>.edb. It reports Clean Shutdown or Dirty Shutdown.ESEUTIL /R before going further.New-MailboxDatabase -Recovery, pointing -EdbFilePath at your copy.New-MailboxRestoreRequest.Plenty of tools open an EDB file without Exchange. They earn their price in one situation: the server is gone for good and you have no Exchange left to mount a recovery database on.
If you still have a working Exchange server, the recovery database route does the same job, costs nothing and is supported by Microsoft. Try it first.
Check the file is what you think it is before any of this. If it is called Windows.edb, none of these steps apply. The second section tells the two apart in half a minute.
On a working server, New-MailboxExportRequest writes a mailbox straight out to a PST file. No extra software, and it is the supported route.
Use this when somebody is leaving, a mailbox is being retired, legal has asked for a copy or you are about to migrate off this server.
Search for EDB to PST and every result sells a converter. Most of the time you do not need one, because Exchange exports to PST on its own.
Get-MailboxExportRequest, then clear finished jobs with Remove-MailboxExportRequest.The result is an ordinary PST file. Anyone can open it in Outlook, and it carries the same limits and habits as any other PST, including the need to back it up.
Export before the server is switched off, not after. While Exchange runs, this command is free. Once the server is gone, an orphaned EDB file is all you have and a converter becomes the only option.
That is the real difference between the two routes. It is not quality. It is timing.
Before repairing, look for a backup or a database copy. Restoring is faster and keeps everything. ESEUTIL /P is a last resort and it throws away whatever it cannot read.
A database that will not mount feels like an emergency, so people reach for the repair tool first. That order is backwards and it costs data.
Ask one question before anything else. Is there a backup, or a healthy copy of this database in an availability group? If the answer is yes, restore it. A restore brings back everything. A hard repair does not.
Plenty of mount failures have nothing to do with damage. Work down this list before you touch ESEUTIL.
Use this when there is no backup, no healthy copy and the database will not replay its logs.
.edb file somewhere else. Everything below happens on the copy.ESEUTIL /MH and read the state. Clean Shutdown means the file is consistent already.ESEUTIL /R first. Replaying logs is the non-destructive repair.ESEUTIL /P. This is the hard repair and it discards what it cannot read.ESEUTIL /D and then ISINTEG or its modern equivalent, because a hard repair leaves the database internally untidy.ESEUTIL /P is destructive by design. It makes the database mountable by dropping pages it cannot repair. You get a working database and an unknown amount of missing mail.
Run it on a copy, never on your only file. Budget hours on a large database, and expect to move the mailboxes out afterwards.
If Outlook is reporting a specific code rather than a server-side failure, start there instead. Our guides to Outlook PST errors and new Outlook errors cover the client side.
An offline defrag with ESEUTIL /D shrinks the file on disk. It takes the database offline for hours and needs free space of about 110 percent of the database size.
Delete a pile of mailboxes and the EDB file does not shrink. That surprises people, and it sends them looking for a way to force it.
Exchange keeps the freed pages as white space inside the database and reuses them as new mail arrives. The file stops growing, which is usually all you needed. Nothing is wrong.
There is one good reason to run it: a one-off event freed a large block of space that you will not refill. Moving half the mailboxes off a database is the classic case.
Outside that, the cost is real. The database is down for the whole job. The process rewrites the file from scratch, and every backup you hold stops matching it afterwards.
Get-MailboxDatabase -Status | Select Name, DatabaseSize, AvailableNewMailboxSpace.Dismount-Database. Nobody on it can send or receive until you are done.ESEUTIL /D <database>.edb and wait. Budget hours, not minutes.Moving mailboxes to a new database does the same job with no downtime. Create a fresh database, move the mailboxes across, then delete the empty one. Users stay online throughout, which is why most administrators pick this route.
An EDB file is an Extensible Storage Engine database. ESE is a Windows storage engine, which is why unrelated Windows components also produce .edb files.
You do not need this section to fix anything. It is here because it explains two things that otherwise look arbitrary.
.edbE0*.log transaction logs and edb.chk, the checkpointESEUTIL.EXEMicrosoft describes ESE as a storage technology that lets an application store and retrieve data from tables using indexed or sequential navigation. It ships inside Windows, so any component can use it.
Several do, and several of them name their database .edb. That is the whole reason the second section of this page exists. The extension describes the engine, not the purpose.
ESE stores data in fixed-size pages, indexed so the server can jump straight to a record instead of reading the file end to end. That index is what makes a database of this size usable.
Damage a page near the top of the index and Exchange loses its map of a whole region, even though the messages underneath are intact. A hard repair rebuilds the map and reports every page it had to touch, which reads as catastrophic and usually is not.
Two questions sort out most of what is left. Answer them in order.
Is it even Exchange? Check the file name. Windows.edb is the search index and has its own section. Anything under an Exchange install path is a mailbox database.
Does it still run? If yes, almost everything is easier: export to PST, move mailboxes, restore from backup. If no, you are in recovery database territory.
Seeing a numbered error instead? Our Outlook PST error guides cover the client side, and the OST file guide explains the cached copy that sits on each desktop.
Found something here that does not match your Exchange version? Send us the exact wording on screen and we will check it against Microsoft's docs.