Für den Exchange Server gibt es seit Mitte Februar einen kritischen Sicherheitspatch. Das betrifft den Exchange Server 2013 und kommt als KB4536988 um die Ecke. Was erstmal soweit richtig klingt, dass kritische Sicherheitslücken auch mal außer der Reihe geschlossen werden, kann sich aber auch gern mal als Auslöser für viel Arbeit entpuppen. So geschieht es derzeit, so weit ich das überblicken kann. In meiner täglichen Arbeit habe ich damit zu kämpfen. Das ist zwar gut, weil es meinen Job sichert. Aber auch wieder schlecht, wenn es so aussieht wie derzeit.
Hilfe, mein Exchange Server ist kaputt!
Ich hatte bereits dieser Tage darüber erzählt. Mit dem Sicherheitspatch für Exchange Server 2013 ist Microsoft nicht so eine großartige Nummer gelungen. Die Meldungen, dass mit diesem Patch irgendwie etwas nicht stimmt, häufen sich leider. Wobei: Es gibt Leute, die bei der Behauptung bleiben würden, dass es keine Probleme mit dem Update geben würde. Und daran sehen wir doch schon, wie undurchsichtig die ganze Angelegenheit doch eigentlich ist.
Ich habe Meldungen gelesen, in denen sich die Administratoren darüber beschweren, dass Microsoft mit dem Sicherheitspatch die Exchange Server kaputt updaten würde. Das ist natürlich Quatsch. Microsoft macht mit einem Update nicht mutwillig etwas kaputt. Aber es ist schon so, dass speziell mit dem oben genannten KB teils enorme Probleme auftreten. Und hier kommen wir nun einmal nicht umhin, Microsoft zu fragen, was da eigentlich genau schief gegangen ist.
Bekannte Probleme bisher
Microsoft musste bereits einräumen, dass mit dem KB4536988 unter Umständen nicht alle Dateien korrekt aktualisiert werden. Das soll an der Benutzerkontensteuerung liegen. Sie meinen, dass das nicht passieren würde, wenn man das Update über Microsoft Update installieren würde. Man könne Probleme umgehen, wenn man mit einer administrativen Eingabeaufforderung arbeiten würde. Das halte ich allerdings für einigermaßen schwierig.
Jedenfalls habe ich dieser Tage bereits davon erzählt, dass evtl. OWA und die ECP nicht funktionieren würden, wenn das Update installiert wurde. Die Lösung dazu ist weiter oben verlinkt. Microsoft meint noch, dass vielleicht ein paar oder alle Dienste von Exchange nicht wieder starten würden und man dies manuell nachholen müsste. Aber da geht noch mehr an Merkwürdigkeiten.
Es kann auch vorkommen, dass Emails von Exchange zwar angenommen, aber nicht zugestellt werden. Die bleiben einfach in der Shadow Queue hängen. Und wir haben es selbst erlebt, dass „wie von Zauberhand“ https-Verbindungen von Exchange im IIS Manager einfach verschwunden waren. Ihr glaubt, das war alles? Nein, da geht noch mehr.
Ich habe erfahren, dass es innerhalb einer Database Availability Group dazu kommen kann, dass die Datenbanken sporadisch und „einfach so“ seit dem Update schwenken. Es kommt darüber hinaus zu Synchronisationsproblemen und all dem. Dafür, dass der Exchange Server sicherer gemacht werden sollte, passieren ganz schön viele Fehler.
Lösungsvorschläge?
Wenn nach dem Sicherheitspatch „nur“ OWA und ECP nicht funktionieren und seltsame Fehlermeldungen werfen, habe ich ja oben eine Lösung verlinkt. Aber wie sieht es denn sonst aus? Muss ich jetzt tagelang Protokolle wälzen, um durch Zufall auf die richtige Fehlermeldung zu stoßen? Ich kann mir vorstellen, dass das Alles von der Seite her beeinflusst wurde und vielleicht Microsoft gar nicht so viel dafür kann.
Wie sieht es denn mit dateibasierten Virenscannern aus? Was ist mit Betriebssystem-Updates? Und – beim Exchange Server sehr wichtig – was ist mit .NET und ASP? Dafür gibt es zwar eine Compatibility Matrix. Aber schaut dort rein? Wenn jemand z.B. eine ältere Update-Version hat, kann nicht direkt der Sicherheitspatch installiert werden, sondern es muss vorher das Cumulative Update 23 installiert sein. Das unterstützt .NET 4.7.2 und 4.8. Was ist denn, wenn .NET älter sein sollte?
Des Weiteren ist es sicherlich sinnvoll, so einen Befehl wie den folgenden einfach mal abzusetzen. Denn so erhält man einen Überblick darüber, ob irgendwas kaputt ist oder fehlt. Und eigentlich sollten diese Dinge jedem bekannt sein, der Exchange Server administriert.
Get-ExchangeServer | Get-ServerComponentState | where {$_.State -ne "Active"} >C:\scsbad.txtDieser Befehl sammelt zuerst alle registrierten Exchange Server ein und schaut nach deren Komponenten. Ist eine Komponente nicht aktiv, wird diese in die Textdatei geschrieben. Na klar, man kann auch „Test-ServiceHealth“ verwenden, sollte man auch. Aber so könnte man sich behelfen. Und ich hoffe, dass Microsoft bald eine Abhilfe für diese Situation hat.