WSS3 cannot be crawled
I'm getting this error on the server of WSS 3.0
The start address <sts3://ebs-sharepoint/contentdbid={d901caff-7863-40aa-8460-c3ef9132cb89}> 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 WSS 3.0 is configured to use Kerberos and both the WSS Search and Timer service is running under a domain account.
Any help. Thanks.
Jason
Ответы
- Hi
I fixed the problem on my server
The problem is that we use a FQDN and also running the search service on the frontend server
Have a look on this KB http://support.microsoft.com/kb/896861 - Method 1: Disable the loopback check
It worked for me :)
Все ответы
Hi
I'm having same problem.
Event Type: Warning
Event Source: Windows SharePoint Services 3 Search
Event Category: Gatherer
Event ID: 2436
Date: 2/12/2007
Time: 1:50:00 PM
User: N/A
Computer: <computer>
Description:
The start address <sts3://server.domain.dk/contentdbid={7a7f6b78-5fe1-4c0e-a5f2-956a00cc7f04}> 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)For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
The default content access account is DBO on the DB and running NTLM auth
- I am getting exactly the same problem as well.
- We are having the same problem in 3 of our WSS3 server. Is someone in MS working on it???
- Im having this problem as well. If anyone finds a fix, please let me know if within a few days of this posting. And Microsoft, please figure out what is going on here!
- Hi
I fixed the problem on my server
The problem is that we use a FQDN and also running the search service on the frontend server
Have a look on this KB http://support.microsoft.com/kb/896861 - Method 1: Disable the loopback check
It worked for me :) - both Method 1 and 2 doesn't work for me.
I haven't specify the host header in IIS and I access the website thr FQDN
and the error log show http://servername ... rather than http://servername.domain.com Finally i got it working.
The problem is that I cannot broswe to http://servername in the IE of my WSS3 server.
After correct the proxy setting in IE of the server (bypass proxy), I can crawled the content in http://servername now.
However the event log keep showing that it cannot crawled the Central Administration page.The start address <sts3://ebs-sharepoint:13547/contentdbid={7fa830af-870c-4f83-a04f-b5bf31b3ea58}> cannot be crawled.
It is normal?
I can broswe to http://ebs-sharepoing:13547 from the IE of WSS3 server.- Method 1 worked for me also!
All,
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)For resolving this error, please make sure that your Content Access Account has enought privileges on the data-sources. If you want to index custom data-sources like documentum, intranet sites, databases, fileshares , internet etc make sure that your content access account has enought privileges on the data-source.
If you just want to index the Sharepoint (WSS) sites only, make sure that Shared Services (Timer, Search etc)
are running properly with privileged User Accounts
Check for Loopback Checking as per KB Article: http://support.microsoft.com/kb/896861
Worked for me. If it works for you, please mark this thread as answered. Thanks.
I had the same crawl error messages in Event Viewer. I have also changed the registry settings according to 896861. It did not work. I think the reason my index crawl failed is because WSS search service is using HTTP urls for indexing whereas all my sites are HTTPS enabled. HTTP urls will not return any results. My question is how am I going to modify WSS indexing engine and get it to scan HTTPS urls instead of HTTP without a lot of work. I wonder if the scan path information is stored in the WSS Search database.
I resolved a similar type message.
WSS Central Console --> Operations --> Alternate Address Mapping
I reset the default Sharepoint - 80 site back to the servername.
Once this was configured, the crawling warnings went away.
I tried changing these values so the links in outgoing mail (for alerts, workflow etc) would display the external (public) IP address.
Drew, can you tell me what you changed it from in order to get this to work? I have these Alternate Access Mappings:
Thanks in advance,
FF
Zoiks_Eh wrote: I resolved a similar type message.
WSS Central Console --> Operations --> Alternate Address Mapping
I reset the default Sharepoint - 80 site back to the servername.
Once this was configured, the crawling warnings went away.
I tried changing these values so the links in outgoing mail (for alerts, workflow etc) would display the external (public) IP address.
I struggled with this exact error for the better part of a day before figuring out what the problem was, at least in my case. I'm actually kind of surprised by the cause of it all.
I had been testing Sharepoint in all of the popular browsers and found out that Safari doesn't support kerberos authentication. So I set the auth method to Basic (and disabled integrated auth). That got Safari working, but apparently Sharepoint Search Services won't log in with basic auth. Enabling Integrated auth (I still kept basic auth checked) immediately fixed the error.
- Предложено в качестве ответаDave McMahonMVP19 мая 2009 г. 16:49
O yes... This did it for me as well! Good find!
Bill
- Worked for me too, but now i get another problem with the integrated auth.
Now the users have to log in like: domainname\username
and the default domainname is the wrong one -> it is my local domainname and the machine i like to connect is a subdomain of our local one.
Problem is that it set the wrong one in front mydom\username instead of the subdomain ext\username
i.e.
local is: username@mydom.com
extern: username@ext.mydom.com
So my question:
Is it possible to log in only by typing the username while IIS uses integrated win auth. and basic auth?
or
Is it possible to set the right domain name (automatically) in front of the username or like the example above when a user only types in his username?
Thanks for help
Ramane - Seems the solution mentioned to change callbacks in IIS is not a solution likely for the WSS issue. This is a debug from within SharePoint and the second solution mentioned with the alternative access mapping should work for most people as you easily forget to set the HTTP - HTTPS translation.
I am testing this right now, as I fell in the same trap. Also I would not suggest to change the Registry when doing very legitimate actions like creating a new Web Application.
Regards. - Method 1, Works great for me, in my case i have 3 webapplications with host headers
- I have tried Method 1 & 2 with no luck.
Can someone tell me how to check the settings for this "Please make sure that your Content Access Account has enought privileges on the data-sources". I have done very little with WSS 3.0 since the install and i am having a bit of trouble following all the suggestions.
- How do I determine the Content Access Account, I used our Domain Admin account to install the Windows server and SharePoint?
- Where do I give this account permissions?
- Should I create a separate account for this function?
Search Server 2008 Express
- I had also installed Windows Search Server Express on this server but have not done any configuration at this point but it too returns no results?
- Once I get the searchign fixed would it be best to only use the Search Server for all searches and how do I conf this so its easy and transparent to all users?
Any help would be greatly appreciated.
- I am having the exact same problem discussed in the thread. Running wss3. I have four different servers and 3 of them have the error:
The start address <sts3://>servername>/contentdbid={d901caff-7863-40aa-8460-c3ef9132cb89}> 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 three that have the error all have alternate access mapping entries for external access to the site. The server that is working has not had any alternate access mapping entries modified. On one of the failing servers, I removed the alternate access mapping entries and went back to the default but the error still persists.
Stupals: To get to the screen for setting the Content Access Acount: Central Administration > Operations > Topology and Services > Services On Server > Windows Sharepoint Services Search
I have no idea what settings need to be entered there to get it working. On my server in which search is working (and no alternate access mapping entries have been changed), Service Account is set to "Local Service", Content Access Account is set to "Local Service".
This something else I don't understand. For Service Account it says "The search service account must not be a built-in account in order to access the database. Examples of built-in accounts are Local Service and Network Service." yet the default account is "Local Service". If it must not be a built-in account such as "Local Service", why is the default setting "Local Service"?
Anyways, does anyone have a definitive howto for setting up search after alternate access mappings entries have been changed? I have been googling for hours and can't seem to find the answer.
Edit: I seem to have fixed this by following the instructions for method 2 here: http://support.microsoft.com/kb/896861
I am running Windows Server 2008 and IIS7 so I thought it would not apply but apparently it does.
Edit 2: I also changed:Application Management > Application Security > Authentication providers > Default Zone
IIS Authentication settings to: Checked Integrated Windows authentication (negotiate) and also checked basic authentication.
Is it ok to use basic authentication as long as it is being accessed via ssl? - I pulled my hair out for about 2 weeks trying to solve this very problem. I checked and double-checked the following;
- account permissions and passwords
- start/stop search service
- configure search through Central Administration (again and again and again and...)
- specifying search server/content database through Central Administration
- Alternate Access Mappings (irrelevant to my config)
I also found a number of fixes through google that didn't work or apply to my config;
- eg DisableLoopbackCheck
- Extending web application to use NTLM authentication by default
I was ready to give up when I saw in the Event Viewer on the search server that the "index failed to crawl - permission denied" errors occurred at the same time as kerberos errors for unknown SPNs. eg;
A Kerberos Error Message was received:
on logon session
Client Time:
Server Time: 2:48:27.0000 3/17/2009 Z
Error Code: 0x7 KDC_ERR_S_PRINCIPAL_UNKNOWN
Extended Error:
Client Realm:
Client Name:
Server Realm: DOMAIN.COM
Server Name: HTTP/intranet.domain.com
Target Name: HTTP/intranet.domain@domain.com
Error Text:
File: 9
Line: ae0
Error Data is in record data.
So, I added an SPN for HTTP/intranet and HTTP/intranet.domain.com using the AD account we use for our search. The next attempt to index was successful and we now have search results!!!
Our environment is;
WSS 3.0
2 web servers in NLB farm
1 database server
Kerberos authentication
host headers enabled for WSS site in IIS
Hope this helps someone as it was extremely frustrating to sort out.- Предложено в качестве ответаtechstop 17 марта 2009 г. 7:16
- I started getting this error two days ago, up until then our search has been working fine.
Restarting the search and timer services on the application server resolved the issue for me.
I also noticed that as the search service tried to index changes and was denied access, it started removing entries from the search database. Once it started working again it did not pick these back up, only items that were in the change log.
If you fix the issue you may need to initiate a full crawl to repopulate the search index.
For WSS 3.0
stsadm -o spsearch -action fullcrawlstart- Предложено в качестве ответаmimijo 23 июля 2009 г. 19:02
- Great spot! This did it for me after the standard KB article did nothing!
- http://support.microsoft.com/kb/896861 worked for me using method 1 - adding the host header to the regsitry key, on one server.
Failed on our other WSS servers! Hi
I fixed the problem on my server
The problem is that we use a FQDN and also running the search service on the frontend server
Have a look on this KB http://support.microsoft.com/kb/896861 - Method 1: Disable the loopback check
It worked for me :)
Thank you, thank you, thank you!
I first followed http://geekswithblogs.net/karskip/archive/2007/11/30/117263.aspx to set up the service,
the when I got the error, http://support.microsoft.com/kb/896861 - Method 1 did the trick!
Cheers!
