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!

Ist die GPO komplett neu angelegt? Oder wurde eine bestehende genutzt und umgeändert?

Folgend habe ich euch mal mögliche Grüne aufgeführt, die mir eingefallen sind. Gerne könnt ihr mir in den Kommentaren Ergänzungsvorschläge mitteilen.

Der Scope (Anwendungsbereich) ist nicht richtig definiert

Die GPO muss natürlich zwingend auf die Organisationseinheiten (OU) angewendet werden, in dem die Objekte liegen, die die GPO erhalten sollen.

Weitere Einschränkungsmöglichkeiten:

1. Sicherheitsfilter: Standardmäßig wird eine GPO auf alle „Authentifizierte Benutzer / Authenticated Users“ gefiltert, sprich alle AD-Mitglieder. Hier kann auf einzelne/mehrere Objekte gefiltert werden.
2. WMI-Filter: Möglichkeit einer Filterung auf bestimmte Betriebsversionen (Windows Management Instrumentation)

Sollten diese Filtermöglichkeiten genutzt worden sein, ist sicherzustellen, dass die Benutzer/Computer enthalten sind.

Loopback-Policy verhindert die Anwendung

Liegt der Computer an dem sich der Benutzer anmeldet in einer anderen OU, könnte sich dort eine GPO befinden die eine Loopbackverarbeitung aktiviert hat. (Direkt oder vererbt)

Grundsätzlich werden GPO wie folgt gezogen und angewendet:

• Computerrichtlinien = werden beim Bootvorgang/Netzwerkanmeldung des Rechners verarbeitet
• Benutzerrichlinien = werden bei der Benutzeranmeldung verarbeitet
• Änderungen werden standardmäßig alle 90 Minuten synchronisiert

Eine Loopbackverarbeitung bietet zwei mögliche Einstellungsmöglichkeiten:

• Zusammenführen (die Computerrichtlinien werden nach den Benutzerrichtlinien angewendet und erhalten so eine höhere Priorität)
• Ersetzen (Benutzerrichtlinien werden vollkommen von Computerrichtlinien ersetzt, heißt GPO die auf der Benutzer-OU liegen werden ignoriert. Liegen an der Computer-OU Benutzerrichtlinien an, werden diese angewendet.)

Nötige Berechtigungen sind nicht gegeben

Haben die Benutzer und Computer die nötigen Lese- und Anwendungsrechte auf der GPO?

Damit eine GPO erfolgreich angewendet werden kann, muss diese von dem Benutzer/Computer gelesen und angewendet werden dürfen. Unter „Delegierung“ kann dies geprüft und korrigiert werden.

Benutzer- oder Computereinstellungen der GPO deaktiviert

Enthält eine GPO nur Benutzerrichtlinien, empfiehlt es sich die Computereinstellungen der GPO zu deaktivieren.

Enthält eine GPO hingegen nur Computerrichtlinien, sollten die Benutzereinstellungen deaktiviert werden.

Enthält sie beides sollte natürlich nichts dergleichen deaktiviert werden.

Grundsätzlich solltet ihr für einen neuen Zweck, immer eine neue frische GPO anlegen, sauber konfigurieren, einen Kommentar hinterlegen und nur notwendige Rechte vergeben.

Vor Verknüpfung einer GPO auf eine Produktivumgebung, bitte immer erst testen.