Sharepoint User Profile Services Sync = Easy!
SharePoint 2010, like a lot of newer generation products, has user profile management and publishing built in. If you (with a Wharton login) go to a profile site you can upload a photo, setup your interests, change your phone number, etc. Also, in typical Microsoft product fashion, there are hooks into the Active Directory to pull existing directory data into the User Profiles so that a user wouldn’t have to enter it again (or if the AD is populated from an external, canonical datasource). Things like office address, title, manager, and group memberships are pulled from the AD.
So, the realy cool feature that I’ve been struggling with for a few months was how to get the User Profile photo synchronized back from SharePoint user profiles into the Active Directory. The procedure appears to be quite simple:
This post, for example, from a Microsoft MVP outlines it:
- setup a connection to the User Profile Service Application (UPSA) to import from the AD
- Configure the UPSA to export the Picture property into the thumbnailPhoto property of the AD
- Make sure you’re profile connection has specific permissions (Replicate Directory Changes, Write Attributes, Create Child Objects) to the user accounts you want to sync to
They made it sound soooo simple, but for the life of me I couldn’t get it to work. The process runs without throwing an error, but no pictures are pushed into the AD.
SharePoint User Profile Services = don’t look behind the curtain; your eye’ll burn out!
We narrowed it down to the actual Forefront Identity Manager (FIM) management agent (MA) for SharePoint. It wasn’t properly grabbing the contents of the picture and pushing it into the FIM Metaverse (a waypoint database that connects two datasources to one another, AD & SP in our case).
I verified this by examining the metaverse for any objects that had the SPS_MV_OctetString_PictureURL value populated, like below. Here, ironically, I’ve had a ton of previous experience with FIM working with MIIS/ILM to synchronize our GAL with Live@EDU. Here you can see the confirmed attribute flow in the MA’s properties:
And below you can see the Metaverse Search query that reveals that no objects have that attribute populated.
So we ruled out the connectivity to the AD as the problem by populating a few test users with “garbage” data in their thumbnailPhoto attribute. It gets overwritten with a blank value by the MA sync process. Also, importing that value from AD into the Metaverse worked. That left the value from SharePoint (the PictureURL property) getting put into the Metaverse. Opened a case with Microsoft and we bashed our heads against a wall trying to replicate the problem. It worked in the engineer’s farm. It didn’t work in our farm. We upgraded to the February 2011 Cumulative Update, didn’t work.
Then we came across this article by Tristan Watkins where he described a situation where the SSL root CA certificates needed to be added to the Trust in sharepoint itself (i agree with him; why wouldn’t SharePoint use the machine store instead of its own?). It didn’t work either! To rule out SSL all together we stood up an HTTP-only farm and tried it again. No dice!
Looking at IIS Logs is the answer to life, the universe, and everything!
At this point, I was pretty much ready to kick someone in the no-no place. At one point, I realized that maybe IIS’s logs would show us something. So I spun up the log viewer and lo and behold, the culprit:
2011-03-23 19:44:54 <snip> wharton_jcruz_LThumb.jpg - 80 - 172.16.1.5 HTTP/1.1 - - - bowser 401 2 5 258 92 0
2011-03-23 19:44:54 <snip> wharton_jcruz_LThumb.jpg - 80 - 172.16.1.5 HTTP/1.1 - - - bowser 401 1 2148074254 595 170 0
2011-03-23 19:44:54 <snip> wharton_jcruz_LThumb.jpg - 80 - 172.16.1.5 HTTP/1.1 - - - bowser 401 1 2148074252 258 866 0
You see that HTTP 401.2 error? That means IIS is asking for credentials, and then returning a failure because it didn’t get any! Quick search on that 214807254/252 error revealed that simply adding the target site to the “Intranet” zone in IE would correct the problem. And you know what? It worked!
SharePoint User Profile Services, SSL, Authentication, and you!
So here’s the breakdown:
- You want to setup MySites/SharePoint user profiles to synchronize user profile photos into the Active Directory thumbnailPhoto attribute (which, nicely flows into OCS and Exchange eventually)
- If your MySites application uses SSL, you need to add the root certificate authority to the Trust Relationship in Sharepoint
- The profile photos are secured by authentication, so you have to add the profile site and any associated alternate access mappings to the Intranet zone in IE for the service account your running the UPSA under!
You know what happens when you assume!
God that’s a little complicated, but now that it’s working, it’s pretty damn sweet (and probably made all the more sweeeter because it took so long to figure out). So why didn’t the MS engineer figure it out first, you ask? Well, what I realized later is that the engineer spin up their own dedicated environments, and then browse to those SharePoint sites and central admin pages directly on the servers themselves. They would probably, out of a sense of effeciency, just automatically add the MySites and Central Admin URLs to the Intranet sites to save themselves the time to authenticate and login. We, on the other hand, never browse to sites on the servers themselves and use management workstations or our own desktops.