Ben There, Done That

The other day I went to deploy a solution to our SharePoint farm and got the following error in the Solution Management in Central Administration.  Some important background info is that this solution first created a Web Application.

We have a 4 server farm and the solution wasn’t deploying to any of the servers.  Looking at the event log, we had several different errors all containing the text (the event ID for all of them was 6398):

Error during encryption or decryption. System error code 997.
Error during encryption or decryption. System error code 0.
Error during encryption or decryption. System error code 122.

All of these were based on a time job provisioning something, either the web application or the solution, or come to find out, some of our search services were having errors starting.  The web application for this solution was being created on one of our servers, but failing on the other three (this was what was actually holding up the solution from being deployed).

After doing some searching everyone gave two options:

1. Recreate your SharePoint Configuration database…yeah right, this is going to be our VERY LAST attempt.

2. Run stsadm –o updatefarmcredentials (if you want to stop reading here, run this command first and it should fix the errors listed above…ONLY if this doesn’t work consider recreating your SharePoint Configuration database)

Neither one of these really seemed to make sense, we created all 4 servers in the farm from scratch, install SharePoint on all of them at the same time, created about 8 web applications that had all provisioned fine already, and never made any changes to user credentials (as some posts suggested).  Since the web application was being created fine on Server 1, we started looking at servers 2-4 as to what happened that would block a web application from being provisioned.  We couldn’t find anything.

Finally, we looked at Server 1.  This server had a timer job running with a different credentials than Servers 2 – 4.  Come to find out, when the install had been done, for some reason SharePoint was installed on Server 1 with one set of credentials and on Servers 2 – 4 with a complete different set of credentials.  After realizing this, we conceded to the fact that yes, user credentials are probably all messed up in our SharePoint Configuration database.  We ran the stsadm –o updatefarmcredentials command this morning and all of a sudden the web application could be created, search services started and solutions were able to be deployed.

I’m still baffled as to how our original 8 web applications were created and how solutions were properly deployed previously, but hey, at least everything is fixed now and set up properly.

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.

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.

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.

One of the best new features of SharePoint 2007 is search. I was at a client’s the other day, working on search and we were getting some results back to certain queries, that contained information in the summery (or the Hit highlight area) that we didn’t want people seeing. I spent considerable time going over all the metadata of the pages, removing everything I could think from the metadata being crawled on the content, resetting the content and re-crawling the data. The information just wouldn’t go away. Because the pages themselves were fine to show up in the search, just not the hit highlight information, I decided to customize the search experience.

I performed the search returning the content and started editing the search results page. I opened up the web part properties of the Search Result Core web part and started editing the XSL. There is a line in the XSL that is:

And goes on to say, display the high highlighted summery. I simply changed this line to read

Because the information is case sensitive, and the information was showing up both in upper and lower cases, I had to put both cases in. The allows the results of the certain search query to still appear, however, the hit highlight summery that contained the information is hidden from view.

Just another example of how the customizability of SharePoint can be used to enhance and secure a users experience.