Thursday, March 31, 2016

SharePoint 2013: How to completely remove Search service application


Completely removing the Search service application involves more than just selecting it in Manage Service Applications and then clicking Delete, or executing the single PowerShell commandlet Remove-SPServiceApplication $spapp -RemoveData. That's because there are several Search components that are not removed when you remove the Search service application.  These additional components include:
  • SharePoint Service Application Pool: not removed; must be done manually.
  • Search Index: not removed; must be done manually.
Additionally, there is another search component that is sometimes not removed:
  • Search Service Application Proxy: usually automatically removed when you remove the application, but sometimes it isn't.  In that case, you need to do this manually
In order to completely remove the Search service application from your farm, all of these components must also be removed in addition to the Search Service Application.  This procedure shows you how.


  1. Get Location of Index
    1. This can only be done while you still have a Search Service Application, which is why you need to do it first.
    2. Launch an elevated SharePoint Management Shell.
    3. Execute the following commandlet:
    4. Note down the IDs of the Topology and of each of the IndexComponents.
    5. Now, execute the following commandlets:
      $ssai1=Get-SPEnterpriseSearchComponent -SearchTopology [TopologyID] -SearchApplication $ssa -Identity [ID of first index component]
    6. Note down the RootDirectory.  This is the index location.  Repeat for each index component in your farm.  Don't remove the index files yet, or it may cause your current search service application to fail before you even have a chance to remove it.  You'll remove the index files later as the last step in this procedure.
  2. Remove the Search Service Application
    1. In the same elevated management shell, execute the following commandlet:
      Get-SPServiceApplication | ?{$ -like "*Search*"}
    2. Copy the ID for the Search service application, and the use it in the next commandlet:
      $spapp = Get-SPServiceApplication -identity [ID]
      Remove-SPServiceApplication $spapp -RemoveData
  3. Remove Search Service Application Proxy
    1. In the same elevated management shell, execute the following commandlet to check whether the proxy was also removed:
      Get-SPServiceApplicationProxy | sort-object TypeName | ft TypeName,ID -auto
    2. If you don't find it, skip over to step 4.  Otherwise, copy the ID for the Search Service and then execute the following commandlet:
      Remove-SPServiceApplicationProxy  [ID]
  4. Remove Search Service Application Pool
    1. Execute the following commandlet:
      Get-SPServiceApplicationPool | ft Name, ID -auto
    2. Copy the Name for the Search service application pool, and the use it in the next commandlet:
      $SPAppPool = Get-SPServiceApplicationPool "[App Pool Name]"
      Remove-SPServiceApplicationPool $SPAppPool
  5. Remove Search Indexes
    1. Delete the contents of the index locations you identified in the first step.



  • I use the same search index location for all index components.  This approach makes the location consistent for all servers.
  • If you begin to see application event errors start appearing in your server event logs, like the ones below, it may be because the search service application proxy was not removed.
    NOTE: Before attempting any of the possible Search endpoint failure solutions discussed in the References and elsewhere, be sure to check whether the Search Service Application Proxy may still exist and be listed in Manage Service Applications.  
    Normally, it is removed when you delete it from Manage Service Applications or use the simple PowerShell script.  However, sometimes it isn't.  When it isn't, the entry for the Search Service Application Proxy in the Manage Service Applications listing will move to the bottom; and this is why I missed it the first time I experienced this problem.  I was looking for the Search Service Application entries as they would normally appear alphabetically in the listing.
    8313: aA failure was reported when trying to invoke a service application: EndpointFailure
    Process Name: OWSTIMER
    Process ID: 30072
    AppDomain Name: DefaultDomain
    AppDomain ID: 1
    Service Application Uri: urn:schemas-microsoft-com:sharepoint:service:71e10e14e6e74693a3e3267c0ba8f0d6#authority=urn:uuid:3d32ea035f9e4ea99d241d32f37affdf&authority=https://[SharePoint Server]/Topology/topology.svc
    Active Endpoints: 1
    Failed Endpoints:1
    Affected Endpoint: http://[SharePoint Server]:32843/71e10e14e6e74693a3e3267c0ba8f0d6/SearchService.svc

    8031: An exception occurred while updating addresses for connected app {b577403e-d0ad-480c-9c00-9f5dc6458aba_15cde9e8-f3e0-4ba7-b62e-546e83510937}. 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)

    6482: Application Server Administration job failed for service instance Microsoft.Office.Server.Search.Administration.SearchServiceInstance (0adc8117-bd71-4267-9856-d79ac00fa082). Reason: No active topology exists for : Search Service Technical Support Details: Microsoft.Office.Server.Search.Administration.Topology.InvalidTopologyException: No active topology exists for : Search Service at Microsoft.Office.Server.Search.Administration.SearchServiceInstance.Synchronize() at Microsoft.Office.Server.Administration.ApplicationServerJob.ProvisionLocalSharedServiceInstances(Boolean isAdministrationServiceJob)

Tuesday, March 22, 2016

SharePoint 2013: How to implement task form hyperlinks in Approval workflow email notification


The SharePoint 2010 Approval workflow is one of the standard workflows that comes with SharePoint 2010 and 2013.  The task notification that it sends to approvers presents buttons that provide approvers with one-click access to the task's Edit and View forms.  These buttons are not visible if the approver accesses his or her email via web browser.  Instead, this one-click access must be provided by hyperlinks.  This procedure shows you how.


  1. Launch SharePoint Designer 2013.
  2. Navigate to the site containing the target document library.
  3. In the Navigation pane, at left, select the Workflows item.
  4. Under Globally Reusable Workflow, click on Approval - SharePoint 2010.  
    A popup will appear enabling you to create a copy.
  5. Click Yes. A dialog will appear.
  6. Enter a name for the workflow, and description, and then click OK.  The results pane updates to display another tab.  On this tab, you will see a single stage.
  7. Click on Approval Workflow Task (en-US) Copy 1.  The tab updates to display the workflow customization page of the copied workflow.
  8. In the Customization section, click Change the behavior of a single task.  The tab updates to display the copied workflow that you can now edit.  
    There are four email notification actions in this workflow.  You only need to modify the ones in the When a Task is Pending stage.
  9. Click on Current Task:Assigned To. A dialog appears displaying the email format.
    It's the last line that will be modified here.
  10. Replace task item 3 with
    Open this Task to accept or reject the approval, or View the status of this task for more actions (if you cannot update this task, you may not have access to it).
  11. Select Task, and then click the hyperlink symbol at upper right . This opens the Edit Hyperlink dialog.
  12. For the Address, click the Function button . This opens the Lookup for String dialog.
  13. From the Data source dropdown, select Current Task: Approval Workflow Task (en-US).
  14. Then from the Field from source dropdown, select Form_URN.
  15. Click OK, and then click OK again. The Task word in the email is now a hyperlink to the task's edit form.
  16. Next, select the View word in the email, and then click the hyperlink symbol.  The Edit Hyperlink dialog appears.
  17. For the Address, click the Function button.
  18. From the Data source dropdown, select Workflow Context
  19. From the Field from source dropdown, select Workflow Status URL.
  20. Click OK, and then click OK again.  The email content will now look like this
  21. Click OK.  The Define Email Message dialog closes.
  22. Now, repeat these steps for the Workflow Context: Initiator email notification, and you are done.
  23. Save and Publish.  You are done.  Now you can add this workflow as you would any of the other 2010 globally re-usable workflows.  
  24. One important note: the workflow you created (from a OOTB workflow) is only available within the scope of the web or site you created it in.  This means that if you connected SharePoint Designer to a particular web within a site collection, the workflow will only be available within that web.  If you want it to be available to all webs within a site collection, you must create it in the root web of the site collection..


Monday, March 21, 2016

SharePoint 2013: Get-SPProduct: Cannot insert duplicate key row


You are patching a SharePoint Server 2013 farm.  After installing the updates, you then execute Get-SPProduct -local on all machines. On one machine, executing this commandlet returns the error,
Get-SPProduct : Cannot insert duplicate key row in object 'dbo.ServerVersionInformation' with unique index 'IX_ServerVersionInformation_ServerID_product_PatchableUnit_PatchName'. The duplicate key value is...


  • Re-execute the commandlet


  • I have experienced this error a couple of times, both when executing Get-SPProduct concurrently on multiple SharePoint servers (a multi-server farm) and on just a single SharePoint server.  Each time, I was able to re-execute the commandlet without issue.