FullTextSQLQuery and the Like statement in SharePoint 2010

At my current client, we encountered an issue with some of the custom search web parts. In these web parts, we would perform a custom FullTextSQLQuery against the search index using the Like statement against custom created managed properties. Somehow, the search did not return any results, no matter what the keyword was.

This behavior was kind of strange and indicated that there must be something wrong with the creation of the managed properties, or the population of these properties. Several steps were taken, like again executing a full crawl, remapping the managed properties and so on.

Still, the search did not return any results. This drove me a little bit nuts until I found a post in the social MSDN by Steve Curran. It turns out, Microsoft changed the behavior a little bit since SharePoint 2010. Managed properties on SharePoint 2010 have an additional setting called ‘Reduce storage requirements for text properties by using a hash for comparison’ that influence the way the query behaves when using the Like statement (or the contains statement for that matter). If not checked, any Like comparison against this managed property will always return null, no matter what you put in. Checked this setting, ran a full crawl again and search was working fine.

So thank you Steve!

Advertisements

User Profile Synchronization: Possible solution to the ‘stopped-extension-dll-exception’ message

It has been a while since my last post, all due to delivering my current project. In the next few posts, I would like to share some learning that I obtained during this project, in which we delivered an Intranet site based on SharePoint 2010.

This post is about User Profile synchronization, in particular using the Business Connectivity Services to complete the User Profiles in the store. This post will not go into how we would configure the User Profiles to sync using BCS, and in our case the Secure Store, but will talk about a particular error message you could encounter in FIM. If there is interest in such a post, please leave a comment.

So what is FIM? FIM stands for Forefront Identity Manager and is the driving force behind the User Profiles within SharePoint 2010. It uses two windows services that are connected to the SharePoint 2010 service applications.

When you open up the FIM client on the server (C:\Program Files\Microsoft Office Servers\14.0\Synchronization Service\UIShell\miisclient.exe), you might find the following error at one of the synchronization stages: “stopped-extension-dll-exception“. If you look in the event log, you might see some errors stating exceptions of ” “NoSuchObjectType” or “object user not found” or similar. So what is going on here?

Basically, there could be many things, but this post only describes one possible solution to your problem. You should always verify that the FIM windows services are running; that is step 1. In my scenario, I was updating the User Profile with information from a BCS entity that pulled data from a database. In my case, the cause for this error was the incorrect security setup of the entire chain. So from the Secure Store Service through the Business Connectivity Service down to the User Profile service. Any misconfiguration there can lead to this brilliant detailed and descriptive error message.

In short, we have to make sure that the identity the user profile service is running in (by default the application pool account) has sufficient rights to use the Secure Store Service and the BCS service. The following prerequisites have to be in place to ensure the synchronization will work:

1. Ensure that the account the User Profile Sync (so your FIM services) has access to the Secure Store Application and is allowed to execute them.
2. Ensure that the account the User Profile Sync (so your FIM services) has access to the BCS service applicaton
3. Ensure that the account the User Profile Sync (so your FIM services) has access to the BCS entity and is allowed to use it

Seems simple and it is, but easy to overlook. In principle, the easiest way to check if all the security settings are applied correctly is to create an external list using the BCS entity and log on using the same account the FIM services are running. If setup correctly, you should see the data from your external content type. If so, the User Profile service should be able to use it and as such, can perform the synchronization. If not, then your security configuration is not correct and your synchronization will fail with above error message.

Hope it will help someone! I will try to make some more time in the near future to write up some of the learnings.

CU