Viele Admins berichten derzeit von ein einem erfolgreichen Angriff auf ihren Exchange Server. Viele finden Hinweise auf unbefugte Zugriffe oder sogar eine installierte Webshell. Viele sind nun verunsichert, was nun zu tun ist oder wie weiter vorgegangen werden soll. Manche implementieren nun beispielsweise IIS-Rewrite Rules oder deaktivieren die UM-Dienste, wie es in diesem Artikel von Microsoft empfohlen wird:
Hier gibt es allerdings etwas zu beachten: Der Artikel beschreibt Maßnahmen die getroffen werden können, wenn der verfügbare Patch nicht installiert werden kann. Der Artikel geht davon aus, dass der Exchange nicht bereits erfolgreich angegriffen wurde. Die beschriebenen Maßnahmen sind also “Workarounds” für Umgebungen die den Patch nicht installieren können und bisher nicht angegriffen wurden. Wenn sich also bereits Hinweise finden lassen, dass der oder die Exchange Server angegriffen wurden, gilt oder oben verlinkte Artikel so nicht mehr.
Wenn Ihr also bereits durch die zahlreichen verfügbaren Scripts, Hinweisen in den Logs oder komische .js / .aspx Dateien in Verzeichnissen davon ausgehen könnt, dass der Exchange Server erfolgreich angegriffen wurde, dann müsst ihr jetzt schnell reagieren. Das Kind ist jetzt bereits in den Brunnen gefallen, eine erfolgreich installierte Webshell ermöglicht es dem Angreifer Zugriff auf weite Teile des Netzwerks. Macht euch bewusst, dass Exchange Server weitreichende Berechtigungen im Active Directory haben und der Angreifer mittels Webshell nun möglicherweise weitreichenden Zugriff auf das Netzwerk haben.
Bevor man sich aber nun auf eine möglicherweise langwierige Analyse des Vorfalls begibt und versucht den erfolgten Angriff rückgängig zu machen, indem beispielsweise die angelegten Dateien oder ähnliches gelöscht wird, könnte man auch über eine Recovery Installation des Exchange Servers nachdenken. Nach einer Recovery Installation hat man sowohl eine frische Installation des Betriebssystems und auch des Exchange Servers. Nur wenige Einstellungen für die Exchange Konfiguration müssen erneut durchgeführt werden (Beispielsweise Empfangsconnectoren). Eine Recovery Installation ist zudem auch noch recht schnell durchgeführt, nach etwa 2 – 3 Stunden ist das Betriebssystem inkl. Exchange wiederhergestellt. Ein weiterer Vorteil: Eine aktuelle Datensicherung wird bei diesem Vorgehen nicht benötigt.
Kleine Vorwarnung: Dieser Artikel ist recht schnell entstanden und mit Exchange 2019 getestet worden, ich kann hier natürlich nicht alle Umgebungen nachstellen und im Hinblick auf Zeit auch nicht auf jedes Detail eingehen. Wenn etwas unklar, bitte ich um Hinweise, dann kann ich den Artikel überarbeiten.
Exchange Server sofort vom Netz nehmen
Wenn es bereits Hinweise auf eine Kompromittierung des Exchange Servers gibt, dann muss der Server sofort vom Netzwerk getrennt werden. Natürlich bedeutet dies Downtime für die Benutzer, es geht nun aber darum mehr Schaden abzuwenden. Der Exchange Server gehört also vom Netz, bei einer VM könnt ihr die virtuelle Netzwerkkarte beispielsweise in VMware oder Hyper-V deaktivieren. Bei einem physikalischem Server lässt sich der Switch Port deaktivieren oder zur Not die Netzwerkkabel ziehen. Hauptsache der Server kommt vom Netz. Damit wird erst einmal weiterer Schaden verhindert. Wer nicht gleich “das Kabel ziehen möchte”, muss mindestens die Portfreigeben und / oder den Zugriff vom Internet auf den Exchange Server blockieren. Für welche Möglichkeit ihr euch auch entscheidet, die weiteren Maßnahmen werden Downtime erfordern (zumindest wenn ihr keine DAG betreibt).
Passwörter zurücksetzen
Nachdem der Exchange Server vom Netz genommen wurde, werden mindestens die Passwörter für den Benutzer “Administrator” und dem Benutzer mit dem Ihr ihr Exchange administriert zurückgesetzt. Wenn ihr euch also mit dem Konto “Administrator” am Exchange Server anmeldet (via RDP oder EAC usw) dann wird dieses Passwort nun geändert. Alle weiteren Passwörter für administrative Benutzer müssen ebenfalls geändert werden. Dies ist das Minimum!
Wichtige Einstellungen sichern
Ihr könnt jetzt anfangen die Neuinstallation von Exchange vorzubereiten. Dazu sichert ihr euch am besten ein paar wichtige Einstellungen vom kompromittierten Server. Am besten geht ihr einmal die Konfiguration des Servers durch, viele der Einstellungen werden im Active Directory gespeichert und sind auch nach der Neuinstallation entsprechend eingestellt. Sichern sollte man sich aber in jedem Fall die Einstellungen der virtuellen Verzeichnisse. Hier muss jedes Verzeichnis einmal durchgegangen werden und Werte für Interne- und Externe URL, sowie die Einstellungen zur Authentifizierung gesichert werden:
Die entsprechenden Werte lassen sich beispielsweise einfach in eine TXT Datei kopieren. Ebenfalls wichtig sind die Einstellungen der Empfangsconnectoren:
Sichert euch auch hier die entsprechenden Einstellungen.
Zertifikat sichern
Damit die Neuinstallation des Exchange Servern möglichst einfach verläuft, sichert ihr euch am besten das aktuelle Zertifikat. Wenn ihr den Exchange Server nur vom Internet getrennt habt, könnt ihr das Zertifikat noch via EAC exportieren:
Wenn ihr den Server komplett vom Netzwerk getrennt habt, dann lässt sich das Zertifikat via MMC exportieren:
Datenbank sichern
Bevor die Datenbank gesichert wird, müssen die Exchange Dienste gestoppt werden. Mit dem folgenden Befehl lassen sich alle Exchange Dienste deaktivieren:
Get-Service *exchange* | Set-Service -StartupType Disabled
Danach können die Exchange Dienste gestoppt werden. Tipp: Durch das beenden des Dienstes “Microsoft Exchange Active Directory Topology” werden auch die meisten anderen Exchange Dienste gestoppt:
Sichert euch nun die die Exchange Datenbanken. Wenn die Datenbank(en) auf anderen Laufwerken als C: gespeichert wurden, habt ihr hier einfaches Spiel. In diesem Fall muss nichts gesichert werden. Wenn die Datenbanken allerdings auf auf Laufwerk C: gespeichert werden, dann müssen alle Datenbank Dateien zunächst an einen sicheren Ort kopiert werden:
Wenn die Datenbanken auf einem separaten Laufwerk gespeichert werden, müssen die Daten nicht extra gesichert werden.
Server neu installieren
Im Active Directory wird jetzt das Computer Konto des Exchange Servers zurückgesetzt:
Wichtig: Das Konto wird nur zurückgesetzt, aber NICHT gelöscht.
Nachdem das Konto zurückgesetzt wurde, wird der Server neu installiert.
Falls ihr die Datenbanken auf einer anderen Partition oder Laufwerk gespeichert hattet, achtet darauf, dass die Daten bei der Neuinstallation nicht verloren gehen. Also lieber doppelt die Einstellungen kontrollieren.
Für die Neuinstallation muss die gleiche Betriebssystem Version verwendet werden, welches auch vorher im Einsatz war. Nach der Installation des Betriebssystems bekommt der neue Server den gleichen Namen und die gleiche IP wieder der alte Server, danach wird der neue Server in das Active Directory aufgenommen.
Ihr solltet nun also eine frische Windows Installation mit dem gleichen Computernamen haben, welche auch bereits zum AD hinzugefügt wurde. Jetzt fehlt noch Exchange.
Exchange neuinstallieren
Auf dem frischen Windows Server müssen zunächst die Voraussetzungen für Exchange installiert werden. Die Voraussetzungen für Exchange 2016 und 2019 finden sich hier:
Nachdem die erforderlichen IIS-Rollen, .NET-Framework und UCMA-API installiert wurden, kann die Exchange Wiederherstellung mit dem folgenden Befehl gestartet werden:
Setup.exe /IAcceptExchangeServerLicenseTerms /Mode:RecoverServer
Falls Exchange nicht im Standardverzeichnis installiert wurde, muss noch der Parameter “TargetDir” angegeben werden:
Setup.exe /IAcceptExchangeServerLicenseTerms /Mode:RecoverServer /TargetDir:"D:\Program Files\Exchange"
Nach etwas Zeit ist Exchange wieder installiert. Der Server sollte nun neu gestartet werden.
Datenbank wiederherstellen
Damit die Datenbank wiederhergestellt werden kann, muss zunächst das Restore erlaubt werden, dies geschieht mit dem folgenden Befehl auf der Exchange Management Shell:
Get-MailboxDatabase -Server EX1 | Set-MailboxDatabase -AllowFileRestore $true
Jetzt wird die der gesamte Ordner mit der Datenbank vom alten Server wieder zurück an seinen Bestimmungsort kopiert:
Sobald die Daten kopiert wurden, kann die Datenbank gemountet werden:
Wenn die Datenbank auf einem anderen Laufwerk als C: gespeichert wurde, sind die Daten ja noch am gleichen Ort verfügbar. Stellt dann sicher, dass die Laufwerksbuchstaben passen. Ihr solltest in diesem Fall direkt in der Lage sein die Datenbank zu mounten.
Zur Sicherheit sollte nun kontrolliert werden, ob alle Exchange Dienste gestartet sind, falls noch nicht alle Dienste laufen, einfach starten.
Einstellungen der virtuellen Verzeichnisse wiederherstellen
Die Anmeldung an Exchange via EAC ist jetzt bereits wieder möglich. Ihr könnt jetzt die Einstellungen der virtuellen Verzeichnisse korrigieren und wieder auf die vorigen Werte einstellen:
Wie schon bei der Sicherung müsst ihr hier jedes Verzeichnis durchgehen.
Zertifikat importieren
Das zuvor gesicherte Zertifikat kann nun also wieder bequem per Exchange Administrative Center importiert und den Diensten zugeordnet werden:
Der Pfad zur gesicherten PFX Datei muss via UNC Pfad angegeben werden:
Im nächsten Schritt muss nur noch der Server für den Import angegeben werden:
Jetzt muss das importierte Zertifikat nur noch an die Exchange Services gebunden werden:
Jetzt könnt ihr die Benutzer wieder auf Exchange loslassen. Parallel dazu solltet ihr noch einmal alle Einstellungen kontrollieren und ggf. nachbessern. Beispielsweise wäre es jetzt an der Zeit die Empfangsconnectoren wieder entsprechend zu konfigurieren.
Exchange 2019 CU14 RecoverServer fails
es scheint so das mit der CU14 kein wiederherstellen funktioniert zumindest bei mir ging es nicht
Microsoft hat dazu auch einen Eintrag
„Cannot convert null to type“ error and Exchange 2019 CU14 RecoverServer fails
https://support.microsoft.com/en-au/topic/-cannot-convert-null-to-type-error-and-exchange-2019-cu14-recoverserver-fails-2f0e1202-8253-4bfc-a9bb-d575ccfa7cef
Im Zusammenhang mit Exchange 2019 CU14 gab es bei mir ein interessante Auffälligkeit:
Das restore setup lief auf einen Fehler, der bei Microsoft unter
https://support.microsoft.com/de-de/topic/fehler-null-kann-nicht-in-typ-konvertiert-werden-und-exchange-2019-cu14-recoverserver-schl%C3%A4gt-fehl-2f0e1202-8253-4bfc-a9bb-d575ccfa7cef
dokumentiert ist.
Eigentlich sollte das setup mit CU13 durchgeführt werden. Ob der alte Exchange bereits auf CU14 war, ist mir nicht bekannt. CU13 wollte jedenfalls nicht starten, da das Build von CU14 erwartet wurde. Daher wurde das Setup von CU14 gestartet mit oben genanntem Ergebnis.
Die Lösung war, die Build Nummer im AD zu ändern und danach das CU13 restore setup auszuführen. Damit lief es problemlos durch.
Sehr guter Artikel wieder mal. Danke!
Hatte zwar keinen Angriff, aber trotzdem gebraucht.
Zur Info, wenn beim Setup die Version bemängelt wird, da Patchstand höher als die CU:
https://learn.microsoft.com/en-us/exchange/troubleshoot/setup/version-error-in-recover-server-mode-install
Viele Grüße,
Stephan
Ergänzung:
Setup.exe /IAcceptExchangeServerLicenseTerms_DiagnosticDataON bzw. OFF
Anders mag MS nicht mehr.
Bei Installation muss man folgendes machen :
Setup.exe /Mode:RecoverServer /IAcceptExchangeServerLicenseTerms_DiagnoticsDataON
Laut Microsoft : /IAcceptExchangeServerLicenseTerms_DiagnosticDataON
/IAcceptExchangeServerLicenseTerms_DiagnosticDataOFF This switch is required in all unattended setup commands (whenever you run Setup.exe with any additional switches). If you don’t use this switch, you’ll get an error. To read the license terms, visit Microsoft License Terms.
To accept the license terms and send diagnostic data to Microsoft use the switch with suffix DiagnosticDataON.
To accept the license terms but not send diagnostic data to Microsoft use the switch with suffix DiagnosticDataOFF.
Note: These switches are available beginning with the September 2021 Cumulative Updates for Exchange Server 2016 and Exchange Server 2019.
Hallo zusammen,
mal wieder eine super Anleitung, die auch komplett nachvollziehen kann. Nur zu einem Punkt habe ich eine Frage:
„Falls Exchange nicht im Standardverzeichnis installiert wurde, muss noch der Parameter “TargetDir” angegeben werden:
Setup.exe /IAcceptExchangeServerLicenseTerms /Mode:RecoverServer /TargetDir:“D:\Program Files\Exchange“
Kann ich auch ein ANDERES Installationsverzeichnis, als bei der ursprünglichen Installation verwenden? Oder muss ich wieder das der ursprünglichen Installation verwenden?
Ich freue mich über hilfreiche Tipps. :)
Viele Grüße
Bastian
Hallo Frank,
danke für die super Anleitung. Damit habe ich den Server sehr gut neu installieren können.
Nach dem der neue Server online war hat er zwar Mails empfangen und auch zum Senden angenommen, nur blieben die alle in der Warteschlange hängen. Sah also so aus als ob nix rein oder raus geht.
Ich habe es dann gelöst. Nach der Recovery Installation war im ECP unter Server bei den DNS Lookup-Einstellungen der Reiter Alle verfügbaren Netzwerke eingestellt. Dies führte aber zu einer Meldung im Anwendungs-Ereignisprotokoll „DNS für Adaper xxxx xxxxxxx nicht möglich“ (oder so ähnlich), Als ich dann die richtige Netzwerkkarte manuell gesetzt habe hat der Server alle Warteschlangen abgearbeitet.
Danach habe ich ziemlich lange gesucht. Falls jemand das gleiche Problem hat hoffe ich geholfen zu haben.
Gruß Remoter3446
Hallo Frank,
Danke für die Anleitung. Leider waren wir davon betroffen und wollten bei einem Exchange 2016 auf Windows 2016 nach deiner Anleitung neu installieren. Es lief alles perfekt, bis zum RecoverServer beim Punkt Transportrolle. Hier endet das Setup mit dem Fehler, das der Inhaltsfilter nicht registriert werden konnte. Es findet sich zwar über Google ein paar Infos hierzu, aber keine hat geholfen. Setup.exe /PAD endete mit einem Fehler, dass ein Scriptordner fehlen würde. Alle Voraussetzungen sind installiert. Ich bin mit meinem Latein am Ende. Hast du noch eine Lösungsmöglichkeit?
LG aus Bayern, Augsburg,
Danny
Hallo,
Leider habe ich auch einen Server, der wohl neu installiert werden müsste. Alles unter HyperV. Exchangeinstallation ist unter komplett alleine auf einer VHD (D:\Exchange).
Hab ich es richtig verstanden, dass ich in diesem Fall das komplette existierende Laufwerk D:\Exchange einfach als Target Dir angeben muss und schon fluppt es? Muss ich dann überhaupt irgendwelche Einstellungen anpassen bis auf das Zertifikat?
Sind nicht ggf. auch böse „Webshells etc.“ im vorhandenen Exchangeverzeichnis vorhanden? Nicht, dass man einfach drüber installiert und Angriffe gehen weiter.
Wäre über eine Antwort dankbar.
Gruss
Peter
Hallo Franky,
ich habe die Installation nach der Anleitung durchgeführt. Leider scheint die Installation die SCP Einträge nicht angepasst zu haben. Unser Autodiscover beim Anlegen von Outlookprofilen funktioniert nun leider nicht mehr.
Über die bekannten Befehle ist es mit nicht möglich die SCP-Einträge zu setzen. Gibt es eine Möglichkeit den SCP nachträglich zu setzen? (Das was bei der Installation automatisch gemacht wird)
Mit freundlichen Grüßen
Benjamin
Konnte mir die Frage nun selbst beantworten.
Im AD Sites und Services bis unter Services->Microsoft Exchange->First Organisation->Exchange Administrative Grup (xxxxxxxx)->Servers->Servername->Protocols springen und hier den Ordner Autodiscover löschen.
Mit dem Befehl Set-ClientAccessServer -Identy Servername -AutoDiscoverSiteScope NamederSite wird der Eintrag neu erstellt und kann dann über die bekannten Befehle wieder angepasst werden.
Z.B.: Set-ClientAccessService -Identity „srv-mail“ -AutoDiscoverServiceInternalUri https://autodiscover.domain.de/Autodiscover/Autodiscover.xml
Im Anschluss einen iisreset absetzen.
Hallo Franky,
Du bist echt Goldwert. Ich war leider betroffen und musste sein sehr altes Backup zurückholen und dabei stellte ich noch fest dass dieses beschädigt war und das System nicht hochfuhr.
Daher musste ich den Exchange neuinstallieren. Mit dieser Anleitung hier hat das erstaunlicherweise ohne Probleme geklappt.
Mobile Clients über HTTPS von aussen habe ich jetzt abgeklemmt bis ich eine gute Lösung dafür. Clientzertifkate etc. pp. auf den mobile Geräten.
Vielen Dank.
Moin liebe Mitleidenden!
Habe auch das Vergnügen, dass ein Exchange leicht verseucht ist. Habe die Maschine (2016er) mit CU19 etc. gepatched. Nachdem alles augenscheinlich schön war und etwas zeit übrig war, stellte ich die gesamte Ausmaße fest:
WebShells waren vorhanden (gut wusste ich auch vorher), jedoch gab es auch schon aktive Eingriffe (Minidumps der LSASS.EXE etc.)
Nun möchte ich gerne eine vorhandene Sicherung vom 2.3 nutzen.
Geprüft und ist sauber (keine Spuren von WebShells etc.)
Frage:
Kann ich dieser Version (CU 16) nehmen, die aktuelle Datenbank offline kopieren und dann einfach CU19 erneut installieren? Oder werden mir dabei Informationen aus dem AD (da war ja schon CU19 aktiv) in die Quere kommen?
Hat jemand da Erfahrung?
Fast Lane
Voraussetzung: Exchange in einer VM / System und Datenbanken auf 2 getrennten Partitionen (!!Wichtig!!) / Verfügbare Backups der VM, z.B. über Veeam
Sicher haben einige den Exchange Server in einer VM laufen. Wahrscheinlich liegt die Installation auf der Systempartition und die Datenbanken auf einer weiteren Partition. Falls jetzt noch die VM gesichert wird, z.B. mit Veeam, gibt es eine Express Lösung. Das Ganze funktioniert auch mit mehreren Exchange-Servern im DAG
Beispiel Hyper-V:
1. VHDX der Systempartition aus dem Backup wiederherstellen, z.B. von Dezember 2020.
2. Exchange Server herunterfahren
3. Die wiederhergestellte VHDX Datei im Hyper-V Server neu einbinden. Datei austauschen reicht nicht !!
4. Server starten und als lokaler Admin einloggen.
5. Vertrauensstellung zur Domain wiederherstellen:
Powershell
Reset-ComputerMachinePassword -Server MEINDC -Credential CONTOSO\administrator
6. Neu einloggen
7. Exchange CU 20 installieren und alle Windows Updates installieren
8. Server wieder Online nehmen
Fertig!
Hallo Franky,
1000 Dank. Eine super Anleitung. Die hat uns gerettet. Ich habe gerade den Exchange 2016 neu aufgesetzt. Es hat alles einwandfrei funktioniert.
Gruß,
Peter
Hallo zusammen, ich habe es nun auch mit einem Exchange2016 probiert; konnte aber leider die vorhandene Datenbank nicht mehr anbinden. Ich habe es nach dieser Anleitung nun geschafft, eine neue Datenbank (Kopie der alten) zu erstellen und die Postfächer wieder sauber zu mounten. https://www.frankysweb.de/exchange-2016-wiederherstellung-einer-datenbank-auf-einem-anderen-server/
Problem ist aber, dass nun die „alte“ Datenbank noch im System vorhanden ist und ich diese nicht löschen kann. Folgende „Postfächer zeigen noch auf die alte Datenbank:
get-mailbox -Database MBXDB01 -Monitoring
get-mailbox -Database MBXDB01 -AuditLog
get-mailbox -Database MBXDB01 -Arbitration
Jemand eine Idee für mich, wie ich diese Verknüpfung auf die „neue“ Datenbank setzten kann? Sehe gerade den Wald vor lauter Bäumen nicht :(
Danke und VG aus Rosenheim
Hallo zusammen,
um auf der sicherne Seite zu sein (hatten noch 2019 CU3), hatten wir uns auch entschlossen, den Server neu aufzusetzen, was Dank Frankys Anleitung problemlos lief (hierzu mal einen großen Dank für diesen, sowie viele weitere hilfreiche Artikel).
Zur Installation haben wir auch gleich die 2019 CU8-Version genommen, was ebenfalls problemlos lief.
Bei der Überprüfung ist jedoch aufgefallen, dass unter installierte Programme zwar Exchange 2019 CU 8 angezeigt wird, aber im ECP und der ExchangeShell die Version 464.5 (CU3) angegeben wird.
Leider stehen wir da jetzt auf dem Schlauch und finden keine Erklärung, warum dem so ist.
Hat hierzu vielleicht jemand eine Idee?
Gruß
Volker
Sitze wohl gerade kurz vor dem gleichen Problem.
Überlege jetzt erst CU3 zu installieren und dann ein Update auf CU10 zu machen.
https://docs.microsoft.com/de-de/Exchange/high-availability/disaster-recovery/recover-exchange-servers?view=exchserver-2019
„Wenn Sie nicht über die Installationsmedien für die kumulative Updateversion (Cumulative Update, CU) verfügen, die auf dem Server installiert wurde, um wiederhergestellt zu werden, können Sie einen Server mit dem neuesten verfügbaren kumulativen Update wiederherstellen. Nur die letzten beiden CUs stehen zum Download zur Verfügung.“
Die Binär-Version ist jetzt tatsächlich CU10
$ExchangeServers = Get-ExchangeServer | Sort-Object Name
ForEach ($Server in $ExchangeServers) {
Invoke-Command -ComputerName $Server.Name -ScriptBlock { Get-Command Exsetup.exe | ForEach-Object { $_.FileversionInfo } }
}
Was ist denn dann die DisplayAdminVersion?
Wenn ich nach obiger Anleitung vorgehe, muss ich dann auf den Clients die Outlookprofile neu anlegen oder sollte die Verbindung ohne Neuanlage gleich funktionieren?
HELP: bei mir kommt bei jeden server diese meldung:
[PS] C:\Windows\system32>Get-MailboxDatabase -Server EX16 | Mount-Database
Bestätigung
Mindestens eine Datenbankdatei dieses Informationsspeichers fehlt. Das Einbinden dieses Informationsspeichers erzwingt
die Erstellung einer leeren Datenbank
??
jmd nen tipp? ich hab, wie beschrieben: die datenbank von D:\Exchange Server\Mailbox rauskopiert, server neu installiert, datenbank zurück kopiert und dann kommt die meldung??
HELP :(
edit: wohl nur beim Echange 2016 – grade bei nem 2019er gemacht: da gings.. hmm
Hallo Stefan,
Vermutlich hast du nur die Datenbank und keine weiteren Dateien aus dem Ordner rauskopiert.
Ich habe alles genau nach Franks Anleitung durchgeführt und konnte den Exchange 2016 ohne Probleme neu aufsetzen.
Mein Glück war dass der Datenbankpfad etc. auf einer anderen Partition lag.
Gruß Dominic
Fehler gefunden: falschen pfad kopiert :(
da es leider keine antworten gibt:
ist es auch möglich einen zweite exchange (gleiche version) zu installieren um dann einfach die datenbanken zu verschieben?
danke
Nochmals zum Thema DAG.
Kann ich einen Server aus der DAG entfernen, das Konto des Servers zurücksetzen und anschließend den Server neu installieren und dann wieder in die DAG aufnehmen und so dann mit allen weiteren Servern in der DAG verfahren?
Dann würde ich mir das Sichern der Mailboxdatenbanken sparen können.
VG Gregor
Die Frage interessiert mich auch..haben auch zwei Server als DAG.
Vorgehen wäre dann
1.Server aus der dag entfernen
2. Server nach der Anleitung oben neu machen
3. zur dag hinzufügen
4. gleiches Spiel mit dem anderen Server
So wäre keine down Time vorhanden und alles einmal auf neu
Dateien haben wir keine, aber logeinträge und neu machen ist mir da doch lieber
Hallo Jens,
innerhalb einer DAG lassen sich die Server entsprechend „austauschen“:
1 DBs auf Server passiv schalten
2 Server neuisntallieren nach Anleitung
3 Reseed der DBs
4 Mit den weiteren Servern bei Punkt 1 beginnen
Gruß,
Frank
Danke Frank.
Gibt es eine Empfehlung den Server erst aus der DAG zu entfernen oder drin zu lassen weil er ja am Ende wieder der „gleiche“ ist?
Hallo Gregor,
gleiches Spiel wie bei Jens:
1 DBs auf Server passiv schalten
2 Server neuisntallieren nach Anleitung
3 Reseed der DBs
4 Mit den weiteren Servern bei Punkt 1 beginnen
Gruß,
Frank
Hallo,
Bei uns sind ein Teil unserer Kunden betroffen bzw. zeigen Anzeichen dass etwas versucht wurde. In den meisten Fällen wurden die Angriffe von der UTM/Firewall geblockt und kamen nicht bis zum Exchange-Server durch. (Die meisten Kunden machen ihre Updates selbst und melden sich erst wenn sie nicht mehr weiterkommen)
Leider waren sie bei einem Kunden erfolgreich und konnten sich dort einnisten. Nach Analyse verschiedener Logs wird nach erfolgreicher Kompromittierung eine Verbindung zu 198.98.61.152 aufgebaut und es werden dorthin minimal Daten übertragen. Gleichzeitig geht über einen Prozess mit der svchost.exe die CPU-Auslastung auf 100%. Dies hat in der Nacht von Dienstag auf Mittwoch angefangen. Ich hab den Server dann so schnell wie möglich von der restlichen Netzwerkstruktur isoliert und die Serverumgebung überprüft. Hier wurde weiter nichts auffälliges gefunden.
Nun komme ich an den Punkt der „Exchange Server Neuinstallation“.
Es ist eine vollständige Datensicherung vom 27.02.2021 vorhanden. Jedoch ist der Server neben Exchange auch noch Domänencontroller mit allen Betriebsmasterrollen und macht auch DHCP sowie DNS. (Mehrere DCs sind vorhanden)
Hier bin ich mir jetzt unsicher wie ich genau vorgehen soll, da ich ein solches Szenario noch nie hatte.
Kann ich den kompletten Server aus den Datensicherung wiederherstellen, vorher die zweite virtuelle Festplatte mit den aktuellen Exchange-Datenbanken abtrennen und diese danach einfach wieder verbinden? Oder ist es sehr viel komplizierter?
Für jeden, noch so kleinen, Tipp bin ich sehr dankbar.
Grüße
Moin Dominic,
da hast du ja den Jackpot.
Da du mehrere DC’s hast, würde ich die FSMO Rollen an einen anderen übertragen und anschließend die DC-Rolle deinstallieren, damit dieser aus dem AD raus ist. DHCP würde ich ebenfalls fix auf einen anderen packen.
Anschließend würde ich die VM herunterfahren, einen Snapshot erstellen und eine Neuinstallation des OS und Exchange probieren.
Dann hast du den gleichen Server (denk an gleiche IP und Servernamen, sowie den Exchange-Installation-Pfad) jedoch nur mit Exchange.
Dank des Snapshots kannst du notfalls zurückrollen, sollte dies nicht klappen.
VG Joy
Hallo Joy,
Vielen Dank für die Tipps. Daran hatte ich vor lauter Schlafmangel überhaupt nicht gedacht.
Mache mich gerade daran den Server neu zu machen. Hab sogar noch bisschen Glück dass die FSMO-Rollen doch auf einem anderen DC liegen und der DHCP als Cluster läuft. Alles weitere sollte dann nicht mehr so ein großer Aufwand sein.
Gruß Dominic
So, kurze Abschluss-Info:
Exchange-Server läuft wieder. Hatte keinen großartigen Probleme beim neu aufsetzen. Einzig bei der Domäneneinbindung des „neuen“ Servers kam immer wieder eine Fehlermeldung, welche aber darauf zurück zu führen war dass der „alte“ Server noch als Replikations-DC unter AD-Standorte und Dienste war obwohl ich ihn ordnungsgemäß heruntergestuft hatte. Nachdem ich diesen Eintrag gelöscht hatte lief alles weitere ohne Probleme und Fehler durch. Die meiste Zeit war der Installation von Server und Exchange zuschauen sowie bei den Updates.
Danke nochmal Joy für deine Tipps und an Frank für die super Anleitung, welche bei meinem Exchange 2016 funktioniert hat.
Gruß Dominic
Hi Dominic,
kannst du eventuell kurz erläutern, wie genau sie sich eingenisten haben? In welchen Logs hast du die Datenübertragung gesehen?
Ich danke dir.
VG Seb
Hallo Seb,
jetzt komme ich endlich dazu zu antworten.
Ich hab „nur“ im Ressourcenmonitor gesehen dass die svchost.exe 100% CPU-Auslastung hat und dann über die PID gesehen dass an die o.g. IP-Adresse dauerhaft minimal Traffic (12 B/s) läuft. Habe dann in der Firewall den kompletten Netzbereich (sowie alle anderen momentan bekannten IP-Adressen) blockiert und dann das wininit-Script in der Aufgabenplanung gelöscht.
Gruß Dominic
Nur zur Info für VM-Umgebungen mit intel Prozessoren in den Hostsystemen:
Wenn an einem virtuellen Exchange Server Scripte injiziert wurden, dann kann sich ein Angreifer auch ohne Internetverbindung und trotz Trennung vom Netzwerk (es kommt auf die injizierten Scripte an) sich durch die intel Foreshadow Sicherheitslücke Zugriff auf das Hostsystem verschaffen und sich von dort aus mittels ZombieLoad und/oder RIDL/LVI ausbreiten (Davon sind aktuell noch alle Intel CPUs betroffen, auch die neusten der sämtliche Xeon-Reihen). Dafür ist kein physischer Zugriff auf das kompromittierte System nötig, wie es mit Spectre und Meltdown der Fall ist.
Hallöchen,
auch wir müssen unseren Server neu aufsetzen und da kommt diese Anleitung hier zur richtigen Zeit,
herzlichen Dank dafür !!!
Eine Frage hätte ich: Wir haben momentan Windows Server 2016 + Exchange Server 2016. Kann man das jetzt
auf Windows Server 2019 + Exchange Server 2019 mit Hilfe dieser Anleitung gleich mit upgraden oder geht das nur mit
den identischen Systemen also 2016 ?
Viele Grüße
Klaus Skibowski
Moin Klaus,
laut Franky und auch docs.microsoft.com müssen es die identischen Versionen sein.
VG Joy
Hallo,
ich habe einen Exchange 2016 CU21 Mar22SU, bei dem ich die Recovery-Installation durchführen will.
Kann ich denn zumindest gleich Exchange 2016 CU23 installieren?
Oder muss ich einen CU21 installieren, den auf Mar22CU aktualisieren und dann erst die Datenbank einbinden?
Hallo zusammen,
wie sieht es eigentlich bei einem Exchange im Hybrid Modus aus.
Wie ist hier die beste Vorgehensweise den Server neu zu machen?
Neuen Server parallel in bestehende Organisation installieren, danach alles wie bei einer Migration verschieben, dann den alten entfernen.
Danke für im Voraus für eine Info
Hallo,
vielen herzlichen Dank für diese Anleitung!
Ich hätte eine laienhafte Frage zur Neuinstallation und zwar konkret zu dem Punkt „Nachdem das Konto zurückgesetzt wurde, wird der Server neu installiert.“
Bedeutet das Windows von dem jeweiligen Image darüber installiert werden muss?
Vielen Dank!
Gruß
Peter
Dank funktionierender Backups konnten wir eine Abkürzung nehmen und die Server äußerst schnell wiederherstellen.
Unsere Exchange-Server laufen (zum Glück) auf VMs, was noch einmal viel Zeit gespart hat.
Schritt 1: Netzwerkzugang möglichst trennen
Schritt 2: Sichern der aktuellen Datenbank (z.B. auf Hyper-V host)
Schritt 3: Wiederherstellen eines Backups von vor dem Angriff
Schritt 4: Sicherheitsmaßnahmen, wie z.B. Passwort ändern – je nach eurem System
Schritt 5: Exchange (oder ganze VM) abschalten
Schritt 6: Datenbank des Backups durch neuere ersetzen (einfach an die selbe stelle kopieren)
Schritt 7: Exchange wieder starten
Dank dem Backup sind also alle Nutzer und auch das Zertifikat noch vorhanden.
Gibt es irgendeinen Grund das nicht so zu handhaben?
Falls nicht hilft das vielleicht ja auch anderen.
Moin,
Danke wieder einmal für den Top-Artikel!
Diesen Artikel haben wir für sehr wertvoll empfunden und dies direkt bei einem Exchange 2013 probiert. Leider erfolglos.
Die Datenbanken waren nicht mehr mountbar und sind bei jedem Mount-Versuch immer wieder in „Dirty Shutdown“ gelandet.
Soft-Recovery (eseutil /r) konnte die DB’s wieder auf „Clean Shutdown“ setzen – nächster Mount-Versuch wieder Dirty..
Wir mussten nun einen Rollback machen und laufen wieder mit dem kompromittierten System.
Viele Grüße,
Joy
Ich hätte eine Frage.
Wenn ich Exchange 2013 CU23 und KB5000871 installiere. Bin ich dann komplett sicher?
Oder müssen die vorherigen Security Updates für CU23 ebenfalls installiert werden?
Könntet ihr vielleicht auch berichten wo ihr welche Befehle oder so gefunden habt, dann kann man gezielt danach schauen.
Keine Webshell, auch keine get-Befehle im Log, aber im Log der Ankermailbox, also autodiscover, stand ein verschlüsselter Befehl:
2021-03-04T00:39:07.237Z,da1517ce-8659-45d2-85a2-5d84a9d455a8,15,2,792,5,,Negotiate,true,NT-AUTORITÄT\SYSTEM,,ExchangeServicesClient/0.0.0.0,182.18.152.105,SERVER01,SERVER01.domain.loc,POX/OutlookAutoDiscoverProvider,200,,0,0,1,,,,,GlobalThrottlingPolicy_482f821a-7d81-48b3-964a-4d53f7e850a5,,,156,2,0,2,130,19,330,ADSessionSettingsFromAddress=0;ADRecipientSessionFindBySid=2 9655;Caller=null;ResolveMethod=FoundBySMTP;RequestedRecipient=11d5fefb-c6ca-4636-a3ab-28d63cc5271a;RequestedRecipientType=UserMailbox;RequestedRecipientTypeName=ADUser;RecipientDatabase=MAILBOX-DB-TEAM;ExchangePrincipal=administrator@domain.loc;epSite=domain.loc/Configuration/Sites/K-SOMEWHERE;epServer=SERVER01.domain.loc;SkipST=False;GrpInfo=K-SOMEWHERE;MbxGuid=18fa9c49-1dad-45f8-8498-aecce5e1843a;vdirSrc=SERVER01;vdirSrc=SERVER01;vdirSrc=SERVER01;Team=True;delegates=13;MapiHttpEnabledSource=NotRequested;S:ServiceCommonMetadata.RequestSize=347;S:WLM.Bal=299916;S:WLM.BT=Ews;S:BudgetMetadata.MaxConn=27;S:BudgetMetadata.MaxBurst=300000;S:BudgetMetadata.BeginBalance=300000;S:BudgetMetadata.Cutoff=0;S:BudgetMetadata.RechargeRate=1800000;S:BudgetMetadata.IsServiceAct=False;S:BudgetMetadata.LiveTime=00:00:00;S:BudgetMetadata.EndBalance=299916;Dbl:WLM.TS=330;Dbl:BudgUse.T[]=167.986602783203;I32:VCGS.C[SERVER01]=6;Dbl:VCGS.T[SERVER01]=0;I32:ADS.C[DC02]=3;F:ADS.AL[DC02]=8.755466;I32:ADR.C[DC02]=6;F:ADR.AL[DC02]=10.74802;I32:ATE.C[DC02.domain.loc]=7;F:ATE.AL[DC02.domain.loc]=0.5714286;I32:ATE.C[DC01.domain.loc]=20;F:ATE.AL[DC01.domain.loc]=0.1;I32:ADR.C[DC01]=10;
F:ADR.AL[DC01]=3.57847;I32:ADS.C[DC01]=13;F:ADS.AL[DC01]=1.247415,,,,2452,1_63_64_61_62_62_62_4_65_67_61_59_6_12_75_22_23_167_82_145_83_86_89_91_95_96_97_94_201_180_102_149_196_103_165_104_166_105_189_106_184_182_152_183_182_151_185_182_182_182_152_151_107_109_184_182_152_183_182_151_185_182_182_182_152_151_163_198_199_155_164_147_161_184_182_152_183_182_151_185_182_182_152_151_74_74_110_187_182_181_181_111_115_116_117_118_169_119_112_170_182_152_182_171_114_170_182_152_182_171_120_112_119_121_175_176_178_186_182_152_179_182_151_152_193_192_148_177_174_186_182_152_182_153_151_151_152_190_114_119_121_175_176_178_186_182_152_152_179_182_151_193_192_148_177_174_186_182_152_152_182_153_151_151_190_127_144_154_155_156_156_128_186_182_152_182_153_151_151_152_186_182_152_152_182_153_151_151_198_129_194_134_197_194_134_197_194_134_197_194_134_197_194_134_197_194_134_197_194_134_197_194_134_197_194_134_197_194_134_197_194_134_197_194_134_197_132_129_138_139_140_142_15_33_42_24_50_52_169_55_56_57_206_2,2021-03-04T00:39:06.906Z,156,159,156,156,159,330
Da hier die DCs mit auftauchen und ich keine Ahnung habe, wie man aus der Zahlenfolge was Lesbares hinbekommt, könnte es sein, dass eine Wiederherstellung des Exchange Servers nicht ausreicht.
Viele Grüße
Olaf
Falls jemand in das gleiche Problem läuft: ich habe zwar keine Erklärung für … local 2, aber ich bin nun aus Zeitgründen hingegangen und habe erneut das Konto resettet, die Systempartition noch einmal weggeschmissen und den Installationsschritt wiederholt. Wunder der IT, jetzt bekomme ich ein „normales“ Domänenprofil im Netzwerk angezeigt. Btw. ist es wohl tatsächlich so, dass ein AD rejoin eine neue SID generiert und das wär mir eh zu heikel, sind doch Namen nur „Schall und Rauch“ für Microsoft.
Hallo Frank,
tausend Dank für die Anleitung!
Ein Netzwerk konnte ich nach dem Artikel bereits wieder Online nehmen.
Bei einem 2. hänge ich gerade an einem Problem.
Neuer Server (Hyper V 2012 R2) ist installiert und in Domäne, Updates drauf. Eigentlich möchte ich nun mit Exchange beginnen.
Die Netzwerkverbindung am Server zeigt mir aber „Domäne.local 2“ dahinter steht auch nichts von wegen „nicht authentifiziert“, sondern nur „Domäne.local 2“
DNS geht, pingen, Server in Domäne, verwaltbar. Aber gut finde ich das trotzdem nicht.
Ich würde bei einem frischen System den einfach noch einmal aus der Domäne nehmen und nach Neustart wieder rein.
Ich bin mir aber hier nicht sicher, ob das „raus und wieder rein“ ein Unterschied zu „Konto zurücksetzen“ ist, Stichwort Reset vielleicht gleiche System SID, aber bei raus und rein eine neue und dann klappt das Recover nicht etc.
Kann mir da jemand die Sorge, oder gar Erklärung für …local 2 geben?
Besten Dank.
Moin Dirk,
aus der vmware Welt oder auch Notebooks kenne ich dies!
Wenn du bei einem Notebook per LAN im „Domäne.local“ Netzwerk bist und dann mit dem WLAN das gleiche Netz betrittst wird dies als „Domäne.local 2“ angezeigt.
VG Joy
Moin Joy,
ist eine Hyper V Umgebung. Und dort gibt es nur den einen virt. Switch, kein WLAN oder weitere Netze.
Fällt wohl mal wieder in die Kategorie, „mach es einfach noch einmal genauso und beim 2. Mal geht’s“. :-/
Hallo zusammen,
was haltet ihr davon einen 2ten Exchange Server aufzusetzen und die Mailboxen zu migrieren ?
Danach den alten ausnehmen und abschalten ?
Moin Thomas,
bei der Idee schließe ich mich an und wir haben dies auch im Kopf.
Aber… Infiziert sich der zweite Exchange während der einige Stunden/Tage neben dem kompromittierten System steht? Das ist noch in meinem Hinterkopf.
VG Joy
ich bin auch am überlegen ob das nicht besser wäre, da bei uns sowieso das Upgrade von 2016 auf 2019 ansteht. Vorteil wäre halt eine sehr geringe Downtime. Während der Migration am kompromittierten Server alle Ports bis auf 25 nach außen blockieren, dann sollte das Risiko relativ gering sein. Was mir aber sorgen bereitet: laut den Logs wurde ein neues OabVirtualDirectory angelegt, was ich schon gelöscht habe, man weiß aber nicht was sonst noch so passiert ist. Kann es sein dass bei einer Migration der Schadcode mit migriert wird?
Hallo Frank
Ich bei der Recovery Installation in einen Fehler gelaufen bei der Hub Transport Rolle.
[03.09.2021 11:39:32.0346] [2] Beginning processing Write-ExchangeSetupLog
[03.09.2021 11:39:32.0346] [2] [ERROR] Failure configuring SearchFoundation through installconfig.ps1 – Old nodes belonging to the system ‚Fsis‘, already exist in ‚D:\Exchange Server\Bin\Search\Ceres\HostController\Data‘. Rerun the configuration in attach mode, if you need to reuse them.
[03.09.2021 11:39:32.0346] [2] [ERROR] Failure configuring SearchFoundation through installconfig.ps1 – Old nodes belonging to the system ‚Fsis‘, already exist in ‚D:\Exchange Server\Bin\Search\Ceres\HostController\Data‘. Rerun the configuration in attach mode, if you need to reuse them.
[03.09.2021 11:39:32.0346] [2] Ending processing Write-ExchangeSetupLog
[03.09.2021 11:39:32.0612] [1] The following 1 error(s) occurred during task execution:
[03.09.2021 11:39:32.0612] [1] 0. ErrorRecord: Failure configuring SearchFoundation through installconfig.ps1 – Old nodes belonging to the system ‚Fsis‘, already exist in ‚D:\Exchange Server\Bin\Search\Ceres\HostController\Data‘. Rerun the configuration in attach mode, if you need to reuse them.
[03.09.2021 11:39:32.0612] [1] 0. ErrorRecord: System.Exception: Failure configuring SearchFoundation through installconfig.ps1 – Old nodes belonging to the system ‚Fsis‘, already exist in ‚D:\Exchange Server\Bin\Search\Ceres\HostController\Data‘. Rerun the configuration in attach mode, if you need to reuse them.
bei Microsoft.Exchange.Configuration.Tasks.Task.ThrowError(Exception exception, ErrorCategory errorCategory, Object target, String helpUrl)
bei Microsoft.Exchange.Management.Deployment.WriteExchangeSetupLog.InternalProcessRecord()
bei Microsoft.Exchange.Configuration.Tasks.Task.b__91_1()
bei Microsoft.Exchange.Configuration.Tasks.Task.InvokeRetryableFunc(String funcName, Action func, Boolean terminatePipelineIfFailed)
[03.09.2021 11:39:32.0690] [1] [ERROR] The following error was generated when „$error.Clear();
if ($RoleProductPlatform -eq „amd64“)
{
try
{
# Need to configure the ETL traces before the fast service is installed. This will ensure that when the service comes up
# it will have the necessary trace session setting available to read from the registry
$fastPerfEtlTraceFolderPath = Join-Path -Path $RoleBinPath -ChildPath „\Search\Ceres\Diagnostics\ETLTraces“
$fastDiagnosticTracingRegKeyPath = ‚HKLM:\SOFTWARE\Microsoft\Office Server\16.0\Search\Diagnostics\Tracing‘
if(-not(Test-Path -Path $fastPerfEtlTraceFolderPath))
{
$null = New-Item $fastPerfEtlTraceFolderPath -Type ‚Directory‘ -Force
}
if (-not(Test-Path -Path $fastDiagnosticTracingRegKeyPath))
{
$null = New-Item -Path $fastDiagnosticTracingRegKeyPath -Force
}
$null = New-ItemProperty -Path $fastDiagnosticTracingRegKeyPath -Name ‚TracingPath‘ -PropertyType ’string‘ -Value $fastPerfEtlTraceFolderPath -Force
$null = New-ItemProperty -Path $fastDiagnosticTracingRegKeyPath -Name ‚TracingFileName‘ -PropertyType ’string‘ -Value ‚DocumentProcessingTrace‘ -Force
$null = New-ItemProperty -Path $fastDiagnosticTracingRegKeyPath -Name ‚DocumentParserSuccessLogMessage‘ -PropertyType ‚Dword‘ -Value 1 -Force
$null = New-ItemProperty -Path $fastDiagnosticTracingRegKeyPath -Name ‚DocumentParserLoggingNoInitialisation‘ -PropertyType ‚Dword‘ -Value 1 -Force
# Max trace folder size 50 * 100 = 5GB
$null = New-ItemProperty -Path $fastDiagnosticTracingRegKeyPath -Name ‚MaxTraceFileSize‘ -PropertyType ‚Dword‘ -Value 50 -Force
$null = New-ItemProperty -Path $fastDiagnosticTracingRegKeyPath -Name ‚MaxTraceFileCount‘ -PropertyType ‚Dword‘ -Value 100 -Force
$null = New-ItemProperty -Path $fastDiagnosticTracingRegKeyPath -Name ‚UseGeneralSwitch‘ -PropertyType ‚Dword‘ -Value 1 -Force
$null = New-ItemProperty -Path $fastDiagnosticTracingRegKeyPath -Name ‚GeneralSwitch‘ -PropertyType ‚Dword‘ -Value 0 -Force
}
catch
{
# ETl tracing is not critical. Info only log
Write-ExchangeSetupLog -Info („An exception ocurred while trying to Configure the FAST ETL traces. Exception: “ + $_.Exception.Message);
}
$fastInstallConfigPath = Join-Path -Path $RoleBinPath -ChildPath „Search\Ceres\Installer“;
$command = Join-Path -Path $fastInstallConfigPath -ChildPath „InstallConfig.ps1“;
$dataFolderPath = Join-Path -Path $RoleBinPath -ChildPath „Search\Ceres\HostController\Data“;
try
{
# the BasePort value MUST be kept in sync with dev\Search\src\OperatorSchema\SearchConfig.cs
&$command -action i -baseport 3800 -dataFolder $dataFolderPath -silent;
}
catch
{
$errorMsg = „Failure configuring SearchFoundation through installconfig.ps1 – “ + $_.Exception.Message;
Write-ExchangeSetupLog -Error $errorMsg;
# Clean up the failed configuration attempt.
&$command -action u -silent;
try
{
if ([System.IO.Directory]::Exists($dataFolderPath))
{
[System.IO.Directory]::Delete($dataFolderPath, $true);
}
}
catch
{
$deleteErrorMsg = „Failure cleaning up SearchFoundation Data folder. – “ + $dataFolderPath + “ – “ + $_.Exception.Message;
Write-ExchangeSetupLog -Error $deleteErrorMsg;
}
}
# Set the PowerShell Snap-in’s public key tokens
try
{
$PowerShellSnapinsPath = „HKLM:\SOFTWARE\Microsoft\PowerShell\1\PowerShellSnapIns\“;
$FastSnapinNames = @(„EnginePSSnapin“, „HostControllerPSSnapIn“, „InteractionEnginePSSnapIn“, „JunoPSSnapin“, „SearchCorePSSnapIn“);
$officePublicKey = „71E9BCE111E9429C“;
$exchangePublicKey = „31bf3856ad364e35“;
foreach ($fastSnapinName in $FastSnapinNames)
{
$fastSnapinPath = $PowerShellSnapinsPath + $fastSnapinName;
$assemblyNameProperty = Get-ItemProperty -Path $fastSnapinPath -Name „AssemblyName“ -ErrorAction SilentlyContinue;
if ($assemblyNameProperty -ne $null -and (-not [string]::IsNullOrEmpty($assemblyNameProperty.AssemblyName)))
{
$newAssemblyName = $assemblyNameProperty.AssemblyName -ireplace ($officePublicKey, $exchangePublicKey);
Set-ItemProperty -Path $fastSnapinPath -Name „AssemblyName“ -Value $newAssemblyName;
}
}
}
catch
{
# Info only log
Write-ExchangeSetupLog -Info („An exception ocurred while configuring Search Foundation PowerShell Snapin. Exception: “ + $_.Exception.Message);
}
}
“ was run: „System.Exception: Failure configuring SearchFoundation through installconfig.ps1 – Old nodes belonging to the system ‚Fsis‘, already exist in ‚D:\Exchange Server\Bin\Search\Ceres\HostController\Data‘. Rerun the configuration in attach mode, if you need to reuse them.
bei Microsoft.Exchange.Configuration.Tasks.Task.ThrowError(Exception exception, ErrorCategory errorCategory, Object target, String helpUrl)
bei Microsoft.Exchange.Management.Deployment.WriteExchangeSetupLog.InternalProcessRecord()
bei Microsoft.Exchange.Configuration.Tasks.Task.b__91_1()
bei Microsoft.Exchange.Configuration.Tasks.Task.InvokeRetryableFunc(String funcName, Action func, Boolean terminatePipelineIfFailed)“.
[03.09.2021 11:39:32.0690] [1] [ERROR] Failure configuring SearchFoundation through installconfig.ps1 – Old nodes belonging to the system ‚Fsis‘, already exist in ‚D:\Exchange Server\Bin\Search\Ceres\HostController\Data‘. Rerun the configuration in attach mode, if you need to reuse them.
[03.09.2021 11:39:32.0690] [1] [ERROR-REFERENCE] Id=SearchFoundationComponent___9f5053e82ecb4a8f9790bdf498c0664d Component=EXCHANGE14:\Current\Release\Shared\Datacenter\Setup
[03.09.2021 11:39:32.0690] [1] Setup is stopping now because of one or more critical errors.
[03.09.2021 11:39:32.0690] [1] Finished executing component tasks.
[03.09.2021 11:39:32.0737] [1] Ending processing DisasterRecovery-BridgeheadRole
[03.09.2021 11:39:32.0737] [0] CurrentResult console.ProcessRunInternal:198: 1
[03.09.2021 11:39:32.0737] [0] CurrentResult launcherbase.maincore:90: 1
[03.09.2021 11:39:32.0737] [0] CurrentResult console.startmain:52: 1
[03.09.2021 11:39:32.0737] [0] CurrentResult SetupLauncherHelper.loadassembly:452: 1
[03.09.2021 11:39:32.0737] [0] Setup von Exchange Server wurde nicht abgeschlossen. Weitere Details finden Sie im Protokoll ‚ExchangeSetup.log‘ im Ordner ‚:\ExchangeSetupLogs‘.
[03.09.2021 11:39:32.0737] [0] CurrentResult main.run:235: 1
[03.09.2021 11:39:32.0737] [0] CurrentResult setupbase.maincore:396: 1
[03.09.2021 11:39:32.0752] [0] End of Setup
[03.09.2021 11:39:32.0752] [0] **********************************************
Fehler gefunden
Diese aus der Registry löschen, danach die Recovery Installation neu starten und es läuft durch.
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ExchangeServer\v15\HubTransportRole]
„UnpackedVersion“=“15.1.2176.2“
„Action“=“DisasterRecovery“
„Watermark“=“SearchFoundationComponent___9f5053e82ecb4a8f9790bdf498c0664d“
Danke noch mal für die Anleitung.
Danke für deine Antwort – hatte nämlich das selbe Problem.
Aber wie kommt man auf den Pfad? Habe das LOG überprüft – Leider ohne Erfolg :-(
Ein Hallo ins Forum,
auch wir waren betroffen. Mein Lösungsweg war:
– Maschine vom Netz
– Restore eines Snapshots älter als 4 Wochen von „System“ (hier C:) und „Exchange Server“ (hier J:).
– Exchange DB und Logs liegen ebenfalls auf separaten Volumes und wurden beibehalten.
– Patchen
Schauen wir mal, was in den nächsten Tagen passiert ;-)
Viele Grüße & herzlichen Dank,
Stefan
Hallo Zusammen,
wir konnten hier auf zwei Exchange-Server auch die Skripte nachweisen. Keine Frage Neuinstallation ist das Beste (werden wir auch tun). Nur mal zum Verständnis: Die Skripte wurden so wie ich das verstehe automatisiert auf dem System in rasender Geschwindigkeit abgelegt. Der Spuk war meisten nach Sekunden schon vorbei. So wie ich den Microsoft-Artikel interpretiere, war das der erste Schritt. Im zweiten Stepp wurden die Skripte von einer Person ausgeführt und alles zum Abzapfen vorbereitet. Wenn sich auf den Systemen keinerlei Hinweise des Ausführens zeigen, dann wäre doch theoretisch die Gefahr nach Löschen der Skripte auch gebannt?
Danke & Grüße
Lars
Hallo Lars,
ja, das kann so sein, aber NIEMAND würde dafür garantieren (können)…
Ein nicht unerhebliches Restrisiko bleibt also…
Grüße, Jens
Hallo,
unser 2013er Exchange ist auch betroffen. Wir nutzen allerdings eine hybdride Umgebung und leider war die OWA wohl erreichbar von extern.
Kann man auch einen 2019er nun aufsetzen und dann den 2013er gleich ablösen und das mit diesem Vorgang direkt umsetzen oder würdet ihr hier einen andere Lösung empfehlen?
Vielen Dank,
Bernd Nordlohne
Hallo Frank,
könntest du ggf. einmal in einem Artikel darlegen, wie man nach der Installation eines Exchange 2019er Servers IPv6 korrekt abstellt?
Ich habe das nun mehrfach versucht und erhalte dann keinen Zugriff mehr auf die EMS. Mailversand etc funktioniert.
Über das Healthchecker Tool von MS bin ich darauf gestoßen, dass das auch von MS recommended ist, es abzudrehen.
Vielen Dank vorab.
Ich habe den Exchange komplett neu aufgesetzt, Neuinstallation lief auch fehlerfrei durch. Leider lassen sich jetzt den vorhandenen Usern keine Mailboxen zuordnen. Da muss irgendwo noch etwas vom altem exchange die Zuordnung blockieren.
Hintergrund war, das der Exchange bei der Update-Installation crashte und mir eine saubere Neuinstallation lieber war.
Weiß jemand, wie ich die User wieder angebunden bekomme? Das Problem gibt es auch nur bei Usern, welche vorher am alten Exchange angemeldet waren.
Hallo,
was muss dann nachträglich auf jeden Fall manuell angepasst werden? Mindestens doch web.config-Einstellungen oder?
Toller Artikel, echt klasse in der kurzen Zeit. Mit ist allerdings unklar wie das nun funktioniert wenn eine DAG im Einsatz ist. Eventl. könnte man das in der Anleitung noch näher erläutern.
Hallo Frank,
vielen Dank für den Artikel, er hat uns sehr geholfen!
Gruß
Marvin
Mich würde mal interessieren wieso ihr so sicher seid, dass nichts anderes in Mitleidenschaft gezogen wurde? Dazu habe ich noch nichts gefunden.
Ich hab bei uns auf dem Exchange die Shell gefunden und den Server offline genommen. Allerdings bin ich mir nicht sicher, dass die Angreifer nicht weiter vorgedrungen sind. Zumal der Exchange ja tiefgreifende AD Rechte hat.
Insofern wird die Domäne jetzt komplett neu aufgesetzt. Zum Glück waren die Server in einem separaten Netz.
PS: falls sich einer Fragen sollte warum der Patch nicht eingespielt war. Der Angriff erfolgte vor der Veröffentlichung des Patches.
Wenn ich eine Webshell finden würde, würde ich wahrscheinlich alles neu machen.
Hi,
wenn ich aber ein Backup habe und ich mir sehr sicher sein kann, dass der Exchange-Server am 03.03. kompromitiert wurde, kann ich doch einfach den kompletten Server recovern, den aktiven vorher backupen, Mailflow stoppen und herunterfahren und vom Netz trennen und dann die virtuelle Disk dem recoverten Server zeigen und die EDBs kopieren, oder?
Die Frage würde mich auch sehr interessieren. Ich hätte ein älteres Backup genommen, zurückgespielt Datenbank getrennt und wie oben beschrieben den letzten aktuellen Datenbank Stand (edb + protokolle) manuell kopiert und wieder eingefügt.
Gibt es daran etwas auszusetzen? Exchange 2016 CU19.
Gruß René
Sali René
nein so habe ich es auch gemacht. Zugriff von Aussen gesperrt und dann wie oben beschrieben gemacht.
Gruss
Adi
Hallo, ich bin gerade dabei es so zu machen.
Welche Logs meint Ihr die in dem Httpproxy ? ich hatte vor einfach nur die Ornder in denen die Mailboxdatenbanken sind, welche ich vorher mit Veeam komplett gesichert habe, dann wieder in das vorher mit Veeam Rückgesicherte System an den gleichen Ort zu schieben. Auch mit Veeam.
Hallo Frank,
toller Artikel! Wenn man ihn nicht im Moment braucht dann (hoffentlich nicht ) eventuell später mal.
Vielen Dank1
Moin Frank,
danke für die Anleitung. Ich wollte gerne wissen, ob es auch möglich wäre bei einer DAG einen Server neu zu installieren und danach den anderen Server, damit dadruch keine Downtime entsteht. Wäre sowas möglich oder doch keine gute Idee?
Gruß
Umut
Du könntest im Zweifel einen Server aus der DAG nehmen, neu installieren und wieder zur DAG hinzufügen…
Moin Frank,
tolle Aktion so schnell so eine Anleitung raus-zugeben. Dürfte sicherlich dem einen oder andere betroffenen helfen. Ich lerne dadurch jetzt auch wie ich einen Exchange ohne Backup wiederherstellen kann, tolle Option. Bis jetzt war die Strategie DAG mit Intervallbackups. Und immer das Risiko wenn das Backup nicht will.
Ich frage mich warum es nicht so etwas in Form von Büchern gibt… streng genommen ist dein Blog immer mein erster Anlaufpunkt wenn ich etwas zu Exchange 2016 wissen will oder muss.
Also vielen Dank für deine Mühe und bitte weiter so.
Gruß
Alex
Hi,
wieso gibt es keine Bücher? Also ich bin mir ziemlich sicher, dass im Schrank auf Arbeit welche stehen… Und auch bei Microsoft selbst ist die entsprechende Dokumentation vorhanden…
Allerdings nicht so schön beschrieben.
Und bei mir auf dem Schreibtisch liegt auch noch Microsoft Exchange Server 2019, das Handbuch für Administratoren…
Rheinwerk Verlag von Thomas Stensitzki … https://www.amazon.de/Microsoft-Exchange-Server-2019-Administratoren/dp/3836256436/ref=sr_1_1?__mk_de_DE=%C3%85M%C3%85%C5%BD%C3%95%C3%91&dchild=1&keywords=Microsoft+Exchange+server+2019+handbuch&qid=1615197535&sr=8-1
Guten Morgen Frank,
vielen Dank für den tollen Artikel, wie auch für alle anderen.
Ich habe mit dem MS Testscript tatsächlich 2 Hinweise auf Versuche gefunden, die mir auf den ersten Blick aber erfolglos schienen.
Auch das MS Malware Scantool, welches ja für den Exchange-Vorfall erweitert wurde, hat nicht gefunden
Nichts desto trotz habe ich natürlich kein gutes Gefühl mehr…
Ich denke ich versuche mich erstmal daran, den Exchange aus dem Veeam Backup von vor einer Woche wiederherzustellen, den Patch zu installieren und dann die Festplatte mit der aktuellen Datenbank in die neue Maschine zu übernehmen…
Mal schauen wie das klappt.
Hi Jörg,
kannst du schon von deiner Variante Berichten?
Die würde mir persönlich am besten gefallen, weil man sich doch einiges an Konfigurationsarbeit spart
LG
Daniel
Hallo Zusammen
Wenn die Mailboxdaten auf dem Laufwerk D: liegen geht das recht gut so.
Dank gutem Backup konnten wir die System innert kurzer Zeit wieder zurücksetzten.
Vorgehen:
– Herunterfahren der VM. Sichern der des Aktuellen C: Drive
– Schliessen der Firewall.
– Rücksicherung der Disk C. aus Backup vor den Vorfall
– Disk anbinden anstellen des alten C:
– Server Starten, updaten und Patchen
– Testen des Exploit, alles io.
– Firewall wieder auf und weiter geht’s mit mailen
@Franky
Danke noch für die Meldung. War in der glücklichen Lage das mein Hautsystem gleich am 2.3. gepatcht habe und durch deine Newsfeed vorgewarnt war.
LG
Adi
Hallo Adi.
Danke für Deinen Beitrag. Der hat mir sehr geholfen. Denn auf diesem Wege konnten wir den Vorgang doch sehr beschleunigen.
Wir nutzen einen ProxMox-Cluster + vzDump + Veeam Backup. Das vzDump hat mir (leider) nicht geholfen, da ich nicht das gewünschte Datum vorrätig hatte. Deswegen also Veeam. Hier der Weg… vom Prinzip identisch.
a) Firewall geschlossen
b) Exchange DB ausgehängt
c) Shutdown Exchange VM
d) Veeam Volume Restore als VMDK (OS + ExchangeInstallation + LogFiles)
e) VMDK > Konvert > RAW
f) Volumes in VM ersetzt.
g) Start VM
h) Test mit Scripten + Firewall wieder auf
Bei uns sah es gut aus… dann jedoch auch wieder einige Hinweise auf Ausnutzung der Sicherheitslücke.
Jedoch lag mir quer im Magen, dass ich kein definitives Datum sehen konnte.
Ganz am Ende, wie soll es anders sein… kam dann der Gedanke!
ESET-Logs einsehen >> hier wurde…
– das genaue Datum angegeben
– Und auch klar definiert, dass der Angriff von ESET gekillt wurde. ESET war hier extrem schnell mit den Updates!
So sind wir also glimpflich davon gekommen.
Gruß, Lars
Hi Daniel,
sorry, jetzt erst deine Antwort entdeckt…
Hat prima geklappt… Leider etwas langwierig weil der Storage ganz furchtbar langsam ist…
In der Budgetplanung für dieses Jahr ist schon einer drin, und nach der Warterei wird die GF mir den wohl problemlos durchwinken ;)
Also ich habe den alten Exchange per Firewall für HTTP(s) vom Internet genommen.
Interner Zugriff ohne Probleme weiter möglich.
Dann parallel einen Exchange von vor einem Monat wiederhergestellt in ein separiertes Veeam SureBackup Netz.
Einen DC dazu (gleich alt, weil sonst Problem mit dem Maschinen-Account Passwort) und den wiederhergestellten auf das gleiche Patch-Level gebracht wie den aktuellen Exchange.
Dann Abends Exchange heruntergefahren, die vmdk files der Festplatten für Logs und Mailboxe-DBs in den wiederhergestellten Exchange kopiert. Den neuen ins normale Netz genommen und gestartet.
Wichtig: Maschinen-Account zurücksetzen per lokalem Admin, da der Server sonst keine Vertrauensstellung mit der Domäne mehr hat.
Nach Neustart war die Kiste einsatzbereit.
Läuft jetzt einige Tage Problemlos.
Zwar gehören wir zu den Glücklichen, die nicht Betroffen sind, aber richtig guter Artikel und gerade in der aktuell angespannten Zeit für Exchange Admins bestimmt Gold wert.
Und sind wir mal ehrlich: Nach dem Exploit ist vor dem Exploit. Also immer gut so eine Anleitung irgendwo vorrätig zu haben^^
Grüße