Larry Kuhn

Midwest Bloggers

	Arbindo Chattopadhyay
	U.S. Midwest SharePoint Community
	Ram Gopinathan
	Larry Clarkin
	Kevin Hammond
	Dave Bost
	Angela Binkowski
	Andrew Ehrensing
	John West

User Groups

	Chicago SharePoint User Group
	Chicago .NET Users Group
	Chicago Windows User Group
	Chicago Visual Studio Team System User Group

Other Blogs

Directory of MS Team Blogs

Links

4/19/2009

SharePoint Index Server Local Crawling affected by MS09-014 - KB 963027

Many customers I know have taken advantage of the "Index Server Local Crawling" tip that was published a long while ago by Joel Oleson over here: http://blogs.msdn.com/joelo/archive/2007/02/06/use-a-dedicated-web-front-end-for-crawling.aspx

Recently, Microsoft released "MS09-014: Cumulative security update for Internet Explorer" which, among other things, closed a vulnerability in NTLM authentication. Details of the security update are listed here: http://support.microsoft.com/kb/963027

Basically, there was a potential “man in the middle” security issue with NTLM authentication that has been mitigated by implementing the following behavior: If you’re browsing to your own machine, and the URL you’re browsing to doesn’t match the machine name, then NTLM authentication will fail.

After applying this security update to SharePoint servers, crawls that are configured to use the Local Crawling approach and that use the FQDN as the start address of the crawl will begin to encounter HTTP 401 errors during the local crawl.

The NTLM authentication change was also included in .NET Framework 3.5 SP1, and is described in http://msdn.microsoft.com/en-us/library/cc982052.aspx.

The solution is straightforward, and is documented both in the .NET Framework 3.5 SP1 article I just mentioned and in http://support.microsoft.com/kb/896861. Note that Method 1 is the preferred option to fix it.

Thanks to many colleagues who helped pull together the details here. Hopefully info this will save some folks some headaches.

Posted at 6:37 AM by lkuhn | Category: Search; SharePoint | Permalink | Email this Post | Comments (1)

Comments

alternate solution needed for win2008

This problem reared its head happened after applying these updates to the MOSS WFE; kb952004 kb956572 kb959426 kb960803 *kb963027* . The solution presented here didn't work (but maybe has to do with running on win2008 x64 server). Simultaneous with these symptoms, we got an HTTP 403.14 when browsing to the root (e.g. http://dev-intranet/) Resolved by: 1. detaching content database of the affected site (central admin > application mgmt > content databases, Remove Content Database) 2. create new web application (central admin > application mgmt > create or extend web app > create new web app) with mostly defaults except database authentication & search server 3. created a new site collection in this new web application * observe the ability to get to this new site (central admin > application mgmt > create site collection) 4. detach the database of the new site (central admin > application mgmt > content databases, Remove Content Database) 5. stsadm -o addcontentdb -url http://NewSiteURL -databasename DetachedOriginalContentDB (apparently the attach aspx times out with large databases or is otherwise flaky) 6. go to the crawl log (shared services admin > search settings, view crawl log) * observe crawler sailing through new application's content database 7. edit bindings in IIS manager of the old non-functional Site, change the port to something unused and random, and remove the hostname (i.e. if its mapped to a DNS entry this is the host header info) 8. edit bindings in IIS manager of the newly created functional Site, change the hostname, port, IP address to the desired final state/match the DNS entry (e.g. hostname=dev-intranet, port=80) 9. edit alternate access mappings (central admin > operations > alternate access mappings, edit public URLs for the Collection that was just created in step 2; if your crawl is in progress, move the Default URL to the Intranet URL space. Enter the IIS binding name/host header (step 8) into the Default URL And kung-fu support from microsoft was required to get us back up. Route questions about this resolution to @pritish on twitter.

at 5/20/2009 7:29 PM