Solved

SharePoint Search Crawler "Start Address" Change Failing

Posted on 2013-01-14
3
1,022 Views
Last Modified: 2013-02-04
Hello,

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 127.0.0.1. 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 127.0.0.1 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?

Thanks!
0
Comment
Question by:jkeagle13
  • 2
3 Comments
 
LVL 15

Accepted Solution

by:
colly92002 earned 500 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.
0
 

Author Comment

by:jkeagle13
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.

Thanks!
0
 
LVL 15

Assisted Solution

by:colly92002
colly92002 earned 500 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?
0

Featured Post

Get up to 2TB FREE CLOUD per backup license!

An exclusive Black Friday offer just for Expert Exchange audience! Buy any of our top-rated backup solutions & get up to 2TB free cloud per system! Perform local & cloud backup in the same step, and restore instantly—anytime, anywhere. Grab this deal now before it disappears!

Join & Write a Comment

Let’s list some of the technologies that enable smooth teleworking. 
PRTG Network Monitor lets you monitor your bandwidth usage, so you know who is using up your bandwidth, and what they're using it for.
After creating this article (http://www.experts-exchange.com/articles/23699/Setup-Mikrotik-routers-with-OSPF.html), I decided to make a video (no audio) to show you how to configure the routers and run some trace routes and pings between the 7 sites…
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…

758 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

Need Help in Real-Time?

Connect with top rated Experts

19 Experts available now in Live!

Get 1:1 Help Now