Henning Uhle

Ich habe beruflich viel mit dem Microsoft Exchange Server zu tun. Es bleibt dabei nicht aus, dass ich diesbezüglich auch einmal seltsames beobachten kann. Und das möchte ich einfach mal aufschreiben. Es kann ja sein, dass es Exchange-Administratoren gibt, die das Thema auch mal interessiert. Denn eine Hochverfügbarkeitslösung wie eine DAG nutzt man nun eben mal nicht ohne Grund.

Ist der Exchange Server für Microsoft nicht mehr relevant?

Ich bin das erste Mal mit dem Exchange Server in der Version 6.0 in Kontakt gekommen. Das war der gute alte Exchange 2000 Server. Aus der Zeit weiß ich, dass die Installation von einem Exchange Server nicht zwingend gleich erfolgreich sein muss. Vor allem, wenn das Produkt hochverfügbar arbeiten soll. Auf Windows 2000 Server und Windows Server 2003 war das schon mit Fingerbrechen verbunden.

Nach dem Exchange Server 2003 kam der 2007er, den ich nur am Rande erlebt habe. Nach dem Unfug, dass ein Exchange Server als Cluster-Ressource installiert werden musste, war ich eigentlich froh, dass mit Exchange Server 2010 dann die Welt sich weitergedreht hatte. Microsoft hatte die Database Availability Group für sich entdeckt. Dabei verfügen alle Server über alle Daten und tauschen Änderungen aus. Grob gesagt.

Aber es gab erst einmal eine Vielzahl an Rollen, das reduzierte sich dann von 2010 bis 2019 immer mehr. Aber man merkt Microsoft an, dass sie eigentlich mit dem Prunkstück Microsoft Exchange Server nicht mehr allzu viel am Hut haben. Die Updates funktionieren teilweise nicht, Funktionen wirken wie einfach nur noch „hingerotzt“. Der Riese aus Redmond möchte unbedingt, dass die Kunden in die Cloud gehen.

Updates machen ECP und OWA kaputt

Wir haben es oft genug gehört, dass man Exchange niemals über solche Dinge wie den Windows Server Update Service aktualisieren sollte. Was macht man also? Man lädt sich Update-Pakete in Form von MSP-Dateien herunter. Da das Ganze ausführbare Dateien sind, sollte dann eigentlich ein Doppelklick ausreichen, um das Update erfolgreich durchzuführen. Haben wir gedacht.

Microsoft wäre nicht Microsoft, wenn nicht alles anders sein würde. Denn irgendwann haben sie angefangen, ihre Hilfeartikel umzuschreiben. Neuerdings (glaube ich) steht in diesen Artikeln, man könne zwar die MSP-Dateien zum Update nutzen. Aber man soll doch bitte einen „Elevated Prompt“ benutzen, also eine Eingabeaufforderung als Administrator. Und dort soll man den vollständigen Pfad zur MSP-Datei eintragen.

War das immer schon so umständlich? Ich bin mir da gerade nicht sicher. Hintergrund ist die Benutzerkontensteuerung von Windows. Die haut dazwischen. So schreibt es Microsoft zum Beispiel hier. Ja, Administratoren sollten damit umgehen können. Aber mir war nicht bewusst, dass dies schon immer so war. Mal abgesehen davon, dass der Maintenance-Modus einer Exchange DAG wie hier nicht mehr richtig funktionieren muss. Nun auch noch so etwas?

Ist eine ganze DAG kaputt?

Und dann kommt es dazu, dass nach einem Update der Knoten einer solchen DAG eben jene Knoten immer wieder abstürzen und ihren Zeugenserver nicht mehr finden. Nun denkt man sich, dass man dann einfach einen zweiten Zeugen angibt. Wozu gibt es schließlich die Möglichkeit? Nur wird dann das Witness-Verzeichnis nicht als solches erkannt. Löschen ließ sich das Ganze auch nicht. Klasse, war nun die DAG kaputt? Vielleicht ja auch nicht. Man startet also mal den Clusterdienst neu:

Stop-ClusterNode -Name Node01
Start-ClusterNode -Name Node01

Das hilft aber wahrscheinlich nur bedingt. Zwar könnte die Replikation wieder anlaufen. Aber nun haben wir das Problem, dass dieser ominöse zweite Zeuge noch vorhanden ist. Den bekommen wir nicht so ohne weiteres weg. Und so richtig sicher sind wir uns mit der Replikation auch bloß nicht. Besser, wir machen es richtig. Am Ende haben wir uns also daran abgearbeitet:

Remove-MailboxDatabaseCopy “DBName\Node01” –Confirm:$False
Set-DatabaseAvailabilityGroup -Identity DAG1 -DatacenterActivationMode Off
Set-DatabaseAvailabilityGroup -AlternateWitnessDirectory $null
Set-DatabaseAvailabilityGroup -AlternateWitnessServer $null
Set-DatabaseAvailabilityGroup -Identity DAG1 -DatacenterActivationMode DagOnly
Add-MailboxDatabaseCopy –Identity DBName -MailboxServer Node01 -ActivationPreference 2

Die Datenbank-Kopien haben wir entfernt und wieder hinzugefügt, weil die sich vor dieser Aktion tagelang initialisiert haben. Wir gingen davon aus, dass die Kopien eh kaputt sind. Und da es Kopien sind, können sie auch ganz unspektakulär neu erstellt werden. Je nach Datenmenge kann das dann aber etliche Stunden dauern, da ja die Daten von einem auf den anderen Server kopiert werden.

Was will ich damit sagen?

Jeder Artikel muss ja so etwas wie eine Erkenntnis zu Tage fördern. So soll das auch bei dem vorliegenden sein. Was will ich denn mit dem Artikel sagen? Am ehesten vielleicht so etwas wie: Behalten Sie erstmal Ruhe. Es bringt nichts, in Aktionismus auszubrechen. Natürlich könnte man hergehen und eine DAG neu erzeugen, wenn die Mitgliedsserver irgendeinen Unfug fabrizieren.

Aber wenn so etwas passiert, dass nach Updates irgendwas nicht mehr funktioniert, ist es immer ratsam, die Suchmaschinen um Rat zu fragen. Ein Exchange Server funktioniert eben so, wie man ihn einstellt. Und wenn Updates für das Produkt installiert werden, ohne dass jemand die Berechtigungen dafür hat, ist es nachvollziehbar, dass irgendwas nicht mehr funktioniert.

Ich habe die Erfahrung gemacht, dass man sich nach und nach herantasten muss und nicht von Anfang an mit Kanonen auf Spatzen schießen muss. Vielleicht muss es nicht immer gleich die Neuerstellung sein? Vielleicht genügt es auch mal, das Ganze neu zu initialisieren. Niemand will ja mehr machen als unbedingt notwendig. Es gibt nun einmal keine „Fleiß-Bienchen“.