Article ID: 188005
Article Last Modified on 7/16/1999
APPLIES TO
- Microsoft Search, when used with:
- Microsoft Site Server 3.0 Standard Edition
This article was previously published under Q188005
SYMPTOMS
When you specify a site-specific account to crawl a large secure site, the
crawl begins to fail to authenticate at some point. Access to the URLs is
denied to the Search Gatherer.
CAUSE
The site-specific account information is not persisted during the crawl. If
an error is encountered or if Search runs out of memory and reloads the
information for the crawl, the information for the site-specific account is
lost.
The site-specific account information also is lost if the site has a
large number of secure pages that are being indexed by the crawl.
RESOLUTION
To resolve this problem, apply the latest Site Server 3.0 service
pack.
To work around this problem, change the Search Default Content
Access Account to the account/password needed to access the URLs
for the site in question. If crawling many secure sites, a
separate catalog is necessary for each site. This may not be a
feasible workaround for crawling many secure sites as part of a
single catalog.
To change the Default Content Access Account, perform the following steps:
- In the Microsoft Management Console (MMC), open the Search snap-in and
open the server in question.
- Right-click the Catalog Build Server and select the Accounts
tab.
- Fill in the information for the Default Content Access Account.
STATUS
Microsoft has confirmed this to be a problem in Site Server version 3.0.
This problem has been corrected in the latest U.S. service pack for
Microsoft Site Server version 3.0. For information on obtaining the service
pack, query on the following word in the Microsoft Knowledge Base (without
the spaces):
MORE INFORMATION
The site specific account information is now persisted, so the crawl will
successfully recover from an error.
Additional query words: sp
Keywords: kbbug kbfix kbsiteserv300sp1fix KB188005