Today I spoke with a customer that had a unique situation – at least for me.  They have started to create distribution lists that reside in Office 365.  They still had distribution lists that were synchronized from on premises.  The customer wanted to add the cloud only distribution list as a member of the distribution list synchronized from on premises. 

Natively this functionality is not possible since cloud only distribution lists are not synchronized from the cloud to on premises.  (One could arguable use Office 365 Groups and group back sync – but that could get complicated).  To fulfill this request I believe we can utilize a mailbox and forwarding.  Let’s take a look.

On premises we have a DL called OnPremisesDL.

[PS] C:Windowssystem32>Get-DistributionGroup OnPremisesDL

Name         DisplayName  GroupType PrimarySmtpAddress
—-         ———–  ——— ——————
OnPremisesDL OnPremisesDL Universal OnPremisesDL@domain.org

In the cloud we have a DL called CloudDL.

PS C:Userstimmcmic> Get-DistributionGroup CloudDL

Name    DisplayName GroupType PrimarySmtpAddress
—-    ———– ——— ——————
CloudDL CloudDL     Universal CloudDL@domain.onmicrosoft.com

My initial thoughts were to utilize a shared mailbox for this purpose.  Our new-remoteMailbox does not have the ability to provision a shared mailbox remotely – and the mailbox must exist as an object both in the cloud and on premises.  To accomplish this we will create the shared mailbox on premises and migrate it to Office 365.

[PS] C:Windowssystem32>New-Mailbox -Shared -Name CloudDL-Forward

Name                      Alias                ServerName       ProhibitSendQuota
—-                      —–                ———-       —————–
CloudDL-Forward           CloudDL-Forward      azure-mbx        Unlimited

With the mailbox created it can be migrated to Office 365 which will preserve the shared status and convert it to a remote shared mailbox.

Post migrating the mailbox to Office 365 we can set the appropriate properties to allow forwarding.  My first recommendation is to hide the mailbox from the distribution list.   This command is executed on premises.

[PS] C:Windowssystem32>Set-RemoteMailbox CloudDL-Forward -HiddenFromAddressListsEnabled:$TRUE
[PS] C:Windowssystem32>

My second recommendation is to enable forwarding using the forwarding SMTP address property and prevent delivery to the shared mailbox.  The forwarding address utilized should match the cloud distribution lists primary SMTP address.  This command is executed in Office 365. 

[PS] C:Windowssystem32>Set-Mailbox CloudDL-Forward -ForwardingSMTPAddress CloudDL@domain.onmicrosoft.com -DeliverToMailboxAndForward:$FALSE
[PS] C:Windowssystem32>

Hiding the mailbox from the address list will prevent users from accidentally selecting it in a name search or when browsing the address list.  The forwarding SMTP address parameter will allow transport to send all messages to the cloud DL preserving the from address as the original sender.  The deliver to mailbox and forward parameter set to false will prevent the delivery of the message to the shared mailbox.  This essentially serves as a forwarder that exists as both an object on premises and within the cloud.

In order for the messages to route to the on premises distribution list and then deliver to the cloud distribution list our mailbox must be a member of the on premises distribution list.

[PS] C:Windowssystem32>Add-DistributionGroupMember -Identity OnPremisesDL -Member CloudDL-Forward
[PS] C:Windowssystem32>

When this has completely synchronized to the on premises environment a test can be performed.  Using an outlook profile we will email the onpremisesDL@domain.com.  The email should arrive in the mailbox of user@domain.com since user@domain.com is a member of CloudDL@domain.onmicrosoft.com

The test email was successfully received to the mailbox that is a member of CloudDL.  Note the to address is the on premises distribution list.

In Office 365 support we occasionally receive requests to review non-deliverable reports.  In some instances the non-deliverable reports are generated by remote mail systems antispam technologies – specific reverse DNS looksups.

 

What is a reverse DNS lookup.  Let’s take a look.

 

An email is addressed from an Office 365 mailbox to a remote mail system.  Our outbound gateways connect to the remote mail system to begin the SMTP transmission.  Here is a sample header:

 

Hop↓
Submitting host
Receiving host
Time
Delay
Type⇒

1
BY2PR0501MB1848.namprd05.prod.outlook.com ([10.163.155.153])
BY2PR0501MB1848.namprd05.prod.outlook.com ([10.163.155.153])
2/7/2018, 2:02:41 PM

mapi

2
BY2PR0501MB1848.namprd05.prod.outlook.com (10.163.155.153)
BY2PR0501MB1816.namprd05.prod.outlook.com (10.163.155.146)
2/7/2018, 2:02:41 PM

0 seconds

Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256)

3
NAM01-SN1-obe.outbound.protection.outlook.com (104.47.32.55)
DM3NAM06FT011.mail.protection.outlook.com (10.152.109.1)
2/7/2018, 2:02:43 PM

2 seconds

Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256)

 

In this case NAM01-SN1-obe.outbound.protection.outlook.com is the server initiating the connection to the receiving gateway.  This server identifies itself in that transmission as NAM01-SN1-obe.outbound.protection.outlook.com and the public IP address associated – in this instance 104.47.32.55.

 

When a reverse DNS lookup is performed – the IP address of the connection is utilized to return the hostname assigned by the ISP hosting the reverse dns namespace.   Here is an example from nslookup:

 

C:>nslookup
Default Server:  UnKnown
Address:  192.168.1.254

> server 8.8.8.8
Default Server:  google-public-dns-a.google.com
Address:  8.8.8.8

> set type=ptr
> 104.47.32.55
Server:  google-public-dns-a.google.com
Address:  8.8.8.8

Non-authoritative answer:
55.32.47.104.in-addr.arpa       name = mail-sn1nam01on0055.outbound.protection.outlook.com

 

In this case the reverse DNS lookup for IP address 104.47.32.55 is mail-sn1nam01on0055.outbound.protection.outlook.com.

 

At one time in the antispam world a protection that was often utilized was to compare the connecting host name to the reverse DNS name.  If the names matched the host was considered valid.  In the case of Office 365 the reverse dns record may not match the name of the host initiating the connection.  As you can see here NAM01-SN1-obe.outbound.protection.outlook.com is not equal to mail-sn1nam01on0055.outbound.protection.outlook.com.  There is no requirement within the mail flow RFCs that the connecting host name or the name provided within the connections EHLO request must match a reverse DNS lookup of the connecting IP address. 

 

In the case of the NDRS presented from the customer the NDR is due to antispam on the receiving servers blocking connections from servers that do not pass a successful reverse DNS check. 

 

Unfortunately from the Office 365 standpoint there is little that can be done.  Reverse DNS looks ups are largely unreliable in todays transport environments to feed antispam decisions and have arguably been replaced by more reliable technologies like SPF and DKIM.  Administrators experiencing these types of NDRs should engage with the third party blocking the messages and request whitelisting for their domains.

 

You can find some more specific and detailed information regarding server naming conventions and Office 365 here –> https://blogs.msdn.microsoft.com/tzink/2016/07/15/the-outbound-ip-and-helo-format-for-office-365/

In Office 365 administrators can invoke the managed folder assistant by using the start-ManagedFolderAssistance command.

 

PS C:> Start-ManagedFolderAssistant tmcmichael@domain.com

 

This week I had a customer present with an issue where the invocation of the managed folder assistance was failing with a generic RPC error.

 

“The call to Mailbox Assistance Service on server: ‘NAME’ failed.  Error from RPC is –2147220989”

 

When this error is encountered subsequent retries of the same command can be successful.

 

The error can sometimes occur as portions of mailboxes are being initialized within the service.  For example – if a secondary archive is being provisioned off a main archive.

 

As a potential workaround to this issue the primary mailbox GUID can be specified in the start-ManagedFolderAssistant command. 

 

get-mailboxLocation –user tmcmichael@domain.com | fl mailboxGuid,mailboxLocationType

 

MailboxGuid         : aace1f4e-5181-4855-a0c7-466f1fe2f1d1

MailboxLocationType : Primary

MailboxGuid         : c2098d94-d55b-4a06-9b52-d485c54e9a19

MailboxLocationType : MainArchive

 

This command will dump the mailbox types and GUID of all mailboxes associated with a user.

 

From the list we can locate the primary mailbox and the mailbox GUID.  Using this mailbox GUID we can invoke the managed folder assistance.

 

PS C:> Start-ManagedFolderAssistant aace1f4e-5181-4855-a0c7-466f1fe2f1d1

 

When utilizing the GUID we can minimize the change that any initialization process does not cause the command to fail.

In Office 365 administrators may discover issues with distribution lists and distribution list membership.  In this article I wanted to walk through some of the common issues that I have seen and how we worked through them. 

When working with distribution lists and distribution list membership we must review the locations where this information is stored.  The information in this post starts assumes distribution lists that are source on premises. 

Any distribution list analysis starts with looking at the distribution list on premises and its membership.  This is then picked up by AAD Connect where an entry is placed into the metaverse.  The list and its membership is then exported to Azure Active Directory.  Once in Azure Active Directory the list is made available through a synchronization process into the individual workloads such as Exchange Online.  By looking for data at each of these points we can identify the issues with our distribution lists and memberships and implement corrective action.

Symptom Scenario #1:  My distribution list is not present in Exchange Online.

Scenario Summary:  The distribution list is not within an organizational unit synchronized by  Azure AD Connect.

In this scenario a user has reported that a distribution list is not available to them in Exchange Online.  It has been confirmed that the group does not appear in the global address list in any client.  Starting our analysis in Exchange Online we attempt to pull properties of the distribution list.

PS C:> Get-Recipient TestUsers
The operation couldn’t be performed because object ‘TestUsers’ couldn’t be found on ‘CO1PR06A002DC02.NAMPR06A002.prod.outlook.com’.
    + CategoryInfo          : NotSpecified: (:) [Get-Recipient], ManagementObjectNotFoundException
    + FullyQualifiedErrorId : [Server=BY1PR0601MB1402,RequestId=756ebc52-32b4-49af-9825-4c024e435f47,TimeStamp=11/12/2017 7:55:46 PM] [FailureCategory=Cmdlet-ManagementObjectNotFoundException] 47F81C4,Microsoft.Exchange.Management.RecipientTasks.GetRecipient
    + PSComputerName        : ps.outlook.com

This error confirms no recipient exists in Exchange Online.  Knowing that distribution lists within Exchange Online have to be represented in Azure Active Directory we can attempt to search there. 

PS C:> Get-MsolGroup -SearchString TestUsers
PS C:>

In this case the lack of any returned object indicates that the group does not exist within Azure Active Directory.  This would imply either an issue with Azure Active Directory Connect <or> the on premises object.  We can utilize the synchronization services manager installed with AAD Connect to perform a metaverse search.  In this case we are searching for the missing distribution list.

The group does not exist in the metaverse.  If the group has not been processed by AAD Connect – it will not be available in Azure Active Directory or Exchange Online.  Continuing to back track through we can review the Exchange options on the local group. 

[PS] C:>Get-Recipient TestUsers

Name      RecipientType
—-      ————-
TestUsers MailUniversalDistributionGroup

The group is present in on premises Exchange and is a valid recipient.   If the group is present and valid in Exchange On Premises – why is it not being processed by AAD Connect.  One of the most common reasons for this is that the group is not within the sync scope of AAD Connect.  We can launch the configuration wizard for AAD Connect using the short cut on the desktop of the AAD Connect server.  When validating domain / ou filtering in this instance it is observed that “sync selected domains and OUs” is the option.  We can expand the different organizational units to determine what is and what is not within sync scope.  Here is an example.

Using get-Group we can dump the organizational unit that the group is stored in. 

[PS] C:>Get-Group TestUsers | Select-Object organizationalUnit

OrganizationalUnit
——————
contoso.local/Contoso/Groups/Office365-NoSync

In this instance the group does exist in an organizational unit that is not included in sync scope.  If we move the group to an OU that is within sync scope it should eventually become available to us within Office 365.  For example:

[PS] C:>Get-Group TestUsers | Select-Object organizationalUnit

OrganizationalUnit
——————
contoso.local/Consoto/Groups/Distribution

When a delta synchronization has completed the group should now be found within the AAD Connect metaverse.

When the export has completed successfully the group should be visible in Azure AD. 

PS C:> Get-MsolGroup -SearchString TestUsers

ObjectId                               DisplayName                GroupType                  Description
——–                               ———–                ———                  ———–
81e58cc5-9f48-41d3-a9d3-b500c8ebc6dc   TestUsers                  DistributionList

And finally the group should be available within Exchange Online.

PS C:> Get-Recipient TestUsers

Name      RecipientType
—-      ————-
TestUsers MailUniversalDistributionGroup

In this situation and scenario our group failed to be represented in Exchange Online because it was not in an organizational unit covered by the AAD Connect sync scope.  Moving it to an appropriate organizational unit or adding the organization unit to be within sync scope would correct this condition.

Symptom Scenario #2:  A member of my distribution list did not receive an email.

 

Scenario Summary:  The user does not exist in Azure AD or Exchange Online but is a member of the distribution list on premises.  The user does not exist in Office 365 because it resides in an organization unit not synchronized to Office 365.

In this scenario a user has reported that a member of this distribution list has not received an email that they sent.  Using a similar method as the first scenario we will start by reviewing the properties of the distribution list in Exchange Online.  In this case the missing user is MissingRecipient@contoso.com.  Using get-recipient we can verify that the distribution list is present within the service.

PS C:> Get-Recipient TestUsers

Name      RecipientType
—-      ————-
TestUsers MailUniversalDistributionGroup

The distribution list membership can also then be validated in Exchange Online.

PS C:> Get-DistributionGroupMember -Identity TestUsers | ft

Name              RecipientType
—-              ————-
Timothy McMichael UserMailbox
Bill Moran        UserMailbox

This output confirms that the recipient is not a member of the distribution group in Exchange Online.

In order for a recipient to be a member of a distribution list it too must be represented in Exchange Online.  Using get-recipient we can determine if the missing user is also in Exchange Online.

PS C:> Get-Recipient MissingRecipient
The operation couldn’t be performed because object ‘MissingRecipient’ couldn’t be found on ‘CO1PR06A002DC02.NAMPR06A002.prod.outlook.com’.
    + CategoryInfo          : NotSpecified: (:) [Get-Recipient], ManagementObjectNotFoundException
    + FullyQualifiedErrorId : [Server=BY1PR0601MB1402,RequestId=8f7fdfd1-274a-4622-b3a6-b45aff678120,TimeStamp=11/12/2017 9:20:24 PM] [FailureCategory=Cmdlet-ManagementObjectNotFoundException] 5DAE93AD,Microsoft.Exchange.Management.RecipientTasks.GetRecipient
    + PSComputerName        : ps.outlook.com

The output of this command confirms the recipient is not available in Exchange Online.   Knowing that the source of information in this scenario is Azure AD we can continue our investigation there.

The group in this instance is successfully found in Azure AD.

PS C:> Get-MsolGroup -SearchString TestUsers

ObjectId                               DisplayName                GroupType                  Description
——–                               ———–                ———                  ———–
81e58cc5-9f48-41d3-a9d3-b500c8ebc6dc   TestUsers                  DistributionList

Using the object ID of the group we can determine the group membership within Azure AD.

PS C:> Get-MsolGroupMember -GroupObjectId 81e58cc5-9f48-41d3-a9d3-b500c8ebc6dc

GroupMemberType EmailAddress               DisplayName
————— ————               ———–
User            tmcmichael@contoso.org     Timothy McMichael
User            bmoran@contoso.org         Bill Moran

This confirms that the representation of the group in Exchange Online matches that of Azure AD.  Does the recipient exist in azure AD?

PS C:> Get-MsolUser -SearchString MissingRecipient
PS C:>

In this case the lack of any return suggests that the object is not within Azure AD.  This would indicate either an issue with Azure AD Connect <or> with the on premises user object. 

Using the synchronization service manager we can perform am metaverse search for the object. 

The user does not exist in the metaverse.  If the user has not been processed by AAD Connect – it will not be available in Azure Active Directory or Exchange Online.  Continuing to back track through we can review the Exchange options on the local user. 

[PS] C:>Get-Recipient MissingRecipient

Name              RecipientType
—-              ————-
Missing Recipient UserMailbox

The recipient on premises is valid.  Is it a member of the given group?

[PS] C:>Get-DistributionGroupMember -Identity TestUsers | ft

Name              RecipientType
—-              ————-
Timothy McMichael MailUser
Bill Moran        MailUser
Missing Recipient UserMailbox

In this case the user is a member of the distribution list on premises.  Looking at the properties of the user – is there any reason it would not be processed via AD connect?

[PS] C:>Get-User MissingRecipient | Select-Object organizationalUnit

OrganizationalUnit
——————
contoso.local/Contoso/Users/Office365-NoSync

Very similar to the issue in scenario #1 this user is in an organizational unit not covered under the synchronization scope of Azure AD Connect.  The user therefore is not replicate to Azure AD and is then not available in Exchange Online.  Regardless of the membership of the distribution list on premises if the object is not available in Azure AD it will not be eligible to be a member of the distribution group in Exchange Online.

To fix this we will move the user to an organizational unit covered under the AD Connect synchronization scope.

[PS] C:>Get-User MissingRecipient | Select-Object organizationalUnit

OrganizationalUnit
——————
contoso.local/Contoso/Users/Members

When the next delta synchronization cycle processes the user should be able to be located in the metaverse.

Once the user has been successfully exported it should be able to be located in Azure AD.

PS C:> Get-MsolUser -SearchString MissingRecipient

UserPrincipalName                DisplayName       isLicensed
—————–                ———–       ———-
MissingRecipient@contoso.org     Missing Recipient False

The user should now show as a member of the group in Azure AD.

PS C:> Get-MsolGroupMember -GroupObjectId 81e58cc5-9f48-41d3-a9d3-b500c8ebc6dc

GroupMemberType EmailAddress                     DisplayName
————— ————                     ———–
User            tmcmichael@contoso.org           Timothy McMichael
User            bmoran@contoso.org               Bill Moran
User            MissingRecipient@contoso.org     Missing Recipient

With the Azure AD object now appearing as expected the recipient and list should be reconciled in Exchange Online. 

PS C:> Get-Recipient MissingRecipient

Name              RecipientType
—-              ————-
Missing Recipient MailUser

 

PS C:> Get-DistributionGroupMember -Identity TestUsers | ft

Name              RecipientType
—-              ————-
Timothy McMichael UserMailbox
Bill Moran        UserMailbox
Missing Recipient MailUser

The missing user is now corrected and the distribution list will function as expected.

In this instance the user failed to be a member of the distribution group because the user on premises was not in the AD Connect organizational unit synchronization scope.

Symptom Scenario #3:  A member of my distribution list did not receive an email.

Scenario Summary:  The distribution list is a security group on premises allowed to contain non-mail enabled objects.  In this instance the user is not a mail enabled object, and therefore is not seen as a recipient during DL expansion in Office 365.

In this symptom scenario a user reports that a distribution list member did not receive an email addressed to the list.  As we have in other scenarios we will begin the analysis by looking at the Exchange Online group and validating it is present.

PS C:> Get-Recipient TestUsers

Name      RecipientType
—-      ————-
TestUsers MailUniversalDistributionGroup

The membership of the group can also be validated in Exchange Online.

PS C:> Get-DistributionGroupMember -Identity TestUsers | ft

Name              RecipientType
—-              ————-
Timothy McMichael UserMailbox
Bill Moran        UserMailbox
Missing Recipient MailUser
NoMailbox User    User

In this instance the user that did not receive the email NoMailbox User.  It is interesting to note in this stage that the recipient type is User.   Running get-recipient we can determine that the user, although they appear in the distribution list, are not appearing as a recipient.

PS C:> Get-Recipient NoMailboxUser
The operation couldn’t be performed because object ‘NoMailboxUser’ couldn’t be found on ‘CO1PR06A002DC02.NAMPR06A002.prod.outlook.com’.
    + CategoryInfo          : NotSpecified: (:) [Get-Recipient], ManagementObjectNotFoundException
    + FullyQualifiedErrorId : [Server=BY1PR0601MB1402,RequestId=756ebc52-32b4-49af-9825-4c024e435f47,TimeStamp=11/12/2017 9:57:40 PM] [FailureCategory=Cmdlet-ManagementObjectNotFoundException]CBC02122,Microsoft.Exchange.Management.RecipientTasks.GetRecipient
    + PSComputerName        : ps.outlook.com

In this instance since the Exchange Online information is accurate the Azure AD information should also be accurate. 

PS C:> Get-MsolUser -SearchString NoMailbox

UserPrincipalName             DisplayName    isLicensed
—————–             ———–    ———-
NoMailboxUser@contoso.org     NoMailbox User False

PS C:> Get-MsolGroupMember -GroupObjectId 81e58cc5-9f48-41d3-a9d3-b500c8ebc6dc

GroupMemberType EmailAddress                     DisplayName
————— ————                     ———–
User            tmcmichael@contoso.org           Timothy McMichael
User            bmoran@contoso.org               Bill Moran
User            MissingRecipient@contoso.org     Missing Recipient
User            NoMailboxUser@contoso.org        NoMailbox User

Knowing that the Azure AD information is accurate there is no indication that an AD Connect problem exists.  Why though is the recipient only showing as a user?  Is it a valid recipient on premises?  We can validate this with get-recipient.

[PS] C:>Get-Recipient NoMailboxUser
The operation couldn’t be performed because object ‘NoMailboxUser’ couldn’t be found on ‘Azure-Dc.domain.local’.
    + CategoryInfo          : NotSpecified: (:) [Get-Recipient], ManagementObjectNotFoundException
    + FullyQualifiedErrorId : [Server=AZURE-MBX,RequestId=b0e9dc63-f0b5-41d4-86bb-df31adfa0a4e,TimeStamp=11/12/2017 10:06:12 PM] [FailureCategory=Cmdlet-ManagementObjectNotFoundException] 34C958E5,Microsoft.Exchange.Management.RecipientTasks.GetRecipient
    + PSComputerName        : azure-mbx.fmrs.local

In this case the recipient is not a mail enabled object.  The group in question is a security group and therefore can contain non-recipient objects.  When replicated into Azure AD and subsequently into Exchange Online the users will appear as group members but only as a USER – not an Exchange recipient type.  Mail enabling the object as a mailbox, remote mailbox, or mail user should rectify the issue.

PS C:> Get-Recipient NoMailboxUser

Name           RecipientType
—-           ————-
NoMailbox User MailUser

 

PS C:> Get-DistributionGroupMember -Identity TestUsers | ft

Name              RecipientType
—-              ————-
Timothy McMichael UserMailbox
Bill Moran        UserMailbox
Missing Recipient MailUser
NoMailbox User    MailUser

The recipient will now receive email addressed to the distribution list.

Symptom Scenario #4:  The Exchange Online distribution group membership is incorrect.

Scenario Summary:  The distribution list membership on premises and within Azure Active Directory is correct.  The membership is not correct within Exchange Online.

In this scenario an administrator has discovered that the membership of the distribution list within Exchange Online is not accurate.  As with our other scenarios we will begin our investigation in Exchange Online.

The first step is to determine if the distribution list is present in Exchange Online.

PS C:> Get-Recipient TestUsers

Name      RecipientType
—-      ————-
TestUsers MailUniversalDistributionGroup

In this example the distribution list is present in Exchange Online.  The next step is to review the membership of the distribution list.

PS C:> Get-DistributionGroupMember -Identity TestUsers | ft

Name              RecipientType
—-              ————-
Timothy McMichael UserMailbox
Bill Moran        UserMailbox
Missing Recipient MailUser

The Exchange Online distribution list contains three members.  The next step is to review the membership of the distribution list in Azure Active Directory.

PS C:> Get-MsolGroup -SearchString TestUsers

ObjectId                               DisplayName                GroupType                  Description
——–                               ———–                ———                  ———–
81e58cc5-9f48-41d3-a9d3-b500c8ebc6dc   TestUsers                  DistributionList

PS C:> Get-MsolGroupMember -GroupObjectId 81e58cc5-9f48-41d3-a9d3-b500c8ebc6dc

GroupMemberType EmailAddress                     DisplayName
————— ————                     ———–
User            tmcmichael@contoso.org           Timothy McMichael
User            bmoran@contoso.org               Bill Moran
User            MissingRecipient@contoso.org     Missing Recipient
User            MissingUser@contoso.org          Missing User

In this instance the membership of the group within Azure Active Directory is 4 members where the membership in Exchange Online is 3 members.  This clearly indicates a difference between the information replicated from Azure AD to Exchange Online.

As we have discovered in our previous examples the last thing we need to know is does the recipient exist in Exchange Online.  If the recipient is mail enabled in Exchange Online – it should be eligible to be a member of the distribution list in Exchange Online.

PS C:> Get-Recipient MissingUser

Name           RecipientType
—-           ————-
Missing User   MailUser

In this instance the recipient is valid within Exchange Online.

To correct this condition a support case should be opened with product support services.  Product support services has methods to assist customers in resynchronizing membership between Azure AD and Exchange Online.

In support you often have interesting cases come across your desk – and sometimes the questions and situations presented are odd.  On occasion you look at some of them and are like that’s impossible…and that’s what happened here.

In this escalation, the customer was reporting that when they would remove a user from an Office 365 Group (Unified Group) and add a different user – the original user they removed would come back to group membership but the new user was not added.  That’s interesting – a user that was removed successfully would automatically just reappear in the group when a completely different user was added.  Turns out – it actually happened.  Let’s take a look.

I have a test tenant TenantA.onmicrosoft.com.  In this tenant, I create an Office 365 Group named Test.  By default, the group membership contains the group owner and this is reflected in Outlook Web Access.

Guest access is enabled for the tenant and a guest account is added.  In this case, the guest account is tmcmichael@domainA.org.  The new guest member is reflected in Outlook Web Access.

When a guest account is added to an Office 365 Group and guest account object is first provisioned in Azure Active Directory.  We can see the guest account with Get-MsolUser.

PS C:Userstimmcmic> Get-MsolUser -SearchString tmcmichael

UserPrincipalName                                                        DisplayName                isLicensed
—————–                                                        ———–                ———-
tmcmichael_domainA.org#EXT#@tenantA.onmicrosoft.com                      tmcmichael@domainA.org     False

Through a forward synchronization process the guest account is then replicated into Exchange Online as a mail user object.  We can see the mail user object with Get-Recipient.

PS C:Userstimmcmic> Get-Recipient tmcmichael*

Name                            RecipientType
—-                            ————-
tmcmichael_domainA.org#EXT#     MailUser

At this time, I will remove the account tmcmichael@domainA.org from the Office 365 Group and save the changes.

Although the user was removed from the group – and does not exist in any other group or guest arrangement – the account remains in Azure Active Directory and Exchange Online.

PS C:Userstimmcmic> Get-MsolUser -SearchString tmcmichael

UserPrincipalName                                                        DisplayName                isLicensed
—————–                                                        ———–                ———-
tmcmichael_domainA.org#EXT#@tenantA.onmicrosoft.com                      tmcmichael@domainA.org     False

PS C:Userstimmcmic> Get-Recipient tmcmichael*

Name                            RecipientType
—-                            ————-
tmcmichael_domainA.org#EXT#     MailUser

With the user removed, I will now invite the new user that I wish to grant guest access.  In this instance tmcmichael@domainB.com.

The user was added successfully and when refreshing group membership – the user vanishes and the original user appears in the group!  What happened?

In this instance, both DomainA.org and DomainB.com both belong to tenantB.onmicrosoft.com.  In tenantB.onmicrosoft.com the recipient TMcMichael has proxy addresses assigned at both TMcMichael@domainA.org and TMcMichael@domainB.com.

PS C:Userstimmcmic> $a=Get-MsolUser -SearchString tmcmichael

PS C:Userstimmcmic> $a.ProxyAddresses

smtp:tmcmichael@domainB.com
smtp:tmcmichael@aaa

SMTP:tmcmichael@domainA.org
smtp:tmcmichael@aaa.org
smtp:tmcmichael@aaa.mail.onmicrosoft.com
smtp:tmcmichael@aaa.onmicrosoft.com
smtp:director@aaa.com
smtp:2148@aaa.com

A guest account receives a link to access the group – with the link providing them the permissions to access the group and group data.  In this case, there is no difference between tmcmichael@domainA.org and tmcmichael@domainB.com.  When tmcmichael@domainB.com is added, Azure Active Directory resolves this address and determines that it belongs to the same object that has tmcmichael@domainA.org.  When this occurs, no new guest account is created, the original guest account and mail user are retained, and the membership is updated in Exchange Online.  With the original mail user object being retained, upon refresh the GUI displays the attributes of that mail user, presenting the appearance that the user that we removed was added again and that the user we wanted added did not add.

At this time our product engineering group is investigating alternate ways to handle this as reverting to the same object and failing to show the desired addition causes confusion within the UI.  If you find this confusing and you desire to fix it – the only method to fix this is to remove the guest account from Azure Active Directory and start over.  This will force a new guest account to provision.  Removing the guest account would subsequently remove any access that original account would have via links or emails to all Office 365 properties – you may want to proceed with caution.