Error in PortalCrawl Web Service when crawling people with SharePoint 2010

I was playing with User Profiles and Search with SharePoint 2010 and I was getting some odd results.  First of all, I would get results from the user’s ‘my sites’, but not actual ‘people’.  By looking at the scopes, I could see that no results were available for the People scope.

So I checked up my crawl log and sure enough, I had a single error: Error in PortalCrawl Web Service.  Now that doesn’t really tell me anything so I checked out the logs and found the following 2 related messages:

10/27/2009 14:18:52.15     w3wp.exe (0x1540)                           0x18C8    Office Search Server              Common                            7ps2    Medium      PortalCrawl.GetSite(): System.UnauthorizedAccessException: Attempted to perform an unauthorized operation.     at Microsoft.Office.Server.Administration.UserProfileApplicationProxy.DemandAdministrationAccess(UserProfileApplicationAdminRights rights)     at Microsoft.SharePoint.Portal.Search.PortalCrawl.PortalCrawl.GetSite(_PortalSite& sSite).    88e720df-4686-4aa5-bf8a-197ae1900bfb

10/27/2009 14:18:52.16     mssearch.exe (0x0738)                       0x1FF0    Office Search Server              Gatherer                          cd11    Warning     The start address sps3://my cannot be crawled.  Context: Application 'Search_Service_Application', Catalog 'Portal_Content'  Details:  Error in PortalCrawl Web Service.   (0x80042617)    

 

Now I could tell I had an access error so I validated my DisableLoopbackCheck registry key – it was already set;  checked the web application user policies (which is now in the Central  Admin > Security > Specify web application user policy), the search account already had its permissions; I even checked the https://my web site and the account also had permissions there.

When looking back at the error message – and more precisely the stack trace – I could see the class for UserProfileApplicationProxy – I hadn’t checked my proxy permission.

If you look at those permissions, there’s an explicit ‘Retrieve People Data for Search Crawlers’ checkbox.

 

Now, if you run the wizard to create your service applications, it will use the default account (which probably has too much rights) and give the right permissions.  When you go and change the ‘default content access account’, it will not give that permission – only the web application user policy ‘Full read’ permission.

 

Not sure if this behaviour will change for RTM or not so make sure you check the permissions for the content access account in the proxy ‘administrators’.

 

Maxime

Comments

• Anonymous
  December 26, 2009
  Hi MaximeB - Did you also get "Unrecognized attribute 'allowInsecureTransport'" error in ULS log? If yes, then install WCF fix. You can download it from http://support.microsoft.com/default.aspx/kb/971831 I hope it helps...

• Anonymous
  December 26, 2009
  Hi, Yeah I had back then and I had the fix -- but it wasn't public so I couldn't post about it yet. The WCF is indeed a requirement for most shared applications work correctly.

• Anonymous
  January 06, 2010
  Hi, I have the same problem as descibed. Above. Permissions on the search service application have been set correctly. Still getting this error: The start address sps3://srv00098:80 cannot be crawled.  Context: Application 'Search_Service_Application', Catalog 'Portal_Content'  Details:  Error in PortalCrawl Web Service.   (0x80042617) what i am doing wrong here ?

• Anonymous
  January 12, 2010
  Nice catch Maxime.. I also ran into this today.

• Anonymous
  January 12, 2010
  mschaaks: do you also have the unauthorized access just before?  The 2nd error is simply saying that it cannot crawl for any reason.

• Anonymous
  January 28, 2010
  Excellent, worked for me!

• Anonymous
  May 25, 2010
  Don't forget to point out that those Indexer/crawler account permissions are set via the Administrators button when the User Profile Service Applcation (or what ever you have called it) is selected. Note: I may have hit this in RTM, though I'm getting the error for sps3://<main content root site> as I'm not (yet) using sps3://<MySite>. Still diagnosing. HTTP crawls seem fine.

• Anonymous
  May 25, 2010
  Duh!  sps3:// is apparently just for crawling MySite! Can't believe I've never hit that before... So now I have the cannot be crawled error on my MySite location... <sigh.

• Anonymous
  March 29, 2011
  I have checked the permission "Retrieve People Data for Search Crawlers’ checkbox " . But still getting the same error. What could be wrong in this?

• Anonymous
  June 16, 2011
  Like Pradeep, I also checked the permission "Retrieve People Data for Search Crawlers’ checkbox " . But still getting the same error. What could be wrong in this? khushi.sshaikh@hotmail.com

• Anonymous
  June 16, 2011
  That was all i had to do in that setup.  did you test by logging with your crawl account to see if it could navigate to that web application?   If it doesn't, make sure you have a user policy on that web application.  If it works, then it's likely to be an issue with the proxy configuration.

• Anonymous
  January 17, 2014
  Just thought I'd throw my two cents in here - I started experiencing this problem after deleting the User Profile Service Application and re-creating it (using the same databases other than Sync db). I tried full reindex, checked the crawl account permissions but no luck.  what finally resolved the issue for me was to delete the old Content Source (I had a content source containing only the SPS3://MySiteHost url) and re-creating it -when I did another full crawl the errors were no longer there.