All my posts are provided "AS IS" with no warranties, and confer no rights.

My Colleague Tag , or “there is no timer job…”

The question that generated this post was: “What timer job needs to run in order for the Colleagues tag to become in effect and to be displayed as such in the search results page ?”

While this might seem trivial to some, there is a valid point behind the question, now with the multitude of social elements that come in play in SharePoint. Why, sometimes after adding a colleague it is displayed as such within minutes and sometimes within hours? What data needs to be synchronized between the Profile DB and Social DB. What TImer JOb does that?

Well, let’s start with the beginning:

If we are talking about search results, the very first pointer is that the colleague tag MUST be in the index.

On the first SSA Set-up this property is not by default indexed so we need to manually add it

Go to search settings-Managed metadata, crawled properties, search for Colleagues, set it to be “included in index”.

Launch a full crawl. After the crawl is complete, the Ranking phase occurs. During this phase, we compute the relevance of the items based on common properties ( in our case we compute the social relevance of the crawled items(profiles). This also updates the flag that is used in People Core Results WebPart to idfentify a direct colleague or a colleague of a colleague – see below ).

o Sent items in Outlook. Periodically (every 5 days or so, depending on usage) Outlook analyzes Sent Items for common recipients, weighted by frequency of contacts and other factors. This is how Outlook is able to suggest likely recipients when you begin typing their name in the To: line, and in my experience, it seems to work pretty well. When you click Suggested colleagues, it collects these names from Outlook via an ActiveX control, and adds them to the list of suggestions.

o Office Communicator contacts are examined; that is, those contacts that you’ve added to your Office Communicator client from the company directory. These are also collected from the Communicator client via an ActiveX control.

o Site Memberships are all sites in which you are explicitly included in the "~Members" group for the site (where ~ is your site name). Other users who are also explicitly included in the ~Members group on those sites are suggested as your colleagues. This information is collected by a WSS profile synchronization timer job.

o DG (Distribution Group) Memberships are examined for suggestions. Distribution groups stored in AD are collected during the AD import.

…. “

When we add a user as a colleague, the information is added into the User Profile Service Application database – Table name is UserColleagues , we perform this through the QuickLinksAdd stored procedure: http://msdn.microsoft.com/en-us/library/dd774764(office.12).aspx. Many thought this data needs to be replicated into some additional profile/social related DB before it will be displayed.

No. The data resides only in this db and is getting picked up by the crawl as per above.

To summarize:

There is no timer job that will update the flag. You just need to allow the crawl to complete the Ranking Phase.

Now, since this can take some time , a tip to improve the speed of the process:

Set up a content source that would ONLY Crawl the profiles (sps3://mysitehost). This would ensure the crawl will only execute the ranking for the profiles, faster, not all the items that are crawled.