SharePoint Search Crawler "Start Address" Change Failing


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?

Who is Participating?
colly92002Connect With a Mentor Commented:
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 ( to analyse the log files and it may tell you more information about which account is failing.
jkeagle13Author Commented:
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.

colly92002Connect With a Mentor Commented:
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?
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.