User Profile Picture Export Permissions

Most IT Professionals with SharePoint 2010 experience will be familiar with the initial configuration complexities of the User Profile Service Application but it’s probably less well-known that there are additional requirements to set up profile property export, and that some properties have further requirements still. SharePoint 2010 allows properties to either be imported or exported (but not both, out of the box). The most basic of these requirements for Active Directory export are the Write All Properties and Create Child Objects permissions on the OUs where data will be written by SharePoint.

We initially followed Matthew McDermott’s Profile Image Export suggestions but in our case these steps were insufficient, as detailed below. That article was written while SharePoint 2010 was a beta product. The User Profile Service Application changed since that release and is now configured differently, so it doesn’t surprise me that our experience differs.

You might wonder why we spent this much effort just to get a picture in Active Directory (of all places). While we think it’s important to have this knowledge for our clients and delegating photo selection to end users can drive SharePoint adoption, it is also used by the Outlook 2010 Social Connector. When you start using this great new social computing front-end, it just feels incomplete without a photo.

Identifying the Trouble

We’ve recently deployed a new SharePoint 2010 farm for team sites, but we wanted to make certain that the User Profile Service Application was fully configured before unleashing it, as it’s not the sort of thing that you want to add to a system that’s already in production. In our initial testing we completed a full profile import then decided to test exporting changes to a few of the Active Directory properties, such as mobile number and the profile picture, or thumbnailPhoto (as it’s known in LDAP). This is done by removing the Import mapping in the User Profile Property and adding a new setting for Export (see Matthew McDermott’s blog above if this is unclear). The mobile number synchronised successfully but the thumbnailPhoto failed, with no obvious errors.

After running a couple of full synchronisations while actively monitoring ULSViewer, I also launched the FIM (Forefront Identity Manager) Client, AKA Synchronisation Service Manager (or MIISClient.exe), as Spencer Harbar recommends in his Rational Guide. Note that although this is not a supported tool for SharePoint 2010, it provides a view of what’s going on in SharePoint’s FIM instance that isn’t always visible in the ULS logs. This can sometimes be invaluable.

Stepping through these FIM events, it was clear that the LDAP thumbnailPhoto property (PictureURL in SharePoint) wasn’t getting marked for export. We could monitor the addition of the Mobile number when that data was updated, but the PictureURL was not captured.

Active Directory Rights

Revisiting the source, I decided to see if the TechNet documentation included anything specific for the User Profile picture, as it was last updated on 12 August 2010 and I’d not looked at it since May. Happily it speaks specifically to these requirements, albeit in rather cryptic terms:

To export properties, such as profile pictures, from SharePoint Server 2010 to AD DS, at least Replicate Directory Changes permission is needed on the object and all child objects for the AD DS domains to which you want to export data from SharePoint Server 2010. Read/Write permission is also needed on the container that stores the user picture attribute, for example, the ThumbnailPhoto attribute.

Unfortunately my Active Directory skills are not as sharp as they were when I actually administered a domain, but I figured it shouldn’t be rocket science to figure out how to grant permissions on an attribute. Pretty much everything I found mentioned granting read/write permissions on the following user attributes:

Read/Write – jpegPhoto
Read/Write – pwdLastSet
Read/Write – userAccountControl

However, I still didn’t know how to do that. Luckily the fifth post in this thread spells it out:

1. Right-click the appropriate OU
2. Select the Security tab
3. Click Advanced
4. Click Add
5. Select user then OK
6. Select Properties tab
7. Change Apply To to Descendant User Objects
8. Check both Read and Write for the following permissions:
thumbnailPhoto
userAccountControl
pwdLastSet

Note: I tried to set the permissions on thumbnailPhoto without including the other two attributes and the sync failed in precisely the same manner as it had previously.

After granting these rights in my development domain and kicking off a User Profile sync I saw the PictureURL attribute appear in FIM and it successfully updated Active Directory. However, when I repeated this process in our production environment I still had the same behaviour as before. At this point I had another look through the ULS logs in painstaking detail and this time I paid attention to two certificate errors (more on that tomorrow). But before pursuing any certificate troubleshooting missions I made a note and hit the search engines one last time in anger.

SQL Native Client

In my searches I also found that FIM 2010 requires the SQL 2008 Native Client on installations where SQL is installed on another server. My development environment has local SQL but production uses a shared instance. I tried to run the installer for the Native Client in production but was notified that it already existed. On reflection, I remembered this is installed by the SharePoint 2010 pre-requisite installer, which explains why this issue is being reported by full FIM users and not by SharePoint 2010 users. However, it’s worth noting this requirement here in case someone has an overzealous administrator that decides to remove the Native Client.

SSL

It will turn out that my production environment requires additional work because the MySite web application is SSL-secured. I will go over those requirements in my next post, although it should not be necessary to follow those steps unless the User Profile Service Application is reading data from an SSL-secured site.