[2 days left] What’s wrong with your cloud strategy? Learn why multicloud solutions matter with Nimble Storage.Register Now


SharePoint Search Crawler "Start Address" Change Failing

Posted on 2013-01-14
Medium Priority
Last Modified: 2013-02-04

I am working on a SharePoint farm with multiple app servers and multiple WFEs. One of my app servers is dedicated to search, and one of my WFEs is dedicated to just being crawled for content.  

I have a number of web applications. One is a multi-tenant site. It isn't partition for search purposes, however, and has a single crawler that picks up all of the content.

It was setup so that the single content source for the crawl uses a start address of: https://localhost. In the HOST file on the app server the search service runs on, localhost was pointed to the IP of the WFE set aside for crawling, instead of So, when the search starts out on the app server it sees localhost, but is actually directed to the IP of the WFE to crawl based on the HOST file modification.

This recently caused problems with another service on that app server which needed the localhost entry to be the true loopback.

I decided to change the address to resolve the other issue and to follow best practices, and figured a similar trick would work. I added an entry to the HOST file on the app server that pointed to the same IP. I made something up, calling it: searchcrawlwfe. I then changed the content source start address to point to https://searchcrawlwfe instead of https://localhost. This seemed to me to be a simple enough substitution.

Yet, the search crawler fails with error: "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. (Error from SharePoint site: HttpStatusCode Unauthorized The request failed with HTTP status 401: Unauthorized.)"

Nothing else changed. It is still the same account that was crawling successfully before, same settings, same everything. I ensured the disableLoopback was set properly, which it was before. The ignore SSL was set to YES, as it was before. All I did was make the switch to the "start address."

Why would I get that error by moving from a crawler start address of: https://localhost to https://searchcrawlwfe? The HOST file was doing the same thing for both, as both localhost and searchcrawlwfe point to the same WFE IP. I tried a few other variations, such as pointing to: https://<COMPUTER NAME> and even https://<IP ADDRESS>. While all three of those resolved in a web browser to the same location in the WFE that https://localhost did, neither of the three attempts worked for search crawler purposes.

How can I properly use a non-localhost start address for this content source?

Question by:jkeagle13
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 2
LVL 15

Accepted Solution

colly92002 earned 2000 total points
ID: 38775970
I would guess that the path that is now being used has aditional security over the localhost route.  It wil be down to the account that the sevice is running under not having enough permissions on the site somehow.

Check IIS - look at the web application and check the permissions.  If you can, log in as teh account that teh search service runs under and try to browse to the site.  If this doesn't clearly show you what is wrong, then use the uls viewer (http://ulsviewer.codeplex.com/) to analyse the log files and it may tell you more information about which account is failing.

Author Comment

ID: 38780454
The log files are very unhelpful. The only error shown is related back to the "access denied."

The oddity is that the account must have access - it is the same account that works fine when the start address is: "localhost." The account has elevated privileges and is dedicated to serve as a search crawler.

My hunch is that this somehow relates to the multi-tenancy, and the fact that multi-tenancy has issues with setting different hosts.

LVL 15

Assisted Solution

colly92002 earned 2000 total points
ID: 38782339
I think you are correct - I have a feeling that using localhost means that you will not going through the same authentication process as using the full address.  It may even come back to the dreaded "double hop" problem if you are using NTLM rather than kerberos.

Is it possible to change the account you use to the system account used to run the for the web application or even the app pool account?

Featured Post

Industry Leaders: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Issue: One Windows 2008 R2 64bit server on the network unable to connect to a buffalo Device (Linkstation) with firmware version 1.56. There are a total of four servers on the network this being one of them. Troubleshooting Steps: Connect via h…
Make the most of your online learning experience.
Monitoring a network: why having a policy is the best policy? Michael Kulchisky, MCSE, MCSA, MCP, VTSP, VSP, CCSP outlines the enormous benefits of having a policy-based approach when monitoring medium and large networks. Software utilized in this v…
Michael from AdRem Software outlines event notifications and Automatic Corrective Actions in network monitoring. Automatic Corrective Actions are scripts, which can automatically run upon discovery of a certain undesirable condition in your network.…
Suggested Courses

649 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question