I recently had some fun and games trying to fix a broken SharePoint Search Service Application. Although I’m not entirely what caused the issue (other than, you know, SharePoint) although it may be to do with changing the Farm Passphrase but one way or another it was, fooked.
I opted to just delete it and create a new one. This didn’t go well. A new application was created, but it, also, was dead.
As many people have found, Central Admin and Remove-SPServiceApplication have a habit of doing entirely nothing when it comes to remove broken Search Applications.
Fortunately, I found someone who had gone through the pain and found an overlooked stsadm command that did the trick – plus some handy other hints on how to get things squared away.
What I found was that when I deleted the broken search service, the new one almost sort of sprung in to life. Good news.
The only issue I encountered though was finding the correct WCF Endpoint to delete. Given that I’d created the new application but reused the existing pools, the IIS Pool had two WCF endpoints listed. And I couldn’t find a way of getting the ‘current’ WCF endpoint in use. Until, that is, I noticed it was staring me in the face in central admin:
Yep – it was right there in the URL – and this guid correlated with the WCF endpoint GUID listed in IIS under SharePoint Web Services. So I deleted the other one, and all was good again.
PS. In the link, there is a comment about old search databases hanging around. I also had this issue, despite having deleted them from SQL Server and the filesystem itself.