Office 365: Converting a remote mailbox to a mail user…
In Office 365 it may become necessary to change recipient types for on premises accounts. In this scenario contoso.com provided a mailbox within their Office 365 tenant for a user. A decision was made to host the users mailbox within a different mail system but authentication would still occur against the contoso.com domain. The desire was to retain the original active directory account provisioned for the user and have the user appear in the global address list with routing information to the new mail system.
Let’s take a look at this example.
In the contoso.com directory a user account was provisioned.
PS C:\> Get-ADUser testcontoso | fl
DistinguishedName : CN=Test Contoso,OU=Users,OU=UsersOU,DC=contoso,DC=local
Enabled : True
GivenName : Test
Name : Test Contoso
ObjectClass : user
ObjectGUID : a89d3274-747d-4f10-8fa6-68ea419656d1
SamAccountName : TestContoso
SID : S-1-5-21-2774288044-2073832935-89463056-1298
Surname : Contoso
UserPrincipalName : TestContoso@contoso.com
The user was enabled for a remote mailbox using the command enable-remotemailbox. Once the object is replicated through directory synchronization a new remote mailbox will be created within Office 365.
[PS] C:\>Enable-RemoteMailbox -Identity TestContoso -RemoteRoutingAddress testcontoso@contoso.mail.onmicrosoft.com
Name RecipientTypeDetails RemoteRecipientType
---- -------------------- -------------------
Test Contoso RemoteUserMailbox ProvisionMailbox
We can verify the account creation in Azure Active Directory with get-msolUser.
PS D:\> Get-MsolUser -UserPrincipalName testcontoso@contoso.com
UserPrincipalName DisplayName isLicensed
----------------- ----------- ----------
TestContoso@contoso.com Test Contoso False
The final step in provisioning is verification of the Exchange Online Account. This can be performed with get-recipient.
PS D:\> Get-Recipient TestContoso
Name RecipientType
---- -------------
Test Contoso UserMailbox
When reviewing the object on premises there are active directory attributes that in conjunction with directory synchronization control how the object is created and provisioned in the service. For this example we are particularly interested in an attribute msExchRemoteRecipientType. For a remote mailbox that was provisioned using on premises commands enable-remoteMailbox the remote recipient type should be a value of 1.
msExchRemoteRecipientType: 1;
In our example the value is 1. A good reference for recipient display types https://blogs.technet.microsoft.com/johnbai/2013/09/11/o365-exchange-and-ad-how-msexchrecipientdisplaytype-and-msexchangerecipienttypedetails-relate-to-your-on-premises/.
1
0x1
ProvisionedMailbox (Cloud MBX)
Now that we have established how the user and mailbox were provisioned we can review the conversion process. In our example we want to convert the user from a REMOTE MAILBOX to a MAIL USER. (A mail user is an active directory account that is extended with an email address outside the organization for the purposes of allowing authentication to the directory, allowing the user to appear in the global address list, and having messages sent from the source mail system to the remote mail system.).
The process starts by disabling the remote mailbox. This is accomplished utilizing the disable-remoteMailbox command.
[PS] C:\>Disable-RemoteMailbox TestContoso -Confirm:$FALSE
This process removes the Exchange attributes from on premises and adjusts the remote recipient type. In this case the remote recipient type is adjusted to 8.
msExchRemoteRecipientType: 8;
8
0x8
DeprovisionMailbox
At this stage the user account still exists in on premises Active Directory and still exists in Azure Active Directory. We have not deleted nor modified further the account.
To enable the account as a mail user we will use the enable-mailUser command.
[PS] C:\>Enable-MailUser TestContoso -ExternalEmailAddress test@contoso.com
Name RecipientType
---- -------------
Test Contoso MailUser
Using the get-recipient command we can validate the attribute set on premises – specifically the email addresses and target address.
[PS] C:\>Get-Recipient TestContoso | Select-Object EmailAddresses,ExternalEmailAddress,PrimarySMTPAddress | fl
EmailAddresses : {smtp:TestContoso@contoso.mail.onmicrosoft.com,
smtp:TestContoso@contoso.org, smtp:TestContoso@contoso.com,
SMTP:test@external.com}
ExternalEmailAddress : SMTP:test@external.com
PrimarySmtpAddress : test@external.com
In the case of a mail enabled contact the primary SMTP address, external SMTP address, and primary email address in the proxy addresses signified by SMTP: should all match. This is one of the few cases where a primary proxy address will reflect an external non-owned address.
We can verify the same information in Exchange Online using get-recipient.
PS D:\> Get-Recipient TestContoso | Select-Object RecipientType,EmailAddresses,ExternalEmailAddress,PrimarySMTPAddress | fl
RecipientType : MailUser
EmailAddresses : {X500:/o=contoso/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=84d0cea822fe44509f4382fdaed37ab5-Test Co, SMTP:TestContoso@contoso.onmicrosoft.com,
smtp:TestContoso@contoso.mail.onmicrosoft.com, smtp:TestContoso@contoso.com, smtp:TestContoso@contoso.org}
ExternalEmailAddress : SMTP:test@external.com
PrimarySmtpAddress : TestContoso@contoso.onmicrosoft.com
This output confirms that a mail user object has been provisioned in the service but the addresses do not match on premises? Why?
In this instance the provisioning process is confused by the presence of the remote recipient type on premises. A typical mail user does not have a remote recipient type set. In this instance the mail user will work, but any attempts to search via SMTP address or information displayed on contact cards may not be consistent with expectations. For example, the contact in the on premises GAL would show a primary proxy of the external address while the Exchange Online GAL would show a primary proxy of the internal address. Although this display is not the same – we will route messages correctly to the external recipient since the external email address is properly set.
How do we fix this issue?
In order to correct this condition the remote recipient type needs to be cleared. Using Active Directory Users and Computers ensure advanced features is enabled (view –> advanced features). Locate the user account on premises and select properties.
Select the EDIT button –> CLEAR –> OK. This will revert the entry to NOT SET. The apply button will commit the change to the directory. Directory replication and directory synchronization will apply the change to Azure Active Directory and Exchange Online.
When changes have replicated successfully we can use get-recipient to validate the changes in Exchange Online. The primary proxy address listed in SMTP addresses and signified with SMTP: matches the primarysmtpaddress field. The fix was successful.
PS D:\> Get-Recipient TestContoso | Select-Object RecipientType,EmailAddresses,ExternalEmailAddress,PrimarySMTPAddress | fl
RecipientType : MailUser
EmailAddresses : {smtp:TestContoso@contoso.onmicrosoft.com, SMTP:test@external.com, X500:/o=contoso/ou=Exchange Administrative Group
(FYDIBOHF23SPDLT)/cn=Recipients/cn=84d0cea822fe44509f4382fdaed37ab5-Test Co, smtp:TestContoso@contoso.mail.onmicrosoft.com, smtp:TestContoso@contoso.com,
smtp:TestContoso@contoso.org}
ExternalEmailAddress : SMTP:test@external.com
PrimarySmtpAddress : test@external.com
This is the process that can be utilized to convert a remote mailbox to a mail user.