SPSearch Unable to Index WSS 3.0 Content Source

I’ve recently been running into problems with search on several WSS 3.0 SharePoint sites. It simply wasn’t returning results. They’re all configured the same way, so it’s no surprise that they’re all experiencing this problem. If it was MOSS, I would’ve had this resolved by now. I’m just not as fluent with WSS and familiar with its limitations. I’ve run out of GoogleFu mojo on this one, and ended up having to go through trial-by-error and spending several days banging my head on my desk before I figured it out. So here it is!

There are tons of discussions and HowTos out there that have a lot of great info and starting points. Those did not help with my scenario.

Sure, I verified that search was configured and that I had an Index server defined. I’ve even reconfigured search several times (I think the database name is appended with “_5” or so by now). I’ve tried the different loopbackcheck fixes to no avail. Literally, no change. The default AAM zone is NTLM. This was not a permissions issue for us. Our AAMs are configured properly and the portal works great in every other aspect. I’ve stepped through just about every search troubleshooting checklist that I’ve found, with no impact.

Here’s the scenario, and ultimately the root of the problem:

Single server farm. Pretty standard, except the web app was extended to have FBA. There’s an external HTTPS URL being redirected via ISA. The site’s internal URL is HTTP://servername:##/sites/yaddayaddaortal/

And there it is. The cause. Check this out:

The event log reports that it cannot crawl the content source at sps://servername:##/ (minus the /sites/…). Well, yeah, of course not. There’s no site there. I looked everywhere to see if I could configure the search content sources to change that. This appears to be a hard-coded assumption on behalf of WSS? I have yet to find a way to change this. The kicker is that this appears to be a road block for the search crawl. If no site is found there, then it simply stops before it even gets started.

Solution:
Make sure you have a site defined at “/” – even if it’s not THE site collection that you’re using. And make sure that it’s NTLM. I created a blank site, titled “Search” with a description to simply state that it’s required for search to work. No users actually have access to this site collection except for the admin. I ran another full crawl – fixed! No more errors in the event log, and now search returns results.

This was so simple, that I’m not sure what took me so long to try it. I was definitely overthinking it. We could just not have created these sites under the /sites/ managed path to begin with, but it was a business requirement, so I was stuck with it (for now). 🙂

No Responses

There are no comments.

Comments are closed.

For questions and feedback on this entry, send me an email.