I'm Indexing and I only get errors...

Got this message from a user responding to a comment they saw in a previous post...

http://blogs.msdn.com/joelo/archive/2006/11/16/upgrading-from-wss-3-0-b2tr-to-rtm.aspx

# John Angelini said on March 26, 2007 12:34 PM:
Regarding Search..... I struggled with this for awhile. In the Event Logs, I found several "Access Denied" errors with the message "The start address <sts3://yoururl/contentbid={GUID}> cannot be crawled" and error code 2436. These messages should appear every 5 minutes, when the SharePoint Search Service Timer Job fires. 5 minutes is, of course, assuming the value has not been changed from the default.
Hopefully this will help. I was able to fix the problem with a registry hack. My issue was Loopback Checking, which IIS uses to protect against Denial of Service Attacks. Basically, the default value does not allow the Search Service to crawl the site, because it essentially receives a dangerous level of Requests coming from the loopback address (default 127.0.1.1), which it denies access to "thinking" it is an attack.
See Knowledge Base Article KB896861 at http://support.microsoft.com/kb/896861 for the fix.
Short story: Create a DWORD registry key at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Lsa named DisableLoopbackCheck and set the value to 1, for TRUE, to disable the loopback checking.
Hope this helped. Please repost this thread on any other boards relating to this problem. We the developers are responsible for our own community, so help others by reposting this thread to those who need it, and they will be there to help you when you need it!!

-----------------

We experienced the same issue after following the above steps.

Our environment is:
 A stand alone PC with Windows 2003 SP2 and latest updates;
No domain existed and workgroup mode ( ie: stand alone );
 IP address and DNS setting is automatically assigned by DHCP;
 Installed with WSS 3.0 with Q932091 patch;
 Windows SharePoint Search, Timer services are running on NTAuthoriy\NetworkService;
Have tried the Check Loopback registry hack according to KB 896861;
 Still no records found with periodically 2436 errors.

Any idea ?

Gabe Bratton came back with some quick witted insightful answers...

Gabe: The two most common issues that come to mind:

1.     The web application is using Basic or Kerberos authentication.  Customer needs to use workaround in http://technet2.microsoft.com/windowsserver/WSS/en/library/8208d71e-7c41-4845-bc06-95429de02cf11033.mspx?mfr=true.

2.     AAM is misconfigured as noted in Mistake 5 of Troy Starr’s blog, http://blogs.msdn.com/sharepoint/archive/2007/03/19/what-every-sharepoint-administrator-needs-to-know-about-alternate-access-mappings-part-2-of-3.aspx. 

Curt came back with this...

Sounds like this scenario as well: 

WSS 2007 - Search not working - Event ID 2436 The start address <sts3://servername/contentdbid={GUID}> cannot be crawled.

- Event ID 2436 The start address <sts3://servername/contentdbid={GUID}> cannot be crawled. [ ]


<><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
*** Problem Description ***
BEHAVIOR/SYMPTOMS:
====================
Search is not working for any sites on a specific virtual server that has been
extended to host WSS as a web application

ERROR MESSAGE:
====================
We see the following error message in the Application Event log:

Windows SharePoint Services
Gatherer
EventID 2436

The start address <sts3://servername/contentdbid={GUID}> 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)

No results matching your search were found.

We see the following error in the ULS Logs for SharePoint -
DRIVE:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\LOGS

Monitorable CSTS3Accessor::InitURLType: Return error to caller, hr=80041205 -
File:d:\office\source\search\search\gather\protocols\sts3\sts3acc.cxx

ENVIRONMENT:
====================
Windows Server 2003 sp1
WSS
WSS installed in Active Directory Account Creation mode


<><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>


CAUSE:
====================
The error said it all. The start address, which in this case was the netbios name
of the server, could not be crawled properly. So although it seemed to have the
content indexed for all the sites in the web application you could not search on
any of it due to the default URL being inaccessible. All the crawled content was
being flagged as inaccessible.

The client had created a web application and specified SERVERNAME for the default
URL but they never created any site at that address. Instead they used stsadm to
create hostheader sites within the web application.

stsadm.exe -o createsite -url http://domain.com -ownerlogin DOMAIN\username
-owneremail email@mail.com -hhurl http://servername

RESOLUTION/WORKAROUND:
====================
After reproducing the clients problem we created the netbios site with stsadm

stsadm.exe -o createsite -url http://servername -ownerlogin DOMAIN\username
-owneremail email@mail.com

Once a crawl was completed we could return search results from the new site but the
sites that had been created previously would only show search results if you added
new content to the sites. The previously incremental crawled content had been
flagged or security trimmed so it could not be returned in search.

There is no way to start a full crawl for WSS search, it is always incremental so
we had to stop the search service in the SharePoint Admin page and start it
again.

http://servername:PORT/_admin/Server.aspx

Once this had been done we could return search results from all of the clients WSS
sites.

STEPS TO REPRO:
====================
Install WSS 2007 in Active Directory Account Creation mode
Start Search, Set your Outgoing Email settings
Create a web application and use the netbios name of the server as the default
URL
Create an FQDN site via stsadm
Since we are in AD account creation mode we need to create the sites for the web
application via stsadm

stsadm.exe -o createsite -url http://domain.com -ownerlogin DOMAIN\username
-owneremail email@mail.com -hhurl http://servername

Add the FQDN to the virtual server in IIS that is extended as the WSS web
application

You will be able to browse the site successfully but you will not return any search
results on the site.

<><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><

Let me add...

One of the more common mistakes I see is people that use the default web application and extend it for their web applications.  When they do this by using the server name, use localhost or leave it default with a blank host header it makes SharePoint confused when it tries to retrieve sites.  Best practice is to not use the servername, localhost, and to not use the default web application since it already has a description field and it can be very confusing.  If you are creating host header site collections you should create one site with the server name so it will be able to properly connect to the sites and databases as explained above.  If you're not using host header site collections, use a new name that can be either mapped in DNS or whatever you are using for names in your company.  Alternate access mappings are by far the best workaround for these issues.