SharePoint Profile pictures syncing to the Active Directory

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:

Management Agent Attribute Flow screenshot

And below you can see the Metaverse Search query that reveals that no objects have that attribute populated.

MetaVerse Search

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:

  1. 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
  2. 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
  3. 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.

This entry was posted in Chaos Theory, SharePoint. Bookmark the permalink. Follow any comments here with the RSS feed for this post.

11 Responses to SharePoint Profile pictures syncing to the Active Directory

  1. Wow… thanks for the detailed article. I was also struggling with the user profile sync at our customers environment an this solved our problem.

    Regards
    Andreas

  2. sharepoint says:

    what i did not understand here is that you tried it using an all http farm but still did not find it succesful! so is it not that you will have to do the same for non https as well?

  3. Joe Cruz says:

    It sounds like it should work, but it didn’t, which was very frustrating.

    We went down that path to rule out SSL issues, but ultimately it was the AAMs for the UPSA that needed to be added to the intranet sites list for the service account. We use FQDNs and Intranet URLs, part of the problem, I think, but tricky to troubleshoot!

  4. Dave G says:

    Hey Joe, maybe I’ll get lucky and you’ll have alerts on this blog. I’ve read in multiple places that I need to add the Root CA certificate to SharePoint but no one provides much detail, the term Root CA certificate gets thrown around, are we talking about the Root CA certificate from the Certificate Authority or a Root CA cert already on the SharePoint box, as shown in the certificates MMC on Windows Server 2008? Any additional detail you could provide would be much appreciated?

    Thanks in advance.

    • Joe Cruz says:

      Hi, Dave.

      It’s the Root CA cert for the certificate that is assigned to the web application that hosts the UPSA (in our case, it’s the Verisign Root Certificate Authority). IIS, itself, reads the local machine’s list of trusted certificate authorities, so it’s typically not a problem. SharePoint, oddly, has a separate location to manage trusted certs, completely ignoring the local machine store.

      Hope that helps!

      Joe

      • Dave G says:

        Thank Joe, forgive my ignorance, could you quickly specify how I export and import the certificate please? Import for example Central Admin > Security > Manage Trust > New > Root Authority Certificate (and Provide Trust Relationship?) > Select Certificate obtained via export process – Roles > IIS > [Server Name] > Server Certificates… or from the CA server http://cert_server/certsrv > Download a CA Certificate > Download CA Certificate. You can probably see where I’m getting confused, there seems to be certificates all over the place. We have our own root CA and no matter how many certificates I add I’m still getting “An operation failed because the following certificate has validation errors…”

        Thanks for responding so quickly! Maybe others will find these comments useful.

        Dave

        • Joe Cruz says:

          It’s a .cer file that you have to import, and using your in-house CA that path sounds correct. No need to add STS trust configuration.

          • Dave G says:

            Hi Joe, just wanted to say thanks for your help and for anyone else struggling with this I finally got export working by exporting the Root CA certificate ‘chain’ from our internal Certificate Authority (in this case Microsoft Certificate Services), opening the certificates within this chain (double click the .P7B file) and then exporting them as Base-64, both parent and subordinate certificates and then add these to Manage Trusts in Central Administration. IISRESET and then all is well.

          • Joe Cruz says:

            Congrats, Dave! That’s good news.

  5. Uzma says:

    This issue has been a pain in the backside for months for me. My lync photos and ad thumbnailphoto refused, absolutely refused to update.

    Thank you so much for your tips that helped me to get this working, will link back to your blog.

    Uzma

    • Joe Cruz says:

      Good to hear, Uzma! It’s such an esoteric feature that everyone *says* is easy, just change the UPSA, but it’s so lightly documented as to be almost a non-feature!

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>


University of Pennsylvania Logo
Copyright © 2014 The Wharton School, University of Pennsylvania