"Access is denied. Check that the Default Content Access Account has access to this content"
Our search is not working. The crawl log indicates following error: "Access is denied. Check that the Default Content Access Account has access to this content, or add a crawl rule to crawl this content. (The item was deleted because it was either not found or the crawler was denied access to it.)".
If I check the event viewer, it indicates following error: "Login failed for user 'NT AUTHORITY\NETWORK SERVICE'. [CLIENT: <local machine>]"
My default content access account is another one than this NT AUTHORITY\NETWORK SERVICE account. The content access account password is correct. Apparently this content access account is translated to the NETWORK SERVICE account upon a crawl. And this network service account doesn't has the appropriate rights on database level. How can I fix this?
- BearbeitetMike Walsh MVPMVP, ModeratorDienstag, 7. April 2009 08:11" " added around the error message (to make it clear this IS an error message
Antworten
- Had this problem and solved it by using user@domain.local instead of domain\user when specifying the Default Content Access Account.
Central Administration --> SSP --> Search Administration | Default Content Access Account.
Still puzzled as to why this cropped up at all. Crawl logs say that crawls were successful as of a week ago. Then suddenly it stopped. No changes were made (I only touch this machine to do backups and apply any patches, which is rare). (The patch part is rare, not the backup part.)
HTH- Als Antwort vorgeschlagenJ Siegmund [MCTS] Dienstag, 7. April 2009 07:54
- Als Antwort markiertMike Walsh MVPMVP, ModeratorDienstag, 7. April 2009 08:11
- I had a post in my Blog about this that might help you. It was targeted at BDC crawling, but should apply to you also.
http://www.keirgordon.com/2007/04/bdc-crawl-error-parameter-is-incorrect.html
You can change that default content access account in the search settings for your shared service provider.
Keep in mind that whatever account you choose to crawl with, you will need to add it to your SQL server with permissions.
Alle Antworten
- I had a post in my Blog about this that might help you. It was targeted at BDC crawling, but should apply to you also.
http://www.keirgordon.com/2007/04/bdc-crawl-error-parameter-is-incorrect.html
You can change that default content access account in the search settings for your shared service provider.
Keep in mind that whatever account you choose to crawl with, you will need to add it to your SQL server with permissions. check ur default access account has the permission to crawl or not first i don't think so NT AUTHORITY\NETWORK SERVICE is the account should be used. try with the account in default content access account on which ur servcies of moss are running i mean office sharepoint servcies search or check with the administrator account also to crawl.u might get it.cheers up
- I'm also working through this. Have found many posts but no solution. I've verified that the account has proper permissions and that both the Default Content Access Account and the account used to run the Office Sharepoint Server Search are the same. Now I've got a new error which I can find no information on "The password for the content access account cannot be decrypted because it was stored with different credentials. Re-type the password for the account used to crawl this content."
Thoughts?
Thanks,
Michael
mrw - MichaelinSyracuse said:
I'm also working through this. Have found many posts but no solution. I've verified that the account has proper permissions and that both the Default Content Access Account and the account used to run the Office Sharepoint Server Search are the same. Now I've got a new error which I can find no information on "The password for the content access account cannot be decrypted because it was stored with different credentials. Re-type the password for the account used to crawl this content."
Thoughts?
Thanks,
Michael
mrw
I was also getting the same error but was able to solve the problem by going back to the Search Settings page under SSP and then reentering the credentials for the content crawler account.
Try if that works for you.
Vivek I am getting the same error on a document library... not a sub site or at the site collection level. THe main user is adding meta-data to each of the documents within this specific doc lib. i will say that the doc lib in questiosn does contain ALOT of folders. There are not stacked, maybe 2 levels deep at best. Could the folders be causing an issue? the user adding meta-data while it is crawling?
- Hi all,
The resolution for this was to add the following registry key
1) Click Start, click Run, type regedit, and then click OK.
2) In Registry Editor, locate and then click the following registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
3) Right-click Lsa, point to New, and then click DWORD Value.
4) Type DisableLoopbackCheck, and then press ENTER.
5) Right-click DisableLoopbackCheck, and then click Modify.
6) In the Value data box, type 1, and then click OK.
7) Quit Registry Editor, and then restart your computer.http://support.microsoft.com/kb/896861
...Sandeep Lad
- Als Antwort vorgeschlagenHeliguyG6 Dienstag, 12. Mai 2009 14:03
- Hi all,
The resolution for this was to add the following registry key
1) Click Start, click Run, type regedit, and then click OK.
2) In Registry Editor, locate and then click the following registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
3) Right-click Lsa, point to New, and then click DWORD Value.
4) Type DisableLoopbackCheck, and then press ENTER.
5) Right-click DisableLoopbackCheck, and then click Modify.
6) In the Value data box, type 1, and then click OK.
7) Quit Registry Editor, and then restart your computer.http://support.microsoft.com/kb/896861
...Sandeep Lad
- Als Antwort vorgeschlagenPSeale Mittwoch, 1. April 2009 18:14
- Sandeep, today you're my hero, that worked!
- Had this problem and solved it by using user@domain.local instead of domain\user when specifying the Default Content Access Account.
Central Administration --> SSP --> Search Administration | Default Content Access Account.
Still puzzled as to why this cropped up at all. Crawl logs say that crawls were successful as of a week ago. Then suddenly it stopped. No changes were made (I only touch this machine to do backups and apply any patches, which is rare). (The patch part is rare, not the backup part.)
HTH- Als Antwort vorgeschlagenJ Siegmund [MCTS] Dienstag, 7. April 2009 07:54
- Als Antwort markiertMike Walsh MVPMVP, ModeratorDienstag, 7. April 2009 08:11
- Same here! I also noticed all search crawls suddenly stopped working. Used elpollodiablo's solution and now they seem to run again. CPU is spiking against the roof so there must be something happening :)
Strange behaviour though, I updated the server yesterday with the latest Windows updates; perhaps those had something to do with this?
MCTS in Web Application Development in .NET 2.0 - Hi there,
For some reason I'm always having authentication troubles with the search crawling in SharePoint.
Some things I have noticed:
1) The content access account doesn't need specific permissions in SQL server. Although somehow my SPSearch account (content access) ended up with sysadmin privleges. :S
2) My latest troubles with the crawler seemed to be a direct result of installing KB963027 (supposedly a "cumulative update for IE7"). This same update caused all sorts of other issues with NTLM (I couldn't log in to any of my sharepoint sites at all - except central admin), so I had to make the DisableLoopbackCheck registry entry... Before entering this, search crawling was failing for ALL my local sharepoint sites except one (which seemed to be working only because I had some crawl rules set up for it) - as per Sandeep's post.
3) Simply adding a crawl rule like "include http://site/*" fixed the problem for that site only.
4) I tried elpollodiablo's solution, unfortunately sharepoint said the username was invalid when I entered it in that format.
5) The problem seems to cause itself at random times, without any user input.
My conclusion would be that the majority of people here are experiencing the same problems, due to windows updates. The same problems seem to be evident on multiple OSes, suggesting that it is some core component of NTLM which is at fault. the LSA loopback check thing (whatever the ____ that is!!?) seems to be the root cause, seemingly invalidating the "default content access account" setting in sharepoint. If the default content access account value is re-saved the problem seems to be fixed. Also adding a crawl rule seems to bypass the content access account problem, even if you have "use the default content access account" specified for the rule.
The main issue here is the sheer unpredictability of the problem...!
I really think Microsoft should do something to fix this. There's definitely a bug in there somewhere, and leaving the user to figure out what's going on isn't really acceptable.. - Sandeep is the bomb!!! Worked like a charm.
- Als Antwort vorgeschlagenStowner Dienstag, 28. April 2009 22:39
- Hey!
Your`e the man Sandeep.
I spent weeks searching for solution, this worked.
Fredrik This issue was caused by the .NET Framework 3.5 SP1 & Family Updates, in that the authentication methods for communication between the specific SharePoint services were changed. The DisableLoopbackCheck does in fact work, but I expect it will be the cause for additional headaches in the near future when additional Service Packs are released.
For the time being, remember to make this change on all SharePoint Servers in your farms. If not, you have additional problems, such as incredible latent pages, the application pools shutting down unexpectedly - yes...actually shutting down, and corrupting your content databases to the point that Content Deployment ad Quick Deploy will no longer work.
Fun Stuff
- Steve- We were getting the same error after the latest round of security patches: "Access is denied. Check that the Default Content Access Account has access to this content, or add a crawl rule to crawl this content. (The item was deleted because it was either not found or the crawler was denied access to it.)".
Adding DisableLoopbackCheck registry value to all of our SharePoint farm servers fixed the issue. No restart of services or machines was needed.
Andre Galitsky, MS-Certified SharePoint Administrator, Minneapolis, MN -- My SharePoint Blog: http://www.sharepointnomad.com - This also fixed my SharePoint problem. But it also caused RDC terminal server connections to be denied. Anyone else experience this or have a fix?
- Sandeep is indeed the man...Fixed
Thanks much!- BearbeitetBPulliam Dienstag, 26. Mai 2009 13:52spelling error
- You are my hero
Sandeep Lad ,
i spent 2 hours to fix this freaking error , it also fixes the problem to visit site from sharepoint server .
Sem - Sandeep, its true you are the man. I'll spread the word!
Thank heaps, spent about 3 hours on this one prior to finding your post.
How did you come across the loop back reg key as the fix? - Indeed, Sandeep's solution worked. A reboot was not needed, but an IIS reset and reset the search service.Thanks. This stuff should not be happening.
- Thanks to Sandeep's solution. It worked like a charm...You are indeed a genius. This solution helped to resolve an emergency. I thank all of you who went through this before me to arrive at this solution and posting it online. Thanks Again to Sandeep and the rest.
- Hi ,
I am having the same error as"Our search is not working. The crawl log indicates following error: "Access is denied. Check that the Default Content Access Account has access to this content, or add a crawl rule to crawl this content. (The item was deleted because it was either not found or the crawler was denied access to it.)"."
I am having windows 2003 server with SP2 installed.
My situation is.
I have 2 web application in my SPP , one for production which is running for past 3 yrs and another one i created for testing by taking backup from PROD site & restore in new web application.
When i search for some items in both site i can able to find the Test Site in my result and not able to see the Prod site.
I got error saying crawl log indicates following error: "Access is denied. Check that the Default Content Access Account has access to this content, or add a crawl rule to crawl this content. (The item was deleted because it was either not found or the crawler was denied access to it.)".
Both the site is rrunning with same yuser access right but getting error only for Prod site.
Pls help me.
Regards,
Hari Hari:
The first thing I'd do is to make sure that your Default Content Access account does indeed have access to the content. Log in to your SharePoint site in Prod using this account and see if you can access the content via your browser. This account needs at least Reader access in order to be able to index it.
I'd also suggest separating your Prod and Test environments. If you can't set them up on separate instances of SharePoint, at the very least create separate SSPs for each environment. You probably don't want your Prod users searching your Prod site and finding Test content.
Andre Galitsky, MS-Certified SharePoint Administrator, Lexington, KY -- My SharePoint Blog: http://www.sharepointnomad.com- Hi Andre,
Thanks a lot for your information.
Sure i will create new SPP and associate my Test site with new SSP.
Currently i dont know the password used for Default Content Access Account id so i am planning to create new user and assign it to Default Content Access account.
Bcoz i took backup of Prod web application and restored in new Test web application just 5 days back and i can able to get search results from Test site but not from Prod site and getting Access Denied error only for my Prod site during Content Crawl.
Pls let me know whether i need to create Domain account or local account for Search and where and all i need to set this new user id & pwd ?
is it enough if i set new id & pwd in Default content access account page? or i need to set this in DB also?
Kindly help me.
Regards,
Hari Your Default Content access account must be a domain account. Please review these resources for more information:
http://technet.microsoft.com/en-us/library/cc678863.aspx
http://technet.microsoft.com/en-us/library/cc263445.aspx
http://support.microsoft.com/default.aspx/kb/934838
As always, try all your configuration changes in Test first, before deploying in Production.You might also want to purchase a good SharePoint admin book for a thorough review of security practices and administration, such as this one:
http://www.amazon.com/Microsoft%C2%AE-Office-SharePoint%C2%AE-Administrators-Companion/dp/0735622825
Andre Galitsky, MS-Certified SharePoint Administrator, Lexington, KY -- My SharePoint Blog: http://www.sharepointnomad.com- Hi Andre,
Thanks a lot for information sharing.
Will try changing the default access account and get back to you.
Regards,
Hari Sandeep Your solution worked.
Everyone,
Cautious: Go thru the below link before you switch it on PROD environment.
http://harbar.net/archive/2009/07/02/disableloopbackcheck-amp-sharepoint-what-every-admin-and-developer-should-know.aspx- THanks Sandeep...
I had the same problem and your post helped me resolve it. This registry fix worked for me as well, The real question here is what did it do to allow crawls to work again? I like the rest of these people were getting Access Denied, which you'd think was a permissions issue, but obviously was not. Thanks for the fix!
