SharePoint - SharePoint 3 Gatherer error

Asked By Steve Gould

25-Jan-07 03:12 PM

Some time ago I installed WSS 3 beta on my web server then uninstalled it as
it made the server unstable.

I installed WSS 3 on my the server two days ago. It was throwing the warning
message below so I ran a repair. That killed SharePoint so this morning I
uninstalled and reinstalled it. It runs stable again, but throws the
following error every 5 minutes:

---
Event Type: Warning
Event Source: Windows SharePoint Services 3 Search
Event Category: Gatherer
Event ID: 2436
Date:  1/25/2007
Time:  11:01:25 AM
User:  N/A
Computer: SPIDER
Description:
The start address
crawled.

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

Details:
The object was not found.   (0x80041201)

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

Of course Microsoft has no reference to this yet. The XML file
74a1c34f-297a-4eb3-877f-b87a1e489c12 does exist in "C:\Documents and
Settings\All Users\Application
Data\Microsoft\SharePoint\Config\8d080e97-df19-4b6e-9a7f-3a71514836e9" with
todays date.


Suggestions anyone?

Steve

25-Jan-07 06:00 PM

SPS3 = the default content source that crawls user profiles in the SSP.  I
suspect you didn't reinstall an SSP when you install the WSS v3 again.

--
Bill English, MVP
Mindsharp

25-Jan-07 07:59 PM

You lost me Bill.

SPS3 = SharePoint Portal Server???

SSP = ???

I only installed Windows SharePoint Services, not SharePoint Server.

So what am I missing?

Steve

25-Jan-07 09:38 PM

My bad.  I misread "sts" for "sps".  I would suggest that you uninstall WSS
and IIS, then reinstall and try it again.  The problem is that the internal
MSSearch.exe engine is not able to crawl the local farm - AFAICT.  So, since
there is not much in the way of Search admin capabilities in WSS, a
reinstall seems to be a plausable course of action.

--
Bill English, MVP
Mindsharp

25-Jan-07 11:28 PM

Man, search seems to need a little work in WSS3.

Steve, it is possible that this error is due to a problem that the search
service is having accessing the databases?

To really troubleshoot this we need more data.  Is this a basic install?  If
it is an advanced, server farm install, do your search and content access
databases have access to the SQL server?  Is the search database accessible
from your sharepoint server (spider?)?  And, is the content database for
your web application using the sharepoint server you have the search service
running on?

I have numerous search problems, and they have varied between installations.
I once had gatherer/VSS/security issues that were all miraculously fixed by
just rebooting the sharepoint server.  I once had the search service stop
for some reason (maybe, somehow, I accidentally stopped it), when I
restarted it I had to delete the database and start again to get it to work
(this is essentially by design).  I also had the same thing happen on a
different deployment of sharepoint, but that time I also had to "remind" the
web application's content database to use the search server.  I also had one
bad situation search failure which amounted to the database access account
(the server farm account) suddenly stopped working, removed itself from SQL,
but still showed up as a farm administrator (but couldn't get an alert
because it wasn't a member of the site...).  That required a full rebuild of
WSS at that point.

Frankly, I think you should search through these newsgroups (sharepoint
general,setup_and_ administration, and wssservices) for other posts about
this issue.

-callahan

26-Jan-07 11:42 AM

My WSS 3.0 server has been logging this same error for a while:

Event Type:	Warning
Event Source:	Windows SharePoint Services 3 Search
Event Category:	Gatherer
Event ID:	2436
Date:		26/01/2007
Time:		3:45:22 AM
User:		N/A
Computer:	TITAN
Description:
The start address
crawled.

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

Details:
The item could not be accessed on the remote server because its address has
an invalid syntax.   (0x80041208)

This is basically a default fresh WSS 3.0 install.  WSS 3.0 is instaleld on
a single server, using Active Driectory, and is not using SQL server.  The
search bars in the sites do function.  Hope that helps somebody diagnose the
issue.
If you need any more details, I'll get you what you need.

26-Jan-07 03:02 PM

As this is on our production web server, uninstalling IIS would be a last
resort. That makes me cringe at the thought. This server also runs WSUS and
a Perl application so I sincerely don't want to mess with it.

I have WSS 3 beta on here as well as a failed install of WSS 3 two days ago.
Actually it was doing the same thing as now. I tried a fix that broke it.
The fix came from:

http://www.sharepointblogs.com/mcotw/

When I stoped the search service inside SharePoint admin and then tried to
restart it I got an error that stated the database schema was incorrect and
I had to install the search service elsewhere or delete the tables, etc. I
have no clue how to do that. The database is the default Microsoft ##SSEE.
Can I create a new one and use that instead? Or is there a way to remove all
the tables, schema, etc from this database and reuse it?

26-Jan-07 03:13 PM

I did a basic install. I do have a SQL 2000 server and SQL 2007 64 bit on
the shelf (no 64 bit server to install it on). I could use my SQL server,
but I don't really want to.

My web server is called Spider. The current server is listed as
status is "Ready". The SharePoint Services Search Server is listed as


I get the gatherer/VSS/security issues when I stop and disable the
SharePoint Search service and leave the Timer service running. Stoping the
timer service stops the errors. All go away when I re-enable the services,
but then I get the gatherer errors.

The SQL desktop engine is used by WSUS as well as SharePoint. I thought
about uninstalling it and starting from scratch. I can reinstall WSUS if I
need to, but would rather pass on that if possible. Is there any way to
remove the ##SSEE database so it can be reinstalled by re-installing WSS? Or
can I build a new instance such as ##SSEEFF and then direct WSS to use that
instead? I have no experience mucking with SQL other than on our main SQL
server and then rarely and with caution as it runs our accounting software.

Steve

28-Jan-07 02:08 AM

Since thie server previously had WSS3 beta installed then uninstalled I
figured this error could be from traces of the old DB. I uninstalled WSS
again and also uninstalled Embedded SQL. I then deleted the data directory
where Embedded SQL stored everything. I reinstalled WSS and the error is
back, but pointing to a different BID this time.

I am positive that even though I tried to uninstall all instances of the
previous WSS config something remained. I know this because I had altered
the default site theme before. After installing WSS again the same theme is
in place, not the default one.

Something somewhere is calling out this content page that doesn't exist. I
have found it in the registry, but I don't know what it points at in real
terms, sts3://spider/contentdbid...

I cannot uninstall IIS as I have too much running in IIS, so that option is
out. I have done everything I can think of short of that except that I know
some remnant of WSS isn't being uninstalled and has altered my new site
properties.

If nobody has any answers then it's off to PSS on Monday. Since so many
people are reporting this issue I'll report my results here after it gets
solved.

Steve

28-Jan-07 10:12 PM

I do not have an answer for you, unfortunately.  I would suggest calling PSS.

--
Bill English, MVP
Mindsharp

28-Jan-07 10:16 PM

You could try uninstalling WSS again along with the embedded SQL plus delete
the registry keys in the 12.0 hive in the registry.  Be sure to delete the
web sites in IIS, their web application files and the binaries for both
programs.

If you can delete the mssearch or microsoft search registry keys, this might
help.

One other thing you can try:  Start/Run/ type  in "installer".

Find the WSS beta install package along with the RTM WSS install package and
uninstall them from this location.

Otherwise, it is a PSS call, I'm afraid.

--
Bill English, MVP
Mindsharp

29-Jan-07 01:22 PM

Thanks Bill.

I think I will take one last crack at removing all traces of WSS and
reinstall. If that fails then PSS will be hearing from me :)

30-Jan-07 09:46 AM

I followed Bill's tips to uninstall and clean the registry of sharepoint and
MSEE references.  This seemed to spawn additional errors after the reinstall
but I'll wait to see if they are recurring.  Last night the 2436 error came
up in the logs again:

Event Type:	Warning
Event Source:	Windows SharePoint Services 3 Search
Event Category:	Gatherer
Event ID:	2436
Date:		30/01/2007
Time:		2:25:04 AM
User:		N/A
Computer:	TITAN
Description:
The start address
crawled.

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

Details:
The item could not be accessed on the remote server because its address has
an invalid syntax.   (0x80041208)

Any luck with your reinstall, Steve?

30-Jan-07 11:43 AM

I ran through the same uninstall steps. The same warning returned for me
also. I am on the phone with PSS now, but there is a 2 1/2 hour wait time. I
will post my results/repair if I am able to solve it.

Steve

30-Jan-07 01:53 PM

The gatherer issue is now resolved. It was really quite simple, but
undocumented.

I was a bit of my own worst enemy here. Because SharePoint is being
installed on my production web server I wanted to isolate it until I could
get it fully configured. By default SharePoint disables the "Default Web
Site" installs itself with the IP Address of "All Unassigned". Since this
server runs WSUS as well as 2 web sites and Microsoft Virtual Server,  I
could not allow the Default Web Site to be stopped. What I had done was to
assign a statip IP address to SharePoint and then restart the Default Web
Site.

The next issue is that SharePoint sets its URL as http://servername. The
gatherer service runs against this name. In my case this URL isn't
ShaprePoint so the gatherer couldn't find the SharePoint site and was
kicking the errors. I saw this in the error messages, but I didn't put 2 and
2 together.

In my case I will need to fix the issue again later when I go live with the
site since the URL will have to change. Temporarily I altered the URL to the
actual IP address SharePoint is using. To change the URL mappings:

Launch SharePoint 3.0 Central Administration.
Click on Operations
Select "Alternate Access Mappings" under Global Configuration
Select ShaprePoint's internal URL
Edit the URL to the desired value. (in my case it was http://192.168.1.60
for now) then click OK.

That resolved it for me. It looks like you can also set additional URLs here
too, internal, external, etc.

Steve