Foreword
As in the first part of this article series is about the manual removal of an Exchange Server. This procedure may be necessary in "unclean" environments. This procedure should not be used after a migration. The clean uninstallation is the best way here. The following cases can be considered for manual removal:
- There was already an Exchange installation "earlier" that is incomplete or faulty
- The Exchange server has burned down and cannot be restored via disaster recovery (no backup available, AD computer account deleted)
- A new Exchange Server is to be installed in a mishandled Active Directory in which one or both of the above points apply
- The migration is being prepared, but the old corpses are preventing a successful installation
The procedure described below must be carried out with caution and is FINAL. So please read carefully and make sure you create a backup of the domain controller.
If the Exchange Server computer account still exists, a disaster recovery should be attempted first. Manual removal is a last resort.
Surroundings
In the first article there was only one Exchange server and the environment was to be reset to a green field. The following case is likely to be somewhat more common.
There is a productive Exchange Server (FWCOMEX1) and an Exchange Server that exists as a corpse in the environment (FWCOMEX2):
For this environment, I had installed the Exchange Server FWCOMEX2, created a database and two mailboxes and deleted the server immediately. I've seen something like this before, usually as part of a failed migration.
In this environment, FWCOMEX1 should therefore be retained and only FWEXCOM2 removed.
Procedure
It doesn't really matter in which order you proceed, I'll start with the DNS. All of the steps mentioned here take place on the domain controller FWCOMDC1 or on the remaining Exchange server FWCOMEX1.
Remove DNS entries
Depending on the environment, you will find a different DNS configuration here. All entries pointing to the defective Exchange server can now be removed from the DNS:
Making a mistake here is still relatively uncritical. If you "accidentally" delete the wrong DNS entry, you can simply create it again. However, this must not happen again in the following steps.
In this case, I have deleted all entries that refer to the FWCOMEX2 server:
If several DNS zones are used, these must also be checked.
Delete configuration from Active Directory
When deleting the Exchange Server from the Active Directory, it is better not to make a mistake.
The Exchange Server object of the defective Exchange Server is first deleted using ADSIEdit:
Only the productive Exchange server(s) should then be displayed:
The data beacons that still refer to the defective Exchange Server can also be deleted:
Again, caution is advised here, deleting the productive databases has unpleasant consequences. This means that only the productive databases remain:
The defective server has now been removed from the Active Directory.
Assign new mailbox to user
If there were still mailboxes in the mailbox database of the defective Exchange server, the mailboxes are now listed as inconsistent. Here is an example of the mailboxes of Hans Dampf and Lucky Luke:
Here you can see that the two mailboxes are no longer assigned to a database:
The following command can be used to assign an existing database to all inconsistent mailboxes:
get-mailbox | where {!$_.database} | set-mailbox -Database FWDB1
Of course, there is no content in the newly assigned database, these are empty mailboxes, but they are in a consistent state again. Users can log in to their empty mailbox.
Delete computer account
Now you can also delete the computer account of the defective Exchange server. Again, it is better to look twice to avoid deleting the wrong account:
Installing a new Exchange Server
Before a new Exchange Server with a new name is installed, the Active Directory should be prepared once via the command line so that the necessary entries are created again.
There is a separate article on this.