Event log messages generated by SharePoint

[Clint]

We're getting a whole whack of events in the Application Event Log that look
like:

Source: Microsoft SharePointPS Search Service
Category: Gatherer
Event ID: 3036
The content source <sps://edmadmin/site$$$people> cannot be accessed.

Context: http://edmadmin/ Application, Portal_Content Catalog

Details:

Unspecified error

(0x80004005)

For more information visit
http://www.microsoft.com/servers/redirect/contentredirect2.asp

Any ideas why this is happening? I've done my google searches, with no
luck.

Thanks,

Clint

[Garth H]

I have the same issue on my test server. I have no clue what's causing
the error, and like wise no good leads in the KB or from Google.

[Clint]

Well, you're no help! :) I've got to dig into this again soon, so I'll try
to post if I dig up anything.

Clint

"Garth H" <webd...@spamcop.net> wrote in message
news:#UVrc8Fg...@tk2msftngp13.phx.gbl...

[Hollis D. Paul]

In article <#LQ4NNMg...@tk2msftngp13.phx.gbl>, Clint wrote:
> Well, you're no help! :) I've got to dig into this again soon, so I'll try
> to post if I dig up anything.
>

There is something wrong with your installation of the portal server that is
keeping the indexing service from operating correctly.

Is the App Pool running under a domain administrator identity, and does it
have a log-in defined for your SQL server, and read-write capabilities in the
SharePoint databases?

Do you still have FrontPage Server Extensions installed, or were they
installed when you created your portal. If yes, you will never get the
search to work in the portal. It requires an uninstall of FPSE2002, SPPS,
WSS, and IIS, and then a reinstall of IIS, with the search component
included, then SPPS2003 (WSS first then SPPS) then create a new portal and
provision it with the existing databases. Should work then, assuming that
you have turned on search in the administrative pages, etc., Etc.

Perhaps the real search experts for SharePoint Portal Server will confirm the
details of all this after the holiday.

Hollis D. Paul [MVP - Outlook]
Hol...@outhousebythesound.com
Mukilteo, WA USA

[Clint]

Thanks for the suggestions. I'll check into those items. I'm not sure what
order things were installed, however.

Apparently, I'm the SharePoint expert in our organization, due to the fact
that I installed it once. :)

Clint

"Hollis D. Paul" <Hol...@outhousebythesound.com> wrote in message
news:VA.0000226...@obts-outlookdev.outlookbythesound.mukwoods...

[Hollis D. Paul]

In article <Ok$p4pNgF...@tk2msftngp13.phx.gbl>, Clint wrote:
> Apparently, I'm the SharePoint expert in our organization, due to the fact
> that I installed it once. :)
>

Welcome to the club! It's long name is trial by fire.

[Garth H]

I also didn't keep very good install notes. Luckily the install in
question is a test instance.

My problems only popped up after I added the v6 IFilter for acrobat
docs, so I figure that it may have something to do with that too.

Thanks for the tips, I'll be sure to keep everything in order on the
next test install.

[Clint]

I think I've got my problem fixed, so I thought I'd post in here to let
others know what the solution was.

Long long ago, when we first set up the Portal server, we created a test
Portal. For some reason, this portal was mal-formed, and didn't have any
sites or anything underneath it. So while I was busy fighting permissions
and security on the directories that the SharePoint Search service said it
couldn't access, the problem was that the directories didn't actually exist.

Solution was to blow away the non-used Portals. That ended with me getting
another Sharepoint error, about the alerts not being able to run on, and a
database being missing. So I re-configured another Portal with the same
name, mapped it to our "real" Portal, and life is good. Hope this helps
someone, someday...

Clint

"Clint" <nob...@nowhere.non> wrote in message
news:Ok$p4pNgF...@tk2msftngp13.phx.gbl...