Object not synchronized as mail-enabled user from on-premises AD in Office 365 dedicated/ITAR


In Microsoft Office 365 dedicated/ITAR, an on-premises or legacy dedicated mail user is listed as a user in Azure AD. This situation may affect mail delivery within vNext or mail from the Internet through Exchange Online Protection.


This issue occurs if the mailNickname property does not have a value set in the on-premises Active Directory Domain Services (AD DS).


In Azure AD Connect, a value must be set for the mailNickname property for an Exchange user. The following screen shot shows the default scoping filter.
A screen shot of the default scoping filter page

If no value is set, the object is synchronized to Azure AD as a user, and the object will not have any mail properties set in Exchange.  

Customers who move to vNext from legacy dedicated may have some objects that don’t have a mailNickname value set. The synchronization rules that are used by Microsoft Managed Services Service Provisioning Provider (MMSSPP) do not require a mailNickname property to exist on the object in the on-premises AD DS. MMSSPP uses the value of the SamAccountName property for Users and Groups. Contact objects are set to a value that equals their givenName.sn attribute.

Legacy dedicated customers should set a value in your on-premises AD DS for all objects, or change the default scoping filter in Azure AD Connect.

Article ID: 3186692 - Last Review: Aug 19, 2016 - Revision: 1