Neues Update für Exchange Server 2019

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:

Neues Update für Exchange Server 2019
Qulle: Exchange Team Blog

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.

35 Gedanken zu „Neues Update für Exchange Server 2019“

  1. 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) ?

    Antworten
  2. 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?!

    Antworten
  3. 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?

    Antworten
  4. 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 ?

    Antworten
    • 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

      Antworten
      • 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.

        Antworten
  5. 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=0https://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

    Antworten
  6. 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

    Antworten
    • 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.

      Antworten
  7. 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.

    Antworten
    • 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

      Antworten
  8. 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?

    Antworten
    • 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.

      Antworten
  9. 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.

    Antworten
  10. 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.

    Antworten
    • 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.

      Antworten
  11. 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)

    Antworten
  12. 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…

    Antworten
  13. 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.

    Antworten
      • 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. ;)

        Antworten
      • Ganz ehrlich, ich kapiere das nicht: Lizenzen und CALS um eine Sophos, einen Exchange, ein AD etc zu betreiben vorhanden. Sowas profanes aber wichtiges, wie ein Sectigo Postive SSL bei LeaderSSL z.b. 5 Jahre für Summe 85 EUR netto oder gleich ein Wildcard mit 5 Jahre Laufzeit für ein paar hundert EUR, das gibt das Budget dann nicht mehr her, und die schweineteure und sensible Umgebung muss mit solchen LE Frickeleien ans laufen gebracht und gehalten werden?

        Antworten

Schreibe einen Kommentar