We have been having an issue with our search indexing and crawling in one of our SharePoint farms. The problem is that after an undetermined set of time, pretty much all search queries wind up returning several results that show nothing but an IE icon. The result isn’t attached or any page or give any textual information. Obviously best case would be to figure out what causes this error, but at this point in time we haven’t been able to find the problem.
However, what we have discovered is that simply resetting the search index and running a full crawl will solve the issue.
So…until we can solve the issues, I wrote a small SharePoint timer job that simply resets our search index right before a scheduled full crawl runs. I used Andrew Connell’s post (http://www.andrewconnell.com/blog/articles/CreatingCustomSharePointTimerJobs.aspx) to develop the Timer Job, Solution and Feature and modified it and was able to find the following code on http://www.sharepointdev.net/sharepoint–development-programming/programmatically-reset-all-crawled-content-41959.shtml that I inserted into the timer job frame work in order to automatically reset our index on a regular schedule to minimize the risk of our search issue effecting the end users.
try
{
SearchContext sc = SearchContext.GetContext(ServerContext.Default);
sc.Reset(true);
}
catch (Exception ex)
{
throw new InvalidOperationException("Unable to reset content index.", ex);
}
For some of you, this may not seem like much, but coming from the SharePoint Administration/Configuration side of SharePoint and having very little real development experience I was rather proud of myself.
SharePoint is designed to security trim your search results based on your user ID, a great feature to have in SharePoint as you don’t want search to return results of pages and content a user doesn’t have access too. However, this requires one extra “step” at times when moving a site from development to testing or even to production.
I’m sure this topic has been blogged about before as this isn’t the first time I’ve run into it, but I figured I would write a short post about it for anyone that encounters what would appear to be an issue with their Search in SharePoint.
The scenario: You have been building out a SharePoint site and you are ready to release it to the rest of your users. You have tested everything using your own credentials. You add a new user to the site with credentials equivalent to your end users and start testing with those credentials before going live. Everything is working as expected…until
The problem: Your perform a search…You go to your search page, search for some well known content that you know should be returned, but you get no results in SharePoint search. Your navigate to the page and you have access to it and can view the content you are searching for. To further test, you run a few more searches, but everything comes back with no search results.
The resolution: When SharePoint performs a crawl (incremental or full) it looks at all your content AS WELL AS who has permission to access the content. If you add users to your site, and immediately try a search before running a search crawl, the search index still has that the newly added user doesn’t have access to the content. So, if you are going to add new users to the site that need access to search, or you are going to be testing search, immediately after adding those new users, run an incremental crawl so your SharePoint search index can pick up that these new users actually have access to the content you are searching for.
That’s right, Microsoft latest ravamp of their search engine is not available and it is called Bing. Go check it out and www.bing.com. First off, I’m glad they changed the name from Live to Bing. Live Search just wasn’t unique enough. I’m interested to hear others thoughts on the name change as well.
I haven’t had a ton of time to play with the search, but the little I have done has seemed to be pretty good. Results from a search are similar to Google but not exact, which is to be expected. For all I know at this point in time, they could be better. I think a presupposition that “Google is always right” has been developed over the last few years, and who’s to say their search results will continue to be the best? I think every “new” search that comes along should be tried and evaluated as you never know when something better might come along. With that said, I’m definitely going to give Bing a shot.
Lastly, I do think it is rather interesting how similar the Bing interface looks to the Google interface. This is the biggest thing I’m not a fan of…not because I don’t like the interface, but it would be nice to see MS come up with an interface unique to their own. I understand, Google’s interface works for them, people like it, so why not model after their interface…it would just be nice to see a unique search interface some out of Microsoft as well, who knows, maybe something unique and different could be better that Google’s…you never know.
I was working with a client the other day who was having problems with search. They had a SharePoint site that search couldn’t crawl. The first thing to check was obviously permissions and those all worked fine. I started digging into it and found it was the error: “Error HRESULT E_FAIL has been returned from a call to a COM component.”
When looking for a fix I ran across this post in the TechNet forums that gave me the answer. Your web.config file may have identity impersonate=”false”. Sure enough, I looked at the web.config and impersonate=”false”. I changed it to =”true”, performed an iisreset and reran the full crawl. Success!! The downside…it did indeed break a custom feature that was installed in the farm. So now we are on to fixing that problem.
February 12th, 2009
admin
Details are starting to surface about SharePoint “14”. One of the details that has been solidified in the last couple of days is the integration of Microsoft’s acquisition of FAST Search into SharePoint “14”. Microsoft made the first step towards the integration this past June when they released FAST Search web parts for SharePoint 2007.
It will be exiting to see details of SharePoint “14” continue to emerge and the growth and expansion of the SharePoint platform and search in particular in this case.
I had a strange problem the other day with search. I was working with a SharePoint install after stsadm had been used to move the search index. There were quite a few errors being thrown including errors about the index when we would go in and set up content sources. We tried resetting everything in the Search settings, deleting and recreating SharedServices, all new databases and running the configuration wizard again and checked all permissions. All of this was done to no avail. It appeared that no matter what we did, the farm wasn’t moving over/recreating the index files in the new locations.
Finally, we removed the search server from the farm, ran a repair from the Windows Add/Remove Programs and re-ran the configuration wizard to re-join the server to the farm. We made sure than the new file location for the index files was still set, and continued to re-setup everything to enable search. Bingo!! That worked!! So, if you are having problems with your search server no matter what you try, give this a shot.
Today was the day for new PDF iFilter information to be posted. First of all, Adobe FINALLY released their 64 bit iFilter for SharePoint, it can be download here. I haven’t tried it out yet, but I have a 64 bit install all ready to try it on. I’ll put up any additional info once I install it and try it out. This leads me to my second announcement.
Before you rush out and download the Adobe version, if you have a lot of PDF files or are concerned about crawl times, you may want to check out the FOXIT PDF iFilter. Here is a performance analysis of the 32 bit iFilter from Adobe and FOXIT: http://blogs.msdn.com/ifilter/archive/2007/11/14/foxit-vs-adobe-pdf-ifilter-32-bit-only.aspx. Based on this analysis, I would be surprised to see similar results with the x64 bit version from FOXIT and Adobe will be similar. The disadvantage of FOXIT however, is that you do have to purchase the iFilter where the one from Adobe is free.