Exchange loswerden (Teil 3): Die Verwaltung zieht in die Cloud - Alexander Zarenko

Dies ist Teil 3 der Serie „Exchange loswerden“. In Teil 1 ging es um den Mailflow, in Teil 2 um Postfächer und Public Folders. Beides sollte erledigt sein, bevor du die Verwaltung in die Cloud verlagerst.

Die Postfächer liegen in Exchange Online, der lokale Exchange-Server steht trotzdem noch da. Der Grund ist fast immer derselbe: Solange Benutzer aus dem AD synchronisiert werden, sind ihre Exchange-Attribute im AD zu Hause. Neue Adresse, CustomAttribute, aus der GAL ausblenden – das ging bisher nur über die Exchange-Verwaltung on-prem.

Seit Microsoft die Verwaltung der Exchange-Attribute in die Cloud verlagern lässt, ist dieser Grund weg. In diesem Teil geht es darum, wie das geht, was danach fehlt, und was bei mir im ersten echten Einsatz schiefging.

Was sich ändert und was bleibt

Die Identität bleibt im AD: Name, Abteilung, UPN, Kennwort und Konto-Status werden weiter von Entra Connect synchronisiert. Nur die Exchange-Attribute wechseln die Seite. Microsoft nennt das „Source of Authority“ (SOA). Danach pflegst du Adressen, CustomAttributes, Weiterleitungen und das Ausblenden aus der GAL in Exchange Online. Vor- und Nachname änderst du weiterhin im AD.

Das gilt nur für Benutzer mit Postfach in Exchange Online. Verteiler und Kontakte haben einen eigenen Weg, dazu weiter unten.

Voraussetzungen

Entra Connect Sync ab 2.5.190.0. Ältere Versionen versuchen, die Attribute bereits umgestellter Postfächer weiter nach Entra zu schieben, und scheitern dabei.
Rolle: Exchange Administrator (empfohlen), Hybrid Identity Administrator oder Global Administrator.
Interaktive Anmeldung. Zertifikatsbasierte App-Anmeldung funktioniert für die Umstellung nicht, Skripte im Taskplaner fallen also aus.
Geduld nach dem Umzug. Nach einem Mailbox-Move oder einem Set-RemoteMailbox erst einen Sync-Zyklus abwarten und dann noch einmal 24 Stunden. Microsoft begründet das ausdrücklich: Stellst du zu früh um, riskierst du, dass veraltete Empfängertyp-Werte aus der Cloud die richtigen Remote-Mailbox-Werte im AD überschreiben, sobald der Writeback läuft.

Postfächer umstellen

Der Schalter heißt IsExchangeCloudManaged und wird immer allein gesetzt, nie zusammen mit anderen Parametern:

Set-Mailbox -Identity <User> -IsExchangeCloudManaged $true
Get-Mailbox -Identity <User> | Format-List Identity, IsExchangeCloudManaged

Erst ein Testbenutzer, dann der Rest:

$mbx = Get-Mailbox -ResultSize Unlimited | Where-Object { $_.IsDirSynced -eq $true -and $_.IsExchangeCloudManaged -eq $false }

$i = 0
$mbx | ForEach-Object {
    $i++
    Write-Progress -Activity "Exchange Cloud Management aktivieren" -Status "$i / $($mbx.Count)" -PercentComplete ($i / $mbx.Count * 100)
    Set-Mailbox -Identity $_.Alias -IsExchangeCloudManaged $true -WhatIf
}

Wenn du lieber klickst: Das Exchange SOA Conversion Tool von Hans Christian Andersen zeigt alle synchronisierten Postfächer, stellt per Mehrfachauswahl in beide Richtungen um und protokolliert mit. Mit ExchangeOnlineManagement 3.6.0 friert die Oberfläche allerdings ein. Mein Fix ist als PR #1 eingereicht, bis zum Merge funktioniert mein Fork. Warum ist das relevant? Ich benutze ehrlich gesagt oft immer noch 3.6.0, weil es das letzte ist, das in der Powershell_ISE funktioniert (Install-Module ExchangeOnlineManagement -MaximumVersion 3.6.0). Zeilenweise Code Schnipsel ausführen können, ohne etwas installieren zu müssen, finde ich nach wie vor genial und bleibe der ISE treu, solange sie da ist (leider abgekündigt).

Stand November 2026: Bei meinen letzten beiden Kundeneinsätzen kam weder das Original noch mein Fork mit einem neueren Modul (> 3.6.0) zu einer Verbindung mit Exchange Online. Ich bin dann auf die PowerShell-Befehle oben ausgewichen. Wenn das Werkzeug bei dir hakt: Die paar Zeilen oben tun (fast) dasselbe.

Zurück geht es mit -IsExchangeCloudManaged $false. Dann überschreiben im nächsten Sync-Zyklus die AD-Werte die Cloud-Werte, was du in der Cloud geändert hast, vorher also sichern.

Neue Benutzer und das Ende der Address Policy

Ohne Exchange gibt es kein New-RemoteMailbox. Der Weg laut Microsoft: Benutzer im AD anlegen, Sync abwarten, Lizenz zuweisen (damit entsteht das Postfach), dann IsExchangeCloudManaged setzen. Den letzten Schritt sparst du dir mit dem Tenant-Standard:

Set-OrganizationConfig -ExchangeAttributesCloudManagedByDefault
Get-OrganizationConfig | Format-List BlockExchangeProvisioningFromOnPremEnabled   # True

Aber erst, wenn alle Postfächer migriert sind und on-prem niemand mehr Empfänger anlegt. Sonst kommen neue on-prem-Empfänger als normale Entra-Benutzer ohne MailUser an, und ihr Onboarding nach Exchange Online scheitert.

Warum die Option „-ExchangeUndSoWeiter“ heißt und das Property „BlockExchangeIrgendwasAnderes“, wird wohl auf ewig Microsofts Geheimnis bleiben 😉

Was beim Anlegen fehlt, ist die Email Address Policy. In Exchange Online gelten Address Policies nur für Microsoft 365 Groups. Neue Benutzer bekommen ihren UPN und die onmicrosoft.com-Adresse, mehr nicht. Das Adressschema (vorname.nachname@, Zweitdomänen) gehört deshalb ins Anlege-Skript. Schreib dir die alten Policies auf, solange der Server noch läuft:

Get-EmailAddressPolicy | Format-List Name, Priority, RecipientFilter, EnabledEmailAddressTemplates

Löschen läuft übrigens weiterhin über das AD: Benutzer löschen, Sync, Postfach weg. Shared Mailboxes legst du direkt in Exchange Online an, ohne AD-Objekt.

Verteiler und Kontakte

IsExchangeCloudManaged gilt nur für Postfächer. Für synchronisierte Verteiler und mail-aktivierte Sicherheitsgruppen gibt es die Group-SOA, umgestellt per Graph:

Connect-MgGraph -Scopes 'Group.ReadWrite.All','Group-OnPremisesSyncBehavior.ReadWrite.All'
Invoke-MgGraphRequest -Method PATCH `
    -Uri "https://graph.microsoft.com/v1.0/groups/$groupId/onPremisesSyncBehavior" `
    -Body (@{ isCloudManaged = $true } | ConvertTo-Json) -ContentType 'application/json'

Verschachtelte Gruppen werden nicht mitgenommen, jede einzeln umstellen, von unten nach oben. extensionAttribute1–15 werden an umgestellten Gruppen nicht unterstützt. Mit Oberfläche geht das über das Group SOA Conversion Tool, ebenfalls von Hans Christian Andersen: Es listet die mail-aktivierten Sicherheitsgruppen und Verteiler, erkennt verschachtelte Gruppen und stellt bei Mehrfachauswahl von unten nach oben um. Bei einem Kunden habe ich rund 80 Gruppen umgestellt. Zwei davon meldeten „Internal server error“, waren aber trotzdem korrekt vom AD entkoppelt, in Exchange Online änderbar und hatten alle Mitglieder. Bei einem Fehler also erst den Zustand prüfen (das GET auf onPremisesSyncBehavior), bevor du es noch einmal versuchst.

Für Mail-Kontakte gibt es dasselbe Prinzip mit dem Endpunkt /contacts und der Berechtigung Contacts-OnPremisesSyncBehavior.ReadWrite.All. Microsoft dokumentiert dort allerdings nur das Lesen ausdrücklich. Das Umstellen funktioniert trotzdem: Ich habe bei Kunden mehrfach Kontakte mit dem Exchange Contacts SOA Conversion Tool umgestellt. Es zeigt je Kontakt, ob er cloud-verwaltet ist, und stellt in beide Richtungen um. Gepflegt werden die Kontakte danach zum Beispiel mit meinem MailContactEditor.

Writeback: Wenn das AD die Adressen trotzdem kennen muss

Nach der Umstellung änderst du Adressen nur noch in Exchange Online. Das AD bekommt davon zunächst nichts mit. Meistens ist das egal. Es gibt aber Anwendungen, die proxyAddresses, mail oder extensionAttribute* aus dem AD lesen: Telefonanlagen, Fax-Server, Archivlösungen, HR-Schnittstellen, Skripte. Für die gibt es den Writeback.

Warum Cloud Sync und nicht Entra Connect

Der Writeback läuft über Entra Cloud Sync, zusätzlich zu Entra Connect Sync. Microsoft schreibt das ausdrücklich als Pflicht („mandatory“). Connect bleibt, wie er ist: Er synchronisiert weiter vom AD nach Entra und erledigt den klassischen Hybrid-Writeback für alle, die noch on-prem verwaltet werden. Cloud Sync übernimmt nur den neuen Job „EXO to AD attribute sync“.

Die naheliegende Frage, ob Connect das nicht schon kann: Der Haken „Exchange hybrid“ in Connect schreibt nur wenige Attribute zurück, und bei proxyAddresses laut Doku nur die X500-Adresse aus Exchange Online. Neue SMTP-Adressen, mail oder CustomAttributes kommen darüber nicht im AD an.

Was der neue Job zurückschreibt, steht in der Exchange-Doku: proxyAddresses, mail, extensionAttribute1–15, msExchExtensionCustomAttribute1–5 und die beiden RecipientType-Attribute. Ausblenden aus der GAL, Weiterleitungen und Berechtigungen bleiben in der Cloud. Vorsicht: Die Entra-Seite zu Cloud Sync zeigt unter derselben Überschrift („LES Writeback“) eine ganz andere Tabelle. Verlässlich ist am Ende nur der Tab Attribute Mapping in eurem eigenen Job.

Hast du den Writeback schon vor dem 3. August 2026 eingerichtet, fehlt dir die Zuordnung Mail → mail. Du kannst sie mit „Restore default mappings“ nachziehen, das setzt aber eigene Anpassungen an Zuordnungen und Filtern zurück.

Einrichtung

Provisioning Agent installieren, mindestens Version 1.1.1107.0. Der Server gehört laut Microsoft in Tier 0. Ich nehme normalerweise denselben Server wie für Entra Connect.
Im Entra Admin Center: Entra Connect → Cloud Sync → New configuration → EXO to AD attribute sync → Create.
Start provisioning.
Testen:

# Exchange Online
Set-Mailbox -Identity <User> -CustomAttribute1 "TestValue_$(Get-Date -Format 'yyyyMMdd_HHmmss')"

Dann im Job „Provision on demand“ für den Benutzer auslösen oder etwa 20 Minuten warten und on-prem nachsehen:

Get-ADUser <User> -Properties extensionAttribute1 | Select-Object extensionAttribute1

So viel zur Doku. Jetzt zur Praxis.

Was beim ersten echten Einsatz passiert ist

Die Umgebung: zwei Forests. Der Agent und sein Dienstkonto stehen in Forest A, die Benutzer, deren Attribute zurückgeschrieben werden sollen, in Forest B. B vertraut A. Entra Connect läuft bereits und soll unangetastet bleiben.

Stolperstein 1: Der Container für Managed Service Accounts fehlt

Der Agent läuft unter einem gMSA. Standardmäßig legt der Assistent provAgentgMSA$ selbst an. Bei uns scheiterte das: Der Standardcontainer CN=Managed Service Accounts war in Forest A irgendwann gelöscht worden.

Prüfen lässt sich das über den Well-Known-Eintrag an der Domain Root:

$domain = Get-ADDomain
(Get-ADObject $domain.DistinguishedName -Properties wellKnownObjects).wellKnownObjects |
    Where-Object { $_ -like '*1EB93889E40C45DF9F0C64D23BBB6237*' }
# Zeigt der DN ins Leere oder auf ein gelöschtes Objekt (\0ADEL), fehlt der Container.

Der schnelle Ausweg: „Use custom gMSA“. Das gMSA legst du selbst in einer eigenen OU an und gibst nur den Agent-Servern das Recht, das Kennwort abzurufen:

New-ADServiceAccount -Name gmsaCloudSync `
    -DNSHostName gmsaCloudSync.contoso.com `
    -Path 'OU=Service Accounts,OU=Tier0,DC=contoso,DC=com' `
    -PrincipalsAllowedToRetrieveManagedPassword 'SRV-CS01$', 'SRV-CS02$'

Den gelöschten Container sauber wiederherzustellen (aus dem AD-Papierkorb, sonst neu anlegen und wellKnownObjects anpassen) ist ein eigener Change. Für Cloud Sync brauchst du ihn nicht.

Stolperstein 2: Gibt es einen KDS Root Key?

Ohne KDS Root Key kein gMSA. Vorsicht beim Prüfen: Get-KdsRootKey kann ohne ausreichende Rechte einfach nichts liefern, ohne Fehlermeldung. Ein leeres Ergebnis heißt also nicht, dass es keinen Schlüssel gibt. Verlässlicher ist der Blick in den Container, in dem die Schlüssel liegen:

$config = (Get-ADRootDSE).configurationNamingContext
Get-ADObject -SearchBase "CN=Master Root Keys,CN=Group Key Distribution Service,CN=Services,$config" `
    -Filter * -Properties whenCreated, msKds-UseStartTime |
    Select-Object Name, whenCreated, @{ n = 'UseStartTime'; e = { [DateTime]::FromFileTimeUtc($_.'msKds-UseStartTime') } }

Bei uns war wirklich keiner da. Wenn du einen anlegst, solltest du wissen: Microsoft lässt die DCs bis zu 10 Stunden warten, bis alle den Schlüssel repliziert haben. Mit -EffectiveTime ((Get-Date).AddHours(-10)) lässt sich die Wartezeit umgehen, laut Microsoft aber nur für Testumgebungen mit einem DC gedacht. In Produktion entweder warten oder vorher sicherstellen, dass der Schlüssel auf allen DCs angekommen ist.

Stolperstein 3: Cross-Forest und das falsche Konto

Im Assistenten fügst du unter „Connect Active Directory“ die Domänen hinzu, in die der Agent schreiben soll. Microsoft verlangt dort ein Domänen-Admin-Konto, und das hat einen Grund, der in der Doku nur in einem Nebensatz steht: Mit genau diesem Konto setzt der Assistent die Berechtigungen für das gMSA in dieser Domäne.

Wir hatten Domäne B mit einem Konto aus Forest A hinzugefügt, das in B nur lesen durfte. Damit konnte der Assistent in B keine Rechte setzen, und er hat das auch nicht gemeldet. Aufgefallen ist es erst beim ersten Writeback:

HybridSynchronizationActiveDirectoryInsufficientAccessRights
00002098: SecErr: DSID-03151483, problem 4003 (INSUFF_ACCESS_RIGHTS)

Nachdem ein Domänen-Admin aus B die Rechte gesetzt hatte, lief der nächste Durchgang sauber. Das geht auch ohne erneuten Assistenten, mit dem PowerShell-Modul des Agents:

Import-Module 'C:\Program Files\Microsoft Azure AD Connect Provisioning Agent\Microsoft.CloudSync.Powershell.dll'
Set-AADCloudSyncPermissions -PermissionType HybridExchangePermissions `
    -TargetDomain 'fabrikam.com' -TargetDomainCredential (Get-Credential)

Die Domäne muss dafür vorher im Assistenten hinzugefügt worden sein.

Stolperstein 4: adminCount und abgeschaltete Vererbung

Später kam dasselbe InsufficientAccessRights noch einmal, diesmal nur bei einzelnen Benutzern. Ein Skript fand 147 von rund 1000 Benutzern mit adminCount = 1, etliche davon mit abgeschalteter Vererbung. Das bleibt zurück, wenn ein Konto irgendwann Mitglied einer geschützten Gruppe war: SDProp schaltet die Vererbung ab und setzt adminCount, nach dem Austritt nimmt niemand das zurück. Die Rechte, die der Assistent auf Domänenebene setzt, kommen am Objekt dann nicht an. Microsoft beschreibt genau diesen Fall und sucht mit Get-ADObject -Filter {AdminCount -gt 0}.

Bereinigen heißt: adminCount leeren und die Vererbung wieder einschalten, aber nur bei Konten, die wirklich in keiner geschützten Gruppe mehr sind. Sonst setzt SDProp beides innerhalb einer Stunde zurück. Bei 147 Konten ist das Arbeit, wenn du jedes vorher prüfst. Hattest du vorher schon den Exchange-Hybrid-Writeback von Entra Connect im Einsatz, ist das meist längst erledigt. Aber jedes AD hat seine eigene Geschichte, und der Writeback braucht ein halbwegs sauberes.

Was der Writeback im AD tatsächlich ändert

Beim Kunden haben wir vor dem Start des Writebacks nachgesehen, was er im AD ändern würde: Empfängertyp, mail und die primäre Adresse in proxyAddresses, je Postfach mit Exchange Online verglichen. Ergebnis: eine ganze Reihe von Abweichungen. Stichproben zeigten, dass sich das AD über Jahre auseinanderentwickelt hatte. In der Cloud zu Shared Mailboxes umgewandelte Postfächer standen im AD noch als normales Remote-Postfach, Adressen waren nur in Exchange Online gepflegt worden.

Aufgefallen war das niemandem, und es hatte offenbar auch keine Folgen. Das AD hinkte schlicht hinterher, weil alle Postfächer und Mail-Objekte längst in Exchange Online zu Hause waren und dort gepflegt wurden.

Daraus folgt eine beruhigende Einschätzung: Wenn alle Objekte ihre Heimat in Exchange Online haben, kann der Writeback die Daten im AD nicht schlechter machen, sondern nur besser. Er gleicht eine veraltete Kopie an die gepflegte Quelle an. Die Sorge, mit dem Writeback etwas kaputt zu machen, war in diesem Szenario unbegründet.

Zwei minimale Einschränkungen gibt es trotzdem:

Werte, die es nur im AD gibt: Der Writeback bringt proxyAddresses auf den Stand der Cloud. Eine Adresse, die nur im AD stand, ist danach auch dort weg. Meistens ist das Bereinigung. Wenn aber eine lokale Anwendung genau diese Adresse nutzt, ist es ein Verlust.
Frisch migrierte Postfächer: Das ist Microsofts Warnfall. Wird ein Postfach direkt nach dem Move umgestellt, bevor der Sync durch ist, kann ein veralteter Empfängertyp aus der Cloud ins AD geschrieben werden. In einem Bestand, der seit Jahren in der Cloud liegt, spielt das keine Rolle.

Wenn du vorher sehen willst, was sich ändert, nimm mein Prüfskript AttributeWritebackCheck. Es ändert nichts, vergleicht jedes synchronisierte Postfach mit dem AD, erklärt jede Abweichung und gibt am Ende ein Gesamturteil aus. Vor dem Einrichten läuft es als Vorschau, danach als Kontrolle:

Connect-ExchangeOnline
.\Test-ExchangeAttributeWriteback.ps1 -BeforeWriteback   # vorher: was würde sich ändern?
.\Test-ExchangeAttributeWriteback.ps1                    # nachher: passt alles?

Empfehlen würde ich es dort, wo gerade erst migriert wurde oder lokale Anwendungen Adressen aus dem AD lesen.

Ein Wort zu den Rechten

Wenn du nachsiehst, was der Assistent dem gMSA gibt, schluckst du kurz. Laut Microsoft setzt er alle Berechtigungen, die Cloud Sync für irgendein Szenario brauchen könnte, beim selbst angelegten wie beim eigenen gMSA. Darunter sind „Replicating Directory Changes All“ in der Domain Root, also DCSync, und „Read/Write all properties“ auf Benutzer, Gruppen und Kontakte. Auch HybridExchangePermissions allein ist schon „Read/Write all properties“. Gebraucht wird für den Writeback nur das Schreiben weniger Attribute an Benutzerobjekten.

Wenn du es enger haben willst: WriteProperty auf die zurückgeschriebenen Attribute, nur Klasse user, über eine Gruppe in der Zieldomäne, und die Einträge des Assistenten entfernen. Dann musst du aber nachziehen, sobald Microsoft das Mapping erweitert, und das Provisioning-Log auf InsufficientAccessRights beobachten. Mindestens aber gehört der Agent-Server in Tier 0, wie Microsoft es auch verlangt, und das gMSA-Objekt selbst lässt sich mit Set-AADCloudSyncRestrictedPermissions härten. Ich persönlich habe bisher davon abgesehen.

Fazit

Mit der Cloud-Verwaltung der Exchange-Attribute fällt der letzte gute Grund für den Exchange-Server on-prem weg. Für Postfächer ist das ein Schalter, für Gruppen und Kontakte ein Graph-Aufruf. Was du ersetzen musst, ist die Address Policy – und die ist oft weniger bedeutsam als geglaubt.

Den Writeback brauchst du nur, wenn lokal noch etwas Exchange-Attribute aus dem AD liest. Die meisten wollen ihn trotzdem haben und verfahren nach dem Motto: Besser haben als brauchen 🙂

Im nächsten Teil (Teil 4, erscheint in Kürze) geht es um den eigentlichen Rückbau: erst die System-Postfächer abräumen, was nach erfolgter Verlagerung der Verwaltungshoheit in die Cloud deutlich einfacher geht, dann die Hybrid-Konfiguration entfernen und den letzten Server deinstallieren.

Feedback, Fragen und Erfahrungen gerne in die Kommentare.