Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium


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
  • 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

Free Backup Tool for VMware and Hyper-V

Restore full virtual machine or individual guest files from 19 common file systems directly from the backup file. Schedule VM backups with PowerShell scripts. Set desired time, lean back and let the script to notify you via email upon completion.  

Question has a verified solution.

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

This month, Experts Exchange’s free Course of the Month is focused on CompTIA IT Fundamentals.
Tech spooks aren't just for those who are tech savvy, it also happens to those of us running a business. Check out the top tech spooks for business owners.
Here's a very brief overview of the methods PRTG Network Monitor (https://www.paessler.com/prtg) offers for monitoring bandwidth, to help you decide which methods you´d like to investigate in more detail.  The methods are covered in more detail in o…
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…

577 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