SharePoint: Unexpected values in user profile SIP Address property

Posted On April 10, 2020

Consider the following scenario:

• You configure Active Directory Import (ADI) within SharePoint 2013, 2016, or 2019.
• You make some custom user profile property mappings.
• You run a Full import.
• You notice that users have odd values with their SIP Address user profile property. For example:

 

 

Or maybe it has an “SMTP:” prefix like this:

 

 

Cause:

This can happen if you create an explicit profile property mapping from the “SIP Address” user profile property to the “proxyAddresses” Active Directory attribute.

 

 

Note: This is basically the same issue that my colleague Adam wrote about here, only his post is about the Work Email property. The same rule applies to both Work Email and SIP Address.

 

As I mention in a previous post here, Active Directory Import includes a number of hard-coded property mappings, which unfortunately, are not visible in the “Manage User Properties” user interface (UI). The ProxyAddresses Active Directory (AD) attribute is multivalued. It can contain email addresses, SIP addresses, and some other things. The ADI code has logic within it to take that multi-value and parse it out into its appropriate single values.

If you manually map the “Work Email” or “SIP Address” properties to the “proxyAddresses” AD attribute, that explicit mapping will override the logic behind the hard-coded mapping, and you can get SIP and email addresses imported with incorrect values.

 

 

Resolution:

Just like in Adams post for Work Email, we can fix this for SIP Address by removing the manually-created mapping, so that no mapping is shown in the UI:

 

 

That allows the hard-coded (and unfortunately, hidden) mapping to take over again and correctly pull the proper email and SIP addresses out of the ProxyAddresses attribute.

 

Alternatively, if your organization stores SIP Addresses in a different single-valued AD attribute, you can create a manual mapping to point to that AD attribute. The above problem occurs not solely because you created a manual mapping. It occurs because that manual mapping was made to a multi-valued attribute (proxyAddresses). Making a manual mapping to a single-valued attribute should be no problem.