SBS 08, Event ID 2436 Windows SharePoint Services 3 Search

[Meng R]

We installed a fresh SBS 2008 last month and was working fine until two days ago. Till then I haven’t ran Windows Update on the same. But since I installed the updates I started getting the error mentioned in my title above. I searched internet and found that there are thousands of users facing this problem. But dint found anyone fixed the issue successfully.

There was a users who faced this error suggesting that this can be fixed by trashing the services and reassign them to new accounts. But if I’m not wrong it will break SBS wizard, isn’t it. Anyways, though this error is all over web, I’m posting the Event Log again here:

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>

Hope somebody can help me out getting rid of this.

[Billie]

Nope, you are wrong. It will not break SBS Wizard. Actually SharePoint Search make use of 2 separate accounts which is one for search service and another to access the content in SharePoint sites. While configuring SharePoint search in Central Administration, it explicitly notify you that those 2 accounts cannot be built-in and SBS *is* using built-in ccounts for these two SharePoint search accounts by default.

[Duder]

I'm getting same wss errors as above for 2 days now.

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.

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

Some folks are swapping WSS URL's

That's not a good fix imo.

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

After creating the SP Search account, change the existing wss search logon account in the WSS Search service properties to the new SPSearch account.

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

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

My logs show SQL informational messages regarding access failure to sql. I wonder if we need to add the above rights to the 2 accounts we made? If so I'll need to find instructions on adding those.

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.

[Meng R]

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.

[ATXStables]

Solution:
I am running Windows SharePoint Services 3.0 with sp1.
This issue cropped up after the search server express installation. i have all services installed on one server. I believe that the root cause were the credentials related to the search services credentials.

The resolution was the following:
- Go into SharePoint Central Administation website
- Click on the Operations Tab
- Click on Servers in Farm
- Click on the server that is running the services search
- Alright, this is where it gets hairy.... You see in Windows SharePoint Services, each time you stop and start the Windows SharePoint Services Search, you have to create a new database. yup, that's a free product for you :). This is much easier if you are running with sql server versus the free sql server.
- Determine if the status of the Windows SharePoint Services Search is started or stopped. If started, stop it by clicking on STOP.
- Now click on the Windows SharePoint Services Search words to the left. This will present a panel that asks for 2 usernames. 1 is a service acct that must be a local admin of the machine. This account will run as the identity of the application pool that you can find in the IIS Manager
- The second account is the content access account.
*Note: if you are running on a separate server and if it was named MSFTSUX the usernames would be in the format of MSFTSUX\sptpooladmin and MSFTSUX\SSE_Content_Access.
- fill in the search database with an entirely new name as Windows sharePoint services likes a new database each time you stop and start search.
- After you have all the information you need to click on OK, then click on OK
- OK, the hard part is over, so go back to the screen above that shows the services running on the server.
- This time click on Action which should be start.
- The screen appears to be the same screen as you saw before, but it is not. It has a start button at the bottom instead of OK. Enter the passwords, AGAIN :( and click on Start.
- Now verify the perms for the database. According to microsoft, the index account should be the db_owner. however, the perms may differ based on which documentation you read. So, give both accounts db_owner privelages. the index account will require bulkadmin privelages if you are so secure you are worried about insurgents in your databases :)

windows sharepoint services Search notes:
- you can view the database tables to determine the status of your search. I have a 57 gb database and it takes about 8 hours to index it. My index database turns into about 1gb. check out the below tables to track the status of your index.
msscrawlhistory (fields of interest are starttime and endtime)
msscrawlurl
msscrawlerrorlist

I hope this helps as I have spent quite a fair amount of time debunking my windows sharepoint services search installation.

Ride On...

p.s. you may receive an error message
Your search cannot be completed because this site is not assigned to an indexer. Contact your administrator for more information.

In central Administration:
- Click on Application Management
- Click on Content Databases
- OK, be careful here as I have made this mistake several times...
On the right handside is a dropdown labeled Web application.
You must select the web application related to your sharepoint site. i.e. my sharepoint site runs on port 80. so if you have a server named MSFTSUX and a web application named MSFTSUX0180 with a url of MSFTSUX select the http://MSFTSUX
- Next, click on the database name listed.
- A panel appears and there is a drop down next to the label of Search Server
- Select the server MSFTSUX from the dropdown.
- Click on OK.

Using the above steps you have just pointed the content database to be indexed and indexing will occur.

Good luck and be sure to thank Microsoft for allowing you to create a new database each and everytime you stop and restart the Search Services in Windows SharePoint services. :)