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.
Hallo Frank,
erst mal ein Herzliches Dankeschön von mir für deine super Tutorials! Haben mir schon einige Male aus schwierigen Situationen geholfen.
Am ende dieses Tutorials wollte ich auch einen frischen Exchange 2016 installieren, leider ist mir meine Installation dann bei Schritt 11 von 15 in folgenden Fehler gelaufen:
„Microsoft.Exchange.Data.DataValidationException: ‚Database‘ ist für ‚UserMailbox‘ verbindlich.“
Durch ein wenig Recherche hat sich dann herausgestellt dass noch 2 weitere Mailboxen vom defekten 2016 übrig waren die man im 2010 durch die Pfade nicht auf anhieb finden konnte:
Die SystemMailbox und die Migration-Mailbox.
Diese beiden können mit dem CMDlet
Get-Mailbox -Arbitration | ft Name, ServerName, Database -Auto
ausfindig gemacht werden.
Anhand der ausgegebenen Namen die auf keine Datenbank verweisen sucht man dann einfach im Active Directory Benutzer und Computer die beiden User und löscht diese. So läuft die Setup für den neuen Exchange dann auch endlich durch! Danach nur noch mit
E:\setup.exe /preparead /IAcceptExchangeServerLicenseTerms
Den Migration-User neu erstellen lassen und in der Exchange Management Shell mit
Enable-Mailbox -Arbitration -Identity „Migration.8f3e7716-2011-43e4-96b1-aba62d229136“
Und
Set-Mailbox „Migration.8f3e7716-2011-43e4-96b1-aba62d229136“ -Arbitration –Management:$true
Konfigurieren und die Migration kann weiter gehen.
Wäre nett von dir wenn du dein Tutorial noch um die Punkte erweitern könntest damit die nächsten Armen Teufel nicht in den selben Fehler rennen wie ich
Danke, hat super geklappt. Man sollte auf jeden Fall die Datenbank des defekten Servers entfernen, da sonst wie bei mir keine Datenbanken mehr angezeigt werden.
Hallo Frank,
vielleicht hast Du eine Idee bzgl. eines Problems, was ich bei der Installation meines Exchange 2016 habe. Ich hatte bei der ersten Installation leider einen Fehler gemacht und die virtuelle Maschine auf einen vorher angelegten Snapshot zurückgesetzt (war leider nicht so eine gute Idee, wie sich jetzt durch die enstandenen Probleme herausgestellt hat, aber ich habe die Problematik leider nicht komplett zu Ende gedacht), den ich vor der Installation gemacht habe.
Habe dann, wie von der beschrieben, das AD bereinigt, den Server einmal aus der Domäne genommen, aus dem AD gelöscht und wieder neu hinzugefügt.
Leider bricht meine erneute Installtion dann bei der Postfachinstallation (Schritt 10 von 14 Postfachrolle: Postfachdienst) mit einer ellenlangen Fehlermeldung (u.a. steht im log: Database is mandatory on UserMailbox) ab und ich bin recht ratlos.
Ein Tipp: Nach dem letzten Schritt sollte man mit LDIFDE einmal die Domain Partition und einmal die Konfiguration Partition in eine TXT-Datei exportieren und dort dann nach dem Servernamen suchen. Oft „versteckt“ er sich noch an verschiedenen Stellen, die man noch fixen muss, z.B. Routinggroupmaster, OAB Generator, PF-Masterserver. Einfach um sicher zu sein, dass wirklich alle einfach zu findenden Verweise auf den Server verschwunden sind.