Microsoft hat heute neue Sicherheitsupdate für alle unterstützen Exchange Server Versionen veröffentlicht. Microsoft weißt ausdrücklich darauf hin, dass die Updates keinen Fix für die Zero-Day Schwachstellen (ProxyNotShell) enthalten. Die folgenden Schwachstellen werden durch das Sicherheitsupdate behoben, drei der Schwachstellen gelten als kritisch:
Die Updates können hier runtergeladen werden:
Hier findet sich der Artikel auf dem Exchange Team Blog:
Da wie bereits erwähnt die Zero-Day Lücken noch nicht geschlossen wurden, muss der Workaround via URL Rewrite Regel erhalten bleiben. Der String für das Reg-Ex Pattern wurde in der letzten Zeit öfter durch Microsoft angepasst. Dies ist der aktuelle String für die URL-Rewrite Regel:
(?=.*autodiscover)(?=.*powershell)
Eine entsprechende Anleitung zur Konfiguration der URL Rewrite Regel findet sich hier:
Microsoft empfiehlt, dass die Updates zeitnah installiert werden.
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?
Hast du Extended Protection aktiv?
Schau mal hier im Abschnitt „NTLMv1 is not supported when Extended Protection is enabled“:
https://microsoft.github.io/CSS-Exchange/Security/Extended-Protection/
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,
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.
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
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?
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?
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.
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….
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)
Server 2016
CU22
DAG
Security Update ohne Probleme durchgelaufen.
Ex2013 DAG kein Probleme.
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
Klappt der Versand denn bei anderen Servern? Ist der SFP Record richtig in den DNS Einstellungen bei der Domain?
SPF meinte ich
SPF Record scheint in Ordnung. Wir hatten auch noch den Spamfilter des Providers im Verdacht, welcher dann abgeschaltet wurde. Seither erhalten wir folgende Fehlermeldung im Log des Sendeconnectors: „TLS negotiation failed with error IllegalMessage“. Das übergebene Zertifikat ist gültig und es handelt sich um ein Wildcardzertifikat.
Microsoft liefert Updates gegen SSL-/TLS-Probleme durch Windows-Updates
https://www.heise.de/news/Microsoft-liefert-Updates-gegen-SSL-TLS-Probleme-durch-Windows-Updates-7314906.html
Exchange 2019 CU 11 / Server 2019 ohne Probleme
Extended Protection und die URL Rewrite-Regel vorher aktiv
Exchange 2013 (auf Windows Server 2012 R2) alle Updates ohne Probleme installiert. Extended Protection und die URL Rewrite-Regel hatte ich vorher schon aktiv.
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
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?
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.
@Dominik
ESET während der Installation aktiv oder deaktiviert?
war aktiviert :)
Jemand schon auf Exchange 2016 CU 22 erfolgreich gewesen?
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
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.
also nicht über Windows Update?
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 ;)
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.
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.
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.
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)
Hast du auch Virenschutz (Eset?) installiert?
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.
exchange 2016 update:
auf 2 verschiedenen servern totalausfall, dienste starten nciht mehr. Deinstallation fehlgeschlagen. Snapshot wiederherstellung
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.
wurde automatisch aus dem Windows Update installiert.
Warum installierst du automatisch Updates aus Windows Update?
Weitere besondere Software (insbesondere AV) auf den Systemen?
Genug freier Festplattenspeicher?
Ja, Eset Mail security, das wird es vermutlich gewesen sein.
Festplattenspeicher ist genug.
Hast du ESET Update und gleichzeitig ein Windows Update gemacht? Dann geht das System kaputt.
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.
Da fehlen 2 Klammern.
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.
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.
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
Hallo Jens,
laut Blogeintrag wurden nur die Probleme mit der Auto-Archivierung gefixt wenn EP aktiviert ist:
https://techcommunity.microsoft.com/t5/exchange-team-blog/released-october-2022-exchange-server-security-updates/ba-p/3646263
Hallo Mike,
könntest Du kurz auf die Sprünge helfen, wo du die Info gelesen hast? Ich finde es nicht :-)
Danke vorab
Hallo Jens,
unter issues resolved „outlook and compliance related“, nachdem sofern ichs noch korrekt im Kopf habe sonst keine Probleme bekannt waren außer die nichtmehr funktionierende Auto-Archivierung wird das hoffentlich gefixt sein.
Werd das aber morgen nochmal im Lab verifizieren bevor ich die EP auch in Produktivumgebungen aktiviere die Archiving nutzen.
LG
So ist es. Es gibt aktuell einen Workaround, welcher in der aktuellen Fassung des Skripts eingeflossen ist. Details gibt es unter https://microsoft.github.io/CSS-Exchange/Security/Extended-Protection/ unter „Known issues and workarounds“.