Exchange 2010: Restore database (the sledgehammer method!)

Foreword: The method described in the following article should only be used in exceptional cases. I had to carry out the steps listed below when the Exchange database entry in the Active Directory was damaged and could not be restored. However, a lot of cleanup work is necessary after this action. But it can't hurt to have these steps in mind if the Active Directory suddenly crashes. That is why I am describing them here. Please read the whole article first, BEFORE it is implemented.

The situation: First a few words about the error situation, the Exchange databases were initially still online, but the database containers in the Active Directory configuration partition apparently had errors. The Exchange server was then booted as scheduled after the update installation, which meant that the databases could no longer be started. The Exchange servers were members of a DAG, but in this case the switch to the passive copy of the database did not work either. According to ESEUTIl, the databases were in the clean shutdown state, but the error message when mounting the database corresponded to the message that is displayed when the databases are in the dirty shutdown state. Unfortunately, I failed to take screenshots of the error messages, so I will only describe the procedure.

Background: A lot of configuration data for the Exchange databases is stored within the Active Directory, the configuration of the databases can be displayed and also edited with ADSI Editor, here is a screenshot of a mailbox database from an Active Directory perspective:

Normally, you don't need to do this manually via the ADSI editor. In my case, however, it was necessary. As already mentioned, it was not possible to clarify exactly what the problem was (permissions? replication?). All attempts to bring the databases back online failed, so the only way to get the databases back online as quickly as possible was to use the sledgehammer method.

The procedure: First I deleted the database container via ADSI Editor. Exchange does not allow the deletion of databases as long as there are still mailboxes in the database, so this step had to be done via ADSI Editor. So I deleted the entry "CN=MBDB01".

The Exchange Server no longer recognizes this database and its configuration.

Now ESEUTIL is used to check whether the database is in the clean shutdown state. described here. After "ESEUTIL /MH" indicates that the database is in the clean shutdown state, all files except for the .EDB file are deleted.

A new empty mailbox database is now created:

New-MailboxDatabase -Name NEUEDB -Server SMAIL01 -EdbFilePath d:\NeueDB\NeueDB.edb -LogFolderPath d:\NeueDB

The database is now mounted once so that the database files are created, after which provisioning is immediately canceled again:

Mount-Database -Identity NEUEDB
Dismount-Database -Identity NEUEDB

Next, all files in the "D:\NeueDB" directory are deleted

Then the original mailbox database is copied to d:\NeueDB and renamed to NeueDB.EDB. In my case, I only copied the EDB file from D:\TMP (see screenshot above) to d:\NEUEDB and renamed it to NEUEDB.EDB.

Now specify that the "NEUEDB" database may be overwritten when restoring:

Set-MailboxDatabase -Identity NEUEDB -AllowFileRestore $true

The "NEUEDB" database can now be mounted

Mount-Database -Identity NEUEDB

So far so good, but the mailboxes still refer to the old database:

Before the users can log in again, the correct database (now NEUEDB) must be configured for the mailboxes; this is done with the following commands:

get-mailboxdatabase | clean-mailboxdatabase
get-mailboxstatistics –database NEUEDB | set-mailbox –database NEUEDB
get-mailboxdatabase | clean-mailboxdatabase

All mailboxes that were originally in the MBDB01 database have now been moved to the new NEUEDB database. Users can log in again.

Note: As already mentioned, this method still involves clean-up work. System mailboxes may have to be recreated. Mailbox restrictions may also need to be adjusted. This article only shows another way to make a database available again. In my case, a defective Active Directory was to blame, but in my experience this is relatively rare. Before using this method, take a look at the alternatives first:

https://www.frankysweb.de/?cat=12