Nach dem Update, ist vor dem Update. Heute hat Microsoft die Kumulativen Updates für Exchange Server 2016 und 2019 veröffentlicht. Beide CUs enthalten die vorangegangen Sicherheitsupdates vom 02.03.21. Bei dem CU 20 handelt es sich um das vorletzte CU für Exchange Server 2016, danach werden nur noch Sicherheitsupdates veröffentlicht. Für Exchange 2016 wird das letzte CU also im Juni 2021 veröffentlicht werden. Danach wird es nur noch Sicherheitsupdates für Exchange 2016 geben.
Hier geht es direkt zum Download der CUs:
Das CU 9 kann via VLSC, Visual Studio Portal oder im Action Pack runtergeladen werden. Das CU 9 für Exchange 2019 ist im Visual Studio Portal ist es bereits verfügbar.
Details zu den behobenen Problemen gibt es unter den folgenden Links:
- Exchange Server 2019 Cumulative Update 9 (KB4602570)
- Exchange Server 2016 Cumulative Update 20 (KB4602569)
Da die beiden CUs die Sicherheitsupdates für den HAFNIUM Exploit enthalten, könnte man darüber nachdenken, direkt das CU auf bisher nicht aktualisierten Servern zu installieren. Es ist also nicht nötig die Sicherheitsupdates vor den CUs zu installieren.
Wichtig: Exchange Server welche bisher nicht mit den Sicherheitsupdates vom 02.03 aktualisiert wurden, müssen möglichst zeitnah aktualisiert werden. Außerdem sollte noch das Script EOMT ausgeführt werden, damit festgestellt werden kann, ob der Server bereits erfolgreich angegriffen wurde.
Hier findet sich noch der Artikel aus dem Microsoft Exchange Team Blog:
Hinweis: Wer zeitnah bei neues Updates für Exchange Server per Mail informiert werden möchte, kann den Newsletter abonnieren. Ich versuche immer möglichst zeitnah über neue Updates zu informieren.
Kumulatives Update 22 für Exchange Server 2016 (KB5005333)
Microsoft Exchange erhält neue Sicherheitsfunktion
Zusammen mit den September-Updates für On-Premise-Installationen von Microsoft Exchange Server ab Version 2016 wird ein neues Sicherheitsfeature „Emergency Mitigation (EM)“ standardmäßig aktiviert. Die neue Funktion wird auf Exchange-Servern mit Mailbox-Rolle als Dienst installiert und prüft stündlich bei Microsoft, ob neue aktive Exploits in Umlauf sind bzw. ob Microsoft Mitigationsmaßnahmen zur Verfügung stellt. Sofern neue Maßnahmen zur Verfügung stehen, werden diese automatisch auf den Exchange-Server angewandt. Die Maßnahmen können aus dem Beenden aktuell gefährdeter Dienste, Abschalten von „App Pools“ sowie der Verhinderung Angriff-spezifischer HTTP-Anfragen an den Exchange-Server bestehen. Microsoft weist darauf hin, dass EM nicht die regulären Updates ersetzt, vielmehr soll es als schnellstmögliche Maßnahme bis zur Installation von Updates das Risiko einer Kompromittierung verringern. Exchange-Administratoren können die Funktion „Emergency Mitigation“ bei Bedarf abschalten, falls diese nicht gewünscht wird. Das Update steht für Exchange Server, Versionen 2016 und 2019 zum Download zur Verfügung.
Hi !
Wir haben wie viele andere nach Ex16CU20 das Problem dass wir weder mit ARM noch PRTG inventarisieren oder ändern können (benutzt Powershell Backend).
Hier scheint MS etwas am Powershell Verhalten oder der Authentifizierung geändert zu haben.
Hat da jemand aktuelleste Infos ob sich das mit EX Bordmitteln beheben lässt oder die Softwarehersteller nachbessern müssen ?
Rossi
Hallo nochmal,
da auf unserem Exchange 19 das CU9 nicht durchlaufen wollte (3 Versuche), haben wir einen neuen Server aufgesetzt parallel. Nach erfolgreicher ex19cu9 Installation, griffen wir uns die vhd’s zum neuen Server und haben die edb gemounted. So weit, so gut. Allerdings versucht die Auth trotzdem noch über den alten Server zu gehen – ist er offline, wirft owa nach Auth einen 500er. Gleiches mit den Mailboxen. Es wird immer noch versucht auf den alten Mailserver zuzugreifen. Mir steht mittlerweile ganz schön einer auf der Leitung.
Ich wär euch für einen kleinen Denkanstoß sehr dankbar!
Beste Grüße,
Volkmar
Hallo Volkmar,
Habt ihr einen DAG?
Habt ihr den alten Exchange Server dekommisioniert oder sitzt der noch im AD?
Habt ihr einen Failovercluster?
Ich habe das Gefühl, dass ihr euch partout nicht an die „best practices“ von Exchange halten wollt.
Da ist es auch kein Wunder, dass euch das auf die Füße fällt. Exchange Systeme sind kompliziert und verlangen tiefgreifende Kenntnis, besonders wenn man da außerhalb der empfohlenen Pfade geht. So sehr ich also Leute wie Franky es zutraue, dass er in jeglicher Situation die Oberhand hätte, so sehr würde ich es mir nicht anmaßen und deshalb befolge ich brav die empfohlenen Pfade, auch wenn ich dank Franky und sein Blog heute viel mehr weiss als früher und bis jetzt jede Panne beheben konnte.
Kurzum Volkmar, vielleicht solltet ihr euch jetzt einen Profi wie Franky ins Boot holen wenn ihr weitermacht und auf die „best practices“ verzichten wollt.
Aber wenn ihr weitere alleine euer Glück versuchen wollt, 3 Ansatzpunkte habe ich dir oben geliefert.
Das das Update bei den Postfachrollen abbrach ist übrigens nicht verwunderlich. Wenn mich mein bisheriges Wissen nicht täuscht ist es erst ab da, dass die Konfiguration aufm Server aktualisiert wird, spricht das Upgrade angewendet wird. Davor werden nur die Dienste beendet, die alten Daten gelöscht, die neuen Daten inkl. den Sprachen kopiert.
Hallo zusammen,
wir haben bei uns Exchange Server 2016 im Einsatz und auch zeitnah die Security Patche beim CU19 installiert. Auch nach mehreren Prüfungen mit den bekannten Skripten und manueller Kontrolle sind keine Befunde sichtbar geworden.
Am Sonntagabend habe ich angefangen auf unseren Servern das CU20 zu installieren und war gestern fertig.
Nun habe ich aus unserem First Level Meldungen erhalten, das beim Versuch des Erstellens eines Postfaches (EAC > Empfänger > Postfächer > + Symbol > Benutzerpostfach) ein 500 Fehler kommt. Der Fehler tritt bei der globalen Adresse auf (welche auf unseren Loadbalancer zeigt exchange.domain.de) und auch wenn die URL direkt von den Exchange Servern aufgerufen wird.
In den Logs konnte ich erstmal nichts finden und es betrifft nur unser First Level alle Exchange Admins haben diese Meldung nicht.
Benachrichtigung entfernen|Bearbeiten|Löschen|Typ ändern
Question
Sie können nicht über Ihren eigenen Beitrag abstimmen.
0
Hallo zusammen,
wir haben bei uns Exchange Server 2016 im Einsatz und auch zeitnah die Security Patche beim CU19 installiert. Auch nach mehreren Prüfungen mit den bekannten Skripten und manueller Kontrolle sind keine Befunde sichtbar geworden.
Am Sonntagabend habe ich angefangen auf unseren Servern das CU20 zu installieren und war gestern fertig.
Nun habe ich aus unserem First Level Meldungen erhalten, das beim Versuch des Erstellens eines Postfaches (EAC > Empfänger > Postfächer > + Symbol > Benutzerpostfach) ein 500 Fehler kommt. Der Fehler tritt bei der globalen Adresse auf (welche auf unseren Loadbalancer zeigt exchange.domain.de) und auch wenn die URL direkt von den Exchange Servern aufgerufen wird.
In den Logs konnte ich erstmal nichts finden und es betrifft nur unser First Level alle Exchange Admins haben diese Meldung nicht.
Hier die Rollen der First Level Kollegen bzw. welche in der entsprechenden AD-Gruppe enthalten ist.
Über die Exchange Management Shell können die Benutzer die Postfächer erstellen also liegt es nicht an den Rechten.
Sorry da passte das Copy Paste nicht.
Das ist der originale Artikel von mir.
https://social.technet.microsoft.com/Forums/de-DE/a0697e7e-6694-4ab3-9207-72086e3e5b7b/exchange-server-2016-cu20-postfacherstellung-fhrt-zu-fehler-500-unerwarteter-fehler?forum=exchange_serverde
also wenn ich das bei unserer installation mache kommt kein 500er fehler, sondern ganz normal das fenster zum Eingeben der Daten. Ich muss aber folgendes gestehen:
1. bei uns läuft alles auf Englisch und nicht in Deutsch
2. Ich hab das jetzt schnell als Administrator ausprobiert.
Es ist definitiv nicht das Token denn in meiner Testumgebung kann ich das ebenfalls nachstellen. Hat ein Benutzer die oben genannten Exchange Rollen bekommt er den Fehler. Gebe ich dem Anwender aber das volle Exchange Paket an Rechten klappt der Zugriff ohne Fehler und der Anwender hat wirklich wenige Gruppen.
Ursache gefunden.
Wir haben bei uns diverse Kollegen di nur für bestimmte Kunden zuständig sind und somit auch diverse Exchange-ADM Rollen.
Diesen Rollen ist bisher neben einen definierten Schreibbereich im AD auch die folgenden Exchange Rollen zugewiesen worden was bis zum CU20 ausgereicht hat.
1. View-Only Recipients
2. Distribution Groups
3. Mail Recipient Creation
4. Mail Recipients
Nun nach dem CU20 kam ja der 500er Fehler und auch in meiner Testumgebung gab es diesen Fehler und die Lösung war eine Exchange Rolle die nun zusätzlich zugewiesen werden musste.
5. View-Only Configuration
Jetzt kommt auch kein Fehler mehr aber leider sehen jetzt die Kollegen viel mehr als vorher im EAC aber können nichts verändern.
Vielleicht hat jemand die Erklärung warum das ab dem CU20 sich geändert haben könnte.
MfG Paul
Hallo Paul,
Vielleicht hat Microsoft etwas geändert um die Angriffe wie Anfang März zu erschweren.
Sicher ist, dass CU20 Änderungen am AD vornimmt. Das konnte ich bei unserem Update von CU19 auf CU20 feststellen. Leider schweigt sich aber MS dazu aus, was das Update am AD bewirkt hat.
Vielleicht haben die etwas in Richtung Split Permission bei Exchange probiert. Trimac und co predigen ja schon seit langem, dass man Exchange mit Split Permission betreiben sollte. MS schwiegt bis jetzt eher dazu. In der Dokumentation um die Angriffe abzuwehren und spätere zu vermeiden tauch aber jetzt eine Empfehlung zu Split Permission vom MS.
MS ist da aktuell leider alles andere als transparent und ich vermute, dass bei den Angriffen weiter potentielle Schwachstellen identifiziert wurden, die man jetzt versucht zu flicken.
Wir müssen uns ja vor Augen führen, dass in den letzten 3 Wochen MS immer mit Informationen an die Öffentlichkeit gegangen ist, nachdem sich diese nicht mehr leugnen liessen.
Alleine am 2. März von vereinzelten Angriffen zu sprechen war ja eine Farce. Und seitdem rückt MS mit der Wahrheit nur scheibchenweise raus. Wer sich auf MS verlassen hat im hiesigen Fall, der dürfte einiges an Schaden erlitten haben.
Hi Alex,
CU5 habe ich noch nicht versucht zu installieren. Das Update brach bei den Postfachrollen ab – also im späteren Verlauf des Updates – und lief über eine Stunde. Neustart und erneuter Anstoß halfen nicht.
Ich schaue in der Zwischenzeit über die Release-Notes der anderen CUs.
Hallo zusammen,
leider warf das CU9 Update bei meinem Exchange 19 einen Fehler (vorher CU4, alle Updates über den Service).
„Zugriff verweigert“ bei einem Pfad, welchen es bei mir noch nie gab (CService::ScGetStatus (d:\dbs\sh\e19dt\0219_205444_0\cmd\1d\sources\dev\admin\src\libs\exsetup\service.cxx:723)
Error code 0XC0070424 (1060): Der angegebene Dienst ist kein installierter Dienst.
D: ist die 2. Partition für die Daten des Exchange. Die liegen allerdings unter D:\Datenbanken\…
Exchange selbst ist standardmäßig unter C:\Programme installiert.
Ich hab das gesamte Log des Updates da, falls noch etwas benötigt wird.
Habt ihr eine Idee?
Beste Grüße
Moin Volkmar,
könnte es sein, dass sich an Exchange 2019 von der CU4 auf der CU9 etwas geändert hat bei den Pfaden und Diensten?
Es ist ja so, dass Microsoft Exchange 2019 ja weiter entwickelt mit jeder CU… ein Sprung von 5 CUs dürften einen Zeitraum von 1 bis 1,5 Jahre bedeuten. In dieser Zeit hatte Microsoft 4 CUs Zeit um etwas an Exchange zu ändern.
Hast du dir mal die Release Notes der CU5, CU6, CU7, CU8 und CU9 auf die Veränderungen angeschaut die von Microsoft angegeben werden?
Prinzipiell wird der Sprung von mehr als 2 CUs nicht empfohlen… da ist das Risiko immer da, dass es Änderungen gegeben hat, die zu Problemen führen wie du ihn hast.
Ist das Update zum Anfang abgebrochen? in der Mitte?
Hast du mal versucht CU5 zu installieren um zu sehen ob du dasselbe Problem bekommst?
Bei mir wirft das EOMT Script (neueste Version) nach dem Update (Exchange 2016 CU20 /Server 2012r2) folgende Fehlermeldung
[PS] C:\test>.\eomt.ps1
In C:\test\EOMT.ps1:8 Zeichen:18
+
+ ~
Dateispezifikation nach dem Umleitungsoperator fehlt.
In C:\test\EOMT.ps1:169 Zeichen:21
+ Sign up
+ ~
Das kaufmännische Und-Zeichen (&) ist nicht zulässig. Der &-Operator ist für eine zukünftige Verwendung reserviert.
Verwenden Sie das kaufmännische Und-Zeichen in doppelten Anführungszeichen („&“), um es als Teil einer Zeichenfolge zu
übergeben.
In C:\test\EOMT.ps1:176 Zeichen:21
+ Sign up
+ ~
Das kaufmännische Und-Zeichen (&) ist nicht zulässig. Der &-Operator ist für eine zukünftige Verwendung reserviert.
Verwenden Sie das kaufmännische Und-Zeichen in doppelten Anführungszeichen („&“), um es als Teil einer Zeichenfolge zu
übergeben.
In C:\test\EOMT.ps1:203 Zeichen:189
+ … ata-ga-click=“(Logged out) Header, go to Features“>Features <span cla …
+ ~
Der Operator "→Mobile <span cla …
+ ~
Der Operator "→Actions <span cla …
+ ~
Der Operator "→Codespaces <span cla …
+ ~
Der Operator "<" ist für zukünftige Versionen reserviert.
Es wurden nicht alle Analysefehler berichtet. Korrigieren Sie die berichteten Fehler, und versuchen Sie es erneut.
+ CategoryInfo : ParserError: (:) [], ParseException
+ FullyQualifiedErrorId : MissingFileSpecification
Kann mir jemand sagen, wie ich da weiter komme ?
Mit PowerShell 7 kommt folgender Fehler
ParserError: C:\test\EOMT.ps1:8
Line |
8 |
| ~
| Missing file specification after redirection operator.
du sollst auf einem exchange server keine anderen powershell versionen installieren, fernab der vom os mitgelieferten powershell.
Windows PowerShell
Exchange 2013 or later requires the version of Windows PowerShell that’s included in Windows (unless otherwise specified by an Exchange Setup-enforced prerequisite rule).
Exchange 2010 requires Windows PowerShell 2.0 on all supported versions of Windows.
Exchange does not support the use of Windows Management Framework add-ons on any version of Windows PowerShell or Windows.
If there are other installed versions of Windows PowerShell or PowerShell Core that support side-by-side operation, Exchange will use only the version that it requires.
Quelle: https://docs.microsoft.com/en-us/exchange/plan-and-deploy/supportability-matrix?view=exchserver-2016
Danke für die Antwort (?)
Ich kann in dem Text nicht erkennen, dass man keine andere Powershell Version nebenbei installieren darf. Powershell 7 unterstützt side-by-side operation.
Und mein Problem wurde damit leider auch nicht beantwortet, der Fehler wurde schon vor der Installation von Powershell 7 angezeigt.
Mit freundlichen Grüßen.
MG
Hi MG,
Worauf MOM20xx hinweisen wollte ist, dass man nicht das neueste Powershell einfach so mit Exchange oder Windows Server nutzen kann.
Du hast als Umgebung Win2012r2… da ist glaube ich Powershell 3.0 mit ausgeliefert.
Wenn du also da Powershell 7.0 installierst, dann bewegst du dich außerhalb des von Microsoft empfohlenen. Powershell 7.0 wurde nicht für den Win2012r2 entwickelt.
Wir hier nutzen Powershell 5.0 und das nur weil sonst bestimmte Skripte wie die von Lets Encrypt nicht sauber laufen mit älteren Versionen.
Mit Powershell 5.0 lief das EOMT Skript einwandfrei.
Der Fehler der bei dir auftritt scheint ein Problem der Zeicheninterpretation zu sein. Sieht so aus als ob bei Powershell 7.0 bestimmte Zeichen vielleicht anders interpretiert werden als bei früheren Powershell Versionen.
Vielleicht solltest du dich mal an Microsoft wenden mit dem Fehler, weil das sieht definitiv nach einem Powershell Problem aus, nicht eines vom EOMT Skript.
Update lief sauber durch.
Habe meinen exchange mit einer waf geschützt.
Der exchange server ist nur über seine url erreichbar, wer nur die ip eingibt bekommt eine Fehlermeldung der sophos.
So kann ich portscans uf den exchange abwehren.
Zudem, habe ich die länder auf die pot. User eingegrenz, so dass ich die ursprungs länder ausschiessen konnte, waren meist asitische.
Cool, das Exchange 2019 CU9 ist auch erstmals ohne VLSC zum Download bereitgestellt.
Hoffe das es so bleibt und nicht nur ein versehen war.
https://www.microsoft.com/en-us/download/details.aspx?id=102900
Gruß Dirk
das hoffe ich auch :)
Hallo,
mal eine Frage zum Hardening.
würde eigentlich funktionieren wenn ich diese URL (suffixe) custom setzte.
Z.B. /owa_xyz usw.
$servername = „EX2016“
$internalhostname = „outlook.frankysweb.de“
$externalhostname = „outlook.frankysweb.de“
$autodiscoverhostname = „autodiscover.frankysweb.de“
$owainturl = „https://“ + „$internalhostname“ + „/owa“
$owaexturl = „https://“ + „$externalhostname“ + „/owa“
$ecpinturl = „https://“ + „$internalhostname“ + „/ecp“
$ecpexturl = „https://“ + „$externalhostname“ + „/ecp“
$ewsinturl = „https://“ + „$internalhostname“ + „/EWS/Exchange.asmx“
$ewsexturl = „https://“ + „$externalhostname“ + „/EWS/Exchange.asmx“
$easinturl = „https://“ + „$internalhostname“ + „/Microsoft-Server-ActiveSync“
$easexturl = „https://“ + „$externalhostname“ + „/Microsoft-Server-ActiveSync“
$oabinturl = „https://“ + „$internalhostname“ + „/OAB“
$oabexturl = „https://“ + „$externalhostname“ + „/OAB“
$mapiinturl = „https://“ + „$internalhostname“ + „/mapi“
$mapiexturl = „https://“ + „$externalhostname“ + „/mapi“
$aduri = „https://“ + „$autodiscoverhostname“ + „/Autodiscover/Autodiscover.xml“
sorry aber das ist security by obscurity und hat nichts mit hardening zu tun
patch die kiste oder spiel die workarrounds von microsoft ein.
Danke für den Hinweis. Direkt eingespielt. Mir ist aufgefallen, dass EOMT.ps1 vor CU9 (Exchange 2019) „is not vulnerable: mitigation not needed“ angezeigt hat und nun nach CU9 und einem erneuten Check „is vulnerable: applying mitigation“. Übersehe ich da was oder wie ist das zu verstehen?
2021-03-17 08:08:29 Info: EOMT precheck complete on XXX
2021-03-17 08:08:30 Info: XXX is not vulnerable: mitigation not needed
CU9 Install
2021-03-17 10:38:18 Info: EOMT precheck complete on XXX
2021-03-17 10:38:18 Info: XXX is vulnerable: applying mitigation
2021-03-17 10:38:18 Info: Starting mitigation process on XXX
Ebenfalls bei EX2016 so.
Nach CU „XX is vulnerable:…“
Gerade eben Ex2016 CU20 installiert und EOMT.ps1 sagt:
AUSFÜHRLICH: ExSRV is vulnerable: applying mitigation
AUSFÜHRLICH: Starting mitigation process on ExSRV
AUSFÜHRLICH: Installing the IIS URL Rewrite Module on ExSRV
AUSFÜHRLICH: IIS URL Rewrite Module installed on ExSRV
AUSFÜHRLICH: Applying URL Rewrite configuration to ExSRV :: Default Web Site
AUSFÜHRLICH: Mitigation complete on ExSRV :: Default Web Site
Naja, vielleicht passt MS sein Scritp nochmal an und Aktualisiert seine Buildtabelle :-)
die aktuelle Version des Scripts checkt wie folgt:
function Get-ServerVulnStatus {
$Version = (Get-ItemProperty ‚HKLM:\SOFTWARE\Microsoft\ExchangeServer\v15\Setup\‘).OwaVersion
$FutureCUs = @{
E19CU9 = „15.2.858.5“
E16CU20 = „15.1.2242.4“
}
if ($version -like „15.2.*“) {
$LatestCU = $FutureCUs.E19CU9
} elseif ($version -like „15.1.*“) {
$LatestCU = $FutureCUs.E16CU20
} else {
$LatestCU = „15.2.000.0000“ #version higher than 15.0 to trigger SecurityHotfix check for E15
}
if ([version]$LatestCU -ge [version]$Version) {
$SecurityHotfix = Get-ItemProperty HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\* `
| Where-Object displayname -Like „*KB5000871*“ `
| Select-Object displayname -ErrorAction SilentlyContinue
if (!$SecurityHotfix) {
return $true
}
}
return $false
}
und nachdem es nach der Installation von Exchange 2016 CU20 keinen Uninstall Eintrag für KB5000871gibt wird der Server als anfällig klassifiziert. Somit ist dieses Script fernab von CU19 respektive CU18 + installiertem Sec-Patch unbrauchbar.
Oder will uns das Script mitteilen, dass CU20 vielleicht die Sec-Updates gar nicht inkludiert hat?
MOM20xx
18. März 2021 um 05:25
„die aktuelle Version des Scripts checkt wie folgt:
function Get-ServerVulnStatus {
$Version = (Get-ItemProperty ‚HKLM:\SOFTWARE\Microsoft\ExchangeServer\v15\Setup\‘).OwaVersion
$FutureCUs = @{
E19CU9 = „15.2.858.5“
E16CU20 = „15.1.2242.4“
}
if ($version -like „15.2.*“) {
$LatestCU = $FutureCUs.E19CU9
} elseif ($version -like „15.1.*“) {
$LatestCU = $FutureCUs.E16CU20
} else {
$LatestCU = „15.2.000.0000“ #version higher than 15.0 to trigger SecurityHotfix check for E15
}
if ([version]$LatestCU -ge [version]$Version) {
$SecurityHotfix = Get-ItemProperty HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\* `
| Where-Object displayname -Like „*KB5000871*“ `
| Select-Object displayname -ErrorAction SilentlyContinue
if (!$SecurityHotfix) {
return $true
}
}
return $false
}
und nachdem es nach der Installation von Exchange 2016 CU20 keinen Uninstall Eintrag für KB5000871gibt wird der Server als anfällig klassifiziert. Somit ist dieses Script fernab von CU19 respektive CU18 + installiertem Sec-Patch unbrauchbar.
Oder will uns das Script mitteilen, dass CU20 vielleicht die Sec-Updates gar nicht inkludiert hat?“
#################
Ich hoffe, das einfach die neuen Buildnummern vom Skript nicht korrekt geprüft werden.
Laut MS steht in den PatchReleaseNotes explizit drin:
„Kumulatives Update 20 für Microsoft Exchange Server 2016 wurde am 16. März 2021 veröffentlicht. Dieses kumulative Update enthält Korrekturen für Nichtsicherheitsprobleme und alle zuvor veröffentlichten Fixes für Sicherheits- und Nichtsicherheitsprobleme. Diese Korrekturen werden auch in späteren kumulativen Updates für Exchange Server 2016 enthalten sein. Dieses Update behebt auch Sicherheitslücken, siehe Microsoft Common Vulnerabilities and Exposures CVE-2021-26412, CVE-2021-27078, CVE-2021-26854, CVE-2021-26855, CVE-2021-27065, CVE-2021-26857, CVE-2021-26858.“
https://support.microsoft.com/de-de/topic/kumulatives-update-20-f%C3%BCr-exchange-server-2016-98964463-f7df-4131-6b8c-4f46dafc748e
Das sind die CVEs zu den Hafnium Sicherheitslücken:
Microsoft Exchange Schwachstellen CVE-2021-26855, CVE-2021-26857, CVE-2021-26858, CVE-2021-27065 Detektion und Reaktion
https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Cyber-Sicherheit/Vorfaelle/Exchange-Schwachstellen-2021/MSExchange_Schwachstelle_Detektion_Reaktion.pdf?__blob=publicationFile&v=3
Sie werden alle in den Releasenotes als gepatched beschrieben.
sollte jetzt gemäß https://github.com/microsoft/CSS-Exchange/blob/main/Security/src/EOMT.ps1 behoben sein.
es wird nun korrekterweise auf if ([version]$LatestCU -gt [version]$Version) abgefragt und die aktuellen CUs werden nicht mehr als vulnerable angesehen
Korrekt.
Empfehlung ist dann noch:
.\EOMT.ps1 -Rollbackmitigation
um die fälschlicherweise angewendeten mitigations wieder rückgängig zu machen.
CU20 muss nicht nochmal „drüberinstalliert“ werden.
VG :)
Moin. Gerade aktuelles EOMT auf CU9 ausprobiert (EX2019) und wird weiterhin als „vulnerable“ angesehen:
2021-03-19 09:15:41 Info: Starting EOMT.ps1 on XXX
2021-03-19 09:15:41 Info: EOMT precheck complete on XXX
2021-03-19 09:15:41 Info: XXX is vulnerable: applying mitigation
2021-03-19 09:15:41 Info: Starting mitigation process on XXX
2021-03-19 09:15:42 Info: IIS URL Rewrite Module is already installed on XXX
2021-03-19 09:15:42 Info: Applying URL Rewrite configuration to XXX :: Default Web Site
2021-03-19 09:15:58 Info: Mitigation complete on XXX :: Default Web Site
Im Script gesehen: E19CU9 = „15.2.858.5“ … bei mir ist 15.2.858.2 ?!
was gibt (Get-ItemProperty ‚HKLM:\SOFTWARE\Microsoft\ExchangeServer\v15\Setup\‘).OwaVersion in einer powershell bei dir aus?
und lad dir die letzte version vom script unter https://github.com/microsoft/CSS-Exchange/releases/latest/download/EOMT.ps1herunter sollte. derzeit Version 21.03.18.2345 sein
Get-ItemProperty ‚HKLM:\SOFTWARE\Microsoft\ExchangeServer\v15\Setup\ gibt aus:
OwaVersion : 15.2.858.2
NextOwaVersion : 15.2.858.2
OwaBasicVersion : 15.2.858.2
MsiBuildMajor : 858
MsiBuildMinor : 5
Hallo Frank,
danke, aktuell wie immer. Wir haben gestern Nacht mehrere 2016er und 2019er auf den aktuellsten Stand gebracht. Soweit alles easy, falls jemand aber bei Punkt 8, Client Frontend, auf einen Zertifikatsfehler kommt:
Abrechnen (gibt eh keinen anderen Button)
Bei den Zertifikaten (IIS oder Zertifikatsspeicher) raussuchen, welcher Fingerabdruck/Seriennummer beim Fehler ist
Zertifikat Löschen
Installation erneut starten (geht butterweich)
Bei uns war es Let´s Encrypt, dass wir auf 2 Maschinen produktiv hatten, nun wieder vernünftige von Sectigo.
Danke und Grüße
Moin, kurze Frage: Könnte man die Neuinstallation des Exchange, wie von Franky beschrieben, auch direkt mit dem CU 20 machen? Aktuell wäre der Server auf CU19 mit Patch, soll aber dennoch neu installiert werden.
Vielen Dank :)
Gruß,
Das würde mich auch interessieren.
Kann ich einen Exchange 2016 CU17 direkt zu einem CU20 gem. Anleitung „Neuinstallation ohne Datenverlust“ von hier übertragen, oder muss vorher das CU20 bzw. auf dem neuen erst das CU17installiert werden?
Danke schon mal
https://docs.microsoft.com/de-de/exchange/high-availability/disaster-recovery/recover-exchange-servers?view=exchserver-2016
Wenn Sie nicht über die Installationsmedien für die kumulative Update-Version (Cu) verfügen, die auf dem wiederherzustellenden Server installiert wurde, können Sie einen Server mit dem neuesten verfügbaren kumulativen Update wiederherstellen.
Jedes CU war bis jetzt immer eine Vollversion – also anhand von der größe der ISO müsste dies bei dem CU20 ebenfalls möglich sein.
Hallo Stephan,
die Frage die ich mir stelle ist ob ich die ausgehängte Datenbank von der CU17 des alten Servers auf dem neuen Server mit der CU20 wieder einhängen kann.
Gruß
Hallo Roland,
ah, sorry, habe Deine Fragestellung falsch verstanden – und habe ich noch so nie gemacht, bin leider keine Hilfe…
*In der Theorie* sollte das kein Problem sein, weil CUs das Datenbankformat nicht weiter tangieren, zumindest wenn man sich auf das Changelog verlässt.
Ist die DB wegen der Hafnium-Lücke ausgehängt?
Ich habe gelernt das man immer das CU installiert (Recovery Installation) wie es vorher auch drauf war. Mit einem neuen CU kommen ab und zu auch Anpassungen am AD-Schema und da ist es vielleicht nicht sinnvoll das dann gleich mit zu machen.
Installieren am Besten das CU welches vorherdrauf war mit den Security Patch und bringe die DB`s wieder in den aktive Status.
Wenn dann alles ohne Fehler läuft kannst du schauen ob das Schema erweitert werden muss und das neueste CU einspielen.
Genauso ist es mit .Net Framework denn da musst du auch schauen welches vorausgesetzt ist für das entsprechende CU.
MfG Paul
hallo,
wo finde ich die VOraussetzung für CU20 bezgl. welches Schema/Version und welche .Net Framew Version?
Vielen Dank
MfG
Gizmo
Danke für die Info, wir waren gott sei dank nicht betroffen.
Wie immer klasse Service von Dir Frank!
Hatte jemand schon den Fehler , dass er das de:DE um Sprachpaket nicht deinstallieren konnte? Es kommt immer das es nicht installiert ist, ist es aber . Gibt es eine andere Möglichkeit?
Hier auch gerade installiert. Exchange 2016 kein DAG. Lief sauber und gefühlt irgendwie schneller durch. Das PDF Problem in OWA ist behoben worden.
Gruß
Gerade das aktuelle CU20 bei meinem Exchange 2016 installiert – alles ohne Probleme :)
Vielen Dank an Frank für diese super Webseite, auf die ich sehr gerne zurückgreife :)
Viele Grüße
Philipp