Crawl error Processing this item failed because of an unknown error when trying to parse its contents sharepoint

During various search troubleshooting i came across the following crawling error in the Crawl log of a SharePoint 2013 environment.

Processing this item failed because of an unknown error when trying to parse its contents. (Error parsing document ‘http://********.*****.com/Project/abcd/Q_M/ABX/SitePages/Homepage.aspx’. Sandbox worker pool is
closed.; ; SearchID = *******************)

In order to fix this you can try to perform the following action plan:
Open “Local Policies
Click on “User rights assignment


Make sure that the search service account has the following rights:
Replace a process level token


Adjust memory quotas for a process


Impersonate a client after authentication


Please make sure that the policies don’t get changed afterwards.

After implementing the above changes please run a clear configuration cache
After clearing the cache, start a full crawl and the errors should be gone.


Start SharePoint Service Application Proxy using Powershell

If your Usage and Health Data Collection Proxy is in a stopped state here is a quick bit of PowerShell to to get it started:

$sap = Get-SPServiceApplicationProxy | where-object {$_.TypeName -eq “Usage and Health Data Collection Proxy”}

The above can easily be adapted to allow you to start any Service Application Proxy

“Unable to render the data. If the problem persists, contact your web server administrator.” error in SharePoint 2016 BCS

Created an external list SharePoint 2016 using business data connectivity services, configured secure store target application and created external list in SharePoint.
The external list displayed this error message with a correlation ID.

“Unable to render the data. If the problem persists, contact your web server administrator.”


ULS Log viewer found this message in the logs:

Error while executing web part: Microsoft.BusinessData.Infrastructure.BdcException: The shim execution failed unexpectedly – Unable to obtain the application proxy for the context.. —> Microsoft.Office.SecureStoreService.Server.SecureStoreServiceException: Unable to obtain the application proxy for the context.


The web application is not associated with the secure store service application.

  • Go to SharePoint Central Administration site
  • Application management >> Click on Configure service application associations under Service Applications.
  • select the web application in which your site exist, Check the “Application proxy group” column >> Make sure the BDC and secure store service applications check boxes checked.


Query 0 Server Not Responding – Event ID 2587

Error :

Windows 2008 R2 (x64)
SharePoint 2010

Windows 2008 R2 (x64)
SQL 2008

Services running on SERVER1: (none as localsystem, localservice, networkservice)

SharePoint 2010 Administration (started/auto)

SharePoint 2010 Timer (started/auto)

SharePoint 2010 Tracing (started/auto)

SharePoint 2010 User Code Host (stopped/disabled)

SharePoint 2010 VSS Writer (stopped/manual)

SharePoint Foundation Search V4 (started/manual)

SharePoint Server Search 14 (started/manual)


Search/indexing is not working, and in return, backups are failing claiming:

Failure Message Object Query-0 (D: on SERVER1) failed in event On Backup

Search Service Application reports:

Index Partition – 0 – SERVER2Search_Service_Application_PropertyStoreDB_9a482efd99954748a062952a3d2617d7

Query Component 0 SERVER1 Not Responding

System Event Log on SERVER1 reports:

Event ID 2587

The following conditions are currently affecting index propagation to this server for search service application ‘Search Service Application’:

1. Query 0, catalog Main: failing to copy index files from crawl component 0 for 1490 minutes. Access is denied. 0x80070005

2. Query 0 is not being automatically disabled because the minimum number of ready query components per partition is 2.

Solution :

  1. Please try to disconnect the query server from the search topology,
  2. stop the Search service in central admin, clear the index files in the query server.
  3. After that, starts the search service instance using Start-SPServiceInstance PowerShell.

Run the following PowerShell to reset the Query server:

$ssa = Get-SPEnterpriseSearchServiceApplication -Identity “SSAName”
$queryComponents = $ssa | Get-SPEnterpriseSearchQueryTopology -Active | Get-SPEnterpriseSearchQueryComponent
$component = $queryComponents | where {$_.ServerName -eq “QueryServerName” }

Internal server error exception when users perform a search in SharePoint


When users perform a search in a Microsoft SharePoint environment, they receive the following error message:

Internal server error exception:

Troubleshoot issues with Microsoft SharePoint Foundation

Additionally, the following critical exception may be written to the ULS log of the SharePoint Web front-end server:

Process: OWSTIMER.EXE (0x1CE0)

Product: SharePoint Foundation

Category: Topology

EvendID: 8031

An exception occurred while updating addresses for connected app {eaf6c00c-cc3f-460e-8bf2-ad9b991ea6ea_aa16845d-045a-46bc-bbc6-d701ff13950d}. The uri endpoint information may be stale. System.InvalidOperationException: The requested application could not be found at Microsoft.SharePoint.SPTopologyWebServiceApplicationProxy.ProcessCommonExceptions(Uri endpointAddress, String operationName, Exception ex, SPServiceLoadBalancerContext context) at Microsoft.SharePoint.SPTopologyWebServiceApplicationProxy.ExecuteOnChannel(String operationName, CodeBlock codeBlock) at Microsoft.SharePoint.SPTopologyWebServiceApplicationProxy.GetEndPoints(Guid serviceId) at Microsoft.SharePoint.SPConnectedServiceApplicationAddressesRefreshJob.Execute(Guid targetInstanceId) bf94139a-66f8-4aab-af31-406a5ebb6db9


This issue occurs when the Search service application proxy is associated with a web application but is not associated with any Search service applications in the farm.


To allow users to search without receiving this error message, reassociate the web application with a valid Search service application proxy. A valid Search service application proxy will be associated with a Search service application in the Manage service applications option. To do this, follow these steps:

  1. Open Central Administration.
  2. Click Manage web applications.
  3. Select the affected web application.
  4. On the ribbon, click Service Connections.
  5. Under Configure Service Application Associations, select the valid Search service application proxy check box.


Failed to get the server time zone id. Exception: Microsoft.SharePoint.SPEndpointAddressNotFoundException: There are no addresses available for this application

Error : Failed to get the server time zone id.Exception: Microsoft.SharePoint.SPEndpointAddressNotFoundException: There are no addresses available for this application. 

When I check the View Web Analytics Reports from Central Admin on Production, it throws the above error though it works on Test environment.

To resolve this, I have performed the following steps by looking at the ULS Logs.

Navigate to Central Administration 

System Settings and click on Manage Services on Server

Stopped the following two services though it was already started

  • Web Analytics Data Processing Service
  • Web Analytics Web Service

Started the above two services but when I check View Web Analytics Report, doesn’t seem to work.

On Further checks found the Manage Metadata Service App wasn’t able to retrieve the metadata

Stopped and Started the Managed Metadata Web Service

This resolved the issue for me now able to view the Web Analytics Reports from Central Admin

If it doesn’t work, check the ULS logs to identify and troubleshoot  the issue.

Unable to open any Excel Services spreadsheet “We’re sorry. We ran into a problem completing your request. Please try again in a few minutes.”


IIS reset

Share service applications across farms in SharePoint 2013

In SharePoint 2013, some service applications can be shared across server farms.

By publishing a service application, you can optimize resources, avoid redundancy, and provide enterprise-wide services without installing a dedicated enterprise services farm. You can publish the following service applications in a SharePoint 2013 farm:

  • Business Data Connectivity
  • Machine Translation
  • Managed Metadata
  • User Profile
  • Search
  • Secure Store

Additionally, a SharePoint 2010 farm can consume services from a SharePoint 2013 Server farm. This allows for upgrade of multi-farm environments in which a farm hosting service applications is upgraded first. In this scenario, the service applications and features that the SharePoint 2010 farm experiences are limited to those that are available in SharePoint 2010. For example, a SharePoint 2010 farm cannot consume the Machine Translation service application from a SharePoint Server 2013 farm and does not benefit from the new features of the User Profile service application.

There are significant restrictions on when services and content can be shared between a SharePoint 2010 farm and a SharePoint 2013 farm. Content type syndication uses the backup and restore mechanism in SharePoint Server to publish the content types across site collections. And backup and restore does not work across versions in the following scenarios:

  • Between a SharePoint 2010 farm and a SharePoint 2013 farm
  • Between sites in 2010 mode on a 2013 farm and those in 2013 mode on a 2013 farm

To learn how to work with these restrictions and successfully share services and content between SharePoint 2010 and SharePoint 2013 farms go here: How to upgrade an environment that uses content type syndication (SharePoint Server 2013)

If the server farms are located in different domains, the User Profile service application requires both domains to trust one another. For the Business Data Connectivity service and Secure Store service application administration features to work from the consuming farm, the domain of the publishing farm must trust the domain of the consuming farm. Other cross-farm service applications work without a trust requirement between domains.

The User Profile service must reside in the same datacenter as the content it supports — The performance of social features require the User Profile service application to be located in the same datacenter as My Sites, team sites, and community sites.

The farm that contains the service application and publishes the service application so that other farms can consume the service application is known as the publishing farm. The farm that connects to a remote location to use a service application that the remote location is hosting is known as the consuming farm.

If you are familiar with SharePoint 2010, you might find it useful to think of the publishing farm as the parent farm and the consuming farm as a child farm.

This article describes the steps that are required to publish and consume service applications across farms. These steps must be performed in the order listed.

  1. Exchange trust certificates between the farms.To start, an administrator of the consuming farm must provide two trust certificates to the administrator of the publishing farm: a root certificate and a security token service (STS) certificate. Additionally, an administrator of the publishing farm must provide a root certificate to the administrator of the consuming farm. By exchanging certificates, each farm acknowledges that the other farm can be trusted.For more information, see Exchange trust certificates between farms in SharePoint 2013.
  2. On the publishing farm, publish the service application.On the farm on which the service application is located, an administrator must explicitly publish the service application. Service applications that are not explicitly published are available to the local farm only.For more information, see Publish service applications in SharePoint 2013.
  3. On the consuming farm, set the permission to the appropriate service applicationsYou must give the consuming farm permission to the Application Discovery and Load Balancing Service Application on the publishing farm. After doing this, give the consuming farm permission to the published service applications that it will be consuming.For more information, see Set permissions to published service applications in SharePoint 2013.
  4. On the consuming farm, connect to the remote service application.After the publishing farm has published the service application, an administrator of the consuming farm can connect to that service application from the consuming farm if the address of the specific service application is known.For more information, see Connect to service applications on remote farms in SharePoint 2013.
    You cannot share a User Profile service application across farms that reside in separate domains unless you first establish a domain-level trust between the two domains.
  5. Add the shared service application to a Web application proxy group on the consuming farm.An administrator must associate the new service application connection with a local Web application on the consuming farm. Only Web applications that are configured to use this association can use the remote service application.For information about how to configure a Web application proxy group connection, see Add or remove service application connections from a web application in SharePoint 2013.
    It is important that you plan the proxy group layout before you add service applications to proxy groups.
  6. Configure server-to-server authentication between the publishing and consuming farms.To allow a web application or an application service to request a resource from a web application on another farm on behalf of a user, you have to configure server-to-server authentication between the farms. For more information, see Configure server-to-server authentication between publishing and consuming farms.
    Web applications or application services that request resources from an application service on another farm do not require server-to-server authentication

Considerations while provisioning the service application using pre-created databases”there is already a database exists with the same name”

* Recently I had worked with my customer to setup a new SharePoint farm with pre-created (DBA created) databases.

Concept and prerequisites are very well documented inthis TechNet article. While testing the deployment what really matters were the creation of couple of service application. 

* Bad guys were Usage Logging & State Service Application. All other service applications were easy to provision (we were using auto AutoSPInstaller  to automate the deployment using Power Shell).

* Except Usage Logging & State Service application all other service applications were able to use the pre-created database while provisioning the new service application using New-SP* commandlets. 

* Usage Logging & State Service applications were complaining that the there is already a database exists with the same name

* To work-around this, we have to approach the provision in a different way. I’m giving the provisioning script samples for both Usage Logging & State Service Applications.

Usage Logging Service Application :

Steps are explaining below.

1. Create new Usage Service Application with a temporary ( or default) database

2. After that, modify the Usage Service Application to use the pre-created database name, this will dismount the usage logging database created in step #1

3. Delete the database created in step #1 manually from the SQL server

Automating the Steps 1-2 given below.

add-pssnapin microsoft.sharepoint.powershell

Write-Host -ForegroundColor White "Provisioning WSS Usage Application..."

$SPUsageApplicationName = "WSS Usage Service Application"
$precreatedUsageDB = "WSS_Usage_Database"
$sqlserver = "spsql"
$tempUsageDB = "WSS_Usage_ToDelete"

New-SPUsageApplication -Name $SPUsageApplicationName -DatabaseName $tempUsageDB

$UsageServiceApp = Get-SPUsageApplication $SPUsageApplicationName

Set-SPUsageApplication -Identity $UsageServiceApp.ID -DatabaseName $precreatedUsageDB -DatabaseServer $sqlserver

Write-Host -ForegroundColor White "Re-provisioning Health Data Collection Proxy as by default it will be in stopped state"

$SPUsageApplicationProxy = Get-SPServiceApplicationProxy | where {$_.DisplayName -eq $SPUsageApplicationName }

Write-Host -ForegroundColor Blue "Done provisioning SP Usage Application."

State Service Application :

This is little different than Usage Logging Service Application provisioning.

Steps are explaining below.

1. First we have to mount the pre-created database to SharePoint and have to initialize it.

2. Use the same method as other service application provisioning, using New-SPStateServiceApplication and provide the pre-created database name.

3. Create state service application proxy.

add-pssnapin microsoft.sharepoint.powershell

$StateServiceDB = "State_Service_DB"
$StateServiceName = "State Service Application"
$StateServiceProxyName = "State Service Application Proxy"

Write-Host -ForegroundColor White "Provisioning State Service Application..."

Mount-SPStateServiceDatabase -Name $StateServiceDB | Initialize-SPStateServiceDatabase

New-SPStateServiceApplication -Name $StateServiceName -Database $StateServiceDB | Out-Null

Write-Host -ForegroundColor White "Creating State Service Application Proxy..."

$StateServiceApplication = Get-SPStateServiceApplication -identity  $StateServiceName

$StateServiceApplication | New-SPStateServiceApplicationProxy -Name $StateServiceProxyName -DefaultProxyGroup

Write-Host -ForegroundColor Blue " - Done creating State Service Application."

Other service applications can be pointed in this scenario are

1. ASP.NET Session state service (Enable-SPSessionStateService). With that there is no way to specify a pre-created database , 

    ASP.NET session state database schema is provisioned by ASP.NET by calling SQLServices class. once you use Enable-SPSessionStateService.

From my deployment experience this was the main issue and there was no any other deployment issues faced while going with the DBA pre-created deployment method. Hope this hint will help someone.