Inhalt
ToggleSeit Jahren werden Exchange-Admins nun schon mit der Administration von Hybridbereitstellungen gebeutelt. Es ist technisch bedingt komplex und daher auch fehleranfällig.
Immer wieder taucht die Frage auf: „Muss ich das jetzt lokal oder in der Cloud konfigurieren?“
Nicht selten wird die Antwort dann im Trial-and-Error-Verfahren ermittelt.
Doch Microsoft hat endlich die flehentlichen Bitten erhört und eine Lösung für dieses Problem entwickelt. Ist diese jedoch bereits praxistauglich oder muss man hier ebenfalls Kröten schlucken?
Das soll dieser Beitrag anhand von Erfahrungen aus der Praxis zeigen.
Grundlagen
Begriffsklärung "Hybridbereitstellung"
Zunächst soll einmal kurz geklärt werden, was der Begriff Hybridbereitstellung eigentlich bedeutet. Hieraus ergeben sich dann die Prinzipien für den Betrieb einer solchen Umgebung.
Eine Hybridbereitstellung (oder auch hybride Bereitstellung) bezieht sich zunächst einmal unabhängig von Exchange auf Benutzeridentitäten und weitere Objekte, die aus einem Active Directory nach Entra ID synchronisiert werden.
Hierbei ist es wichtig, zu verstehen, dass der AD-Benutzer und der Entra-Benutzer grundsätzlich zwei getrennte Objekte sind. Diese werden über die Synchronisation lediglich miteinander verbunden und erhalten (weitestgehend) die gleichen Attribute.
Damit nun die Attribute nicht unterschiedlich modifiziert werden und sich gegenseitig überschreiben könnten, ist es erforderlich, eine Autorität für die Bearbeitung dieser Attribute festzulegen. Und diese Autorität ist im Standard Active Directory.
Im weiteren Sinne gilt dieser Grundsatz dann auch für eine Exchange-Hybridkonfiguration. Attribute – vor allem Exchange-bezogene Attribute – müssen lokal modifiziert werden.
Nun gibt es bei Exchange jedoch die Besonderheit, dass einige wenige Einstellungen nur in der Cloud modifiziert werden können. Hierzu zählen beispielsweise:
- Weiter- und Umleitungen auf Postfachebene
- Postfachberechtigungen wie Senden als und Vollzugriff
- Postfachtyp (Benutzer, Freigabe, Ressource)
Dieser Umstand erschwert in der Praxis jedoch die Administrierbarkeit, da sich diese auf zwei Bereiche aufteilt.
Um in der Folge besser auseinanderhalten zu können, um welchen Bereich es geht, werden die Begriffe wie folgt verwendet:
- Hybridbereitstellung = Active Directory + Entra ID
- Hybridkonfiguration = Exchange Server + Exchange Online
Der letzte Exchange Server - warum notwendig?
Vorgaben für die Verwaltung von Exchange-Attributen
Technologisch betrachtet, war und ist Exchange Server nicht dafür ausgelegt, mehrere Organisationen zu umfassen. Das hat sich auch mit der aktuellen Version SE nicht geändert.
Dementsprechend ist eine Hybridkonfiguration im Grunde nur eine Behelfslösung, um die lokale und die Cloud-Organisation miteinander zu verzahnen. In der Praxis wird jedoch deutlich, dass diese einige Einschränkungen hat und die Administration komplexer macht.
Nun könnte man theoretisch sagen:
„Meine Postfächer sind alle in der Cloud und mein MX-Eintrag zeigt auf Exchange Online. Ich brauche den Exchange Server also nicht mehr.“
Während das technisch korrekt sein mag, entspricht es jedoch nicht den Vorgaben von Microsoft. Diese besagen, dass die Administration von Exchange-Attributen in einer Hybridumgebung nur über einen Exchange Server und das zugehörige PowerShell-Modul unterstützt ist.
Dementsprechend ist es weder erlaubt, diese manuell anzupassen noch dafür Drittherstellerlösungen einzusetzen – auch wenn diese technisch dazu in der Lage wäre.
Es war klar, dass diese Problematik kein Dauerzustand sein kann. Allerdings hat es trotzdem recht lange gedauert, bis Microsoft eine Lösung zur Vereinfachung gefunden hat, wie sie diese Komplexität vereinfachen können.
Der erste Schritt - Reduktion auf die Exchange-Verwaltungstools
Am 20. April 2022 wurde das kumulative Update 12 für Exchange Server veröffentlicht. Dieses brachte eine wesentliche Neuerung für die Verwaltung von Exchange-Attributen mit sich – seitdem müssen ausschließlich die Exchange-Verwaltungstools bereitgestellt werden, um darüber die Attribute zu verwalten.
Im Detail offenbarten sich jedoch auch hier wieder einige Schwächen des Ansatzes:
- E-Mail-Objekte und ihre Attribute sind ausschließlich über PowerShell verwaltbar (wenngleich man sich selbst wieder grafische Oberflächen dafür bauen kann)
- Die Verwaltungstools unterstützen keinen rollenbasierten Zugriff, folglich funktionieren sie nicht mit Benutzern aus einer anderen AD-Gesamtstruktur
- Eine Auditierung von Änderungen ist nicht möglich
- Der letzte Exchange Server kann nur heruntergefahren werden, darf aber nicht deinstalliert/gelöscht werden
Die finale Lösung - cloudbasierte Verwaltung
Des Rätsels Lösung brachte dann eine Neuerung, die für Entra ID eingeführt wurde. Seit Ende 2025 ist es möglich, die sogenannte „Source of Authority“ für Benutzer und Gruppen nach Entra ID zu verschieben. Dadurch wird es möglich, diese Objekte vollständig in Entra ID zu verwalten – auch wenn diese aus einem Active Directory synchronisiert werden!
Active Directory muss also nicht mehr zwangsläufig die Autorität für die Verwaltung von Attributen synchronisierter Objekte sein. Und dies führt dann zur Lösung für das Exchange-Problem – E-Mail-aktivierte Objekte sind vollständig über Exchange Online verwaltbar!
Diese Änderung wurde in zwei Phasen eingeführt und ist nun allgemein verfügbar.
Zeit, es einmal auszuprobieren!
Vorbereitungen
Auch wenn es in den Fingern juckt – erst einmal sind Analyse und Planung angesagt. Die folgenden Kapitel nennen einige wichtige Aspekte hierfür.
Alternative Lösung für E-Mail-Relay
Ein Exchange Server wird gerne weiterhin als internes Mail-Relay für Applikationen und Systeme genutzt, die keine oder nur Basisauthentifizierung unterstützen.
Ist dies der Fall, muss eine Alternative hierfür implementiert werden. Die folgende Liste nennt einige Beispiele:
- Postfix für die lokale Bereitstellung
- Nutzung eines SMTP-Relays in Exchange Online
- Nutzung von „direktes Senden“ in Exchange Online
- Aufbau einer Instanz von Azure Communication Services
Verwaltungsskripte
Falls Ihr Verwaltungsskripte einsetzt, die gewisse Abläufe automatisieren, so müssen diese auf Exchange Online umgestellt oder entfernt werden. Ein typisches Beispiel wäre ein Skript zur automatischen Erstellung fehlender Remotepostfächer, dieses wird dann nicht mehr benötigt.
Hierbei ist zu beachten, dass Skripte in der Cloud nicht mehr wie früher über ein Dienstkonto zugreifen, sondern dafür entweder ein sogenanntes Clientgeheimnis (vergleichbar mit einem ablaufenden Kennwort) oder ein Zertifikat benötigt wird. Die Schritte hierfür sind grundlegend wie folgt:
- Vorhandenes oder neues Zertifikat bereitstellen (es darf auch ein selbstsigniertes Zertifikat verwendet werden!)
- Falls das Skript über eine geplante Aufgabe und ein Dienstkonto ausgeführt wird, dem Dienstkonto Leseberechtigungen auf den privaten Schlüssel des Zertifikats gewähren
- App-Registrierung in Entra ID erstellen und mit den notwendigen Berechtigungen ausstatten (üblicherweise Office 365 Exchange Online > Exchange.ManageAsApp)
- Funktionalität testen
OPTIONAL: Einrichtung der Entra-Cloudsynchronisierung
Es muss ermittelt werden, ob die Exchange-Attribute weiterhin im lokalen Active Directory benötigt werden. Es kann beispielsweise Applikationen geben, die diese für irgendwelche internen Funktionen verwenden (z.B. für einen E-Mail-Versand).
Wenn dies der Fall ist, muss die Entra-Cloudsynchronisierung implementiert werden. Nur hierüber ist ein Rückschreiben von Exchange-Attributen cloudverwalteter Objekte unterstützt. Für die Entra-Cloudsynchronisierung muss ein Dienst auf einem beliebigen System mit Zugriff auf das Active Directory installiert werden. Das Installationspaket ist kostenlos im Entra Admin Center verfügbar.
Wichtig hierbei: Entra Connect Sync und die Entra-Cloudsynchronisierung können grundsätzlich nebeneinander betrieben werden, dürfen jedoch nicht die gleichen Objekte beschreiben! Dementsprechend sind Organisationseinheiten nach und nach zur Cloud-Synchronisierung zu transferieren.
Konvertierung von Objekten
Nachdem alle Voraussetzungen erfüllt sind, können nun die Objekte nacheinander konvertiert werden.
Postfächer
Für Postfächer ist die Umstellung am einfachsten, da einfach nur ein Attribut am Postfach selbst umgestellt werden muss. Dies kann direkt über das Exchange Online PowerShell-Modul erfolgen:
# Exchange Online PowerShell-Modul installieren, falls noch nicht vorhanden
if (!(Get-InstalledModule 'ExchangeOnlineManagement'))
{
Write-Host 'Notwendiges Modul nicht installiert, Installation wird durchgeführt...' -ForegroundColor Yellow
Install-Module -Name 'ExchangeOnlineManagement' -Scope CurrentUser -Confirm:$False
}
# Verbindung zu Exchange Online aufbauen
Connect-ExchangeOnline -ShowBanner:$False
# Einzelnes Postfach umstellen
Get-Mailbox <BenutzerprinzipalName> | Set-Mailbox -IsExchangeCloudManaged $true
# Alle Postfächer umstellen
Get-User -Filter 'IsDirSynced -eq $true' | Set-Mailbox -IsExchangeCloudManaged $true
# Verbindung zu Exchange Online trennen
Write-Host 'Trenne Verbindung zu Exchange Online...' -ForegroundColor Yellow
Disconnect-ExchangeOnline -Confirm:$False
Sollten sich im Nachhinein Probleme ergeben, lässt sich das Attribut genauso auch wieder umstellen. Anschließend werden die Exchange-Attribute wieder mittels Entra Connect Sync von lokal synchronisiert.
E-Mail-aktivierte Sicherheits- und Verteilergruppen
Für E-Mail-aktivierte Sicherheits- und Verteilergruppen ist das Vorgehen etwas anders. Diese werden nicht direkt in Exchange Online, sondern in Entra ID umgestellt. Hierfür gibt es aktuell kein direkt modifizierbares Attribut.
Stattdessen muss eine Abfrage zusammengebaut und über den Graph Explorer auf die Gruppe(n) angewendet werden. Dementsprechend wird das PowerShell-Modul für Microsoft Graph für Gruppen benötigt. Das folgende Skript stellt alle notwendigen Schritte zusammen:
- Prüfen, ob das notwendige Modul installiert ist und Installation, falls nicht
- Aufbau einer Verbindung zu Microsoft Graph – für die Einrichtung der notwendigen Berechtigungen wird mindestens die Rolle Anwendungsadministrator benötigt
- Abfrage eines eindeutigen Bezeichners für die zu konvertierende(n) Gruppe(n)
- Abfrage, ob eine oder mehrere Gruppen konvertiert werden sollen
- Konvertierung der Gruppe(n)
- Abbau der Verbindung zu Microsoft Graph
if (!(Get-InstalledModule 'Microsoft.Graph.Groups')
{
Write-Host 'Notwendiges PowerShell-Modul nicht installiert, installiere...' -ForeGroundColor Yellow
Install-Module Microsoft.Graph.Groups -Scope CurrentUser
}
# Verbindung zu Microsoft Graph herstellen
Write-Host 'Verbindung zu Microsoft Graph aufbauen...' -ForeGroundColor Yellow
Connect-MgGraph -Scopes 'Group.ReadWrite.All', 'Group-OnPremisesSyncBehavior.ReadWrite.All'
# Abfragen, ob eine oder mehrere Gruppen konvertiert werden sollen
$Choice = Read-Host 'Eine oder mehrere Gruppen konvertieren? (1:Einzeln 2:Mehrere)'
# Nach Gruppennamen fragen
$Identifier = Read-Host 'Bitte gib den Anfang des Gruppennamens ein'
if ($Choice -eq 1)
{
# Gruppen-ID ermitteln und Filter konfigurieren
$Id = (Get-MgGroup -Filter "startswith(Displayname,'$Identifier') and OnPremisesSyncEnabled eq true" |`
Out-GridView -Title 'Please select group' -OutputMode:Single).Id
$GraphUrl = "https://graph.microsoft.com/beta/groups/$Id/onPremisesSyncBehavior"
# Ausgabe auf Bildschirm
Write-Host ''
Write-Host 'Konvertiere Gruppe...' -ForeGroundColor Yellow
Start-Sleep 2
# JSON-Payload für die PATCH-Anforderung konfigurieren
$jsonPayload = @{isCloudManaged = "true"} | ConvertTo-Json
# PATCH-Anforderung ausführen, um den JSON-Payload zu aktualisieren
Invoke-MgGraphRequest -Uri $GraphUrl -Method Patch -ContentType "application/json" -Body $jsonPayload
}
if ($Choice -eq 2)
{
# Alle Gruppen mit dem angegebenen Bezeichner ermitteln
$Ids = (Get-MgGroup -Filter "startswith(Displayname,'$Identifier') and OnPremisesSyncEnabled eq true"`
| Out-GridView -Title 'Please select groups' -OutputMode:Multiple).Id
# Ausgabe auf Bildschirm
Write-Host ''
Write-Host 'Konvertiere Gruppen...' -ForeGroundColor Yellow
Start-Sleep 2
# Konvertierung Gruppe für Gruppe durchführen
ForEach ($Id in $Ids)
{
# Graph-URL konfigurieren
$GraphUrl = "https://graph.microsoft.com/beta/groups/$Id/onPremisesSyncBehavior"
# JSON-Payload für die PATCH-Anforderung konfigurieren
$jsonPayload = @{isCloudManaged = "true"} | ConvertTo-Json
# PATCH-Anforderung ausführen, um den JSON-Payload zu aktualisieren
Invoke-MgGraphRequest -Uri $GraphUrl -Method Patch -ContentType "application/json" -Body $jsonPayload
}
}
# Verbindung zu Microsoft Graph trennen
Write-Host 'Trenne Verbindung zu Microsoft Graph...' -ForeGroundColor Yellow
Disconnect-MgGraph
E-Mail-Kontakte
Für E-Mail-Kontakte ist das gleiche Vorgehen wie für Gruppen erforderlich. Dies bedeutet, dass die Änderung über Entra ID und das Microsoft Graph-Modul erfolgt.
Das folgende Skript stellt alle notwendigen Schritte zusammen:
- Prüfen, ob das notwendige Modul installiert ist und Installation, falls nicht
- Aufbau einer Verbindung zu Microsoft Graph – für die Einrichtung der notwendigen Berechtigungen wird mindestens die Rolle Anwendungsadministrator benötigt
- Abfrage, ob ein oder alle Kontakte konvertiert werden sollen
- Falls ein Kontakt: Abfrage eines eindeutigen Bezeichners für den zu konvertierenden Kontakt
- Falls alle Kontakte: Ermittlung und Konvertierung aller Kontakte
- Abbau der Verbindung zu Microsoft Graph
if (!(Get-InstalledModule 'Microsoft.Graph.Groups')
{
Write-Host 'Notwendiges PowerShell-Modul nicht installiert, installiere...' -ForeGroundColor Yellow
Install-Module Microsoft.Graph.Groups -Scope CurrentUser
}
# Verbindung zu Microsoft Graph herstellen
Write-Host 'Verbindung zu Microsoft Graph aufbauen...' -ForeGroundColor Yellow
Connect-MgGraph -Scopes 'Contacts-OnPremisesSyncBehavior.ReadWrite.All'
# Abfragen, ob eine oder mehrere Kontakte konvertiert werden sollen
$Choice = Read-Host 'Eine oder alle Kontakte konvertieren? (1:Einzeln 2:Alle)'
if ($Choice -eq 1)
{
# Nach Kontaktnamen fragen
$Identifier = Read-Host 'Bitte gib den Anfang des Kontaktnamens ein'
# Kontakt-ID ermitteln und Filter konfigurieren
$Id = (Get-MgContact -Filter "startswith(Displayname,'$Identifier') and OnPremisesSyncEnabled eq true" | *
Out-GridView -Title 'Bitte Kontakt auswählen' -OutputMode:Single).Id
$GraphUrl = "https://graph.microsoft.com/beta/contacts/$Id/onPremisesSyncBehavior"
# Ausgabe auf Bildschirm
Write-Host ''
Write-Host 'Konvertiere Kontakt...' -ForeGroundColor Yellow
Start-Sleep 2
# JSON-Payload für die PATCH-Anforderung konfigurieren
$jsonPayload = @{isCloudManaged = "true"} | ConvertTo-Json
# PATCH-Anforderung ausführen, um den JSON-Payload zu aktualisieren
Invoke-MgGraphRequest -Uri $GraphUrl -Method Patch -ContentType "application/json" -Body $jsonPayload
}
if ($Choice -eq 2)
{
# Alle Kontakte ermitteln
$Ids = (Get-MgContact -Filter OnPremisesSyncEnabled eq true"`).Id
# Ausgabe auf Bildschirm
Write-Host ''
Write-Host 'Konvertiere Gruppen...' -ForeGroundColor Yellow
Start-Sleep 2
# Konvertierung Gruppe für Gruppe durchführen
ForEach ($Id in $Ids)
{
# Graph-URL konfigurieren
$GraphUrl = "https://graph.microsoft.com/beta/contacts/$Id/onPremisesSyncBehavior"
# JSON-Payload für die PATCH-Anforderung konfigurieren
$jsonPayload = @{isCloudManaged = "true"} | ConvertTo-Json
# PATCH-Anforderung ausführen, um den JSON-Payload zu aktualisieren
Invoke-MgGraphRequest -Uri $GraphUrl -Method Patch -ContentType "application/json" -Body $jsonPayload
}
}
# Verbindung zu Microsoft Graph trennen
Write-Host 'Trenne Verbindung zu Microsoft Graph...' -ForeGroundColor Yellow
Disconnect-MgGraph
Anpassung der globalen Standardeinstellung
Damit die zuvor beschriebenen Schritte nicht für jedes Objekt erneut ausgeführt werden müssen, kann eine globale Einstellung in Exchange Online gesetzt werden. Diese bewirkt, dass alle neuen Objekte automatisch für die Cloud-Verwaltung konfiguriert werden. Auch dies muss mittels PowerShell konfiguriert werden:
# Exchange Online PowerShell-Modul installieren, falls noch nicht vorhanden
if (!(Get-InstalledModule 'ExchangeOnlineManagement'))
{
Write-Host 'Notwendiges Modul nicht installiert, Installation wird durchgeführt...' -ForegroundColor Yellow
Install-Module -Name 'ExchangeOnlineManagement' -Scope CurrentUser -Confirm:$False
}
# Verbindung zu Exchange Online aufbauen
Connect-ExchangeOnline -ShowBanner:$False
# Globale Einstellung setzen
Write-Host 'Konfiguriere Cloud-Verwaltung für alle neuen Objekte...' -ForegroundColor Yellow
Set-OrganizationConfig -ExchangeAttributesCloudManagedByDefault
# BEI BEDARF: Globale Einstellung zurücksetzen
# Set-OrganizationConfig -ExchangeAttributesServerManagedByDefault
# Verbindung zu Exchange Online trennen
Write-Host 'Trenne Verbindung zu Exchange Online...' -ForegroundColor Yellow
Disconnect-ExchangeOnline -Confirm:$False
Das oben gezeigte Skript enthält auch den Befehl, mit dem die Standardeinstellung wieder auf einen lokalen Exchange Server gesetzt werden kann, falls erforderlich.
Abbau der Hybridkonfiguration und von Exchange
Sobald alle Objekte konvertiert sind und alles wie gewünscht funktioniert, kann zunächst die Hybridkonfiguration und anschließend die Exchange-Organisation abgebaut werden.
Das ist auf zwei Arten möglich:
- Saubere Entfernung
- Radikalmethode
Beide Varianten habe ich schon in der Praxis genutzt. In der Regel starte ich mit der sauberen Entfernung und wenn diese fehlschlägt, wechsle ich dann zur Radikalmethode. 😉 Siehe hierzu das entsprechende Kapitel weiter unten.
Das sollte aber nur das allerletzte Mittel sein, falls die Deinstallation von Exchange Server irreparabel fehlschlägt.
Entfernung der Hybridkonfiguration
Zunächst ist die Hybridkonfiguration zu entfernen. Hierfür sollte ausschließlich PowerShell genutzt werden, da viele Schritte nur über PowerShell ausgeführt werden können.
Die folgenden Befehle sind über die Exchange Management Shell auszuführen:
# Dienstverbindungspunkt für Autodiscover zurücksetzen
Get-ClientAccessService | Set-ClientAccessService -AutoDiscoverServiceInternalUri $null
# Hybridkonfiguration entfernen
Remove-HybridConfiguration -Confirm:$false
# Verbindung zwischen Exchange Server und Exchange Online deaktivieren
Get-IntraOrganizationConnector | Set-IntraOrganizationConnector -Enabled $false
Die folgenden Befehle beziehen sich auf die Konfiguration in Exchange Online. Diese können ebenfalls über die Exchange Management Shell ausgeführt werden. Über die Angabe eines Präfixes für die Befehle wird sichergestellt, dass Exchange Server und Exchange Online parallel angesprochen werden können.
Die Befehle führen die folgenden Schritte durch:
- Prüfen, ob das Exchange Online-PowerShell-Modul installiert ist und installieren, falls nicht
- Verbindung zu Exchange Online aufbauen
- Alle Eingangsconnectors ermitteln und Auswahl für Entfernung des hybriden Connectors anzeigen
- Alle Sendeconnectors ermitteln und Auswahl für Entfernung des hybriden Connectors anzeigen
- Entfernung der hybriden Connectors
- Entfernung der Frei-/Gebucht-Konfiguration für die lokale Exchange-Organisation
- Trennen der Verbindung zu Exchange Online
# Exchange Online-PowerShell installieren, falls noch nicht vorhanden
if (!(Get-Installed-Module ExchangeOnlineManagement))`
{Install-Module ExchangeOnlineManagement -Confirm:$False}
# Zu Exchange Online verbinden - mit dem Präfix wird sichergestellt, dass die Befehle für die lokale
# Exchange-Organisation nicht überschrieben werden
Connect-ExchangeOnline -Prefix EOL -ShowBanner:$False
# Eingehende Connectors anzeigen und zu löschenden Connector auswählen
$InboundConnector = (Get-InboundConnector | Where-Object {$_.Name -like 'Inbound from*'} |`
Out-GridView -Title 'Bitte zu löschenden Eingangsconnector auswählen' -OutputMode:Single).Name
# Ausgehende Connectors anzeigen und zu löschenden Connector auswählen
$OutboundConnector = (Get-OutboundConnector | Where-Object {$_.Name -like 'Outbound to*'} |`
Out-GridView -Title 'Bitte zu löschenden Ausgangsconnector auswählen' -OutputMode:Single).Name
# Connectors entfernen
Remove-InboundConnector -Identity $InboundConnector -Confirm:$False
Remove-OutboundConnector -Identity $OutboundConnector -Confirm:$False
# Frei-/Gebucht-Konfiguration entfernen
Write-Host 'Entferne Frei-/Gebucht-Konfiguration...' -ForegroundColor Yellow
Get-OrganizationRelationship | Where-Object {$_.Name -like 'O365 to On-premises*'} | Remove-OrganizationRelationShip -Confirm:$False
# Verbindung zu Exchange Online trennen
Write-Host 'Trenne Verbindung zu Exchange Online...' -ForegroundColor Yellow
Disconnect-ExchangeOnline -Confirm:$False
Als letztes muss die Exchange-Hybrid-App entfernt werden, die für die Kommunikation von Exchange Server zu Exchange Online verwendet wird. Hinweis: hierfür wird die Entra-Rolle Anwendungsadministrator (oder höher) benötigt.
Die folgenden Befehle laden das für die Entfernung verwendete PowerShell-Skript herunter und führen dieses mit dem entsprechenden Parameter aus:
# Skript für Entfernung der App herunterladen
$Uri = 'https://github.com/microsoft/CSS-Exchange/releases/latest/download/ConfigureExchangeHybridApplication.ps1'
Invoke-WebRequest -Uri $Uri -OutFile .\ConfigureExchangeHybridApplication.ps1
# Skript ausführen
Write-Host ''
Write-Host 'Exchange-Hybrid-App wird entfernt...' -ForegroundColor Yellow
.\ConfigureExchangeHybridApplication.ps1 -DeleteApplication
Deinstallation von Exchange Server
Sobald die Hybridkonfiguration zurückgebaut worden ist, kann Exchange Server deinstalliert werden. Hierfür müssen zunächst die üblichen Voraussetzungen erfüllt werden:
- Sendeconnectors löschen bzw. den zu deinstallierenden Server entfernen
- Datenbankverfügbarkeitsgruppe(n) löschen bzw. Server aus Gruppe entfernen
- Datenbank(en) bereinigen und löschen
Anschließend sollte die Deinstallation gestartet werden können. Ich habe es in der Praxis schon des Öfteren erlebt, dass die Deinstallation aufgrund irgendeines Fehlers fehlschlägt und der Server anschließend nicht mehr repariert werden kann. Hier hilft dann die Radikalmethode (siehe unten).
Ansonsten entfernt die Deinstallation des letzten Exchange Servers auch die Konfiguration aus dem ADSI.
Einzig die in Active Directory-Benutzer und -Computer angelegten Ressourcen müssen noch manuell entfernt werden:
- Systempostfächer (typischerweise im Container „Users“)
- Organisationseinheit „Microsoft Exchange Security Groups“
- Systemordner „Microsoft Exchange System Objects“
- Ggf. zusätzlich angelegte Rollengruppen und Dienstkonten
Die Radikalmethode (Vorsicht: nur im Notfall!)
Die Radikalmethode ist nur dann anzuwenden, wenn Du Dir sicher bist, was Du tust oder wenn die saubere Deinstallation von Exchange irreparabel fehlgeschlagen ist. Sie funktioniert jedoch deutlich schneller! 😉
Die Radikalmethode sieht grob zusammengefasst wie folgt aus:
- Virtuelle Maschine des Exchange Servers löschen bzw. physischen Server mit Windows neu installieren
- Exchange-Konfiguration mittels ADSI-Editor entfernen
- Objekte und Organisationseinheiten aus Active Directory-Benutzer und -Computer entfernen
Die ADSI-Konfiguration kann wie folgt entfernt werden:
- ADSI-Editor auf einem System mit Zugriff zu Active Directory starten
- Kontext Konfiguration auswählen
- CN=Services erweitern
- CN=Microsoft Exchange mit Rechtsklick löschen und Warnung bestätigen
Und wie funktioniert das nun in der Praxis?
Ja, in der Theorie liest sich das alles gut. Vielleicht sagst Du:
„Supertoll – klappt aber bei uns nicht.“
Dafür kann es viele Gründe geben, beispielsweise:
- Ihr könnt aufgrund rechtlicher/regulatorischer Vorgaben nicht alle Postfächer in die Cloud verschieben
- Ihr könnt aufgrund technischer Einschränkungen in Exchange Online (noch) nicht alle Postfächer in die Cloud schieben (Stichworte: Basisauthentifizierung, EWS-Zugriff)
- Ihr verwendet Exchange Server als internen MTA und habt ggf. keine vollständige Übersicht, wer diesen MTA nutzt
Selbstverständlich ist es kein Muss, den/die letzten Exchange Server zu deinstallieren. Wenn Ihr Euch mit der Hybridkonfiguration auskennt, spricht nichts dagegen, diese weiter einzusetzen.
Wenn Euer Hinderungsgrund jedoch beispielsweise einer der folgenden ist:
- „Ich traue mich nicht, Exchange zu deinstallieren, weil ich befürchte, etwas kaputt zu machen.“
- „Mir sind die Schritte für die Umstellung zu komplex/nicht nachvollziehbar.“
- „Ich kenne mich mit der Cloud nicht so gut aus.“
dann möchte ich Euch ein paar meiner Erfahrungen aus der praktischen Umsetzung mitgeben. Vielleicht können Euch diese ermutigen, Euch damit zu beschäftigen. Und dann gibt es ja immer noch die Möglichkeit, sich Unterstützung heranzuholen. 🤜🤛
Bereitstellung eines anderen E-Mail-Relays
Exchange Server wird ganz gern auch als E-Mail-Relay für Applikationen und Systeme eingesetzt – besonders für solche, die keine oder nur Basisauthentifizierung unterstützen.
Zugegebenermaßen sind die Möglichkeiten mit Exchange Online hier eingeschränkt. Allerdings heißt dies nicht, dass es keine Lösung gibt.
Einzig Anwendungen, die E-Mails mittels IMAP abholen, sind meiner Erfahrung nach problematisch. Diese müssen in Verbindung mit Exchange Online zwingend OAuth unterstützen, eine Alternative gibt es hier tatsächlich nicht.
Für den Versand einzelner E-Mails ohne Authentifizierung oder mit Basisauthentifizierung gibt es mehrere Varianten, je nachdem, ob sich der/die Empfänger intern oder extern befindet/n:
- Intern: Direktes Senden, SMTP-Relay über Connector
- Extern: SMTP-Relay über Connector
Für Massenmails sieht es etwas anders aus, da Exchange Online grundsätzlich nicht für Massenmails ausgelegt ist.
- Intern: HVE (E-Mails mit hohem Volumen)
- Extern: Azure Communication Services als Alternative
Zum Thema Massenmails habe ich einen eigenen Artikel in meinem Blog erstellt: Die Microsoft Cloud kann keine Massenmails! …Oder etwa doch…? – Crow In The Cloud
Einrichtung der Entra-Cloudsynchronisierung
Bislang hatte keiner meiner Kunden die Anforderung, dass Exchange-Attribute weiterhin im Active Directory aktuell gehalten werden müssen, weil irgendeine Applikation oder ein System diese verwendet. Es kann aber natürlich auch Organisationen geben, in denen dies erforderlich ist.
Für solche Fälle kann die Entra-Cloudsynchronisierung genutzt werden. Aus meiner Sicht ist diese mittlerweile eine schöne Alternative zu Entra Connect Sync, wenngleich sie noch nicht den gleichen Funktionsumfang hat (und wahrscheinlich auch nie bekommen wird, Microsoft hat hier andere Pläne).
Für den Fall, dass Ihr auf OU-Basis synchronisiert und keine speziellen Synchronisationsregeln verwendet, solltet Ihr Euch damit auseinandersetzen. In dem Fall hat die Cloudsynchronisierung für Euch sogar einige Vorteile:
- Es wird lediglich ein Agent im lokalen Netzwerk installiert, welcher sich selbstständig aktualisiert. Regelmäßige Wartungsfenster können entfallen.
- Es können mehrere Agents parallel installiert werden und aktiv sein (bei Entra Connect Sync darf immer nur eine Instanz aktiv sein).
Die Migration von Entra Connect Sync zur Cloudsynchronisierung ist recht einfach:
- Entra Connect Sync in den Staging-Modus versetzen
- Agent lokal installieren (kann auch auf dem Entra Connect Sync-Server erfolgen)
- Synchronisationsaufträge im Entra Admin Center konfigurieren
- Funktionalität mittels „Bereitstellen bei Bedarf“ testen
- Entra Connect Sync deinstallieren
Ich persönlich finde jedoch zwei Dinge an der Cloudsynchronisierung nicht so gut:
- Das Dienstkonto für den Zugriff auf Active Directory muss Mitglied der Gruppe Domänen-Admins oder Organisations-Admins sein. Das ist bei Entra Connect Sync nicht so.
- Die Konfiguration der Synchronisationsaufträge ist ein wenig fummelig, da man sich hierzu den eindeutigen Pfad der OU benötigt (OU=…,DC=…).
Hoffentlich wird das mit künftigen Versionen noch verbessert.
Konvertierung der Objekte
Die Konvertierung der Objekte ist das eigentliche Kernstück. Für Postfächer ist das recht einfach gelöst – Attribut anpassen, fertig. Für Gruppen und Kontakte ist es mE leider noch unnötig kompliziert, aber wahrscheinlich technisch nicht anders möglich.
Allerdings kann man sich hier gut mit den Skripten behelfen, die ich oben eingefügt habe. Damit muss man sich nicht die komplexen Befehle einprägen oder gar mit dem Graph Explorer arbeiten – Objekt auswählen, konvertieren, fertig.
Und wirklich schön ist, dass man alles auch wieder rückgängig machen kann. Es ist also keine Umstellung für immer, sondern ich kann im Problemfall immer wieder zurück zum Ausgangsszenario.
In der Praxis muss man ein wenig aufpassen, wenn man viel mit verschachtelten Gruppen arbeitet. Dies möchte ich an dem folgenden Beispiel anschaulich zeigen.
Ausgangssituation:
Ein Kunde verwendet verschachtelte Gruppen, um darüber sowohl den Zugriff auf Exchange-Postfächer als auch Dateifreigaben auf dem lokalen Dateiserver zu steuern. Dementsprechend ist die Gruppe E-Mail-aktiviert und wird nach Entra ID/Exchange Online synchronisiert.
Ziel:
Die E-Mail-aktivierte Sicherheitsgruppe soll über Exchange Online verwaltet werden. Alle darüber eingerichteten Zugriffe sollen erhalten bleiben.
Bewertung
Dies ist nur zum Teil möglich. Die Konvertierung kann durchgeführt werden und auch die zum Zeitpunkt der Konvertierung vorhandenen Berechtigungen bleiben erhalten.
Allerdings werden ab diesem Zeitpunkt lokal durchgeführte Änderungen nicht mehr auf die Gruppe in Entra ID/Exchange Online übertragen, da die Synchronisation gesperrt wird. Folglich müssen Berechtigungen ab diesem Zeitpunkt zweimal (lokal und in der Cloud) gepflegt werden.
Lösungsansätze
Variante 1 (empfohlen): Entkopplung der Berechtigungen, um Abhängigkeiten abzubauen.
- Erstellung/Verwendung eigener Berechtigungsgruppen pro Dienst (Dateiserver, Exchange-Ressource, usw.).
- Verwendung von nativen Cloud-Gruppen für Cloud-Dienste anstelle von synchronisierten Gruppen.
- Verschachtelung einer „Benutzer“gruppe in die neue lokale und Cloud-Gruppe
Variante 2: Beibehaltung der existierenden Gruppen
- Erstellung einer neuen „Benutzer“gruppe und Synchronisation
- Verschachtelung der Benutzergruppe in die lokale und Cloud-Gruppe, um das gleiche Berechtigungsprinzip weiterzuverwenden
Deinstallation von Exchange Server
An sich ist die Deinstallation eines Exchange Servers nichts besonderes. Bei einigen könnte es aber schon länger her sein, da Exchange Server SE eine direkte Aktualisierung von 2019 unterstützt. Dementsprechend war die typische Side-by-Side-Migration nicht erforderlich.
Ich habe in den letzten Jahren so einige Exchange Server deinstalliert und bin dabei immer wieder auf unterschiedliche Fehler gestoßen. In einigen Fällen lief die Deinstallation nicht vollständig durch, sondern blieb bei einem Schritt hängen.
Der Server landet so in einem undefinierten Zustand – er ist zwar noch da, aber nicht mehr funktionsfähig. Hier habe ich dann die folgenden Szenarien erlebt:
Szenario 1: Die Deinstallation kann einfach nochmal gestartet werden. Der Assistent erkennt die unvollständige Deinstallation und macht dort weiter, wo er zuvor fehlgeschlagen ist.
Szenario 2: Der Assistent erkennt die unvollständige Deinstallation, kann diese allerdings nicht fortsetzen. Es muss eine Reparatur über die Kommandozeile gestartet werden. Diese verläuft erfolgreich und die Deinstallation läuft anschließend durch:
<Laufwerksbuchstabe:>\setup.exe /m:RecoverServer /IAcceptExchangeServerLicenseTerms_DiagnosticDataOff
Szenario 3: Der Assistent erkennt die unvollständige Deinstallation, kann diese allerdings nicht fortsetzen. Es muss eine Reparatur über die Kommandozeile gestartet werden. Diese verläuft ebenfalls nicht erfolgreich (oder kann gar nicht erst gestartet werden). Der Server ist somit irreparabel funktionsunfähig.
Szenario 3 hatte ich kürzlich bei einem Kunden, bei dem ich die Exchange Server selbst aufgebaut habe. Ich war mir also ziemlich sicher, dass beim Aufbau alles ordentlich eingestellt wurde. 😉
Diese Server wurden bis zu diesem Zeitpunkt als Lösung für die Signaturenverwaltung betrieben (der Kunde durfte aufgrund regulatorischer Vorgaben keine Cloudlösung hierfür einsetzen). Der Kunde stellte dann auf eine andere Lösung um, die nicht auf Exchange Server aufsetzt.
Da der Kunde nicht beabsichtigte, Exchange Server weiter für andere Zwecke einzusetzen (alle Postfächer waren bereits in der Cloud, EWS-Zugriffe waren im Rahmen der Migration umprogrammiert worden), haben wir hier die Radikalmethode gewählt (siehe oben). Damit lässt sich eine Exchange-Organisation zur Not ebenfalls sauber aus einem Active Directory entfernen. Im Bedarfsfall könnte auch wieder eine Exchange-Organisation installiert werden.
Teilen mit:
- Auf Bluesky teilen (Wird in neuem Fenster geöffnet) Bluesky
- Auf LinkedIn teilen (Wird in neuem Fenster geöffnet) LinkedIn
- Auf Pinterest teilen (Wird in neuem Fenster geöffnet) Pinterest
- Auf Telegram teilen (Wird in neuem Fenster geöffnet) Telegram
- Drucken (Wird in neuem Fenster geöffnet) Drucken
- Einen Link per E-Mail an einen Freund senden (Wird in neuem Fenster geöffnet) E-Mail
- Auf Mastodon teilen (Wird in neuem Fenster geöffnet) Mastodon
- Auf Nextdoor teilen (Wird in neuem Fenster geöffnet) Nextdoor