Exchange Server: Neuinstallation ohne Datenverlust (Beispielsweise nach Angriff)

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:

image

Die entsprechenden Werte lassen sich beispielsweise einfach in eine TXT Datei kopieren. Ebenfalls wichtig sind die Einstellungen der Empfangsconnectoren:

image

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:

Exchange Server: Neuinstallation ohne Datenverlust (Beispielsweise nach Angriff)

Wenn ihr den Server komplett vom Netzwerk getrennt habt, dann lässt sich das Zertifikat via MMC exportieren:

Exchange Zertifikat sichern

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:

Dienste stoppen

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:

Exchange Datenbank sichern

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:

Computer Account zurücksetzen

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"

Exchange Server: Neuinstallation ohne Datenverlust (Beispielsweise nach Angriff)

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

Wiederherstellung konfigurieren

Jetzt wird die der gesamte Ordner mit der Datenbank vom alten Server wieder zurück an seinen Bestimmungsort kopiert:

Datenbank wiederherstellen

Sobald die Daten kopiert wurden, kann die Datenbank gemountet werden:

Datenbank mounten

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:

Viertuelle Verzeichnisse konfigurieren

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:

Zertifikat importieren

Der Pfad zur gesicherten PFX Datei muss via UNC Pfad angegeben werden:

Zertifikat importieren

Im nächsten Schritt muss nur noch der Server für den Import angegeben werden:

Zertifikat importieren

Jetzt muss das importierte Zertifikat nur noch an die Exchange Services gebunden werden:

Zertifikat importieren

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.

81 Gedanken zu „Exchange Server: Neuinstallation ohne Datenverlust (Beispielsweise nach Angriff)“

  1. 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

    Antworten
  2. 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.

    Antworten
    • 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

      Antworten
      • 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

        Antworten
        • 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.

        Antworten
  3. 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

    Antworten
  4. 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

    Antworten
  5. Hallo Frank,

    toller Artikel! Wenn man ihn nicht im Moment braucht dann (hoffentlich nicht ) eventuell später mal.

    Vielen Dank1

    Antworten
  6. 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?

    Antworten
    • 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é

      Antworten
        • 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.

  7. 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.

    Antworten
  8. 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.

    Antworten
  9. 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.

    Antworten
  10. 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.

    Antworten
  11. 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

    Antworten
  12. 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

    Antworten
    • 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

      Antworten
  13. 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

    Antworten
  14. 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] **********************************************

    Antworten
    • 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.

      Antworten
      • 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 :-(

        Antworten
  15. Hallo zusammen,
    was haltet ihr davon einen 2ten Exchange Server aufzusetzen und die Mailboxen zu migrieren ?
    Danach den alten ausnehmen und abschalten ?

    Antworten
    • 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

      Antworten
    • 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?

      Antworten
  16. 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.

    Antworten
    • 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

      Antworten
      • 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“. :-/

        Antworten
  17. 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.

    Antworten
  18. 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

    Antworten
  19. 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?

    Antworten
  20. 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

    Antworten
  21. 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.

    Antworten
  22. 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

    Antworten
  23. 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

    Antworten
  24. 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

    Antworten
  25. 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.

    Antworten
  26. 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

    Antworten
    • 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

      Antworten
      • 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

        Antworten
        • 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

      Antworten
      • 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

        Antworten
  27. 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

    Antworten
    • 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

      Antworten
      • 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

        Antworten
        • 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

      Antworten
  28. 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

    Antworten
  29. 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 :(

    Antworten
    • 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

      Antworten
  30. Wenn ich nach obiger Anleitung vorgehe, muss ich dann auf den Clients die Outlookprofile neu anlegen oder sollte die Verbindung ohne Neuanlage gleich funktionieren?

    Antworten
  31. 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

    Antworten
  32. 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

    Antworten
  33. 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

    Antworten
  34. 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!

    Antworten
  35. 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?

    Antworten
  36. 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.

    Antworten
  37. 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

    Antworten
    • 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.

      Antworten
  38. 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

    Antworten
  39. 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

    Antworten
  40. 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

    Antworten

Schreibe einen Kommentar