SharePoint 2016: AD Import Profile Property Mappings aka: my profiles are missing email address

Update 4/10/20: We’ve found a number of customers manually mapping profile properties for AD Import because that’s what they had done in previous versions of SharePoint using FIM Sync. There can be problems in certain scenarios when doing this. For example, if you manually map “WorkEmail” property to the “proxyAddresses” AD attribute, that explicit mapping will override the logic behind the hard-coded mapping, and you can get email addresses imported with an “SMTP:” prefix like so: SMTP:josh@contoso.com. My colleague Adam wrote a post about this WorkEmail issue with more details: https://adamsorenson.com/sharepoint-adi-mappings/ The same type of problem can also occur with the SIP Address property. I wrote a post about that: https://joshroark.com/sharepoint-unexpected-values-in-user-profile-sip-address-property/

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 Name
Name: 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 name

Name: AccountName

This property stores the claims-encoded User Principal Name for the user.

For example: i:0#.f|membership|gherrera@contoso.com

This property is used to look up the user profile.

UserPrincipalName

DisplayName: Claim User Identifier

Name: 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 Name

Name: SPS-UserPrincipalName

This property stores the User Principal Name of the user.

For example: gherrera@contoso.com

GivenName

DisplayName: First name

Name: FirstName

This property is replicated to the site collection by WSS Sync.

For example: Gabriela

sn

DisplayName: Last name

Name: LastName

This property is replicated to the site collection by WSS Sync.

For example: Herrara

Manager

DisplayName: Manager

Name: 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: Name

Name: PreferredName

This property is replicated to the site collection by WSS Sync.

For example: Gabriela Herrara

telephoneNumber

DisplayName: Work phone

Name: WorkPhone

This property is replicated to the site collection by WSS Sync.

For example: (123) 456-7890

proxyAddresses

DisplayName: Work email

Name: WorkEmail

Processed in this order when it’s added to the profile: 

  • WorkEmail if the value in proxy address is prefixed with SMTP: (Must be in CAPS)
  • WorkEmail if the value in proxy address is prefixed with smtp: (Must be lowercase)

This property is replicated to the site collection by WSS Sync.

For example: gherrera@contoso.com

ProxyAddresses

DisplayName: SIP Address

Name: 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: Office

Name: Office

This property is replicated to the site collection by WSS Sync.

Title

DisplayName: Title

Name: Title

This property is replicated to the site collection by WSS Sync

Title

DisplayName: Job Title

Name: 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: Department

Name: Department

This property is replicated to the site collection by WSS Sync.

Department

DisplayName: Department

Name: 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 redirect

Name: PublicSiteRedirect

 

PreferredLanguage

DisplayName: Language Preferences

Name: 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-HideFromAddressLists

Name: SPS-HideFromAddressLists

 

msExchRecipientTypeDetails

DisplayName: SPS-RecipientTypeDetails

Name: SPS-RecipientTypeDetails

 

ObjectGuid

DisplayName: Active Directory Id

Name: ADGuid

Internal

DistinguishedName

DisplayName: Distinguished Name

Name: SPS-DistinguishedName

Internal

ObjectId

DisplayName: msonline-ObjectId

Name: msOnline-ObjectId

Internal

UserType

DisplayName: SPS-UserType

Name: 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. However, you should be careful about doing this, and only do it when necessary, as outlined in my 11/17/19 update at the top of this post.

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.

One Comment

Add a Comment