That's added if you specify a server  for the Indexer to crawl instead of
leaving the default of "all servers" or whatever it is. Normally I tell
folks to leave the default and edit the hosts file manually. There are a
few problems with letting SharePoint handle it itself.

Please note, if you manually modify the hosts file, SharePoint will
revert it back to its original syntax. I imagine a Timer Job checks the
host file every 15 minutes or hour.

I found that by changing the crawl server  <to Web Front End #1> in the
following, the Central Administration server would modify its host  file
to use the desired server <Web Front End #1> for search and Crawling.
Central Administration (Operations -> Services on Server -> Select
Central Admin server -> Office SharePoint Server Search)

Yeah, like I said below, you have to leave the setting at its default,
which is crawl all servers, or it will continue to edit the Hosts file
behind you every time you fix it.

If you don't mind, what are some of the problems that you have seen with
SharePoint handling it. I am seeing a lot of Kerberos and propagation
errors. Right now the host  files on the 2 WFT are empty and the one on
the index  servers references the main url, server  name of the primary
WFT and the url of the mysites - all pointing to the IP of the Index
server? Is this correct? Can you provide an example of how the host file
should look if I edited it manually and changed the it back to crawl
using all servers.

Also if I did change it back, what would be the impact? Will the index
need to be rebuilt? I just spent two days getting search to work again
so I am hesitant to change anything.

There are two main problems that arise from letting SharePoint handle it
itself. First, if the machine you specify for crawling is multihomed
sometimes SharePoint will pick the wrong IP address for the Hosts file
entry. I *believe* (though I haven't tested this in a while) that it
takes whichever IP address is lower. If that doesn't happen to be the
interface you want it using, or if IIS isn't bound to that NIC you've
got problems and there is no way to tell SharePoint to use the other
address. Second, in some situations where a farm  was upgraded from v2 to
v3/moss the Farm address internally was http://server instead of
http://portal.company.com. In those cases when SharePoint automatically
makes the entry  in the Hosts file it makes it for server  instead of
portal.company.com. Since that change is at the IP level the Indexer can
no longer contact server because it's got the wrong IP address thanks to
SharePoint.

After having been bitten personally by both of those issues I've quit
using the automatic functionality and I do it by hand now.

I have no idea what's causing the Kerberos errors  you're seeing, but
they could very well be caused by this. I have no idea.

I 'think' I am seeing the light. Just a few more questions...bear with
me.

Okay so we have it set up like this:

IDX - index  role, dedicated server  to index

WFE1 - query  role

WFE 2 - query role

So you are saying to keep the query role on the two WFE but to change
the IDX server to use all WFE for indexing correct? Will this require
me to rebuild the index again?



I am not sure how to or what needs to go in the host  file to manual edit
it. Is this documented anywhere?



Also, I am experiencing the problems that you mentioned below. The
Kerberos error is due  to IDX trying to communicate to the WFE as its
computer name causing the token given by kerberos  to be different (or
something like that). I am also seeing a propagation error between the
two query servers. Do you think this is due to host file issue.

Event Type: Warning

Event Source: Office Server Search

Event Category: Search service

Event ID: 10039

Date: 7/10/2009

Time: 9:46:12 AM

User: N/A

Computer: WFE1

Description:

Retry of query machine 'WFE2' has failed with error: Logon Failure: The
target account name is incorrect. 0x80070574. It will be retried
again in 900 seconds. Component: 403f8149-8e5a-45ba-a854-b3de0b24c33a

Event Type: Error

Event Source: Office Server Search

Event Category: Search service

Event ID: 10038

Date: 7/10/2009

Time: 9:00:24 AM

User: N/A

Computer: WFE1

Description:

Query machine 'WFE2' has been taken out of rotation due to this error:
Logon Failure: The target account name is incorrect. 0x80070574. It
will be retried in 15 seconds. Component:
403f8149-8e5a-45ba-a854-b3de0b24c33a

Event Type: Error

Event Source: Kerberos

Event Category: None

Event ID: 4

Date: 7/10/2009

Time: 9:28:11 AM

User: N/A

Computer: WFE1

Description:

The kerberos client received a KRB_AP_ERR_MODIFIED error from the server
host/WFE1. The target name used was cifs/WFE1. This indicates that the
password used to encrypt the kerberos service ticket is different than
that on the target server. Commonly, this is due to identically named
machine accounts in the target realm (domain.com), and the client realm.
Please contact your system administrator.

I am starting to miss SP 2003. Things were so simpler then.

I think your first step should be to change the Indexer to use all web
front ends. Wait a few minutes, make sure your Indexer's hosts file gets
cleared up, then wait a day or so and see if your documents are crawled
and your errors  go away. If not, something else is likely the problem.
If so, then we can slowly start to make some of the other changes.