Ziel

Exportiere eine Übersicht aller Mailboxen mit einer bestimmten Empfängerdomain (z. B. @domain.tld) inklusive Elementanzahl, Gesamtgröße und Anzeigename.

PowerShell-Befehl

get-mailbox -ResultSize Unlimited |
  where { $_.PrimarySMTPAddress -like "*@domain.tld" } |
  get-mailboxstatistics |
  select DisplayName,ItemCount,TotalItemSize |
  Export-Csv -Path "C:\temp\Mailboxstatistik.csv" -NoTypeInformation -Encoding UTF8

Erläuterung

Ergebnis

Die CSV-Datei C:\temp\Mailboxstatistik.csv enthält eine saubere Tabelle mit:

• DisplayName (Anzeigename der Mailbox)
• ItemCount (Anzahl der Elemente)
• TotalItemSize (Gesamtgröße der Mailbox)

Bonus: Nur Nutzer anzeigen, keine Shared/Room-Mailboxen

Wenn du nur Benutzer-Mailboxen (keine Ressourcen oder freigegebene) erfassen willst, kannst du den Filter anpassen:

get-mailbox -ResultSize Unlimited -RecipientTypeDetails UserMailbox |
  where { $_.PrimarySMTPAddress -like "*@domain.tld" } |
  get-mailboxstatistics |
  select DisplayName,ItemCount,TotalItemSize |
  Export-Csv -Path "C:\temp\Mailboxstatistik.csv" -NoTypeInformation -Encoding UTF8

Fazit: Mit nur wenigen Zeilen PowerShell bekommst du schnell und zuverlässig einen Überblick über Mailboxnutzung pro Domain – ideal für Analyse, Migration oder Lizenzbewertung.

Der Nachrichtenfluss dieser Testmail läuft wie folgt:

Extern → Hornetsecurity → Exchange OnPrem → Exchange Online

Das bedeutet: Die Nachricht lässt sich in beiden Umgebungen nachvollziehen. Dieser Artikel behandelt exemplarisch das Message Tracking einer E-Mail vom Absender abow@domain.tld mit Startdatum 21.01.2026.

Teil 1: Exchange OnPrem

Befehl:

Get-MessageTrackingLog -Sender "abow@domain.tld" -Start "01/21/2026" | Select * | Out-GridView

Erklärung:

Nützliche Felder:

• EventId: z. B. RECEIVE, SEND, DELIVER, SENDEXTERNAL, AGENTINFO
• MessageSubject: Titel der E-Mail
• Source: Ursprung des Events, z. B. STOREDRIVER, SMTP, PUBLICFOLDER
• Recipients: Liste der Empfänger

Weitere Infos: Microsoft-Dokumentation zum Cmdlet

Teil 2: Exchange Online (Microsoft 365)

Seit etwa 2020 ist das klassische MessageTrackingLog in Exchange Online nicht mehr verfügbar. Stattdessen gibt es:

• Get-MessageTrace – Überblick über Nachrichtentransport
• Get-MessageTraceDetail – Detailinformationen

Beispiel 1: Get-MessageTrace

Get-MessageTrace `
  -SenderAddress "abow@domain.tld" `
  -StartDate "01/21/2026" `
  -EndDate "01/22/2026" |
  Select *

Wichtig: Das Enddatum muss einen Tag später gesetzt werden, da Exchange Online tagesweise auswertet.

Doku: Get-MessageTrace (Microsoft)

Beispiel 2: Get-MessageTraceDetail

Variante A: Per Pipeline direkt aus dem vorherigen Befehl:

Get-MessageTrace `
  -SenderAddress "abow@domain.tld" `
  -StartDate "01/21/2026" `
  -EndDate "01/22/2026" |
Get-MessageTraceDetail |
Select *

Variante B: Manuell mit MessageTraceId und Empfängeradresse:

Get-MessageTraceDetail `
  -MessageTraceId "GUID" `
  -RecipientAddress "abow@domain.tld"

Hinweis

Ein Nachteil von Get-MessageTraceDetail: Die Umwandlung zwischen onmicrosoft-Adresse und primärer SMTP-Adresse wird nicht sauber dargestellt – Probleme bei der Adressauflösung bleiben also u. U. unentdeckt.

Doku: Get-MessageTraceDetail (Microsoft)

Fazit

• Exchange OnPrem bietet detailliertes, lokales Tracking per Get-MessageTrackingLog
• Exchange Online nutzt Get-MessageTrace und Get-MessageTraceDetail – weniger granular, aber ausreichend für Standardanalysen
• Für Hybrid-Umgebungen (z. B. mit Hornetsecurity oder zentralem Mailflow) muss beide Seiten geprüft werden
• Nutze GUI-Ausgaben (Out-GridView), wenn du schnell manuell analysieren willst

Viele Umgebungen haben unterschiedliche Zertifikate zwischen intern (Default Web Site) und extern am Netscaler/WAP oder Firewall. Hier musste ich einige Schritte gehen um passende öffentliche Zertifikate für eine valide Zertifikatskette nach intern zu kaufen/erzeugen und zu binden.
NTLMv1 war zum Glück gar kein Thema mehr.

Bitte konfiguriert eure Exchange Server/Umgebungen immer mit gleichen URLs (intern = extern) für alle virtuellen Verzeichnisse, das hätte es mir auf jeden Fall einfacher gemacht.
Hybrid-Konfigurationen sind auch kein Thema gewesen, da ich immer die Classic-Variante eingerichtet habe.
Hier und da musste ich noch das SSL-Abladen am Outlook-Anywhere deaktivieren aber das war es dann auch schon.

Ihr hoffe ihr habt eure Umgebungen gut im Griff.

Bei Fragen, fragen!

Wie immer berichte ich in diesem Artikel nur von meinen persönlichen Erfahrungen und Erkenntnissen.
Es handelt sich hierbei um keine offizielle Anleitung von Microsoft.
Ein nachhandeln geschieht auf eigene Gefahr.

Tatsächlich sind diese Einstellungen seit 2009 verfügbar und ein Thema von Windows IIS, wird aber jetzt zwingend benötigt, um Sicherheitslücken zu schließen.

Das Flussdiagramm stellt einmal dar, wie der Weg zum schließen der Lücken aussieht.

Hier nun aufgelistet die Einschränkungen:

• Extended Protection kann nicht auf Exchange Server 2013-Servern (Grundsätzlich aber ab Exchange Server 2013 CU23 möglich) aktiviert werden, die über öffentliche Ordner in der Koexistenzumgebung verfügen.
  • Hier werden die Public Folder sonst nicht mehr bei den Endbenutzern erscheinen
• Extended Protection kann nicht auf Exchange Server 2016 CU22 oder Exchange Server 2019 CU11 oder früher aktiviert werden, die die Public Folder Hierarchie hosten.
  • Läuft nur ab 2016 CU23 und 2019 CU12
• Extended Protection funktioniert nicht auf Hybridservern mit der Modern Hybridkonfiguration
  • Features wie Postfachmigration und Frei/Gebucht-Informationen werden unterbrochen
• NTLMv1 wird nicht unterstützt (sollte möglichst sowieso nicht mehr genutzt werden!) Anleitung
  • Nutzt ein Client dennoch NTLMv1, wird er ständig mit Passwortabfragen bombadiert
• SSL-Offload-Szenarien werden nicht unterstützt
  • Die Extended Protection schlägt aufgrund der SSL-Beendigung während des SSL-Offloads fehl. Um Extended Protection in Ihrer Exchange-Umgebung zu aktivieren, verwenden Sie kein SSL-Offloading mit Ihrem Load Balancer.
• Die TLS-Konfiguration
  • Konsistente TLS-Versionen:
    • Überprüfen Sie, dass alle Exchange-Server im Unternehmen die gleiche TLS-Version verwenden. Wenn beispielsweise ein Server TLS 1.2 verwendet, müssen alle anderen Server ebenfalls auf TLS 1.2 konfiguriert sein.
    • Abweichungen in den TLS-Versionen zwischen den Servern können zu Verbindungsproblemen mit den Clients führen und sollten vermieden werden.
  • SchUseStrongCrypto-Registrierungswert:
    • Setzen Sie den Wert des SchUseStrongCrypto-Registrierungswerts auf 1 auf allen Exchange-Servern innerhalb der Organisation.
    • Falls dieser Wert nicht explizit auf 1 festgelegt ist, kann der Standardwert je nach verwendeter .NET-Version interpretiert werden, was zu unerwünschten Konfigurationen führen kann.
  • SystemDefaultTlsVersions-Registrierungswert:
    • Stellen Sie sicher, dass der SystemDefaultTlsVersions-Registrierungswert ebenfalls explizit auf 1 festgelegt ist.
    • Wenn diese Werte nicht wie erwartet festgelegt sind, kann dies zu TLS-Konflikten führen, die wiederum zu Problemen bei der Clientkonnektivität führen.
• Softwarekompatibilität von Drittanbietern
  • Testen Sie Produkte von Drittanbietern in Ihrer Exchange Server-Umgebung, um sicherzustellen, dass sie ordnungsgemäß funktionieren, wenn der erweiterte Schutz aktiviert ist. Ich habe zum Beispiel Antivirenlösungen gesehen, die Verbindungen über einen Proxy senden, um Clientcomputer zu schützen, aber dies verhindert die Kommunikation mit dem Exchange-Server und sollte deaktiviert werden.

SSL-Bridging funktioniert, sofern im Exchange und Load-Balancer das gleiche Zertifikat verwendet wird.

SSL-Offloading für Outlook Anywhere ist standardmäßig aktiviert und muss deaktiviert werden, indem Sie die folgenden Schritte ausführen:

Set-OutlookAnywhere -Identity "EXCH1\rpc (Default Web Site)" -SSLOffloading $false

Sind all diese Einschränkungen geprüft und abgestimmt, kann die Extended Protection via Skript-Unterstützung aktiviert werden.

ExchangeExtendedProtectionManagement.ps1 ist ein Skript zur Automatisierung der Extended Protection des Windows-Authentifizierungsmoduls auf Exchange-Servern. Stellen Sie vor der Konfiguration sicher, dass die TLS-Einstellungen auf allen Servern, auf denen Sie den erweiterten Schutz aktivieren möchten, und auf dem Server, auf dem der Extended Protection bereits aktiviert ist, identisch sind, und dass die erforderlichen anderen Voraussetzungen gegeben sind.

Folgend eine Auflistung mit Beispiel Codezeilen zum ausführen:

PS C:\> .\ExchangeExtendedProtectionManagement.ps1

Einfache Ausführung über alle Server der Organisation.

PS C:\> .\ExchangeExtendedProtectionManagement.ps1 -ExchangeServerNames <Array_of_Server_Names>

Ausführen für nur bestimmte Server.

PS C:\> .\ExchangeExtendedProtectionManagement.ps1 -SkipExchangeServerNames <Array_of_Server_Names>

Ausführen für alle Server außer …

PS C:\> .\ExchangeExtendedProtectionManagement.ps1 -FindExchangeServerIPAddresses -OutputFilePath "C:\temp\ExchangeIPs.txt"

Export einer Liste aller Exchange Server IPs in der Organisation.

PS C:\> .\ExchangeExtendedProtectionManagement.ps1 -RollbackType "RestoreIISAppConfig"

Wiederherstellen der IIS-Einstellungen zuvor.

PS C:\> .\ExchangeExtendedProtectionManagement.ps1 -ShowExtendedProtection

Aktuelle Einstellungen anzeigen.

Hier noch alle Parameter mit Erläuterung.

Offizieller Microsoft Artikel: Link

Heute möchte ich euch ein Skript vorstellen mit dem ihr die IP-Adressen aus allen vorhandenen Empfangsconnectoren als .csv exportieren könnt.
Das Skript kann auch außerhalb der Exchange Powershell (Management Shell) ausgeführt werden, da das benötigte SnapIn importiert wird.

Das Skript erstellt für jeden Connector eine .csv-Datei in der alle eingetragenen IPs geschrieben werden.
Die .csv-Dateien werden unter C:\temp\ abgelegt.
Jede .csv-Datei wird wie folgt benannt:

Was ist zu beachten?

• Das Powershell-Skript kann evtl. aufgrund von ExecutionPolicys an der Ausführung gehindert werden. (_{Wie ihr das für Benutzer oder Computer aufhebt, gerne in einem weiteren Artikel})
• Der Export-Pfad ist fest definiert. Sicherstellen das der Ordner existiert. (_{oder im Skript umschreiben})

### Script to Export Recieve Connectors as .csv
#Autor: Andreas Bowitz
#Version: 0.1

#Import Exchange Snapin
Add-PSSnapin Microsoft.Exchange.Management.PowerShell.SnapIn

#Variablen/Arrays
$Hostname = hostname
$Connectors = Get-ReceiveConnector
$ExportPath = "C:\temp\"

#Export all Recieve Connectors
foreach($Connector in $Connectors){

$Connectorshort = $Connector.Identity
$Connectorshort = $Connectorshort.Name

$Connectorshort = $Connectorshort.replace(" ","_")

#write-host $Connectorshort

$export = $ExportPath+$Connectorshort+".csv"


(Get-ReceiveConnector -Identity $Connector).RemoteIPRanges | Sort-Object | Select-Object Expression | Export-Csv $export -NoTypeInformation

}


#Clear all Variablen/Arrays
$Hostname = $null
$Connectors = $null
$ExportPath = $null
$Connector = $null
$export = $null
$Connectorshort = $null

Gerne könnt ihr das Skript auch einfach hier herunterladen:

Bei Verbesserungsvorschlägen o.Ä. einfach melden via Kommentar.
Danke.

Wie immer berichte ich in diesem Artikel nur von meinen persönlichen Erfahrungen und Erkenntnissen/Ergebnissen.
Es handelt sich hierbei um keine offizielle Anleitung von Microsoft.
Ein nachhandeln und nutzen von Skripten geschieht auf eigene Gefahr. ;)

Diese Anleitung gilt für die Exchange OnPrem Versionen 2016 & 2019.

Damit ein Exchange Server Postfächer hosten kann benötigt er Datenbanken.
Heute zeige ich euch, wie Ihr eine neue Datenbank (später DB) anlegt, Grundkonfiguriert und welche Überlegungen man sich vielleicht vorher machen sollte.

In diesem Artikel wird es nicht um das Thema DAG gehen.

Aus meiner Erfahrung heraus sollte eine DB nicht größer als 1,5 TB (1.500 GB) werden. Ein Exchange Server mit einer Standard Lizenz lässt keine DB größer als 1024 GB zu, haben wir allerdings eine Enterprise Lizenz ist dies möglich (bis zu 16 TB supportet). Verschwendet man allerdings mal einen Gedanken an evtl. zukünftige Wiederherstellungen, ist 1,5 TB noch eine gut verkraftbare Menge an Daten in Anbetracht der Wiederherstellungs-/Reparaturzeit.

Also im ersten Schritt sollte man sich also Gedanken über Datenmengen und deren Wachstum machen. Es ist kein Problem auch mehrere DB anzulegen und die Daten aufzuteilen.

Hinweis

• Standard Lizenz: max. 5 DB
• Enterprise Lizenz: max. 100 DB

Als nächstes ist der Speicher dran, es empfiehlt sich IMMER extra Festplatten/Partitionen für die DB und Logs einzubinden.

Die Namen der Festplatten/Partitionen sollte entsprechend LOG_DB0# bzw. DB0# lauten.
Die Laufwerksbuchstaben sollten fortlaufend eingestellt werden, DB z.B. E-J und für die Logs N-S.

Zum Beispiel:

Das Log-Laufwerk/Partition sollte immer mindestens 5-10% der zugehörigen DB-Größe betragen.
Die Logs sind extreme wichtig für den Betrieb, die Wiederherstellung und die allgemeine Datenkonsistenz!

Ebenfalls empfehle ich 5-7 GB RAM pro zusätzlicher Datenbank für das Systeme.
Jetzt kommen wir aber zur eigentlichen Anlage, hier könnt ihr das natürlich über das ECP erledigen, ich bevorzuge allerdings die Exchange-Powershell Variante.

Hierzu öffnen wir eine Exchange Admin Console als Administrator.
Im ersten Schritt legen wir die neue DB unter der Angabe von Datenbank-/ und Logpfad an.

New-MailboxDatabase -Name DB01 -EdbFilePath E:\DB01\DB01.edb -LogFolderPath N:\LOG_DB01 -Server SV-EXCH0

Wenn die DB angelegt ist, ist diese einzubinden. Das geschieht mit dem folgenden Befehl

Mount-Database DB01

Falls notwendig können jetzt noch Limitierungen angepasst und das Offline-Adressbuch gesetzt werden

Set-MailboxDatabase DB01 -IssueWarningQuota 500MB -ProhibitSendQuota Unlimited -ProhibitSendReceiveQuota Unlimited -DeletedItemRetention 7 -MailboxRetention 7 -OfflineAddressbook "\Standard-OfflineAdressbuch"

Je nachdem was für eine Backup-Lösung im Einsatz ist, kann es notwendig sein einem Service Account Rechte auf die DB zu gewähren!

Get-MailboxDatabase DB01| Add-ADPermission -User "svc_backupaccount" -AccessRitghs ExtendedRights -ExtendedRights Receive-As,ms-Exch-Store-Admin

Damit haben wir unsere DB angelegt. Denkt bitte immer daran euer Monitoring, Backup, sowie auch den AntiVir in seinen Ausnahmen entsprechend anzupassen.

Ihr habt keine Lust auf Powershell? Na gut, dann hier der Weg über die ECP.

Loggt euch ein, geht links auf „Server“ und dort auf den Reiter „Datenbanken“. Hier könnt ihr auf das + klicken und die neue DB anlegen.

Um die DB einzubinden, einfach den Haken dafür mit setzen.

Die Limitierungen und das Offline-Adressbuch kann man dann in den Einstellungen über den Bearbeiten-Button konfigurieren.

Jetzt aber noch ein paar weitere Kniffe und Informationen.
Ihr wollt eine DB nachträglich umbenennen? Kein Problem

Get-MailboxDatabase -Server SV-EXCH0 | Select Name,EdbFilePath,LogFolderPath | fl Set-MailboxDatabase "DB01" -Name DB02

Damit wird die DB01 in DB02 umbenannt.
Ihr wollt sie einfach nur verschieben, da sie auf ein falsches Laufwerk erstellt wurde?

Move-DatabasePath -Identity DB01 -EdbFilePath F:\DB01\DB01.edb -LogFolderPath O:\LOG_DB01

Das soll es erstmal gewesen sein. Sollte ihr noch Anregungen haben, gerne her damit. Habe ich was vergessen? Her damit. Ich lerne auch nie aus.
Wie man nun Mailboxen migriert/verschiebt zeige ich euch ein anderes mal.

Wie immer berichte ich in diesem Artikel nur von meinen persönlichen Erfahrungen und Erkenntnissen.
Es handelt sich hierbei um keine offizielle Anleitung von Microsoft.
Ein nachhandeln geschieht auf eigene Gefahr. ;)