New update for Exchange Server 2019

Microsoft released CU 14 for Exchange Server 2019 yesterday. CU 14 brings these new features:

  • .NET Framework 4.8.1 Support for Windows Server 2022
  • Extended Protection is activated by default, this can be deactivated via a switch in the shell (Attention!)

Support for TLS 1.3 was also planned, but this did not make it into CU 14. The CU 14 can be downloaded here:

As already mentioned, by default the CU 14 activates the Extended Protection. This can lead to problems if the requirements for Extended Protection have not yet been created in the environment. Microsoft has developed Exchange Team Blog published a graphic:

New update for Exchange Server 2019
Qulle: Exchange Team Blog

Anyone who cannot currently use Extended Protection must therefore call up the setup with the parameters from the graphic. However, Extended Protection also seals a new critical vulnerability:

Due to the vulnerability, Extended Protection should therefore be activated.

35 thoughts on “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) ?

    Reply
  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?!

    Reply
  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?

    Reply
  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 ?

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

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

        Reply
  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

    Reply
  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

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

      Reply
  7. Hmm, leider kann ich es nicht durchführen.
    „Ein Aufrufziel hat einen Ausnahmefehler verursacht“
    Hatte das bisher noch jemand?
    Gruß
    Max

    Reply
  8. 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.

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

      Reply
  9. 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?

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

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

    Reply
  11. 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.

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

      Reply
  12. 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)

    Reply
  13. 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…

    Reply
  14. 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.

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

        Reply
      • 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?

        Reply

Leave a Comment