Monitor unlimited number of servers
Filter log events
Create email and web-based reports

Direct access to Microsoft articles
Customized keywords for major search engines
Access to premium content

Event ID: 2436 Source: WindowsSharePointServices3Search

The start address <address> cannot be crawled.

Context: Application "Search index file on the search server" Catalog "Search"

Details: <error> <error code>.
I got this on my SBS 2008. To fix it, in registry editor, locate [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa3] and add a DWORD value named "DisableLoopbackCheck" type 1 in the Value data box.
A previous post kind of runs through the steps, but here they are numbered out a little clearer from one of the links below, supposedly this came direct from MS support:
1. Go to SharePoint Central administration -> Application management.
2. Choose "Create or extend Web application".
3. Choose "Extend an existing Web application".
4. Choose your "basic" web application from the list.
5. Set other parameters as needed. Suppose we configure it to run at http://server:1234.
6. From Zone list, choose a zone other than Default. i.e. Custom.
7. After the mapped site is created, go to Application Management -> Authentication Providers.
8. Find and click the zone (for the mapped site) we just created. Set "Windows integrated" authentication.
9. Go to Operations -> Alternate access mappings.
10. Change the alternate access mapping collection to our web application.
11. Click Edit Public URLs, and exchange the URL in the list. Make sure that the new URL http://server:1234 (our new URL) is in Default URL while the original URL can be set at any other zone.
12. Wait for a few mins and test the issue.

I also had to restart IIS to get the site to work again as all this broke it.
In my case, resetting the password of ''Default content access account'' using SSP console (Search, Search settings) fixed it.
Error: Access is denied (code 0x80041205).  This may be recorded in certain conditions (specific hotfixes are applied) because  Windows Server 2003 Service Pack 1 (SP1) includes a loopback check security feature that is designed to help prevent reflection attacks on your computer. ME971382 provides information on registry changes that have to be made on all Web Front End servers and any Index server configured to crawl itself in order to workaround this problem.
I was having a similar issue - getting access denied messages and to check the default content access account.  After trying nearly everything possible, I finally narrowed down the culprit to a Microsoft Security Patch - MS06-068 (ME957097). We have 2 web frontends and a dedicated app server for search and the local authentication was failing after installing this patch. Just turned off the loopback check on the app/search server, rebooted, and search was back in action.

In my case, I came across a blog entry which led to the solution of my problem. See EV100120 (a link to the "SharePoint 2007 Search" article) and read it.
In my case, the Authentication Methods was set to Basic. Once changed to Integrated Windows authentication, the search began working.
In our particular instance, we had configured two front end web servers with a third dedicated search server for content and indexing. At some point, the MOSS Website was disabled on the search server which caused events 2436 to be displayed in the event log. Enabling the website on the same port as the primary web servers allowed content to crawl as expected.
From a newsgroup post: "I changed the internal URL for our site to something more user friendly than the computer name and then my eventlog was full of the message 'The start address
<sts3://intranet/contentdbid={8ad03df4-8d1f-4344-86df-6ebe0bc9a057}> 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)

The error was fixed by putting the old name back and adding the new name to a different section in alternate accessing."
From a newsgroup post: "There are some particulars that are not documented very well when setting up your search settings. The search engine will only crawl on a site that is the default zone. If the default zone is secured (https), search will not return any results and you will see this error in the application log.
To fix this, create and extend the current web application with a new site. The default settings will suffice for everything except the zone. Change the “Zone” to Internet or Custom. This new site will be the site the search service uses to index. Bear in mind the site uses the same content as your public SharePoint site. After creating the site, go to Operations > Alternate Access Mappings and change the “Alternate Access Mapping Collection to your main SharePoint site collection. Then click “Edit Public URLs” and swap the URLs in the fields such that the Default zone is the new “unsecured” SharePoint site. The secure site can be in any zone except the default zone.
Now when the search indexer runs, it will use the default zone site (the new unsecured site) to crawl. That’s it". See the link to " - Windows SharePoint Services (WSS) 3.0 Search Setup Notes" for the original thread.

See the link to "WSSv3 Search, Small Business Server & DNS" for a different situation regarding this event.
See the link to "Google Thread" for an interesting new post on this issue.

Windows Event Log Analysis Splunk App

Build a great reporting interface using Splunk, one of the leaders in the Security Information and Event Management (SIEM) field, linking the collected Windows events to



Cisco ASA Log Analyzer Splunk App

Obtain enhanced visibility into Cisco ASA firewall logs using the free Firegen for Cisco ASA Splunk App. Take advantage of dashboards built to optimize the threat analysis process.