Neue Sicherheitsupdates für Exchange Server (Januar 2022)

by

Microsoft hat neue Sicherheitsupdates für Exchange Server 2013, 2016 und 2019 veröffentlicht. Das Sicherheitsupdate soll die folgenden drei Schwachstellen beheben:

Bei den drei genannten Schwachstellen handelt es sich um Fehler die Remote Code Execution ermöglichen. Die Updates sollten daher möglichst zeitnah installiert werden, auch wenn derzeit noch keine Ausnutzung der Schwachstellen bekannt ist.

Hier können die Updates runtergeladen werden:

  • Exchange Server 2013 CU23
  • Exchange Server 2016 CU21 und CU22
  • Exchange Server 2019 CU10 und CU11

Microsoft liefert wie üblich nur Updates für das aktuelle und das vorherige CU. Exchange Server mit älterem CU sind aber höchstwahrscheinlich ebenfalls von den Schwachstellen betroffen. Wer aktuell noch Exchange Server mit älterem CU betreibt, muss zunächst auf ein aktuelles CU aktualisieren und dann die Sicherheitsupdates installieren.

Da Exchange Server aktuell gerne als Ziel bzw. als Einfallstor für Angriffe genutzt werden, sollte jeder Admin darauf achten, dass Sicherheitsupdates für Exchange Server und auch das Betriebssystem möglichst zeitnah installiert werden.

Das Update behebt auch ein Problem welches es mit dem November Update gegeben hat:

Hier findet sich der entsprechende Eintrag aus dem Exchange Server Team Blog:

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“:

Sicherheitsupdates

Das Update kann 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:

33 thoughts on “Neue Sicherheitsupdates für Exchange Server (Januar 2022)”

  2. Moin,
    bin ich der einzige, bei dem die Security-Updates die Dienste schon bei der Installation deaktiviert haben? Das war doch bisher nicht so, sondern beim rebooten wurde das erledigt. Oder bin ich da schief gewickelt?

    Reply

    • Also ich kenn das nur so, dass die Dienste direkt am Anfang der Installation deaktiviert werden. Zumindest beim EXCH2019. Deswegen mach ich die Installation von Updates des Exchange immer außerhalb der regulären Arbeitszeit.

      Reply

  3. Anhängend an die Boot Loops bei DCs.

    Hat schon jemand die MS Security Updates auf nem Server 2016 mit Exchange 2016 installiert?
    (Also nicht den Exchange Patch).

    Es ist die Rede von:
    KB5009557, KB5009546, KB5009624 und KB5009595

    Fehler:
    – DCs machen alle 15 Minuten einen Reboot
    – HyperV-Hosts können keine VMs mehr starten oder Live-Migration scheitert. Teilweise startet der Hyper-V-Dienst schon nicht.
    – ReFS Dateisysteme sind nur noch als „RAW“ sichtbar.

    –> wir haben unsere Exchange 2016 DBs auf ReFS Datenträgern lagernd.

    Mag zwar sein, dass wir „wie viele“ ein DAG haben, aber ich möchte das nicht erleben, dass meine Datenträger nicht mehr erkannt werden. Keine Ahnung was am Ende die Lösung ist, oder ob ich einen neuen Server aufsetzen muss mit Anlage von 20 Volumes, Mount Points, ….

    Hat da schon jemand Erfahrung? Positiv wie negativ

    Reply

  5. Hallo!

    Bestätige das Problem bei Server 2012R2 DC und auch Server 2012R2 Hyper-V Host. Eine Deinstallation des Updates im abgesicherten Modus hilft. Viel Erfolg mit F8 beim boot in einer VM :) :)

    Bin mir nicht sicher ob 2016-2022 auch betroffen sind.
    Kann noch jemand das Problem am Server 2016-2022 DC / Hyper-V Host bestätigen?

    Die Exchange Updates (2016-2019) liefen bei mir ohne Probleme durch :)

    LG

    Reply

  6. Guten Morgen,

    bei uns gab es heute auf einem 2012 R2 DC einen Bootloop, auch ohne dass ein zweiter DC existiert.
    Installiert wurden folgende Patches: KB5009586, KB5008881, KB5008277.
    Anschließend kam ich bis zum Anmeldebildschirm, konnte mich aber nicht anmelden, da er nach Eingabe des PW nicht weiter wollte. Nach einer kurzen Zeit startetete er dann neu.

    Behoben habe ich das Problem, in dem ich im abgesicherten Modus KB5009586 deinstalliert habe.

    Grüße,
    Matthias.

    Reply

  7. Hi zusammen,

    Security-Update auf Exch 2016 CU22 DAG installiert: keine Probleme.

    Zu den DC-Boot-Loops:
    kenne ich noch von früher vor allem bei 2016 nach diversen CUs wenn die AD auf einer separaten Partition liegt (z.B. bei VMWare SCSI:1:0).
    Abhilfe hier: DSRM booten, Datenträgerverwaltung, die „offline gegangene“ Partition wieder Online schalten und rebooten.
    [hatte mich damals viel Zeit gekostet…, vielleicht hilft die Info dem/der einen oder anderen Kollegen]

    VG
    Benny

    Reply

  8. Hallo Frank,

    dein Link zum Exchange Blog verweist auf deinen eigenen Artikel zu den November Exchange Updates.

    Gruß
    Daniel

    Reply

    • Einen DAG Server hat es bei mir auch erwischt. Die Deinstallation der Patches kb:5009624

      wusa /uninstall /kb:5009624

      half dabei die Partitionen wieder lesbar zu machen. Alle Datenbanken waren aber gestoppt und mit dem Status

      FailedAndSuspended eingebunden.

      Man kann die Datenbanken wie folgt wieder in sync bringen:
      Get-MailboxDatabaseCopyStatus -Server Servername | Resume-MailboxDatabaseCopy

      Hilft das alles nicht, dann muss wohl das Seeding neu durchgeführt werden
      z.B.

      Update-MailboxDatabaseCopy -Identity DBName\Servername -DeleteExistingFiles
      # Dauert aber sehr sehr lange, weil die Datenbank komplett neu kopiert wird

      Reply

  10. Hallo,

    erübrigt sich mit dem Security Update auch das manuelle ausführen des Skriptes bez. des 2022 Bugs?
    Reicht es die Anti Malware Funktion wieder zu aktivieren oder muss das Skript noch ausgeführt werden?

    Reply

  11. die exchange updates sind auf einem eigenständigen server installiert. und die laufen durch. auf diesen servern funktionieren auch die windows updates.

    problematisch sind dieses monat die windows updates wenn sie auf einem domain controller installiert werden sollen. da kommen dann die beschriebenen probleme mit boot loop. also nur auf domain controllern. wird ja hoffentlich keiner einen exchange server direkt am domain controller betreiben.

    Reply

  12. generell scheint es keine gute idee zu sein die patches auf domain controllern zu installieren. nach der installation auf dem ersten dc war noch alles ok. als dann die patches am zweiten draufkamen, gingen die reboot orgien der dcs los.

    bei uns waren es windows server 2012 r2.

    nach der deinstallation von KB5009595 und KB5009624 auf beiden DCs lief wieder alles. Deinstallation war nur möglich, nachdem nur noch ein DC online war.

    der fix

    Behebt ein Windows Server-Problem, bei dem Active Directory-Attribute bei einem LDAP-Änderungsvorgang (Lightweight Directory Access Protocol) mit mehreren bestimmten Attributänderungen nicht ordnungsgemäß geschrieben wurden.

    dürfte wohl nicht so sehr getestet worden sein.

    Exchange Updates waren problemlos

    Reply

    • Hallo MOM20xx,

      kannst du mir kurz erklären ob du die Exchangeupdates meinst oder die Updates der DC’s?
      Ich kann das aus deinem Post nicht ganz herauslesen.

      Hast du Exchange auf einem DC installiert oder auf einem/mehreren eingeständigen Servern?

      Grüße Toni

      Reply

  13. Bei unserem Ex2016 CU21 gibts leider noch Probleme, sowohl über Windows Update als auch „manuelle“ Installation mit elevated shell…

    Reply

  14. Auf einem Win2019, Ex2019 CU11 erfolgreich installiert.
    Domain Controller 2019 hat es zerrissen.
    DC rebooted nach wenigen Minuten nach dem update boot wieder.

    Reply

  16. Bereits zehn Mal installiert (2016 CU22 und 2019 CU11), prinzipiell keine Probleme.

    ABER Panda AD360 im Hardening Modus blockiert schon die Installation des Patches und danach werden ebenfalls Exchange Dateien blockiert, die erst durch deren Prüfung müssen, wenn man sie nicht manuell freischaltet. Nur selbst wenn das nach ein paar Minuten passiert, sind die Dienste trotzdem nicht gestartet. Ich empfehle daher, den Panda erstmal in den beim Erweiterten Schutz in den Audit Modus zu versetzen. Morgen hat sich das Ganze hoffentlich wieder beruhigt. Bisher lief solch ein Patch bei mir immer durch, ohne dass Panda angepasst werden musste.

    Reply

Leave a Comment