www.johntimney.com

You might be suffering from something called a Security only Crawl.

http://blogs.msdn.com/russmax/archive/2009/02/09/troubleshooting-security-only-crawl.aspx

One possible fix for this is to install the Feb 2009 MOSS Hotfix cummulative package.

http://support.microsoft.com/kb/967209/

Although, I've not suffered from this specific problem it can be a bit difficult to identify a root cause. Generally, security only crawls impact MOSS farms that make heavy reliance on Sharepoint groups and don't use AD groups, causing a ripple of unapplied ACL changes that Index has to force apply as it indexes.

As with any hotfix, especailly a cummulative one - test, test and then test again before you install this to live!

If you are running MOSS on Windows 2008 you can get an error whenever any file over 28MB is uploaded. This happens regardless of what the max upload size is set to for the web application and the usual error is a 404 File Not Found, somewhat confusing really!

When you make a change to the web app settings from Central Admin they do not get transfered to the web.config. So you must manully update the web.config for all web apps and all Web Front End servers needing this change.

You need to add add the following settings under the section of the Web.config file found in Inetpub\wwwroot\wss\VirtualDirectories\VirtualDirectoryFolder:

This solved the issue for me.

Ok, this is a beauty! Deep searches, like advanced search queries or adding codeplex components like faceted search that make use of ordered search results between web front end servers and offset query servers appear to grind to a halt, deadlock the web app and force a recycle. The recycle may be an automatic one, or may have to be forced to get IIS to recover. However, this wasn't easily seen as the system was live and the users were just using the soltuion, when it would suddenly grind to halt. It was not something you could predict and we first thought it might be down to excessive load although the system was configured far in excess of the NFR requirements for transaction per second.

It took an age to track this one down and we were simply lucky that one of the chaps in the team spotted a slow down when another team member did something related to faceted searching, and data sorting. This only actually led us to realise it was connected to search somehow, but it at least allowed us to reproduce the problem and we could now regularly bring the platform to its knees. So, it was likely to be Query server related.

Taking a look at the even logs on the query servers, it was apparent one of them had dropped out of the MOSS farm. The error was "Source: Office Server Search EventID: 10038 Level: Error Query machine 'machinename' has been taken out of rotation due to this error. We had three of them and one missing from the rotation cycle was a clear indicator it was strugglng with something, although as the error was only on 1 server, it was not symptomatic of the problems we were having as it was the only one of the three query servers to be showing any event log errors. It merited further investigation however now we had some correlating evidence of root cause.

The rotation cycle error led me to a recently released KB description which had something in it that was very interesting: "the client computer stops responding for about two minutes". Our very symptom, as the WFE servers are clients to the offset role Query Servers! Even though it doesn't mention it could occur in this type of transaction scenario between a WFE server and a Query server.

Applying the hotfix solved this issue, and we suddenly stopped having server restarts due to deep search queries.

http://support.microsoft.com/kb/946487