[English]Ein Blog-Leser hat mich zum Wochenabschluss auf ein Problem hingewiesen, was er bei der Administration eines Exchange Server 2013 nach der Installation der aktuellen Februar 2020-Updates hatte. Mails wurden zwar angenommen, aber nicht mehr in den Postfächer der Benutzer einsortiert. Ich stelle es mal hier ein, vielleicht hilft es anderen Administratoren.
Anzeige
Blog-Leser Andre H. teilte mir Freitag (14.2.2020) seine Update-Erfahrungen beim Exchange Server 2013 (CU 23), der unter Windows Server 2012 R2 läuft und plötzlich muckte, per Mail mit.
Wir hatten gestern Abend auf einen unserer Exchange 2013 CU23 Servern auf Windows Server 2012R2 die aktuellen Windows Updates installiert – und danach Probleme festgestellt, welche wir nicht vorenthalten wollen.
Andre ließ die folgenden Updates in seiner Umgebung auf dem Server installieren [das muss letzten Donnerstag, den 13.2.2020, gewesen sein]:
KB4502496, KB4536988, KB890830, KB4537767, KB4538124, KB4484156, KB4484265, KB4537821, KB4537803, KB4537759
Soweit nichts ungewöhnliches und nach der Installation der Updates, dem Neustart und der Wiederinbetriebnahme des ersten Servers (Server im DAG-Verbund) lief augenscheinlich alles prima, schreibt Andre. Aber dann fingen die Probleme an.
Heute früh nun stellten wir fest, dass verschiedenste Mails, extern wie intern, nicht in den Postfächern der Benutzer landeten – vom Server angenommen waren sie jedoch.
Nach einigen Checks im Eventlog konnten wir keine genauere Ursache feststellen, nahmen den Server als aktives Mitglied aus dem DAG-Verbund und aus dem vorgeschalteten LoadBalancer, um genauer zu untersuchen.
Wir wendeten uns nebenher an den Microsoft Support mit 2h Reaktionszeit; nach ca 20min. erfolgte ein Rückruf. Der MS-Kollege checkte kurz die Umgebung, erstellte eine neue Datenbank und 2 Testbenutzer, per OWA dann den Mailfluss – Ergebnis: kein Mailfluss.
Im MessageTrackingLog konnte man sehen, dass die Mails in der Shadowqueue fest hingen, und dies dann nicht weiter ging.
Ein Dienstecheck ergab auch keine Probleme.
Die Transportconfig sah auch gut aus.
Im IIS Manager angekommen, prüften wir die Bindungs-Einstellungen der beiden veröffentlichten Webseiten; in der Default-Website fehlte hier ein Eintrag: Trotz eines vorhandenen Eintrags mit dem Type https, Port 443 und ip Adresse "*" sowie dem passenden Zertifikat konnte wohl keine Verbindung von den anderen Servern zu diesem Server hergestellt werden.
Laut Microsoft fehlte hier ein weiterer Eintrag: Type https, Port 443, als IP Adresse explizit 127.0.0.1 mit dem passenden Zertifikat. Weshalb der vorhandene "*" Eintrag hier nicht greift, konnte der Microsoft-Supporter nicht erklären. Die Lösung:
Anzeige
Gesagt, gesezt, "iisreset" – Warten.
Auch hier schreibt Andre auf die Frage, warum dieser fehlende Eintrag nun plötzlich verschwunden war, habe der Microsoft-Supporter er nicht genau erklären können. Er habe es aber aber auf eins der installierten Windows Updates geschoben. Andre schreibt:
Dies macht auch durchaus Sinn, niemand von uns änderte in der IIS Config eine deartige Einstellung.
Die bisher "verlorenen" Mails trudelten dann nach 10-15min. ein, der Exchange Queue Viewer leerte sich, die Benutzer (und wir) waren glücklich.
Zum Problem an sich meint Andre, dass die folgenden Updates (bzw. eines davon) aus Sicht von Microsoft (und seiner Sicht) wohl am wahrscheinlichsten etwas (unabsichtlich?) verändert haben:
KB4536988 Security Update for Exchange Server 2013 CU23
KB4502496 Security Update for Windows Server 2012 R2 x64 2020-02
KB4538124 Security and Quality Rollup for .NET Framework 3.5… 2020-02
Andre gibt an, dass sie im Eventlog Events finden konnten, dass der IIS Dienste sowie AppPools während der Installation der Updates mehrfach beendet wurden. Genaueres lässt sich dazu jedoch nichts sagen und für den MS Support war der Call nach dem Neu-Hinzufügen des Eintrags und einem erfolgreichen Test abgeschlossen.
Andre merkt an, dass der Microsoft Support keine RootCause-Analyse macht – dazu gäbe es den MS Premier Support. Diesen bekomme man nur ans Telefon, O-Ton Andre, wenn man vorher einen mindesten 1 Jahr laufenden, recht teuren Premier Support Vertrag abschließt und dazu zusätzlich 300€ pro Stunde für den Support abdrückt. Und als Wochenendgebet fügt er hinzu:
Somit bleiben uns 2 weitere Server, auf denen wir die Updates installieren und schauen können, ob diese Probleme wieder auftreten.
Im weltweiten Netz haben wir bislang noch nicht dazu gefunden, liegt vielleicht an den recht neuen Updates.
und beschließt dieses mit den Worten: Wir wünschen nun allen eine weiterhin problemlos laufende Umgebung und Ihnen, lieber Hr. Born, weiterhin viel Kraft und Erfolg sowie ein schönes Wochenende. Dem ist nix hinzuzufügen – außer, dass ich vielleicht mal eine Mütze Schlaf brauche und diese jetzt nehme. An dieser Stelle ein Danke an Andre für die Hinweise. Gegebenenfalls hilft die Info dem ein oder anderen Administrator bei ähnlichen Themen. Und falls ihr in dieses Schlamassel rauscht, hinterlasst einen Kommentar.
Anzeige
Hab grad mal an einem Ex2016 geschaut… dort ist auch eine Bindung für 127.0.0.1 für die Ports 80 und 443 drin.
Exchange 2013, bei uns ist nur eine Bindung für 127.0.0.1 für Port 80 drin, nicht jedoch für 443 (dort nur *)
Ich bin so froh, kein Exchange Admin zu sein. Ich will ja gar nicht wissen, wie die Story weitergeht, wenn es eine globale Exchange Infrastruktur mit diversen Servern gibt.
Wir haben das schon vor Jahren ausgelagert.
Du meinst sowas wie Office 365? Da gab es z. B. das Problem, dass nach dem Update auf iOS11 auf Ex2016 und höher HTTP/2 abgeschaltet werden musste, betroffen war auch Office 365. Hatte die Tage erst mit iOS13/Ex2019 denselben Workaround gebraucht, da in einem internen Netz kein Mails mit Anhängen über ca. 100 kB gesendet werden konnten.
Update KB4502496 wurde gerade zurückgezogen – zur Info.
Hallo Herr Born,
habe mich gerade sehr über Ihren Artikel gefreut… vergangenen Donnerstag auf Freitag, habe ich unseren Exchange, mit exakt den selben Updates versorgt wie Ihr Informant. Alle Updates liefen im ersten Moment problemlos durch – nach einem Neustart dann aber das böse Erwachen.
Das Anmelden ging schon verdächtig schnell, dann stellte ich fest, dass die Verwaltbarkeit im Servermanager komplett deaktiviert wurde mit dem viel sagen Fehler: Online – Data retrieval failures occurred (Online – Fehler beim Datenabruf) unter Verwaltbarkeit.
Nahezu alle Dienste waren deaktiviert (nein nicht beendet) und ließen sich auch nicht starten.
Das CU23 Update für den EXC2013 habe ich vergangenen Montag eingespielt.
Das Update KB4536988 Security Update for Exchange Server 2013 CU23 ist bei uns nicht erfolgreich abgeschlossen worden.
Nach knapp 6 Stunden Troubleshooting habe ich ohne jeglichen Erfolg aufgeben müssen und ein Backup wiederhergestellt. Auch nach der Wiederherstellung, haben wir für mehrere Stunden keine Mail empfangen (senden ging direkt).
Auch wir haben für 300€ ein Support-Ticket unter https://support.microsoft.com/de-de/oas buchen müssen um einem längeren Ausfall vorbeugen zu können. Es hat übrigens drei Anrufe bei der Hotline gebraucht um dor ein Ticket erstellen zu können:
-https://support.microsoft.com/oas ist für die Amerikanischen Kunden (das merkt man dann im allerletzten Schritt, wo nur Amerikanische Kreditkarten eingetragen werden können.
-https://support.microsoft.de/oas gibt es nicht
-Die Lösung: https://support.microsoft.com/oas aufrufen und den weitergeleiteten Link (https://support.microsoft.com/en-us/supportforbusiness/productselection) manuell umbeschrifen auf https://support.microsoft.com/de-de/supportforbusiness/productselection
-Da es sich um ein Problem unserer Firma handelt, nehme ich logischerweise auch meinen Firmen Tenant (Nutzeraccount)… auch hier stellt sich dann relativ spät nach dem erstellen des gesamten Ticket herraus, dass es nicht funktioniert (man kann keinen Ticket-Support kaufen). Ein weiterer Anruf bei der MS-Hotline brahcte dann die Infotmation hervor, dass ich einen Privaten Account nutzen muss…………
Als ich dann endlich den Anruf von MS erhalten habe, funktioniere das System glücklicherweise wieder (paralel sind Mails gekommen), der MItarbeiter schaut e sich trotzdem nochmal alles kurz an und hat das System als fehlerfrei befunden. Da das Problem von einem MS-Update ausging und er wohl am selben Vormittag zwei identische Fälle hatte – wurden uns sämtliche Kosten erlassen.
Was mich die ganze Aktion an Schlaf, glaubwürdigkeit bei den Kollegen und der Geschäftsführung, Haare auf dem Kopf gekostet hat, steht auf einem ganz anderen Zettel.
Erspart euch den spaß und spielt das Update bitte nicht ein.
Hallo,
eine Frage an Martin M.
Auch bei älteren Exchange Security Updates, die als .msp Datei kommen, gibt und gab es Probleme beim Dienstneustart. Eine Fehlerquelle war, das .msp File direkt downzuloaden zu starten und nicht aus einer Administrativen CMD bzw. über den Update Dienst. Auf welche Art haben sie das Update eingespielt?
Grüße Boris B.
Hallo Boris,
das Sicherheitsupdate für CU23 habe ich wie immer ganz normal über die Windows-Updates integriert. Ich habe das Update nicht manuell heruntergeladen und ohne eine administrative CMD via befehl gestartet.
Laut https://support.microsoft.com/de-de/help/4487563/description-of-the-security-update-for-microsoft-exchange-server können die Update ohne weiteres über Windows-Updates installiert werden. Nur beim manuellen integrieren, ist die CMD notwenidig.
Es war auch nicht das Problem, dass ein paar Dienste nicht gestartet werden konnten, sondern quasi alle Dienste des Servers "deaktiviert" waren.
VIele Grüße – Martin
Hallo Martin,
danke für die Info. Ich habe das Updates für dieses WE eingeplant – dann hoffe ich mal, dass Euer Fall die Ausnahme war. Zumindest konnte ich im Netz keine weiteren User finden, die Probleme gemeldet hatten.
Gruß Boris
Hallo Boris,
so ging es mir am Donnerstag auch. Aber seit Samstag gibt es diesen Artikel, der doch recht deutlich über Probleme mit diesem Update berrichtet – oder hab ich mich verlesen?
Die Updates habe ich zwischenzeitlich (am Sonntag), nachgeholt und diesesmal ist auch alles sauber durchgelaufen – es scheint sich zwischenzeitlich etwas getan zu haben.
Viele Grüße
Martin
https://support.microsoft.com/de-de/help/4536988/description-of-the-security-update-for-microsoft-exchange-server-2013
"Exchange-Dienste bleiben möglicherweise nach der Installation dieses Sicherheitsupdates deaktiviert. Dies bedeutet nicht, dass das Update nicht ordnungsgemäß installiert wurde. Diese Situation kann eintreten, wenn die Dienststeuerungsskripts versuchen, den normalen Zustand der Exchange-Dienste wiederherzustellen, und dabei ein Problem auftritt.
Um dieses Problem zu beheben, stellen Sie mit dem Dienst-Manager den Starttyp Automatisch wieder her und starten anschließend die betroffenen Exchange-Dienste manuell. Um dieses Problem zu vermeiden, führen Sie das Sicherheitsupdate an einer Eingabeaufforderung mit erhöhten Rechten aus. Weitere Informationen zum Öffnen eines Eingabeaufforderungsfensters mit erhöhten Rechten finden Sie unter Starten einer Eingabeaufforderung als Administrator."
Hier ist das Problem perfekt dokumentiert (zwischenzeitlich)…. Das Dokument wurde seitens MS am 14.02.2020 angepasst – also vermutlich nach dem unteranderem wir in das Problem gelaufen sind. Ob der beschriebene Workaround bei betroffenen eine Lösung bringt, kann ich leider nicht mehr nachvollziehen. Mein auslesen der Logs und prüfen der Dienste hatte mich jedenfalls nicht auf diesen Weg der Lösung gebracht. Auch sehr langes Googeln und suchen nach bekannten Problemen oder gleichgesinnter hat mich nicht auf den Artikel gebracht.
Erst die Rücksprache mit dem MS-Support am Freitag gegen 12.00 Uhr, hat hervorgebracht, dass wir nicht alleine sind.