Office 365 – Distribution List Migrations 2.0 – Part 33

14 Replies

Testing a distribution list for pre-migrations…

When migrating distribution lists to Office 365 there is a series of health checks performed to ensure that the migration will be successful. Through the enumeration and normalization process each recipient that appears on the property of the distribution list is tested for presence in Office 365.

 

Prior to version 2.9.6.6 the only way to predict success or failure of the migration was to attempt and perform the migration. If the group contained a nested distribution list, a member of a property was not present, or the group was not directory synchronized the migration would fail and allow the administrator to review the logs. At the end of each migration is a failure table with exception codes that allow administrators to analyze the failure and take actions.

 

Version 2.9.6.6 introduces several test functions to offer administrators the opportunity to test pre-requisites before performing a migration. These commands include Test-PreMigration, Test-PreMigrationO365Group, and Test-PreO365GroupConversion. Each of the test commandlets performs the tests based on the type of migration that will be performed.

 

TEST-PREMIGRATION

This commandlet allows the administrator to test a standard on-premises to Office 365 distribution list migration.

 

Test-PreMigration -groupSMTPAddress atestgroup178@domain.com -globalCatalogServer azure-dc-0.home.domain.com -activeDirectoryCredential $cred -activeDirectoryAuthenticationMethod kerberos -exchangeOnlineCredential $cred -azureADCredential $cred -logFolderPath c:\temp

 

In this instance the group failed the test, and the folder was renamed to reflect failure.

 

[2/21/2023 7:11:46 PM] – FAILED – renaming directory.

[2/21/2023 7:11:46 PM] – PreReqTest-20230221T1911466009-atestgroup178-FAILED

[2/21/2023 7:11:46 PM] – c:\temp\PreReqCheck\

 

When reviewing the failure table contained at the end of the log file the following is noted.

 

[2/21/2023 7:11:45 PM] – +++++

[2/21/2023 7:11:45 PM] – Pre-requist checks failed. Please refer to the following list of items that require addressing for migration to proceed.

[2/21/2023 7:11:45 PM] – +++++

[2/21/2023 7:11:45 PM] –

[2/21/2023 7:11:45 PM] – =====

[2/21/2023 7:11:45 PM] – Alias: domainAdmin

[2/21/2023 7:11:45 PM] – Name: domainAdmin

[2/21/2023 7:11:45 PM] – PrimarySMTPAddressOrUPN: domainAdmin@domain.com

[2/21/2023 7:11:45 PM] – RecipientType: user

[2/21/2023 7:11:45 PM] – GroupType:

[2/21/2023 7:11:45 PM] – RecipientOrUser: Recipient

[2/21/2023 7:11:45 PM] – ExternalDirectoryObjectID:

[2/21/2023 7:11:45 PM] – OnPremADAttribute: managedBy

[2/21/2023 7:11:45 PM] – DN: CN=domainAdmin,CN=Users,DC=home,DC=domain,DC=com

[2/21/2023 7:11:45 PM] – ParentGroupSMTPAddress: atestgroup178@domain.com

[2/21/2023 7:11:45 PM] – isAlreadyMigrated: False

[2/21/2023 7:11:45 PM] – isError: True

[2/21/2023 7:11:45 PM] – isErrorMessage: OFFICE_365_DEPENDENCY_NOT_FOUND_EXCEPTION: A group dependency was not found in Office 365. Please either ensure the dependency is present or remove the dependency from the group.

[2/21/2023 7:11:45 PM] – =====

[2/21/2023 7:11:45 PM] – Pre-requiste checks failed. Please refer to the previous list of items that require addressing for migration to proceed.

 

In this instance the managedBy attribute has a manager that is not present in Office 365. This creates a property that cannot be recreated in the service.

 

TEST-PREMIGRATIONO365GROUP

When migrating from an on premises group to an Office 365 group there are different sets of properties to test for. This commandlet allows administrators to test for pre-requisits associated specifically with an on-premises to Office 365 group migration.

 

Test-PreMigrationO365Group -groupSMTPAddress atestgroup178@domain.com -globalCatalogServer azure-dc-0.home.domain.com -activeDirectoryCredential $cred -activeDirectoryAuthenticationMethod kerberos -exchangeOnlineCredential $cred -azureADCredential $cred -logFolderPath c:\temp

 

In this instance the group failed the test, and the folder was renamed to reflect failure.

 

[2/21/2023 7:39:02 PM] – FAILED – renaming directory.

[2/21/2023 7:39:02 PM] – PreReqTest-20230221T1939022343-atestgroup178-FAILED

[2/21/2023 7:39:02 PM] – c:\temp\PreReqCheck\

 

When reviewing the failure table at the end of the log file the following errors are noted.

 

[2/21/2023 7:39:01 PM] – +++++

[2/21/2023 7:39:01 PM] – Pre-request checks failed. Please refer to the following list of items that require addressing for migration to proceed.

[2/21/2023 7:39:01 PM] – +++++

[2/21/2023 7:39:01 PM] –

[2/21/2023 7:39:01 PM] – =====

[2/21/2023 7:39:01 PM] – Alias: aTestGroup178

[2/21/2023 7:39:01 PM] – Name: aTestGroup178

[2/21/2023 7:39:01 PM] – PrimarySMTPAddressOrUPN: aTestGroup178@domain.com

[2/21/2023 7:39:01 PM] – RecipientType: group

[2/21/2023 7:39:01 PM] – GroupType: -2147483640

[2/21/2023 7:39:01 PM] – RecipientOrUser: Recipient

[2/21/2023 7:39:01 PM] – ExternalDirectoryObjectID:

[2/21/2023 7:39:01 PM] – OnPremADAttribute: SecurityGroupCheck

[2/21/2023 7:39:01 PM] – DN: CN=aTestGroup178,OU=MigrationTest,OU=DLConversion,DC=home,DC=domain,DC=com

[2/21/2023 7:39:01 PM] – ParentGroupSMTPAddress: atestgroup178@domain.com

[2/21/2023 7:39:01 PM] – isAlreadyMigrated: N/A

[2/21/2023 7:39:01 PM] – isError: True

[2/21/2023 7:39:01 PM] – isErrorMessage: UNIFIED_GROUP_MIGRATION_GROUP_IS_SECURITY_EXCEPTION: To perform an Office 365 Unified Group migration of a mail-enabled security group on premsies the administrator must use -overrideSecurityGroupCheck acknolwedging that permissions may be lost in Office 365 as a result of the migration.

[2/21/2023 7:39:01 PM] – =====

[2/21/2023 7:39:01 PM] – =====

[2/21/2023 7:39:01 PM] – Alias: domainAdmin

[2/21/2023 7:39:01 PM] – Name: domainAdmin

[2/21/2023 7:39:01 PM] – PrimarySMTPAddressOrUPN: domainAdmin@domain.com

[2/21/2023 7:39:01 PM] – RecipientType: user

[2/21/2023 7:39:01 PM] – GroupType:

[2/21/2023 7:39:01 PM] – RecipientOrUser: Recipient

[2/21/2023 7:39:01 PM] – ExternalDirectoryObjectID:

[2/21/2023 7:39:01 PM] – OnPremADAttribute: managedBy

[2/21/2023 7:39:01 PM] – DN: CN=domainAdmin,CN=Users,DC=home,DC=domain,DC=com

[2/21/2023 7:39:01 PM] – ParentGroupSMTPAddress: atestgroup178@domain.com

[2/21/2023 7:39:01 PM] – isAlreadyMigrated: False

[2/21/2023 7:39:01 PM] – isError: True

[2/21/2023 7:39:01 PM] – isErrorMessage: UNIFIED_GROUP_MIGRATION_MANAGER_NOT_MEMBER_EXCEPTION: Office 365 Groups require all owners to be members. ManagedBY is mapped to owners – this manager is not a member of the group. The manage must be removed, use the switch -addManagersAsMembers to add all managers, or manually add this manager as a member.

[2/21/2023 7:39:01 PM] – =====

[2/21/2023 7:39:01 PM] – =====

[2/21/2023 7:39:01 PM] – Alias: Tim

[2/21/2023 7:39:01 PM] – Name: Tim McMichael

[2/21/2023 7:39:01 PM] – PrimarySMTPAddressOrUPN: Tim@domain.com

[2/21/2023 7:39:01 PM] – RecipientType: user

[2/21/2023 7:39:01 PM] – GroupType:

[2/21/2023 7:39:01 PM] – RecipientOrUser: Recipient

[2/21/2023 7:39:01 PM] – ExternalDirectoryObjectID:User_6004ad19-6c4c-4ea5-83a2-7d10afc5e3a1

[2/21/2023 7:39:01 PM] – OnPremADAttribute: msExchBypassModerationLink

[2/21/2023 7:39:01 PM] – DN: CN=Tim McMichael,OU=Users,OU=domain Objects,DC=home,DC=domain,DC=com

[2/21/2023 7:39:01 PM] – ParentGroupSMTPAddress: atestgroup178@domain.com

[2/21/2023 7:39:01 PM] – isAlreadyMigrated: False

[2/21/2023 7:39:01 PM] – isError: True

[2/21/2023 7:39:01 PM] – isErrorMessage: UNIFIED_GROUP_MIGRATION_BYPASS_MODERATION_FROM_SENDERS_OR_MEMBERS_EXCEPTION: Office 365 Unified Groups do not have BypassModerationFromSendersOrMembers. To migrate to an Office 365 Unified Group the bypass moderation from senders or members must be cleared.

[2/21/2023 7:39:01 PM] – =====

 

In this instance the tests failed, indicating three different exceptions that apply only to Office 365 Group migrations. The first being the source group is a security group, the second that the manager is not a member, and lastly the group has BypassModerationFromSendersOrMembers rights. These are all issues that would prevent successful migration from on-premises to Office 365 Group.

 

TEST-PREO365GROUPCONVERSION

This test allows the administrator to test the pre-requisites associated with converting a cloud only distribution group to an Office 365 Group. As with migrations from on-premises groups the conversion process tests for the same requirements that the on-premises migration has. This allows administrators to predict the success or failure of a group conversion.

 

test-preO365GroupConversion -groupSMTPAddress zCloudOnlyMemberOfMailDistribution41@domain.com -exchangeOnlineCredential $cred -azureADCredential $cred -logFolderPath c:\temp -addManagersAsMembers:$TRUE

 

In this instance there are no pre-requisites that would not allow the conversion to succeed.

 

[2/21/2023 7:53:51 PM] – Success – renaming directory.

[2/21/2023 7:53:51 PM] – PreReqTest-20230221T1953517076-zCloudOnlyMemberOfMailDistribution41-Success

[2/21/2023 7:53:51 PM] – c:\temp\PreReqCheck\

 

The test commandlets allow administrators to run pre-requisite checks and test for the probability of migration success or failure without actually running the migration process.

14 thoughts on “Office 365 – Distribution List Migrations 2.0 – Part 33”

  1. Pingback: Office 365 – Distribution List Migration – Version 2.0 | TIMMCMIC

  2. Taranjeet Singh

    Hi Timmcmic

    Does the Test Migration command (TEST-PREMIGRATION) allows testing multiple DLs at once? Something like this:

    Test-Premigration -groupSMTPAddresses $group

    Like

    Reply ↓
    1. TIMMCMIC Post author

      I’m not sure what you’re specifically asking so if this does not answer just follow up.

      For the test-pre migration you’ll need your domain credential, graph, and exchange online credentials.

      It simply does all the discover up front and then goes through and does the health checking of the on premises settings verses Office 365. If anything is found out of alignment it fails. It’s the same as if you went ahead and migrated it – if anyt of these fail the migration fails. It just doesn’t proceed with the migration if everything is ok.

      Timmcmic

      Like

      Reply ↓
  7. write2tsm

    One last question (if you don’t mind pls.). Is there a possibility to have the DLs renamed (according to a new naming scheme) when these are recreated in cloud (M365)? Does the DL Conversion tool allows something like that?

    Thanks

    Like

    Reply ↓
    1. TIMMCMIC Post author

      @write2tsm

      Azure has a group nameing convention that you can establish – but if memory serves that’s only for the modern / unified / m365 group. With that being said if the DL is simply you can migrate it from a standard DL on premsies directly to an M365 group – in which case I believe the naming convention would apply.

      If this is a standard DL your best bet is to write a wrapper script around the dlconversion tool and have the migration performed and then a rename done to whatever you want post migration. The tool itself though will not allow that.

      If i may ask – what’s the use case here. You want all the DLs migrated to be prepended with a specific name or characters or something? I ask because if there’s value in it to others it’s a potential feature we could look at.

      TIMMCMIC

      Like

      Reply ↓
  8. write2tsm

    Sure, happy to share the use case. There wasn’t any strict naming standard and the existing DLs (on-prem) evolved with all sorts of different names. As part of the big change (conversion to cloud), we want the DL names to follow a standard, yet keep them familiar to users, so we are renaming them to something like this:

    DL-

    Thanks

    Like

    Reply ↓
    1. TIMMCMIC Post author

      @write2tsm…

      Version 2.9.8.14 now supports prefix and suffix using the -dlNameSuffix and -dlNamePrefix. As it stands now the code will validate that the existing name plus prefix and suffix combinations do not exceed 64 characters (the max limit for name) and post migration will automatically set name and display name to be the original name plus the prefix and suffix. Note that if the display name is different from the actual name both will get the prefix and suffix in this version.

      Like

      Reply ↓
  9. write2tsm

    Wonderful and thanks once again. Sorry, I noted that my previous comments missed the complete DL naming format. What we expect in the new DLs (when recreated in cloud):

    new DL naming: DL-existingDLname

    Some DLs start with an _ character that we wish to replace with – character. Is this possible with Version 2.9.8.14?

    If yes, is there any supporting documentation on how to use it.

    Like

    Reply ↓
    1. TIMMCMIC Post author

      So that one is probably not going to make the cut. I’ve had others inquire about naming conventions so adding the -dlNamePrefix and -dlNameSuffix seemed like an overall useful item to add. Its also low risk in testing. Modifying the strings to remove characters would be slightly more costly. I think what I would probably recommend doing if you’re users are in the cloud anyway is running a pre-migration script to remove the _ from the name and / or displayName and then use the -dlNamePrefix swtich in the new version to add DL-

      Timmcmic

      Liked by 1 person

      Reply ↓

Leave a comment