Search Not Working? Might be that an update has clobbered it…

I’m starting to hit this problem so much lately that it’s now one of the first things I look for when a client calls me and indicates their search is not working properly. It also seems to affect authentication in other cases, and is more likely to occur in demo environments where everything sits on the one box (including the browser being used to access the site) – Mark Harrison’s hit the issue recently too…

A security bulletin came out on November 11th 2008 that discusses a remote code execution vulnerability. Almost all versions of Windows are affected by this vulnerability. SharePoint systems on <= Windows 2003 SP1 or Windows 2008 server have this patch installed. Implementing the patch causes an indexing server to fail when it attempts to index a site that is:

  • Hosted on the same server and
  • Uses a host header / DNS entry instead of a machine name and
  • Is being indexed using aforementioned DNS Entry
  • The site runs under a named account (an AD or Local Computer account, not say “Network Service”)


  • You will see errors in the indexing log that indicate access is denied to the web sites
  • You will see Errors in the Windows Security log that indicate Event ID 537 has occurred – this error will list the user as the crawling account used by your indexing engine, a logon type of 3 and a Logon process containing some unusual characters such as Ðùº
  • You will not be able to search for content that would normally be returned on those sites

The text from the error is:

"Access is denied. Verify that either the Default Content Access Account has access to this repository, or add a crawl rule to crawl this repository. If the repository being crawled is a SharePoint repository, verify that the account you are using has "Full Read" permissions on the SharePoint Web Application being crawled."


The patch that was rolled out as part of the 2003 Service Pack and with Windows 2008 Server disable the service account’s ability to use cached authentication credentials to access the local resource – this prevents an authentication token playback exploit that the patch fixed.


There are 2 resolutions, neither of which involve modifying SharePoint or the security granted to the account. On the server running the indexing service, you need to enable a registry key that either:

  1. Enables an authentication request to be cached for a specific DNS name, or
  2. Enables all authentication requests to be cached for that computer (disabling the hotfix’s change).

Option 2 needs a reboot. Now let’s say that you have a server farm. Every time you add a new web application with an Alias and you go with option 1, you need to apply the Registry update so that the site can be indexed. In most enterprises, this would be "discovered" post-Search implementation until it happened so often that it became annoying – and a process was put in place to update the registry key along with creating a search site. I can’t see many people buying this "Best Practice" option unless they work for a bank or somewhere with sensitive information. Here is the info from KB Article 896861:

Method 1: Specify host names

Note: Microsoft recommends that you use this method.
To specify the host names that are mapped to the loopback address and can connect to Web sites on your computer, follow these steps:

  1. Click Start, click Run, type regedit, and then click OK.
  2. In Registry Editor, locate and then click the following registry key:


  3. Right-click MSV1_0, point to New, and then click Multi-String Value.
  4. Type BackConnectionHostNames, and then press ENTER.
  5. Right-click BackConnectionHostNames, and then click Modify.
  6. In the Value data box, type the host name or the host names for the sites that are on the local computer, and then click OK.
  7. Quit Registry Editor, and then restart the IISAdmin service.
Method 2: Disable the loopback check

Follow these steps:

  1. Click Start, click Run, type regedit, and then click OK.
  2. In Registry Editor, locate and then click the following registry key:


  3. Right-click Lsa, point to New, and then click DWORD Value.
  4. Type DisableLoopbackCheck, and then press ENTER.
  5. Right-click DisableLoopbackCheck, and then click Modify.
  6. In the Value data box, type 1, and then click OK.
  7. Quit Registry Editor, and then restart your computer.

This is just one of those Search Issues that is not immediately clear… hopefully this saves someone more troubleshooting time than it cost me 🙂
The only other mention I have seen of this issue specifically relating to SharePoint was here – – Thanks Darren for pointing me in the right direction 🙂


About Brad Saide

I'm a SharePoint consultant. I'm also slowly going bald, seem to have a permanent spare tyre around my waist and enjoy socialising with friends over a beer or 10. The last 2 may possibly be related. Started working with SharePoint when the first version was in limited beta release (participated in the Technology Adoption Program while at Woolworths) and have been committed to the adoption of the technology as a business enabler ever since.
This entry was posted in Uncategorized. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s