I just came across this one with one of my SharePoint 2010 customers.
They were facing this error message in their crawl log for 3 lists and couldn’t figure out what’s the issue. When they tried to browse the list everything looked fine, except for that the view was a access based datasheet view.
So we started looking into this issue by drilling into the ULS logs and found the following:
CSTS3Accessor::Init fails, Url sts4s://yoursite/siteid={GUID}/weburl=yourweburl/webid={WebID}/listid={ListID}/viewid={viewI}, hr=8004FD0F [sts3handler.cxx:312] d:\office\source\search\native\gather\protocols\sts3\sts3handler.cxx
We also checked the IIS logs on the crawl target server and found the request for this particular element in the IIS log returned a 200 OK.
One of the first things you will find on the internet when searching for this issue, is to check the useragent settings on your crawl servers which you can find in the registry of the box under:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office Server\14.0\Search\Global\Gathering Manager\UserAgent
The common statement is to update the user agent string, or at least the Internet Explorer (MSIE) part of it, to represent a more up to date user agent. (Out of the box it shows version 4 – which we also could see in the IIS logs of the crawl target).
So we gave this approach a shot and changed the registry values, rebooted the servers and started a full crawl… and after all those steps we felt pretty confident to get rid of those errors… but after the crawl was done when we checked the crawl log, for sure the errors still persisted.
So after checking one more time that we had all the registry keys done right we cranked up verbose logging for search ready to start drilling deeper into the issue. Unfortunately the ULS logs turned out not to be of great help.
So we went to the crawl server and tried browsing the page again, even looked at the zone settings and everything looked just fine.
On the edge of desperation we came up with the idea to login as the search crawl account and try to browse the page and BOOOM here SharePoint is screaming at us with a nice big error message, which basically told us that the list has exceeded the threshold for lookup columns (which out of the box is set to 8).
This Access WebDatabase had 16 lookup columns. So for testing purposes we changed the threshold in central admin to be 17 and started a incremental crawl and voila all our crawl issues disappeared from the logs. Obviously this should not be the final fix and my customer agreed to change the design of the list to reduce the amount of lookup columns. But at the end the crawl logs in SharePoint told us the truth even though as so often they didn’t tell us the whole story…
Hope it helps.
