Microsoft hat ein neues Sicherheitsupdate für Exchange Server 2013 bis 2019 veröffentlicht (CVE-2019-1373). Das Update schließt eine Sicherheitslücke, bei der es im schlimmsten Fall möglich ist aus der Ferne Code auszuführen. Microsoft stuft den Schweregrad der Sicherheitslücke mit dem Schweregrad kritisch ein. Das Update sollte also zeitnah installiert werden. Microsoft nennt die folgenden Details zu der Lücke:
A remote code execution vulnerability exists in Microsoft Exchange through the deserialization of metadata via PowerShell. An attacker who successfully exploited the vulnerability could run arbitrary code in the context of the logged in user.
Exploitation of this vulnerability requires that a user run cmdlets via PowerShell.
The security update addresses the vulnerability by correcting how Exchange serializes its metadata.
Hier findet sich der KB Eintrag für das Update:
Wichtig: Hier bitte unbedingt die Hinweise zu den bekannten Problemen zu diesem Update im oben verlinkten Artikel lesen. Es kann bei und nach der Installation zu Problemen kommen.
Hier geht es direkt zum Download des Updates:
- Download Security Update for Exchange Server 2019 Cumulative Update 3 (KB4523171)
- Download Security Update for Exchange Server 2019 Cumulative Update 2 (KB4523171)
- Download Security Update for Exchange Server 2016 Cumulative Update 14 (KB4523171)
- Download Security Update for Exchange Server 2016 Cumulative Update 13 (KB4523171)
- Download Security Update for Exchange Server 2013 Cumulative Update 23 (KB4523171)
Das mit das Update installiert werden kann, muss zunächst auf eine kompatible Exchange Version aktualisiert werden. Beispielsweise Exchange 2019 CU3, Exchange 2016 CU14 oder Exchange 2013 CU23. Nur für diese Exchange Versionen wird das Update unterstützt, dass heißt natürlich nicht, dass die Sicherheitslücke nicht auf in früheren Exchange Versionen, beispielsweise Exchange 2016 CU 10 enthalten ist. Für ältere CU Versionen wird die Lücke nur nicht mehr gefixt.
Patch auf Exchange 2019 per Windows Update installiert, ich dachte erst ich hätte die selbe Problematik mit den Diensten, nach einiger Zeit kamen diese allerdings auch hoch (mit Ausnahme des Compliance Audit-Dienst den ich manuell starten musste).
Auch hier eine positive Meldung: Update lief ohne Probleme durch. Exchange 2016 CU 14. Kein DAG. Alle Dienste liefen nach den Restart. Auch unser Exchange Rules macht was es soll. Einzig im ECP gab es kurzzeitig eine komische Meldung bei den Zertifikaten. „Sperrungsprüfung fehlgeschlagen“ beim Let’s Encrypt Zertifikat. Bin nicht ganz draus schlau geworden. Während ich nach dem Fehler ge-googlt hab, löste sich das anscheinend von selbst. Ein paar Minuten später stand nämlich wieder „gültig“ da. Die Funktion war aber zu keiner Zeit eingeschränkt.
Exchange 2016, CU 13 – Update ging problemlos durch. Alle Dienste laufen ohne Probleme.
(Nur so als Info abseits der nicht so positiven Kommentare hier :D)
Ich habe bei einem Kunden eine 2016CU14 Umgebung, in der der Patch automatisch installiert wurde, dort funktioniert nun ein Drittanbieter-Tool aufgrund von Berechtigungsprolemen nicht mehr. Seteup /prepareAD hat nichts gebracht, bisher keine Lösung.
In einer 2013CU23 Umgebung habe ich das Problem, dass der Healthmonitor spinnt und bspw. Get-Healthreport nur noch Unknown zurückmeldet, wesegen, keine DBs aus dem DAG gemountet werden. Hier versuche ich derzeit zurück CU23 zu kommen. Wenigstens hat hier der andere Knoten das Update nicht installiert, sodass zumindest die Funktion gewährleistet ist.
Das mit der Versionsmummer ist m.E. normal, Security Patches ändern nicht den igentlchen Build, die „korrekte“ Nummer sieht man nur in der Versionsnummer der ExSetup.exe
Auch bei uns verursacht das Update unter Exchange Server 2016 CU 14 keine Probleme.
Exchange 2016 CU14 – DAG-Cluster mit 4 Knoten – Windows Server 2016 mit allen Updates inkl. 2019-11 .NET 4.8
Update auf dem WSUS freigegeben
Jeweils die Server nacheinander in Wartung genommen und das Update als Exchange-Admin (kein Domain-Admin) über den Windows Update Dienst installiert.
Alles ohne Probleme.
Bei mir auch noch Build 1847.3, hatte mich schon gewundert
Habe das Update auf unseren Exchange 2016 mit CU14 installiert. Ist ein DAG mit 3 Servern. Einfach mittels WSUS drüber geklatscht, kein Wartungsmodus, nur die aktiven DBs auf einen anderen Server installiert.
Soweit so gut und keine Probleme seit letzter Woche. Mir ist aber gerade aufgefallen, dass sich die Build Nummer nicht erhöht hat in der ECP. Ist immer noch Version 15.1 (Build 1847.3). Gemäss https://www.msxfaq.de/exchange/update/build.htm#exchange_2016__version_15_1_ sollte sich das ja auf 1847.5 erhöhen.
Was habt Ihr denn so für Build-Versionen?
Also ich habe am Wochenende unsere
beiden 2010er Exchange Standard mit DAG auf Windows 2012 (R1) VM durch
zwei Exchange 2016 Standard mit DAG auf Windows 2016 ersetzt.
WSUS ist bei beiden Servern aktuell und die Versionsnummer ist Version 15.1 (Build 1847.3)
Die Migration lief übrigens relativ gut:
– Musste nach dem Installationsvorbereitungsskript noch manuell Framework (4.7.2?) nach-installieren (Skript hat 4.6? installiert)
– Exchange 2016 hat die Exchange 2010er Server gesehen
– Exchange 2016 DAG lies sich einfacher einrichten als auf Exchange 2010
– Die Postfächer sowie Arbiration und Archiv konnten ohne Probleme migriert werden
– SSL Zertifikat musste aus Exchange 2010 exportiert werden und wurden dann über UNC Pfad in Exchange 2016 importiert
– Sende- und Empfangskonnektoren waren soweit korrekt (die 2010er habe ich löschen müssen)
– Firewall, Nat und DNS Hosts wurden manuell aktualisiert (2x DNS überprüfung notwendig weil ich eventuell einen Eintrag übersehen habe)
– InterneSMTPServer mussten per Shell manuell hinzugefügt und entfernt werden
– PST Backup-Script im Verzeichnis (V14 auf V15) wurde noch geändert.
– Outlook Clients haben dann Mailboxen repariert (autodiscover)
– Nur ist eine der beiden 2012er VMs nach der kompletten Dekommissionierung von Exchange 2010 und Installation neuer Rollen (Remotedesktopdienste) abgeschmiert und wurde neu erstellt weil ich es nicht mehr gewagt habe ein Backup mit der eventuellen Exchange 2010 Installation wiederherzustellen.
Exchange 2016 CU14 – DAG-Cluster mit 2 Knoten.
Auch hier die Knoten jeweils in den Wartungsmodus versetzt und das Update manuell über eine PowerShell mit erhöhten Rechten gestartet (so wie immer). Es funktioniert alles ohne Probleme.
Exchange 2013 CU23 – DAG Cluster mit 2 Knoten. Ich habe das Update über den WSUS freigegeben und dann über den Windows Update Dienst installiert. Die Knoten jeweils in den Wartungsmodus versetzt. Es lief alles sauber durch. Die Dienstefehler hängen wohl mit UAC zusammen (wenn man das Update manuell lädt und installiert). Das gab es auch schon bei Exchange 2010. Einfach eine CMD mit erhöhten Rechten öffnen und dort das Update starten. So steht es auch im KB Artikel von Microsoft.
Moin Boris B.,
danke für den Hinweis aber ich habe es natürlich auch über den WSUS ausgerollt und es kam zum anfangs beschriebenen Problem (Exchange 2013 CU23). Werde es bei Gelegenheit nochmal manuell testen wie von Dir beschrieben.
Unser Exchange 2016 verträgt das CU13 Update erst gar nicht. Habe es bereits 2 mal laut installer erfolgreich installiert, aber nach dem anschließenden Neustart starten sehr viele Dienste nicht mehr mit dem Hinweis, das ein Abhänigier Dienst nicht gestartet ist, will man diese dann anzeigen, kommt ein Fehler Win32.. und der Server wird im Monitoring sogar nur noch als PC erkannt. Spiele jetzt erst mal wieder das Backup ein und machen mich dann auf die erweiterte Fehlersuche. Falls ihr das auch schon hattet, wäre ich um Tipps dankbar.
Exchange Server 2016 CU 14 hier, nur der Transport Dienst hat ein bisschen länger gebraucht zum starten als sonst (Herzklopfen…), aber sonnst alles soweit okay.
Hallo,
gibt es bereits Erfahrungen mit E2016 in einer größeren Installation mit DAGs?`
E.
Moin,
hilfreich zur Einschätzung wäre es wenn Ihr wenigstens kurz erwähnt auf welcher Exchange Version ihr seid.
Hallo,
in unserem Testsystem geht alles. Werde es nächste Woche produktiv einspielen und hoffen :)
Schönes Wochenende euch allen
Exchnage Server 2016 CU 14
Hallo,
bei uns gibt es nach dem Update mehrere eigenartige Effekte.
Zum einen verweigern Outlook 2016+ den Zugriff auf Öffentliche Ordner. Per OWA sind die da und auch bei Outlook 2010 sind diese sichtbar und nutzbar.
Aber auch bei einigen Outlook 2016 wird spontan die Verbindung zum Server abgewiesen – nur Offline Verbindung möglich. Wenn es keine schnelle Hilfe gibt oder wir keine Lösung finden, muss das Updates erstmal wieder runter.
Hallo Ingo,
Der Backend-Server verliert teilweise die Zertifikats-Zuordnung (bei 2 von 8 2013er passiert (beide LE-Zertifikate)).
–> IIS- Manager
–> Exchange Back End
–> Bindungen bearbeiten
–> https 444 (444 ist richtig, nicht ändern!) bearbeiten
–> SSL-Zertifikat –> richtiges Zertifikat wieder einstellen
–> Admininistrative CMD –> iisreset
–> #läuft
Gruß Meik
Merci,
aber das hat bei uns noch gepasst…..
Danke für den Hinweis! Das selbe Problem hatte ich bei meinen Exchange 2019 CU3 auch, als das Sicherheitsupdate eingespielt wurde. Das Zertifikat neu einzustellen hat geholfen, ein iisreset war nicht notwendig.
Moin,
also unter Exchange 2013Cu23 nicht zu empfehlen, läuft auf Fehler und deaktiviert alle Exchange Dienste.
Den Kommentar habe ich leider zu spät gelesen und durfte auf das (zum Glück) vorher gemachte Backup zurück.
Nach der Installation des CU 23 lief noch alles und nach dem Sicherheitsupdate ging gar nichts mehr.
OK, das macht es natürlich extrem sicher.
Ich habe das gleiche Probleme mit Exchange 2016 auf Cu14.
Gibt es dafür eine Lösung?
Das Problem ist erst aufgetreten nachdem das Security Update installiert wurde.
Danke.
Ja. Würde mich auch interessieren.
Was macht man in diesem Fall?
Grüße,
Mike
wir konnten zum Glück zurück auf das letzte Backup vor dem Update Fehler und ich habe dann direkt über das komplette ISO Exchange 2016 CU14 (~5,8GB) über eine administrative Powershell die Setup.exe aus dem ISO gestartet. Damit lief die Installation und auch der anschließende Neustart sauber durch. Hoffe das hilft euch weiter!
Viele Grüße
Roland