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.