Microsoft hat neue Sicherheitsupdates für alle Exchange Server Versionen (2013 – 2019) veröffentlicht. Es dürfte sich dabei um die Beseitigung der Schwachstellen handeln, welche beim Pwn2Own 2021 benutzt wurden, um Exchange Server zu attackieren. Die folgenden Schwachstellen werden behoben:
Hier mal eine Beschreibung von der Pwn2Own Webseite, vermutlich wird genau diese Schwachstelle nun behoben:
The DEVCORE team combined an authentication bypass and a local privilege escalation to complete take over the Exchange server.
Team Viettel successfully demonstrated their code execution on the Exchange server, but some of the bugs they used in their exploit chain had been previously reported in the contest. This counts as a partial win but does get them 7.5 Master of Pwn points.
Qeuelle: https://www.zerodayinitiative.com/blog/2021/4/2/pwn2own-2021-schedule-and-live-results
Die verfügbaren Updates sollten möglichst zeitnah eingespielt werden. Aktuell gibt es noch keine aktiven Exploits, aber das wird sich vermutlich mit der Verfügbarkeit der Updates schnell ändern, da durch die Updates auch die Sicherheitslücken öffentlich werden. Ein Update Desaster wie kürzlich beim HAFNIUM Exploit wollen wir doch alle gerne vermeiden. Ein kleiner Vorteil ist jetzt nun das hoffentlich alle Exchange Server schon auf einem aktuellen Patch Level sind.
Die Updates finden sich hier:
Hier wird einmal der Update Pfad für die Installation der April Updates deutlich:
Hier findet sich noch ein Beitrag des Microsoft Security Response Center:
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“:
Alternativ kann das Update 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:
Update 14.04.21: Die Schwachstellen welche beim Pwn2Own benutzt wurden, sind durch diese Updates noch nicht behoben worden. Bei den hier genannten Schwachstellen handelt es sich um andere Sicherheitslücken. Es werden also wahrscheinlich noch weitere Updates in der nächsten Zeit folgen.
Hallo,
uns ist aufgefallen, dass im Exchange 2016 entweder nach dem Update auf CU20 oder nach dem dazu passenden Sicherheitsupdate die Outlook-Suche im Online-Modus wieder nur 250 Ergebnisse liefert.
Die Anpassung „MaxHitsForFullTextIndexSearches“ in der Microsoft.Exchange.Store.Worker.exe.config
und das Deaktivieren der Outlook-Option „Suchläufe durch Begrenzung der Anzahl angezeigter Ergebniss beschleunigen“ hat leider keine Besserung ergeben. Es werden immer nur noch 250 Ergebnisse angezeigt.
Es findet sich auch ein Hinweis, dass sich irgendetwas mit dem CU20 gändert hat:
5001189 Postfach-Überwachungsprotokollsuchen und Outlook beide an MaxHitsForFullTextIndexSearches in Exchange Server 2019 und 2016 gebunden
https://support.microsoft.com/de-de/topic/postfach-%C3%BCberwachungsprotokollsuchen-und-outlook-beide-an-maxhitsforfulltextindexsearches-in-exchange-server-2019-und-2016-gebunden-a3b9b190-57f5-4b15-a426-7edfbedcbd53
Leider verstehe ich den Hinweis nicht so ganz.
Wir haben diese Beobachtung auf mehreren Exchange 2016 Servern und in allen Outlook Version 2010,2013,2016 machen können.
Hat jemand anders auch dieses Problem bemerkt und evtl. sogar eine Lösung parat?
Grüße,
Jörg
Hallo Jörg,
lies dir mal den originalen englischen Beitrag durch. Siehe https://support.microsoft.com/en-us/topic/mailbox-audit-log-searches-and-outlook-both-tied-to-maxhitsforfulltextindexsearches-in-exchange-server-2019-and-2016-a3b9b190-57f5-4b15-a426-7edfbedcbd53
Der deutsche ist eine maschinelle Übersetzung und dementsprechend nicht verständlich.
Wenn „ResultSize“ größer ist als die Anzahl an Ereignissen, dann wird der Wert von „ResultSize“ nur berücksichtigt, wenn der Parameter „MaxHitsForFullTextIndexSearches“ in den Einstellungen nicht verändert wurde.
Wurde für „MaxHitsForFullTextIndexSearches“ ein Wert festgelegt, so wird „ResultSize“ auf diesen Wert begrenzt.
Das war das Verhalten vor CU20.
Mit CU20 sollte der Wert von „ResultSize“ Berücksichtigung finden unabhängig der Einstellung von „MaxHitsForFullTextIndexSearches“. So unterstützen die Outlook Suchergebnisse und der Befehl „Search-MailboxAuditLog -ResultSize“ nun unterschiedliche Einstellungen und kommen sich nicht mehr ins Gehege.
Prüft also eure eingestellten Werte für die Outlook Suchergebnisse. Wenn du willst, dass die Outlook Suchergebnisse mehr als 250 Ergebnisse liefert, dann muss du den Parameter der Outlook Suchergebnisse ändern. Dieser hat mit CU20 keinen Einfluss mehr auf „Resultsize“. Der Parameter „MaxHitsForFullTextIndexSearches“ hat auch keinen Einfluss mehr auf „Resultsize“.
Hallo Alex,
vielen Dank für die Antwort. Leider habe ich es wohl immer noch nicht verstanden. Der Wert „ResultSize“, welchen man wohl mit Search-MailboxAuditLog -ResultSize ändern kann, wurde nicht verändert.
Evtl. gibt es auch noch einen weiteren Wert – Du sprichst vom „Parameter für Outlook-Suchergebnisse“. Ich kenne nur die Beschränkung in Outlook selbst: Optionen/Suchen/Suchläufer durch Begrenzung der Anzahl angezeigter Ergebnisse beschleunigen – welches nicht angehakt ist . Findet sich der Parameter für die Outlook-Suchergebnisse auf dem Client oder auf dem Exchange-Server?
Grüße,
Jörg
Hallo miteinander,
die überwiegend meisten Admins haben sich nicht nur um Exchange zu kümmern, sondern um einen ganzen Zoo von Servern und PCs. Da ist es geradezu eine Katastrophe wie Microsoft seine (unliebsame) On-prem-Kundschaft mit verkorkster Software, verbogenen Patches und grauenhaftem Support drangsaliert. Patch-Strategie als Russisch-Roulette: Wenn alles gut geht wirst du mit dem Normalzustand belohnt (ein sicheres System), hast du Pech ist das Mailsystem deines Dienstherren futsch und deine Reputation und dein Nervenkostüm gleich mit. Also rette sich wer kann in die Cloud, wo, wen wundert es noch, solcherlei Probleme ein Fremdwort sind. Als Admin habe ich das aber nicht zu entscheiden, ich kann mich nur selbst schützen mit Backup, Backup, Backup und wenn es geht Snapshot, dann bleibt der Puls unten, wenn etwas schief geht. Um so mehr ist dieser Blog ein Segen für alle unschuldig gestraften Exchange-Admins. Ich habe meinem ersten (von 4) Exchange 2016CU20-Server das April-Update verpasst und es ging gut (über Admin-Shell). Dank Euch allen für Eure Erfahrungsberichte.
Moin Heiner,
Beeile dich mit den April-Updates… die ersten Proof of Concepts dazu sind draußen. Es dürfte nicht mehr lange dauern bis diese eingesetzt werden. Du willst doch kein zweites Hafnium bei dir, oder?
Ehrlich gesagt würde ich nie eine On-Prem Installation ohne DAG in Betracht ziehen. Natürlich sind das Extra Kosten am Anfang und etwas mehr Wartungsaufwand im Tagesgeschäft. Aber du entkommst einer Menge Probleme dadurch. Und wenn dein Kunde das nicht einsieht, dann hat er auch kein Exchange On-Prem verdient. Dann gleich in die Cloud.
Cu fehlerhalt oder Patches fehlerhaft? Einfach den Server aus dem letzten Backup wiederherstellen und dann mit dem DAG den Datenstand zurück synchronisieren. Haben wir letztens bei der Hafnium Geschichte gemacht. Anstelle den Server zu säubern haben wir den geopfert. Somit waren wir sicher, dass da nix zurück blieb. Wir hatten keine Downtime. Aber einiges an Aufwand um zu prüfen ob ungebetener Besuch sich ins Netz verbreitet hatte.
Einen einzelnen Exchange Server bei einem Kunden zu betreiben erfordert in der Tat ein sehr starkes Nervenkstüm. Vor allem aber kannst du sehr schnell in der Falle des Service Level Agreement mit zugesicherten Uptime laufen… wir haben mal Probleme gehabt da hat es eine Woche gedauert bis wir diese gelöst hatten… ohne den DAG hätte mich der Kunde erwürgt… dank des DAG hatte er aber während der gesamten Woche seine Emails weiterhin.
Backups kann ich auch nur beipflichten… wir machen vor jeder CU ein Gesamtbackup von jedem Server.
Snapshots sehe ich kritischer… ich habe da schon richtig Probleme bei der Wiederherstellung gehabt… seitdem werden nur Backups bei ausgeschalteten Server gemacht. Auf Snapshots verzichte ich aktuell.
Ich kann der Aussage nur beipflichten das dieser Blog für jeden Exchange-Admin ein Segen ist.
Hallo Alex,
danke für Dein Statement zu DAG! Ich habe bisher immer einen riesen Bogen darum gemacht, da unsere Kundensysteme ziemlich überschaubar sind. Da sind doppelte Lizenzkosten und Rechner-Ressourcen oft schwer zu vermitteln. Der Ansatz, dass man im Zweifel auch mal einen Server ohne größere Downtime opfern kann, ist sehr elegant (wenn z.B. eine Kompromittierung länger nicht bemerkt wurde und das letzte saubere Backup zu lange zurück liegt). In Zukunft werde ich das auf jeden Fall mit in Betracht ziehen, wenn der Kunde onprem bleiben will und man im worst case nicht „erwürgt“ werden möchte. Beim Kunden ist es immer so mit das auffälligste und dramatischste, wenn E-Mail nicht geht und gefühlt jede Minute kommt eine Anfrage, wann denn wieder gearbeitet werden kann. Dann hat man meist gleich drei dicke Bretter gleichzeitig zu bohren: Den Kunden beruhigen, das Problem zu lösen und für die Zwischenzeit ein Workaround zu finden.
Danke für deinen Beitrag T. Beyer!
Das hatte ich auch noch nicht gehört.
Auf einem Server 2012 + DAG 2013 CU23 lief es ohne weitere Probleme.
Hallo Zusammen,
ich möchte hier meine heutige Erfahrung mit diesem Update doch mal allgemein mitteilen, vielleicht hat der ein oder andere ähnliche Probleme. Betrifft Server 2016 mit Exchange 2016cu20 – nach scheinbar erfolgreicher Installation am 13.4. durch Windows-Update kam es ein paar Tage später zum Totalausfall, weil der Server zur Ansicht kam, dass das Update zu installieren sei und dabei fehlschlug.
Als Ergebnis blieben alle Exchange Dienste, der IIS, die Remoteregistrierung und WinMgmnt deaktiviert, sodass der Server praktisch tot war.
Nach Ausschluss eines Hackereingriffs konnte die Ursache mit dieser Lösung (von 2018!) gefunden und der Exchange reaktiviert werden: https://www.iph.ch/wissenswertes/2018/3/22/exchange-wiederherstellung-nach-fehlerhafter-installation-eines-sicherheitspatches
Offenbar stolpert das Update über eine nicht vorhandene Funktion zur Steuerung der Dienste und hinterlässt beim Abbruch den Server mit deaktivierten Diensten. Kurz beschrieben, habe ich exakt wie im Link dargestellt die fehlende Funktion mit dem Powershell Script simuliert, sodass das Update sauber durchgelaufen ist und tatsächlich der Exchange jetzt wieder normal läuft.
Ich finde es unglaublich, dass ein so zentrales Update einen Server im Fehlerfall unbrauchbar hinterlässt aber die Ursache offenbar schon länger bekannt sein muss. Meine einzige Erklärung ist die, dass das Update mit so heißer Nadel gestrickt wurde, dass sowas in Kauf genommen wird, damit nicht erneut eine Katastrophe passiert wie im März.
Moin,
genau aus diesen Gründen haben wir keine automatischen Updates für unsere Exchange Systeme am laufen. Wir patchen immer manuell. Ist zwar etwas aufwendiger, aber dadurch gehen wir genau solchen Problemen aus dem Weg.
Das Problem was ihr gehabt habt ist ein rekurrentes Problem. Es ist nicht das erste Mal, das etwas beim automatischen Patchen schief läuft. Seht es positiv. Es gab gleich eine Lösung und ihr musstet nicht selbst drauf kommen.
Gruß
Tja, das Update war keineswegs automatisch, sondern selbstverständlich manuell angestossen und schien ja ordentlich durchgelaufen zu sein. Keine Fehler, Versionsnummern korrekt, etc…
Der dicke Hund kam Tage später, als doch der Windowsd Installer startete, wahrscheinlich vom installierten Acrobat Reader der sich selbst darüber aktualisiert. Dabei hat der Windows Installer nochmal das Exchange Update begonnen, für mich ganz klar ein Fehler von Microsoft die das Update wohl so heiß gestrickt haben, dass irgendein Flag nicht richtig gesetzt war.
Nun ja, „ist nochmal gut gegangen“ wie so oft ;-) und jetzt habe ich hoffentlich alle Updateautomatiken im Server gestoppt.
Ich meinte natürlich die automatische Updatefunktion… diese ist bei unseren Exchange Servern auf manuell gestellt.
Was macht ein Adobe Reader auf einem Exchange Server? :)
Hallo Zusammen,
wie haltet ihr das generell mit dem Patching der Exchange’s.
Seid ihr schon voller „Vorfreude“ und installiert direkt nach Release das neuste CU, oder wartet ihr eine CU ab (bedingt evntl. Bugs) und installiert die Patches manuell? :-)
Danke & Viele Grüße!
Hallo,
wir warten normal für unsere 2016er DAG immer 4-5 Wochen. Lockdown bedingt war der PDF Bug im OWA etwas lästig für die Kollegen, so haben wir das CU20 sofort installiert.
Gruss
Moin,
kommt auf den Inhalt der CU an. Wenn die CU keine Sicherheitspatches beinhaltet die als kritisch gelten, dann wird so 2-3 Wochen gewartet um Feedback über die Stabilität zu haben. Dann wird aufgespielt.
Wenn in der CU Sicherheitsupdates sind die kritisch sind, dann erfolgt die Installation binnen 1-2 Werktage nach kurzen Test auf ein Backup.
Wir haben auch einen DAG und können uns somit den Luxus leisten einen Server zu opfern und aus Backups wiederherzustellen wenn nötig. Das Backup kann ja auch ein paar Wochen alt sein, da wir ja über den DAG die Email Daten zurücksynchronisieren können. Das war für Hafnium ganz gut, weil wir da ein Backup aus Dezember nehmen konnten, also von vor der Zeit wo die Lücke genutzt wurde. Unsere anderen Server sind mit den Webservices nicht von außen erreichbar.
Wir patchen immer manuell. Bei einem DAG bietet es sich an.
Gruß
Hallo zusammen,
nach dem Erscheinen haben wir gleich das Update auf unsere Exchange DAG angewendet, mit dem tollen Nebeneffekt, dass per Remote Powershell bestimmte Teile unserer Powershell Admin-Scripts nicht mehr funktionieren. Nach und nach häuften sich im Exchange Blog auch die Rückmeldungen von Benutzern von „PRTG“, dass auch deren Scripte zur Abfrage von Mailboxgrößen etc. nicht mehr wie gewünscht funktionieren. Scheinbar hat Microsoft hier ohne Vorankündigung etwas geändert. Jetzt einige Tage nach der Herausgabe des Updates wurde auch mal der Release Blog-Eintrag angepasst:
After application of the Exchange Server April security update CMDlets executed against the Exchange Management Console using an invoked runspace might fail with the following error message:
The syntax is not supported by this runspace. This can occur if the runspace is in no-language mode.
This behavior is expected; please change any code using .AddScript() to use .AddCommand() for continued compatibility.
Ein bisschen mehr Info (neben der Info, dass künftig bestimmte Dinge nicht mehr gehen werden) wie man seine Powershell-Scripts jetzt am besten umbauen soll wäre ja zu viel verlangt, oder?
VG,
Uwe
Hallo Uwe,
also aktuell sollte nicht viel von Microsoft erwartet werden. Spätestens mit Hafnium wurde klar wie wichtig die Kundengruppe ist, welche Exchange vor Ort betreibt.
Bedingt durch die immer schneller auftauchenden gravierenden Schwachstellen bei Exchange 2013 / 2016 / 2019 dürfte Microsoft aktuell eher fieberhaft versuchen die Schwachstellen die sie seit Jahren übersehen haben zu schließen. Und wenn es bedeutet an bestimmten Stellen was zu ändern, dann wird es einfach umgesetzt. Egal ob es dann für dritte Konsequenzen hat.
Vor allem sind ja die Lücken aus dem Pwn2Own 2021 wohl noch offen. Da darf man nur hoffen, dass diese nicht bis zum Patch vorher öffentlich werden. Sonst droht uns wahrscheinlich ein Hafnium reloaded.
Gruß
Gruß
@GeroK
Prüfe doch mal folgendes
get-adpermission „“ | select user,extendedrights | where {$_.extendedrights -like „Ms-Exch-SMTP-Accept-Any-Recipient“}
Ausgabe:
User ExtendedRights
—- ————–
NT-AUTORITÄT\ANONYMOUS-ANMELDUNG {ms-Exch-SMTP-Accept-Any-Recipient}
Die Berechtigung setzen, falls nicht vorhanden:
Get-ReceiveConnector „“ | Add-ADPermission -User „NT-Autorität\Anonymous-Anmeldung“ -ExtendedRights „Ms-Exch-SMTP-Accept-Any-Recipient“
@GeroK
ah jetzt sehe ich, dass du mittels User sendest. Dann vergiss was ich geschrieben habe.
Trotzdem Danke für die Antwort ;)
Aktuell geht es wieder. Nur verstehe ich nicht warum was mich etwas wurmt….
Leider gibt es jetzt schon wieder diverse andere Themen und ich habe keine Zeit da weiter zu suchen.
Ist auf irgendwann später verschoben :/
2 Exchange 2013 in DAG inkl. Server 2012R2 ohne Probleme durchgelaufen
@Christian
Danke für die Antwort :)
Mein Kopf raucht… Ich versuche seit 2 Tagen eine saubere Lösung dafür zu finden, habe zig Technet Artikel gelesen usw.
Wobei ich immer noch nicht verstehe was genau sich geändert hat das es jetzt nicht mehr funktioniert (hat)….
Wenn ich mit deinem Befehl einen Testmail verschicke im Kontext des Users der in der Software eingetragen ist geht es intern aber extern nicht. Da kommt „Unable to relay recipient in non-accepted domain“.
Ich habe aber im Forum einen Thread dazu erstellt:
https://www.frankysweb.de/community/exchange2016/external-relay-mit-mehreren-absendern-ueber-einen-client/
VG!
Gero
@Gero
Hi,
haben wir auch. Geht aber alles wie vorher. Mach auf den entsprechenden Server die PS auf und schicke den Befehl ab:
send-mailmessage -to „“ -from „“ -subject „Testmail!“ -smtpserver
Klappt das?
Nach dem Upadate via Windows Update /ecp beim Anmelden mit admin$@foo.bar Fehlermeldung „Cannot serialize context“ Anmeldung mit admin@foo.bar funktioniert aber.
Winsrv 2016, Exchange2016 CU19 – ansonsten keine Probleme
Ist bekannt.
Wenn du im Thread bei Microsoft zum Update gehst, dann wird von anderen Usern auch auf das Problem hingewiesen.
Das Problem ist das $ Zeichen.
Aktuell gibt es wohl noch keine Lösung. Am besten du schaust bei Microsoft im Thread zum Exchange Patch rein. Siehe https://techcommunity.microsoft.com/t5/exchange-team-blog/released-april-2021-exchange-server-security-updates/ba-p/2254617
Hallo zusammen,
die Aktualisierung lief auf diversen Exchange 2016 CU20 problemlos und fehlerfrei durch.
Gerade habe ich bei borncity folgendes gelesen:
„An dieser Stelle noch ein kurzer Hinweis. Ich hatte ja im Blog-Beitrag Vorwarnung: 0-Day-Schwachstellen, ist das nächste Exchange-Drama im Anrollen bereits den Hinweise gegeben, dass auf der Pwn2Own 2021 Hackerkonferenz einige Schwachstellen in Exchange ausgenutzt werden konnte. Meine Vermutung, dass diese Schwachstellen im Rahmen eines Sonderupdates zum 13. April 2021 geschlossen werden, ist aber unzutreffend.
Die RCE-Schwachstellen CVE-2021-28480, CVE-2021-28481, CVE-2021-28482 und CVE-2021-28483 wurden von der National Security Agency (NSA) gemeldet. Ich gehe daher davon aus, dass spätestens im Mai 2021 ein weiteres Sicherheitsupdate für Exchange Server kommen dürfte.“
https://www.borncity.com/blog/2021/04/15/exchange-update-fehler-und-infos-13-april-2021/
Kann dies irgendwie validiert werden? Ist das korrekt?
Beim BSI steht nach wie vor drauf das die Updates die Lücken schließen würden.
https://www.bsi.bund.de/SharedDocs/Cybersicherheitswarnungen/DE/2021/2021-207541-1032.pdf;jsessionid=539A45EF58454652A98DB7C5E9C99F23.internet471?__blob=publicationFile&v=2
Viele Grüße,
Carsten
Win2012, E2016 mit DAG, Hybrid
SUpdates 4-2012, Cu20 + Exchange SecUpdate
Bisher keine Probleme festgestellt.
Hallo zusammen,
hat sich mit dem Exchange Update irgendetwas an den Empfangsconnectoren bzgl. Authentifizierung geändert?
Wir haben hier so „spezielle“ Software die über SMTP mit Auththentifizierung (AD User) Mails nach extern verschickt.
Seit Mittwoch geht das nicht mehr. Updates habe ich Dienstag Abend installiert. Da drängt sich ein Zusammenhang auf…. :/
VG!
Gero
Hallo, bei meinen Exchangern 2016 OS und Exchange 2016 CU19 bleibt ein Server einfach seit über 1h hängen „Getting Windows ready Don’t turn off your computer“ hat das auch jemand?
Hallo Zusammen,
das Exchange Security Update habe ich auf allen unseren Exchange Servern (2013 CU23 und 2019 CU8) über den WSUS reibungslos installiert.
Normalerweise warte ich immer eine Woche mit den Betriebssystem Monats-Updates da es da ja öfter auch zu Problemen kommt.
Sollte ich die (KB5001382, KB5001393, KB5001403, KB4601275) jetzt sofort auch installieren oder kann ich die später installieren?
Viele Grüße
Birgit
Wir haben gestern Abend unseren Exchange 2016 CU20 unter Windows Server 2012 R2 geupdated. Zuerst das monatliche Windows Update, anschließend das Exchange Security Update manuell. Bis auf die Standard-Fehler, die Exchange gefühlt dauerhaft ins Log bläst, ist uns nichts aufgefallen. Dienste laufen und bisher gab es von den Usern (800 an der Zahl) keine Beschwerden.
Danke für den Hinweis!
Schönen Donnerstag zusammen.
VG John
Hallo zusammen,
bei uns (Exchange 2016CU19) lief das Update auch soweit erfolgreich durch (gestartet in Admin Console), gestern zwischen 12-13h.
Seit heute 9 Uhr haben wir auf einmal keinen Zugriff mehr auf die öffentlichen Ordner (Meldung: Outlook versucht eine Verbindung herzustellen).
Irgendwelche Ideen?
Thx
Marcus
Installation auf EX 2013 mit elevated Shell lief ebenfalls problemlos durch! Danke Frank!
Nach dem erfolgreichen Update KB5001779 ging für einen Exchange 2016 CU20 OWA und ECP nicht mehr,
Für OWA ist das Problem gewesen das er im Verzeichnis \Program Files\Microsoft\Exchange Server\V15\ClientAccess\Owa\prem\15.1.2242.8 keine Daten hatte – Notlösung war die Daten aus dem Ordner 15.1.2242.4 zu kopieren
für ECP ähnliches Problem: hier fehlen ganz viele Daten in \Program Files\Microsoft\Exchange Server\V15\ClientAccess\ecp\15.1.2242.8 – auch hier wurden die Daten aus dem Ordner 15.1.2242.4 als Notlösung kopiert.
Heute abend wird nochmal ein Update KB5001779 versucht, mal sehen ob dieses dann die Dateien neu schreibt
Hatte das selbe Problem, mal wieder nach den Updates.
Führ das Script UpdateCas.ps1 aus das im „Exchangeserver/V1X/Bin“ Order liegt. Das kopiert die Dateien aus den „Current“ Ordnern „ClientAccess\owa\Current“ nach „ClientAccess\owa\15.1.2242.8“ und „ClientAccess\owa\Current2\version“ nach „ClientAccess\owa\prem\15.1.2242.8“. Dann hast du die richtigen Dateien der neuen Version und OWA und ECP sollten wieder gehen.
Keine Ahnung warum MS es nicht gebacken bekomt, die Dateien direkt zu kopieren.
Same here. Musste beim EXCH 2019 CU9 nach dem Update das ECP und das OWA wiederherstellen. Ging mit dem Script und der Anleitung zum Ändern der Pfade wie hier:
https://www.frankysweb.de/exchange-2016-serverfehler-in-anwendung-owa-und-oder-ecp/
Nach Neustart des IIS klappt es wieder. Schade, dass man das jetzt bei jedem CU oder Sicherheitsupdate so fahren muss.
Hallo
habe gestern Abend das Update auf einem Exchange Server 2016 CU20 ohne Probleme installiert.
Danke für den Blog-Beitrag!
Hallo nachdem der Neustart und die Updates installiert wurden, können sie keine Clients mehr am Server anmelden.
Outlook wird getrennt. Owa funktioniert hat aber keine aktuellen Daten.
Gruß Frank
Setze mal :
Set-ExecusionPolicy Unrestricted
nach Installations-Erfolg UND Neustart aber wieder auf RemoteSigned
sollte helfen. Auch den Virenwächter deaktivieren – für die Zeit der Installation. (Vermutlich steht es bei Dir sogar auf „Restricted“ )
Ich denke du wolltest mir helfen und hast das auch erfolgreich getan !!! Ich habe den Walt vor lauter Bäumen nicht mehr gesehen.
Viele Checks in den letzten Wochen gepaart mit neuen Passwörtern … Updates mache ich natürlich immer so, was gestern passiert ist kann ich mir nicht erklären, macht ggf das Alter.
Danke noch einmal !!!!
Gruß thomas
Ja gern geschehen – war schon spät – daher so konfus geschrieben :)
Geht uns hier glaube im Moment allen so.
Hallo Installation Exchange 2016 update auf CU 20 bleibt bei Punkt 17 3 % hängen EAC funktioniert
ProductVersion FileVersion FileName
————– ———– ——–
15.01.2242.004 15.01.2242.004 C:\Program Files\Microsoft\Exchange Server\V15\bin\ExSetup.exe
hatte das schon jemand
Danke Frank
Installation auf Exchange 2013, Server 2012 r2 mit elevated cmd lief bei deaktiviertem Sophos Intercept X & EDR auf Anhieb durch
Ganz komisch bei mir.
Exchange 2016 Cu 19 auf CU 20 kein Problem bei der Installation, beim einspielen vin diesem Patch bekomme ich folgende Fehlermeldung:
The user who’s currently logged on doesn’t have sufficient permissions to install this package. You need at least Exchange Server Administrator permissions on the current computer to complete this task.
Rechtemäßig sieht das eigentlich OK aus, zumal das installieren der CU 20 auch keine Probleme verursacht hat….
Hätte jemand eine Idee ?
Ich habe den Fehler bei einen SU für Exchange 2016 CU23.
Fehlerursache war ein selbstgeschriebenes Profile, dass von einen Netzlaufwerk geladen wurde und dabei auch eine zusätzliche ps1 Datei dotsourced hat.
Hi,
hatten bei zwei Servern das Problem, dass der Patch zwar installiert wurde aber die Dienste nicht aktiviert wurden (laut infos soll es sich um das „cmd als admin“ problem handeln, bin mir aber relativ sicher, dass es aus der admin cmd war)
Wie Thinky schrieb: exchange dienste wieder auf automatisch stellen.
Aber auch wichtig:
bei uns waren die Dienste
Microsoft-Filteranwendungsdienst
WWW-Publishingdienst
ebenfalls auf deaktiviert.
Diese wieder auf Automatisch stellen und dann starten hatte das Problem behoben.
Bei einem Kundenserver (Server 2012R2, Exchange 2013 CU23, letzte Updates drauf) brach die Installation über Windows Updates ab. Exchange Dienste waren dann deaktiviert.
Lösung: Alle Dienste wieder auf automatisch gesetzt, System neu gestartet, Update heruntergeladen und ausgeführt (cmd als Admin!)
Lief dann einwandfrei durch.
Hallo @ll –
wenn das Update klappt, steht als Version unter
Get-Command Exsetup.exe | ForEach {$_.FileversionInfo}
CU9 = 15.02.0858.010
CU8 = 15.02.0792.013
CU19 = 15.01.2176.012
CU20 = 15.01.2242.008
Bei mir hat ein Server beim Neustart das Update wieder deinstalliert – ein gemeiner Trick !
Viele Grüße aus Berlin Jens
Hallo,
hab es grade auf dem ersten Server (Win2019 Exch2019, CU9) installiert. Danach hat sich leider die ECP zerschossen. Anmeldung und OWA funktioniert weiterhin beim Laden der der ECP kommt aber ein Laufzeitfehler:
„
“
Ist schon jemand so etwas aufgefallen?
Schöne Grüße aus Berlin
Huch, da hat sich die Fehlermeldung aufgelöst (habe mal die entfernt):
!– Web.Config Configuration File —
configuration
system.web
customErrors mode=“Off“/
/system.web
/configuration
An dieser Stelle möchte ich einfach mal ein herzliches DANKE an Franky für seine Mühen sagen!!!
Gestern Abend zuerst die April Updates installiert und danach manuell über „Elevated Shell“ mit Admin-Rechten das Security Update manuell installiert.
Alles reibungslos funktioniert.
Win 2012 R2 | Exchange 2013 CU23
Danke für den Blog-Beitrag!
@Gernot
ja so ist es – es wird bei mir die Buildnummer CU23: 15.0.1497.015 angezeigt.
Eomt kenn vermutlich den letzten Stand noch nicht und …
Sollte passen. Dankeschön.
eomt.ps1 zum prüfen ob auch nach diesem neuesten Update die Lücke noch geschlossen ist kommt: ..is vulnerable: applying mitigation – das kann nicht sein da alle Updates eingespielt worden sind
Version: Exchange 2013CU23
Build Number: 15.0.1497.2
Exchange IU or Security Hotfix Detected.
Security Update for Exchange Server 2013 Cumulative Update 23 (KB4523171)
Security Update for Exchange Server 2013 Cumulative Update 23 (KB4536988)
Security Update for Exchange Server 2013 Cumulative Update 23 (KB4581424)
Security Update for Exchange Server 2013 Cumulative Update 23 (KB4593466)
Security Update for Exchange Server 2013 Cumulative Update 23 (KB5000871)
Security Update for Exchange Server 2013 Cumulative Update 23 (KB5001779)
@Thomas
„Get-Command Exsetup.exe | ForEach {$_.FileversionInfo}“
sollte bei dir
CU23: 15.0.1497.15 anzeigen
Quelle: https://www.msxfaq.de/exchange/update/pwn2own2021.htm
Soeben auf Exchange 2016 CU 19 mittels Windows Update installiert.
Bekam gegen Ende der Installation eine Visual Studio Just-In-Time debugger Meldung:
An unhandled Microsoft .net Framework Exception occured in w3wp.exe
Hab dann bei do you want to debug using the selected debuger auf no geklickt.
Installation lief einwandfrei zu Ende.
Danach Aufforderung zum Neustart…
„Get-Command Exsetup.exe | ForEach {$_.FileversionInfo}“ zeigt die aktuelle Version an (15.01.2176.012).
Es scheint alles zu funzen.
Die beschriebene Meldung kam bei mir auch unter der Version Exchange 2013 CU23 aber am Anfang der Installation. Ich habe die Meldung auch mit no bestätigt und die Installation lief problemlos durch.
Ebenfalls bei Exchange 2016 sowie 2019 installiert, ohne Probleme.
Ich habe diesen Hinweis bezüglich den Updates gefunden -> Installieren Sie das Updates NICHT über die Windows Update-Funktion sondern manuell als Administrator aus einer eine „elevated Shell“
Welchen Hintergrund hat das? Die Installation der Updates prüfe ich stets via „Get-Command Exsetup.exe | ForEach {$_.FileversionInfo}“, wo mir die korrekte Build angezeigt wird.
MfG der Seb
Wo hast du diese Infos denn her? Microsoft selbst sagt im KB Artikel, dass eine Installation über Windows Updates quasi „problemloser“ ist, da man hier nicht auf die Admin Rechte rücksicht nehmen muss.
https://www.msxfaq.de/exchange/update/pwn2own2021.htm
MfG der Seb
Gerade installiert, lief sauber durch. Exchange 2016 CU20.
Wie sieht es eigentlich aus wenn man den Patch auf einem CU 19 installiert und Tage später CU 20, ist es nötig den Patch dann erneut einzuspielen?
Afaik ja, wäre erst im CU21 dann eingebaut.
Die verfügbaren Updates sollten möglichst zeitnah eingespielt werden. >> Welche Updates? Beim Exchange 2016 inkl. CU20 wird mir nur das monatliche Update 04-2021 angezeigt. Gibt es noch mehr?
Sind doch im Arikel verlinkt…
Und wo? Ich finde nirgends passende KBs dazu. Sorry.
https://www.microsoft.com/en-us/download/details.aspx?id=103002