The crawling on our intranet and internet based support site stopped working for some reason. The crawl log showed an access denied for the default account. I tried reentering the password and I confirmed the account wasn’t locked out but everything was ok. I was even able to access the sites with that account.
Then I tried accessing the same sites from the server and that didn’t work. I would be continuously prompted for credentials. I tried accessing other WSS/SharePoint sites not hosted in the same farm: the authentication worked. I tried accessing another .net app on the same server using http://localhost:xxx that worked too. So the issue was really isolated to our sites.
Next, I looked at the IIS logs and searched for the win32 error code returned when denying authentication: 2148074252.
I found a couple of posts referring to a IIS 6 issue and a kb article from MS: http://support.microsoft.com/kb/896861
This matched exactly my problem: our site used host headers so that’s why I couldn’t authenticate.
The solution I used was however not the one from the KB article as this could be a security threat. Instead, what I did was to add an alternate access mappings for each site using the server name and a different port: 81, 82, etc… and then index these sites using these new urls.
The crawl went fine and the documents were searcheable again.
Note: if you follow the same steps I did, make sure to update your crawl rules, authoritative sites and scopes definitions as they may have an impact.
No need to update the search results however as users will continue to access the WSS site using the normal url so the documents will continue to have same urls in the search results.
Del.icio.us |
Digg It |
Technorati |
Blinklist |
Furl |
reddit |
DotNetKicks