http://msmvps.com/blogs/cgross/archive/2009/03/29/sharepoint-search-amp-event-id-2436-errors-in-sbs-2008.aspx
*UPDATE: Still not why the steps below work on some boxes but not others. However, the SBS team just blogged about the implications of the Loopback Check registry key as well as the ability to register your public URL on your SBS box so that it bypasses the loopback check without having to completely disable the loopback check. I still recommend reconfiguring SharePoint Search as noted below in addition to registering your public URL to bypass the Loopback Check.
*UPDATE: We have confirmed that the steps below work on some SBS 2008 boxes, but not all installs. If these steps do not work, see Dan's entry in the Comment section about disabling the LoopBackCheck in the registry. Despite what you may see in other forums, SharePoint search will work just fine with https://remote.company.com being the Default security zone for your companyweb - you do not need to edit your alternate access mappings. Additionally, the SPContent account only needs to be a member of the domain users security group, and the SPSearch account only needs to be a member of the domain users and WSS_WPG security groups. SharePoint Central Administration will add the SPSearch user account to the WSS_WPG security group when search is configured per the steps below.
*Updated on 2009-03-29 at 9:45am CDT (GMT -5). Original post missed the steps of stopping the Search service before reconfiguring.
With Small Business Server 2008, SBS customers finally get Windows SharePoint Services 3.0 built-in to replace the SharePoint 2.0 companyweb included with SBS 2003. However, when you get your SBS 2008 box all set up and running, you may notice a few quirks when it comes to SharePoint search. Specifically,you are seeing 2436 errors in your Application event log:
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: server.company.local
Description:
The start address <sts3s://remote.company.com: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>
<Channel>Application</Channel>
<Computer>server.company.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.company.com:987/contentdbid={d4078aab-ce82-4581-
8d4f-973e1e6eac23}</Data>
</EventData>
</Event>
The issue here is that Windows SharePoint Services Search uses two separate accounts – one user account runs the search service, and the other user account is used to actually access the SharePoint content in order to index it. When configuring SharePoint Search, SharePoint Central Administration explicitly states that these accounts cannot be built-in accounts (such as LOCAL SYSTEM or NETWORK SERVICE). By default, SBS 2008 is using built-in windows accounts, which is resulting in this error being generated.
Luckily, this is easy to fix. The first thing we need to do is to create two new user accounts for SharePoint search to use. Personally, I do not create these accounts using the SBS add user wizard, because they will effectively be service accounts, so they do not need mailboxes, and we don’t need to see these accounts included in the User account list on the SBS console.
1. On your SBS, open Active Directory Users & Computers (Start –> Administrative Tools –> Active Directory Users & Computers.
2. Within ADU&C, navigate to the Organizational Unit where you want to create the new user accounts. (Personally, I create a new “Service Accounts” OU under <domain> –> My Business –> Users)
3. Right-click on the OU and select New –> User
4. On the first page of the new user window, enter the following info:
o First Name: SPSearch
o Last Name: <leave blank>
o Username: spsearch
5. Click Next.
6. Enter a strong password for the new account.
7. Uncheck the option “User must change password at next login”
8. Check the option “User cannot change password”
9. Check the option “Password never expires”
10. Click Next
11. Click Finish.
12. Repeat steps 3-11, using “SPContent” instead of “SPSearch” in step 4
We do not have to worry about granting any access or permissions to the two new accounts we created. After the accounts have been created, close Active Directory Users & Computers, then open SharePoint Central Administration (Start –> Administrative Tools –> SharePoint 3.0 Central Administration).
1. When SharePoint 3.0 Central Administration opens, go to the Operations tab.
2. Click on the “Services on Server” link
3. In the Action column, click the link to Stop the “Windows SharePoint Services Search” service.
o You will receive a warning that stopping the search service will remove existing indices. Click OK to acknowledge the warning.
4. When you return to the SharePoint Central Administration Operations tab, the Windows SharePoint Search Service will show as stopped. Click the link to Start the Windows SharePoint Services Search service. This will open the Search service configuration page.
5. In the Service Account section, select the “Configurable” option
1. For a username, enter <DOMAIN>\SPSearch (where <DOMAIN> is your AD domain).
2. For a password, enter the strong password you assigned to the SPSearch account.
1. In the Content Access Account section, select the “Configurable” option
1. For a username, enter <DOMAIN>\SPContent (where <DOMAIN> is your AD domain)
2. For a password, enter the strong password you assigned to the SPContent account.
2. In the Search Database section, change the database name by appending and underscore 1 (“_1”) to the database name.
o By default, the database name should be WSS_Search_[SERVERNAME], so we’re changing it to WSS_Search_[SERVERNAME]_1.
o Changing the name is necessary because the default database name already exists with search data. If we attempted to use the default database name, SharePoint would throw an error that the database contains user-defined schema and cannot be used. By changing the search database name on this configuration page, SharePoint Central Administration will create a new database using this name and configure search to use this new database. Since the new database is empty, we won’t encounter any errors.
1. Accept the remaining defaults and click the OK button.
After clicking OK, the settings should be applied and you should return to the “Services on Server” page in SharePoint Central Administration, and the Windows SharePoint Services Search” service should be listed as started.
Close SharePoint Central Administration and open the Services MMC (Start –> Administrative Tools –> Services). Restart the Windows SharePoint Services Search service. Verify that the Windows SharePoint Services Search service is configured to login with the SPSearch account you created.
Voila! Moving forward, you should not experience the 2436 error event in your Application Log.
