Freigeben über


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.

SearchAccountPermission

 

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.