Like and server or basically anything in the world an Exchange Server is not perfect and it can fail due to hardware, corrupted updates, an issue on the virtual environment hosting it or a virtual machine crash. One would rely on a snapshot of the server if it’s a virtual machine but Exchange Server is an application that maintains state data and you will have grave consequences if you try to recovery an Exchange Server virtual machine from a snapshot. In such cases, recovery is not supported .
Let’s take in consideration that we have two servers SRV01 and SRV02 both being Windows Server 2019 along with an Exchange 2019 installation with Database Availability Group (DAG). We have two Exchange databases replicated between SRV01 and STV02. What is SRV01 went down due to corruption or hardware failure and we need to recover it?
Before starting the installation of the new SRV01 Exchange Server, you would need to make sure to check out the installation path of the failed server which can be retrieved from the Configuration Partition using the ADSIEDIT.MSC. After finding the server, you would need to right click on SRV01 and select properties. On the new window opened, look for the attribute msExchIsntallPath under the Attribute Editor tab and it will show the installation path of the previous SRV01.
From SRV02 we open the Exchange Control Panel and remove the SRV01 from being a member of the DAG while removing any passive database copies with are relative to SRV01.
If you wouldn’t know you can do so by opening a PowerShell window using the Exchange Management shell and running the command:
Get-MailboxDatabaseCopyStatus – Server SRV01.
This will list all the databases which were replicating to the server. To remove the passive copies you would need to run the same command and add
The next step is to clean the server from the cluster by using following command to forcedly evict the server from the cluster.
Get- ClusterNode SRV01 | Remove-ClusterNode
The last step in the Exchange is to remove the server from the DAG which can be done by executing
Remove-DatabaseAvailabilityGroupServer SRV01 –Identity DAG01 – ConfigurationOnly
After this step and the Active Directory has replicated successfully we need to open the Active Directory Users and Computers, find the computer account of SRV01, right click on it and select Reset Account. This will reset the computer account and will not cause any issues since we will keep the same name.
We need to start off by installing a new machine with Windows 2019 Server maintaining the same computer name and IP Address; making sure that all relative updates and fixes are installed. Once this is done you need to grab and install all the Exchange Server’s prerequisites. After making sure that the operating system is fully patched and the prerequisites are installed, we grab the Exchange installation media and the setup with Recovery option as setup /m:Recoverserver and stating the installation path if not the default one with the parameter /TargetDir. Make sure that the media is at the same version level of the previous SRV01 installation and not above it.
Once the installation is complete, you would need to make sure that the Exchange Server services are all started successfully along with the correct certificates installed for Web, IMAP, POP and others. The virtual directories are configured as they should be with accordance of your setup and not the internal host name. Since this is a new installation you will need to make sure with the people who take care of the antivirus to exclude the Exchange Databases from active scanning.
Once this is done, you will need to add the server back as a DAG member by running the command
Add-DatabaseAvailabilityGroupServer –Identity DAG01 – MailboxServer SRV01
If all goes well and the server is a healthy member in the DAG, we can re-seed the databases from SRV02 to SRV01 by using
Add-MailboxDatabaseCopy EXDB01 –MailboxServer SRV01
The option is you have a single server is to run and make a new Exchange installation keeping the same server name and IP address. Unfortunately it’s not that easy and if you do this it will fail as if the old server was stopped abruptly, it will still exist in the Active Directory Schema’s Configuration Partition and you would need to make a full clean-up of the server’s presence. This will not work as you will not be able to attach the database to the newly installed server. An alternative to this is to try to recover the existing server or recover the server from backup. The issue here is that the emails that were stored between the backup and when the server crashed are lost.
With the use of third party Exchange Server Recovery applications such as Stellar Repair for Exchange, you can easily repair corrupted EDB files, extract data and migrate the data directly to a new database or if you have a single server installation you can migrate directly to another Exchange Server. This way you will not lose any emails which were stored between the time of the last backup and when the server corrupted. The application is also capable migrating directly to Office 365.