locked
"Access is denied. Check that the Default Content Access Account has access to this content"

    Question

  • 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?

     

    • Edited by Mike Walsh FIN Tuesday, April 07, 2009 8:11 AM " " added around the error message (to make it clear this IS an error message
    Monday, May 21, 2007 12:01 PM

Answers

  • 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
    Friday, April 03, 2009 9:46 PM
  • 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.


    Monday, May 21, 2007 5:57 PM

All replies

  • 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.


    Monday, May 21, 2007 5:57 PM
  • 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 Smile

    Tuesday, September 11, 2007 9:18 AM
  • 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
    Thursday, September 04, 2008 6:48 PM
  • 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
    Tuesday, September 23, 2008 3:37 AM
  • 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?

    Thursday, October 09, 2008 9:55 PM
  • 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

     

    • Proposed as answer by HeliguyG6 Tuesday, May 12, 2009 2:03 PM
    Tuesday, March 31, 2009 6:53 AM
  • 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

     

    • Proposed as answer by PSeale Wednesday, April 01, 2009 6:14 PM
    Tuesday, March 31, 2009 6:53 AM
  • Sandeep, today you're my hero, that worked!
    Wednesday, April 01, 2009 6:15 PM
  • 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
    Friday, April 03, 2009 9:46 PM
  • 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
    Tuesday, April 07, 2009 7:54 AM
  • 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..
    Tuesday, April 28, 2009 4:37 AM
  • Sandeep is the bomb!!!  Worked like a charm. 
    • Proposed as answer by Stowner Tuesday, April 28, 2009 10:39 PM
    Tuesday, April 28, 2009 10:03 PM
  • Hey!
    Your`e the man Sandeep.
    I spent weeks searching for solution, this worked.

    Fredrik
    Thursday, April 30, 2009 12:54 PM
  • 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

    Friday, May 01, 2009 2:51 PM
  • 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
    Thursday, May 07, 2009 3:13 PM
  • 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?
    Tuesday, May 26, 2009 3:28 AM
  • Sandeep is indeed the man...Fixed

    Thanks much!
    • Edited by BPulliam Tuesday, May 26, 2009 1:52 PM spelling error
    Tuesday, May 26, 2009 1:52 PM
  • 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
    Monday, June 01, 2009 1:21 PM
  • 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?
    Tuesday, June 09, 2009 2:14 AM
  • 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.
    Monday, June 15, 2009 8:21 PM
  • 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.
    Wednesday, July 01, 2009 4:30 PM
  • 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


    Tuesday, July 28, 2009 1:02 PM
  • 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
    Wednesday, July 29, 2009 2:07 AM
  • 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
    Wednesday, July 29, 2009 6:04 AM
  • 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
    Wednesday, July 29, 2009 8:43 PM
  • Hi Andre,

    Thanks a lot for information sharing.
    Will try changing the default access account and get back to you.


    Regards,
    Hari
    Saturday, August 01, 2009 9:08 AM
  • 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

    • Proposed as answer by Kish B Friday, August 21, 2009 7:35 PM
    • Edited by Kish B Monday, August 24, 2009 4:07 PM
    Friday, August 21, 2009 7:34 PM
  • THanks Sandeep...

    I had the same problem and your post helped me resolve it.
    Tuesday, September 22, 2009 6:08 AM
  • 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!

    Friday, November 20, 2009 6:07 PM
  • 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

     


    you rock sandeep!
    Tuesday, January 05, 2010 8:30 PM
  • 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

     


    you rock sandeep!
    Worked fro me too.  Nice one Sandeep
    Friday, January 15, 2010 2:59 PM
  • Sandeep, You rock!  
    Wednesday, January 27, 2010 3:35 PM
  • Hooray for Sandeep.  Your solution worked beautifully

    Wednesday, January 27, 2010 8:27 PM
  • Thank u very much Sandeep, worked for me as well.
    Friday, January 29, 2010 2:45 PM
  • Thank you very much Sandeep. Great work ;-)
    Thursday, February 04, 2010 11:22 AM
  • Thank you! Worked perfect for me after looking for days.
    Thursday, February 04, 2010 3:19 PM
  • I discovered that my problem was because of site level permissions.  I had a couple sites that did not inherit from the parent and I hadn't allowed any access for the default content access account to those sites.  Even though I created a rule to exclude that site, the index started running as soon as I gave the default content access account read access to those sites.
    Monday, April 26, 2010 6:32 PM
  • I believe I just conquered this.  I changed my content access account to administrator and that worked.  Along the way I had made the registry entry to get rid of the sts: gathering error, the loopback entry and removed my crawl rule completely. 

    It's odd that M$ sets up these things with Service accounts but for them to work you have to change them.

    Monday, May 17, 2010 4:42 PM
  • The disable loop back check worked for me also. My sharepoint server is running win 2008. the sharepoint site is enabled for SSL with a Self Signed Cert.

    After disabling the loop back check I can also open the sharepoint site on the server. Prior to
    adding the disable loopbackcheck I was unable to launch the  sharepoint https site on the server.
    The search crawl failed to work also, regardless if I used the sharepoint admin account or a less privilaged account instead for the crawl.

    It appears that the loopback check causes problems right out of the box. The begging question is why its the default of a sharepoint install ?. Bug ?

    Thanks Paul

    Wednesday, August 04, 2010 8:40 PM
  • Hi,

    I am going crazy with people search:@. People profiles are not crawling at all.

    error: "sps3://mysite:2009

    The object was not found. (The item was deleted because it was either not found or the crawler was denied access to it.)"

    We have separate test and prod environment. People search is working fine in Test. 

    Environment: MOSS 2007 SP2 on WINDOWS 2008R2.

    steps taken:

    - verified that default content account can access my site.

    - Root level (/) site exist in my site web application(http://mysite:port)

    - my site url is listed as sps3//mysite:port/ in the content source. Also created new content source for my site. Did full crawl multiple times.

    - Reset all crawl settings and started again. Everything was crawled except people. 

    - Users profile exist in SSP > User profiles and properties.

    Not sure what else i can try!

    But here is a strange behavior in SSP > personalization services permssions

    - I have modified permission for default content account(just granted Manage Analytics, Manage User Profiles, Personal Features). 

    - When i did a full crawl, the permission was reset for this account to ALL.

    - Then I deleted default content account from SSP > perso...service permission and did full crawl again.

    - strangely, the account came back with all permissions selected. 

    - I deleted/modified other accounts in here and for those changes stay.

    So, basically when crawl happens, the permission for this account is reset.

    Please response if you have any suggestions.

     

     

    Tuesday, August 17, 2010 6:18 PM
  • Thank you Sandeep!  DisableLoopbackCheck got it working.
    Wednesday, September 15, 2010 4:34 PM
  • After reading Sandeep's Quote and looking all the responses... I was right on the top of my seat.

    I thought finally I got the solution.

     

    But... NO :( ... Its not happening for me.

     

    I am yet to try elpollodiablo's solution. Dont know if it will help.

    Thursday, September 23, 2010 1:58 PM
  • OK... i have changed 'Default content access account' from domain\service_account to service_account@domain.com.

    Will check the logs and put my findings.

    Friday, September 24, 2010 12:37 PM
  • Wouldnt recommend doing the DisableLookBack thing.. Its there as a security measure..

    Id recommend method 1 of http://support.microsoft.com/kb/896861:

    Method 1: Specify host names (Preferred method if NTLM authentication is desired)

    To specify the host names that are mapped to the loopback address and can connect to Web sites on your computer, follow these steps:

    1. Set the DisableStrictNameChecking registry entry to 1. For more information about how to do this, click the following article number to view the article in the Microsoft Knowledge Base:
      281308  (http://support.microsoft.com/kb/281308/ ) Connecting to SMB share on a Windows 2000-based computer or a Windows Server 2003-based computer may not work with an alias name
    2. Click Start, click Run, type regedit, and then click OK.
    3. In Registry Editor, locate and then click the following registry key:
      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0
    4. Right-click MSV1_0, point to New, and then click Multi-String Value.
    5. Type BackConnectionHostNames, and then press ENTER.
    6. Right-click BackConnectionHostNames, and then click Modify.
    7. In the Value data box, type the host name or the host names for the sites that are on the local computer, and then click OK.
    8. Quit Registry Editor, and then restart the IISAdmin service.

    I did that.. And its working now for me.

    Monday, September 27, 2010 2:14 AM
  • Looks like this article is moving away from the actual problem.

    I am still getting the same problem.

    On search administration page:-

    Default access account shows 'Error'.

     

    I have tried all above options, its not working for me.

    • Proposed as answer by mooseman Friday, December 03, 2010 9:43 PM
    Friday, October 01, 2010 10:59 AM
  • Genius Sandeep, pure Genius!
    Keith Caravelli
    Thursday, October 28, 2010 9:13 PM
  • Sandeep, have you got a Blog somewhere I can follow?
    Keith Caravelli
    Thursday, October 28, 2010 9:15 PM
  • CHEERS Sandeep - pure genius!
    Friday, November 05, 2010 2:51 AM
  • None of the above suggestion worked for me.

    I did discover the solution for myself . It was quite simple. I just reset, re-entered my domain account used for my Sharepoint Service Account. It's the same account that I was in place prior to the SSP going rouge on me:

    1. Central Admin->Operations->Security Configuration->Service Accounts
    2. Select Web Application Pool
    3. Select "Windows SharePoint Services Web Application" from the Web Service drop-down
    4. then select the Site Collection from the Application Pool drop-down (the primary site collection will likely be port 80)
    5. Select an Account for this component-> Select Configurable so that you can enter the user credentials manually (use the std format DOMAIN\user-id) and Password
    6. REPEAT STEPS 1 THRU 5 FOR EVERY DOMAIN YOU WANT THE SEARCH TO CRAWL
    7. You must do an IISRESET /NOFORCE (this will not require a reboot)
    8. Now go to SSP and start a full crawl from the Search Administration->Content Sources->Local Office Sharepoint Server Sites drop-down.

    Should work like a champ.

    I have no idea why the Search Service porks itself from time to time, but I hope I can remember this simple process the next time this happens.

    Gbu

    • Proposed as answer by mooseman Friday, December 03, 2010 10:32 PM
    • Marked as answer by Mike Walsh FIN Friday, January 28, 2011 9:14 AM
    • Unmarked as answer by Mike Walsh FIN Friday, January 28, 2011 9:14 AM
    • Unproposed as answer by Mike Walsh FIN Friday, January 28, 2011 9:14 AM
    Friday, December 03, 2010 9:58 PM