When you spin up a fresh Exchange Server, it drops a default mailbox database in place—usually named something like “Mailbox Database 123456789.” It’s fine for lab setups, but in production? I’ve never kept it. Naming conventions, DAG prep, and storage planning all push me to remove it early in the setup.
I’ve done this on Exchange 2016 and 2019, mostly in hybrid environments. Not gonna lie, the first time I tried removing the default DB, I thought it’d be a quick delete. Spoiler: it’s not. Exchange has its claws in that database—system mailboxes, arbitration mailboxes, even leftover move requests can block you.
Here’s how I usually go about it.
1. Check for Mailboxes (Yes, Even Hidden Ones)
Before touching anything, I run:
Get-Mailbox -Database "Mailbox Database 123456789"
That shows user mailboxes, but don’t stop there. You’ll also want:
Get-Mailbox -Database "Mailbox Database 123456789" -Arbitration
Get-Mailbox -Database "Mailbox Database 123456789" -Monitoring
Get-Mailbox -Database "Mailbox Database 123456789" -AuditLog
These system mailboxes are sneaky. If you miss them, the delete will fail and you’ll be stuck wondering why.
2. Rename It (Optional, But I Usually Do)
Sometimes I rename the default DB before moving mailboxes, just to keep things clean in the EAC. Helps me track what’s legacy vs. what’s active.
Set-MailboxDatabase "Mailbox Database 123456789" -Name "LegacyDB"
3. Move Everything Out
This part takes patience. I use New-MoveRequest for each mailbox:
New-MoveRequest -Identity "SystemMailbox{GUID}" -TargetDatabase "NewDB"
Then monitor with:
Get-MoveRequest | Get-MoveRequestStatistics
If you’re running this on a dev box or low-spec VM, expect delays. I’ve had move requests hang for hours on a 4GB RAM test server.
4. Delete the Database (Finally)
Once everything’s moved and the move requests are cleared, you can delete the DB from EAC. But heads up: this only removes it from Exchange. The EDB file still sits on disk.
5. Clean Up the Files
I go into the file system and manually delete the .edb and log files. Usually under:
C:\Program Files\Microsoft\Exchange Server\V15\Mailbox\<DBName>\
Make sure no services are locking the file. I’ve had to stop the Information Store once to get rid of a stubborn log file.
6. Post-Removal Checks
After cleanup, I run:
Get-MailboxDatabase
Just to confirm it’s gone. Then I check services—Transport, Mailbox Assistants, etc.—to make sure nothing’s broken.
Lessons Learned
- Don’t rush the mailbox moves. Even one leftover arbitration mailbox will block deletion.
- Always clear move requests after completion. I’ve missed that step before and it cost me an hour.
- If you’re scripting this, build in pauses or checks. Exchange doesn’t always update status instantly.
Final Thoughts
Removing the default Exchange DB isn’t hard, but it’s easy to mess up if you skip steps. I’ve done this enough times to know what to watch for—but every environment throws its own curveballs.
Ever had a mailbox move freeze mid-transfer? Or a phantom mailbox block deletion? Drop your experience in the comments—I’d love to hear how others handle this.
