Office 365: Users have both a cloud and on premises mailbox.
In Office 365 our provisioning logic generally prevents the existence of a mailbox on premises and in the service. You can imagine the confusion of cloud messages delivering to a mailbox in the cloud and on premises messages delivering to a mailbox on premises.
When a mailbox is provisioned on premises the azure active directory synchronization process is responsible for synchronizing the attributes into Azure AD and Office 365. One of the attributes synchronized from on premises to Azure AD is the ExchangeGUID. Here is an example of a test account on premises.
[PS] D:\>Get-Recipient RecipientTest | fl name,recipienttype,exchangeGuid
Name : Recipient Test
RecipientType : UserMailbox
ExchangeGuid : f20047a9-3fd1-4906-8d98-188feacdd5b7
When AAD Connect has completed a synchronization cycle the same can be verified on the mail user object created in the service. Any on premises mailbox should be represented by a mail user object within the service.
PS C:\> Get-Recipient RecipientTest | fl name,recipienttype,exchangeguid,skuAssigned
Name : Recipient Test
RecipientType : MailUserExchangeGuid : f20047a9-3fd1-4906-8d98-188feacdd5b7
SKUAssigned :
In most cases the mail user object is originally unlicensed. The presence of the immutableID value demonstrates a link to an on premises active directory account.
PS C:\> Get-MsolUser -UserPrincipalName recipienttest@domain.com | fl displayName,userprincipalname,immutablid,isLicensed,Licenses
DisplayName : Recipient Test
UserPrincipalName : RecipientTest@domain.com
ImmutableId : XSLPV65jKEqTyWafMqX8LA==
IsLicensed : False
Licenses : {}
In this example we will assign an Exchange Online license via the portal.
The license assignment can be validated with get-MSOLUser.
PS C:\> Get-MsolUser -UserPrincipalName recipienttest@DOMAIN.com | fl displayName,userprincipalname,immutablid,isLicensed,Licenses
DisplayName : Recipient Test
UserPrincipalName : RecipientTest@domain.com
ImmutableId : XSLPV65jKEqTyWafMqX8LA==
IsLicensed : True
Licenses : {ORGANIZATION:STANDARDWOFFPACK}
The replication of the license status can be validated with get-recipient and reviewing the skuAssigned. In this case the object continues to be retained as a mail user with a SKUAssigned.
PS C:\> Get-Recipient RecipientTest | fl name,recipienttype,exchangeguid,skuAssigned
Name : Recipient Test
RecipientType : MailUser
ExchangeGuid : f20047a9-3fd1-4906-8d98-188feacdd5b7
SKUAssigned : True
The presence of the ExchangeGUID and license has signified to the provisioning process that a mailbox object should not be provisioned. This test has concluded as expected.
If the presence of an ExchangeGUID + a license signifies that no mailbox should be provisioned how is it possible that a mailbox could be provisioned in both locations? Let us take a look at an example presented by a customer I recently worked with…
In this instance I have created a CLOUD ONLY account. The account has been provisioned with a UPN that matches an on premises UPN suffix and no licenses.
PS C:\> Get-MsolUser -UserPrincipalName testDuplicate@DOMAIN.com | fl displayName,userPrincipalName,isLicensed,Licenses
DisplayName : Test Duplicate
UserPrincipalName : TestDuplicate@DOMAIN.com
IsLicensed : False
Licenses : {}
When a license is assigned via the portal that contains an Exchange Online option – mailbox object would be provisioned in Exchange Online. This is the expected behavior – no ExchangeGUID is replicated from on premises. In addition the immutableID is not populated demonstrating no link to an on premises AD account (therefore a cloud only account).
PS C:\> Get-MsolUser -UserPrincipalName testDuplicate@domain.com | fl displayName,userPrincipalName,immutableID,isLicensed,Licenses
DisplayName : Test Duplicate
UserPrincipalName : TestDuplicate@domain.com
ImmutableId :
IsLicensed : True
Licenses : {ORGANIZATION:STANDARDWOFFPACK}
PS C:\> Get-Recipient TestDuplicate | fl name,recipienttype,exchangeguid,skuAssigned
Name : TestDuplicate
RecipientType : UserMailbox
ExchangeGuid : 9e58304a-ed80-416a-8eac-f2e769056e52
SKUAssigned : True
At this point everything looks to be working as expected. Here is where the issue could come into existence. The customer I worked with was testing Office 365. In this instance they took and intentionally mirrored some key on premises accounts prior to having directory synchronization enabled in their tenant. That is to say that the customer created cloud only accounts for testing that utilized the same on premises user principal name and same proxy addresses as accounts on premises. Using our example this is the on premises account representation.
[PS] D:\>Get-Recipient TestDuplicate | fl name,recipienttype,exchangeGuid
Name : Test Duplicate
RecipientType : UserMailbox
ExchangeGuid : 064e1a94-3199-49a7-9cb3-3ce3412424d6
In this example you will note that the ExchangeGUID of the mailbox on premises does not match the ExchangeGUID of the account within the service. This is to be expected since there is no directory sync relationship
At this time the customer has decided to enabled directory synchronization on the accounts. In preparation for this the licenses on the accounts were removed.
PS C:\> Get-MsolUser -UserPrincipalName testDuplicate@domain.com | fl displayName,userPrincipalName,immutableID,
isLicensed,Licenses
DisplayName : Test Duplicate
UserPrincipalName : TestDuplicate@domain.com
ImmutableId :
IsLicensed : False
Licenses : {}
The license change replicates into Exchange Online resulting in the associated mailbox no longer being valid.
PS C:\> Get-Recipient TestDuplicate | fl name,recipienttype,exchangeguid,skuAssigned
The operation couldn't be performed because object 'TestDuplicate' couldn't be found on
'CO1PR06A002DC01.NAMPR06A002.prod.outlook.com'.
+ CategoryInfo : NotSpecified: (:) [Get-Recipient], ManagementObjectNotFoundException
+ FullyQualifiedErrorId : [Server=BY1PR0601MB1402,RequestId=5faf2d1c-dc9a-4fd7-8395-db766ca0cf0b,TimeStamp=9/10/20
17 3:53:46 PM] [FailureCategory=Cmdlet-ManagementObjectNotFoundException] 10E01848,Microsoft.Exchange.Management.R
ecipientTasks.GetRecipient
+ PSComputerName : ps.outlook.com
It was at this time that a very important and often overlooked attribute was set. Although the license was removed rendering the Exchange Online mailbox inaccessible the users representation within the Exchange Online Active Directory was not removed. This can be seen with the get-user command.
PS C:\> Get-User TestDuplicate
Name RecipientType
---- -------------
TestDuplicate User
An attribute of the user object within the Exchange Online Active Directory is the previous recipient type. In this case the license removal resulted in this attribute being populated as user mailbox – as the previous recipient type for the linked account was mailbox.
PS C:\> Get-User TestDuplicate | fl name,recipienttype,previousrecipienttypedetails
Name : TestDuplicate
RecipientType : User
PreviousRecipientTypeDetails : UserMailbox
Prior to the existence of previous recipient type details the provisioning process, when handling license additions and removals, would attempt to guess at what the previous recipient type was. This could lead to mailbox reconnect issues, wrong object provisioning, and other miscellaneous issues when provisioning accounts after license removal and addition. The previous recipient type details no exists to track the status of the recipient in Exchange Online. Administrators do not have access to modify the previous recipient display type.
In our case the administrator is now proceeding with the process of soft matching cloud only accounts to accounts that exist on premises. The following is after a directory sync cycle where soft matching occurred. We can now verify that the immutableID field is stamped indicating the account is linked to an on premises active directory account.
PS C:\> Get-MsolUser -UserPrincipalName testDuplicate@domain.com | fl displayName,userPrincipalName,immutableID,isLicensed,Licenses
DisplayName : Test Duplicate
UserPrincipalName : TestDuplicate@domain.com
ImmutableId : YcQouGWUS0Ww3XyDegtu6g==
IsLicensed : False
Licenses : {}
With the directory synchronization cycle completed the administrator then assigned licenses to the accounts.
PS C:\> Get-MsolUser -UserPrincipalName testDuplicate@domain.com | fl displayName,userPrincipalName,immutableID,
isLicensed,Licenses
DisplayName : Test Duplicate
UserPrincipalName : TestDuplicate@domain.com
ImmutableId : YcQouGWUS0Ww3XyDegtu6g==
IsLicensed : True
Licenses : {ORGANIZATION:STANDARDWOFFPACK}
When the license status replicates to Exchange Online an appropriate recipient object will be provisioned.
PS C:\> Get-Mailbox TestDuplicate | fl name,recipientType,exchangeGUID,skuAssigned
Name : Test Duplicate
RecipientType : UserMailbox
ExchangeGuid : 17d89853-ec3e-4bb3-9bf8-a7d022818fb0
SKUAssigned : True
In this example a recipientType of user mailbox has been provisioned. This is NOT the expected recipient type. In this example we should have expected a mail user object to be created. Why did this occur? Although the on prmises ExchnageGUID is populated and replicated by directory synchronization the users previous recipient type was user mailbox. The provisioning process ignores the presence of the replicated ExchangeGUID and creates in this instance a new blank mailbox for the user within Exchange Online since the previous recipient display is stamped.
ExchangeGuid CLOUD : 17d89853-ec3e-4bb3-9bf8-a7d022818fb0
ExchangeGuid ON PREMISES : 064e1a94-3199-49a7-9cb3-3ce3412424d6
If the licenses is removed from the account the object reverts to a mail user object with the matching Exchange GUID on premises.
PS C:\> Get-Recipient TestDuplicate | fl name,recipienttype,exchangeguid,skuAssigned
Name : Test Duplicate
RecipientType : MailUserExchangeGuid : 064e1a94-3199-49a7-9cb3-3ce3412424d6
SKUAssigned : False
ExchangeGuid CLOUD : 064e1a94-3199-49a7-9cb3-3ce3412424d6
ExchangeGuid ON PREMISES : 064e1a94-3199-49a7-9cb3-3ce3412424d6
The combination of previous recipient display type as user mailbox and a license triggers the mailbox provisioning process even if ExchangeGUID is stamped. This can lead to a condition where an on premises mailbox and Exchange Online mailbox exist at the same time.