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 |
The value in this property is used to create the path of a user’s OneDrive for Business site collection. For example: 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:
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.
Add a Comment
You must be logged in to post a comment.