Gatherer issue in WSS 3

[Jeff]

I am seeing the following error with the search gatherer in WSS 3:

Event Type: Warning
Event Source: Windows SharePoint Services 3 Search
Event Category: Gatherer
Event ID: 2436
Date: 12/1/2006
Time: 1:15:07 PM
User: N/A
Computer: MyServer
Description:
The start address
<sts3://sharepoint.mycomp.com/contentdbid={4fc809d0-07c1-4b7f-b47d-8b3e54f5e9c4}>
cannot be crawled.

Context: Application 'Search index file on the search server', Catalog
'Search'

Details:
Access is denied. Check that the Default Content Access Account has access
to this content, or add a crawl rule to crawl this content. (0x80041205)

For more information, see Help and Support Center at
http://go.microsoft.com/fwlink/events.asp.

The default Content access account is actually a domain admin account at
this point (I wanted to eliminate user rights as an issue).

This is preventing search from working on all our sites. How do I fix this?

Jeff

[Jeff]

Has anyone seen the error in my post before?

This is holding up full adoption of WSS 3. . .

Even if you know where I could get assistance with this it would be great

Jeff

"Jeff" <jeffp...@yahoo.com> wrote in message
news:%23C4Iq2X...@TK2MSFTNGP05.phx.gbl...

[fallo...@gmail.com]

I've got the same thing. In my first Web Application I somehow got
Search working, but it is not working on a second Web Application I
created, and I get your error in my Event Logs. I'm sure it is
permissions related, I just don't know what to change yet.

I'm working on a solution and will post if I find something.

Anthony

[Jeff]

Thank you. I'm glad I am not the only one :) My plan is to try a fresh
install of WSS3 on a different system If I can get search working there I
will move my site collection to the new system.

I will be very itnerested if you come up with a solution

Jeff

<fallo...@gmail.com> wrote in message
news:1165329055....@j44g2000cwa.googlegroups.com...

[michel...@zobele.com]

I have the same problem :( no one with some good news?

Jeff ha scritto:

[Jeff]

I found this site which helped:

http://episteme.arstechnica.com/eve/forums/a/tpc/f/12009443/m/309003312831/inc/-1

I had kerberos authentication enabled without an SPN as well. . .I changed
to NTLM and the warning went away.

I still do not get any results when I do a search on a site, however. I may
just not have waited enough time. . .I will post again when I ahve it
completely working

Jeff

<michel...@zobele.com> wrote in message
news:1165927927.7...@n67g2000cwd.googlegroups.com...

[medu...@gmail.com]

I have the same problem. No matter what account I use, I get the error.
The accounts have access to the DB, it just won't crawl.

[michel...@zobele.com]

I have solved my problems doing this:

1) Go in the IIS Manager on the "Application Pools".
2) Open the properties of the Sharepoint Web application that cause the
crawl problem.
3) Go to the "Identity" tab and modify from "Network Service" to the
DCA account.
4) iisreset /noforce

In my environment this solve all the problems and make run the search
engine in sharepoint.

medu...@gmail.com ha scritto:

[michel...@zobele.com]

I have solved my problem, doing this:

1) Start IIS Manager

2) Go into the "Application Pools"

3) Find the Sharepoint WebApp and then open it's proprieties.

4) Go into the "Identity" tab" and change the user account from Network
Service to DCA.

5) Save and exit.

In my environment this fix all the problem and make run the search on
sharepoint!

medu...@gmail.com ha scritto:

[Wes]

No, we don't use the Network Service account. Our identities are as follows:

IIS App Pool: sts_content
IIS Admin Pool: sts_admin
Search Service Account: sts_admin
Search Account: sts_content (which is more permissions than reccomended for
search)

SQL DBO: sts_admin
SQL DBUser: sts_content

[Jeff]

Ultimately, I reinstalled WSS 3 on a new system, restored my sites from
backup, and configured search. It works now.. .not a satisfying solution to
the problem on my old server, but at least it is working now with a fresh,
clean install of WSS

Jeff

<michel...@zobele.com> wrote in message
news:1166198956.4...@j72g2000cwa.googlegroups.com...

[fallo...@gmail.com]

I ultimately got this working today by switching from Basic
Authentication to NTLM auth. That means my users will have to change
the way they log in, but the Search is finally working!

[noe...@interactivewebs.com.au]

I have gone to MS for support on this. This is what they say...

Problem Description:
===============

You were not able to use search in your WSS 3.0 site which was
configured to use Basic authentication (no return in search results).

In observing the event log, the following error can be seen.

Context: Application 'Search index file on the search server', Catalog
'Search'
Details:
Access is denied. Check that the Default Content
Access Account has access to this content, or add a crawl rule to
crawl this content. (0x80041205)

Cause:
=====

Confirmed that it is by design limitation that WSS 3.0 crawler only
understands Windows auth (NTLM). It does not understand Forms auth,
Basic etc.

Resolution:
========

A work around we found for the issue is to extend your WSS 3.0 web
application to run on an additional port, configure NTLM for the site
and have crawler to follow NTLM site to build index.

Detailed steps are as follows:

1. Go to SharePoint Central administration -> Application management.
2. Choose "Create or extend Web application".
3. Choose "Extend an existing Web application".
4. Choose your "basic" web application from the list.
5. Set other parameters as needed. Suppose we configure it to run at
http://server:1234.
6. From Zone list, choose a zone other than Default. i.e. Custom.
7. After the mapped site is created, go to Application Management ->
Authentication Providers.
8. Find and click the zone (for the mapped site) we just created. Set
"Windows integrated" authentication.
9. Go to Operations -> Alternate access mappings.
10. Change the alternate access mapping collection to our web
application.
11. Click Edit Public URLs, and exchange the URL in the list. Make
sure that the new URL http://server:1234 (our new URL) is in Default
URL while the original URL can be set at any other zone.
12. Wait for a few mins and test the issue.

Hope that helps

[andy....@gmail.com]

I ran into this problem yesterday. I wasn't sure where to begin.
I've also lost some hair over this, but have finally got it figured
out. The problem started when I changed from integrated auth to basic
so my users wouldn't have to type in DOMAIN\username. Well apparently
this affects the logins on the search service settings screen, which
had been DOMAIN\username while i was under integrated auth. I changed
them to just username and both the search and the authentication are
working now.

[andy....@gmail.com]

dirty lies, just looked at it again and the login is failing, it was
pulling up results from previous search scans. apologies.