IsExchangeCloudManaged

Es gibt Neuigkeiten bei der Verwaltung von Exchange Online Empfängern bei der Nutzung von ADSync, Entra ID Connect Sync oder Entra ID Cloud Sync. Zukünftig können Sie die Exchange Online Einstellungen auch für "DirSync"-Benutzer wahlweise verwalten.

Ich habe das Thema auch als Audiodatei für einen Podcast aufbereitet
isexchangecloudmanaged.mp3

Bisher: OnPremises Managed

Sobald Sie ihren Microsoft 365 Tenant mit ADSync oder EntraID Cloud Sync an das lokale Active Directory gekoppelt haben, konnten Sie die meisten Exchange Eigenschaften nicht mehr im Exchange Online Admin Center oder über die Exchange Online PowerShell setzen. Sie mussten diese Einstellungen im lokalen AD über einen Exchange Server oder zumindest die Exchange Management Rolle und PowerShell machen. ADSync hat die Felder dann zu Microsoft 365 sowohl ins Azure AD/Entra ID als auch in das Exchange Verzeichnis geschrieben und jede Änderung in der Cloud unterbunden wurde.

Das bedeutete aber auch, dass Sie lokal das Exchange Schema einspielen und die Exchange Bestandteile installieren und aktualisieren mussten. Mit einem Exchange Server konnten Sie ihre Empfänger dann wenigstens per Browser verwalten, was für kleine Firmen mit Teilzeit-Administratoren oft einfacher ist, als eine Exchange PowerShell zu nutzen. Wer diese Einschränkungen nicht akzeptieren wollte, durfte kein ADSync einsetzen, sondern musste irgendwie selbst sich Gedanken über die Verwaltung der Identitäten in Microsoft 365 machen.

Phase 1: Cloud Managed

Dass diese Einschränkungen speziell bei mittleren und kleineren Firmen ein Problem ist, war Microsoft schon lange klar. Ich selbst habe das Thema schon 2017 bei einem MVP-Summit in Redmond angesprochen und wie man diese strenge Kopplung an ADSync lockern könnte. Ich weiß aber auch, dass das Thema "Verzeichnisabgleich" alles andere als einfach ist. Das Risiko von Konflikten und Unstimmigkeiten ist sehr groß.

Umso neugieriger war ich, als Microsoft erste Überlegungen angestellt hat, diese Funktion zu lockern und dabei auch das Feedback von MVPs einbezogen hat. Im ersten Schritt ist es möglich, in Exchange Online pro Benutzer zu steuern, ob das Objekt weiterhin wie bisher vom lokalen Active Directory und ADSync verwaltet wird oder ob wie eine Verwaltung der Exchange Online Properties in der Cloud möchten.

Wie setzen dazu das Feld "IsExchangeCloudManaged" auf "$True" und entkoppeln damit das Objekt hinsichtlich der Exchange Attribute von ADSync.

Set-Mailbox <identity> -IsExchangeCloudManaged:$true

Die Angabe von "IsExchangeCloudManaged" kann nicht mit anderen Befehlen kombiniert werden.

PS C:\> set-mailbox fctest3 -IsExchangeCloudManaged $true -CustomAttribute5 ext5b
Write-ErrorMessage : ||Parameter -IsExchangeCloudManaged can only be used with
the -Identity parameter and cannot be combined with any other parameters

Weitere wichtige Voraussetzungen:

  • Letzten DirSync prüfen
    Stellen Sie sicher, dass ADSync auch alle lokale Änderungen in Entra ID und Exchange Online repliziert hat. Nicht dass ausstehende Updates aus dem lokalen AD nicht mehr ankommen. Microsoft spricht von einer Wartezeit von 24h, ehe Sie nach Änderungen im lokalen AD das Feld dann setzen.
  • Berechtigungen
    Sie müssen die entsprechende Exchange Online RBAC-Rolle haben, z.B. Organization Management, Mailbox Recipients und davon abgeleitete Rollen. Zudem müssen Sie "Exchange Administrator" sein, damit sie per RBAC und PowerShell nutzen können
  • DirSync
    Das Feld können Sie natürlich nur setzen, wenn die Objekte auch durch ADSync repliziert werden, d.h. das Feld "Disynced:$true" ist. Ansonsten macht es ja keinen Sinn.
  • ADSync 2.5.76.0
    Sie müssen dazu ADSync Version 2.5.76.0 oder höher einsetzen. Ältere Versionen werden eine Fehlermeldung, weil Sie die lokalen Felder nicht mehr schreiben können.

    Prerequisites - Microsoft Entra Connect version https://learn.microsoft.com/en-us/exchange/hybrid-deployment/enable-exchange-attributes-cloud-management#microsoft-entra-connect-version

Wir können ab sofort für dieses Objekte alle Einstellungen bezüglich Exchange Online direkt in der Cloud per Exchange Online Admin Center (https://exchange.cloud.microsoft) oder Exchange Online PowerShell vornehmen.

Allerdings bedeutet dies auch, dass etwaige Änderungen im lokalen Active Directory nicht zu Exchange Online übertragen werden und auch Änderungen in Exchange Online nicht im lokalen AD landen.

Das ist aber kein Problem, da dieses Modell ja gerade für die Umgebungen ist, bei denen es lokal überhaupt keinen Exchange Server mehr gibt.

Ob und ab wann dies per Graph oder eine andere REST-API möglich sein wird, kann ich noch nicht sagen.

Phase 2: WriteBack

Aber auch wenn alle Postfächer und Maildienste durchweg in Exchange Online gehostet werden, könnte es schon noch erwünscht sein, die Informationen aus Exchange Online auch zumindest teilweise im lokalen AD zu hinterlegen. So sind die Felder "Mail" und "Proxyaddresses" auch ohne eine Exchange Schema Erweiterung im lokalen Active Directory vorhanden und könnten durch andere Dienste abgefragt werden. Ich denke hier an ERP-Applikationen, Scan2Mai-Lösungen u.a., die z.B. per LDAP das Active Directory als Verzeichnisdienst nutzen.

In einem zweiten späteren Schritt kann EntraID Cloud Sync, d.h. die "Cloud Version" von ADSync diese Funktion übernehmen. Ausgewählte Felder von Exchange Online werden dann an die lokalen Benutzer repliziert.

Die Verwaltung der Exchange Eigenschaften erfolgt weiterhin komplett in Exchange Online über die PowerShell oder das Admin Center der Cloud.

Rollback

Sie können jederzeit wieder den alten klassischen Weg einschlagen. Sie setzen einfach das Feld "isexchangecloudmanaged" in der Exchange Online wieder auf "$False" und die Daten aus dem lokalen AD werden durch ADSync wieder zu Exchange Online übertragen.

Achtung:
Damit werden die Cloud-Felder allerdings durch OnPremises überschrieben! Sie sollten also vorher sehr genau sicherstellen, dass die lokalen Einstellungen der Benutzer korrekt sind. Dies gilt insbesondere für die ProxyAddresses und Mail. Wenn Sie in der Cloud aus einem Postfach eine Shared/Room-Mailbox gemacht haben, dann sind auch RemoteRecipienttype etc. reelvant.

Der Wechsel zu "IsExchangeCloudManaged:$true" ist zwar nicht unumkehrbar aber eigentlich nicht der Regelfall.

Set-Mailbox <identity> `
   -IsExchangeCloudManaged:$false

Mit fallen nur zwei Gründe ein, warum jemand wieder die klassische Verwaltung nutzen möchte.

  • Provisining nicht Ready
    Wenn Sie den Prozess zur Anlage von Benutzern noch nicht für eine direktes Provisioning mit Exchange Online angepasst haben, macht es keinen Sinn die den "State of Authority" (SOA) eines Benutzers in die Cloud zu verschieben
  • Move Request zurück
    Wenn Sie weiter im Hybrid-Mode arbeiten und ein Postfach aus der Cloud wieder zum lokalen Exchange Server migrieren wollen, dann darf der Wert auch nicht gesetzt sein. Der MoveRequest aus der Cloud muss über den lokalen MRSProxy die Eigenschaften des lokalen AD-Objekts von "RemoteMailbox" auf "Mailbox" umstellen und ADSync die Werte wieder zu Exchange Online replizieren.

Für den Fall gibt es den Rollback.

Hybrid und Move Request

Was mache ich, wenn ich weiter Exchange Hybrid nutze, d.h. Objekte in Exchange Online und OnPremises nutze. Dann sollten sie erst mal diese Funktion nicht nutzen, denn Änderungen in Exchange Online werden in Phase 1 noch nicht nach Exchange OnPremises zurückgeschrieben. Damit funktioniert auch eine Migration von Postfächern aus der Cloud zu OnPremises nicht mehr. Fatalerweise prüft Microsoft das nicht, d.h. der MoveRequest funktioniert schon aber die Umstellung scheitert aber kann nachträglich nicht mehr geändert werden, weil in Exchange Online dann keine Mailbox sondern nur noch ein MailUser hat.

Wenn Sie Postfächer von Exchange Online zu OnPremises migrieren, muss die "isexchangecloudmanaged=$false" sein.

Aber auch in die Gegenrichtung stört natürlich die unterbrochene Replikation mit ADSync, denn im regulären Hybrid-Betrieb ändern sich natürlich auch manchmal etwas an lokalen Benutzern und da solche Änderungen dann nicht mehr bei den entsprechenden Objekten in Exchange Online ankommen, müssen Sie es dort auch noch mal pflegen.  

Meine Empfehlung: Wer Hybrid mit lokalen Servern nutzte, sollte auf den Einsatz von "isexchangecloudmanaged" verzichten und klassisch lokal verwalten, bis mit Phase 2 ein Abgleich möglich ist.

Was ist mit Gruppen?

Das Management in Exchange Online mittels "IsExchangeCloudManaged:$true" betrifft nur "Benutzer", d.h. Postfächer mit allen Varianten (Room, Shared, Equipment) aber keine Mailverteiler. ADSync kann heute Mailverteiler mit seinen Mitgliedern zu Exchange Online replizieren aber dieser Abgleich ist nicht bidirektional möglich. Änderungen in Exchange Online an Gruppen sind nicht möglich. Sie können allerdings schon länger die Gruppen direkt in Exchange Online verwalten und durch EntraID CloudSync auch in das lokale AD zurückschreiben lassen. Dazu ist es aber erforderlich, dass Sie die Gruppen direkt in Entra ID/Exchange Online verwalten oder die autoritative Quelle von OnPremises in die Cloud verlagern. Siehe dazu auch EXO Verteiler Migration.

Auch hier gibt es aber eine Funktion, die aktuell "Preview" ist

Letzter Exchange Server

Sie haben alle Benutzer in Exchange Online und möchten ihren letzten Exchange Server loswerden? Das ist nun möglich und supportet. Denken Sie aber daran, dass die vorher den lokalen Server auf "Restaktivitäten" untersuchen. Viele Server werden insbesondere noch als "Relay" für SMTP verwenden, da der Hybrid Connector eine sichere Verbindung zwischen OnPremises und dem eigenen Tenant bereitstellt.

Sonderfall Attribut "mail"

Haben Sie die Dokumentation auf https://learn.microsoft.com/en-us/exchange/hybrid-deployment/enable-exchange-attributes-cloud-management#identity-exchange-attributes-and-writeback gelesen? Dort werden alle Felder angezeigt, die beim WriteBack geschrieben werden. Ein Feld habe ich aber vermisst:

mail

Zugegeben, das Feld ist für Exchange selbst nicht relevant. Exchange orientiert sich an der Liste der Mailadressen im Feld "ProxyAddresses". Allerdings aktualisieren die Exchange Commandlets bei der Änderung der primären Mailadresse sehr wohl auch das Feld "mail". Insofern bin ich etwas verwundert, dass dieses Feld nicht zurückrepliziert und nicht mal aufgeführt wird. Ich kann aber die Mailadresse wie folgt ändern:

Set-Mailbox -identity <user> -WindowsEmailAddress <neue Mailadresse>

Damit ändert Exchange Online nicht nur die ProxyAddresses sondern auch die Mailadresse des Users in Entra ID. Sie landet aber nicht im lokalen AD und auch das Rückschreiben mit Phase 2 enthält zumindest laut Microsoft Dokumentation nicht das Feld "mail".

Wer etwas mutig ist, kann dies natürlich über eine Custom Rule  in Entra ID Sync selbst konfigurieren.

Sonderfall Attribut "mailNickName"

Das Feld "mailnickname" wird zumindest mit aufgeführt aber ebenfalls nicht beim "WriteBack" mit geschrieben. Die Exchange Administratoren kennen das Feld auch als "Alias". Es muss im Forest eindeutig sein und wird z.B. bei den Empfängerrichtlinien verwendet. Allerdings kann ich das nicht ändern.

PS C:\> Set-Mailbox fctest3 -Alias fctest3b
Write-ErrorMessage : ||Cannot modify account attribute as only the Exchange
attributes are editable for this user. None of the parameters were changed.
Learn more: https://aka.ms/ExchangeCloudManaged

Ich kann dieses Feld weiterhin nur OnPremises ändern. Das ist natürlich eine Grauzone, denn das Feld ist eigentlich nicht Bestandteil der Exchange Schemaerweiterung aber wird von Exchange OnPremises aktiv genutzt. Laut Microsoft darf ich aber Exchange Felder nur über die Exchange Verwaltungswerkzeuge ändern.

Sonderfall Attribut "ExtensionAttributeX"

Wer die von Microsoft mittlerweile freigestellten Attribute "extensionAttribute1-15" und "msExchExtensionCustomAttribute1-5" lokal z.B. zur Filterung mit ADSync verwendet, muss auch hier aufpassen, da diese Felder sehr wohl von Exchange Online weiter in Beschlag genommen und am Phase 2 auch zurückrepliziert werden.

Ein Disable-Mailbox in Exchange Online wird dann auch diese Felder "leeren" und beim Zurückschreiben verwinden die Informationen auch im lokalen AD. Das ist natürlich schlecht, wenn Sie genau diese Felder für von Exchange unabhängige Steuerungen verwenden, z.B. RFID-Kartennummern oder ADSync Filterungen. Im schlimmsten Fall könnte ADSync davon ausgehen, dass das Objekte nicht mehr repliziert werden soll und das Konto daraufhin im Entra ID auch löscht.

Sonderfall "New User"

Sie haben die Funktion eingeführt und verwaltet nun alle Exchange Online Benutzer direkt in der Cloud, während ADSync weiterhin die Benutzer anlegt und einige Felder wie Vorname, Nachname, Displayname verwaltet. Nun kommt ein neuer Mitarbeiter und sie legen ihn im lokalen AD an, warten auf den nächsten ADSync-Lauf und lassen eine Exchange Online Lizenz zuweisen. Der Benutzer bekommt ein Postfach und kann arbeiten. Sie können diesen Benutzer aber dennoch noch nicht in Exchange Online verwalten, denn der Wert von "isexchangecloudmanaged" steht by Default auf "$false".

Um den Benutzer dennoch verwalten zu können, müssen Sie den Wert erst per Exchange PowerShell setzen.

Ich habe noch keine Einstellung gefunden, wie Sie dies im Exchange Admin Center per Browser am Benutzer oder eine globale Einstellung ändern können.
Ich bin aber sicher, dass Microsoft daran schon arbeitet.

Sonderfall "Delete User"

Wenn Sie einen Benutzer im lokalen Active Directory löschen, dann wird ADSync auch das Objekt in Entra ID und Exchange Online löschen. Dies wird durch "isExchangeCloudManaged" nicht blockiert.

Sonderfall "Disable-RemoteMailbox"

Mich hat natürlich interessiert, was bei einem absichtlichen oder unabsichtlichen "Disable-Remotemailbox" im lokalen AD auf einen Benutzer passiert, der in der Cloud mit "isexchangecloudmanaged=$true" abgeschaltet ist. Also habe ich lokale einen Testuser "Disabled", d.h. das AD-Konto blieb bestehen aber ich habe alle Exchange Properties entfernt. ADSync hat diese Löschungen erkannt, ins Metaverse synchronisiert aber ausgehend nicht geschrieben. Die Filter haben dies unterbunden.

Achtung: Wenn Sie später wieder in Exchange Online mit "Set-Mailbox <identity> -IsExchangeCloudManaged:$false" den Sync wieder einschalten, dann gewinnt wieder das lokale AD

D.h. alle lokalen Änderungen werden wieder zu Exchange Online geschrieben. Das damals OnPremises deaktivierte Remote-Postfach wird aber in Exchange Online nicht gelöscht", solange es eine Lizenz hat. Daten sollten hier nicht verloren gehen aber die ProxyAddresses, ExtensionAttribute und andere Felder werden natürlich aus dem lokalen AD geholt

ADSync Details "blockExchangeAttributesOnPremisesSync"

Natürlich habe ich auch noch etwas weiter hinter die Kulissen geschaut. Dazu habe ich eine OnPremises RemoteMailbox in der Cloud getrennt und dann einen Delta-Sync laufen lassen. Es ist gut zu sehen, dass beim nächsten Delta Import aus Entra ID ein Attribut "blockExchangeAttributesOnPremisesSync" auf True gesetzt wird:

 

Interessanterweise steht bei  "Changes = None", obwohl das Feld vorher noch nicht gesetzt war. Das Feld wird auch ins Metaverse synchronisiert.

Damit wissen wir, wo wir in den Synchronization Rules schauen müssen. Es gibt das Feld an zwei Stellen. Einmal der Import aus Entra ID:

Aber auch einmal "Outbound" ins lokale AD:

Ausgehend wird das Feld aber nicht in ein lokale AD-Feld geschrieben, sondern beim Scoping-Filter verwendet:

Wenn das Feld gesetzt ist, dann werden die unter "Transformations" aufgeführten Felder nicht ins lokale AD zurückgeschrieben. Wir sehen hier aber auch noch das Feld "blockOnPremisesSync", welches wohl die Rückreplikation für Phase 2 steuert. Zuerst aber die Transformations für Exchange "blockExchangeAttributesOnPremisesSync"

Wenn das Feld auf True gesetzt ist, dann werden diese Felder nicht zurückgeschrieben. Die Felder steuern etwas Archiv und Hold-Policies, ganz viel "Spamschutz", der OnPremises wohl nicht genutzt wird und das Feld Proxyaddresses. Weder das Feld "mail" noch "Alias" werde aber nicht zurückgeschrieben.

Es wird auch kein anderes lokales AD-Feld mit der Information gefüllt, dass blockExchangeAttributesOnPremisesSync in der Cloud aktiv ist. Wir können also im lokalen AD diese nicht erkennen. Maximal eine Abfrage im ADSync Metaverse würde diese Information lokal liefern.

ADSync Details "blockOnPremisesSync"

Bei der Analyse ist aber auch noch dieses Feld aufgetaucht, welches in jeweils zwei Regeln verwendet wird. Zusätzlich zur Regel 152 kommt auch noch 120 hinzu, über die Kontakte aus Entra ID eingelesen werden

Auch beim Export gibt es nun eine zusätzliche Regel 157, die sich auf Kontakte bezieht.

Beim Zurückschreiben richtung lokalem AD wird dann aber nur die Proxy-Addresse für Kontakte geschrieben.

Diese Funktion habt aber nicht direkt etwas mit "blockExchangeAttributesOnPremisesSync" zu tun, sondern ist eher ein Hinweis, dass zukünftig hier noch mehr kommen könnte.

ADSync Details "CloudSOAExchMailbox"

Bei der Analyse ist mir noch ein Feld aufgefallen, was in den Kontext passt. "CloudSOAExchMailbox" gibt an, ob der "State of Authority" in der Cloud liegt. SOA kennen viele Administratoren vermutlich aus DNS im Netzwerk, wo bei einer DNS-Zone hinterlegt wird, welcher DNS-Server ein autoritativer Nameserver ist. Microsoft speichert in diesem Metaverse-Feld ein True oder False

Die Formel dahinter ist:

CBool(
  IIF(IsPresent([cloudMSExchRecipientDisplayType]),(
    IIF([cloudMSExchRecipientDisplayType]=0,True,(
      IIF([cloudMSExchRecipientDisplayType]=2,True,(
        IIF([cloudMSExchRecipientDisplayType]=7,True,(
          IIF([cloudMSExchRecipientDisplayType]=8,True,(
            IIF([cloudMSExchRecipientDisplayType]=10,True,(
              IIF([cloudMSExchRecipientDisplayType]=16,True,(
                IIF([cloudMSExchRecipientDisplayType]=17,True,(
                  IIF([cloudMSExchRecipientDisplayType]=18,True,(
                    IIF([cloudMSExchRecipientDisplayType]=1073741824,True,(
                      IIF([cloudMSExchRecipientDisplayType]=1073741840,True,False)
     )))))))))))))))))))
  ,False)
)  

Wenn das Feld "cloudMSExchRecipientDisplayType" vorhanden ist, dann wird für ausgewählte Werte das Feld auf "true" gesetzt. Das habe ich für ein "getrenntes" Objekt im Connector-Space geprüft

Bei einer anderen Mailbox, bei der "isExchangeCloudManaged: $false steht". findet sich hier:

 

Übrigens gibt es einen Teil der Felder auch bei Gruppen, wie Sie im Metaverse Designer gut sehen könne:

Sie können das durchaus als Zeichen sehen, dass wir auch Gruppen aus Entra ID ins lokale AD replizieren können.

Trennen und Wiederverbinden - Konflikte

Wir wissen, dass ein  "-IsExchangeCloudManaged $true" die Verwaltung einiger Felder in Exchange Online erlaubt und damit die lokalen Felder nicht mehr in die Cloud geschrieben werden. Die ADSync-Regeln haben aber keinen Filter von OnPremises zu Exchange Online. Also habe ich einen Testserie gemacht.

  • Remote Mailbox mit Sync
    Ich habe ganz klassische lokal eine "RemoteMailbox" angelegt und durch ADSync in die Cloud replizieren lassen und mit einer Exchange Online Lizenz versehen. Wie erwartet hat das alles funktioniert und auch gesetzte "CustomAttributes" sind angekommen. Die Cloud folgt OnPremises und kann auch nicht mit Set-Mailbox in der Cloud gesetzt werden.
  • Set-Mailbox fctest3 -IsExchangeCloudManaged $true
    Dann habe ich diese Mailbox in der Cloud "getrennt" und den Wert geändert. Das musste in zwei Schritte und auch etwas zeitlichem Abstand erfolgen.

    Auch bei ADSync kann es zu temporären Fehlern kommen wie "exported-change-not-reimported", wenn Sie "zu schnell" sind. Also bitte erst die Objekte mit "-isExchangeCloudManaged:true$" freistellen und dann die interne EntraID-Replikation und danach zwei ADSync-Läufe abwarten.
  • ADSync und Kontrolle
    Dann habe ich zwei DeltaSync angestoßen, bei dem die Felder "blockExchangeAttributesOnPremisesSync" und "blockOnPremisesSync" importiert und das vorher schon nicht vorhandene Rückschreiben deaktiviert wurde. Die Werte des CustomAttribute5 in Exchange Online blieben auf "5Cloud" und OnPremises hat sich auch nichts geändert. Interessant war nun nur, was im Metaverse steht.

    Im Metaverse sind die Werte für "blockExchangeAttributesOnPremisesSync" und "blockOnPremisesSync" gesetzt aber auch ein Feld "CloudSOAExchMailbox".
  • Lokal Löschen
    Ein Leser hat gefragt, was nun passiert, wenn ich lokal alle Exchange Spuren entfernen möchte und die msexch*-Felder oder CustomAttribute leere oder gleich ein "Disable-RemoteMallbox" mache. In ADSync habe ich natürlich beim Delta Import die Löschungen gesehen. und auch der Sync und sogar der Export eine Änderungen schreiben wollte.
    Aber in den Details sehen wir dann doch den Wert "5cloud", was dem Wert in Exchange Online entspricht.
  • Reaktivieren mit "-IsExchangeCloudManaged $false"
    nach all den Änderungen in der Cloud und OnPremises habe ich dann das Cloud-Objekt wieder über ADSync verwalten lassen. Diese Änderung wird nach wenigen Sekunden auch in Entra ID bekannt. Allerdings ändern sie die Werte bei dem Cloud-Objekte nicht sofort. Es ist also nicht so, dass die lokalen Daten aus dem OnPremises Verzeichnis "irgendwo" in Entra ID schon vorliegen und durch die Umstellung einfach aktiviert würden. Sie müssen schon darauf warten, dass ADSync die Werte neu schreibt. Sie sehen das im Audit-Log zum Konto:

    Das Update kommt aber nicht schon beim ersten Lauf, denn beim nächsten Import wird erst wieder das Feld blockExchangeAttributesOnPremisesSync anhand der Informationen in Entra ID gesetzt und erst beim zweiten Lauf in die Auswertung der Synchronisierungsregeln einbezogen. Manchmal erkennt ADSync auch, dass es einen "FullSync" machen muss.

Einschätzung

Bei meinen Tests habe ich keine Überraschungen gefunden und die neue Funktion scheint robust, zuverlässig und vorhersehbar zu funktionieren. Ich konnte das Verhalten problemlos nachvollziehen und in meiner Testumgebung gab es keine unerwarteten Die neue Funktion ist ideal für Firmen, die überhaupt keine lokalen Exchange Dienste mehr betreiben wollen und lieber heute als morgen die Exchange Online-Einstellungen nur noch in der Cloud verwalten aber die Verwalten der AD-Konten selbst weiterhin lokal vornehmen. Damit kommt Exchange in die gleiche Betriebsart wie auch andere Produkte, z.B. Microsoft Teams. Die Identitäten mit Kennwort, allgemeine ADFelder etc. kommen bis auf weiteres aus dem lokalen AD und Microsoft 365-spezifische Einstellungen werden nicht mehr durch ADSync aus dem lokalen AD bezogen sondern direkt in der Cloud verwaltet. Diesen Wechseln hatten wir schon beim Umstieg von Skype for Business zu Microsoft Teams gesehen. Solange lokal die msRTC-Felder und insbesondere die msRTCLineURI gefüllt war, war eine Verwaltung in der Cloud eingeschränkt. Kaum wurde das Feld lokal geleert, kann man es in der Cloud verwalten. Das Exchange Teams hat einen anderen Weg gewählt.

Wenn Sie die Änderung aber wieder rückgängig machen  wollen, dann würde ich bis zur Phase 2 warten, wenn auch der Writeback aus der Cloud ins lokale AD möglich ist. Dann sollten alle Änderungen in Exchange Online auch ins lokale AD repliziert werden. Ob das aber ausreicht, wird die Zukunft zeigen.

Weitere Links