SharePoint 2016: AD Import Profile Property Mappings aka: my profiles are missing email address
The issue that prompted this post:
I was troubleshooting an issue where when using Active Directory Import (aka AD Import, aka: ADI) to import user profiles in SharePoint 2016, users from one domain were imported without issue. Users from another domain were imported, but missing email addresses (the "Work Email" profile property).
We found that the out-of-box property mappings for SharePoint 2016 include a mapping from the "WorkEmail" profile property to the "proxyAddresses" Active Directory (AD) attribute. We had (incorrectly) assumed that it was mapped to the "mail" AD attribute.
In the non-working domain, none of the users had the "proxyAddresses" AD attribute populated, but they did have "mail" populated.
We created an explicit profile property mapping from the "WorkEmail" profile property to the "mail" AD attribute and ran a Full Import. All profiles got their email addresses correctly updated.
What's the story with AD Import property mappings anyway?
If you're coming from SharePoint 2010 or 2013 and you were using Profile Synchronization (aka: FIM Sync) to import profiles, you might expect to see property mappings in Central Admin | <your user profile service app> | Manage User Properties. However, when using AD Import, the only property mapping that shows there is "Claim User Identifier" mapped to samAccountName. The other mappings are what I call "implicit mappings" that are hard-coded in the SharePoint Source Code. Other than using reflection, there's no way to actually see what they are.
Default config for AD Import:
The out-of-box mappings for AD Import are documented here: https://support.microsoft.com/en-us/help/3168272/information-about-user-profile-synchronization-in-sharepoint-online. The article is for SharePoint Online, but the mappings are the same for the on-premise version of SharePoint 2016. I have copied the mapping table here for the sake of completeness:
Active Directory attribute |
SharePoint User Profile property |
Notes |
UserPrincipalName |
DisplayName: User NameName: UserName |
The value in this property is used to create the path of a user's OneDrive for Business site collection.For example:gherrera@contoso.com and /gherrera_contoso_com/This property is replicated to the site collection by WSS Sync. |
UserPrincipalName |
DisplayName: Account nameName: AccountName |
This property stores the claims-encoded User Principal Name for the user.For example: i:0#.f|membership|gherrera@contoso.comThis property is used to look up the user profile. |
UserPrincipalName |
DisplayName: Claim User IdentifierName: SPS-ClaimID |
This property stores the user's claims identifier. The identifier is the User Principal Name.For example: gherrera@contoso.com |
UserPrincipalName |
DisplayName: User Principal NameName: SPS-UserPrincipalName |
This property stores the User Principal Name of the user.For example: gherrera@contoso.com |
GivenName |
DisplayName: First nameName: FirstName |
This property is replicated to the site collection by WSS Sync.For example: Gabriela |
sn |
DisplayName: Last nameName: LastName |
This property is replicated to the site collection by WSS Sync.For example: Herrara |
Manager |
DisplayName: ManagerName: Manager |
The manager property is used to determine colleagues and will be used in the user profile and OneDrive for Business deletion process. For more information see: 3042522 How user profiles are deleted in SharePoint Online and OneDrive for Business. |
DisplayName |
DisplayName: NameName: PreferredName |
This property is replicated to the site collection by WSS Sync.For example: Gabriela Herrara |
telephoneNumber |
DisplayName: Work phoneName: WorkPhone |
This property is replicated to the site collection by WSS Sync.For example: (123) 456-7890 |
proxyAddresses |
DisplayName: Work emailName: WorkEmail |
Processed in this order when it's added to the profile:
This property is replicated to the site collection by WSS Sync.For example: gherrera@contoso.com |
ProxyAddresses |
DisplayName: SIP AddressName: SPS-SIPAddress |
SPS-SIPAddress if the value in proxy address is prefixed with sip:.This property is replicated to the site collection by WSS Sync. |
PhysicalDeliveryOfficeName |
DisplayName: OfficeName: Office |
This property is replicated to the site collection by WSS Sync. |
Title |
DisplayName: TitleName: Title |
This property is replicated to the site collection by WSS Sync |
Title |
DisplayName: Job TitleName: SPS-JobTitle |
SPS-JobTitle contains the same value as Title. SPS-JobTitle is connected to a Term Set.This property isn't replicated to the site collection. |
Department |
DisplayName: DepartmentName: Department |
This property is replicated to the site collection by WSS Sync. |
Department |
DisplayName: DepartmentName: SPS-Department |
SPS-Department contains the same value as Department. SPS-Department is connected to a Term Set.This property isn't replicated to the site collections. |
WWWHomePage |
DisplayName: Public site redirectName: PublicSiteRedirect |
|
PreferredLanguage |
DisplayName: Language PreferencesName: SPS-MUILanguages |
SPS-MUILangauges is used by SPO to determine which language a site is displayed in for the user when MUI is enabled. |
msExchHideFromAddressList |
DisplayName: SPS-HideFromAddressListsName: SPS-HideFromAddressLists |
|
msExchRecipientTypeDetails |
DisplayName: SPS-RecipientTypeDetailsName: SPS-RecipientTypeDetails |
|
ObjectGuid |
DisplayName: Active Directory IdName: ADGuid |
Internal |
DistinguishedName |
DisplayName: Distinguished NameName: SPS-DistinguishedName |
Internal |
ObjectId |
DisplayName: msonline-ObjectIdName: msOnline-ObjectId |
Internal |
UserType |
DisplayName: SPS-UserTypeName: SPS-UserType |
Internal |
Can I create my own mappings for the properties that are already implicitly mapped?
Of course. That's what I had to do to fix 'missing email address' issue I described above.
Just like you've done in every version of SharePoint since 2010, go into your User Profile Service App | Manage User Properties. Edit your property of choice, choose the proper import connection, enter the AD attribute name, click the Add button, and then click OK. Note: The "attribute" drop-down box doesn't work, and probably should have been removed from the UI. You must type in the AD attribute name manually.
When added, the mapping should now show up in the UI:
Note: Any explicit mappings should essentially override the hard-coded "implicit mappings". For example, when I manually map WorkEmail to the "mail" AD attribute. Even if I have an SMTP value within my proxyAddresses AD attribute (the implicit mapping), my WorkEmail will be updated with the value from my "mail" AD attribute (explicit mapping). – This seems intuitive, but I was curious, so I tested and confirmed it in build 16.0.4639.1002.