Diese Dokumentation basiert auf der Installation eines CU auf dem eigenständigen Exchange-Server exch01.domain.tld, der vorab mit allen aktuellen Windows-Updates versorgt wurde. Die zugrunde liegende Umgebung ist ein Multi-AD-Forest mit Child-Domain – also deutlich komplexer als eine Single-Forest-/Single-Domain-Struktur.

Wichtig vorab (Stand: Juni 2026): Exchange 2016/2019 sind End of Support

Exchange Server 2016 und 2019 haben am 14. Oktober 2025 das Support-Ende erreicht. Es gibt seitdem keine regulären Sicherheitsupdates, Bugfixes oder technischen Support mehr. Wer noch im Programm der Extended Security Updates (ESU) ist, erhält Updates nur noch bis April 2026 – das ist ausdrücklich nur ein Übergang, keine Dauerlösung.

Die einzige weiterhin unterstützte On-Prem-Variante ist Exchange Server Subscription Edition (SE). Exchange SE RTM ist code-identisch mit Exchange 2019 CU15; SE CU1 kam in H1/2026, SE CU2 folgt in H2/2026 und blockt dann die Koexistenz mit 2016/2019.

Konsequenz für dieses Thema: Reine CU-Installationen auf 2016/2019 sind heute fast nur noch im Rahmen einer In-Place-Migration nach SE relevant (2019 CU14/CU15 → SE) oder mit aktivem ESU. Der hier beschriebene Ablauf gilt aber technisch unverändert auch für Exchange Server SE – Modern Servicing bedeutet lediglich: Es ist immer nur das aktuellste CU supported (kein „N-1″ mehr).

Voraussetzungen

Passende Berechtigungen

Für das Update wird ein Benutzerkonto benötigt, das Mitglied in folgenden Gruppen ist:

• Organization Management
• Organisations-Admins (Enterprise Admins)
• Schema-Admins

Nur damit ist sichergestellt, dass alle Änderungen am Active-Directory-Schema und an der Exchange-Organisation durchgeführt werden können. Fehlen die Rechte, schlägt die Installation fehl – und die Ursache lässt sich oft nur mit gezielter Log-Recherche nachvollziehen.

In seltenen Konstellationen (wie z. B. bei domain.tld) ist die Gruppe Organisations-Admins nicht automatisch Mitglied der Domänen-Admins jeder betroffenen Domäne. Dann muss PrepareDomain zwingend mit einem Benutzer aus der Domänen-Admins-Gruppe der jeweiligen Domäne ausgeführt werden.

Vorbereitung der Arbeiten

Je nach Umgebung unterscheiden sich die Vorbereitungsschritte. Vieles lässt sich aber schon im Vorfeld erledigen.

Übersicht der Exchange-Server erfassen

Erstelle vorab eine Übersicht aller Exchange-Server inklusive Dienstestatus, Build-Versionen und ggf. Rollenverteilung. Das dokumentiert den IST-Zustand sauber und hilft im Fehlerfall enorm.

Tipp: Microsoft empfiehlt offiziell den Exchange Server Health Checker (PowerShell-Skript), um vorab zu sehen, welche CUs/SUs/manuellen Schritte ausstehen. Den IST-Zustand kannst du außerdem mit dem unten verlinkten Pre-Flight-Skript einsammeln.

Beginn der Arbeiten kommunizieren

Vor dem Start der Wartung den Kunden/Service Owner rechtzeitig informieren, damit Einschränkungen bekannt und eingeplant sind.

Exchange-Version ermitteln

Zuerst feststellen, welche Version aktuell läuft – per Exchange Management Shell oder EAC.

Get-ExchangeServer | Select-Object Name, AdminDisplayVersion | Format-Table

Beispielausgabe:

Name    AdminDisplayVersion
----    -------------------
EXCH01  Version 15.1 (Build 2044.4)
EXCH02  Version 15.1 (Build 2044.4)

Die Build-Nummer ordnest du über die Microsoft-Liste der konkreten CU-Version zu: Exchange Build Numbers and Release Dates (Microsoft Learn)

Build-Logik kurz erklärt: 15.0.x = Exchange 2013, 15.1.x = Exchange 2016, 15.2.x = Exchange 2019 / Exchange SE. Im Beispiel entspricht 15.1.2044.4 dem Exchange 2016 CU17.

CU-Version der Setup-Datei prüfen

Welche Version ein vorhandenes Setup-Paket enthält:

Get-Command Exsetup.exe | ForEach-Object { $_.FileVersionInfo }

Download der aktuellen CU/SE-Version

Aktuelle Pakete (Exchange SE bzw. die letzten ESU-fähigen SUs für 2016/2019) gibt es bei Microsoft. Nutze zur Pfadbestimmung den Exchange Update Wizard, der dir abhängig von Quell- und Ziel-CU die genauen Schritte ausgibt.

Besonderheit: UM Language Pack

Hinweis: Unified Messaging (UM) wurde mit Exchange 2019 entfernt und ist in Exchange SE nicht mehr vorhanden. Dieser Abschnitt ist daher nur noch für Exchange 2016 relevant.

Falls UM eingesetzt wird, ist ggf. ein UM Language Pack installiert (z. B. für Voicemail-Ansagen). Es muss nach dem CU-Update in passender Version neu installiert werden und erscheint in der Systemsteuerung unter Programme und Features.

Prüfen, ob ein Language Pack aktiv ist:

Get-UMService | Select-Object Name, Languages

Wird nur {en-US} ausgegeben, ist kein zusätzliches Sprachpaket installiert.

.NET Framework-Version ermitteln

Am einfachsten per PowerShell (als Administrator):

(Get-ItemProperty "HKLM:SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full").Release

Beispielausgabe:

528049

Der Release-Wert lässt sich der Microsoft-Tabelle zuordnen – 528049 = .NET 4.8: How to determine which .NET Framework versions are installed

Kurzreferenz Release-Werte: 528040/528049/528449 = .NET 4.8 · 533320/533325 = .NET 4.8.1. Exchange SE benötigt .NET 4.8 (auf Windows Server 2025 ist 4.8.1 systemseitig dabei).

Kompatibilität von CU und .NET Framework

Mit diesen Infos prüfst du anhand der Supportability Matrix, ob die installierte .NET-Version zum geplanten CU passt. Ist das nicht der Fall, muss .NET vor dem CU aktualisiert werden.

Exchange Server Supportability Matrix (Microsoft Learn)

In unserem Beispiel: .NET 4.8 wird bereits ab Exchange 2016 CU13 unterstützt – ein .NET-Update ist hier nicht erforderlich.

Active Directory Schema-Version prüfen

Vor dem CU prüfen, ob das AD-Schema bereits die erforderliche Version hat.

Exchange Schema Version:

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

Exchange Object Version (Domain):

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

Exchange Object Version (Forest):

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

Hinweis: Die ObjectVersion (Configuration) wird in manchen Umgebungen erst nach dem erfolgreichen Update des ersten Exchange-Servers erhöht.

Beispielausgabe:

RangeUpper: 15332
ObjectVersion (Default): 13237
ObjectVersion (Configuration): 16217

Die jeweils erforderlichen Soll-Werte je CU stehen hier:

• Exchange 2016 – AD- und Domain-Vorbereitung
• Exchange 2019 – AD- und Domain-Vorbereitung

In unserem Fall muss das Schema erweitert werden, da das neue CU eine höhere Schema-Version voraussetzt.

Tipp: Alle obigen Abfragen plus Dienstestatus, FSMO, .NET und Transport Agents erledigt das verlinkte Pre-Flight-Skript in einem Rutsch (read-only).

Schema Master ermitteln

Für das Schema-Upgrade muss bekannt sein, welcher DC die Schema-Master-Rolle hält. Das Upgrade sollte im Vorfeld des CU erfolgen.

Variante 1 – CMD:

netdom query fsmo

Variante 2 – PowerShell:

Get-ADForest | Select-Object SchemaMaster

Schema-Erweiterung des Active Directory

Die Installations-ISO des CUs wird auf dem DC mit der Schema-Master-Rolle eingebunden (im Beispiel rootdc01.domain.tld).

Alternativ auf einem anderen DC in der gleichen AD-Site wie der Exchange-Server. Bei Bedarf die FSMO-Rolle temporär verschieben:

1. mmc öffnen → Snap-In „Active Directory-Schema“ hinzufügen
2. Rechtsklick auf Active Directory-Schema → Change Domain Controller
3. Ziel-DC wählen → Operation Master → Change

Durchführung

1. PowerShell als Administrator auf dem Schema-Master öffnen
2. Auf das ISO-Laufwerk wechseln (z. B. D:):

D:

3. Befehle nacheinander ausführen:

.\setup.exe /PrepareSchema /IAcceptExchangeServerLicenseTerms_DiagnosticDataON
.\setup.exe /PrepareAD /IAcceptExchangeServerLicenseTerms_DiagnosticDataON

Zum Lizenz-Schalter: Microsoft akzeptiert zwei Varianten – _DiagnosticDataON oder _DiagnosticDataOFF. Der Unterschied ist ausschließlich, ob optionale Diagnosedaten an Microsoft gesendet werden. Funktional ist die Installation identisch. Tipp: Innerhalb einer Wartung konsistent denselben Schalter verwenden, um Verwirrung in den Logs zu vermeiden.

Komplexe Umgebungen mit mehreren Domänen

Gibt es Exchange-Server in weiteren Domänen:

.\setup.exe /PrepareAllDomains /IAcceptExchangeServerLicenseTerms_DiagnosticDataON

Schlägt PrepareAllDomains mangels Domain-Adminrechten fehl, jede Domäne einzeln vorbereiten:

.\setup.exe /PrepareDomain:<domain.tld> /IAcceptExchangeServerLicenseTerms_DiagnosticDataON

Abschluss der AD-Vorbereitung

Danach ist das AD auf dem aktuellen Stand. Die ISO kann vom DC wieder ausgehängt werden.

Hinweis: Vor dem Start der Exchange-Installation die AD-Replikation abwarten – meist reichen ca. 15 Minuten, je nach Umgebung mehr. Mit repadmin /replsummary lässt sich der Replikationsstand prüfen.

Problem: „Ein Neustart einer vorangegangenen Installation steht noch aus“

Vor dem Setup kann diese Meldung kommen:

Ein Neustart einer vorangegangenen Installation steht noch aus. Starten Sie das System neu, und führen Sie Setup erneut aus.

Das Setup wird abgebrochen. Details im Log:

<SystemDrive>:\ExchangeSetupLogs\ExchangeSetup.log

Lösungsmöglichkeiten

• Variante 1 (empfohlen): Server einmal neu starten, Setup erneut ausführen.
• Variante 2 (nur wenn Reboot nicht hilft): Den Registry-Wert prüfen:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager → PendingFileRenameOperations

Korrektur/Warnung (wichtig!): Diesen Wert nicht blind löschen. PendingFileRenameOperations kann mehrere legitime ausstehende Umbenennungen enthalten, die Windows beim nächsten Boot erledigen will. Werden die gelöscht, können laufende Updates inkonsistent werden.

Besser: Erst den Inhalt ansehen (Get-ItemProperty ... -Name PendingFileRenameOperations), den Wert exportieren/sichern, und nur wenn dort ausschließlich irrelevante Reste stehen, gezielt entfernen. In 95 % der Fälle löst ein simpler Reboot das Problem sauber.

Weitere Infos: FrankysWeb – „Ein Neustart steht noch aus“

Sonderanpassungen an der Konfiguration

Individuelle Konfigurationsänderungen (z. B. an web.config) können durch ein CU überschrieben werden. Diese vorab dokumentieren/exportieren und nach dem Update prüfen und ggf. erneut setzen.

Abhängige Drittherstellersoftware

In produktiven Umgebungen ist oft Drittsoftware aktiv (Signaturen, Archivierung, Security). Solche Komponenten können durch ein CU beeinträchtigt werden, vor allem wenn Exchange-DLLs ersetzt werden.

Prüfen, ob sich Software in den Mailflow einklinkt:

Get-TransportAgent

Beispielausgabe:

Name                              Enabled  Priority
----                              -------  --------
Exclaimer Auto Responder Agent    True     1

Hier ist der Exclaimer Auto Responder Routing Agent aktiv (laut Hersteller keine Maßnahmen nach CU nötig). Anders z. B. bei CI-Mail Policy – die muss nach jedem CU neu installiert werden.

Empfehlung: Vor dem Update die Dritthersteller-Doku prüfen oder beim Hersteller anfragen, ob nach einem CU Maßnahmen nötig sind.

Vorbereitung vor dem Update

Kundenkommunikation

Falls noch nicht erfolgt: Kunde vor Beginn informieren, besonders bei Produktivsystemen.

Kein Snapshot!

Ein Snapshot (Hyper-V/VMware) ist nicht sinnvoll – das CU ändert nicht nur Exchange, sondern auch das AD-Schema. Ein Snapshot-Rollback führt zu inkonsistenten Zuständen. Es gibt kein Rollback – nur den Weg nach vorn.

Technische Vorbereitung

Status der Exchange-Dienste dokumentieren

IST-Zustand festhalten:

• Dienste (Screenshot oder PowerShell): Test-ServiceHealth
• Komponentenstatus: Get-ServerComponentState <Servername>

Hintergrund: CU-/Hotfix-Installationen setzen Dienste/Komponenten oft auf „Deaktiviert“. Eine saubere Rückdokumentation ist entscheidend.

Zugriffe reduzieren

• Benutzersitzungen abmelden (alle außer Admin).
• Offene PowerShell-Sitzungen beenden:

Get-Process *powershell* | Stop-Process -Id <Prozess-ID>

Virenscanner deaktivieren

• AV (z. B. Bitdefender) deaktivieren (bei Bitdefender: Shift + Rechtsklick > Poweruser).
• Andere Lösungen nach Herstelleranleitung.
• Geht keine Deaktivierung: dokumentieren und fortfahren.

Backup pausieren

• Laufende Backup-Jobs pausieren/deaktivieren – das CU beinhaltet mehrere Neustarts; Sicherungen können den Prozess stören oder beschädigte Backups erzeugen.

Installation des .NET Framework Updates (falls erforderlich)

Im Beispiel nicht nötig – der Vollständigkeit halber:

1. Offline-Installer herunterladen (z. B. .NET 4.8)
2. Als Administrator ausführen, Lizenz akzeptieren, installieren
3. Laufzeit bis zu 60 Minuten, wirkt teils eingefroren
4. Neustart zwingend
5. Danach über Windows Update verfügbare .NET-Sicherheitsupdates nachziehen

IIS URL Rewrite Module (bei bestimmten CUs)

Seit dem CU vom September 2021 gibt es einen sicherheitsrelevanten „Not-Aus-Schalter“. Dafür ist vorab das IIS URL Rewrite Module nötig:

Microsoft URL Rewrite Module

Installation dauert nur wenige Minuten und sollte vor dem CU erfolgen, falls das CU diese Abhängigkeit mitbringt.

Installation des Cumulative Updates (CU)

Vor der Installation den Exchange Server einmal neu starten, um sauber zu starten.

ISO-Datei einbinden

Die CU-ISO per Doppelklick einbinden – sie erscheint als virtuelles Laufwerk.

Wichtiger Hinweis: Extended Protection

Mit aktuellen CUs wird Extended Protection (EP) automatisch aktiviert. Exchange Extended Protection (Microsoft Learn)

Soll EP nicht aktiviert werden:

.\Setup.exe /Update /DoNotEnableEP /IAcceptExchangeServerLicenseTerms_DiagnosticDataON

EP ist eine Sicherheitsfunktion und sollte im Normalfall aktiviert bleiben. /DoNotEnableEP nur nutzen, wenn dokumentierte Kompatibilitätsgründe vorliegen (z. B. bestimmte Loadbalancer-/Hybrid-Szenarien).

CU-Installation starten

1. Administrative PowerShell öffnen
2. Zum ISO-Laufwerk navigieren
3. Installation starten:

.\Setup.exe /Mode:Upgrade /IAcceptExchangeServerLicenseTerms_DiagnosticDataON

Wichtig: setup.exe muss als Administrator laufen, sonst drohen inkonsistentes Verhalten oder ein defekter Exchange-Server.

Während der Installation

• Die Installation kann mehrfach längere Zeit „hängen“ – das ist normal.
• Alle Exchange-Dienste sind gestoppt – das Monitoring sollte das erkennen (ggf. Wartungsfenster setzen).
• Häufige Fehlerursache: Backup-Software startet automatisch → Backup-Jobs vorab stoppen!

Neustart nach dem CU-Update

Nach der Installation ist ein Neustart zwingend. Er kann ungewöhnlich lange dauern – teils bis zu einer Stunde, bis alle Dienste laufen.

Nacharbeiten nach dem CU-Update

Sonderanpassungen prüfen und ggf. erneut setzen

web.config-Anpassungen u. Ä. jetzt prüfen und bei Bedarf erneut vornehmen – CUs überschreiben solche Änderungen.

Arbeiten nach dem Neustart

1. Dienste & Konfiguration

Exchange-Dienste gestartet und in erwarteter Konfiguration? → Abgleich mit Vorher-Screenshot.

2. Komponentenstatus

Get-ServerComponentState <Servername>

→ Abgleich mit dokumentiertem Zustand.

3. Datenbankstatus

Im EAC → Servers → Databases prüfen, ob alle Datenbanken eingebunden/bereitgestellt sind. (PowerShell: Get-MailboxDatabaseCopyStatus.)

4. Mailflow testen

Test eingehend und ausgehend (z. B. Admin sendet an Techniker, erhält Antwort).

5. OWA / Outlook-Zugriff prüfen

OWA mit Testnutzer testen, wenn möglich Outlook-Konnektivität prüfen.

6. Monitoring prüfen

Alles wieder „grün“? CPU-Last direkt nach Neustart erhöht ist normal – nach 30–60 Minuten sollte sie sich stabilisieren.

7. Ereignisprotokolle prüfen

Anwendungs-/System-Eventlogs filtern (Kritisch/Fehler/Warnung). Kurz nach dem Neustart sind manche Fehler normal und verschwinden wieder.

Letzte Schritte nach dem CU-Update

Prüfung mit Test-ServiceHealth

Test-ServiceHealth

Alle erforderlichen Dienste sollten „Running“ zeigen.

Microsoft empfiehlt, nach dem Update erneut den Exchange Health Checker laufen zu lassen, um offene Folgeaktionen zu erkennen.

Reaktivierung des Virenscanners

Falls manuell deaktiviert und nicht automatisch zurück: AV wieder aktivieren.

Backup fortsetzen

Pausierten Backup-Job fortsetzen (Rechtsklick → Fortsetzen).

Prüfung der erfolgreichen Installation

Get-ExchangeServer | Select-Object Name, AdminDisplayVersion | Format-Table

Beispielausgabe:

Name    AdminDisplayVersion
----    -------------------
EXCH04  Version 15.1 (Build 2044.4)
EXCH05  Version 15.1 (Build 2176.2)

Die Build-Nummer muss der Zielversion entsprechen (siehe Microsoft Build-Liste).

Abschluss

• Information kommunizieren (intern an Service Owner, extern an Kunde/Ansprechpartner).
• Installationsdateien bereinigen (ISO und extrahierte Dateien löschen, Papierkorb leeren).

Bonus: Pre-Flight-Skript

Das begleitende PowerShell-Skript PS_Exchange_CU_PreFlight_Check.ps1 sammelt den kompletten IST-Zustand (Versionen, Dienste, ComponentState, AD-Schema, FSMO, .NET, Transport Agents, Pending-Reboot) read-only in eine Textdatei – ideal für die Vorher-/Nachher-Dokumentation.

Ziel

Erstelle eine dynamische Verteilergruppe, die nur aktive Benutzer mit einer bestimmten Adresse (z. B. „Bahnhofsstraße 7“) enthält.

PowerShell-Befehl

New-DynamicDistributionGroup `
  -Name "GP_NRW" `
  -OrganizationalUnit "Users" `
  -RecipientContainer "domain.tld" `
  -RecipientFilter {
    (StreetAddress -eq 'Bahnhofsstraße 7') -and
    (RecipientType -eq 'UserMailbox') -and
    (UserAccountControl -ne '514')
  }

Erklärung der Filterkriterien

Hintergrundwissen: UserAccountControl

Im Exchange RecipientFilter ist der Status „deaktiviert“ nicht als boolesches Attribut vorhanden. Stattdessen steht:

• 514 für: deaktiviertes Benutzerkonto
• 512 für: aktiviertes Benutzerkonto

Durch die Negation -ne '514' stellst du sicher, dass nur aktive Objekte in der Gruppe landen.

Ergebnis

Nach dem Ausführen des Befehls hast du eine dynamische Gruppe GP_NRW, die sich automatisch aktualisiert, sobald Benutzer mit dieser Adresse hinzugefügt oder entfernt werden – ohne manuelle Pflege.

Bonus: Abfrage testen

Falls du erstmal prüfen willst, wer in der Gruppe landen würde, kannst du folgenden Testbefehl nutzen:

Get-Recipient -RecipientPreviewFilter `
  "((StreetAddress -eq 'Bahnhofsstraße 7') -and (RecipientType -eq 'UserMailbox') -and (UserAccountControl -ne '514'))" `
  -OrganizationalUnit "Users" `
  -RecipientContainer "domain.tld"

Fazit: Dynamische Gruppen sind ideal für standortbasierte Kommunikation – mit gezieltem Filter sparst du dir manuelle Pflege und erhöhst die Genauigkeit.

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

Moin Leute,

selten aber dennoch kommt es mal vor einen viel zu lang betriebenen Exchange Server vorzufinden.
In meinem Fall handelt es sich um einen Exchange Server 2013 im Jahre 2025. Der Support ist schon lange hinfällig und das WMSVC-Zertifikat, welches eigentlich eine sehr lange Gültigkeitsdauer besitzt, ist daher jetzt kurz vor dem ablaufen.

Normalerweise muss man dieses Zertifikat nie anfassen, jetzt wird es aber doch Zeit dafür..
Die Migration auf Exchange 2019 steht übrigens zeitnah an. Egal.

Was würde es bedeuten, wenn das Zertifikat einfach abläuft? Haben wir dann Probleme?
Definitiv JA, das Zertifkat ist essentiell für den „Web Management Service„-Service!

Aufgabe des Web Management Service (WMS)

Der Web Management Service ermöglicht Remote- und lokale Verwaltung von IIS-Servern und deren Websites. Er wird benötigt für:

• Remote-Verwaltung von IIS: Über den Web Management Service können Administratoren IIS und damit auch Exchange-bezogene virtuelle Verzeichnisse (z. B. OWA, EWS, Autodiscover) remote konfigurieren.
• Konfigurationsänderungen: Der Dienst ermöglicht die Synchronisierung und Verwaltung von Konfigurationen in IIS.
• Integration mit Exchange: Exchange setzt auf IIS für die Bereitstellung seiner Webdienste (z. B. Outlook on the Web, Exchange Web Services), sodass der Web Management Service häufig benötigt wird, um Änderungen oder Diagnosen durchzuführen.

Warum muss der Web Management Service laufen?

Auf einem Exchange-Server wird der Web Management Service benötigt, wenn:

1. IIS-Funktionen verwendet werden: Die Webschnittstellen von Exchange (wie OWA oder ECP) hängen von korrekt konfigurierten virtuellen Verzeichnissen in IIS ab.
2. Remote-Verwaltung erforderlich ist: Falls ein Administrator den Server remote verwalten möchte, ist dieser Dienst entscheidend.
3. Zertifikatsverwaltung oder andere Webserver-bezogene Aufgaben durchgeführt werden: Viele dieser Aufgaben greifen auf den Web Management Service zurück.

Was passiert, wenn der Web Management Service nicht läuft?

1. Verlust der Remote-Verwaltung: Administratoren können IIS nicht mehr remote verwalten, was Diagnosen und Änderungen erschwert.
2. Probleme mit IIS und Exchange-Webdiensten: Änderungen an IIS (z. B. für Autodiscover, OWA, ECP) können nicht korrekt durchgeführt werden. Manche Exchange-Funktionen, die auf IIS beruhen, könnten ebenfalls beeinträchtigt sein.
3. Eingeschränkte Verwaltungstools: Tools, die auf den Web Management Service zugreifen, können nicht verwendet werden.

Wie tauscht oder verlängert man das Zertifikat?

1. Neues WMSVC-Zertifikat erstellen

• Exchange Management Shell öffnen: Starten Sie die Exchange Management Shell mit Administratorrechten.
• Neues Zertifikat erstellen: Führen Sie den folgenden Befehl aus, wobei Sie <ServerName> durch den Hostnamen Ihres Exchange-Servers ersetzen: New-ExchangeCertificate -SubjectName "CN=WMSvc-<ServerName>" -FriendlyName "WMSVC" -Services None -KeySize 2048 -PrivateKeyExportable $true Dieser Befehl erstellt ein neues selbstsigniertes Zertifikat mit dem Namen „WMSVC“.

2. Neues Zertifikat in den Zertifikatsspeicher „Vertrauenswürdige Stammzertifizierungsstellen“ kopieren

• Microsoft Management Console (MMC) öffnen: Drücken Sie Win + R, geben Sie mmc ein und drücken Sie Enter.
• Zertifikate-Snap-In hinzufügen:
  • Gehen Sie zu Datei > Snap-In hinzufügen/entfernen.
  • Wählen Sie Zertifikate und klicken Sie auf Hinzufügen.
  • Wählen Sie Computerkonto und klicken Sie auf Weiter, dann auf Fertig stellen.
• Zertifikat kopieren:
  • Navigieren Sie zu Zertifikate (Lokaler Computer) > Persönlich > Zertifikate.
  • Suchen Sie das neu erstellte WMSVC-Zertifikat, klicken Sie mit der rechten Maustaste darauf und wählen Sie Kopieren.
• Zertifikat einfügen:
  • Navigieren Sie zu Zertifikate (Lokaler Computer) > Vertrauenswürdige Stammzertifizierungsstellen > Zertifikate.
  • Klicken Sie mit der rechten Maustaste in den rechten Bereich und wählen Sie Einfügen.

3. Altes WMSVC-Zertifikat entfernen

• Altes Zertifikat löschen:
  • In der MMC unter Persönlich > Zertifikate das alte WMSVC-Zertifikat suchen.
  • Mit der rechten Maustaste darauf klicken und Löschen wählen.

4. Neues Zertifikat dem Webverwaltungsdienst zuweisen

• IIS-Manager öffnen: Starten Sie den Internetinformationsdienste (IIS)-Manager.
• Management Service konfigurieren:
  • Wählen Sie den Serverknoten in der linken Baumstruktur.
  • Doppelklicken Sie im mittleren Bereich auf Verwaltungsdienst.
  • Unter SSL-Zertifikat das neu erstellte WMSVC-Zertifikat auswählen.
  • Klicken Sie auf Übernehmen.
• Webverwaltungsdienst starten:
  • Gehen Sie zu Dienste (services.msc).
  • Suchen Sie den Webverwaltungsdienst, klicken Sie mit der rechten Maustaste darauf und wählen Sie Starten.

Hinweis: Stellen Sie sicher, dass das neue Zertifikat korrekt zugewiesen ist und der Webverwaltungsdienst ordnungsgemäß funktioniert. Es ist ratsam, regelmäßige Überprüfungen der Zertifikatsgültigkeit durchzuführen, um einen unterbrechungsfreien Betrieb zu gewährleisten.

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.

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.

In diesem Blogbeitrag werden wir uns näher mit Microsoft PowerShell befassen und seine wichtigsten Funktionen, Vorteile und Anwendungen untersuchen. Wir werden auch einen Einblick in die Skripterstellung und -ausführung mit PowerShell geben und einige Beispiele für die Verwendung von PowerShell in verschiedenen Szenarien diskutieren.

Grundsätzlich ist die Powershell für administrative Arbeiten immer als Administrator zu starten.

Microsoft PowerShell: Die Funktionen, die Systemadministratoren lieben werden

1. Automatisierung von Aufgaben

Eines der wichtigsten Merkmale von PowerShell ist die Fähigkeit, Aufgaben zu automatisieren. Mit PowerShell können Systemadministratoren Prozesse automatisch durchführen lassen, wie z.B. das Erstellen von Benutzerkonten, das Verwalten von Netzwerkeinstellungen oder das Installieren von Software auf mehreren Systemen gleichzeitig. Hier ist ein Beispiel dafür, wie PowerShell bei der Erstellung von Benutzerkonten helfen kann:

# Benutzerkonto erstellen
New-LocalUser -Name "MaxMustermann" -Description "Standardbenutzer" -Password (ConvertTo-SecureString "password123" -AsPlainText -Force)

# Benutzer zu einer Gruppe hinzufügen
Add-LocalGroupMember -Group "Administratoren" -Member "MaxMustermann"

In diesem Beispiel wird ein neues lokales Benutzerkonto namens „MaxMustermann“ erstellt und dem Administratoren-Gruppe hinzugefügt. Dieser Prozess kann automatisiert werden, um Zeit zu sparen und Fehler zu reduzieren.

2. Verwaltung von Systemkonfigurationen

Du kannst PowerShell auch viele Funktionen zur Verwaltung von Systemkonfigurationen nutzen. Mit PowerShell ist es möglich, Informationen über Systemkonfigurationen abzurufen, diese zu ändern oder zu überwachen. Ein Beispiel dafür, wie PowerShell bei der Überwachung von Systemereignissen helfen kann, ist:

# Ereignisprotokolle abrufen
Get-EventLog -LogName Application -EntryType Error

# Ereignisse filtern
Get-EventLog -LogName Application -InstanceId 1000

# Ereignisse in Echtzeit überwachen
Get-EventLog -LogName System -Newest 10 -Wait

In diesem Beispiel rufst du das Anwendungsereignisprotokoll ab und filterst nach Fehlern (EntryType Error). Du kannst auch nach bestimmten Ereignis-IDs suchen oder Ereignisse in Echtzeit überwachen, um Probleme auf deinem System schnell zu erkennen.

3. Verwaltung von Netzwerkeinstellungen

Du kannst PowerShell auch bei der Verwaltung von Netzwerkeinstellungen nutzen. Mit PowerShell ist es möglich, Netzwerkadapter, IP-Adressen, DNS-Server und vieles mehr zu konfigurieren und zu überwachen. Hier ist ein Beispiel dafür, wie PowerShell bei der Konfiguration von Netzwerkadaptern helfen kann:

# Netzwerkadapter abrufen
Get-NetAdapter

# Netzwerkkonfiguration abrufen
Get-NetIPConfiguration

# IP-Adresse konfigurieren
New-NetIPAddress -IPAddress 192.168.1.100 -PrefixLength 24 -DefaultGateway 192.168.1.1

# DNS-Serveradresse hinzufügen
Set-DnsClientServerAddress -InterfaceIndex 12 -ServerAddresses ("192.168.1.10","192.168.1.11")

In diesem Beispiel wird eine neue IP-Adresse für das System konfiguriert und DNS-Serveradressen hinzugefügt.

PowerShell kann auch verwendet werden, um Netzwerkverbindungen zu überwachen und Netzwerkdiagnosen durchzuführen. Hier ist ein Beispiel dafür, wie PowerShell bei der Überwachung von Netzwerkverbindungen helfen kann:

# Netzwerkverbindungen anzeigen
Get-NetTCPConnection

# Netzwerkdiagnose durchführen
Test-NetConnection -ComputerName google.com -Port 80

In diesem Beispiel werden alle aktiven TCP-Verbindungen auf dem System angezeigt und eine Netzwerkdiagnose für die Verbindung zu Google.com auf Port 80 durchgeführt.

Die Verwaltung von Netzwerkeinstellungen ist eine wichtige Aufgabe für Systemadministratoren, da sie die Netzwerkverbindung und den Zugriff auf Ressourcen auf dem System beeinflussen. PowerShell bietet eine leistungsstarke Möglichkeit, diese Einstellungen zu konfigurieren, zu überwachen und zu diagnostizieren.

4. Verwaltung von Dateien und Ordnern

PowerShell bietet auch viele Funktionen zur Verwaltung von Dateien und Ordnern. Du kannst PowerShell verwenden, um Dateien und Ordner zu erstellen, zu kopieren, zu löschen, umzubenennen und vieles mehr. Hier ist ein Beispiel dafür, wie PowerShell beim Kopieren von Dateien helfen kann:

# Datei von einem Ort zum anderen kopieren
Copy-Item -Path C:\Users\MaxMustermann\Documents\example.txt -Destination C:\Users\MaxMustermann\Desktop

# Mehrere Dateien kopieren
Copy-Item -Path C:\Users\MaxMustermann\Documents\*.txt -Destination C:\Users\MaxMustermann\Desktop

In diesem Beispiel wird eine Datei von einem Ort zum anderen kopiert. Du kannst auch mehrere Dateien auf einmal kopieren, um Zeit zu sparen und Fehler zu reduzieren.

WICHTIG: Sollten im Pfad Leerzeichen vorhanden sein, muss der Pfad in „“ gesetzt werden.

5. Integration mit anderen Tools

PowerShell kann auch nahtlos mit anderen Tools und Systemen integriert werden. Du kannst PowerShell-Skripte in andere Programme einbinden oder PowerShell verwenden, um Informationen von anderen Tools zu erhalten. Hier ist ein Beispiel dafür, wie PowerShell mit Active Directory integriert werden kann (Module evtl. notwendig):

# Benutzer aus Active Directory abrufen
Get-ADUser -Filter * -Properties *

# Neue Benutzergruppe erstellen
New-ADGroup -Name "IT-Abteilung" -GroupScope Global -Path "CN=Users,DC=example,DC=com"

In diesem Beispiel wird Active Directory verwendet, um Benutzer und Benutzergruppen zu verwalten. PowerShell kann auch mit anderen Tools wie SQL Server, Exchange Server und SharePoint integriert werden.

6. Neue Module installieren/importieren

Um neue Cmdlets in PowerShell zu importieren, musst du zuerst das entsprechende PowerShell-Modul installieren, das diese Cmdlets enthält. Ein PowerShell-Modul ist eine Sammlung von Cmdlets, Funktionen, Variablen und anderen Ressourcen, die in PowerShell wiederverwendet werden können.

Es gibt verschiedene Möglichkeiten, PowerShell-Module zu installieren. Eine Möglichkeit besteht darin, das Modul manuell von einer Website oder einem Netzwerkfreigabe herunterzuladen und zu installieren. Eine andere Möglichkeit besteht darin, das Modul direkt aus dem PowerShell Gallery-Repository zu installieren, das eine Sammlung von PowerShell-Modulen und Skripten bereitstellt.

Hier sind einige Beispiele, wie Sie PowerShell-Module installieren und importieren können:

1. PowerShell Gallery-Modul installieren und importieren:

• Öffnen PowerShell als Administrator.
• Gebe den Befehl „Install-Module <Modulname>“ ein, um das Modul aus der PowerShell Gallery zu installieren. Zum Beispiel: „Install-Module ActiveDirectory“.
• Gebe den Befehl „Import-Module <Modulname>“ ein, um das Modul zu importieren und die darin enthaltenen Cmdlets und Funktionen zu aktivieren. Zum Beispiel: „Import-Module ActiveDirectory“.

2. Lokales PowerShell-Modul installieren und importieren:

• Lade das Modul von der Website oder der Netzwerkfreigabe herunter und speichere es in einem Verzeichnis auf deinem Computer.
• Öffnen PowerShell als Administrator.
• Gebe den Befehl „Import-Module <Pfad zum Modulverzeichnis>“ ein, um das Modul zu importieren und die darin enthaltenen Cmdlets und Funktionen zu aktivieren. Zum Beispiel: „Import-Module C:\Modules\MyModule“.

3. PowerShell-Modul in einer PowerShell-Sitzung installieren und importieren:

• Gebe den Befehl „Install-Module <Modulname>“ ein, um das Modul aus der PowerShell Gallery zu installieren. Zum Beispiel: „Install-Module ActiveDirectory“.
• Gebe den Befehl „Import-Module <Modulname> -Force“ ein, um das Modul zu importieren und die darin enthaltenen Cmdlets und Funktionen zu aktivieren. Der Parameter „-Force“ sorgt dafür, dass das Modul sofort importiert wird. Zum Beispiel: „Import-Module ActiveDirectory -Force“.

Sobald du das PowerShell-Modul erfolgreich installiert und importiert hast, kannst du die darin enthaltenen Cmdlets und Funktionen verwenden, um Verwaltungsaufgaben auszuführen. Zum Beispiel kannst du das „ActiveDirectory“-Modul verwenden, um Benutzer- und Gruppenkonten im Active Directory zu verwalten. Ein Beispiel für die Verwendung des „Get-ADUser“-Cmdlets aus dem „ActiveDirectory“-Modul wäre:

# Benutzerkonto im Active Directory abfragen
Get-ADUser -Identity john.doe -Properties DisplayName, EmailAddress

Dieser Befehl ruft Informationen über das Benutzerkonto „john.doe“ ab, einschließlich des Anzeigenamens und der E-Mail-Adresse, die im Active Directory gespeichert sind.

Vorteile von Microsoft PowerShell:

Microsoft PowerShell bietet eine Vielzahl von Vorteilen gegenüber anderen Befehlszeilen-Schnittstellen. Hier sind einige der wichtigsten Vorteile:

1. Automatisierung und Effizienz: PowerShell ermöglicht es, wiederkehrende Verwaltungsaufgaben zu automatisieren und dadurch Zeit und Aufwand zu sparen. Durch die Verwendung von Cmdlets kannst du komplexe Aufgaben in kurzer Zeit erledigen, da mehrere Schritte in einem Befehl ausgeführt werden können.
2. Umfangreiche Skriptsprache: PowerShell verfügt über eine umfangreiche Skriptsprache, die es ermöglicht, komplexe Aufgaben zu automatisieren. Mit PowerShell kannst du Funktionen, Schleifen, Bedingungen und andere Kontrollstrukturen erstellen, um Skripts zu schreiben, die mehrere Aufgaben ausführen können.
3. Remote-Verwaltung: PowerShell ermöglicht die Verwaltung von entfernten Systemen über eine einzige Schnittstelle. Du kannst PowerShell-Cmdlets verwenden, um Remote-Verbindungen zu öffnen, Dateien und Ordner zu kopieren, Dienste zu starten und zu stoppen und vieles mehr.
4. Einfache Handhabung von Objekten: PowerShell behandelt alles als Objekte, einschließlich Dateien, Ordner, Dienste, Benutzer und Gruppen. Dies erleichtert die Handhabung von Objekten und die Automatisierung von Aufgaben, da du einfach auf die Eigenschaften und Methoden dieser Objekte zugreifen kannst.
5. Unterstützung für Module: PowerShell unterstützt Module, die eine Sammlung von Cmdlets, Funktionen und Variablen sind. Module können einfach installiert und importiert werden, um zusätzliche Funktionen und Möglichkeiten hinzuzufügen.

Zusammenfassend bietet Microsoft PowerShell eine leistungsstarke Befehlszeilen-Schnittstelle mit umfangreichen Funktionen, die es Benutzern ermöglicht, Aufgaben effizienter und schneller zu erledigen. Mit PowerShell können Verwaltungsaufgaben automatisiert und eine Vielzahl von Aufgaben durchgeführt werden, einschließlich der Verwaltung von lokalen und entfernten Systemen, Dateien und Ordnern, Benutzern und Gruppen und vielem mehr.

Skripterstellung und -ausführung mit Microsoft PowerShell:

Microsoft PowerShell ist nicht nur eine leistungsstarke Befehlszeilen-Schnittstelle, sondern auch eine mächtige Skripting-Sprache. Hier sind einige wichtige Informationen zur Skripterstellung und -ausführung mit PowerShell:

1. PowerShell ISE: PowerShell ISE ist eine integrierte Skripting-Umgebung, die das Erstellen und Debuggen von PowerShell-Skripten erleichtert. PowerShell ISE bietet Syntaxhervorhebung, Intellisense und Debugging-Tools, um die Skriptentwicklung zu vereinfachen. Um PowerShell ISE zu öffnen, gibst du einfach „powershell_ise“ in die PowerShell-Eingabeaufforderung ein.
2. Erstellen von Skripten: PowerShell-Skripte können mit jedem Texteditor erstellt werden. Speichere das Skript als .ps1-Datei, um es später auszuführen. PowerShell-Skripte können auch in PowerShell ISE erstellt und gespeichert werden.
3. Ausführung von Skripten: PowerShell-Skripte können auf verschiedene Arten ausgeführt werden. Wenn du das Skript in PowerShell ISE erstellt hast, kannst du es einfach ausführen, indem du auf die Schaltfläche „Ausführen“ klickst oder die F5-Taste drückst. Wenn das Skript in einem Texteditor erstellt wurde, kannst du es in PowerShell mit dem Befehl „.\skriptname.ps1“ ausführen. Beachte jedoch, dass PowerShell standardmäßig keine nicht signierten Skripte ausführt. Um ein nicht signiertes Skript ausführen zu können, musst du zunächst die Execution Policy ändern.
4. Syntax: PowerShell-Skripte verwenden eine einfache, leicht verständliche Syntax. Cmdlets und Parameter werden durch Leerzeichen getrennt. Beispiel: „Get-ChildItem -Path C:\Temp“ gibt eine Liste der Dateien und Ordner im Ordner „C:\Temp“ zurück.
5. Beispiele:

Beispiel 1: Dieses Skript gibt die Größe aller Dateien im Ordner „C:\Temp“ aus:

Get-ChildItem -Path C:\Temp | ForEach-Object { $_.Name + ": " + $_.Length } 

Beispiel 2: Dieses Skript führt eine Suche nach Dateien mit der Endung „.log“ im Ordner „C:\Logs“ durch und gibt das Ergebnis aus:

Get-ChildItem -Path C:\Logs -Filter *.log 

Beispiel 3: Dieses Skript erstellt einen neuen Ordner „Test“ im Ordner „C:\Temp“:

New-Item -ItemType Directory -Path C:\Temp\Test

Zusammenfassend bietet PowerShell eine einfache Syntax und eine Vielzahl von Tools zur Skripterstellung und -ausführung. PowerShell ISE erleichtert die Skriptentwicklung und -debugging, während PowerShell-Skripte auf einfache Weise in Texteditoren erstellt und ausgeführt werden können.

Execution Policy ändern

Um die aktuelle Execution Policy in PowerShell zu speichern, kannst du die folgenden Schritte ausführen:

1. Öffne die PowerShell-Eingabeaufforderung.
2. Gebe den Befehl „Get-ExecutionPolicy“ ein, um die aktuelle Execution Policy anzuzeigen.
3. Speichere die Ausgabe des Befehls, in eine Variable $policy = Get-ExecutionPolicy
4. Um die Execution Policy zu ändern, gebe den Befehl „Set-ExecutionPolicy“ ein und wähle eine der verfügbaren Optionen:
   • „Restricted“ (keine Skripts erlaubt)
   • „AllSigned“ (nur signierte Skripts erlaubt)
   • „RemoteSigned“ (signierte Skripts von lokalen Computer erlaubt)
   • „Unrestricted“ (alle Skripts erlaubt)
   Beispiel: „Set-ExecutionPolicy RemoteSigned“
5. Wenn die Execution Policy wiederhergestellt werden soll, setze die Policy einfach auf den Wert, der zuvor gespeichert wurde: Set-ExecutionPolicy $policy

Weitere Option: „Bypass": Die Execution Policy wird für das aktuelle PowerShell-Skript deaktiviert.

Beachte, dass hier Administratorrechte benötigt werden, um die Execution Policy zu ändern. Es ist auch wichtig zu beachten, dass die Execution Policy auf Systemebene festgelegt ist und für alle Benutzer und Skripts gilt. Natürlich kann die Policy auch auf Benutzerebene umgestellt werden.

Die verfügbaren Werte für den Scope-Parameter sind:

• Process: Die Änderung der Execution Policy wird nur für die aktuelle PowerShell-Sitzung angewendet.
• CurrentUser: Die Änderung der Execution Policy wird für den aktuellen Benutzer auf dem aktuellen Computer angewendet.
• LocalMachine: Die Änderung der Execution Policy wird für alle Benutzer auf dem aktuellen Computer angewendet.

Der Scope-Parameter kann wie folgt in PowerShell verwendet werden:

Set-ExecutionPolicy <Parameter> -Scope <Scope-Parameter>

Beispiel:

Set-ExecutionPolicy RemoteSigned -Scope CurrentUser

Dies setzt die Execution Policy nur für den aktuellen Benutzer auf dem aktuellen Computer.

Signieren von Skripten

Um ein PowerShell-Skript mit einem selbstausgestellten Zertifikat zu signieren, kannst du die folgenden Schritte ausführen:

Generiere ein selbstsigniertes Zertifikat auf deinem Computer. Dazu kannst du das PowerShell-Modul „New-SelfSignedCertificate“ verwenden. Gebe dazu den folgenden Befehl ein:

$cert = New-SelfSignedCertificate -CertStoreLocation Cert:\CurrentUser\My -DnsName "MyCertName" 

Dieser Befehl erstellt ein neues Zertifikat mit dem Namen „MyCertName“ im aktuellen Benutzerzertifikatspeicher.

Exportiere das Zertifikat als PFX-Datei. Gebe dazu den folgenden Befehl ein:

$pwd = ConvertTo-SecureString -String "MyPassword" -Force -AsPlainText Export-PfxCertificate -Cert $cert -FilePath "C:\MyCert.pfx" -Password $pwd

Ersetze „MyPassword“ durch ein sicheres Kennwort, das zum Schutz der PFX-Datei verwendet werden soll.

Importiere das Zertifikat in den Trusted Publishers Store. Gebe dazu den folgenden Befehl ein:

Import-PfxCertificate -FilePath "C:\MyCert.pfx" -CertStoreLocation Cert:\CurrentUser\TrustedPublisher -Password $pwd

Signiere das PowerShell-Skript mit dem Zertifikat. Gebe dazu den folgenden Befehl ein:

Set-AuthenticodeSignature -FilePath "C:\MyScript.ps1" -Certificate $cert -TimestampServer http://timestamp.digicert.com 

Ersetze „C:\MyScript.ps1“ durch den Pfad zu deinem Skript und „http://timestamp.digicert.com“ durch den Zeitserver deiner Wahl.

Das Skript ist jetzt signiert und kann sicher ausgeführt werden. Beachte, dass Benutzer, die das Skript ausführen, das selbstsignierte Zertifikat manuell in ihren Trusted Publishers Store importieren müssen, um das Vertrauen in das Zertifikat zu bestätigen.

In einer großen Umgebung kann das Zertifikat natürlich auch via GPO ausgerollt werden, hier bietet es sich auch an ein Zertifikat aus der eigenen PKI zu verwenden.

Um ein Zertifikat von der eigenen PKI zu verwenden, musst du sicherstellen, dass das Zertifikat den Zweck „Code Signing“ unterstützt. Dies ist in der Regel durch ein spezielles Template in deiner PKI festgelegt, das für die Ausstellung von Code Signing-Zertifikaten konfiguriert ist.

Das Template sollte die folgenden Einstellungen enthalten:

• Zweck: Code Signing
• Verwendung: Digital Signature
• Private Key: Key Exchange
• Exportable: Ja

Wenn das Template nicht vorhanden ist, musst du es möglicherweise erstellen oder die erforderlichen Einstellungen in einem vorhandenen Template ändern.

Nachdem ein Zertifikat mit den richtigen Einstellungen erstellt wurde, kann das Zertifikat in PowerShell importiert werden und dann das Skript signiert werden, indem der folgende Befehl ausgeführt wird:

Set-AuthenticodeSignature -FilePath "C:\MyScript.ps1" -Certificate $cert -TimestampServer http://timestamp.digicert.com

Ersetze „C:\MyScript.ps1“ durch den Pfad zu deinem Skript und „$cert“ durch das Zertifikat, das du importiert hast.

Beachte, dass der TimestampServer optional ist, aber empfohlen wird, um sicherzustellen, dass das signierte Skript auch nach Ablauf des Zertifikats vertrauenswürdig bleibt. Verwende die URL des Timestamp-Servers, den deine PKI oder dein Vertrauensprovider empfiehlt.

Ein paar Exchange Skript Beispiele:

1. Skript zum Überprüfen von Postfachberechtigungen:

Dieses Skript überprüft die Postfachberechtigungen für ein bestimmtes Postfach und gibt eine Liste der Benutzer und Gruppen aus, die Zugriff auf das Postfach haben.

Get-MailboxPermission -Identity "Postfachname" | where {$_.user.tostring() -ne "NT-AUTORITÄT\SELBST" -and $_.IsInherited -eq $false} | Select Identity,User,AccessRights

2. Skript zum Exportieren von Postfachdaten:

Dieses Skript exportiert die Postfachdaten eines bestimmten Benutzers in eine PST-Datei.

New-MailboxExportRequest -Mailbox "Benutzername" -FilePath "\\Servername\Export\Benutzername.pst"

3. Skript zum Erstellen von Regeln:

Dieses Skript erstellt eine Regel, die Nachrichten von einer bestimmten E-Mail-Adresse direkt in einen bestimmten Ordner verschiebt.

New-InboxRule -Name "Regelname" -MailFrom "E-Mail-Adresse" -MoveToFolder "Ordnername"

4. Skript zum löschen eines Postfaches:

Dieses Skript löscht ein bestimmtes Postfach und alle dazugehörigen Datenbankobjekte.

Remove-Mailbox -Identity "Benutzername" -Database "Datenbankname" -Confirm:$false

Abschließend noch eine generelle Empfehlung, nutzt immer vorab zum Test den -WhatIf Parameter am Ende des Codes oder testet eure Skripte in einer Demo-Umgebung.

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

Link zum Microsoft-Artikel: Link

Vor dem eigentlichen Vorgang muss sichergestellt werden, dass der Administrator die benötigten Rollen/Rechte besitzt um Importe/Exporte durchzuführen.

Dafür im Exchange Online Admin Center unter Rollen > Administrator Rollen eine neue Gruppenrolle anlegen:

Gebt der Gruppenrolle einen Namen und eine Beschreibung:

Die folgenden beiden Rollen müssen der Gruppenrolle hinzugefügt werden:

Zum Schluss noch dem Admin oder Service-Account zuweisen:

Abschließen und damit ist die Grundvoraussetzung gegeben.

Des Weiteren sollte eine Import-Datei nicht größer sein als 20GB, dann lieber zuvor aufteilen.

Im ersten Schritt wird ein Import-Auftrag angelegt.

>> https://compliance.microsoft.com

Auf der linken Seite im Portal, Data lifecycle management > Microsoft 365 > Microsoft 365 > Import.

1. Namen eingeben
2. Methode wählen, in unserem Fall „Hochladen“
3. SAS-URL anzeigen und wegspeichern

1. Azure AzCopy herunterladen und starten
2. Upload Starten: AzCopy /source:C:\PST\ /dest:“https://angezeigteSASURL“ /y
3. Zuordnungsdatei anfertigen nach diesem Muster (Mailbox kann z.B. UPN oder GUID sein)

1. Folgend bestätigt man, dass der Upload fertig ist und man die Zuordnungsdatei hat

1. Zuordnungsdatei hochladen und prüfen lassen und auf Speichern klicken.
2. Der Import ist gestartet und dauert nun etwas.

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

Major Upgrade -> Exchange Versionssprung von z.B. 2013 auf 2016

Minor Upgrade -> CU-Update z.B: von 2019 CU 11 auf 12

Hotfix/Security Update -> z.B: von CU12 auf CU12 AUG22SU

Ich hoffe ich kann dem ein oder anderen damit eine kleine Hilfestellung leisten.
Du hast Ergänzungen? Nur her damit!