MSXFAQ MeetNow aktiv: Komm doch einfach dazu.

Provisioning mit IsExchangeCloudManaged

Diese Seite beschreibt das Provisioning von Exchange Empfänger in Exchange Online Postfächern und anderen Empfängern ohne lokalen Exchange Server oder Management Shell bei aktiviertem Verzeichnisabgleich. Im August 2025 hat Microsoft eine neue Option bereitgestellt. Wer dies nutzt, muss seine Provisioning-Prozesse entsprechend anpassen.

Diese Beschreibung bezieht sich auf Phase 1 und zeigt auf, wie Sie Exchange Online-Objekte mit Entra ID-Connect und einem lokalen ohne Exchange Schema-Erweiterung oder ohne lokalen Exchange Server oder Management verwalten können.

Lesen Sie dazu auch die Seite IsExchangeCloudManaged und insbesondere die Gegenüberstellungen auf Exchange Online Provisioning

Was ist IsExchangeCloudManaged?

Sobald Identitäten in Microsoft 365 durch einen Verzeichnisabgleich verwaltet werden, konnte Sie die Objekte in Entra ID und Exchange Online nur noch sehr eingeschränkt verwalten. Einstellungen wie Quotas und Protokolleinstellungen (IMAP/POP/SMTP waren möglich, da Sie nicht aus dem lokalen Active Directory kommen aber Mail, ProxyAddresses, Vorname, Nachname, Abteilung etc. wurden durch das lokale AD vorgegeben. Mit der Einstellung IsExchangeCloudManaged erlaubt Microsoft nun, dass Sie die Exchange Online Einstellungen von Cloud-Postfächern direkt mit dem Exchange Online AdminCenter oder Exchange Online PowerShell bearbeiten können.

Das ist ideal, wenn Sie lokal gar keinen Exchange Server mehr betreiben wollen aber das lokale Active Directory immer noch führend bezüglich Benutzern und Gruppen sein soll.

Im August 2025 wurde die Phase 1 gestartet, bei der sie das Schreiben aus dem lokalen AD in die Cloud hinsichtlich der Exchange Attribute durch eine Einstellung an dem Cloud-Postfach deaktivieren können. Für Gruppen und Kontakte gibt es diese Funktion noch nicht. Ab 2026 ist dann auch das Rückschreiben aus Exchange Online ins lokale AD möglich, so dass lokale Dienste auch die Mailadressen z.B. per LDAP abfragen können. Mit dem Einsatz von IsExchangeCloudManaged ändert sich natürlich das bisherige Vorgehen bei der Einrichtung, Verwaltung und späteren Deaktivierung der Exchange Online Postfächer.

AD, Entra ID und EXO-Verzeichnis

Um die Funktionen besser zu verstehen, habe ich eine kleine Testserie angelegt, welche die Neuanlage eines Benutzers samt Postfach in Exchange Online durchspielt. Ohne einen lokalen Exchange Server oder eine lokale Exchange Management Shell kann ich weder "New-RemoteMailbox" noch "Enable-RemoteMailbox" machen. Ich kann nur einen Benutzer anlegen und alle anderen Prozesse erfolgen in der Cloud. Ich habe mir daher ein paar Test gemacht, was Exchange Online mit den unterschiedlichen Benutzern anfängt. Die Eckwerte sind:

  • Lokales Windows 2022 AD
  • Es gab nie einen Exchange Server und damit auch keine Schema Erweiterung oder Exchange Siciherheitgruppen
  • Entra ID Connect 2.5.79.0 ohne Exchange Hybrid Checkbox
  • Noch kein "IsExchangeCloudManaged" Aktiv
  • Benutzer wurden mit MMC für User/Computer angelegt
  • EXO Lizenz manuell zugewiesen
  • >1h gewartet wg. EXO Provisioning

Ich habe User mit und ohne EXO Lizenz und Mit/Ohne Mailadresse angelegt. Zudem einige MailUser, zwei Kontakte und universelle und globale Gruppen.

 

Alles sind AD-Benutzer, die durch Entra ID-Connect in Entra ID angelegt worden und die beiden Benutzer mit dem "WithEXO" im Namen haben manuelle eine Lizenz bekommen:

Dann habe ich natürlich einige Zeit gewartet, da die Lizenzzuweisung und das damit verbundene EXO-Provisioning durchaus einige Minuten dauern kann.

Benutzer und Postfächer

Zuerst habe ich normale "UserMailboxen" betrachtet. Folgende vier Benutzer mit unterschiedlichen Einstellungen habe ich angelegt und durch ADSync replizieren lassen. Sie haben sich an zwei Stellen unterschieden:

  • Feld:Mail
    Bei zwei Benutzern wurde eine Mailadresse im lokalen Active Directory vorgegeben. Die beiden anderen Benutzer haben keine Mailadresse erhalten
  • Exchange Online Lizenz
    Zwei der Benutzer haben nach der Replikation durch ADSync eine Exchange Online Lizenz bekommen. Dies triggert in Exchange Online die Anlage eines Postfach.

Hinweis: Ich habe das Feld "MailNickname" erst einmal nicht gefüllt", welches für Exchange OnPremises eigentlich essentiell ist.

Danach habe ich kontrolliert, wie sich die Einstellungen in Exchange Online auswirken und welche Einstellungen wohin übernommen werden.

Objekt Feld "mail" Exo Lizenz EntraID UPN EXO:Get-User EXO:Get-Mailbox  Beschreibung

UserNoMailNoEXO

Leer

Nein

Wie OnPrem 

Ja 

Keine Mailbox

Ohne "Enable-RemoteMailbox" und ohne Lizenz bekommt der Benutzer kein Postfach

UserWithMailnoEXO

Ja

Nein

Wie OnPrem 

Ja 

Keine Mailbox

Ohne "Enable-RemoteMailbox" und ohne Lizenz bekommt der Benutzer kein Postfach 

UserNoMailWithEXO

Leer

Ja

Wie OnPrem 

Ja

Mailbox

Das Feld "mail" im lokalen AD war leer. EXO hat dem User den UPN als primäre Mailadresse gegeben

UserWithMailWithEXO

Ja

Ja

Wie OnPrem 

Ja 

Mailbox 

Der User hat ein Postfach aber die primäre Adresse ist wirklich die abweichende Adresse aus "mail".

Der Entra ID UPN wurde erwartungsgemäß aus dem lokalen AD übernommen und alle vier Objekte sind in der Exchange Online PowerShell mit "Get-User" zu finden. Dies gilt sogar für die Benutzer, die keine Mailadresse haben. Ein Postfach haben aber nur die Benutzer gekommen, die auch eine Lizenz haben.

Das ist ein Unterschied zu Exchange Hybrid, wenn sie die Benutzer lokal als "RemoteMailbox" konfigurieren. Dort provisioniert Exchange eine Mailbox, die aber nach 30 Tagen ohne Lizenz wieder gelöscht wird.

Für die Verwaltung mit "IsExchangeCloudManaged" merken wir uns, dass die Exchange Online Lizenz das Postfach steuern. Es reicht nicht, dass ein Benutzer lokal eine Mailadresse im Feld "mail" hat.

Änderung von Mail

Die Benutzer mit einer Mailbox haben natürlich in Exchange Online entsprechende Mailadressen. Nach der initialen Replikation hatte der Benutzer "UserWithMailWithExo" die erwarteten Mailadresse.

PS C:\> get-mailbox UserWithMailWithExo | fl PrimarySmtpAddress,WindowsEmailAddress,EmailAddresses

PrimarySmtpAddress  : UserWithMailWithEXO3@msxfaqdev.de
WindowsEmailAddress : UserWithMailWithEXO3@msxfaqdev.de
EmailAddresses      : {SMTP:UserWithMailWithEXO@msxfaqdev.de,
                       SIP:userwithmailwithexo@msxfaqdev.de, 
                       smtp:UserWithMailWithEXO@msxfaqdev.onmicrosoft.com}

Danach habe ich OnPremises nur das Feld "Mail" geändert und ADSync angestartet.

PS C:\> get-mailbox UserWithMailWithExo | fl PrimarySmtpAddress,WindowsEmailAddress,EmailAddresses

PrimarySmtpAddress  : UserWithMailWithEXO2@msxfaqdev.de
WindowsEmailAddress : UserWithMailWithEXO2@msxfaqdev.de
EmailAddresses      : {SMTP:UserWithMailWithEXO2@msxfaqdev.de,
                      SIP:userwithmailwithexo@msxfaqdev.de, 
                      smtp:UserWithMailWithEXO@msxfaqdev.onmicrosoft.com,
                      smtp:UserWithMailWithEXO@msxfaqdev.de}

Ich habe die Mailadresse noch mehrfach geändert und die neuen Adressen wurden als "PrimarySmtpAddress" und "WindowsEmailAddress" gesetzt. In den EmailAddresses (ProxyAddresses) werden die früheren Adressen aber weiter geführt.

Wir merken uns, dass auch ohne "IsExchangeCloudManaged" die Exchange Online Empfänger zumindest auch das lokale Feld "Mail" berücksichtigen

Shared Mailbox und Room Mailbox

Bei den Funktionspostfächern gibt es eine Besonderheit. Sie können in Exchange Online eine angelegte Mailbox mit "SET-Mailbox -type <typ>" jederzeit zwischen "Regular, Shared, Room, Equipment, Workspace, Desk umschalten. Räume für Konferenzsysteme brauchen auch eine Lizenz. Eine Shared Mailbox ist aber ein deaktiviertes Konto und wenn Sie weniger als 50GB groß wird, ist auch keine Lizenz erforderlich. Wenn Sie aber nun die Tabelle anschauen, dann gibt es keinen direkten Weg eine Shared Mailbox über das lokale AD anzulegen. Sie müssen temporär mit einer Exchange Lizenz arbeiten z.B.

  1. AD-User mit Mailadresse anlegen, deaktivieren und replizieren lassen
  2. Exchange Online Plan zuweisen und auf Postfach warten
  3. Postfach mit "Set-Mailbox <MailboxID> -Type Shared" umstellen
  4. Exchange Online Plan entfernen 

Eine andere Option wäre über eine lokale Exchange PowerShell  und ADSync mit Hybrid-Checkbox wieder klassische eine Shared Mailbox anlegen. Vielleicht benötigen Sie aber im lokalen AD gar nicht die Information über die Shared Mailbox. Dann könnten Sie direkt mit der Exchange Online PowerShell oder sogar dem Exchange Online Admin Center eine Shared Mailbox anlegen.

Damit lokale Dienste das Postfach finden, könnten Sie dann immer noch lokal einen Benutzer anlegen, der mit dem gleichen Mailadresse dann matched oder sie legen einen Kontakt an, den ADSync dann natürlich nicht in die Cloud übertragen sollte.

Wenn Sie die Shared/RoomMailbox direkt in der Cloud anlegen, dann brauche Sie "-IsExchangeCloudManaged:$true" nicht
Wenn die Objekte aus dem lokalen AD kommen, dann müssen Sie ""-IsExchangeCloudManaged:$true" setzen, wenn eine Verwaltung in der Cloud gewünscht ist.

MailUser

In Exchange gibt es neben Benutzer mit Postfächern und AD-Kontakten auch MailUser. Diese Objekte werden gerne für externe Mitarbeiter genutzt, die zwar ein lokale AD-Konto aber kein Postfach bekommen. Damit Sie im Outlook Adressbuch erscheinen, konnte diese Benutzer auf einem lokalen Exchange Server mit "Enable-MailUser" aktiviert werden. Diese Befehl gibt es in Exchange Online allerdings nicht und wenn sie keinen lokalen Exchange Server und auch keine Schemaerweiterung haben, bleibt nur eine manuelle Anpassung im lokalen AD per LDAP. Für einen lokalen Exchange Server sind das "Mailuser" mit einer TargetAddress. Solche Objekte sind aber auch für Migrationen CrossTenant oder "CrossOrg" wichtig. Dort wird im Ziel ein MailUser angelegt, der später eine MailboxGuid bekommen kann. Ich habe mir natürlich die Frage gestellt, wie ich das mit Exchange Online und ADSync erreiche, wenn es keine lokalen Exchange Server oder Exchange Management Shell gibt.

Ich habe daher nacheinander Felder kombiniert, bis der Benutzer auch in der Exchange Online erschienen sind. Drei Felder sind auch ohne Exchange Schema-Erweiterung vorhanden und habe ich unterschiedlich gefüllt

  • Mail
    Hier addiere ich die externe Mailadresse des Dienstleisters.
  • Alias
    Alle Exchange Objekte sollten einen Alias haben. Ich bin davon ausgegangen, dass ein Objekt ohne Alias nicht in Exchange erscheint aber mit Alias schon.
  • TargetAddress
    Wenn das Postfach nicht in meiner Organisation ist, dann muss ich hier die externe Adresse ein zweites Mal pflegen.

Weitere Felder wie "ProxyAddresses", Recipienttype, Recipienttypedetails etc. habe ich erst einmal nicht weiter betrachtet.

Objekt Mail Alias TargetAddress EntraID EXO:Get-Recipient EXO Typ Beschreibung

MailUser1

Ja

Nein

Nein

Ja

Nein 

Nein

Ein lokaler AD-Kontakt ohne Mailadresse wird in Exchange Online gar nicht als Objekt angeboten. Er landet aber in EntraID

MailUser2

Ja

Ja

Nein

Ja

Nein 

Nein

Ein lokaler AD-Kontakt ohne Mailadresse wird in Exchange Online gar nicht als Objekt angeboten. 

MailUser3

Ja

Ja

Ja

Ja

Ja

Mailuser

Erst mit einer Target-Address wird das Objekt auch in Exchange Online sichtbar 

MailUser4 

Ja

Nein

Ja 

Ja 

Nein

Nein 

 

Erst wenn ich alle drei Felder fülle, weist Get-Recipient den Benutzer als "Mailuser" aus:

Das Verhalten liest in den ADSync-Regeln begründet, die auch ohne aktive "Hybrid-Checkbox" den MailNickname als Filter nutzen.

Erst wenn ich bei dem Benutzer einen Mailnickname pflege, überträgt ADSync zusätzlich die Felder "alias" und "TargetAddress".

Ein "Enable-Mailuser" gibt es in Exchange Online nicht. Externe Benutzer in Exchange Online ohne ADSync sind aktuell wohl nicht vorgesehen. Sie könnten diese als Gast einladen. Dann haben diese Benutzer den Status "GuestMailUser" und sind per Default versteckt. Sie könnten Sie aber natürlich sichtbar machen.

Es gibt aber ein "Set-MailUser" und da müssen Sie etwas vorsichtig sein. Es gibt keinen Parameter "-isExchangeCloudManaged $true" aber dennoch kann ich z.B. den Alias in der Cloud überschreiben, obwohl er eigentlich von ADSync replizert werden sollte. Selbst ein "FullSync" mit ADSync setzt den Wert nicht zurück. Die "Custom Attributes" hingegen kann ich mit dem bekannten "DualWrite"-Fehler nicht schreiben.

Wenn ich dann das Property MailNickName/Alias im lokalen AD ändere, dann wird es von ADSync wieder zu EntraID repliziert und landet mit etwas Verzögerung auch wieder in Exchange Online.

Nur zur Vollständigkeit: Sie können Sie mit "Set-MailUser" in der Cloud auch problemlos eine ExchangeGuid setzen, was für Migrationen wichtig ist.

Für per ADSync verwaltete MailUser bleibt das lokale AD führend und bestimmend. Sie können einen MailUser hinsichtlich Exchange nicht vom lokalen AD abkoppeln. Es gibt hier einfach den Parameter "IsExchangeCloudManaged" nicht.

Sie können übrigens sehr wohl über die Exchange Online PowerShell einen "CloudOnly" MailUser anlegen, z.B. mit:

New-Mailuser `
   -Alias mailuser5cloud `
   -ExternalEmailAddress mailuser5cloud@carius.de `
   -PrimarySmtpAddress mailuser5cloud@carius.de `
   -Name MailUser5Cloud `
   -MicrosoftOnlineServicesID mailuser5clou@msxfaq.net

Sie müssen dann nur noch ein Startkennwort mit eingeben, damit in EntraID ein Benutzer erscheint, der in Exchange in MailUser ist. Wenn Sie den Benutzer aber in EntraID anlegen, habe ich noch keinen Weg gefunden, diesen nachträglich zu einem Mailuser hochzustufen.

Denken Sie daran, dass es im Tenant auch noch Gastuser gibt, die standardmäßig als Exchange Empfänger erscheinen aber "verborgen" sind.

Kontakte

Bei Kontakten wurde nur aus dem Kontakt mit einer Mailadresse in "Mail" auch ein Exchange Online Kontakt geworden.

Objekt Feld "mail" EXO:Get-Contact EXO Beschreibung

ContactNoMail

Nein

Nein 

Nein

Ein lokaler AD-Kontakt ohne Mailadresse wird in Exchange Online gar nicht als Objekt angeboten. 

ContactWithMail

Ja

Ja 

MailContact

Ein lokaler AD-Kontakt mit Mailadresse erscheint als Mailcontact in Exchange Online.
Die "ExternalEmailAddress" ist in Exchange Online identisch zu "mail".

Kontakte haben natürlich keinen UPN oder Lizenzen. Kontakte haben aber auch kein Feld "IsExchangeOnlineManaged". Durch ADSync replizierte Kontakte können weiter nur im lokalen AD verwaltet werden. In der Exchange Online PowerShell bekommen Sie beim Versucht etwas zu ändern auch einen Fehler:

In der Exchange Online Managementshell können Sie den Kontakt angeblich ändern und ohne Fehler schreiben (Stand 29. Nov 2025) aber die Änderungen werden nicht geschrieben.

Für ihr Provisioning bedeutet dies, dass sie solche Kontakte weiter im AD verwalten oder direkt "Cloud Only" Kontakte anlegen, die im lokalen AD dann aber nicht sichtbar sind.

Gruppen

Bei den Gruppen ergibt sich folgendes Bild.

Objekt Feld "mail" EXO:Get-Group EXO:Get-Distributiongroup

GroupGDNoMail

Nein

Nein

Nein

GroupGDWithMail

Ja

Universal

Universal

GroupUDNoMail

Nein

Nein

Nein

GroupUDWithMail

Ja

Universal

Universal

GroupGSNoMail

Nein

Nein

Nein

GroupGSWithMail

Ja

Universal, SecurityEnabled

Universal, SecurityEnabled

GroupUSNoMail

Nein

Nein

Nein

GroupUSWithMail

Ja

Universal, SecurityEnabled

Universal, SecurityEnabled

 

Hier erspare ich mir die Einzelbeschreibung pro Gruppe, da für alle Gruppen gilt:

  • Keine Mailadresse = nicht für Exchange Online relevant 
  • Mailadresse = Distributiongroup in Exchange Online

Für die Exchange Online Gruppen gilt aber aufgrund von ADSync immer noch die Einschränkung, dass die Pflege im lokalen AD erfolgen muss.

 

Diese Einschränkung entfällt erst, wenn Sie die Gruppen direkt in Exchange Online und Entra ID als "Cloud Only"-Objekte anlegen. Dann können die auch Gäste und andere "CloudOnly"-Objekte als Mitglieder aufnehmen.

Bei Gruppen gibt es kein "-IsExchangeCloudManaged:$true". Synchronisierte Gruppen müssen im lokalen AD verwaltet werden oder Sie wechseln zu "CloudOnly"-Gruppen

IsExchangeCloudManaged automatisieren

Bis hierhin haben wir alle Testobjekte im lokalen Active Directory verwaltet und zugeschaut, wie Exchange Online darauf reagiert. Wir haben auch gelernt, dass für einige Funktionen ein Wert in "Mailnickname/Alias" erforderlich ist und welche Auswirkungen Änderungen des lokalen AD-Felds "mail" auch ohne Hybrid-Konfiguration auf die Exchange Online Objekte haben.

Diese Funktion ist nicht erforderlich, wenn Microsoft es ab Phase 2 erlaubt, tenantweit diese Funktion per Default zu ändern.

Dennoch können wir die Exchange Online Objekte noch nicht verwalten. Dafür ist "IsExchangeCloudManaged" zuständig. Dieses Attribut muss mittels Exchange Online Powershell direkt in der Cloud gesetzt werden. Es kommt nicht aus dem lokalen AD aber ADSync liest es natürlich beim Import aus dem Tenant aus und filtert dann beim Export. Mit Phase 2 will Microsoft eine Einstellung bereitstellen, mit der Sie für alle Objekte eine Standardeinstellung von "IsExchangeCloudManaged" vorgeben. Bis dahin können Sie eine ähnliche Funktion natürlich z.B. per lokalem Powershell oder einer Azure Function automatisieren.

Ein lokales PowerShell-Skript sollte sich am besten per App Registration an Exchange Online anmelden. Details zur Einrichtung finden Sie dazu auf EXO PowerShell Automation. Der Code ist dann einfach:

# Verbinden mit PFX-Datei und Zertifikat
Connect-ExchangeOnline `
   -CertificateFilePath ".\automation-cert.pfx" `
   -CertificatePassword (ConvertTo-SecureString -String "" -AsPlainText -Force) `
   -AppID "36ee4c6c-0812-40a2-b820-b22ebd02bce3" `
   -Organization "msxfaqdev.onmicrosoft.com"

# Das funktioniert aktuell leider noch nicht
#Get-Mailbox -filter 'IsExchangeCloudManaged -eq $true' 


Get-Mailbox -resultsize unlimited `
| Where {!$_.IsExchangeCloudManaged -and $_.IsDirSynced} `
| Set-Mailbox -IsExchangeCloudManaged:$true

Vielleicht haben Sie heute schon irgendwo einen "Job-Server", auf dem Sie zur Automatisierung verschiedene Skripte regelmäßig ausführen lassen.

Da die Änderung nur die Exchange Online PowerShell betrifft, bietet es sich natürlich an, diese regelmäßige Funktion über ein  Azure Runbook oder Azure Function nach einem Zeitplan laufen zu lassen.
Idealerweise nutzt man dazu dann eine Managed Identity, welche die erforderlichen Berechtigungen bekommt.

Hier ein paar weiterführende Links, wenn Sie so eine Funktion umsetzen wollen 

Vorschlag

Die Verwaltung von Exchange Online ganz ohne lokale Exchange PowerShell ist im Dezember schon ziemlich gut nutzbar. Vielen Administratoren wird z.B. nicht bekannt sein, dass eine Änderung des Felds "mail" im im lokalen Active Directory direkte Auswirkungen auf die primäre Mailadresse von Exchange Online und die ProxyAddresses dort hat. Nur wenn Sie mehr Einstellungen in Exchange Online anpassen wollen, die durch ADSync noch gesperrt sind, dann kann die Aktivierung von "isExchangeCloudManaged = $true" pro Postfach helfen. Der weg mit einer lokalen Exchange Recipient Management PowerShell oder gar einem lokalen Exchange Server steht ihnen natürlich offen.

Für das Provisioning von Postfächern ist folgende Reihenfolge aus meiner Sicht optimal. 

  1. Lokales AD: User im AD anlegen und Feld „mail“ pflegen.
    Zuerst legen wir einen Benutzer im lokalen Active Directory an. Wenn ich nicht möchte, dass der Benutzer in Exchange Online eine Mailadresse der "Default Domain" bekommt, dann sollte ich gleich im Active Directory das Feld "Mail mit pflegen. Das geht direkt in der MMC für Benutzer und Computer:

    Für "MailUser" müssen sie aber auch noch die Felder "TargetAddress" und "alias" pflegen, welche auf der Karteikarte "Attribut Editor" erreichbar sind.
  2. Verzeichnisabgleich abwarten
    Entra ID Connect Sync oder Cloud Sync sollten den neuen Benutzer finden und in Entra ID anlegen.
  3. Exchange Online Plan zuweisen
    Nun können Sie dem Benutzer eine Lizenz zuweisen, damit Exchange Online für den Benutzer ein Postfach anlegt. Das kann manuelle über das Microsoft 365 Admin Center oder über eine Gruppe erfolgen.
    Hinweis: Wen Sie lokal einen Exchange Server nutzen, dann sollten Sie das Postfach lokal über "Enable-RemoteMailbox" aktivieren, ehe Sie eine Lizenz zuweisen. Siehe auch RemoteMailbox Provisioning und Doppelpostfach mit Exchange Online
  4. Optional: Exchange Online Management aktivieren
    Wenn sie beim Postfach z.B. weitere sekundäre Mailadressen addieren wollen, dann könnten Sie diese lokal im Feld "ProxyAddresses" eintragen und durch den Verzeichnisabgleich synchronisieren lassen. Sie können aber auch die Postfächer über die Exchange Online PowerShell "entkoppeln" „Set-Mailbox  -isExchangeCloudManaged:$True” und dann im Exchange Online Admin Center bei Bedarf weiter pflegen.

Der letzte Schritt ist optional und nur erforderlich, wenn Sie weitere Mailadresse addieren oder andere Exchange Einstellungen anpassen wollen, die durch den Verzeichnisabgleich (Stichwort "Dual Write Exception") gesperrt sind. Anfang 2026 wird es möglich sein, diese Sperre "per Default" zu lösen.

Ergebnis

Mit der Funktion "isExchangeCloudManaged" können sie eine Exchange Online Umgebung mit aktiviertem Verzeichnisabgleich, welcher die Benutzer, Gruppen und Kontakte aus einem lokalen AD in ihren Tenant repliziert, bezüglich der Postfächer schon seit Oktober 2025 problemlos in der Cloud verwalten. Beachten Sie aber die Sonderfunktion des Felds "mail" im lokalen Active Directory, welches auch mit "isExchangeCloudManaged" maßgeblich die primäre Adresse in Exchange Online übersteuert.

Alle die anderen Objekte, d.h. Verteiler, Kontakte und MailUser müssen Sie allerdings weiter lokal verwalten oder sie legen diese gar nicht mehr im lokalen Active Directory an und nutzen direkt "CloudOnly"-Objekte. Dann sind sie aber im lokalen AD aber auch nicht mehr sichtbar und nicht mehr per LDAP auffindbar. Das kann unerwünscht sein. Dann müssten Sie sich ein "WriteBack" überlegen.

Weitere Links