Offering a new alternative for nested group migrations…
Distribution lists offer administrators the opportunity to nest within each other. As a part of distribution list migrations all child groups must be migrated prior to the parent group being migrated.
In the case of a single migration, if the parent is selected for migration and contains children, the migration will fail and the logs will indicate that a child group was found and must be migrated first.
In the case of multiple migrations, if the parent is attempted first before a child for migration, the parent will be scheduled for retry. After a migration pass has been attempted against each group, the parent distribution lists are retried if the child was included in the migration batch.
I recently had a customer that presented an interesting scenario. They have a parent distribution list that contains multiple children. The children lists membership is managed by another product that only has on-premises integration. In this customer instance they desired to migrate the parent distribution list but retain the children on premises. The child distribution lists would continue to be managed through their third party system. Both the parent and child distribution lists were synchronized to Office 365 and available in Exchange Online.
They proposed a solution where they would remove the children distribution lists and then migrate the parent. Post migration, in Exchange Online, they would add the children distribution lists back as members. This is not blocked, synchronized distribution lists can be added as members of a cloud only distribution group.
This obviously is a manual process and could lead to things being missed. Plus, what fun is a manual process when we could easily code a solution to support it 🙂
In version 2.9.8.24 a new switch has been introduced to SINGLE distribution list migrations. The switch is not available in multiple or multiple machine migrations. The switch is “-skipNestedGroupCheck”. When this switch is specified as a part of a migration if a mail enabled child group is found as a member of the distribution list to be migrated the migration is allowed to proceed. Instead of logging an error the mail enabled child distribution list is added as a valid recipient and as long as the recipient can be located in Office 365 the migration will proceed. At the end of the migration the synchronized child distribution lists are added as members of the migrated cloud distribution lists.
At the conclusion of the migration the mail disabled group remains on premises. The membership of the mail disabled group remains the same. If at a later time a child distribution list is migrated the module already supports reviewing all cloud only distribution groups for membership. This group will be found as a member of the previously migrated group and the group membership should be retained.
Are there any mail flow considerations when doing this? The answer is yes! If you are not utilizing the -enableHybridMailFlow switch on premises Exchange Servers will continue to receive email at all child distribution lists. The parent distribution lists address will no longer be available on premises, therefore any email that relied on the expansion of the parent distribution list would fail.
If -enableHybridMailFlow is utilized the following mail flow route ensures that all group, including the non-migrated child distribution lists, receive the message.
- The email is received by the on premises Exchange Server (parent@contoso.com).
- Parent@contoso.com resolves to the dynamic distribution list created by -enableHybridMailFlow.
- Dynamic distribution list expansion occurs and resolves to the single mail contact parent-migratedByScript@contoso.com
- The mail contact parent-migratedByScript@contoso.com has a target address parent@contoso.mail.onmicrosoft.com. This address is resolved.
- Mail flows through the hybrid connector and arrives in Office 365.
- Parent@contoso.mail.onmicrosoft.com resolves to the migrated distribution list parent@contoso.com.
- The migrated distribution list parent@contoso.com is expanded and includes child distribution lists.
- The child distribution lists are now expanded.
I hope this new switch adds some additional flexibility and opens new scenarios for migration!
TIMMCMIC 