Microsoft hat heute Sicherheitsupdates für eine ganze Reihe Schwachstellen in Exchange Server veröffentlicht, auch für Exchange 2010 gibt es noch ein Update. Für Exchange 2016 und Exchange 2019 werden die folgenden Schwachstellen geschlossen:
- CVE-2020-17117 | Microsoft Exchange Remote Code Execution Vulnerability
- CVE-2020-17132 | Microsoft Exchange Remote Code Execution Vulnerability
- CVE-2020-17141 | Microsoft Exchange Remote Code Execution Vulnerability
- CVE-2020-17142 | Microsoft Exchange Remote Code Execution Vulnerability
- CVE-2020-17143 | Microsoft Exchange Information Disclosure Vulnerability
4 oder 5 Schwachstellen fallen in die Kategorie “Remote Code Execution”, daher sollte die verfügbaren Updates schnell eingespielt werden:
- Download Security Update For Exchange Server 2019 Cumulative Update 7 (KB4593465)
- Download Security Update For Exchange Server 2019 Cumulative Update 6 (KB4593465)
- Download Security Update For Exchange Server 2016 Cumulative Update 18 (KB4593465)
- Download Security Update For Exchange Server 2016 Cumulative Update 17 (KB4593465)
Exchange 2013 enthält 4 der 5 genannten Schwachstellen (CVE-2020-17141 entfällt), auch hier steht ein entsprechendes Update bereit:
Sogar für Exchange 2010 gibt es nochmal ein Update:
Wie immer gilt: Die Updates sollten vorher getestet werden, jedoch sollte auch nicht zu viel Zeit ins Land ziehen bis die Updates installiert werden.
Etwas spät aber dennoch hat es wunderbar funktioniert.
Windows Server 2012 R2
Windows Update Stand 27.12.2019
Exchange 15.0.1497.2 (CU 23) (2013)
.Net Framework 461814 (4.7.2)
Agenda meiner Updates (Standalone Exchange):
1. Virenscanner deaktivieren
2. Dienste Screenshots, test-servicehealth, Get-ServerComponentState
3. Windows Updates
4. Neustart
5. Hotfix Install via CMD als Admin
6. Neustart
7. Dienste prüfen, test-servicehealth, Get-ServerComponentState
8. Virenscanner aktivieren
9. Outlook Client Verbindung testen, Mailfluss etc.
Installation des CU19 Update (15.12.20) auf dem Exchange 2016 hat problemlos funktioniert.
Damit ist der Problemfall quasi gelöst.
Das hier:
https://www.frankysweb.de/exchange-2016-serverfehler-in-anwendung-owa-und-oder-ecp/
hat geholfen.
a) im IIS im Exchange Backend / ecp in Application Settings den binSearchFolders von diesem Blödsinn befreien
%ExchangeInstallDir%bin;%ExchangeInstallDir%bin\CmdletExtensionAgents;%ExchangeInstallDir%ClientAccess\Owa\bin
und statt dessen die richtigen (absoluten) Werte hinterlegen wie im Artikel beschrieben
Danach noch
C:\Program Files\Microsoft\Exchange Server\V15\Bin> .\UpdateCas.ps1
C:\Program Files\Microsoft\Exchange Server\V15\Bin> .\UpdateConfigFiles.ps1
und iisreset sowie reboot
Server läuft wieder
das Update ist manuell gestartet nun sauber durchgelaufen (ob es die Anwesenheit von MS gemerkt hat ..)
danach musste der IIS & WWW Publishing Dienst noch auf Automatisch gesetzt und gestartet werden.
Server wieder aus DAG Maintenance nehmen und es sieht gut aus
Erste DBs sind schon dort online und User drauf connected
was es nun war, der TEchniker vermutet der Reboot wäre ursächlich für das jetzige Funktionieren .. MH?!?!
mal schauen wie wir nun mit dem anderen Exchange verfahren
mfg
Stefan
Gleiche Beobachtung bei mir: Bei unserem virtuellen Exchange-Server 2016 CU18 gab es einen Fehler bei der Installation des Patches und nach einem Neustart waren die Dienste deaktiviert und nichts ging mehr. Da ich die Exchange-Datenbanken auf anderen Partitionen lagere, habe ich die virtuelle C:-Platte auf den Stand von vor der Installation zurückgesetzt. Danach funktionierte alles wieder. In einem solchen Fall kann ich der Installation sowieso nicht mehr vertrauen, weshalb ich es gar nicht versuche, die Ursache zu finden. Ich denke mal, dass Microsoft automatisch mit entsprechenden Informationen über die Fehler versorgt wird. Deshalb habe ich diesen Patch auf dem WSUS-Server blockiert und harre der Dinge, die da kommen werden.
Ist das zurücksetzen der C-Platte überhaupt supported ?
Das ist eine gute Frage. Sie entspricht allerdings einer Denkwelt, die ich mir nicht zu eigen machen möchte. Wenn solche Systeme so empfindlich wären, dass man bei einem Exchange-Server nicht auf einen früheren Zeitpunkt zurückwechseln könnte, und gleichzeitig die Patches von so mieser Qualität sind, dass nach einem Installationsversuch der Exchange-Server in einem undefinierten zurückbleiben, dann würde das ja bedeuten, dass die Systeme im Prinzip unwartbar wären. Ich verfüge ja über eine konsistente über unzählige Schattensicherungen-Writer abgesicherte application-safe erzeugte Sicherung des Systems. Warum um alles in der Welt soll ich die nicht verwenden können, wenn ein solches Unglück passiert? In letzter Konsequenz bräuchte ich dann ja überhaupt keine Sicherung zu erzeugen.
Win Server 2016
Exchange 2016 CU18 DAG aus 2 Knoten
Letzte Updates zuletzt Mitte November installiert und bis dato nie Probleme mit Updates auf den Exc-Systemen gehabt.
und nun ebenfalls Probleme, hab den ersten Knoten aktualisiert, bzw versucht über die System Updates
Allerdings ist das KB4593465 immer wieder auf failure gegangen. Manuelle Installation mit Adminrechten ebenfalls (prematurely because of error)
Nach dem Reboot blieben alle Exchange Dienste disabled, manuell wieder auf Auto gestellt und nochmal neugestartet.
Dienste starten alle aber der Server läuft nicht sauber, im Eventlog finde ich nichts, musste ihn am Loadbalancer deaktivieren da sonst ständig die Outlook Clients mit Fehler reagieren.
Hab ein Ticket bei MS geöffnet, bin gespannt was dabei herauskommt.
mfg
STefan
Installation als eigenständiges Update (Commandozeile mit Adminrechten) auf Exchange 2013 CU23. Der Exchange läuft nur noch als „Bedienoberfläche“ für die 365er Konten, die mit der Domain synchronisiert werden. Und hier ist auch das Problem. Auf der gleichen Maschine läuft auch der Azure AD Sync. Und den beendet das Setup nicht! Dadurch kann es zu den gleichen Problemen kommen, wie im KB beschrieben wenn man das Update von Hand und nicht mit Admin Rechten ausführt. Danach war ein Zugriff auf OWA/ECP nicht mehr möglich. Fahre jetzt gerad den 2. Versuch und hoffe, dass es diesmal klappt.
Ergänzung: Alle anderen Dienste des Exchange werden sauber beendet und auch während des Updates deaktiviert. Wer also diese Kombi auf seinem Exchange laufen hat (ich vermute es spielt dabei keine Rolle ob 2013, 1016 oder 2019) tut gut daran den Dienst vorher zu beenden und auch zu deaktivieren.
Danke für den Hinweis.
Hier würde das Prinzip „ein Service = ein Server“ Abhilfe schaffen.
Auf einem unserer Exchange Server 2016 CU 18 stimmte nach der Installation des Updates die Darstellung im ECP nicht mehr. Man konnte sich anmelden, aber hatte danach eine „nur Text“ Seite und alle Links waren ohne Funktion.
Hier die Lösung wie ich das ECP wieder ans Laufen bekommen haben:
Im Ordner E:\Microsoft\Exchange Server\V15\ClientAccess\ecp gibt es jede Menge Ordner 15.1.xxx.x
Der neueste davon war am Tag des Updates erstellt worden. Er enthielt die gleiche Ordnerstruktur wie die restlichen Ordner auch, allerdings keine Inhalte. Ich habe den gesamten Inhalt von 15.1.2106.4 (vom Novemer 2020) nach 15.1.2106.6 (09.12.2020) kopiert, einmal die Seite neu geladen und schon läuft das ECP wieder.
Exchange Server 2019 CU7 – bisher keine Probleme festgestellt.
Ich habe im November den Exchange Server 2019 frisch mit CU7 installiert, habe seitdem die Security Updates vom November und Dezember installiert.
Habe übersehen, dass es im Oktober auch schon ein Security Update für CU7 gegeben hätte.
Beinhaltet dieses Dezember Security Update auch die Security Updates von Oktober und November?
Oder kann ich das Oktober Update bedenkenlos nach dem Dez-Update installieren?
Viele Grüße!
Ahja, steht ja in den jeweiligen MS-Update-Seiten:
This security update replaces the following previously released updates
Wer lesen kann… da haben wir es mal wieder :)
Hallo,
also heute vormittag nach diversen Versuchen den Exchange 2016 VM aus Backup vom 8.12 wieder hergestellt, lief gut danach.
„Updates für andere Produkte bereitstellen“ wenn ein Windows Update ausgeführt wird habe ich deaktiviert.
Trotzdem fing er an den Security Update For Exchange Server 2016 CU18 (KB4593465) und den 020-12 Cumulative Update for Windows Server 2016 for x64-based Systems (KB4593226) zu landen und zu installieren. Von selbst.
BuMM, wieder geht Exchange nicht mehr, Dienste sind deaktiviert etc.
Also der KB4593465 ist der Wahnsinn.
Ich weiss nicht wie ich ihn verhindern soll und wieder einen funktionsfähigen Server bekommen soll, bin mit meinem Latain am Ende.
Tja… hier geht gar nichts mehr nach den Updates. Anmeldeseite von ECP oder OWA erscheint noch, danach ist Ende.
Trifft das zu? https://support.microsoft.com/de-de/help/4593465/description-of-the-security-update-for-microsoft-exchange-server-2019
dto, auch Exchange Server 2016(V 1607 (Build 14393.4104) mit CU18, so ein Mist.
Der Security Update For Exchange Server 2016 CU18 (KB4593465) ist irgendwie destruktiv, Exchange funktioniert damit nicht, empfängte zumindestens keine Mails.
Ohne nähere Anayse deinstalliere ich den KB4593465 gerade wieder, so was brauch ich nicht wirklich auf einer Produktivmaschine.
Habe keine Testmaschine für so was, nur Backups.
Die Deinstallation hat nicht funktioniert, klasse Sache so was „ended prematurely“.
Ich habe dann wie oben von Wolfgang gepostet bei MS hinterlegt die Excahnge Dienste wieder aktiviert udn gestaret und dann KB4593465 nochmals als Admin in der EIngabeaufforderung installiert. Das läuft seit 3 Stunden. Der Hammer, so was, Exchange seit gestern Abend offline.
Bin gerade dran:
6 x Exchange 2016 Enterprise CU 18 auf Server 2016, DAG
1. Virenscanner deaktivieren
2. Internet Explorer -> Tools -> Internet Options -> Advanced -> Security -> Check CRLs… deaktivieren
3. Maintenance Mode starten
4. Alles, was PowerShell hat/ist/heißt, schließen
5. Command-Prompt als Admin starten
6. .msp-Datei aus Kommandozeile heraus starten
7. Warten, bis fertig
8. Maintenance Mode beenden, Virenscanner aktivieren, Check CRLs im IE aktivieren
Dauer: 20 min auf einem Dell R740XD 24 Core Xeon (2.1 GHz), 192 GB RAM, Windows/Exchange auf M.2-SSDs
Abschließend Reboot!
Argh: Erst Reboot – dann ab Punkt 8 weitermachen latürnich!
Alle 6 Systeme der DAG problemlos durchgelaufen
Hallo Wolfgang,
Super, hilfreich deine Info. Nach deiner Erklärungen kann ich entnehmen, daß du einen Dell physikalischen Rackserver verwendest für deine DAG Umgebung, gibt es ein bevorzugten Grund, warum du nicht virtuellen Maschinen einsetzt?
Gruß, Salim
Gestern Abend per WSUS installiert. Lief unauffällig durch. Bisher wurden vom Büro keine Probleme gemeldet.
Server 2016
Exchange 2016 CU18
Gruß