Search crawl to SPS3://mysite.domain.com gives "Access Denied"
-
Tuesday, May 04, 2010 6:09 PM
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?
Answers
-
Tuesday, May 11, 2010 12:11 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 BruggemanModerator Wednesday, April 18, 2012 2:49 PM
-
Saturday, May 15, 2010 12:13 AM
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 BruggemanModerator Wednesday, April 18, 2012 2:49 PM
All Replies
-
Tuesday, May 04, 2010 6:21 PMNot 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:23 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 7:45 PM
I get the same crawl issue using SP2010 Beta 2 on Windows Server R2.
SPS3://servername
and
SPS4://servername
-
Monday, May 10, 2010 2:20 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 3:38 PMI 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:45 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 7:24 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:44 PM
Thanks for the idea, but I did already do that. Still no luck. :(
-
Monday, May 10, 2010 7:48 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
-
Tuesday, May 11, 2010 12:11 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 BruggemanModerator Wednesday, April 18, 2012 2:49 PM
-
Tuesday, May 11, 2010 12:36 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:43 PMMy 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 6:17 PMMike, this helped me solve an issue I was having, where http/https crawling worked fine, but not sps3. Thx for posting.
mc -
Saturday, May 15, 2010 12:13 AM
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 BruggemanModerator Wednesday, April 18, 2012 2:49 PM
-
Wednesday, June 02, 2010 12:13 PM
Here is a good blog entry that helped me.
-
Monday, June 21, 2010 11:43 AMWe 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.
-
Wednesday, August 04, 2010 2:25 AMThis solution worked for me
-
Thursday, October 21, 2010 9:43 PMThank 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 !!!
-
Friday, February 25, 2011 5:20 AM
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 -
Tuesday, March 01, 2011 3:42 PM
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 4:17 PMStan, 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 5:02 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 8:40 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, May 17, 2011 8:18 PMThanks J for posting this. It made me go back and double check this step. This was my issue excatly. Thanks!!
-
Friday, July 08, 2011 3:42 PMThanks jhaebets - this worked for me. I am building everything using Powershell scripts.
GregM -
Friday, February 17, 2012 3:15 PMHey,
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 -
Sunday, March 18, 2012 5:35 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 BruggemanModerator Wednesday, April 18, 2012 2:50 PM
.png){kind=spacer}
