Staff directory webpart broken after a manual synchronization

Question

On the main page of my SharePoint 2010 I have a Staff Directory web part that uses the User Profile service to sync with Active Directory. I noticed that it was not synchronizing correctly as some accounts that I deleted a few weeks ago where still present.

I then jumped on to my Central Administration and manually started a Start Profile Synchronization. After doing this though my web part is completely broken and displays the following error message:

 0 records found
User Profile Error: No User Profile Application available to service the request. Contact your farm administrator.
User Profile Property not found: PreferredName

I have not changed any other properties in the User Profile Service and I have ensured that the permissions are correct on both the Administrators and Permissions under the Service Applications tab. Any ideas?

EDIT:

Per Christopher W. Szabo's suggestion, I have looked at the Application, Security and System logs on my SharePoint server. I have setup SharePoint to attempt to synchronize every night at 1 am with my Active Directory. I have noticed a few errors that happen exactly at this time and I have listed them below.

From Application Log right at 1 AM:

Detection of product '{90140000-104C-0000-1000-0000000FF1CE}', feature 'PeopleILM', component '{1C12B6E6-898C-4D58-9774-AAAFBDFE273C}' failed.  The resource 'C:\Program Files\Microsoft Office Servers\14.0\Service\Microsoft.ResourceManagement.Service.exe' does not exist

From System Log at 1 AM:

The machine-default permission settings do not grant Local Activation permission for the COM Server application with CLSID 
{000C101C-0000-0000-C000-000000000046}
 and APPID 
{000C101C-0000-0000-C000-000000000046}
 to the user NT AUTHORITY\NETWORK SERVICE SID (S-1-5-20) from address LocalHost (Using LRPC). This security permission can be modified using the Component Services administrative tool.

I am not sure what is going on. It seems as if my local SharePoint service account is experiencing permissions issues but I can not find where.

Answer 1

Can you check the Application, System, and Security Event logs on the server hosting the WFE and the User Profile Service Application? Also review the ULS logs to see if there are any warnings or errors.

What about the application pools? Can you verify that they are running? Do you have any other Service Applications that are experiencing issues?

Answer 2

I know you said you checked permissions, but is your web part using impersonation? The first error usually indicates that you don't have permission to perform whatever operation you are attempting agains the User Profile Service. Does it work if you log in to the page as an Administrator? Did you recently apply a service pack or CU to SharePoint? (Sometimes after a CU the User Profile Service needs atention.)

I would begin troubleshooting from the User Profile Service and work from there. (For example, does the organizational browser work, does people indexing work?)

HTH,

Matthew

Answer 3

The logs indicate that the service account does not have the necessary permissions to interface with the COM services on the server. When I build out a farm I create an Active Directory group called "SharePoint Applciation Pool Accounts" and then I use a group policy preference to add that group to the local member group named Distributed COM Operators on each application server and WFE.

That local member group is granted the appropriate user rights to interface with COM. By adding the domain group that contains the application pool accounts your service applications will be able to interface as well. In addition, depending on the topology of the farm, you may very likely have to open component services on each server and enable Network DTC Access.

This can be done by opening Component Services from Administrative Tools, expinding the folder for Distribute Transaction Coordinator, and the viewing the properties for the Local DTC. On the Security tab, check the boxes for Network DTC Access, Allow Remote Client, Allow Inbound, and Allow Outbound.

That should take care of the issue.

Answer 4

Having had a similar issue I ended up having to give very specific permissions to the 14 hive to resolve this same issue: http://iedaddy.com/2012/01/detection-of-product-peopleilm-failed-the-resource-does-not-exist/