Microsoft hat gestern das CU 14 für Exchange Server 2019 veröffentlicht. Das CU 14 bringt diese Neuerungen mit:
- .NET Framework 4.8.1 Support für Windows Server 2022
- Extended Protection wird in der Standardeinstellung aktiviert, dies lässt sich per Schalter in der Shell abschalten (Achtung!)
Angedacht war auch der Support für TLS 1.3, dies hat es allerdings nicht in das CU 14 geschafft. Hier lässt sich das CU 14 runterladen:
Wie bereits erwähnt aktiviert das CU 14 in der Standardeinstellung die Extended Protection. Dies kann zu Problemen führen, wenn in der Umgebung bisher nicht die Voraussetzungen für Extended Protection geschaffen wurden. Microsoft hat hier auf dem Exchange Team Blog eine Grafik veröffentlicht:
Wer Extended Protection derzeit nicht nutzen kann, muss daher das Setup mit den Parametern aus der Grafik aufrufen. Die Extended Protection dichtet allerdings auch eine neue kritische Schwachstelle ab:
Aufgrund der Schwachstelle sollte daher Extended Protection unbedingt aktiviert werden.
Man verzeihe mir meine Frage, aber bezieht sich das „Server“ in der Grafik nur auf Exchange Server, oder auf alle in der domäbe vorhanden Server (Domänencontroller, Member-Server etc) ?
Exchange Cu 14 problemlos! Alles soweit in Ordnung
Wie deaktiviert man den das EP nachdem es installiert wurde ? Gibs hier ein Script ?
Ja, steht auch so in dem MS-Blog Eintrag zum CU14. Das Skript zum manuellen Aktivieren und auch zum Deaktivieren findet sich hier: https://microsoft.github.io/CSS-Exchange/Security/ExchangeExtendedProtectionManagement/
Aber manchmal frage ich mich, warum man nicht die offiziellen Release Notes liest, bevor man CUs oder SUs installiert. In der Regel dokumentiert MS in den Blog Einträgen, die Frank auch immer verlinkt, solche Informationen ziemlich gut.
Hallo,
wenn ich mit zwei Issues hier einmal zu Wort melden darf.
Nach Installation des CU14 auf EX 2019 Hybrid sehen wir keine OWA oder ECP Anmeldewebsite sondern nur noch ein Fenster mit Benutzername und Passwort. Die Anmeldung darin ist beständig, als nach Schließen des Fensters verbleibt das Token im Browser? Wir nutzen einen NGINX und haben erst eine nicht mehr pasende Config als Fehler gesehen, das Verhalten erleben wir aber auch auf dem Server selbst bzw bei direkter Ansprache.
Weil Agentur haben wir eine recht große Flotte von macOS devices. Auf denen erleben wir jetzt, dass Mails nicht mehr gepusht werden sondern nur noch manuell abgerufen werden können. Jeden Tag kommen ein oder zwei User dazu.
Bisher sind wir, insbesondere zu letzterem Problem recht ratlos?!
Ich habe über Frankys Artikel damals SSL-Offloading aktiviert mit :
2
3
4
5
6
7
Set-WebConfigurationProperty -Filter //security/access -Name sslflags -Value „None“ -PSPath IIS: -Location „Default Web Site/OWA“
Set-WebConfigurationProperty -Filter //security/access -Name sslflags -Value „None“ -PSPath IIS: -Location „Default Web Site/ECP“
Set-WebConfigurationProperty -Filter //security/access -Name sslflags -Value „None“ -PSPath IIS: -Location „Default Web Site/OAB“
Set-WebConfigurationProperty -Filter //security/access -Name sslflags -Value „None“ -PSPath IIS: -Location „Default Web Site/EWS“
Set-WebConfigurationProperty -Filter //security/access -Name sslflags -Value „None“ -PSPath IIS: -Location „Default Web Site/Microsoft-Server-ActiveSync“
Set-WebConfigurationProperty -Filter //security/access -Name sslflags -Value „None“ -PSPath IIS: -Location „Default Web Site/Autodiscover“
Set-WebConfigurationProperty -Filter //security/access -Name sslflags -Value „None“ -PSPath IIS: -Location „Default Web Site/MAPI“
wie ist aber der ScriptBefehl nun um das SSL-Offloading wieder zu deaktivieren?
Seit CU14 sind ALLE Mails mindestens für 2 Minuten erst im Postausgang, bevor sie verarbeitet haben.
Outlook auf dem Mac dreht sogar völlig durch und gibt Fehler, dass der Server / die Serververbindung überlastet sei.
Teilweise werden Mails nun auch mehrfach zugestellt.
Jemand eine Idee, was das sein könnte ?
Bei uns sind auch alle Zugriffe auf den Exchange um Minuten verzögert. Also senden einer Mail, Erstellen eines Termins etc.
Auch das Senden einer Mail über OWA bringt einen minutenlangen „Ladering“ im Formular für das Erstellen der Mail.
Im QueueViewer kann man sehen, dass Mails dort teilweise für Minuten liegen, bevor in einem Rutsch alle bearbeitet werden.
Wir haben die CU14 am 15.02. installiert und in der Nacht vom 15.02. auf den 16.02. wurde der Windows-Server gepatched und neu gestartet. Seitdem können wir das Verhalten beobachten. Bei uns war die Extended Protection schon vorher aktiviert (seit dem Aufsetzen des neuen Exchange-Servers)
Wir haben am 05.02. das Zertifikat für SMTP und IIS getauscht, man sieht aber im Admin-Center und auch über PowerShell, dass das neue Zertifikat nur an den IIS gebunden wurde, bei SMTP wird noch das alte Zertifikat angezeigt, welches Anfang März abläuft. Das Problem mit der Verzögerung ist dort aber noch nicht aufgetreten.
In der Ereignisanzeige gibt es eine Warnung, die erst seit dem 16.02. auftritt. Allerdings nicht in der Häufigkeit, dass sie die dauerhaft verzögerten Zugriffe erklären würde:
Warnung 1050, MExRuntime, MSExchange Extensibility
The execution time of agent „Meeting Message Processing Agent“ exceeded 120000 (meist irgendwas zwischen 105 und 120 Sekunden) milliseconds while handling event „OnCreatedMessage“ for message with InternalMessageId: „Not available“. This is an unusual amount of time for an agent to process a single event. However, Transport will continue processing this message.
Nur als Idee: Vielleicht wird die Warnung auch erst ab einer Zeit von > 100000ms geloggt, das Problem verzögert aber trotzdem dauerhaft die Abarbeitung von Events.
Für Ideen bezüglich weiterer Analysen wäre ich sehr dankbar
Wir erleben derzeit, dass die Mails nicht mehr automatisch zugesetellt werden sondern manuell abgeholt werden müssen.
Aktuelles macOS Outlook. Jeden tag kommt ein User dazu.
Obige Fehlermeldung haben wir nicht. Wir haben 4999,1040, 3025.
Hi,
habe das gleiche Problem bei einem Kunden. Gibt es da neue Erkenntnisse?
Gruß
Marcel
moin,
bei uns wurde nach dem Update auf Server 2019 CU14 und Framework 4.8.1 die w3wp.exe vom Defender als Virus bemängt.
Lt. Frankys letzten Infos sollte man das Verzeichnis ja mitscanner. Wir haben derzeit keine Ausnahmen am Defender hinterlegt.
Gibt es dazu schon neuere Infos?
Microsoft Defender Antivirus has detected malware or other potentially unwanted software. For more information please see the following:https://go.microsoft.com/fwlink/?linkid=37020&name=Exploit:Script/ExchgProxyRequest.A!gen&threatid=2147834423&enterprise=0“ https://go.microsoft.com/fwlink/?linkid=37020&name=Exploit:Script/ExchgProxyRequest.A!gen&threatid=2147834423&enterprise=0 Name: Exploit:Script/ExchgProxyRequest.A!gen
ID: 2147834423 Severity: Severe
Category: Exploit Path: amsi:_\Device\HarddiskVolume4\Windows\System32\inetsrv\w3wp.exe
Detection Origin: Unknown
Detection Type: Concrete
Detection Source: AMSI
User: NT AUTHORITY\SYSTEM
Process Name: C:\Windows\System32\inetsrv\w3wp.exe
Security intelligence Version: AV: 1.405.112.0, AS: 1.405.112.0, NIS: 1.405.112.0
Engine Version: AM: 1.1.24010.10, NIS: 1.1.24010.10
Hoi Chrstian,
Haben Sie die Ursache für den Defender-Catch gefunden?
LG,
Wir haben das auch und wissen auch noch nicht was das ist
CU14 wurde gerade installiert.
Server 2019 (DE) mit Exchange 2019 CU13 (DE). On-Premise
Extended Protection war schon aktiviert.
lief ohne Probleme durch , dauerte aber ca 1,5h
zur info
Bei uns gleiches Szenario. Update lief auch problemlos durch. Die CUs brauchen immer ewig zum installieren, ich meine mich zu erinnern dass die letzten paar auch immer so 1,5h gedauert haben.
Hmm, leider kann ich es nicht durchführen.
„Ein Aufrufziel hat einen Ausnahmefehler verursacht“
Hatte das bisher noch jemand?
Gruß
Max
Hat eigentlich jemand Probleme mit dem Update KB5034768 für Windows-Server 2019? Seither scheint der Exchange 2019 im Maintenance Mode und lässt sich nicht mehr in den aktiven Modus versetzen.
Hallo, der KB Artikel zum CU14 ist scheinbar verschwunden
weder https://support.microsoft.com/en-US/help/5035606
noch https://support.microsoft.com/de-DE/help/5035606
funktionieren noch. Die Downloadseite existiert noch.
Generation Time: 02/15/2024 23:52:06
Version: Exchange 2019 CU12
Build Number: 15.02.1544.004
Not on the latest SU. More Information: https://aka.ms/HC-ExBuilds
Die CU12 passt nicht zur Build nach Update von CU13 auf CU14 ….. Bug?!
Hat jemand ne Idee?
Achtung Update dazu:
HeathChecker.ps1-Update (schon lange auf Server gepeichert) updatet sich nicht richtig. Version bliebt nach diversen AutoUpdates auf Stand 23.04.x zurück.
Aktuelle Version liegt bei 24.02.15.1640. Schon sehen alle Outputs anders aus. Natürlich muss man ganze andere Sachen absichern.
Danke Microsoft – good luck @ all
Was ich nicht recht verstehe, wenn EX 2016 keinen SU bekommt, wäre der dann nicht von der CVE-2024-21410 betroffen, oder heißt es auch dort nicht EP aktivieren und fertig. Wenn dem so wäre, dann wäre der CVE-2024-21410 mit EP beim EX 2019 auch geschlossen oder nicht?
So ist es, steht auch so im Exchange Blog und etwas undeutlich formuliert auch im CVE Text. Das CU14 hat nicht direkt was mit dem CVE zu tun, außer das halt bei der Installation Extended Protection automatisch aktiviert wird, wenn man es nicht per Kommandozeile explizit abwählt.
Heißt, ein System das EP schon aktiviert hat ist von dem CVE schon geschützt.
Danke, hätte ich es auch interpretiert man mir nur nicht ganz sicher.
Sehe ich das richtig, dass Microsoft für Exchange 2016 *kein* Sicherheitsupdate veröffentlicht hat? Der Healthchecker in tagesaktueller Fassung meldet mir weder das Vorhandensein einer Lücke noch ein fehlendes Update.
Es gab doch auch meines Wissens nach im Februar keine Exchange SUs. Hier geht es doch um ein CU und das gibt es für 2016 in der Tat nicht mehr.
Wenn auf dem Server EP aktiviert ist, dann ist die neue Lücke auch dicht.
Es muss nichts extra installiert werden, wir reden „nur“ von der Aktivierung der EP
Danke, Jens, hätte sorgfältiger lesen sollen.
Hat eigentlich schon wer ausprobiert, ob mit dem CU14 wieder Piped-Abfragen in der Shell möglich sind, wenn man die von einem Nicht-Mailbox Server aufruft? Das hatten die ja mit einem vergangenen Update kaputt gemacht, aber ich habe akut in dem KB-Artikel zum CU nichts dazu gefunden.
OK, funktioniert immer noch nicht. Bin mal gespannt, wann die das fixen. Wofür hat man „Management Only“ Tools, wenn man dann doch wieder per Remote auf den eigentlichen Exchange Server muss.
Wir haben bislang nicht alle Voraussetzungen, SSL offloading und kein ssl bridge..
Ändern wir nun um und können dann EP aktivieren..
Mit dieser CVE wird die Nummer nun zu heiß und gleichzeitig sind die anderen Lücken aus 2022 auch geschlossen..
Ich schätze mal das es immer noch eine große Anzahl gibt, die EP nicht aktiviert haben und MS daher nun den Schritt mit der Zwangsaktivierung geht. ( Haben sie vorher ja auch angekündigt)
CU14 wurde gestern installiert.
Server 2019 (DE) mit Exchange 2019 CU13 (DE). On-Premise, kein Hybrid. Extended Protection war schon aktiviert.
Vorher wurde ein Neustart gemacht. Das Setup mäkelte immer noch einen ausständigen Neustart an, also hab ich den Regkey HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\PendingFileRenameOperations gelöscht.
Snapshot wurde im ausgeschalteten Zustand erstellt.
Setup als Admin gestartet. 3rd Party Antivirus Dienst vorher gestoppt.
Lief dann in 20-30 Min (nicht auf die Uhr geschaut, habe zeitgleich auch was anderes gepatcht) durch.
Ist dann klaglos durchgelaufen (zum Glück – bei dem Punkt „Language“ war mir nicht ganz so wohl…) und hat dann nochmal einen Reboot gefordert
Outlook Clients, die online waren, meckern nun wie gewohnt einen Neustart an.
HealthChecker sagt alles OK (bwz. wie vorher)
Mails kommen…
Soweit die Erfahrung einer einzelnen Insel…
Mit ssl offloading oder ssl bridging über eine Sophos mit letsencrypt certs wird das mit der extended protection eher nichts.
Werde das wohl deaktivieren müssen.
Benutze die selbe Konstellation (Sophos WAF + LE) und nutze daher EP auch noch nicht. Es gibt zwar einen Weg aber naja…
https://www.frankysweb.de/sophos-utm-zertifikat-der-waf-mittels-powershell-exportieren-exchange-version/
Tja, dann kauft man sich eben ein Zertifikat und hat das Gepfriemel nur einmal im Jahr, oder man automatisiert es, wie im angegebenen Link. Ohne EP bleibt eine kritische Sicherheitslücke offen. Muss jeder selbst wissen, ob er lieber sicher oder lieber bequem unterwegs ist. ;)