Error In Portalcrawl Web Service. Sharepoint
Montreal and working primarily in eastern Canada. Error in PortalCrawl Web Service when crawling people with SharePoint 2010 ★★★★★★★★★★★★★★★ Maxime Bombardier [MCM]October 27, 200912 0 0 0 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 http://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 ac
application. All went fine until we ran the first search crawl, SharePoint Search reported the following error: Error in PortalCrawl Web Service. We have the following URLs configured under the content source: http://mysite sps3://sharepoint The errors being generated were related to crawling user profiles under http://mysite. Solution Some things to check: Ensure that the default content access account configured under search administration has access to the User Profile Service Application. Go to Manage Service Applications -> User Profile Service Application -> Administrators. Ensure that your content access https://blogs.msdn.microsoft.com/maximeb/2009/10/27/error-in-portalcrawl-web-service-when-crawling-people-with-sharepoint-2010/ account has "Retrieve People Data for Search Crawlers" permissions. If you have re-created your user profile service application, ensure that it is re-associated with the relevant web applications. In my case, I had to re-add the service connection not only to Mysite but the main SharePoint site. The reason for this is because my enterprise search portal resided on my main SharePoint site. http://www.mysharepointadventures.com/2012/07/error-in-portalcrawl-web-service/ Share this:EmailPrintLike this:Like Loading... Related Tags: Search, User Profile Service No comments yet. Leave a Reply Click here to cancel reply. Name (required) Mail (will not be published) (required) Website Notify me of follow-up comments by email. Notify me of new posts by email. Popular Latest Comments Tags Unable to browse large document library in explorer view August 3, 2011 The local farm is not accessible. Cmdlets with FeatureDependencyId are not registered. December 17, 2012 SharePoint Keeps Prompting for Credentials February 8, 2012 SharePoint 2010 Search Results Customisation August 24, 2011 Opening Images and Pages in a Dialog / Lightbox November 24, 2011 Get list of Site Collection Admins (SCA) using PowerShell November 4, 2015 Automatically download versions of a file in SharePoint to your computer June 16, 2014 SharePoint 2010 Service Pack 2 no longer allows unresolvable e-mail addresses April 11, 2014 SharePoint 2010 Service Pack 2 breaking scripts using SPServices / jquery April 11, 2014 Hiding calculated columns in a SharePoint Library / List March 21, 2014 Rick Kushner: I took aInvoke-WebRequest out of the script, and I... JPozo: Works!!! Thanks!!!...
Error in PortalCrawl Web Service Recently one of our clients realized that they have no people search anymore and once we went to the People scope, it had 0 items http://spforsquirrels.blogspot.com/2007/12/sharepoint-search-does-not-crawl-people.html in it.After going through the index server event log I found this "warning":Event ID 2436The start address cannot be crawled. Context: Application 'SharedServices1', Catalog 'Portal_Content' Details: Error in PortalCrawl Web Service. (0x80042617)After rebuilding search (which did not help) and analyzing the SharePoint error log, I stumbled across the following:"MS Search Administration 8ije Verbose Search application '6a6d1b28-3a6a-416c-884c-1d8d967f9966': Skipping people start address configuration b/c start address 'sps3://[server_name]:1212' was automatically added to error in the default content source once."There was a port number :1212/ (which seems absolutely correct, considering that my Sites are on this port number). The solution to the problem was to remove the port number and keet the slash, I have seen this Protocol handler get confused with it the past. Once that was removed and the crawl was initiated, it was grabbing the people profiles.Seems like a simple resolution, error in portalcrawl but it cost me my weekend J. Posted by Natalya Voskresenskaya [SharePoint MVP] at 5:05 PM 7 comments: 马头 said... Well, thanks. Although this solution does not apply to my case, it at least make me relaxed a little bit since I know that there are other people stuck at the same problem like me.Another post worthy reading is here http://www.sharepointblogs.com/camper/archive/2007/07/13/moss-2007-people-search-issues.aspx Hope it will help.P.S. my personal idea is that sharepoint gather do not like "Mysite" to have relative path, such as "http://servername:port#/mysite/". This may be the reason that the gather can not crawl.My idea is to remove the relative path of "mysite", set it to "http://servername:port#". You can make the setting in SSP -> Mysite Setting. April 25, 2008 at 12:48 AM Ani said... HiI am also facing same problem. I am not able to search people as well as office documents. Can you me where I need to set protocal handler and what I need to set there?Thanks in advanceAshish April 26, 2008 at 9:02 AM Robert said... In my case the url changed http://... to https://...The sps3://... also needed to change to sps3s://...Basically one of the first things to check is wether the url is correct.After reading a couple of other blogs abo