Exchange Server: New security updates (October 2022)

Microsoft has released new security updates for all supported Exchange Server versions today. Microsoft expressly points out that the updates no fix for the zero-day vulnerabilities (ProxyNotShell). The following vulnerabilities are fixed by the security update, three of the vulnerabilities are considered critical:

The updates can be downloaded here:

  • Exchange Server 2013 CU23
  • Exchange Server 2016 CU22 and CU23
  • Exchange Server 2019 CU11 and CU12

Here you can find the article on the Exchange Team Blog:

Since, as already mentioned, the zero-day gaps have not yet been closed, the workaround via URL rewrite rule must be retained. The string for the Reg-Ex pattern has recently been modified several times by Microsoft. This is the current string for the URL rewrite rule:

(?=.*autodiscover)(?=.*powershell)

Instructions for configuring the URL rewrite rule can be found here:

Microsoft recommends that the updates are installed promptly.

54 thoughts on “Exchange Server: Neue Sicherheitsupdates (Oktober 2022)”

  1. Moin,

    ich habe gestern das Update auf einem 2016er Exchange installiert und habe heute Probleme mit Outlook.
    Es lässt sich garnicht mehr öffnen (Probleme mit der Exchange Verbindung). Neues Profil anlegen ruft ein Anmeldefenster hervor.
    OWA funktioniert.
    Hat jemand eine Idee?

    Reply
  2. Hallo miteinander,

    ich ärgere mich jetzt schon zwei Tage mit dem Update KB5019077 herum. MSX19, CU12, SU2 (08/22), onprem, VM
    Das Einspielen über Windows-Update schlug fehl, Fehler 1603, MSX-Dienste sind alle deaktiviert und lassen sich auch nicht manuell starten, da sie vom MSX-AD-Topologie dienst abhängig sind der eben auch nicht startet. Der ist aber von Net.TCP Port Sharing Service abhängig, der wiederum gestartet ist.
    Auf reddit gibts noch Hinweise auf .NET4.8-Probleme, fehlenden/falschen SharedWebconfig.config-Dateien (ASP.NET 4 event 1310 sollen darauf hinweisen, die bei mir auftauchen), MS schrieb was von Zugriffsrechten, aber leider komme ich nicht weiter:
    .NET-Repairtool machte was, aber das Problem blieb, Neuinstallation/Reparatur von 4.8, weil schon installiert (höhere Nummer) brachen daher ab;
    Dienste starten nicht (auch über Powershell-Script (Reddit)) nicht
    und eigentlich würde ich eine Neuinstallation vermeiden.
    Frage: Wenn es ohne Eure hilfreichen Ideen doch darauf hinausläuft, ein „.\setup /m:upgrade /IAcceptExchangeServerLicenseTerms“ zu machen, was muß ich ggf. beachten, damit ich nicht komplett alles neu konfigurieren muß (konfig, user, db, etc)?

    Vielen Dank und Euch ein entspanntes WE,

    Reply
  3. Hallo,

    ich validiere aktuell die Extended Protection komplett durch.
    Es gibt eine Konfiguration, wo es einen Bug gibt.
    Wenn man OWA und ECP von Formular auf Windows Auth. und Standard Auth. umstellt, kann man sich auf dem Exchange Server selbst, nicht mehr am ECP und OWA anmelden.

    Von einem anderen Client fkt. es, auch von extern, ebenfalls wenn man dort via Sophos Umkehrauth. konfiguriert hat.

    Hat jemand dieses Problem beobachtet, es muss per Design so sein, weil ein Kunde mit der gleichen Einstellung, hat den gleichen Fehler. Wenn nicht, mache ich einen MS Fall auf.

    Reply
    • Manchmal muss man die Frage aufschreiben, damit einem die Lösung einfällt.

      1. Entweder per ECP/OWA mit dem Servernamen zugreifen, dann geht es auch lokal auf dem Exchange Server.
      2. Oder einen Registry Key setzen, denn ich aus den SharePoint Umfeld kenne: DisableLoopbackCheck = 1

      Reply
  4. Gibt es Informationen oder eine Einschätzung wann ein tatsächliches Update zur Behebung der ProxNotShell Sicherheitslücke seitens Microsoft zu erwarten ist? Könnte das Update bald erscheinen oder dauert es bis zum nächsten regulären Patch Day am 08.11.2022?

    Reply
  5. Ich hatte auch auf einem Exchange 2019 mit Servder 2019 massiv Probleme mit dem Patch. Der erste Versuch üer Windows Update schlug fehl. Danach waren wie beschrieben alle Dienste deaktiviert. Ich habe diese manuell gestartet und den Patch nochmal sauber per Hand installiert. Trotz CMD mit erhöhten Rechten waren wieder alle Dienste auf deaktiviert. Nur manuelles umstellen auf Automatisch brachte dann einen Erfolg. Der andere Exchange Server im DAG hatte keine Probleme.

    Was mich nur irrtiert ist das im ECP immer noch Version 15.2 (1118.7) steht. Bei euch auch so?

    Reply
    • Ich weiß nicht, wie oft ich schon Kunden oder in Foren erklärt habe, dass die Installation per Windows Update (oder WSUS) immer wieder für Überraschungen gut ist und im Zweifel natürlich zusätzliche Schritte notwendig sind. Trotzdem gibts immer wieder Leute die ihr Glück versuchen wollen. ;)

      Im ECP steht schon immer nur die jeweilige Hauptversion (das CU, bzw. früher das Service Pack). Security Patches wurden an der Stelle noch nie angezeigt.

      Reply
  6. Komischerweise funktionieren die „nebenpostfächer“ nicht mehr. Fehler „0x8004010F“ beim Senden Outlook 2019.

    Und ja, ich kenne die Workarounds mit ost / neues Profil anlegen. Das ist nicht die Lösung.

    Bei allen Usern mit mehr als 2 Postfächern auf einem Exchangeserver . (Ex 2016 CU23)

    Wirklich komisch….

    Reply
  7. Ich erhalte beim aktivieren der Extended Protection folgenden Fehler:

    Das Argument für den Parameter „SiteVDirLocations“ kann nicht überprüft werden. Das Argument ist NULL oder leer, oder ein Element der Argument Auflistung enthält einen NULL Wert. Geben Sie eine Auflistung an, die keine NULL-Werte enthält und führen Sie dann den Befehl erneut aus.

    Zeichen 35 in Exchange-Script

    Exchange 2016 auf Server 2012 – 15.01.2507.013 (Oktober 2022 SU Update auf CU 23)

    Reply
  8. Hallo zusammen,
    wir haben seit dem Update (KB5019076) auf dem Exchange 2016 CU23 folgendes Problem. Unsere Mails bleiben in der Warteschlange mit folgender Fehlermeldung hängen: „LED= 451 4.4.395 Target host responded with error. -> 421 4.4.1 Connection timed out“. Der Mailprovider, an den die Mails per SMTP versendet werden sollen weist alle Schuld von sich. Wir haben auch schon versucht, das Update manuell zu deinstallieren (hat nichts gebracht). Komischerweise werden zwischenzeitlich teilweise Mails versendet, danach geht der Exchange aber wieder auf o.g. Fehlermeldung. Im Ereignislog können wir auch nichts ungewöhnliches feststellen.
    Vielleicht hat ja jemand eine Idee!?
    Vielen Dank , Florian

    Reply
  9. Exchange 2013 (auf Windows Server 2012 R2) alle Updates ohne Probleme installiert. Extended Protection und die URL Rewrite-Regel hatte ich vorher schon aktiv.

    Reply
  10. Bei mir lief das Update anscheinend nicht sauber durch. Nun komme kommt “ Fehler beim Datenabruf“ und komme auch nicht mehr drauf.
    Das letzte Windows Update funktionierte ohne Probleme.

    Was nun?

    Viele Grüße

    Reply
  11. Bei mir lief das Update anscheinend nicht sauber durch. Nun komme kommt “ Fehler beim Datenabruf“ und komme auch nicht mehr drauf.
    Das letzte Windows Update funktionierte ohne Probleme.

    Was nun?

    Reply
  12. Exchange 2016 mit CU 23 nach SU Oktober Update auf Version 15.01.2507.013 und Dienste laufen alle.

    Installiert unter Server 2012 R2 mit ESET Mailsecurity 9.0.10009.0 über Windows Update.

    Reply
    • Moin Tob, ja da hab ich das Update installiert – aber noch nicht EP aktiviert, da ich erst alle Server nachziehen möchte bevor ich EP einstelle.
      Die Installation lief aber fehlerfrei.
      Ich deaktiviere bei der Installation von CU & SU immer den lokalen AV

      Grüße

      Reply
  13. Updates liefen hier bisher problemlos!

    manuell:
    1x Exchange 2016 unter Windows Server 2012R2
    1x Exchange 2019 unter Windows Server 2019

    Dazu gut 10 weitere Systeme, die sich letzte Nacht automatisch gepatcht haben.

    Reply
      • Doch alle über Windows Update (die meisten vollautomatisch per Zeitplan nachts), 2 „manuell“, aber auch über Windows Update gestartet. „Manuell“ ist da etwas unglücklich ausgedrückt ;)

        Reply
        • gut, so mache ich es nämlich auch immer. Einfach Windows Update Suche und go. Dann sollte es gehen.

          Habe Exchange 2016 CU 23 auf Server 2012.

  14. Das Update oder was auch immer hat bei uns die „Windows Dienste“ teilweise deaktiviert (anstatt manuell oder automatisch).
    Leider nicht alles im Protokoll erkennbar gewesen.
    Exchange Dienste waren alle deaktiviert und konnten somit auch bei einem Neustart nicht starten oder gestartet werden.

    Nachdem die Dienste wieder entsprechend eingestellt sind läuft alles wieder.

    Reply
    • Hi, kurze Frage. Wurde das Update per .exe oder .cab Datei installiert? Wurde die Datei als Administrator ausgeführt, z.B. über eine als Administrator gestartete cmd? Ich kenne das verhalten nur wenn man das Update nicht als Administrator startet.

      Reply
      • das Update kam von alleine über Windows Update und lies sich bei uns auch nicht deinstallieren (die Deinstallroutine lief 20 min und brach dann ab)

        Reply
        • gleichzeitig Windows Update und gleichzeitig ESET installieren, bringt immer Probleme. Man will sich zwar einen Reboot sparen, aber danach könnte alles kaputt sein. ESET rät auch dringlich davon ab.

        • nein, kein Virenschutz von Drittherstellern – nur Microsoft-Produkte als VM unter VMware. Windows 2019 mit Exchange 2019

        • OK, das ist ja merkwürdig. Ich habe den einen der beiden Server mit deaktiviertem Virenschutz jetzt erfolgreich aktualisieren können (Server 2016, Exchange 2016).

        • Mittlerweile ist auch der andere Server, bei dem das Update mit automatischer Aktualisierung durchgelaufen ist, trotz deaktiviertem automatischen Update, erneut automatisch gepatcht worden. Dieses mal jedoch ohne Probleme.

  15. exchange 2016 update:
    auf 2 verschiedenen servern totalausfall, dienste starten nciht mehr. Deinstallation fehlgeschlagen. Snapshot wiederherstellung

    Reply
    • Hi, kurze Frage. Wurde das Update per .exe oder .cab Datei installiert? Wurde die Datei als Administrator ausgeführt, z.B. über eine als Administrator gestartete cmd? Ich kenne das verhalten nur wenn man das Update nicht als Administrator startet.

      Reply
  16. Das mit =.*autodiscover)(?=.*powershell funktionierte bei mit nicht.
    Outlook konnt scih nicht mehr mit demExcahnge Server verbinden und bekam
    ein Fehhlermeldung, dass das autodiscover-Zertifikat nicht gültig ist.

    Reply
      • das ist richtig, das kam nur vom copy/paste hier, in der regel sollte es aber richtig gewesen sein, da ich sie gelöscht
        hatte kann ich es nicht mehr überprüfen.
        habe danach den patch von MS ausgeführt die erstellte regel war die selbe, danach lief es ohne probleme.
        war wahrscheinlich doch wohl eine fehlerhafte eingabe von mir.

        Reply
  17. Hinweis bei DAGs:
    Ich hatte bei uns gerade das Problem, dass die Mitigations auf allen DAG-Membern erst entfernt und der IIS-Dienst neugestartet werden musste, bevor ein DAG-Member in den Wartungsmodus geschaltet werden kann.
    Ansonsten funktionierte der Redirect der Clientverbindungen nicht.

    Eingespielt war die aktuelle MS-Regel per EMS.

    Reply
  18. Hallo zusammen,

    wenn ich das richtig sehe, dann sind es alles CVEs aus August mit der Aktivierung von EP?

    Bin gerade etwas irritiert was nun der Unterschied zum August/Oktober ist

    Reply

Leave a Comment