Search-Mailbox: Unerwünschte Mails aus Postfächern suchen/entfernen

Bei einer SPAM-Welle ist es eventuell nötig, dass bestimmte Mails direkt aus dem Postfach der Benutzer entfernt werden müssen. Dazu ist eine Abstimmung mit dem DSB nötig, da es hier um einen direkten Eingriff in die Postfächer geht. Außerdem ist ein sehr umsichtiger Umgang mit diesem Befehl nötig, da durch die Eingabe von fehlerhaften Parametern ganze Postfächer geleert werden können!
Zum Einsatz kommt hier das cmdlet Search-Mailbox, welches von Microsoft offiziell abgekündigt wurde. Dieses wurde offiziell durch das cmdlet New-ComplianceSearch ersetzt, wird aber immer noch onPrem und in der Cloud unterstützt.
Warum verwende ich trotzdem das alte cmdlet?
Da das New-ComplianceSearch keinen DELETE mehr zulässt, sondern nur noch suchen kann (Datenschutzkonform).
Gibt es Beschränkungen des cmdlets?
Search-Mailbox hat eine Begrenzung von 10.000 Ereignissen pro Postfach und muss ggf. mehrfach ausgeführt werden.
Quelle Microsofts Docs: Search-Mailbox (ExchangePowerShell) | Microsoft Docs
Damit man das cmdlet überhaupt ausführen darf sind die zwei folgenden Exchange-Administrator-Rollen für den AD-Benutzer, welches den Befehl ausführt, nötig:
Discovery Management
Exchange Mailbox Import Export

Das cmdlet hat drei Funktions-Modis:
LogOnly = Es wird nur ein Bericht erstellt, aber keine Mail gelöscht/verschoben
ohne Parameter = Es wird ein bericht erstellt und die gefundenen Mails werden in die TargetMailbox kopiert bleiben aber auch im originalen Postfach vorhanden
DeleteContent = Es wird ein bericht erstellt und die gefunden Mails werden in die Target;ailbox verschoben - die Mail ist im originalen Postfach NICHT mehr vorhanden

Der Bericht sieht dann wie folgt aus:

Beispiele
Beispiel 1 - Postfach durchsuchen und nur Bericht erstellen
Hier wird das Postfach von MMustermann durchsucht nach Mails mit dem Betreff "Virus" und Eingang am 07./08.02.2022. Es wird nur ein Bericht erstellt und keine Mails gelöscht oder kopiert. Der Bericht erfolgt an mailadmin@xyz.de im Ordner SPAM
Search-Mailbox -Identity MMustermann -TargetMailbox mailadmin@xyz.de -TargetFolder "SPAM" -SearchQuery {Subject:"Virus" AND received:"07/02/2022..08/02/2022"} -LogLevel Full -LogOnly



Beispiel 2 - Postfach durchsuchen, Bericht erstellen, Mails kopieren, original Mails im Benutzerpostfach nicht löschen
Hier wird das Postfach von MMustermann durchsucht nach Mails mit dem Betreff "Virus" und Eingang am 07./08.02.2022. Es wird ein Bericht erstellt und die Mails in das Postfach mailadmin@xyz.de in den Ordner SPAM kopiert. Der Bericht erfolgt an mailadmin@xyz.de im Ordner SPAM. Die originalen Mails Bleiben beim Benutzer ERHALTEN.
Search-Mailbox -Identity MMustermann -TargetMailbox mailadmin@xyz.de -TargetFolder "SPAM" -SearchQuery {Subject:"Virus" AND received:"07/02/2022..08/02/2022"} -LogLevel Full



Beispiel 3 - Postfach durchsuchen, Bericht erstellen, Mails kopieren, original Mails im Benutzerpostfachr LÖSCHEN
Hier wird das Postfach von MMustermann durchsucht nach Mails mit dem Betreff "Virus" und Eingang am 07./08.02.2022. Es wird ein Bericht erstellt und die Mails in das Postfach mailadmin@xyz.de in den Ordner SPAM verschoben. Der Bericht erfolgt ebenfalls an mailadmin@xyz.de im Ordner SPAM. Die verschobenen Mails werden in Unterordner pro Postfach abgelegt inkl. der Ordner Struktur, in der sie gefunden wurden.
Search-Mailbox -Identity MMustermann -TargetMailbox mailadmin@xyz.de -TargetFolder "SPAM" -SearchQuery {Subject:"Virus" AND received:07/02/2022..08/02/2022} -LogLevel Full -DeleteContent -Force




Beispiel 4 - Postfachdatenbank durchsuchen, Bericht erstellen, Mails kopieren, original Mails im Benutzerpostfach LÖSCHEN
Hier werden alle Postfächer der Postfachdatenbank MBXDB1 nach Mails mit dem Betreff "Virus" und Eingang am 07./08.02.2022 durchsucht. Es wird ein Bericht pro Postfach erstellt und die Mails in das Postfach mailadmin@xyz.de in den Ordner SPAM verschoben. Der Bericht erfolgt ebenfalls an mailadmin@xyz.de im Ordner SPAM. Die verschobenen Mails werden in Unterordner pro Postfach abgelegt inkl. der Ordner Struktur, in der sie gefunden wurden.
Get-Mailbox -Database "MBXDB1" -resultsize unlimited | Search-Mailbox -TargetMailbox mailadmin@xyz.de -TargetFolder "SPAM" -SearchQuery {Subject:"Virus" AND received:07/02/2022..08/02/2022} -LogLevel Full -DeleteContent -Force


Exchange 2016 DAG: Prüfung und Schwenk der DAG-Datenbanken auf den Master (ReBalance DAG)

Das nachfolgende Skript prüft, ob auf dem aktuellen Exchange DAG Server Datenbank laufen, für die er nicht der "Prefered ActiveServer" ist bzw. ob ihm selbst Datenbanken "fehlen", für die er selbst der "Prefered ActiveServer" ist.
Für jede gefundene Datenbank erfolgt eine gesonderte Abfrage, ob diese zurückgeschwenkt werden soll.
Für korrekte Datenbanken erfolgt nur eine Ausgabe. Zur optischen Prüfung werden die Ausgaben farblich mit rot und grün dargestellt:

# Das Skript überprüft den lokalen Server, ob Datenbanken auf dem System gemountet sind,
# welche primär auf einem anderen Server laufen sollten
# Werde solche Datenbanken gefunden, dann werden diese zurückverschoben und das DAG wieder
# in den ausbalancierten Zustand gebracht
#
# Ralf Entner

Add-PSSnapin Microsoft.Exchange.Management.PowerShell.SnapIn
Get-MailboxDatabase -server $env:COMPUTERNAME | Sort Name | ForEach{
    $db = $_.Name
    $ActivServer = $_.Server.Name
    $OriginServer = $_.ActivationPreference | ? {$_.Value -eq 1}


    If ($ActivServer -ne $OriginServer.Key)
    {
        Write-Host "$db auf $ActivServer soll bevorzugt auf $($OriginServer.Key) laufen – FALSCH" -ForegroundColor Red
        Move-ActiveMailboxDatabase $db -ActivateOnServer $($OriginServer.Key) -Confirm:$Y
    }
    Else
    {
       Write-Host "$db auf $ActivServer soll bevorzugt auf $($OriginServer.Key) laufen - OK" -ForegroundColor Green
    }
}

Exchange 2016 DAG: Server aus den Wartungsmodus (Maintenance) per Powershell nehmen

Problem:
Auch beim beenden des Maintenance-Modus wollte ich das ganze Skripten und standardisieren.

Lösung:
Im Endeffekt arbeitet das PowerShell alle vorherigen Befehle in umgekehrter Reihenfolge ab, um den Server wieder sauber online zu nehmen. Ich schwenke die Datenbanken NICHT automatisch zurück sondern überlasse es der automatischen PreferenceMoveFrequency die Datenbanken wieder zurückzuschwingen (Default: 1 Stunde).

Man kann die PreferenceMoveFrequency abfragen mit folgenden Befehl:
 Get-DatabaseAvailabilityGroup | Format-Table Name, Preference*

Theoretisch kann man diese auch anpassen oder mit einer Time von "00:00:00" deaktivieren.
Hier mein Skript zum Beenden des Wartungs-Modus (Maintenance). Am Ende des Skripts gebe ich noch einige Prüfroutinen aus, um zu sehen, dass alle Dienste und Komponenten wieder korrekt laufen - das ist aber noch ausbaufähig.

Write-Host "Server-Komponeten werden aktiv gesetzt"
Set-ServerComponentState $env:ComputerName –Component ServerWideOffline –State Active –Requester Maintenance

# ClusterNode wieder UP setzen
Write-Host "ClusterNode wird online genommen"
Resume-ClusterNode –Name $env:ComputerName

# Mailbox-Datenbank wier online setzen und für Rückschwenk aktivieren
# KEIN aktives zurückschwenken
Write-Host "Mailboxdatenbanken werden wieder aktiv genommen"
Write-Host "Es wird keine Datenbank aktiv zurückgenommen"
Set-MailboxServer $env:ComputerName –DatabaseCopyAutoActivationPolicy Unrestricted
Set-MailboxServer $env:ComputerName –DatabaseCopyActivationDisabledAndMoveNow $false

# Hub-Transport wieder ACTIVE setzen - MAils werden wieder angenommen
Write-Host "Hub-Transport wird online genommen - Mails werden wieder angenommen"
Set-ServerComponentState $env:ComputerName –Component HubTransport –State Active –Requester Maintenance

# Aktivierung Defender und PS-Restriction-Policy
Write-Host "Defender und PS-Policy werden wieder aktiviert"
Set-MpPreference -DisableRealtimeMonitoring $false
Set-ExecutionPolicy RemoteSigned -force

# Prüfen ob immer noch imWartungsmodus
if ((Get-ClusterNode -Name $env:Computername).state -eq "Up")
	{
	  Write-Host "Server $env:ComputerName befindet sich im NORMALMODUS" -ForegroundColor Green
	}

	Else

	{
	  Write-Host "Server $env:ComputerName befindet sich immer noch im WARTUNGSMODUS" -ForegroundColor Red
 	  Write-Host "Bitte prüfen Sie die Dienste und Eventlogs auf Fehler" -ForegroundColor Red
	}

# Prüfroutinen für Dienste und Komponenten - jeweils mit Pause für Prüfung
Write-Host "###########################################################" -ForegroundColor Yellow
Write-Host "####### Ausgabe aller wichtigen Dienste zur Prüfung #######" -ForegroundColor Yellow
Write-Host "###########################################################" -ForegroundColor Yellow
write-host "`n"
Write-Host "--- ClusterNode muss UP sein ---" -ForegroundColor Yellow
Get-ClusterNode –Name $env:ComputerName
Pause
Write-Host "--- Test-ServiceHealth ---" -ForegroundColor Yellow
Write-Host "Alle Rollen müssen RequiredServicesRunning auf TRUE stehen" -ForegroundColor Yellow
write-host "`n"
Test-ServiceHealth | ft -AutoSize
Pause
Write-Host "--- Überprüfen aller Server-Komponenten ---" -ForegroundColor Yellow
Write-Host "Alle Komponenten ACTIVE bis auf ForwardSyncDaemon und ProvisioningRps" -ForegroundColor Yellow
write-host "`n"
Get-ServerComponentState $env:ComputerName | where {$_.State -ne "Active"} | ft
PAuse
Write-Host "Anzeigen aller Datenbanken" -ForegroundColor Yellow
write-host "`n"
Get-MailboxDatabaseCopyStatus -Server $env:ComputerName | ft
Write-Host "Fertig!" -ForegroundColor Green

Exchange DAG: Server in Wartungsmodus (Maintenance) setzen per Powershell

Problem:
Aktuell musste ich viele Server in einem DAG patchen (CU22, SU etc.) und ich wollte das ganze sauber skripten um Zeit zu sparen und das ganze auch zu standardisieren.

Lösung:
Hier mein Skript, das ich geschrieben habe um den Server sauber in den Wartungsmodus zu setzen. Hier habe ich auch berücksichtigt, dass ich eventuell Mails in den Mail-Queues auf einen anderen Server verschiebe. Das Skript wartet auch, bis alle Datenbanken unmounted sind. Am Ende wird auch nochmal überprüft, ob sich der Server wirklich im Wartungsmodus befindet (Database- und ClusterNode-Checkup)

WICHTIG: Beim "Redirect-Message" MUSS der Target-Server als FQDN angegeben werden und darf selbst nicht in Wartung sein!


# Exchange Module laden
Add-PSSnapin Microsoft.Exchange.Management.PowerShell.SnapIn

# Prüfen ob bereits im Wartungsmodus (ClusterNode not UP und keine Datenbank aktiv gemountet)
if ((Get-ClusterNode -Name $env:Computername).state -ne "Up" -and (Get-MailboxDatabaseCopyStatus -Server $env:ComputerName | Where {$_.Status -eq "Mounted"}).Count -eq 0)
	{
	  Write-Host "Server $env:ComputerName befindet sich bereits im WARTUNGSMODUS" -ForegroundColor Green
	  Write-Host "Keine Änderung vorgenommen..." -ForegroundColor Green
Exit
	}

# Sicherheitsfunktionen abschalten (PS-Execution-Policy und Defender)
Write-Host "Server $env:ComputerName wir in den Wartungsmodus versetzt..."
Write-Host "PS-Policy und Defender werden deaktiviert"
Set-ExecutionPolicy Unrestricted -force
Set-MpPreference -DisableRealtimeMonitoring $true
Sleep -Seconds 3
Write-Host "PS-Policy unrestriced und Defender deaktiviert"

# Hub-Transport abschalten
# Es werden keine Mails mehr angenommen
Write-Host "Hub-Transport wird deaktiviert und Mail-Queues verschoben..."
Set-ServerComponentState $env:ComputerName –Component HubTransport –State Draining –Requester Maintenance
Sleep -Seconds 5

# Bestehende Mails werden aus der Queue auf einen anderen Server verschoben
Redirect-Message -Server $env:ComputerName -Target  -Confirm:$false
Write-Host "Hub-Transport deaktiviert"

# ClusterNode in Suspend-Mode
Write-Host "ClusterNode $env:ComputerName wird angehalten"
Suspend-ClusterNode –Name $env:ComputerName
Sleep -Seconds 3
Write-Host "ClusterNode $env:ComputerName angehalten"

# Mailbox-Datenbanken verschieben und 
Write-Host "Aktive Mailboxdatenbanken werden evakuiert"
Set-MailboxServer $env:ComputerName –DatabaseCopyActivationDisabledAndMoveNow $true
Set-MailboxServer $env:ComputerName –DatabaseCopyAutoActivationPolicy Blocked
Write-Host "Skript wartet, bis Datenbanken evakuiert wurden - Prüfintervall: 30 Sekunden"
While ((Get-MailboxDatabaseCopyStatus -Server $env:ComputerName | Where {$_.Status -eq "Mounted"}).Count -ne 0) 
{
Sleep -Seconds 30
}
Write-Host "Datenbanken wurden alle evakuiert - keine aktive Datenbankkopie mehr auf $env:ComputerName aktiv"

# Server-Komponenten deaktivieren
Set-ServerComponentState $env:ComputerName –Component ServerWideOffline –State InActive –Requester Maintenance
Write-Host "Alle Server-Komponenten deaktiviert"

# Prüfen ob im Wartungsmodus (keine aktiven Datenbanken und ClusterNode not UP)
if ((Get-ClusterNode -Name $env:Computername).state -ne "Up" -and (Get-MailboxDatabaseCopyStatus -Server $env:ComputerName | Where {$_.Status -eq "Mounted"}).Count -eq 0)
	{
	  Write-Host "Server $env:ComputerName befindet sich im WARTUNGSMODUS" -ForegroundColor Green
	}

	Else

	{
	  Write-Host "Server $env:ComputerName befindet sich NICHT im WARTUNGSMODUS" -ForegroundColor Red
	  Write-Host "Bitte prüfen Sie die Dienste und Befehle auf Meldungen" -ForegroundColor Red
	}



Exchange DAG: Prüfen ob alle Datenbanken auf den originalen Servern gemountet sind

Ich arbeite aktuell an einem DAG welches aus acht Servern mit vielen Datenbanken besteht. Um, zu prüfen, ob alle Datenbanken auf ihren originalen Servern gemountet sind, habe ich mir folgendes kleines Skript geschrieben:

Add-PSSnapin Microsoft.Exchange.Management.PowerShell.SnapIn
Get-MailboxDatabase | Sort Name | ForEach{
    $db = $_.Name
    $ActivServer = $_.Server.Name
    $OriginServer = $_.ActivationPreference | ? {$_.Value -eq 1}


    If ($ActivServer -ne $OriginServer.Key)
    {
        Write-Host “$db auf $ActivServer soll bevorzugt auf $($OriginServer.Key) laufen – FALSCH” -ForegroundColor Red
  
    }
    Else
    {
        Write-Host “$db auf $ActivServer soll bevorzugt auf $($OriginServer.Key) laufen - OK” -ForegroundColor Green
    }
}

Das Skript gibt aus, ob eine Datenbank auf einem "falschen" Server läuft und wo sie gemountet werden sollte.
Zur optischen Unterstützung werden die Einträge rot und grün eingefärbt.

Exchange Powershell: Prüfen der Exchange Schema Version

Problem:
Bei der Installation eines kumulativen Updates der Exchange Server ist meistens nicht ganz klar, ob ein Schema Update nötig ist oder nicht. Microsoft gibt meistens die nötige Schema Version an.

Lösung:
Um zu prüfen, ob ich die richtige Version bereits verwende, habe ich mir ein PowerShell-Skript geschrieben, das die Exchange Schema Version ausgibt:

# Exchange Schema Version

Add-PSSnapin Microsoft.Exchange.Management.PowerShell.SnapIn

$sc = (Get-ADRootDSE).SchemaNamingContext
$ob = "CN=ms-Exch-Schema-Version-Pt," + $sc
$ru = "RangeUpper: $((Get-ADObject $ob -pr rangeUpper).rangeUpper)"

$dc = (Get-ADRootDSE).DefaultNamingContext
$ob = "CN=Microsoft Exchange System Objects," + $dc
$ovd = "ObjectVersion (Default): $((Get-ADObject $ob -pr objectVersion).objectVersion)"

$cc = (Get-ADRootDSE).ConfigurationNamingContext
$fl = "(objectClass=msExchOrganizationContainer)"
$ovc = "ObjectVersion (Configuration): $((Get-ADObject -LDAPFilter $fl -SearchBase $cc -pr objectVersion).objectVersion)"

Write-Output $ru $ovd $ovc


Eine schöne Übersicht der jeweiligen Schema Version findet ihr bei Ali:
Ali Tajran: Exchange schema versions (up to date list)
“Das einzig sichere System müsste ausgeschaltet, in einem versiegelten und von Stahlbeton ummantelten Raum und von bewaffneten Schutztruppen umstellt sein.”
Gene Spafford (Sicherheitsexperte)