Category Archives: Service Application

Service-Applications-in-SharePoint-1920x1080

Service Applications in SharePoint

Advertisements
Advertisements

Service Applications in SharePoint

Service Applications in SharePoint are associated with web applications, and specific services are typically deployed as needed in a particular farm. Only deployed services are referred to as service applications. This is a huge advantage in terms of conserving resources and optimizing performance. For instance, a specific web application can be configured to use only the services it needs. The number of service applications that exist is vast, and, as third-party vendors can create their own services for SharePoint Server. A list of services includes the following:

You can set up a single service application to be shared among multiple web applications or deploy multiple instances of the same service across a farm and, in some cases, across multiple farms. Also, there is no limitation regarding the number of services that can be deployed in any single farm. A typical planning scenario requires that you either set up services to share across multiple web applications or isolate an individual service to one or a limited number of web applications. We can publish below service applications across the farm.

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

Navigate to “Central Admin -> Application Management ->Manage Service Applications” and click on “New” from ribbon to see the list of service applications available.

Service-Applications-in-SharePoint-1300x674
Advertisements
Advertisements

you can use powershell command to get the list of  service applications

Get-SPServiceApplication | Format-Table -wrap
Service Applications in SharePoint
Get-SPServiceApplication
Get-SPServiceApplication -Identity 48fbecaa-71e4-4f1d-bdfe-bdcbc17fa061 | Format-Table -wrap
Get-SPServiceApplication-1324x186

sharepoint services 2016

For every service application there is a service associated with it which you can from central admin by navigating to “Central Admin -> Application Management -> Manage Services on Server”.

manage-services-on-server-1273x441
services-on-server-1324x870
Advertisements
Advertisements

Alternatively you can use the powershell command as below

Get-SPServiceInstance | Format-Table -wrap
Get-SPServiceInstance-873x1099
Get-SPServiceInstance | Where {$_.Status -eq "Online"} | Format-Table -wrap
Get-SPServiceInstance-formt-1154x933

Similarly we can start the service instance by running the below command.

Start-SPServiceInstance e63962e4-e1ea-4b83-a9cc-df51683e85f3
Advertisements
Start Service Application Proxy 1920x1080

Start Service Application Proxy using powershell

Advertisements
Advertisements

Start 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 Start Service Application Proxy :

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

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

SharePoint search crawl properties storage locations

SharePoint search crawl properties storage locations

Advertisements

Advertisements

SharePoint search crawl properties storage locations

Here we will discuss about SharePoint search crawl properties storage locations. When gathering files from a content source, the SharePoint 2013 Crawl Component can be very I/O intensive process – locally writing all of the files it gathers from content repositories to its to temporary file paths and having them read by the Content Processing Component during document parsing. This post can help you understand where the Crawl Components write temporary files, which can help in planning and performance troubleshooting (e.g. Why does disk performance of my C:\ drive get so bad – or worse, fill up – when I start a large crawl?)

By default, all Search data files will be written within the Installation Path

  • The Data Directory (by default, a sub-directory of the Installation Path) specifies the path for all Search data files including those used by I/O intensive components (Crawl, Analytics, and Index Components)
    • The Data Directory can only be configured at the time of Installation (e.g. it can only be changed if uninstalling/re-installing SharePoint on the given server)
      • From the Installation Wizard, choose the “File Location” tab as seen below
      • IMPORTANT: Before uninstalling SharePoint, first modify your Search topology by removing any Search components from the applicable server. Once SharePoint is re-installed, you can once again deploy the components back to this server.
    • The defined path can be viewed in the registry:

    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office Server\15.0\Search\Setup\DataDirectory

    • Advanced Note: The Index files (by default, written to the Data Directory) path can be configured separately when provisioning an Index Component via PowerShell using the “RootDirectory” parameter

3175.installAndDataPath
(As a side note: the graphic is only intended to display the default locations specified at install time. It is recommended to change these to a file path other than C:\ drive)

For the Crawl Component:

  • When crawling [gathering] an item, the filter daemon (mssdmn.exe – a child process of the Crawl Component that actually interfaces with an end content repository using a Search Connector/Protocol Handler) will download any applicable file blobs to the SSA’s “TempPath” (e.g. an HTML file, a Word document, a PowerPoint presentation, etc)
    • In the graphic below, this is step 2a
    • The defined path can be viewed either:
      • In the registry (of a Crawl server)

        HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office Server\15.0\Search\Global\Gathering Manager\TempPath

      • Or as a property of the SSA:

        $SSA = Get-SPEnterpriseSearchServiceApplication

        $SSA.TempPath

  • When the filter daemon completes the gathering of an item, it is returned to the Gathering Manager (mssearch.exe – responsible for orchestrating a crawl of a given item) and the applicable blob is moved to the “GathererDataPath“, which is a path relative to the DataDirectory mentioned above.
    • In the graphic below, this occurs in step 2b
    • The defined path can be viewed in the registry (of a Crawl server):

      HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office Server\15.0\Search\Components\-GUID-of-theSSA-crawl-0\GathererDataPath

  • The GathererDataPath is mapped as a network share (used by the Content Processing Components)
    • The shared path can be viewed in the registry (of a Crawl server):

      HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office Server\15.0\Search\Components\-GUID-of-theSSA-crawl-0\GathererDataShare

8233.crawlFlow
Usage by the Content Processing Components:

  • When the item is fed from the Crawler to the Content Processing Component (step 3 above), the item is only logically submitted to the CPC in a serialized payload of properties that represent that particular item – any related blob would remain on the Crawler and retrieved by a later stage in the processing flow
    • For SharePoint list items, there would typically not be a blob (unless the list item had an attachment)
    • For a document in a SharePoint library, the blob would represent the item’s associated file (such as a Word document)
  • During the Document Parsing stage in the processing flow (e.g. during step 4 above), the item’s blob will be retrieved from the Crawl Component via the GathererDataShare
  • When the Crawl Component receives a callback (success or failure) from the CPC (e.g. in step 6b above after an item has been processed), the temporary blob is then deleted from the GathererDataPath

1373.gathererDataShare
An example path to an item with DocID 933112 would look like the following:

file://crawlSrv/gthrsvc_7ecdbb10-3c86-4298-ab09-04f61aaeb636-crawl-0//f8/0xe3cf8_1.aspx   

#0xe3cf8 hex = 933112 decimal

Where:

  • crawlerSrv is a server running a crawl component
  • gthrsvc_-GUID-of-theSearchAdminWebServiceApp--crawl-0 is the name of the crawl component
    • This GUID can be identified using the following PowerShell:

      $SSA = Get-SPEnterpriseSearchServiceApplication

      $searchAdminWeb = Get-SPServiceApplication –Name $SSA.id

      $searchAdminWeb.id

      7ecdbb10-3c86-4298-ab09-04f61aaeb636

  • And the file name is actually re-named to the hex value of the docID
    • For example: 0xe3cf8 hex = 933112 decimal
    • Which we can see in ULS, such as:
      • From the Crawl Component (in this case, running on server “faceman”):

        mssearch.exe     SharePoint Server Search Crawler:Content Plugin      af7zf VerboseEx

        CTSDocument: FeedingDocument: properties : strDocID = ssic://933112 key = path values =\\FACEMAN\gthrsvc_7ecdbb10-3c86-4298-ab09-04f61aaeb636-crawl-0\\f8\0xe3cf8.aspx 

      • From the Content Processing Component:

        NodeRunnerContent2-834ebb1f-009    Search    Document Parsing      ai3ef VerboseEx

        AttachDocParser – Parsing: ‘file://faceman/gthrsvc_7ecdbb10-3c86-4298-ab09-04f61aaeb636-crawl-0//f8/0xe3cf8.aspx’

Advertisements

Advertisements

parse error processing item failed sharepoint

parse error processing this item failed because of an unknown error when trying to parse its contents

There is parse error found in the Crawl log of a SharePoint 2013 environment. Processing this item failed because of an unknown error when trying to parsing its contents. (Error parsing document,Sandbox worker pool is closed,SearchID)

  1. In order to fix this you can try to perform the following action plan:
  2. Open "Local Policies
  3. Click on “User rights assignment
    adjust memory quotes-1276x416

    adjust memory quotes

  4. Make sure that the search service account has the following rights:"Replace a process level token”.
    replace process level token-1060x766

    replace process level token

  5. "Adjust memory quotas for a process"
    adjust memory quota-1054x762

    adjust memory quota

  6. "Impersonate a client after authentication"
    impersonate client-1052x758

    impersonate client

  7. Please make sure that the policies don't get changed afterwards.
  8. Run a clear configuration cache
  9. Start a full crawl and the errors should be gone.
Unable to render the data

Unable to render the data error bdc

Advertisements

Advertisements

Unable to render the data error bdc sharepoint 2016

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 as "Unable to render the data. If the problem persists, contact your web server administrator."

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.

Solution:

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

  1. Go to SharePoint Central Administration site
  2. Navigate to Application management >> Click on Configure service application associations under Service Applications.
  3. 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.

service-application-association-sharepoint-2016

Advertisements

Advertisements

Query-0-Server-Not-Responding-Event-ID-2587-1920x1080

Query 0 Server Not Responding – Event ID 2587

Advertisements
Advertisements

Query 0 Server Not Responding – Event ID 2587

There is an error “Query 0 Server Not Responding – Event ID 2587” in my sharepoint server.

SERVER1:
Windows 2008 R2 (x64)
SharePoint 2010

SERVER2:
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
Advertisements
Advertisements

Resolution:

  • Please try to disconnect the query server from the search topology
  • stop the Search service in central admin, clear the index files in the query server.
  • start 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" }
$component.Recover()