2

In a test SharePoint environment, I have configured the User Profile Service, and the user profiles have been successfully populated into the UPS using the User profile Synchronization Service from the targeted domain. The data in the user profiles correctly reflects the data for the user in AD. In particular, the data for the following fields (the fields shown in a People Picker used on a CBA site) are showing correctly in UPS:

  • Display Name
  • E-mail
  • Address
  • Title
  • Department
  • Presence
  • Work Phone
  • Location

However, on a site that uses claims based authentication, whenever a search is made for a specific user in the People Picker control, when the user is displayed in the List View, no values are being displayed for Work Phone or for Location, even when values are appearing in UPS and in AD. The correct details are being displayed in the People Search results for specified users, and in the user’s Profile pages.

The search service metadata properties for the various fields (WorkTelephone, Location) have been checked and are correctly mapped.

I thought that column data was missing because of a synchronization issue between the UPS and the site’s User Information List. I tested this by updating various field values (including the work phone and location) for a specific user in UPS. When the User profile to SharePoint Quick Synchronization timer job was ran, the data in the Profile page, the people search results and the information displayed for the user in the User information List all updated correctly. The information for the same user in the People Picker is not updated – the work telephone and location are still not displaying values, and the other fields such as display name are not displaying the updated information.

The current SharePoint patch level (build version) for each environment is 14.0.6120.5006 (SharePoint 2010 Server with SP1 and April 2012 CU applied).

Can anyone help identify why the user information shown in the PeoplePicker control isn't showing the correct information? Thanks.

Improve this question

1 Answer 1

Reset to default
1

I believe the April 2012 CU was pulled because there was a regression in it. Might be one you want to get off, June 2012 has been released and so far so good I believe.

If you have some kind of one way trust relationship going on (considering this is a test env) then you need to do something funky with the people picker

Run the command to create the generate the 'key' 

stsadm -o setapppassword -password SomeRandomPassword stsadm -o setproperty -pn Peoplepicker-searchadforests -pv domain:domainB.local;domain:domainA.local,domainA\account,password -url http://webapplication 

Example: stsadm.exe -o setproperty -url http://portal -pn "peoplepicker-searchadforests" -pv "forest:domain1,domain1\adminaccount,Password;forest:fqdn.internal;domain:domain2,domain2\adminaccount,Password;domain:fqdn2.internal"
Improve this answer
1
  • Thanks for your answer. I actually have two environments, one patched to the April 2012 CU, the other to the December 2011 CU, both using the same domain, both exhibiting the same problem. This would imply that it isn't an issue introduced by the April 2012 CU. I'll re-run the STSADM command to configure the PeoplePicker for cross-domains searches, but this has already been done. Thanks.
    – Tangiest
    Commented Jul 5, 2012 at 8:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.