Interesting error. I've seen this reported all over the internet, but in
testing, I have found that this didn't start until I installed the 20+
updates for SBS 08 after the installation was already running for a
couple days from the Action Pack DVD.

I have another person that has the same issue, nothing seems to resolve
this for anyone, unless you trash the services and assign them to new
accounts - which should break SBS wizards if I understand the
implications.

Anyone else running SBS 08 seeing Event ID 2436 in their Windows
Application logs?


Log Name: Application
Source: Windows SharePoint Services 3 Search
Date: 3/29/2009 4:20:05 PM
Event ID: 2436
Task Category: Gatherer
Level: Warning
Keywords: Classic
User: N/A
Computer: ZXZXZXSERVER.ZXZXZX.local
Description:
The start address <sts3s://remote.ZXZXZX.net:987/contentdbid={d4078aab-
ce82-4581-8d4f-973e1e6eac23}> 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)
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Provider Name="Windows SharePoint Services 3 Search" />
<EventID Qualifiers="32768">2436</EventID>
<Level>3</Level>
<Task>3</Task>
<Keywords>0x80000000000000</Keywords>
<TimeCreated SystemTime="2009-03-29T20:20:05.000Z" />
<EventRecordID>1146371</EventRecordID>
<Channel>Application</Channel>
<Computer>ZXZXZXSERVER.ZXZXZX.local</Computer>
<Security />
</System>
<EventData>
<Data>

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)</Data>
<Data>sts3s://remote.ZXZXZX.net:987/contentdbid={d4078aab-ce82-4581-
8d4f-973e1e6eac23}</Data>
</EventData>
</Event>

It won't break any wizards.

SharePoint Search uses two different accounts - one for the search service,
and one to access the content in SharePoint sites. When configuring
SharePoint search in Central Administration, SharePoint explicitly tells you
that these two accounts cannot be built-in (e.g. Local Service / Network
Service) accounts. By default, SBS *is* using built-in accounts for these
two SharePoint search accounts.

Creating two new standard user accounts and updating the SharePoint Search
configuration will eliminate these errors. I reconfigured SharePoint search
on my SBS 08 back in December - I haven't had any 2436 errors since then,
and I haven't seen any adverse affects with the wizards either. And the
wizards shouldn't care about these two accounts anyway.

I'm guessing that the new image-based installation approach is part of the
reason why the SBS team didn't configure SharePoint search properly. I'm
drafting a blog post on optimizing SharePoint search in SBS 2008 which will
include changing these accounts. Should be posted yet tonight.

In article <OBYogoMsJHA.1304>,
chad.gross says...
[..]
> on my SBS 08 back in December - I haven't had any 2436 errors since then,
> and I haven't seen any adverse affects with the wizards either. And the
> wizards shouldn't care about these two accounts anyway.
>
> I'm guessing that the new image-based installation approach is part of the
> reason why the SBS team didn't configure SharePoint search properly. I'm
> drafting a blog post on optimizing SharePoint search in SBS 2008 which will
> include changing these accounts. Should be posted yet tonight.
>Can you give me a generic step-by-step to do this, if it won't take more
than a couple minutes of your time?

Thanks

Just posted on the blog:

http://msmvps.com/blogs/cgross/archi...-sbs-2008.aspx

In article <ORD$u7MsJHA.4632>,
chad.gross says...
> Just posted on the blog:
>
> [..]
>Thanks - reviewing now.

Hi Chad and Leythos. Yes I'm getting same wss errors as above for
days now.

IMO it's either from a admin password change that doesn't filter dow
to the IIS-WSS service accounts or more likely it's due to the sb
updates that MS shoves at us untested.

This is happening to me on a brand new install and I'm havin
flashbacks to last year's WSS update debacle. I'm sure you're on th
right path after reading your posts.

Some folks are swapping WSS URL's.
http://mysharepointblog.com/post/200...tup-Notes.aspx

That's not a good fix imo.

Thanks you 2. MS will send Chad a check for the fix I'm sure. ;) lol

Duder

Update: Chad; The steps for the fix make sense however I get an erro
thrown when I try to restart the wss search service in services:
Error 183 Cannot create a file when that file already exists. Hmm
Bumme

Update2:

Chad's fix has worked but needs this somewhat obvious step added:
After creating the SP Search account, change the existing wss searc
logon account in the WSS Search service properties to the new SPSearc
account.

Enter it's password you created with the account. Start the service an
watch the application log.

Bye bye error. :) Thanks Chad.


This has fix has been posted in the SBSC 4 hr newsgroup also for man
who will need it

In article <Duder.3pua7c>, Duder.3pua7c
says...
> IMO it's either from a admin password change that doesn't filter down
> to the IIS-WSS service accounts or more likely it's due to the sbs
> updates that MS shoves at us untested.
>

On a new install, before doing any updates, using the dvd that was
shipped with my AP subscription, I didn't see that event ID error once,
not that I can tell, and I was looking for it.

After running the 24 updates I started getting it.

UPDATE -

OK guys - I missed a step in the blog post, which explains the error that
Duder encountered. My bad for doing a quick post from notes and not testing
the process. Short story is that I used the notes on configuring SharePoint
search on a clean SharePoint install (not on SBS 08). The difference
between that scenario and the SBS 08 scenario is that SharePoint Search is
previously configured on SBS, where it has not yet been configured on a
clean install. I have updated the blog post to include stopping the
SharePoint search service before changing the configuration.

In article <F8844525-254F-4FBE-9162-47C9D14EE680>,
chad.gross says...
> UPDATE -
>
> OK guys - I missed a step in the blog post, which explains the error that
> Duder encountered. My bad for doing a quick post from notes and not testing
> the process. Short story is that I used the notes on configuring SharePoint
> search on a clean SharePoint install (not on SBS 08). The difference
> between that scenario and the SBS 08 scenario is that SharePoint Search is
> previously configured on SBS, where it has not yet been configured on a
> clean install. I have updated the blog post to include stopping the
> SharePoint search service before changing the configuration.

I followed the directions and still get error ID 2436 every 5 minutes.

Double checked all settings, got no errors, and yet the beast persists.

Sherry Jia from SBSC newsgroup offers this as a reply to this issue:
[..]
> extensions\LOGS.
>
> 5. Please also send us the Application Event log for further research
> My
> email address is potcdata with subject: 43411000- Searc
>
> stopped working on SBS 2008.
>
> 6. Have you enabled the proxy settings in IE?
>

I'm interested in your opinion on #3 Chad. My logs show SQ
informational messages regarding access failure to sql. I wonder if w
need to add the above rights to the 2 accounts we made? If so I'll nee
to find instructions on adding those.

The only other sbs 08 log errors i get are 10016 dcom's which I kno
the fix for and occasional print spooler ones which SBSC has a fix for.

Overall I'm liking sbs 2008. Dude

In article <Duder.3pvinb>, Duder.3pvinb
says...
> The only other sbs 08 log errors i get are 10016 dcom's which I know
> the fix for and occasional print spooler ones which SBSC has a fix for.
>

I'm seeing Security Event ID: 4625 Logon Audit Failure for

An account failed to log on.

Subject: Security ID: SYSTEM

ProcessName C:\Program Files\Microsoft\Exchange Server\Bin
\Microsoft.Exchange.Search.ExSearch.exe

After following the changes at the blog.

Update: Upon further research, I disabled the LSA loopback check on my
test SBS server in the registry. My app, system and security logs are
almost spotless. :)

It achieved a much better result than the above solutions.
Downside is less DDOS security. I'll trust my IPCOP on that.

Cheers Duder