EXO Verteiler Migration

Wer Exchange Online mit ADSync verwendet, kennt die Probleme von Verteilern, die auch durch ADSync verwaltet werden. Sie können nicht in der Cloud verwaltet verwaltet werden. Sie können also auch keine CloudOnly-Benutzer oder Gäste addieren, da ADSync die Finger drauf hält. Diese beschreibt, wie sie daraus CloudOnly-Verteiler machen können.

Problemstellung

Dass ADSync die Gruppen, deren Mitgliedschaften und Mailadressen zwischen einem lokalen Exchange und Exchange Online synchron hält, ist für die Funktion einer Exchange Hybrid-Bereitstellung mit gemeinsam genutzter SMTP-Domain nicht nur "nett" sondern eine für die reibungslose Funktion zwingend erforderlich. Aber wenn Sie keine lokalen Exchange Server mehr betreiben und nur noch ADSync mit der Exchange Management Rolle betreiben, dann stört der "Schreibschutz" in der Cloud.

Die Probleme gehen noch weiter, denn solange z.B. Exchange Postfächer alle OnPremises waren, konnten Sie als Administrator auch reguläre Benutzer zum "Besitzer" einer Gruppe machen. Das sollten sie natürlich nie mit kritischen Berechtigungsgruppen machen aber für Exchange Verteiler oder Berechtigungsgruppen auf SharedMailboxen ist diese Option durchaus interessant. Die normalen Anwender konnten nämlich dann über Outlook oder OWA direkt die Mitgliedschaften der Gruppen selbst verwalten.

Sobald Sie aber das Postfach des Mitarbeiters zu Exchange Online verschoben haben, ist dieser Weg verbaut. Outlook und OWA verbinden sich mit ExchangeOnline und Exchange Online kommuniziert nur mit seinem eigenen Verzeichnisdienst in der Cloud. Ein Durchgriff auf das lokale AD ist damit nicht möglich und die Gruppen in der Cloud sind dank ADSync leider "ReadOnly".

Sie müssen Sich in dem Fall eine eigene Lösung bauen oder zukaufen, mit der die Anwender z.B. per Browser auf einem Portal die lokalen Mitgliedschaften verwalten können.

Da stellt sich dann schon die Frage, ob wir die Verknüpfung zwischen der lokalen Gruppe und der AzureAD/ExchangeOnline Gruppe nicht irgendwie auflösen können.

Achtung: Solange es lokale Exchange Server gibt, müssen Sie immer darauf achten, dass beide Welten alle Empfänger kennen.

Ausgangssituation

Die nächsten beiden Abschnitte gehen davon aus, das wir AzureAD-Gruppen über den Papierkorb wiederherstellen können. Dies ist (Stand Okt 2023) nur für Microsoft Groups möglich.

Ich habe zuerst einen Verteiler im lokalen Exchange Server mit vier Mitgliedern angelegt und msExchExtensionCustomAttribute1 und msExchExtensionAttribute1 gefüllt. Ich hätte noch mehr Properties füllen können aber für meinen Test sollte die reichen.

Einige Minuten später war ADSync fertig und die Informationen im Azure AD sind überschaubar.

PS C:\> Get-AzureADGroup -ObjectId 70a8bf9b-ed4c-44d8-895e-9b5862986536| fl *

DeletionTimestamp            :
ObjectId                     : 70a8bf9b-ed4c-44d8-895e-9b5862986536
ObjectType                   : Group
Description                  :
DirSyncEnabled               : True
DisplayName                  : FCDLTest
LastDirSyncTime              : 19.10.2023 14:36:51
Mail                         : FCDLTest@msxfaqdev.de
MailEnabled                  : True
MailNickName                 : FCDLTest
OnPremisesSecurityIdentifier : S-1-5-21-11949449-30417519-71842111-15974
ProvisioningErrors           : {}
ProxyAddresses               : {x500:/o=ExchangeLabs/ou=Exchange Administrative Group
                               (FYDIBOHF23SPDLT)/cn=Recipients/cn=dd48d38006c74bbb891f1e268dd187e2-70a8bf9b-ed,
                               X500:/o=Net at Work GmbH/ou=Exchange Administrative Group
                               (FYDIBOHF23SPDLT)/cn=Recipients/cn=1296180ee7994b85904ccb060829044d-FCDLTes,
                               smtp:FCDLTest@msxfaqdev.onmicrosoft.com, smtp:FCDLTest@nospamproxy.org...}
SecurityEnabled              : True

Etwas mehr Informationen zeigt hier schon die Exchange Online Powershell. Hier sehen Sie in der Zeile 4 auch das Flag "IsDirSynced"

PS C:\> Get-DistributionGroup fcdl* | fl

GroupType                              : Universal, SecurityEnabled
SamAccountName                         : $S9GPJ0-RQNCERJI816P
BypassNestedModerationEnabled          : False
IsDirSynced                            : True
ManagedBy                              : {Organization Management}
MemberJoinRestriction                  : Closed
MemberDepartRestriction                : Closed
MigrationToUnifiedGroupInProgress      : False
HiddenGroupMembershipEnabled           : False
ReportToManagerEnabled                 : False
ReportToOriginatorEnabled              : True
SendOofMessageToOriginatorEnabled      : False
Description                            : {}
BccBlocked                             : False
AcceptMessagesOnlyFrom                 : {}
AcceptMessagesOnlyFromDLMembers        : {}
AcceptMessagesOnlyFromSendersOrMembers : {}
AddressListMembership                  : {\All Distribution Lists, \Offline Global Address List, \Default Global
                                         Address List, \Groups(VLV)…}
AdministrativeUnits                    : {}
Alias                                  : FCDLTest
ArbitrationMailbox                     : SystemMailbox{15e25b94-0120-42b3-ae34-7aae37db8ded}
BypassModerationFromSendersOrMembers   : {}
OrganizationalUnit                     : deup281a007.prod.outlook.com/Microsoft Exchange Hosted
                                         Organizations/msxfaqdev.onmicrosoft.com
CustomAttribute1                       : extensionAttribute1 
ExtensionCustomAttribute1              : {}
DisplayName                            : FCDLTest
EmailAddresses                         : {SMTP:FCDLTest@msxfaq.net…}
ExternalDirectoryObjectId              : 70a8bf9b-ed4c-44d8-895e-9b5862986536
HiddenFromAddressListsEnabled          : False
LegacyExchangeDN                       : /o=ExchangeLabs/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipien
                                         ts/cn=dd48d38006c74bbb891f1e268dd187e2-70a8bf9b-ed
MaxSendSize                            : Unlimited
MaxReceiveSize                         : Unlimited
ModeratedBy                            : {}
ModerationEnabled                      : False
PoliciesIncluded                       : {}
PoliciesExcluded                       : {{26491cfc-9e50-4857-861b-0cb8df22b5d7}}
EmailAddressPolicyEnabled              : False
PrimarySmtpAddress                     : FCDLTest@msxfaqdev.de
RecipientType                          : MailUniversalSecurityGroup
RecipientTypeDetails                   : MailUniversalSecurityGroup
RejectMessagesFrom                     : {}
RejectMessagesFromDLMembers            : {}
RejectMessagesFromSendersOrMembers     : {}
RequireSenderAuthenticationEnabled     : True
SimpleDisplayName                      :
SendModerationNotifications            : Always
UMDtmfMap                              : {}
WindowsEmailAddress                    : FCDLTest@msxfaq.net
MailTip                                :
MailTipTranslations                    : {}
Identity                               : 70a8bf9b-ed4c-44d8-895e-9b5862986536
Id                                     : 70a8bf9b-ed4c-44d8-895e-9b5862986536
IsValid                                : True
ExchangeVersion                        : 0.10 (14.0.100.0)
Name                                   : 70a8bf9b-ed4c-44d8-895e-9b5862986536

Damit war die Ausgangsituation geschaffen.

Eine Gruppe als Mailverteiler im AzureAD und Exchange Online, die ich nicht in der Cloud verwalten kann, weil ADSync die Hand drauf hält.

Verteiler löschen und Undelete?

Eine lange Lebensdauer war meiner Testgruppe nicht beschieden, den ich habe sie im lokalen AD direkt wieder gelöscht. Da ich lokal noch einen LES - Last Exchange Server bzw. Hybrid Connector Server habe, habe ich das ECP genutzt. Es macht technisch aber keinen Unterschied, wie ich die Gruppe aus dem lokalen AD letztlich lösche.

Achtung:
Mit der Löschung verschwinden auch die Mailadressen der Gruppe. Es sollte also keinen lokalen Exchange Server mehr geben der andere Dienste, die z.B. per LDAP diese Mailadresse suchen. Das können auch lokale Spamfilter, Scan2Mail oder Skripte sei, die das Active Directory zugleich als Adressbuch nutzen.

Aber es gibt immer mehr Firmen, die den lokalen Exchange Server komplett loswerden wollen aber dennoch ihre Benutzer mit ADSync verwalten. Sie können natürlich auch allein mit einer Exchange Management Rolle und ADSync verwalten aber die Beschränkung bleibt, dass der Verteiler in der Cloud "ReadOnly" ist und alle Mitglieder zwingend auch lokale AD-Objekte sein müssen. Also keine Gäste, keine Microsoft Teams, keine Office Groups etc. Das geht alles mit "Cloud Only"-Verteilern. Also lösche ich den Verteiler im lokalen AD

Nun muss ich wieder einen ADSync abwarten oder anstoßen, damit die Gruppe auch im AzureAD gelöscht wird. Der Verteiler verschwindet damit komplett aus Exchange Online und auch im AzureAD-Portal. Wenn Sie nun aber auf "gelöschte Gruppen" gehen, dann finden Sie die soeben gelöschte Gruppe nicht (Stand Okt 2023).


https://portal.azure.com/#view/Microsoft_AAD_IAM/GroupsManagementMenuBlade/~/DeletedGroups

Auf der Suche, ob dies vielleicht per PowerShell möglich ist, habe ich folgende Aussage gefunden:

When a group is deleted it is initially soft deleted and can be recovered during the first 30 days after deletion. After 30 days the group is permanently deleted and can no longer be recovered. Note that soft delete is currently only implemented for Unified Groups (a.k.a. Office 365 Groups)
Quelle: Get-AzureADMSDeletedGroup https://learn.microsoft.com/en-us/powershell/module/azuread/get-azureadmsdeletedgroup

Die Funktion ist für reguläre Gruppen einfach nicht vorhanden. Sie können aktuell Gruppe nicht wiederherstellen, die nicht zugleich "Microsoft Groups" sind. Einen Grund dafür kann ich leider nicht geben.

Dies ist daher kein Weg, um eine bisher per ADSync in Exchange Online verwaltete Gruppe zur CloudOnly-Gruppe zu machen.

DirSync Aus/An-Schalten

Dann habe ich mir überlegt, ob ich nicht einfach ADSync komplett entferne und damit die Objekte in der Cloud zu "CloudOnly"-Objekten werden. Das ist sogar möglich.

  1. Im Tenant die Funktion "DirSync" abschalten
    Das kann durchaus einige Stunden dauern aber dann sollten ALLE Objekte den Status von "DirSync" auf "CloudOnly" erhalten haben.
  2. ImmutableID gibt es nicht
    Wenn Sie Benutzer über den Weg von DirSync auf CloudOnly setzen wollen, dann müssen Sie danach die ImmutableID in der Cloud löschen. Ansonsten würde eine neue ADSync-Installation das Objekt direkt wieder "finden und eindeutig zuordnen. Bei Verteilern gibt es aber keine ImmutableID
  3. ADSync wieder einrichten und Gruppen ausschließen.
    Natürlich will ich ja ADSync für Benutzer und viele andere Gruppen und Devices behalten. Also richte ich ADSync wieder ein aber schließe in der Quelle nun die Exchange Verteiler aus. ADSync matched alle Benutzer wieder anhand der ImmutableID und auch die im ADSync eingeschlossenen Gruppen. Die nun aber ausgeschlossenen Gruppen "bleiben" CloudOnly-Gruppen und sind damit in Exchange Online verwaltbar.

Leider ist das Verfahren alles andere als mal eben gemacht, denn wenn Sie nur die Gruppen aus dem lokalen AD ausschließen oder entfernen würden, dann würde ADSync diese auch in der Cloud löschen. Sie müssen schon den DirSync des kompletten Tenants deaktivieren und neu einrichten. Das kann Stunden dauern, bis alle Objekte in der Cloud "umgestellt" sind, in der es dann auch keine Updates aus dem lokalen AD gibt und es ist schon ein Spiel am offenen Herzen, denn bei der Neueinrichtung des ADSync müssen sie schon sauber arbeiten. So bleibt dann die Gruppe mit dem letzten Stand aus dem lokalen AD im AzureAD erhalten.

Ich habe noch keine Versuche angestellt, die Gruppe im lokalen AD zu löschen oder auszuschließen und vor im Metaverse und Connectorspace das Objekt so zu löschen, das es keinen Export der Löschung ins AzureAD gibt. Das wäre auch nicht hilfreich, wenn die Gruppe im AzureAD dann weiter als "DirSynced" gegen Veränderungen geschützt wäre

Groupmember Management

Nehmen wir an, dass Sie weiterhin die Mitgliedschaften von Gruppen direkt in Exchange Online verwalten wollen. Dazu gibt es im Dezember 2023 neben dem Weg über Outlook sogar zwei URLs:

Das Problem der per ADSync verwalteten Gruppen ist, dass Sie diese selbst als Besitzer nicht verwalten können. Das geht nur mit Cloud-Only-Gruppen.

Gruppenkaskade

Nun könnten sie ja auf folgende Konstruktion kommen:

AD (hidden) Gruppe -> ADSync -> EXOGruppe (Hidden) -> Mitglied in EXOOnly-Gruppe
  • Lokale AD-Gruppe (ohne Exchange Funktion)
    Sie legen eine Gruppe im lokalen AD an, in welche Sie Mitglieder addieren. Allerdings wird diese Gruppe nicht für Exchange aktiviert, denn Sie kann ja nicht durch einen Cloud-Anwender verwaltet werden
  • ADSync verwaltet den Zwilling
    ADSync repliziert diese Gruppe mit ihren Mitgliedern ins AzureAD.
  • Cloud-Only Mailenabled Security Group
    Der Administrator legt in Exchange Online/AzureAD nun eine ganz normale mailaktiviert Sicherheitsgruppe an. Diese Gruppe kann von dem Besitzer der Gruppe wie erwartet verwaltet werden. Als Vorarbeit addieren wird aber die per ADSync replizierte Gruppe in diese CloudOnly-Gruppe

Nu haben Sie eigentliche beide Funktionen erreicht: Sie können die Mitgliedschaft der Gruppe im lokalen AD verwalten und mit der CloudOnly-Gruppe können Sie zusätzlich auch Gäste und anderen CloudOnly-Konten mit addieren. Eine Mail an die Cloud-Only-Gruppe wird an alle Personen zugestellt.

Was auf den ersten Blick wie eine pfiffige Lösung aussieht, ist letztlich eine schwer zu verwaltende Verkettung von Gruppen, von der ich ganz deutlich abrate

CloudOnly-Gruppen

Wenn Sie wirklich Verteiler in der Cloud native verwalten wollen, dann sollten sie allein zur Vereinfachung diese auch wirklich nur dort verwalten. Wer bisher Exchange OnPremises genutzt hat und seine Migration nach Exchange Online quasi abgeschlossen hat und den LES - Last Exchange Server sogar schon durch die nur noch die Exchange Management Rolle abgelöst hat, wird sich kaum noch mit M365Groups Writeback oder ADSync für Verteiler herumschlagen wollen. Ihre Lösung könnte wie folgt aussehen, wenn Sie die lokalen AD-Gruppen für keine anderen Einsatzzweck mehr benötigen

  • Export der lokalen Verteilergruppen
    Zuerst können Sie von den lokalen Verteilergruppen die relevanten Felder exportieren. Dazu zählt neben dem Gruppennamen und ihrer Mailadressen (ProxyAddresses) auch die Liste der Mitglieder und der LegacyExchangeDN. Wenn Sie noch etwas weiter gehen wollen, dann könnten Sie versuchen die ACLs nach diesen Gruppen zu durchforsten
  • ADSync Ausschluss
    Wenn Sie die lokalen Gruppen nicht sofort löschen wollen, dann können Sie diese aber zumindest schon bei ADSync ausschließen, z.B. indem Sie diese in eine nicht replizierte OU verschieben. Beim nächsten ADSync-Lauf werden diese Gruppen natürlich in Exchange Online gelöscht Sie sind einige Minuten nun nicht mehr erreichbar oder sichtbar
  • Exchange Online Gruppen Anlegen
    Da nun auch die Mailadressen frei geworden sind, können Sie die Gruppen in Exchange Online als "CloudOnly Mailenabled Securitygroup" über die Exchange Online PowerShell anlegen und mit allen Eigenschaften versehen. Denken Sie z.B. auch an den alten LegacyExchangeDN und X.500. Sollten die bisherigen Gruppen für Berechtigungen auf SharedMailbox o.ä. genutzt worden sie, müssen Sie diese nun natürlich weiterführen.

Am Ende sieht das Bild dann wie folgt aus:

Ehe Sie nun eigene Skripte starten, möchte ich Sie auf ein Projekt von Timothy McMichael hinweisen, welches mittlerweile als Version 2.0 vorliegt.

Die Funktion des Skripte hat der Autor in 39! Episoden aufgeteilt. Ich würde aber zuerst mit dem Video der Folge 36 anfangen

Planning Distribution List Migrations to Office 365
https://www.youtube.com/watch?v=nfeStYRUg1U

  • Part 1: Introduction to the Distribution List Migration Module version 2.0
  • Part 2: Preparing to use the distribution list migration v2 module.
  • Part 3: Using the distribution list migration module v2 for simple migrations.
  • Part 4: Retaining the original distribution group post migration…
  • Part 5: Gathering advanced dependencies for a group to be migrated.
  • Part 6: How does the module track distribution lists that have been migrated?
  • Part 7: Enabling hybrid mail for for migrated distribution lists.
  • Part 8: Performance updates and enhancements.
  • Part 9: Introducing multiple distribution list migrations / batch migrations.
  • Part 10: Additional code improvements…
  • Part 11: Improvements in error handling in version 2.4.8.x
  • Part 12: Announcing multiple migration machine support.
  • Part 13: Enabling support for partially mail enable distribution groups.
  • Part 14: Enabling hybrid mail flow post migration.
  • Part 15: Enabling migration support for non-synchronized groups.
  • Part 16: Mail flow issues with centralized mail transport enabled and migrated distribution groups.
  • Part 17: I need assistance with the migration module, have a suggestion, or want to request a feature.
  • Part 18: New handling of recipient restrictions assigned to the migrated distribution groups.
  • Part 19: New handling of distribution group creation during migration to eliminate ambiguous references.
  • Part 20: Adding a new method to verify the distribution list is directory synchronized.
  • Part 21: Preparing for the deprecation and disablement of basic authentication.
  • Part 22: The end of basic authentication in Exchange Online…
  • Part 23: Collecting telemetry for performance improvements and usage statistics.
  • Part 24: Issues encountered with large distribution list migrations.
  • Part 25: Large distribution list migrations and code enhancements to increase performance and reliability.
  • Part 26: New handling of nested distribution groups in multiple distribution group migrations.
  • Part 27: Increasing the performance of multiple distribution list migrations.
  • Part 28: Implementing exception codes.
  • Part 29: Implementing the ability to migrated directly from on-premises distribution lists to Office 365 Unified Groups
  • Part 30: Converting a cloud only distribution list to an Office 365 Unified Group
  • Part 31: Enabling support for interactive authentication and single list migrations
  • Part 32: Enabling support for a custom routing domain
  • Part 33: Testing a distribution list pre-migration
  • Part 34: *IMPORTANT* Preparing for MS Graph Implementations
  • Part 35: Improved handling for mailbox folder permissions, full mailbox access permissions, and send as permissions.
  • Part 36: YouTube Tutorial – Introduction to Distribution List Migration 2.0 Module
  • Part 37: YouTube Tutorial – Planning distribution list migrations with the Distribution List Migration 2.0 Module
  • Part 38:Enabling support for migrations with a pre-defined name prefix or suffix.
  • Part 39 Implementing improved error handling and error cleanup.

Letztlich ist es ein sehr umfangreiches PowerShell-Script, welches

PowerShell Gallery – DLConversionV2
https://www.powershellgallery.com/packages/DLConversionV2/
https://github.com/timmcmic/DLConversionV2

Beachten Sie, dass dieser Wechsel erst sinnvoll funktioniert, wenn es keine lokalen Exchange Server mehr gibt, die Mailrouting machen und dazu das Wissen um die Verteiler und deren Mitglieder benötigen. Mit der Umstellung sind die lokalen Gruppen nicht mehr MailEnabled.

M365Groups Writeback

Nachdem wir die Verwaltung aller Exchange-Verteiler in die Cloud verschoben haben und die früheren lokalen Verteiler keine Exchange-Funktion mehr haben, können Sie die lokalen Gruppen natürlich weiter nutzen. Sie sollten allerdings NIE von ADSync gesehen und repliziert werden oder zumindest muss das Feld "mail" leer sein, damit kein Matching erfolgt.

Nun kann es aber natürlich doch noch System geben, die Informationen über die Exchange Empfänger und Verteiler benötigen. Die Benutzer sind im lokalen AD ja weiterhin als "RemoteMailbox" verwaltet und durch ADSync in die Cloud repliziert. Das können Sie auch nicht ablösen, wenn Sie z.B. mit Pass Through Authentifizierung (PTA) oder Password Hash Sync (PHS) arbeiten.

Aber ADSync kann Gruppen in der Cloud über die Funktion M365Groups Writeback als eine Art "Kontakt" im lokalen AD anlegen.

Damit können auch andere Prozesse z.B. per LDAP-Abfragen diese Adressen auflösen. Sie müssen dann die Mails nur weiter an einen lokalen Server oder direkt zu Exchange Online senden. Die Verwaltung der Gruppe und die Mitglieder erfolgt natürlich weiter komplett in Exchange Online und da es keine verbundene lokale AD-Gruppe gibt, können Sie die in der Cloud verwalteten Gruppen auch nicht im lokalen AD zur Vergabe von Berechtigungen nutzen.

Gruppensync zurück

Einen anderen Weg möchte ich ihnen aber auch vorstellen, auch wenn es dazu keine Lösungen von Microsoft gibt. Es hindert sie ja niemand daran, an ADSync vorbei mit einem eigenen Skripte z.B. die Gruppen der Cloud samt ihren Mitgliedern über MSGraph oder die AzureAD PowerShell auszulesen und entweder eine ganz neue Gruppe oder sogar die von früher noch bestehende Sicherheitsgruppe anhand der Cloud-Daten zu aktualisieren.

Wobei hier dann natürlich zu definieren wäre, welche Properties tatsächlich aus der Cloud in das lokale Active Directory übertragen werden müssen und wie mit Konflikten umgegangen wird. Das lokale Objekt kann ja durchaus von einem Administrator verwaltet werden.

Diese so lokal anhand der Cloud verwalteten Gruppen dürfen natürlich nie nie nie durch ADSync wieder in die Cloud zurückrepliziert werden. Wenn die lokalen Gruppen nämlich in dem Zuge auch das Feld "Mail" bekommen, würde dann sofort ein ADSync - Gruppen match erfolgen und ihre CloudOnly-Gruppen stehen wieder am Anfang.

Technisch sollte das mit folgenden Commandlets und einer App Registration sehr schnell umsetzbar sein.

Für den Abgleich von Gruppen zwischen verschiedenen Verzeichnissen habe ich schon früher entsprechende Skripte bereitgestellt:

Allerdings habe ich noch kein Skript, welches dazu z.B.: die Exchange PowerShell oder Microsoft Graph nutzt. Da die Import-Routine aber eh pro Gruppe nur eine Textdatei mit den Mitgliedern liest, ist es kein großer Aufwand auch noch eine Liste der Gruppen mit den gewünschten Properties per Graph oder Exchange Online PowerShell aus dem Tenant auszulesen und entsprechend lokale Gruppen zu verwalten.

Sie kommen damit immer weiter in das Gebiet eines Verzeichnisabgleichs, Provisioning und Identity Management mit vielen Fallstricken
 Wenn Sie nur wenig Erfahrung mit solchen Aufgabenstellungen haben, dann sollten Sie fachkundige Hilfe suchen.

Zwischenstand

Solange ADSync die Verteiler in Exchange Online blockiert, können Sie die Verteiler nur über das lokale AD mit Mitgliedern aus dem lokalen AD verwalten. Wenn Sie Verteiler in der Cloud verwalten wollen, dann müssen es "CloudOnly"-Verteiler sein. Mit den Werkzeugen von Tim McMichael gibt ein Werkzeug, um diese Umstellung mit etwas Planung ganz gut durchzuführen. Sie sollten damit aber nicht am Anfang ihrer Exchange Migration anfangen, wenn noch Postfächer oder Mailrouting auf Exchange OnPremises genutzt werden, sondern erst wenn alle Empfänger und idealerweise auch das Mailrouting direkt in Exchange Online erfolgt.

Weitere Links