Seiten

Freitag, 10. Juli 2026

Exchange Hybrid: SOA-Transfer – Postfach-Attribute endlich in der Cloud verwalten

SOA_Transfer


Wer Exchange Hybrid betreibt und alle Postfächer längst in Exchange Online hat, kennt das Dilemma: Für die Verwaltung der Exchange-Attribute von synchronisierten Benutzern braucht es weiterhin einen lokalen Exchange Server – den berüchtigten Last Exchange Server (LES). Attribute wie E-Mail-Adressen oder CustomAttributes werden on-prem gepflegt und per Entra Connect in die Cloud synchronisiert. Microsoft bietet nun einen Ausweg: Mit dem Source of Authority (SOA) Transfer wandert die Verwaltungshoheit für Exchange-Attribute in die Cloud – pro Postfach oder gleich für den ganzen Tenant. Schauen wir genauer hin.

Was der SOA-Transfer macht

Der SOA-Transfer trennt die Zuständigkeiten sauber auf: Die Identitätsattribute (Name, UPN, Abteilung, Telefonnummern usw.) bleiben im lokalen Active Directory und werden weiterhin synchronisiert. Die Exchange-Attribute (E-Mail-Adressen, CustomAttributes, HiddenFromAddressListsEnabled, Weiterleitungen usw.) hingegen werden nach dem Transfer direkt in Exchange Online verwaltet – per EXO PowerShell, Exchange Admin Center oder Microsoft 365 Admin Center.

Gesteuert wird das über eine neue Postfach-Eigenschaft: IsExchangeCloudManaged. Steht sie auf true, ignoriert Exchange Online die Exchange-Attribute aus der on-prem-Synchronisation und erlaubt die direkte Bearbeitung in der Cloud.

Microsoft rollt das Feature in zwei Phasen aus:

  • Phase 1 (GA): Per-Postfach-Steuerung über IsExchangeCloudManaged, inklusive Rollback-Möglichkeit. Verfügbar in Commercial-Tenants sowie GCCH, DoD und Gallatin.
  • Phase 2 (Public Preview): Attribute-Writeback über Microsoft Entra Cloud Sync. Änderungen an definierten Exchange-Attributen (z. B. Proxy-Adressen, CustomAttribute1–15) werden automatisch ins lokale AD zurückgeschrieben. In der Preview gilt eine Grenze von 200'000 cloud-verwalteten Postfächern pro Tenant. Microsoft hatte die allgemeine Verfügbarkeit auf Ende Juni 2026 angekündigt; die Dokumentation führt das Writeback zum Zeitpunkt dieses Beitrags aber weiterhin als Public Preview.

Voraussetzungen

  • Entra Connect Sync in Version 2.5.190.0 oder neuer. Ältere Versionen versuchen weiterhin, Exchange-Attribute bereits übertragener Postfächer zu pushen – und scheitern.
  • Für das Writeback (Phase 2) zusätzlich der Entra Cloud Sync Provisioning Agent in Version 1.1.1107.0 oder neuer. Wichtig: Cloud Sync wird zusätzlich zu Connect Sync installiert, nicht als Ersatz – Connect Sync synchronisiert weiter wie bisher, Cloud Sync übernimmt nur das Writeback.
  • Rollen: Exchange Administrator (empfohlen), Hybrid Identity Administrator oder Global Administrator.
  • Das Postfach muss in der Cloud liegen und der Benutzer IsDirSynced = true haben.

Die installierte Connect-Sync-Version lässt sich per PowerShell prüfen:

(Get-ADSyncGlobalSettings).Parameters['Microsoft.Synchronize.ServerConfigurationVersion']

SOA pro Postfach übertragen

Wichtig vorab: Nach der letzten on-prem-Änderung per Set-RemoteMailbox sollte man den üblichen Sync-Zyklus plus 24 Stunden abwarten, bevor man umstellt – sonst gehen Änderungen verloren.

Der eigentliche Transfer ist dann ein Einzeiler in der Exchange Online PowerShell:

Set-Mailbox -Identity user@contoso.ch -IsExchangeCloudManaged $true

Kontrolle:

Get-Mailbox -Identity user@contoso.ch | Format-List Identity, IsExchangeCloudManaged

Ab jetzt werden die Exchange-Attribute nicht mehr aus dem on-prem AD aktualisiert, und Bearbeitungen, die bisher mit «The object is being synchronized from your on-premises organization» blockiert wurden, funktionieren direkt in der Cloud:

Set-Mailbox -Identity user@contoso.ch -CustomAttribute1 "ModifiedInTheCloud"

Alle bereits übertragenen Postfächer findet man so:

Get-Mailbox | Where-Object { $_.IsDirSynced -eq $true -and $_.IsExchangeCloudManaged -eq $true }

Attribute-Writeback einrichten (Preview)

Ohne Writeback laufen Cloud und on-prem AD bei den Exchange-Attributen auseinander. Wer das lokale AD aktuell halten will (oder muss), richtet das Writeback über Entra Cloud Sync ein:

  • Im Microsoft Entra Admin Center unter Entra Connect → Cloud Sync eine neue Konfiguration vom Typ «EXO to AD attribute sync (Preview)» erstellen.
  • Auf der Übersichtsseite Start provisioning wählen – der erste Zyklus startet nach wenigen Minuten, danach läuft die Synchronisation etwa alle 20 Minuten.
  • Für einzelne Benutzer lässt sich der Abgleich mit Provision on demand sofort auslösen.

Der Funktionstest ist unkompliziert – Attribut in der Cloud setzen, Sync abwarten, on-prem prüfen:

# Exchange Online:
Set-Mailbox -Identity user@contoso.ch -CustomAttribute1 "TestValue_$(Get-Date -Format 'yyyyMMdd_HHmmss')"

# On-prem (Management Tools / EMS):
Get-RemoteMailbox -Identity user@contoso.ch | Format-List CustomAttribute1

Ein Punkt, der in der Praxis gerne untergeht: «In der Cloud editierbar» und «wird ins AD zurückgeschrieben» sind zwei verschiedene Dinge. Nach dem SOA-Transfer lassen sich fast alle Exchange-Attribute in Exchange Online bearbeiten – aber nur ein Teil davon wandert per Writeback zurück ins lokale AD:

  • Editierbar mit Writeback: z. B. CustomAttribute1–15 (extensionAttribute1–15) und Proxy-Adressen.
  • Editierbar ohne Writeback: z. B. WindowsEmailAddress, Annahme-/Ablehnungslisten (AcceptMessagesOnlyFrom u. ä.), Weiterleitungen (ForwardingAddress) und Archiv-Eigenschaften – diese Werte existieren nach der Änderung nur noch in der Cloud.

Wer on-prem-Prozesse (Skripte, IDM, Gruppenfilter) auf solchen Attributen aufgebaut hat, sollte vor dem Transfer prüfen, ob die betroffenen Attribute Writeback unterstützen. Die vollständige Attribut-Tabelle mit Editierbarkeit und Writeback-Status findet sich in der Microsoft-Doku (Link unten).

Tenant-weite Aktivierung

Wer nicht jedes Postfach einzeln umstellen will, kann das Verhalten für neue Postfächer tenant-weit als Standard setzen:

Set-OrganizationConfig -ExchangeAttributesCloudManagedByDefault

# Kontrolle (True = aktiviert):
Get-OrganizationConfig | Format-List BlockExchangeProvisioningFromOnPremEnabled

Zwei Dinge sind dabei zu beachten: Bestehende, bereits migrierte Postfächer sind davon nicht betroffen – die müssen weiterhin einzeln per IsExchangeCloudManaged übertragen werden. Und Microsoft warnt ausdrücklich davor, die tenant-weite Option zu aktivieren, solange noch produktive Postfächer on-prem gehostet werden: Neu erstellte on-prem-Postfächer erscheinen dann nicht mehr in der globalen Adressliste von Exchange Online.

Neue Postfächer anlegen und löschen

Der empfohlene Workflow für neue Postfächer ohne on-prem Exchange sieht so aus:

  • AD-Benutzer on-prem anlegen und Identitätsattribute pflegen.
  • Entra Connect synchronisiert die Identität in die Cloud.
  • Im Microsoft 365 Admin Center eine Exchange-Online-Lizenz zuweisen – das provisioniert das Postfach.
  • Mit Set-Mailbox -IsExchangeCloudManaged $true die SOA übertragen (entfällt bei aktivierter tenant-weiter Option).

Gelöscht wird weiterhin klassisch: Benutzer im on-prem AD entfernen, die Löschung synchronisiert sich in die Cloud und entfernt auch das Postfach.

Rückweg und Stolpersteine

  • Rollback: Set-Mailbox -IsExchangeCloudManaged $false stellt zurück auf on-prem-Verwaltung. Achtung: Beim nächsten Sync überschreiben die on-prem-Werte die Cloud-Werte – Cloud-Änderungen vorher sichern (Get-Mailbox / Get-User).
  • Offboarding: Soll ein Postfach zurück nach on-prem migriert werden, muss IsExchangeCloudManaged zwingend vorher auf false – sonst bricht die Synchronisation der Exchange-Attribute.
  • Vor- und Nachname und alle anderen Identitätsattribute werden weiterhin ausschliesslich im on-prem AD gepflegt.
  • Shared Mailboxes bei tenant-weiter Aktivierung: entweder direkt in der Cloud (ohne AD-Objekt) erstellen oder temporär lizenzieren und danach konvertieren.
  • Wer eine Dritthersteller-IDM-Lösung einsetzt, sollte beim Hersteller nachfragen, ob das Feature unterstützt wird.

Fazit

Der SOA-Transfer schliesst die letzte grosse Lücke auf dem Weg zum Exchange-freien Rechenzentrum: Empfängerverwaltung direkt in der Cloud, mit vertrauten Tools und ohne PowerShell-Snap-in-Verrenkungen. Für Umgebungen, die den letzten Exchange Server loswerden wollen, ist er die modernere Alternative zum Management-Tools-Ansatz, den ich hier beschrieben habe. Solange das Attribute-Writeback noch in Preview ist, gilt für produktive Umgebungen mit Writeback-Bedarf: testen, aber mit Bedacht ausrollen. Wer das lokale AD bei den Exchange-Attributen nicht aktuell halten muss, kann mit Phase 1 schon heute produktiv arbeiten.

Quellen

Eingestellt von um
Labels: , , , , , ,

Keine Kommentare:

Kommentar veröffentlichen

Abonnieren Kommentare zum Post (Atom)