Member Avatar for jjorgensen626
jjorgensen626 30 Junior Poster in Training

Hi Everyone,

Wanted to share a bit on this subject as I've had to recently make some of these changes. Along my way I found a few sites that basically suggested moving all mailboxes off the database, dismount, delete and create a new database. Simple enough, however I didn't want to do this.

As you may or may not know, by default Exchange installs the database at the following location:
C:\Program Files\Microsoft\Exchange Server\V14\Mailbox\Database1\Database1.edb

Log files would go:
C:\Program Files\Microsoft\Exchange Server\V14\Mailbox\Database1

What if you wanted to change the location or name of those files?

Well thankfully this is super easy with powershell.

First let's get the mailbox database name, by using the Exchange Management Shell:

get-mailboxdatabase

The output should look similar to below:

[PS] C:\Windows\system32>Get-MailboxDatabase

Name Server Recovery ReplicationType
---- ------ -------- ---------------
Database1 Server1 False None
Database2 Server1 False None
Database3 Server1 False None
Database4 Server1 False None
Database5 Server1 False None

[PS] C:\Windows\system32>

Now that we can see the name of the database lets work on moving it while simultaneously renaming it. Keep in mind you wouldn't want to do this during non-maintenance hours, as the dismount will not allow users associated with that database access to their email.

dismount-database "database1"

Obvious what this does.

Here is the fun part:

Move-DatabasePath "Database1" -EdbFilePath "G:\ExchangeDBs\NewDatabase\NewDatabase.edb" -LogFolderPath "G:\ExchangeDBs\NewDatabase"

Move-DatabasePath "Database1"
::
we just selected the database

-EdbFilePath "G:\ExchangeDBs\NewDatabase\NewDatabase.edb"
::
Here we edited both the database location AND the name of the database.

Name went from Database1.edb to NewDatabase.edb.

Location went from C:\Program Files\Microsoft\Exchange Server\V14\Mailbox\Database1\Database1.edb to G:\ExchangeDBs\NewDatabase\NewDatabase.edb

Fun right?

Now we can check the status of the Database:

Get-MailboxDatabase -Status | select name, mounted

Output should look similar to below:

[PS] C:\Windows\system32>Get-MailboxDatabase -Status | select name, mounted

Name Mounted
---- -------
NewDatabase False
Database2 True
Database3 True
Database4 True
Database5 True

[PS] C:\Windows\system32>

Let's use Powershell to mount the renamed/moved database:

Mount-Database "NewDatabase"

Now we can check the status of the Databases again:

Get-MailboxDatabase -Status | select name, mounted

Output should look similar to below:

[PS] C:\Windows\system32>Get-MailboxDatabase -Status | select name, mounted

Name Mounted
---- -------
NewDatabase True
Database2 True
Database3 True
Database4 True
Database5 True

[PS] C:\Windows\system32>

How can we test our Exchange Server databases to see whether they are online and responding to client requests?

Test-MAPIConnectivity

Output should look similar to below:

[PS] C:\Windows\system32>Test-MAPIConnectivity

MailboxServer Database Result Error
------------- -------- ------ -----
Server1 NewDatabase Success
Server1 Database2 Success
Server1 Database3 Success
Server1 Database4 Success
Server1 Database5 Success

[PS] C:\Windows\system32>

To test one specific database use the -Database parameter.

Test-MAPIConnectivity -Database "NewDatabase"

And there you have it. To rename the Database in the Exchange Management Console, simply go to Organization Configuration: Database Management: Right Click the Database you want to rename: Properties: Change the name of the database on the General tab and press OK. **This will not rename the .edb file name. **

  • 1 Contributor
  • 0 Replies
  • 319 Views

Dani AI

Generated

Good, clear walkthrough from . The PowerShell approach shown is the right toolset; below are practical, experience‑based checks and troubleshooting steps to reduce surprises when renaming or moving Exchange mailbox databases (especially on Exchange 2010 / V14).

  • Pre‑move checklist: have a verified full database backup and a tested restore plan; confirm the target volume has DB size + log size + headroom (plan for growth); place database and log files on separate physical LUNs/volumes where possible; verify the target filesystem is NTFS and aligned/formatted per your Exchange/SAN guidance; and keep the original files intact until after validation so you can roll back quickly.

  • Permissions and agents: mirror NTFS ACLs from an existing healthy database folder (use it as the reference). Update or add antivirus and backup exclusions for the new paths before mounting. Pause any backup or snapshot jobs that might interfere with the file move.

  • DAG / high‑availability notes: if the database is part of a DAG, treat each copy individually and plan for reseeding or letting replication catch up. Moving active copies without accounting for replication can force reseeds and extended downtime.

  • Post‑move validation and troubleshooting: after the move verify the store is mounted and monitor the Application event log (ESE / MSExchangeIS entries). Test client access and mail flow (OWA, Outlook, ActiveSync). Update backup and monitoring jobs to reference the new locations. If the database fails to mount, check that the files exist at the new path, confirm ACLs match your reference folder, inspect event log errors for hints, and only then use database repair/inspection tools as a last resort.

Carry out the procedure during a maintenance window, test the entire sequence in a lab or on a passive copy first, and document the final paths so backups and monitoring remain accurate. This complements 's steps and avoids the most common pitfalls.

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.