Der Exchange Server – ein mächtiges Produkt. Soll er gewartet werden, bedient man sich der mitgelieferten Scripte. Das ist der Krebsschaden. Ich habe es oft genug mitbekommen, dass die Scripte, die mit der Installation des Servers mit ausgepackt werden, einfach mal nicht so funktionieren, wie man es sich vielleicht so vorstellt. So auch mit „StartDagServerMaintenance.ps1“ aus dem Microsoft Exchange Server 2010. Was soll so etwas? So richtig eine Erklärung gibt es nicht dafür, oder?
Ich hatte mal einen Artikel geschrieben, der sich mit dem Exchange Server 2010 Wartungsmodus einer Database Availability Group beschäftigt, also mit einem Cluster. Leider funktioniert das so nicht mehr. Ich weiß nicht genau, seit wann das so ist. Aber eine hochverfügbare Exchange Postfach-Server-Lösung kann man nicht mehr so einfach warten wie bisher. Und wie hatte Microsoft da immer getönt, aber wahrscheinlich redet sich der Konzern aus Redmond darauf raus, dass die Lösung ja schließlich 5 Jahre alt ist. Aber die Artikel sind ja nicht aktualisiert worden. Also gelten die noch.
Wer in den letzten Monaten mal einen Mitgliedsserver einer solchen Database Availability Group warten wollte, der konnte sein blaues Wunder erleben. Irgendwelche wirren Fehler und Warnungen wurden da in die Exchange Management Shell geblasen. Und manch einer konnte sicherlich einen riesigen Schrecken bekommen. Und dann kommt Microsoft letzten Sommer daher und erzählt uns einen Weg als Umgehungsmöglichkeit. Nein, da stimmt doch etwas nicht. Manche Dinge kann man sich aber auch schenken. Es kann nämlich auch anders gehen.
Ich habe festgestellt, dass man eigentlich folgendes machen kann, um nicht mehr auf die Scripte angewiesen zu sein. Mir ist klar, dass das eh viele Exchange-Administratoren tun. Aber ich will es dennoch mal aufschreiben:
- Von Server1 werden alle Datenbanken auf Server2 geschoben, also die Datenbanken dort aktiviert
- Im Failover Cluster Manager sollte man einfach mal überprüfen, ob Server1 keine Ressourcen mehr hält
- Die Datenbanken sollten nicht automatisch aktiviert werden. Das steht in deren Eigenschaften
- Die Datenbank-Kopien, die sich nun auf Server1 befinden, müssen angehalten werden
- Dann kann Server1 eigentlich schon aktualisiert werden
- Danach schwenkt man eigentlich alles auf Server1, aktiviert also die Datenbanken dort und prüft die Cluster-Ressourcen
- Und schon ist Server2 dran
- Ist man damit fertig, können die Datenbanken wieder so verteilt werden, wie sie waren, also 5 auf Server1 und 5 auf Server2, zum Beispiel
Es gibt auch sehr sportliche Administratoren, die einfach mal der Meinung sind, dass sie ja einfach so aktualisieren können. Wofür ist es schließlich ein Cluster geworden? Aber eine Database Availability Group bei Exchange Server 2010 und höher funktioniert eben doch etwas anders. Man sollte den Server, mit dem man etwas machen will, doch lieber frei räumen. Da bricht niemandem ein Zacken aus der Krone.
Natürlich haben da auch viele andere Ansichten, wie man am besten eine Exchange Server 2010 Database Availability Group aktualisiert. Aber ich habe nur noch mit wenigen zu tun, die das erfolgreich mit den Scripten „StartDagServerMaintenance.ps1“ und „StopDagServerMaintenance.ps1“ und abschließend noch „RedistributeActiveDatabases.ps1“ durchziehen. Oder bekommen Sie das erfolgreich durchgezogen? Man weiß ja nie.