Vor einer Woche hat Microsoft neue Sicherheitsupdates für Exchange Server 2013, 2016 und 2019 veröffentlicht. Ich berichte erst jetzt darüber, da ich die letzten 14 Tage im Urlaub war. Aber dank des CVE-Reporter sollte dies ja kein Problem darstellen :-)
Die folgenden vier Schwachstellen werden durch die Updates geschlossen:
Hier geht es direkt zu den Downloads:
- Exchange 2019 CU10 (KB5004780)
- Exchange 2019 CU9 (KB5004780)
- Exchange 2016 CU21 (KB5004779)
- Exchange 2016 CU20 (KB5004779)
- Exchange 2013 CU23 (KB5004778)
Außerdem weißt Microsoft explizit darauf hin, dass die manuelle Installation des Updates eine Shell im „Elevated“-Modus („Als Administrator ausführen“) ausgeführt werden muss. Hier einmal ein Beispiel der „Elevated Shell“:
Alternativ kann das Update natürlich auch via WSUS, Windows Update oder anderen Tools installiert werden. Falls das Update der Exchange Server schief geht, finden sich hier übrigens einige mögliche Lösungen für die Probleme:
Hallo zusammen,
aktuell habe ich das Problem, dass das Update zwar installiert wird, aber immer noch über Healthchecker oder Get-Hotfix nicht erkannt wird.
Wenn man es wieder installiert, meldet er keine Fehler. Wie kann man sichergehen, dass es richtig installiert wurde?!
(Exchange 2013 CU 23 – KB5004778)
Ist 2013 nicht EOL?
Security Updates gibt es noch oder was meinst Du ?
Ich nutze selbst kein 2013, habe aber gelesen, dass der Mainsupport 2018 bereits ausgelaufe ist. Dass wie du schreibst dennoch Security-Updates veröffentlicht werden, verwundert mich etwas. Bislang dachte ich, dass beim Erreichen des EOL nur in besonderen Ausnahmefällen wie der Proxy-Logon Sicherheitspatches für ausgelaufene Versionen veröffentlicht werden.
3 Server 2013 CU23 gepatcht, ohne Probleme.
Dass es über KEMP nicht geht, wenn die Server unterschiedliche Stände haben, war mir neu. War das schon immer so ?
Diesen Zustand haben wir beim patchen zum Glück nicht lange.
Hallo,
uns hat es am Wochenende auch getroffen. ECP/OWA funktionierte nicht mehr.
Nach viel suchen und recherchieren Problem eingekreist.
Nur, die Exchange Management Console funktionierte bei uns auch nicht mehr!
Lösung => in der Powershell das AddIn von Exchange einbinden:
Add-PSSnapin Microsoft.Exchange.Management.PowerShell.SnapIn
Dann konnte das Zertifikat neu ausgestellt werden.
Zusätzlich war im IIS – Exchange Back End das Zertifikat nicht zugeordnet, musste also auch noch gemacht werden!
Danke nochmals an Franky, mit seinen Artikeln hier hat er mich richtig geholfen!!!
Bei einer unserer Umgebungen die noch mit Exchange 2013 betrieben wird, haben wir die Aktualisierung gestern Abend durchgeführt. Im Anschluss hatten wir das beschriebene Problem mit OWA/ECP.
https://support.microsoft.com/en-us/topic/cannot-log-in-to-owa-or-ecp-after-july-2021-su-for-exchange-server-2019-2016-and-2013-kb-5005341-476948d6-e124-4a60-bcc7-b0d5341e24ae
Das AUTH Zertifikat war bei uns zwar nicht abgelaufen, allerdings war das (schon vor längerer Zeit) neu erstellte nicht entsprechend in der Konfiguration hinterlegt. Get-AuthConfig hat uns das dann schließlich offenbart, das abgelaufene Zertifikat wurde offensichtlich einfach gelöscht, ein neues erstellt, dieses allerdings nicht mit Set-AuthConfig hinterlegt.
Nachdem wir das gemacht hatten, lief auch direkt wieder alles einwandfrei.
Ist mit diesem Update auch das Problem mit langsamen Verbindungen weg? (AMSI Integration)
Das Problem wird von McAfee Sophos verursacht. Wie könnte es durch ein Microsoft Security Update weg sein?
Problemlos durchgelaufen auf meinen 2019 CU10. Auch die Probleme mit dem Zertifikat haben mich verschont, schön mal sowas zu erleben.
falschen Prepare-Befehl gepostet, hier ist der richtige:
“Setup.exe /PrepareSchema /IAcceptExchangeServerLicenseTerms”
Ist vielleicht eine blöde Frage, aber warum installierst du das manuell?
Das CU macht das ja automatisch.
Hallo.
BTW. Hat jemand den Link für dir Migration von Exchange 2016 nach Exchange 2019 on-premise ?
Wir würden auch gerne auf CU21 updaten, sowie das letzte Sicherheitsupdate. Leider kann man dann aber nicht mehr von außen auf OWA zugreifen. Intern funktioniert es jedoch.
Was wäre nun das Richtige.. auf aktualisiertes und fehlerfreies Update des Sicherheitspatches zu warten oder es selbst hinterher beheben? Wenn das 2-te, dann frage ich mich ob es hierfür schon eine 100%-tige Lösung gibt?
Danke
@ Benny
Gibt es dafür eine Quelle? Warum geht OWA von außen nach dem Update nicht mehr? Hör das jetzt zum ersten y an mal…
Hi zusammen,
die „OWA läuft nicht“-Themen sind nur im Bezug mit den abgelaufenen Zertifikaten zu sehen.
Hier: Exchange 2016 DAG hinter nem Kemp LB mit CU21 + SU am Laufen.
Die Exchange-Server haben wir nacheinander schrittweise auf CU21 (inklusive vorherigem Schema-Prep) angehoben und direkt vor Inbetriebnahme/Live-Schaltung auch das passende SU installiert.
TL:DR:
Exchange 2016 CU20 -> Server reboot -> CU21: Elevated CMD mit Setup.exe /Iaccept… /PrepareAD -> Installation von CU21 -> reboot -> Installation June SU -> reboot.
nächster Server…
https://techcommunity.microsoft.com/t5/exchange-team-blog/released-july-2021-exchange-server-security-updates/ba-p/2523421
Hallo Zusammen,
auch bei mir hat sich nach der Installation des Security Updates der Exchange Server 2016 derart seltsam verhalten (kein OWA, ECP , aber auch kein Zugriff via Exchange Management Shell), dass ich alle Sicherheitsupdates (auch für Windows Server 2016) vom Juli 2021 deinstaliert habe. Gelöst habe ich es nur durch eine eh schon geplante Migration auf Exchange 2019 auf Server 2019, welche Dank der guten Anleitung auf dieser Website reibungslos geklappt hat.
Was wäre ich nur ohne diesen Blog ;-)
auch bei mir hat es bei 3 von 3 exchange das owa und ecp zerschossen *grml*
nach dem tausch des zertifikat dauert es mehrere stunden bis der owa wieder läuft *prima MS!!* grml
Anmerkung zur Installation des SU für Ex 2016 CU20
– Wie oben bereits von mir beschriebe, zunächst Schema-Update mit den Medien vom CU21 durchgeführt
– SU für CU 20 war innerhalb von 15 Minuten installiert, jedoch hat dann der Reboot 45 Minuten gedauert und war sehr CPU-intensiv… es kam bereits leichte Panik auf (leicht aber auch nur, da wir DAGs betreuen) ;-)
Ein derartiges Problem hatten wir schon öfter, bein uns hat es meistens am prozess „tiworker“ gelegen.
Dieser hängt sich beim reboot nach dem update auf (100% single core load) und wird nach einem sehr langen Timeout automatisch terminiert.
In dieser Situation haben wir keine Möglichkeit mehr eine Desktop Session zu öffnen, über eine PSSession lässt sich das Problem jedoch Anhand der CPU Last verteilung verifizieren und der Prozess von Hand stoppen.
Zunächst: Willkommen zurück aus dem Urlaub ;-)
Auch dieses Sicherheitsupdate benötigt wieder einen manuellen Eingriff, sofern man es nicht auf das aktuellste CU installierst , sondern CU-1:
https://techcommunity.microsoft.com/t5/exchange-team-blog/released-july-2021-exchange-server-security-updates/ba-p/2523421
Bei Update von Ex 2016 CU20 bzw. Ex 2019 CU9 muss mit den Dateien von CU21 bzw. CU10 ein Schemaupdate durchgeführt werden. Ob vor oder nach der Installation des SU für CU20 bzw. CU9 ist lt. Microsoft irrelevant. Das Schemaupdate ist aber für den sicheren Betrieb der Umgebungen notwendig.
Hallo zusammen,
ich habe auch ein sehr komisches Verhalten nachdem ich gestern auf einem Ex2016 mit CU20 erst das CU21 installiert habe und dann den Security Patch.
Wenn ich nun über unsere Standard URL das Admin Center aufrufe und mich anmelden will, lädt sich die Seite neu und ich stehe weiterhin bei der Anmeldung. Nehme ich den Server direkt in der URL auf, klappt der Zugriff ohne Probleme. Outlook funktioniert soweit nur eben das Admin Center und OWA nicht mehr. Jetzt habe ich Bedenken bezüglich weiterer Aktualisierung der anderen Exchange Server.
Was kann hier das Problem sein?
MfG Paul
Hallo Paul,
das gleiche Problem habe ich auch beobachtet und wird auch im Microsoft Exchange Blog gemeldet. Ursache bei mir war, das nur ein Teil der Exchange Server gepatcht war. In diesem Zustand hatte ich den gleichen Effekt wie du, dass die Anmeldung über den Loadbalancer nicht mehr funktioniert hat. Herausnehmen des gepatchten Servers als Ziel im LB hat das temporär behoben. Nachdem
Patchen aller Server war das Problem wieder weg.
Hallo Claus,
ja wir setzen auch den KEMP ein und nach dem deaktivieren klappt auch der Zugriff da die ungepatchten Systeme wirken.
Wenn Du einen Link zu den Blog hast wäre das super und ich werde dann wohl erstmal alle restlichen Exchange Server aktualisieren.
MfG Paul
Bei uns gingen alle gepatchten Systeme nicht. Da wir gerade beim umstieg nach Exchange 2019 sind, haben auch die alten Systeme im zusammen soiel mit den neunen nicht funktioniert. Der Kempsupport sagt dazu, das der Parameter
Persistence auf Source-IP bei OWA und ECP gesetzt werden muss, dann funktioniert auch wieder alles. Das ist auch die Vorgabe von Microsoft. Bei uns läuft jetzt wieder alles, ob gepatcht oder ungepatcht ob neu oder alt.
Mit freundlichen Grüßen
Mario
Läuft wieder nachdem ich wie unten schon erwähnt am KEMP die Option „Persistence Options“ (unter Standard Options) auf „Source-IP“ bei den VS OWA und ECP gestellt habe. Bei dem externen OWA & ECP dagegen auf Grund unserer FW davor statt „Source IP“ -> „Super HTTP and Source IP“ (Empfehlung von unserem Externen Support).
MfG Paul
Hallo Paul,
Hier hat Microsoft die Infos zum Security Patch veröffentlicht:
https://techcommunity.microsoft.com/t5/exchange-team-blog/released-july-2021-exchange-server-security-updates/ba-p/2523421
In den Kommentaren schreibt mstoffa am Jul 20 2021 03:39 AM
„As others have stated the login loop issue with servers behind a load balancer appears to be corrected once you apply the July 2021 Security Patch to all servers in the load balancer. This morning I have tested this again and now I have both of our servers running Exchange 2016 CU21 with the July Security Patch. So far I have not noticed any issues logging into ECP or OWA like I was seeing last week with only having one of my servers patched. „
Hallo Peter,
Zertifikat muss 1x für die Org neu installiert werden: https://docs.microsoft.com/en-us/exchange/troubleshoot/administration/cannot-access-owa-or-ecp-if-oauth-expired
Leider wird das eingesetzte und gültige LE Zertifikat dabei geshreddert.
OWA etc. ohne Funktion. 2016 CU21 DAG
Lösung:
Set-AuthConfig -NewCertificateThumbprint -NewCertificateEffectiveDate (Get-Date)
Set-AuthConfig -PublishCertificate
Set-AuthConfig -ClearPreviousCertificate >> habe ich weggelassen
Den Thumbprint zum vorhandenen, gültigen Zertifikat findest Du unter ausführen > mmc > Snapin laden > Zertifikate > dieser Computer > weiter, weiter, weiter > dann müsstest Du da das OAuth Zertifikat sehen > Rechtsklick > 1. Eintrag und in den Eigenschaften findest Du die ellenlange Nummer
Hilft das?
Punkt 1 bis 4 abarbeiten: https://docs.microsoft.com/en-us/exchange/troubleshoot/administration/cannot-access-owa-or-ecp-if-oauth-expired
Den Thumbprint findet man einfacher per get-exchangecertificate, denn an der EMS ist man bei deiner Anleitung ja sowieso schon. ;)