none
Search crawl to SPS3://mysite.domain.com gives "Access Denied"

    Question

  • I am having an issue with indexing user profiles with the SPS3 protocol handler.   Each time it runs I get an "Access Denied" error in my crawl logs.   I have verified that the default content search account has full read permissions on the web application.   I have verified that I don't have a  loop back check issue.

    In my environment I have 3 seperate web applications.  One hosts intranet publishing content, one hosts collaboration content and the third is for the mysites.   The web applications all use host headers and share a single IP address.   Everything is over HTTP.

    My dev farm is configured with a single web front end, a single services server and a SQL server.    The services server is running the search admin and crawl components.  The web front end hosts the query component.

    In the search content source the URL being crawled is SPS3://mysites.domain.com and http://mysites.domain.com.   In the crawl logs it shows the following error for SPS3://mysites.domain.com:

    Access is denied. Verify that either the Default Content Access Account has access to this repository, or add a crawl rule to crawl this repository. If the repository being crawled is a SharePoint repository, verify that the account you are using has "Full Read" permissions on the SharePoint Web Application being crawled. ( HttpStatusCode Unauthorized The request failed with HTTP status 401: Unauthorized. )

    Any ideas?

     

    Tuesday, May 04, 2010 6:09 PM

Answers

  • I had the same issue. I changed the default content crawl account after install. By default the web application policy is updated but not the profile store access.

     

    Go to manage service applications, select user profile service application, and click administrators. You will see your old content access account in there with 'Retrieve people and data for search crawlers' permission, add your new content access account and run a full crawl.

     

    Hope this helps someone.

    • Proposed as answer by ruess Wednesday, August 04, 2010 2:25 AM
    • Marked as answer by Margriet Bruggeman Wednesday, April 18, 2012 2:49 PM
    Saturday, May 15, 2010 12:13 AM
  • I think you are on to something.  Although that talks about fast search it appears that I did miss configuring the permissions for my user profile service application.  I added my default crawl account and gave it "full control" permissions and now I get the error "Error in PortalCrawl Web Service" instead of access denied.   I am guessing that means I am 1 step further.

    I see that there is a permission level called "Retrieve People Data for Search Crawlers".   I am going to just select that next and see what it gives me. 

    Update: Ok... I still get the Error in PortalCrawl Web Service if I point the url to sps3://mysites.domain.com.    I should mention I am using host headers for my web applications.   Not sure if that is an issue.     Now I just pointed the address to sps3://servername which is an empty test site on the server that is not using host headers.    ...The crawl completed successfully!     I am now seeing an error related to audiences :(   I am going to dig in and see if it is realted to the changes I just made.    I also now need to figure out what the crawler is failing with host headers.

    • Proposed as answer by Frank-Ove Monday, June 21, 2010 11:41 AM
    • Marked as answer by Margriet Bruggeman Wednesday, April 18, 2012 2:49 PM
    Tuesday, May 11, 2010 12:11 PM

All replies

  • Not sure if this is the issue or not, but remember that host headers are specific.  If you put in a host header of MySites when you built the site then it won't be able to access the site using http://mysites.domain.com only http://mysites.  Even if you've added an AAM it still won't work.  You would need to either extend the web app or bind a different FQDN host header to the site.  In IIS check your bindings and make sure that you have either both mysites and mysites.domain.com or just mysites.domain.com.
    Paul Stork SharePoint Server MVP
    Tuesday, May 04, 2010 6:21 PM
  • You are correct Paul and I should have put that in my last post.  I do have the fully qualified domain name in the host header in IIS and I am using the FQDN in the content source.    I can access the My Sites in the browser with no issue.   I just can't get search to crawl.

    Tuesday, May 04, 2010 6:23 PM
  • I get the same crawl issue using SP2010 Beta 2 on Windows Server R2.

    SPS3://servername

    and

    SPS4://servername

    Tuesday, May 04, 2010 7:45 PM
  • I have been trying everything I can think of and still no luck.   Any ideas on how to go about troubleshooting this issue?    Anyone from Microsoft listening in?

    I found the following in the ULS log:

    FLTRDMN: Errorinfo is "HttpStatusCode Unauthorized The request failed with HTTP status 401: Unauthorized."  [fltrsink.cxx:553]  d:\office\source\search\native\mssdmn\fltrsink.cxx

    The crawl account has full read access on the  My Sites web application.  

    Monday, May 10, 2010 2:20 PM
  • I know you've said you've verified read access by the crawl account but have you actually logged into the server and used IE to browse that site with the crawl account?
    Monday, May 10, 2010 3:38 PM
  • It does crawl the site with http:// fine but when it goes to SPS3:// it fails with 401 unauthorized.    Because of this people search does not work.

    Using a network trace I can see s web service call to http://mysites.domain.com/_vti_bin/spscrawl.asmx and it successfully authenticates the account and returns back infomration including a link to the DISCO.

    Next I see another call back to the webservice but this time it is calling the GetSite method.   It is again challenged for credentials but at the end of the handshake it gives a 401 Unauthorized message.

     

    Monday, May 10, 2010 3:45 PM
  • You could try it with

    http://svengillis.blogspot.com/2008/10/access-denied-when-crawling-moss.html

    but that didn't worked by me, but by a lot of others...

    • Proposed as answer by Gr8Work Thursday, October 21, 2010 9:41 PM
    Monday, May 10, 2010 7:24 PM
  • Thanks for the idea, but I did already do that.    Still no luck. :(

    Monday, May 10, 2010 7:44 PM
  • Okey, just get mine to work with this:

    http://blogs.technet.com/speschka/archive/2010/02/22/why-do-i-get-an-access-denied-error-when-managing-user-contexts-in-sharepoint-2010.aspx

    Monday, May 10, 2010 7:48 PM
  • I think you are on to something.  Although that talks about fast search it appears that I did miss configuring the permissions for my user profile service application.  I added my default crawl account and gave it "full control" permissions and now I get the error "Error in PortalCrawl Web Service" instead of access denied.   I am guessing that means I am 1 step further.

    I see that there is a permission level called "Retrieve People Data for Search Crawlers".   I am going to just select that next and see what it gives me. 

    Update: Ok... I still get the Error in PortalCrawl Web Service if I point the url to sps3://mysites.domain.com.    I should mention I am using host headers for my web applications.   Not sure if that is an issue.     Now I just pointed the address to sps3://servername which is an empty test site on the server that is not using host headers.    ...The crawl completed successfully!     I am now seeing an error related to audiences :(   I am going to dig in and see if it is realted to the changes I just made.    I also now need to figure out what the crawler is failing with host headers.

    • Proposed as answer by Frank-Ove Monday, June 21, 2010 11:41 AM
    • Marked as answer by Margriet Bruggeman Wednesday, April 18, 2012 2:49 PM
    Tuesday, May 11, 2010 12:11 PM
  • Thank you for the tip, this fixed it. Our crawl of people is working now. I would like to add one clarification.

    After adding your search service account as an administrator, you need to grant the permission "Retrieve People Data for Search Crawlers". Simply adding "Manage Profiles" wasn't sufficient.

    I am forwarding this to Microsoft Support.

     

    Tuesday, May 11, 2010 12:36 PM
  • My audience related errors just went away... I am guessing there was a timer based update I had to wait for.    It looks like people search is working for me now too.   I just need to figure out why it bombs if I point it at a url that is host header based.
    Tuesday, May 11, 2010 12:43 PM
  • Mike, this helped me solve an issue I was having, where http/https crawling worked fine, but not sps3. Thx for posting.
    mc
    Tuesday, May 11, 2010 6:17 PM
  • I had the same issue. I changed the default content crawl account after install. By default the web application policy is updated but not the profile store access.

     

    Go to manage service applications, select user profile service application, and click administrators. You will see your old content access account in there with 'Retrieve people and data for search crawlers' permission, add your new content access account and run a full crawl.

     

    Hope this helps someone.

    • Proposed as answer by ruess Wednesday, August 04, 2010 2:25 AM
    • Marked as answer by Margriet Bruggeman Wednesday, April 18, 2012 2:49 PM
    Saturday, May 15, 2010 12:13 AM
  • We also had permission issues using ports (82) instead of host headers. After setting up the sites using host headers, and added the crawl account under User Profile Service Application - > Administrators, the profiles were successfully crawled.
    Monday, June 21, 2010 11:43 AM
  • This solution worked for me
    Wednesday, August 04, 2010 2:25 AM
  • Thank you CH_FM... the link you sent above... Seemed like it did the trick... So that's where the permissions for SSP's (from the MOSS 2007 world) vanished to !!!
    Thursday, October 21, 2010 9:43 PM
  • I have a SharePoint 2010 Farm with FAST 2010 Search Server for Search.

    People Search is not working and in the crawl log, I get this result:

    Access is denied. Verify that either the Default Access Account has access to this repository, or add a crawl rule to crawl this repository. If the repository being crawled is a SharePoint repository, verify that the account you are using has "Full Read" permissions on the SharePoint Web Application being crawled. (HttpStatusCode Unauthorized The request failed with HTTP Status 401: Unauthorized.)

    How do I resolve this?


    Karthick
    Friday, February 25, 2011 5:20 AM
  • Are you still getting this, Karthick?   I am not doing a people search, but I am still getting the error:

    Access is denied. Verify that either the Default Content Access Account has access to this repository, or add a crawl rule to crawl this repository. If the repository being crawled is a SharePoint repository, verify that the account you are using has "Full Read" permissions on the SharePoint Web Application being crawled.

    I have used the Disable Loop Back registry hack.   I have two different websites hosted on the computer.  One crawls successfully, the other does not with the above error.


    Stan McGinnis

    Tuesday, March 01, 2011 3:42 PM
  • Stan, I was able to resolve this and get my people search to work, after I gave the service account read permissions on the user profile service application itself. The registry modification really did not have any impact. I think you should try this as well, I mean giving right permissions on the required service applications.
    Karthick
    Tuesday, March 01, 2011 4:17 PM
  • Thanks for the update, Karthick.  It appears that the Search Service Account has full permissions to the site and services.  I don't know what is problem.  (we're not using the people search).

     

    Stan McGinnis

    Tuesday, March 01, 2011 5:02 PM
  • After following all the steps suggested above, i was still getting this error. I went back to the user policy for the web app and discovered I had more than 1 account listed in there for the search crawling account. Why this was the case i still do not know (i have been learning on the go so possibly as a result of a past setup issue) but by granting each account in there the 'Retrieve People data for search crawlers permission' I was able to clear the sps3 access denied error. Tested by removing the newly added permission for the second account and the error reappeared.
    • Proposed as answer by ns2004 Wednesday, July 27, 2011 8:29 PM
    Tuesday, March 01, 2011 8:40 PM
  • Thanks J for posting this. It made me go back and double check this step. This was my issue excatly. Thanks!!
    Tuesday, May 17, 2011 8:18 PM
  • Thanks jhaebets - this worked for me.  I am building everything using Powershell scripts.
    GregM
    Friday, July 08, 2011 3:42 PM
  • Hey,

    This article might help to troubleshoot your issue..

    http://kalashnikovtechnoblogs.blogspot.in/2012/02/troubleshooting-crawl-issues-for-ssl.html


    Thanks,
    Kalashnikov
    http://kalashnikovtechnoblogs.blogspot.in
    Friday, February 17, 2012 3:15 PM
  • jhaebets,

    thnx, this one solved my issue with 401 error on people search !

    Regards

    Martin

    • Proposed as answer by IM-consult Sunday, March 18, 2012 5:36 PM
    • Unproposed as answer by Margriet Bruggeman Wednesday, April 18, 2012 2:50 PM
    Sunday, March 18, 2012 5:35 PM
  • On the nose!  I recently rebuilt my User Profile Service.  Adding the search account to the User Profile Service Administrators and giving it full permissions fixed the search errors on sps3://mysites.  Thanks!
    Friday, June 08, 2012 12:14 AM
  • This is the steps that fixed this issue for me. I left the existing account in place and gave it Full Control, and added my default account and gave it full control and now the SPS3://xxxxxxxxxxxx  site gets crawled. Thank you jhaebets
    Tuesday, June 25, 2013 4:39 PM
  • Hi Everyone,

    Issue: Unable to crawl sps3://webapp name, in my case it is effiatech(sps3://effiatech)

    Troubleshooting Done:

    1. checked Service connection on web app level ...User profile service was selected as default group of connection

    2. User profile service has correct permission(Retrieve people data for search crawlers)  under Administrator tab under service application for the domain user which we have selected while creating the User profile service app.

    Tried crawling again but still pops up with the error access denied for sps3://effiatech..

    3. Register a Disableloopbackcheck entry in registry still no luck.

    Resolution:

    1. Added Blank site under root collection (/), crawled again and issue got fix, people directory search is happening..

    Thank you.

    Tuesday, January 28, 2014 8:07 AM
  • Thanks, Jhaebets, I know it is years later, but this just saved me some time.
    Tuesday, September 02, 2014 6:01 PM
  • I had the same issue. I changed the default content crawl account after install. By default the web application policy is updated but not the profile store access.

     

    Go to manage service applications, select user profile service application, and click administrators. You will see your old content access account in there with 'Retrieve people and data for search crawlers' permission, add your new content access account and run a full crawl.

     

    Hope this helps someone.


    This worked for me as well. Thanks for posting.
    Friday, March 06, 2015 2:49 PM