In the Office 365 Portal administrators have the ability to mange, deploy, and remove published applications for their clients. This is achieved through the integrated applications management pane of the Office 365 Admin Portal. Information regarding integrated applications maybe found here Deploy add-ins in the admin center – Microsoft 365 admin | Microsoft Learn.

 

When using the Office 365 Admin Portal and selecting integrated applications some administrator are presented with a warning in the portal. The warning indicates “Something went wrong” and includes a GUID. When this happens please ensure the following settings are in place.

 

1. Go to Azure Portal. Choose “Azure Active Directory” under Azure Services.
   
2. In Azure Active Directory portal, choose Manage > Enterprise Applications.
   
3. Select “Microsoft Applications” under Application Type and click Apply.
   
4. Search application id ‘0517ffae-825d-4aff-999e-3f2336b8a20a’ in search bar. You should see the application name – M365 App Management Service. Select M365 App Management Service.
   
5. Choose Manage > Properties > Enabled for users to sign-in?. Click on “Yes” and Save.
   

 

With the M365 App Management Service enabled administrators should now have access to the integrated applications experience in the Office 365 Admin portal.

Organizations may configure conditional access policies that evaluate if users are at risk when accessing resources hosted in Office 365. There are a variety of risks that can be assigned to users that may impact their ability to access resources.

 

For information regarding risk assignment and detection see What is risk? Azure AD Identity Protection – Microsoft Entra | Microsoft Learn.

 

For information regarding conditional access application to risk see Sign-in risk-based multifactor authentication – Azure Active Directory – Microsoft Entra | Microsoft Learn.

 

When risk has been identified on a user and conditional access applied this may result in the user being blocked. Users may receive a message during the authentication process stating

“We’ve detected suspicious activity on your account. Sorry, the organization you are trying to access restricts at-risk users. Please contact your …”

 

When users receive this message there is also an associated entry in the Azure Sign In Logs that shows the sign on failure and that risk was the reason the sign on was blocked. It’s important to note that risk application can either be in the tenant where the user resides or when the user is accessing resources in another tenant based on a guest invitation.

 

I’ve recently worked some investigations where users were being blocked from signing into guest tenants. When reviewing the Azure sign in logs of the home tenant we were able to validate that the block occurred in the home tenant due to risk being assigned. What we were not able to do was locate this user as a risky user. The tenant that hosted the account did not have conditional access policies that evaluated risk only the tenant hosting the guest resource was evaluating risk. There are several options to remediate risk assigned to a user one of them being administrator dismissal of risk. Unfortunately, that was not possible because the user was not showing as having any risk assigned in the Azure portal. (For information on remediating risk see Remediate risks and unblock users in Azure AD Identity Protection – Microsoft Entra | Microsoft Learn)

 

Why was a user blocked for risk yet not showing as a risky user? As we continued our investigation, we discovered that the risk that was assigned to the user was assigned in December of 2020. As there were no conditional access policies previously evaluating risk there was never an identification of risk. As risk continued to develop in Azure there were essentially two risk platforms. For simplicity I’ll refer to it as V1 risk and V2 risk. The current risk platform is the V2 risk platform. Users that are assigned risk detections today are assigned under the V2 platform and our management tools display this information. In this case the risk assigned to the user was assigned under the V1 platform and is not immediately discoverable in our tools. I will note that having V1 risk assigned to users is not something that is common but could happen and result in access denied to resources being assigned risk administrators cannot see.

 

How do you fix this? Fortunately, administrators have access to a set of tools for dismissing user risk via the Microsoft Graph API. The tools may be located here GitHub – AzureAD/IdentityProtectionTools: Sample PowerShell module and scripts for managing Azure AD Identity Protection service. The following instructions outline how to utilize the tools.

 

• Prepare MS Graph
  • Open powershell as administrator.
  • Execute install-module Microsoft.Graph.Authentication (this assumes that the full Microsoft.Graph module is not already installed)
  • Execute install-module Microsoft.Graph.Identity.SignIns (this assumes that the full Microsoft.Graph module is not already installed)
  • Execute install-module Microsoft.Graph.Users (this assumes that the full Microsoft.Graph module is not already installed)
  • Execute $scopes = @(“Identity.RiskyUser.ReadWrite.All”,”IdentityRiskyUser.Read.All”,”User.Read.All”)
  • Execute Connect-MGGraph -scopes $scopes
    • At this point you may be prompted to consent to this applications use and permissions.
    • It may be possible you do not have rights to do this and may have to have someone perform consent on your behalf.
    • This is required to establish the MSGraph permissions necessary to complete this work.
• Prepare the Identity Protection Module
  • Download the code zip file from the GitHub repository.
  • Expand the zip file to a folder.
  • Navigate to the extracted folder \ src \ modules \ IdentityProtectionTools with Powershell.
  • Run unblock-files * to remove any restrictions on downloaded Powershell files.
  • Run import-module IdentityProectionTools.psd1
• Revoke User Risk
  • In order to revoke user risk you must have the object IDs of the users to revoke. An example search via user principal name:
    • Get-MGUser -search ‘”UserPrincipalName:user@domain.com”‘ -consistencyLevel eventual
    • The ID column lists the object ID of the user.
  • Create an array of users to revoke risk.
    • $users = @()
    • $users += “ID1”
    • $users += “ID2”
    • If only a single user there is only a single add to the array creating an array of 1 users.
  • Revoke the risk assigned to the users.
    • Invoke-AzureADIPDismissRiskyUser -userIDs $users

This will perform a risk dismissal on one or more users. After dimissing risk the user should wait 30 minutes before attempting the sign on again. If the sign on is still unsuccessful due to risk assignment and the risk cannot be otherwise located or remediated in the Azure portal please open a case with support for assistance.

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.

Enabling support for a custom routing domain…

In an Office 365 installation the hybrid routing domain is provisioned when the tenant is initially created. The hybrid routing domain is what is utilized to secure mail flow from on premises installations to Office 365 in a co-existence scenario. The hybrid routing domain is typically mail.tenantName.onmicrosoft.com.

 

When migration distribution lists a contact object is always provisioned for each group migrated. The contact object has a target address utilizing the mail.tenantName.onmicrosoft.com email address either assigned to the migrated distribution list or created as a part of the migration. This is done to ensure that cross premises mail flow is secure using the standard security applied to the hybrid send connector. For information on hybrid mail flow please see the following article: Office 365 – Distribution List Migrations Version 2.0 – Part 7 | TIMMCMIC (wordpress.com)

 

It is possible that customers may have customized the domain that they use for hybrid routing. This was not necessarily uncommon in very early Office 365 tenants and those that may have been upgraded from legacy live.edu tenants. In some instances the mail.tenantName.onmicrosoft.com domain is not utilized on send connectors since there is a custom routing domain in place. This would mean that post distribution list migration emails from on-premises applications could use an internet route and messages may arrive as externally non-secured.

 

Version 2.9.6.6 of the DLConversionV2 module now supports the ability to specify a custom routing domain. The switch -customRoutingDomain is optional and available in both single, multiple, and multiple machine migrations. When the custom routing domain is specified the module will post migration look for the presence of this address in the SMTP proxy address list. If the address is not present an attempt to create the address using the alias of the distribution list and the custom routing domain is attempted. If the stamping of this address is successful, the migration will proceed. If an address collision is detected then a random prefix is generated and combined with the remote routing domain.

 

Once the remote address is determined the mail contact on-premises for the migrated distribution list will utilize this address as a target address. If all send connectors are properly configured mail that uses this custom routing domain and target address will arrive in Office 365 as trusted and secure.

 

Here is an example of implementing custom routing domains with a migration. To begin prior to migration this is the list of email addresses assigned to the group being migrated in Office 365.

 

PS C:\> Get-DistributionGroup atestgroup416 | fl *emailaddresses*

 

EmailAddresses : {SMTP:aTestGroup416@domain.com, smtp:aTestGroup416@domain.mail.onmicrosoft.com,

smtp:aTestGroup416@timmcmic.onmicrosoft.com, X500:/o=domain Home/ou=Exchange Administrative Group

(FYDIBOHF23SPDLT)/cn=Recipients/cn=4be6ea76f04b48f5bdfad29be341b41a-aTestGr}

 

In this migration our custom routing domain is domain.net. The command utilized to migrate the distribution group:

 

Start-DistributionListMigration -groupSMTPAddress atestgroup416@domain.com -globalCatalogServer azure-dc-0.home.domain.com -activeDirectoryCredential $cred -activeDirectoryAuthenticationMethod kerberos -aadConnectServer azure-dirsync-0.home.domain.com -aadConnectCredential $cred -aadConnectAuthenticationMethod kerberos -exchangeServer azure-mail-0.home.domain.com -exchangeCredential $cred -exchangeAuthenticationMethod kerberos -exchangeOnlineCredential $cred -azureADCredential $cred -logFolderPath c:\temp -dnNoSyncOU “OU=DoNotSync,OU=MigrationTest,OU=DLConversion,DC=home,DC=domain,DC=com” -enableHybridMailflow:$TRUE -customRoutingDomain “domain.net”

 

At the conclusion of the distribution list migration the list of email addresses on the migrated distribution group now includes an address @domain.net.

 

PS C:\> Get-DistributionGroup atestgroup416 | fl *emailaddresses*

 

EmailAddresses : {smtp:aTestGroup416@domain.net, X500:/o=domain Home/ou=Exchange Administrative Group

(FYDIBOHF23SPDLT)/cn=Recipients/cn=4be6ea76f04b48f5bdfad29be341b41a-aTestGr,

smtp:aTestGroup416@timmcmic.onmicrosoft.com, SMTP:aTestGroup416@domain.com…}

 

At the conclusion of the migration the mail contact on-premises is created. In this case the enableHybridMailFlow option was set to true which triggers the full mail enablement of this contact. The target address is set to match the secondary SMTP addressed added at the custom routing domain.

 

[PS] C:\>Get-MailContact atestgroup416-migratedbyscript | fl *address*

 

ExternalEmailAddress : SMTP:ATESTGROUP416@domain.NET

AddressListMembership : {}

EmailAddresses : {SMTP:aTestGroup416-MigratedByScript@domain.com}

HiddenFromAddressListsEnabled : True

EmailAddressPolicyEnabled : False

PrimarySmtpAddress : aTestGroup416-MigratedByScript@domain.com

WindowsEmailAddress : aTestGroup416-MigratedByScript@domain.com

 

This change is specific to environments that already have a custom routing domain defined for cross-premises mail flow in a hybrid environment. If you do not have a customized configuration the defaults should be utilized. In environments that have run the updated hybrid configuration wizard and have a custom routing domain the default routing domain of mail.tenantName.onmicrosoft.com should be on the appropriate send connector allow you to utilize defaults.

Enabling support for interactive credentials and single list migrations…

In previous version of the Distribution List Migration 2.0 module the ability to use interactive credentials that required MFA or other approvals was not available to administrators. The module always took credentials provided on the command line and attempted non-interactive authentication. If MFA or another provider intercepted this authentication the migration could not be performed. This often required administrators to either temporarily bypass MFA, use an account that did not require MFA, or utilize certificate based authentication for Exchange Online.

 

In version 2.9.6.6 the need to specify credentials on a single distribution list migration command has been made optional for cloud services. Credentials for Azure Active Directory Connect, Active Directory controllers, and Exchange on-premises installations are still required to be specified on the command line. When a distribution list migration occurs, and credentials are not specified on the command line the interactive authentication dialog is generated on the initial connection to Exchange Online.

 

 

At the completion of the initial interactive logon the administrator is prompted again to log into Azure Active Directory. At this time the interactive logon should display the account already signed in and the administrator should be able to select this account.

 

 

This will complete the interactive authentication flow and allow the migration to complete.

 

Will interactive authentication be supported with multiple distribution list migrations? No – at this time this will not be supported. In order to do multiple distribution list migrations Powershell jobs are utilized. When jobs are provisioned, they are provisioned without interaction. Customers leveraging multiple machine or list migrations will need to use specified credentials or certificate authentication.

 

It is my desire that this change will allow more administrators to test the functionality of the module without the need to request authorization to bypass conditional access.

In Azure Active Directory administrators have the ability to create accounts in two types. They can create user accounts that are members or guests. Typically when I am speaking with customers regarding guest accounts it is usually in the context of B2B invited guest accounts created directly in Office 365 or Azure Active Directory.

 

Guest accounts also serve a purpose in regard to conditional access. Administrators may configure conditional access policies to only require certain conditions be applied to accessing our cloud services when the user type is a guest. For example administrators may want to force MFA to be applied to guest and external accounts but not in other conditions. (Require MFA for guest users with Conditional Access – Azure Active Directory – Microsoft Entra | Microsoft Learn)

 

Guest accounts are no just limited to accounts created in our cloud services. Azure Active Directory Connect has the ability to provision the user type for synced accounts. In a default implementation the user type for all synchronized accounts to Azure Active Directory is Member. There could be certain circumstances where you would like a population of your synchronized accounts to appear as guests in Azure AD. This may be to simply filter out those users who might not have a direct relationship to your organization or for the purposes of applying different conditional access policies to synchronized accounts.

 

The implementation of guest accounts for synchronized objects require the implementation of custom synchronization rules. The rules modify the Azure AD attribute userType and submits the value Guest. This results in a guest user object being provisioned in Azure AD. The following article describes some scenarios and rule examples for creating guest accounts. (Azure AD Connect sync: Make a change to the default configuration – Microsoft Entra | Microsoft Learn)

 

I recently worked on an escalation with a customer where they were leveraging rules to provision guest accounts in Azure. What we were observing is that after the guest accounts were provisioned a validation error would result in the objects in Azure AD. This would essentially imply that there was a failure on the account where other services may have issues provisioning or using that account. Let’s examine a demonstration of this issue and how we resolved it.

 

In Azure Active Directory Connect a new rule was created to provision the accounts user type. The rule was given a name that made sense and outlined what the rule should accomplish. I also retained the cloned rules name so that it was apparent what the basis of the rule is for. (I highlight this not because it is required but after supporting many of these installations and attempting to reverse engineer what others were trying to accomplish the little things can be really helpful). The basis for this rule was the disabled rule In from AD – User Type.

 

 

The scoping filter is where we defined the objects where the rule should apply. In this instance we used an attribute that was already defined in the Azure AD Connect schema extensionAttribute1. If you use a custom attribute or an attribute that is not included in the default attribute sync set you may need to alter the attributes imported on the Active Directory connector. In this instance if extensionAttribute1 = GuestMail the user will be included in this rule.

 

 

The join rules will remain unmodified. The final settings are to define what attributes will be transformed. On the transformation tab we will statically define the attribute UserType with the value Guest.

 

 

In the customers environment accounts were being provisioned in the following manner.

• The account is created in the local active directory.
• The accounts have a valid user principal name registered in the Office 365 tenant.
• The mail address of the object was the users external email address.
• The necessary attributes to provision the account as a guest were set.

 

In this demonstration the user account is created in the same manner with extensionAttribute1 set to “GuestMail”.

 

 

 

 

To validate the successful application of this rule a metaverse search in the Azure AD Connect Synchronization Manager can be performed. The search demonstrates the calculated attributes and shows that user type is set to Guest.

 

 

At the completion of the synchronization cycle and subsequent export the user will be created in Azure AD. Using get-AzureADUser the attributes for this object can be reviewed.

 

Get-AzureADUser -SearchString BlogGuestTest | fl objectType,DirSyncEnabled,DisplayName,Mail,MailNickName,ProxyAddresses,UserPrincipalName

ObjectType : User

DirSyncEnabled : True

DisplayName : Blog GuestTest

Mail : blogguesttest@external.com

MailNickName : blogguesttest

ProxyAddresses : {SMTP:blogguesttest@external.com}

UserPrincipalName : BlogGuestTest@registeredDomain.com

UserType : Guest

 

The outcome is as expected, and a synchronized guest account is now present in Azure AD. The Azure AD object is not the only object that is provisioned as a result of this synchronization. When a guest account is created in Azure AD and the email address is not a registered accepted domain in Exchange Online the Exchange Online provisioning process provisions a guest mail user object. The guest mail user has an external email address set to match the mail attribute synchronized from Azure AD and will appear in the global address list by default. Using get-Recipient in the Exchange Online Management PowerShell the attributes of this object can be reviewed.

 

PS C:\> Get-Recipient blogguesttest | fl DisplayName,Alias,PrimarySMTPAddress,EmailAddresses,RecipientType,RecipientTypeDetails

DisplayName : Blog GuestTest

Alias : blogguesttest

PrimarySmtpAddress : blogguesttest@external.com

EmailAddresses : {SMTP:blogguesttest@external.com}

RecipientType : MailUser

RecipientTypeDetails : GuestMailUser

 

It is common in Azure AD Connect installations with Exchange Online to enable a feature called Exchange Hybrid Deployment. When this feature is enabled certain attributes from Exchange Online are written back to Active Directory. This feature is not required when migrating to Exchange Online or co-existing in an Exchange On-Premises to Exchange Online deployment but is most commonly enabled in these scenarios. It is the enablement of this feature combined with synchronizing guest accounts that have external email addresses that ultimately leads to the validation failures. Let’s observe why this happens.

 

With Exchange Hybrid Deployment enabled in Azure AD Connect one of the attributes written back is the proxyAddresses attribute. When an object is provisioned in Exchange Online an attribute cloudLegacyExchangeDN is written to Azure AD. The hybrid rules take this value from Azure AD and append X500: to it. This combined value is then written to the proxyAddresses attribute in Active Directory. This is where our issue begins. When the user was provisioned the proxyAddresses attribute in Active Directory was NULL. Now this attribute has a value stamped in it.

 

 

When attribute are written back through Azure AD Connect the next import cycle re-imports these values. With a fully mail enabled object that already has proxy addresses this causes the X500 address to be added to the values already present and the newly updated proxy addresses attribute written to Azure AD. In this example proxy addresses were originally NULL and now has a value. This results in the importation of only the X500 address and then the X500 address written to Azure AD. This is a sample from the export operation in the synchronization manager.

 

 

Using get-AzureADUser and reviewing the users properties demonstrates the results of this change.

 

PS C:\> Get-AzureADUser -SearchString BlogGuestTest | fl objectType,DirSyncEnabled,DisplayName,Mail,MailNickName,ProxyAddresses,UserPrincipalName,UserType

ObjectType : User

DirSyncEnabled : True

DisplayName : Blog GuestTest

Mail :

MailNickName : blogguesttest

ProxyAddresses : {x500:/o=ExchangeLabs/ou=Exchange Administrative Group

(FYDIBOHF23SPDLT)/cn=Recipients/cn=7997929e49124a90b9c061b619c58fd8-53a5ba8b-2e}

UserPrincipalName : BlogGuestTest@registeredDomain.com

UserType : Guest

 

The proxy addresses of the user object have changed from the SMTP address previously determined by mail to only the X500 address written back to the Active Directory. Technically this is by design as the Active Directory is the source of authority for this attribute when the object is directory synchronized.

 

The object will now appear in the portal with a validation failure. Using get-AzureADUser the provisioning error is now present on the object.

 

ProvisioningErrors : {class ProvisioningError {

ErrorDetail: <ServiceInstance Name=”exchange/NAMPRD04-001-01″

xmlns=”http://schemas.microsoft.com/online/error/2010/07″&gt;

<ObjectErrors>

<ErrorRecord>

<ErrorCode>ExFD1C0C</ErrorCode>

<ErrorParameters>

<ErrorParameter>53a5ba8b-2e31-450b-a5cc-5adbbe393a2d</ErrorParameter>

</ErrorParameters>

<ErrorDescription>The mailbox 53a5ba8b-2e31-450b-a5cc-5adbbe393a2d doesn’t have

a SMTP e-mail address.</ErrorDescription>

</ErrorRecord>

</ObjectErrors>

<LinkErrors />

</ServiceInstance>

Resolved: false

Service: exchange

Timestamp: 2/15/2023 3:44:19 PM

}

}

 

In this instance the error text displayed is exactly what the issue is. The object as synchronized from the Active Directory does not have an SMTP address. The error is essentially expected in this configuration.

 

What are the options to clear the validation failure?

 

The first option is to evaluate the need to keep the feature Exchange Hybrid Deployment enabled in Azure AD Connect. This feature is what triggers the issue to occur. If this feature was not enabled proxy addresses would not be written to the Active Directory and subsequently imported into Azure Active Directory overwriting the calculated values between Azure AD and Exchange Online. You will want to carefully consider this as a solution as it could have impacts if mail flow is still processed through the Exchange on-premises installation or if you intend to have the ability to migrate mailboxes back to the Exchange On-Premises installation. This will also not fix objects that are in this state as the proxy addresses attribute has already been stamped and processed in the metaverse.

 

The second option is to provision the objects with the proxy addresses stamped. This can be used to prevent the issue from occurring as well as to rectify the issue once it occurs. To fix this issue the administrator would manually stamp SMTP:MAIL where mail is the Active Directory mail field. In our example the proxy addresses attribute would have the added address SMTP:blogguesttest@external.com added. When this is added to the proxy addresses field it will be submitted to Azure AD and the validation error will eventually clear now that the object has a defined proxy address. This may require manual administrator intervention or a change in the user provisioning process in Active Directory. In addition it requires that the Exchange on-premises schema be present in Active Directory. The proxyAddresses field is added by the Exchange on-premises schema updates.

 

The last option is more complicated and requires the addition of an additional transformation to the guest rule in Azure AD Connect. This transformation calculates the proxy addresses for the administrator when the user is evaluated and synced by Azure AD Connect. Here is a sample of the updated rule.

 

 

This is the source rule crafted to correct this issue.

 

IIF(IsPresent([mail]),IIF(IsNullOrEmpty([proxyAddresses]),NULL,RemoveDuplicates(Split(“SMTP:” & LCase([mail]) & “,” & LCase(Join([proxyAddresses],”,”)), “,”))) ,NULL)

 

The rule sets out to do the following:

1. Operate if the mail attribute is present.
2. Take the mail attribute for the user and convert it to a primary SMTP address by adding SMTP: to the value.
3. Take any existing proxy addresses that exist on the object, convert them to lower case, and join them to the calculated mail value.
   1. This ensures that none of the existing addresses can be accidentally interpreted as an additional primary proxy address.
4. Write the entire calculated mult-valued attribute to the proxy addresses field in Azure AD.

 

The rule syntax is structured as follows:

• If the mail field on the object is present:
  • Value True
    • If the proxy addresses field is null or empty
      • Value False
        • Make the mail field lower case.
        • Add SMTP: to the mail filed.
        • Join all addresses in the proxy addresses field with “,”
        • Take all addresses field and make the lower case.
        • Split the concatenated strings of addresses by the delimiter “,”. This creates a multi valued attribute.
        • Remove all duplicates from the list.
      • Value True
        • Do nothing / NULL
  • Value False
    • No nothing / NULL

 

This rule structure automatically populates the proxy addresses field without administrator intervention beyond updating the rule. It also ensures that addresses that were written back are included in the proxy addresses submitted as well as any manually set proxy addresses that may exist in the proxy addresses attribute.

 

Here is an example of this rules application after the transformation has been updated.

 

 

If the administrator adds an additional proxy address as primary to the proxyAddresses attribute transformation application adds the address as a secondary proxyAddress.

 

 

 

If the administrator changes the mail address to a new external address the proxyAddress transformation coverts the primary SMTP address for the object. Note: It does not retain the original external email address as a proxy address as that would not typically occur on a mail user object.

 

 

 

Implementation of these options should allow the seamless provisioning of guest accounts in Azure AD from a synchronized Active Directory account where the mail field is set to an external address.

Distribution groups have a variety of settings on them that allow administrators to control use and privileges. Administrators may choose to restrict who can send to a distribution list by altering the accept messages from senders or members property, enable moderation and bypass moderation rights, or reject messages from individual senders or members to a group.

 

When using the get-distributionGroup commandlet to interrogate these settings a list of recipients that have been granted the rights or privileges is returned.

 

PS C:\> Get-DistributionGroup zCloudonlySendAsSecurity9 | fl *accept*

AcceptMessagesOnlyFrom : {Tim McMichael}

AcceptMessagesOnlyFromDLMembers : {}

AcceptMessagesOnlyFromSendersOrMembers : {Tim McMichael}

 

The list of recipients that is returned shows the names of individual assigned those rights. These names are not fully recipient objects in that it does not identify the specific recipient assigned the rights. Using the get-Recipient command “Tim McMichael” demonstrates that two recipients are returned.

 

PS C:\> Get-Recipient “Tim McMichael”

 

Name RecipientType

—- ————-

Tim McMichael MailUser

8c6f3197-070d-4785-af94-8f091a1f510e MailUser

 

How do we determine which object has been assigned the rights if the output appears ambiguous? The name listed here is the actual name property of the recipient object. If more than one object is returned, we can simply filter on the exact name and determine the exact recipient object the rights are applied to.

 

PS C:\> Get-Recipient -Filter {name -eq “Tim McMichael”}

 

Name RecipientType

—- ————-

Tim McMichael MailUser

 

With the recent changes in the provisioning process this will become less ambiguous with time. The new provisioning logic defaults the name field to the external directory object ID associated with the recipient. The external directory object ID is unique and specific to that recipient. This is an example where external directory object ID is now present.

 

PS C:\> Get-DistributionGroup zCloudonlySendAsSecurity9 | fl *accept*

 

AcceptMessagesOnlyFrom : {8c6f3197-070d-4785-af94-8f091a1f510e, Tim McMichael}

AcceptMessagesOnlyFromDLMembers : {}

AcceptMessagesOnlyFromSendersOrMembers : {8c6f3197-070d-4785-af94-8f091a1f510e, Tim McMichael}

 

With the external directory object ID it becomes unnecessary to utilize a filter as the recipient return is guaranteed to be unique.

 

PS C:\> Get-Recipient 8c6f3197-070d-4785-af94-8f091a1f510e

 

Name RecipientType

—- ————-

8c6f3197-070d-4785-af94-8f091a1f510e MailUser

 

When using command that return multiple objects filterable properties will assist in identifying the correct recipient.

Converting a cloud only distribution list to an Office 365 Unified Group

Office 365 administrators have the ability to create distribution lists directly in Office 365. As the service evolves and service adoption continues administrators may desire to preserve the groups they have created in Office 365 directly but covert them to the new Office 365 Unified Group experience.

 

In Exchange Online administrators had the ability to process a conversion of a cloud only distribution list to a modern Office 365 Unified Group. This feature is documented at the following location:

 

Upgrade distribution lists to Microsoft 365 Groups in Exchange Online – Microsoft 365 admin | Microsoft Learn

 

This feature is being deprecated and will no longer be available within Office 365. The ability to convert cloud only distribution lists to Office 365 Unified Groups is now available in the DLConversionV2 migration module. Administrators now have access to the command convert-Office365DLToUnifiedGroup.

 

The conversion command captures the settings of the Office 365 distribution list and uses them as the basis for deleting and recreating the group as an Office 365 Unified Group. There are some pre-requisites that must be met before a distribution list can be converted. These include:

• The group cannot have any rights on itself or other groups that require a security principle. For example, the group may not have full mailbox access rights, send as rights, mailbox folder permissions, or group manager rights on itself or any other object.
• The group must have at least one manager but no more than 100 managers.
• All managers must be members of the group.
• The group may not contain any mail enabled groups or contacts. Only mailbox and mail user objects are supported for membership.
• The group being migrated may not be a room distribution list type.
• The group being migrated may not have any bypassModerationFromSendersOrMembers properties specified on-premises as this attribute is not supported on Office 365 Unified Groups.

 

To perform a group conversion, use the following command:

Convert-Office365DLtoUnifiedGroup -groupSMTPAddress address@domain.com -exchangeOnlineCredential $cred -azureADCredential $cred -logFolderPath c:\temp -overrideSecurityGroupCheck:$TRUE -addManagersAsMembers:$TRUE

 

The command also supports the utilization of data precollection commands for permissions evaluation. If you encounter any issues with this new feature please open an issue on GitHub or contact me at dlconversionV2@service.microsoft.com.

Implementing the ability to migrate directly from on-premises distribution lists to Office 365 Unified Groups

When the Distribution List Migration Version 2.0 module was initially released a feature was included that allowed administrators during the migration process to trigger an upgrade to an Office 365 Unified Group. The code leveraged a special command included in Office 365 that took a cloud only distribution list and performed a migration in the background to an Office 365 Unified Group. I often found that the upgrade command would fail an was not always very specific in the nature or reasons for the failure. This is why the module would do a best effort trigger to allow the upgrade to be performed but continue moving on if a failure code was returned.

 

For information on the upgrade process please see: Upgrade distribution lists to Microsoft 365 Groups in Exchange Online – Microsoft 365 admin | Microsoft Learn

 

The features outlined in the above post are being deprecated over time. This necessitated taking a new approach to migrating distribution lists from the on-premises environment to Office 365 Unified Groups if the desire was to convert the group type. Version 2.9.6 of the DLConversionV2 powershell module now introduces the ability to migrate directly from an on-premises distribution group to an Office 365 Unified Group without the need to first perform a standard migration and upgrade.

 

To migrate to an Office 365 Unified Group from an on-premises distribution list the start-Office365GroupMigration command is utilized. This command follows the same structure as the traditional start-distributionListMigration command and supports the same parameters. In addition to the standard parameter set there is an additional parameter -addManagersAsMembers. This switch automatically takes any user in the managedBy or msExchCoManagedBy attribute and adds them as members of the group. It is a requirement that all owners be members of the group in Office 365.

 

When migrating from an on-premises distribution list to an Office 365 Unified groups there are some additional restrictions that are not found when performing a standard distribution list migration. These restrictions include:

• The group cannot have any rights on itself or other groups that require a security principle. For example, the group may not have full mailbox access rights, send as rights, mailbox folder permissions, or group manager rights on itself or any other object.
• The group must have at least one manager but no more than 100 managers.
• All managers must be members of the group.
• The group may not contain any mail enabled groups or contacts. Only mailbox and mail user objects are supported for membership.
• The group being migrated may not be a room distribution list type.
• The group being migrated may not have any bypassModerationFromSendersOrMembers properties specified on-premises as this attribute is not supported on Office 365 Unified Groups.

 

The DLConversionV2 module has been modified to perform these additional checks prior to migration and provide the administrator with a list of exceptions found. When the migration is complete the result will be an Office 365 Unified Group that mirrors all the settings of the on-premises distribution list. This will allow users to take advantage of the new features associated with the modern group experience.

 

Here is a sample command for migrating an on-premsies distribution list to an Office 365 Unified Group:

 

Start-Office365GroupMigration -groupSMTPAddress address@domain.com -globalCatalogServer dc.domain.com -activeDirectoryCredential $cred -aadConnectServer aadconnect.domain.com -aadConnectCredential $cred -exchangeServer exchange.domain.com -exchangeCredential $cred -exchangeOnlineCredential $cred -azureADCredential $cred -enableHybridMailFlow:$TRUE -dnNoSyncOU “DN” -logFolderPath c:\temp -overrideSecurityGroupCheck:$TRUE

 

The command also supports certificate authentication as well as pre-collected permissions evaluations using the additional switches present in the module.

 

If you encounter any issues with this new feature please open an issue on GitHub or contact me at dlconversionV2@service.microsoft.com.

 

Implementing exception codes…

Throughout the distribution list migration process it is possible that exceptions may occur. The module is designed to capture most exceptions and provide feedback to administrators regarding what process failed during the migration. The goal is to allow migrations to complete while addressing any one-off issues later. The following are exception codes that administrators may reference to understand the circumstances of individual failures.

 

• GROUP_NO_LONGER_SECURITY_EXCEPTION
  • This exception is thrown when a group is found on the managedBy or msExchCoManagedBy attribute but the group is no longer security enabled.
  • The managedBy property of a distribution group must only contains security enabled objects.
  • The group in error either needs to be security enabled <or> removed from the managedBy property of the distribution group.

 

• GROUP_OVERRIDE_MANAGER_NOT_ALLOWED
  • The group specified for migration was found on its own managedBy or msExchCoManagedBy attribute.
  • The administrator has specified to override the group migration type from Security to Distribution. Groups on the managedBy attribute must be of a security type.
  • The migration needs to be redone not overriding the group security type <or> the group must be removed from the managedBy attribute.

 

• NESTED_GROUP_EXCEPTION
  • The distribution list specified for migration has members that are mail enabled groups.
  • All child distribution lists must be migrated before the parent distribution list migration can be completed.
  • The migration needs to be redone either removing the child distribution lists from the group specified <or> after the child distribution lists have been migrated.

 

• OBJECT_NOT_MAIL_ENABLED_EXCEPTION
  • A non-mail enabled object was discovered on the properties of the group.
  • The non-mail enabled object will not exist in Office 365 and therefore cannot be migrated with the distribution group.
  • Refer to the Active Directory property in the exception and locate the object referenced as non-mail enabled.
  • To complete the migration the object must either be mail enabled or removed from the Active Directory property.

 

• OFFICE_365_DEPENDENCY_NOT_FOUND_EXCEPTION
  • A pre-requisite for migration is that all recipients on properties of the distribution list being migrated may be located in Office 365.
  • This exception indicates that one of those dependencies was not successfully located in Office 365.
  • Refer to the exception for the Active Directory attribute and the object missing.
  • Ensure that the object is appropriately found in Office 365 <or> remove the dependency from the on premises object / attribute.

 

• CIRCULAR_REFERENCE_EXCEPTION
  • A multiple distribution list migration is being performed and the groups contained in the migration set have references to each other.
  • For example GroupA contains GroupB and GroupB contains GroupA.
  • The nested group migration update cannot process circular references.
  • Administrators must remove the circular reference, migration the groups individually, and manually reestablish membership <or> not migrate the lists.

 

• CHILD_GROUP_MIGRATION_EXCEPTION
  • A multiple distribution list migration is being performed and a parent distribution list failed due to having a child distribution list as a member.
  • During the retry phase of multiple list migrations it was determined that the child distribution list was not included in the original migration set.
  • Administrators must include the child list in the migration set <or> remove the child list from membership of the parent distribution list to complete the migration.

 

• UNIFIED_GROUP_MIGRATION_MANAGER_NOT_MEMBER_EXCEPTION
  • A distribution list to Office 365 Unified Group migration is performed.
  • The managedBy and msExchCoManagedBy attributes of the group are used as owners in the migration process.
  • All owners must be members of the group.
  • A user in managedBy or msExchCoManagedBy was not found as a member of the group.
  • Administrators must either add all managers as members of the group <or> remove the manager from managedBy or msExchCoManagedBy.

 

• UNIFIED_GROUP_MIGRATION_MIGRATED_CONTACT_MANAGEDBY_EXCEPTION
  • A distribution list to Office 365 Unified Gorup migration is performed.
  • The managedBy or msExchCoManagedByAttribute contains a mail enabled contact representing a previously migrated distribution list.
  • Office 365 Unified Groups cannot be managed by other mail enabled groups.
  • The contact must be removed from the managedBy or msExchCoManagedBy attribute in order to complete the migration.

 

• UNIFIED_GROUP_MIGRATION_MIGRATED_CONTACT_MEMBERSHIP_EXCEPTION
  • A distribution list to Office 365 Unified Gorup migration is performed.
  • The membership contains a mail enabled contact representing a previously migrated distribution list.
  • Office 365 Unified Group may not have mail enabled contacts or other distribution groups as members.
  • The contact must be removed from the membership attribute in order to complete the migration.

 

• UNIFIED_GROUP_MIGRATION_MIGRATED_CONTACT_MANAGEDBY_EXCEPTION
  • A distribution list to Office 365 Unified Gorup migration is performed.
  • The managedBy or msExchCoManagedByAttribute contains a mail enabled contact.
  • Office 365 Unified Groups cannot be managed by other mail enabled groups or contacts..
  • The contact must be removed from the managedBy or msExchCoManagedBy attribute in order to complete the migration.

 

• UNIFIED_GROUP_MIGRATION_CONTACT_MEMBERSHIP_EXCEPTION
  • A distribution list to Office 365 Unified Gorup migration is performed.
  • The membership contains a mail enabled contact.
  • Office 365 Unified Group may not have mail enabled contacts or other distribution groups as members.
  • The contact must be removed from the membership attribute in order to complete the migration.

 

• UNIFIED_GROUP_MIGRATION_GROUP_MEMBERSHIP_EXCEPTION
  • A distribution list to Office 365 Unified Gorup migration is performed.
  • The membership contains a mail enabled group.
  • Office 365 Unified Group may not have mail enabled contacts or other distribution groups as members.
  • The group must be removed from the membership attribute in order to complete the migration.

 

• UNIFIED_GROUP_MIGRATION_GROUP_MANAGEDBY_EXCEPTION
  • A distribution list to Office 365 Unified Gorup migration is performed.
  • The managedBY or msExchCoManagedBy contains a mail enabled group.
  • Office 365 Unified Group may not have mail enabled contacts or other distribution groups as members.
  • The group must be removed from the managedBy or msExchCoManagedBy attribute in order to complete the migration.

 

• UNIFIED_GROUP_MIGRATION_BYPASS_MODERATION_FROM_SENDERS_OR_MEMBERS_EXCEPTION
  • A distribution list to Office 365 Unified Group migration is performed.
  • The distribution list has bypassModerationFromSendersOrMembers specified.
  • Office 365 Unified Group do not support the use of this attribute.
  • This attribute must be cleared to complete the migration <or> a standard distribution list migration performed.

 

• UNIFIED_GROUP_MIGRATION_DYNAMIC_MEMBERSHIP_EXCEPTION
  • A distribution list to Office 365 Unified Group migration is performed.
  • The membership of the distribution list contains a dynamic distribution group.
  • Office 365 Unified Groups do not support any group types as members.
  • The dynamic distribution group must be removed from membership <or> a standard distribution list migration performed.

 

• UNIFIED_GROUP_MIGRATION_ROOM_LIST_EXCEPTION
  • A distribution list migration to Office 365 Unified Group migration is being performed and the distribution list is a room list.
  • Room lists cannot be converted to Office 365 Unified Groups.

 

• UNIFIED_GROUP_MIGRATION_NO_MANAGERS_EXCEPTION
  • A distribution list migration to Office 365 Unified Group migration is being performed.
  • The distribution list specified for migration has no managedBy or msExchCoManagedBy specified.
  • The managedBy attribute of the group is the source of the owners attribute for the Office 365 Unified Group.
  • Add a manager to the distribution list in order to complete the migration.

 

• UNIFIED_GROUP_TOO_MANY_MANAGERS_EXCEPTION
  • A distribution list migration to Office 365 Unified Gorup migration is being performed.
  • The managedBy and msExchCoManagedBY attribute contains over 100 objects specified.
  • An Office 365 Unified Group may not have more than 100 managers.
  • Remove managers from managedBy and msExchCoManagedBy in order to complete the migration.

 

• UNIFIED_GROUP_MIGRATION_MANAGEDBY_ON_OTHER_OBJECTS_EXCEPTION
  • A distribution list migration to Office 365 Unified Group migration is being performed.
  • The distribution list has managedBy rights on other distribution lists which require a mail enabled security group.
  • To complete the migration, remove the managedBy rights from other groups <or> perform a standard distribution list migration.

 

• UNIFIED_GROUP_MIGRATION_SENDAS_FOUND_EXCEPTION
  • A distribution list migration to Office 365 Unified Group migration is being performed.
  • The distribution list has sendAs rights either to itself or other mail enabled objects requiring a mail enabled security group.
  • To complete the migration remove the sendAs rights <or> perform a standard distribution list migration.

 

• UNIFIED_GROUP_MIGRATION_FULL_MAILBOX_ACCESS_EXCEPTION
  • A distribution list migration to Office 365 Unified Group migration is being performed.
  • The distribution list has full mailbox access rights to other mail enabled objects requiring a mail enabled security group.
  • To complete the migration, remove the full mailbox access rights <or> perform a standard distribution list migration.

 

• UNIFIED_GROUP_MIGRATION_MAILBOX_FOLDER_PERMISSION_EXCEPTION
  • A distribution list migration to Office 365 Unified Group migration is being performed.
  • The distribution list has mailbox folder permissions to folders within mailboxes requiring a mail enabled security group.
  • To complete the migration, remove the mailbox folder permissions <or> perform a standard distribution list migration.

 

• UNIFIED_GROUP_MIGRATION_GROUP_IS_SECURITY_EXCEPTION
  • A distribution list migration to Office 365 Unified Group migration is being performed.
  • The distribution list is a mail enabled security group on premises.
  • To complete the migration the administrator must specify the overrideSecurityGroupCheck to acknowledge that permissions assigned to the group may be lost in Office 365 as a result of deleting and recreating the group.