Recently, while working on testing a newly developed SharePoint publishing site, I was trying to test the search features. Although I had run a crawl, and there was content there, none of the content from the site I was testing was showing in any of the results.
What’s an administrator to do, right? Of course, I went directly to the Shared Services Provider (SSP) to investigate. What I found was interesting. I noticed that the site kept showing the following in the crawl logs:
The object was not found. (The item was deleted because it was either not found or the crawler was denied access to it.)
So I thought okay… let’s check the permissions. I logged into the site using the search access account, and was able to get in fine. Whoops, there’s that deceptive permissions error that shows up even though it really isn’t permissions.
So I ran another crawl and watched for the error to pop up in the crawl logs again. I made note of the time, and then went to the ULS logs. What did I find there?
08/06/2009 17:42:41.32 mssdmn.exe (0x1140) 0x14CC Search Server Common PHSts 0 Monitorable ***** Couldn't retrieve server http://<server name>:35513 policy, hr = 80041201 - File:d:\office\source\search\search\gather\protocols\sts3\sts3util.cxx Line:558
08/06/2009 17:42:41.32 mssdmn.exe (0x1140) 0x14CC Search Server Common PHSts 0 Monitorable ****** Server <server name>:35513 security initialization failed, hr = 80041201 - File:d:\office\source\search\search\gather\protocols\sts3\sts3util.cxx Line:318
08/06/2009 17:42:41.32 mssdmn.exe (0x1140) 0x14CC Search Server Common PHSts 0 Monitorable CSTS3Accessor::InitURLType: Return error to caller, hr=80041201 - File:d:\office\source\search\search\gather\protocols\sts3\sts3acc.cxx Line:1567
08/06/2009 17:42:41.32 mssdmn.exe (0x1140) 0x14CC Search Server Common PHSts 0 Monitorable CSTS3Accessor::InitURLType fails, Url http://<server name>:35513, hr=80041201 - File:d:\office\source\search\search\gather\protocols\sts3\sts3acc.cxx Line:184
08/06/2009 17:42:41.32 mssdmn.exe (0x1140) 0x14CC Search Server Common PHSts 0 Monitorable CSTS3Accessor::Init fails, Url http://<server name>:35513, hr=80041201 - File:d:\office\source\search\search\gather\protocols\sts3\sts3handler.cxx Line:243
08/06/2009 17:42:41.32 mssdmn.exe (0x1140) 0x14CC Search Server Common PHSts 0 Monitorable CSTS3Handler::CreateAccessorExB: Return error to caller, hr=80041201 - File:d:\office\source\search\search\gather\protocols\sts3\sts3handler.cxx Line:261
08/06/2009 17:42:41.55 mssearch.exe (0x0F10) 0x091C Search Server Common GatherSvc 0 Monitorable TraceHealthStatus application 'ae391ddf-d6f6-4997-b259-d17acb225b8a': Everything appears OK - File:d:\office\source\search\search\gather\gthrsvc\gthrapp.cxx Line:5865
That makes lots of sense, right? So I got to the web and begin to search and of course, one of the most common things I find is the dreaded Loopbackcheck. Wait, I thought I already fixed that on this server, so let’s check. It’s a dev machine, so I used the second option and ensured that it was listed properly in my registry. Yep, all there.
By now, I am really scratching my head. What could be causing it to do this? What have I missed. Then a light bulb went off… What if it can’t crawl this site collection because there isn’t a top level site collection? I hadn’t created one, because we were only developing a site collection that would reside at http://<url>/sites/<site collection>. There was no http://<url> site collection. The plan was to create this site collection, make sure it all worked, then back it up and restore it in another site in QA, then production… you get the picture. So I create a blank top level site collection. Guess what!!!!???? It crawled fine, and all search results show correctly.
What have we learned? Next time check the simple stuff first! And remember… you have to “crawl” before you walk!
Happy SharePointing!