Office 365 – Distribution List Migration Version 2.0 – Part 19

New handling of distribution group creation during migration to eliminate ambiguous references.

On occasion recipients in Office 365 may share the same attributes even though they reference different objects. For example, it is possible to have multiple distribution lists where the names are different but the aliases assigned are the same.

 

PS C:\Users\timmcmic> Set-DistributionGroup “Blog Post Test” -Alias BlogPostTest

PS C:\Users\timmcmic> Set-DistributionGroup “Blog Post Test 2” -Alias BlogPostTest

PS C:\Users\timmcmic> Get-DistributionGroup BlogPostTest

 

Name DisplayName GroupType PrimarySmtpAddress

—- ———– ——— ——————

Blog Post Test Blog Post Test Universal BlogPostTest@domain.onmicrosoft.com

Blog Post Test 2 Blog Post Test 2 Universal BlogPostTest2@domain.onmicrosoft.com

 

In the previous example there are two distinct groups that share the same alias. Typically, the alias would be defined based on name and administratively controlled. As the adoption of Office 365 groups and Microsoft Teams increases so does the self-service creation of these recipient objects. This may inadvertently create alias overlap between new and existing objects. In some cases, it also results in the failure of recipient commandlets that gather information on these objects.

 

PS C:\Users\timmcmic> Set-UnifiedGroup “Blog Post Test Unified” -Alias BlogPostTest

PS C:\Users\timmcmic> Get-DistributionGroup BlogPostTest

The current operation is not supported on GroupMailbox.

+ CategoryInfo : NotSpecified: (BlogPostTest:String) [Get-DistributionGroup], RecipientTaskException

+ FullyQualifiedErrorId : [Server=BN8PR04MB6356,RequestId=ad99972d-51df-4eb1-980f-a8513bbc7817,TimeStamp=3/28/2022

3:01:32 AM] [FailureCategory=Cmdlet-RecipientTaskException] 1A51386,Microsoft.Exchange.Management.RecipientTasks.

GetDistributionGroup

+ PSComputerName : outlook.office365.com

 

This created some unique issues in distribution group migrations. Once the distribution group deletion was detected the script automatically creates the new group in Office 365. Originally the group was created with the same name as the migrated group. To ensure the success of future commands the alias of the group was utilized as this was assumed to be unique. As evident in the previous examples this is not guaranteed to be unique and may lead to ambiguous references as to which object we are attempting to manage and modify. Originally the only way to satisfy the migration was to eliminate the object collisions by changing the groups name, alias, or other attribute causing an ambiguous return.

 

DLConversionV2 has subsequently been modified to handle these scenarios. Once the DL deletion is detected the new distribution group is created by returning to the calling code as an object. When assigning a create operation to a variable, the attributes resulting from the objects creation are stored within the variable. This is very important as it gives us access to attributes that ensure a unique reference for future operations. In this instance the new groups external directory object ID is now known. The external directory object ID is the GUID of the mirrored group object created in Azure Active Directory. Set and get commands will accept the external directory object ID as a named reference since it is unique across both Azure Active Directory and Exchange Online. The example below shows groups that possess the same alias but unique external directory object ids.

 

PS C:\Users\timmcmic> Get-DistributionGroup BlogPostTest | fl alias,externalDirectoryObjectID

 

 

Alias : BlogPostTest

ExternalDirectoryObjectId : beea5779-64ed-4f78-8845-54ad8082594a

 

Alias : BlogPostTest

ExternalDirectoryObjectId : 7229fdb0-6ac2-4091-b129-4995c432b1fd

 

The new group created initial name is a combination of a file date time and random number. This ensures a unique name in bulk migration scenarios. Once the group creation is successfully confirmed the subsequent set operations will rename this temporary group to match the on-premises groups. The set operations are no longer passed an alias or primary SMTP address but rather the external directory object ID of the group created for migration. This ensures that a unique object is found, and all subsequent operations performed on that object. In the log you may see references to group smtp address that have a GUID instead of an actual SMTP address.

 

Using specific references increases the occurrence of successful migrations by eliminating ambiguity in the migration process. Happy migrating!