Exchange Wiederherstellung nach fehlerhafter Installation eines Sicherheitspatches

Vor ca. drei Wochen haben wir unsere Exchange Infrastruktur von 2010 auf 2016 migriert. Soweit hat alles funktioniert, abgesehen von mehreren Einträgen im Event Log, die bisher nicht zu beheben waren. Wie üblich wurden gestern die Windows Updates installiert. Enthalten war auch der «Security Update For Exchange Server 2016 CU8 (KB4073392)». Aus einem «ich installiere noch schnell die Updates» wurde ein «wie bringe ich den Exchange wieder zum Laufen».

Situation

Die Installation der Updates schlug zuerst einmal fehl. Windows schlägt ein «retry» vor. Auch dieses schlägt fehlt. Also ein Neustart des Servers. Dieser geht schnell. Nach dem Neustart ist Exchange immer noch nicht verfügbar. Also schaue ich, ob allenfalls ein Service nicht gestartet wurde. Es sind alle Exchange Services «disabled»! Ich versuche nochmals die Updates zu installieren. Alle «normalen» Windows Updates funktionieren, der Exchange Update schlägt wieder fehl. Nach einem Neustart des Servers aktiviere ich alle Exchange Services (Status von «disabled» auf «automatic»). Dies ist nicht ganz einfach, da ich nicht genau weiss, wie der Zustand vor der Installation des Updates aussah. Zudem wurden auch einige Windows Dienste deaktiviert, die nicht direkt Exchange zugeordnet sind (z.B. «World Wide Web Publishing Service» und «IIS Admin Service». Nun sind alle nötigen Services aktiviert und ich versuche sie zu starten. Keiner lässt sich starten, entweder weil ein abhängiger Service nicht läuft oder weil eine Exception auftritt. Exchange ist somit tot!

Lösung

Die Wiederherstellung war ein Suchen und Probieren, doch folgende Schritte führten für mich zum Ziel.

  1. Den fehlerhaften Update (in meinem Fall KB4073392) kann man auch als Installer herunterladen. Also suchen, herunterladen, Admin CMD öffnen und installieren -> schlägt fehl.
  2. Installation mit Logging versuchen: «Exchange2016-KB4073392-x64-en.msp /lxv c:\Rollup.log». Schlägt auch fehl. Im Log hat es jedoch weitere Informationen.
  3. Unter «c:\ExchangeSetupLogs\ServiceControl.log» finde ich die Fehlermeldung: «[Error] System.Management.Automation.CommandNotFoundException: The term 'Stop-SetupService' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.”. Dieser Fehler tritt bei jedem Installationsversuch auf. Relevant ist hier der Name des fehlerhaften Befehls «Stop-SetupService».
  4. Gemäss Recherche von hier erstelle ich unter «C:\Windows\System32\WindowsPowerShell\v1.0» eine Datei «profile.ps1» mit dem Inhalt «New-Alias Stop-SetupService Stop-Service». Dies erstellt in jeder PS Session ein Alias mit dem Namen «Stop-SetupService» .
  5. Nun den Update nochmals starten (Achtung: der Update MUSS im Admin Modus gestartet werden, z.B. Admin CMD öffnen und von dort starten). Er läuft durch. Hier sollte man etwas Geduld mitbringen. Auch wenn der Update scheinbar schon lange fertig ist, sollte man warten. Man kann im Log «c:\ExchangeSetupLog\UpdateCas.log» nachschauen, ob das Skript «UpdateCas.ps1» durchgelaufen ist. Dies wäre ein Hinweis, dass der Update eigentlich fertig ist.
  6. Sollte der Update, wenn der Balken ganz voll ist, auch nach zwei Stunden immer noch nicht fertig sein, kann man im Hintergrund damit beginnen, alle relevanten Services zu starten (aktiviert sind sie ja). Es scheint, als versuche das Skript den Zustand vor dem Update (alle Services laufen nicht) wiederherzustellen und wartet jedoch gleichzeitig, bis die Exchange Dienste wieder laufen. Sobald alle Dienste laufen, wird der Update erfolgreich beendet.
  7. Exchange funktioniert wieder! In meinem Fall jedoch zeigte das OWA und ECP einen HTTP Fehler 500. Ich hatte vergessen , den Service «IIS Admin Service» zu aktivieren und zu starten.
  8. Tritt der Fehler im OWA/ECP immer noch auf, können folgende Schritte zum Erfolg führen.
    • Gemäss MS Artikel hier, können die beiden Dateien «SharedWebConfig.config» unter «%ExchangeInstallDir%FrontEnd\HttpProxy» und «%ExchangeInstallDir%ClientAccess» neu erstellt werden. Ich empfehle vor der Neuerstellung eine Kopie zu erstellen.
    • Weiter kann gemäss hier die Datei «UpdateCas.ps1» unter «C:\Program Files\Microsoft\Exchange Server\V15\Bin» in der Exchange Management Console (als Admin gestartet) aufgerufen werden (dauerte eine Weile zum Durchlaufen).
    • WICHTIG: Nach obigen Schritten unbedingt einen «IISReset» durchführen.
  9. Im Anschluss an diese Schritte und dem Starten des Services «IIS Admin Service» funktionierte die Exchange Infrastruktur wieder.

Warum der Exchange Update den Befehl «Stop-SetupService» verwenden will, konnte ich nicht verifizieren. Scheinbar gibt es diesen PS Befehl nicht. Zudem tritt der Fehler auch nicht bei allen Updates auf. Gemäss meiner Recherche wurde er jedoch bei Exchange 2013 und 2016 bei verschiedenen Updates, mit denselben Folgen, beobachtet.