Managing Service Instances on SharePoint 2013

So you’re ready to take the plunge and go multi-server in your SharePoint farm. Congratulations! There are still some configuration steps and some decisions to make on your new server.  You’ve got to add the server to the farm, and there might be (depending on if your new server will be a front end server) some configuration to make on the network load balancer or proxy server.

This article is going to help demystify service instances in SharePoint 2013, teach you what they are, why they’re important, and how to turn them on and off through both Central Administration and PowerShell. Whoa! That’s a lot for one article, but I promise to take it easy on you.

What Is a Service Instance?

Service instances are the connections between a SharePoint server IIS web site and the windows service. If the service instance isn’t running, the service on the server is not running. Even if you have created a service application, you may not have a running service instance, and just because you have a running service instance doesn’t mean you have a service application.

Service Applications and Service Application Endpoints Vs. Service Instances

The reason you can have a service instance running but not a service application is simple: It’s designed that way. The reason it’s designed that way makes some good sense. The service applications that you’ll run with SharePoint 2013 are modular. You can have one search service application, or you can have ten search service applications. Under the hood, that search service application is running as a service.

Breaking service instances apart from service applications allows a many-to-many relationship between the apps and the underlying Windows services.

Each Service Instance Can Run Multiple Service Applications

Since the service instances are separate from the service applications, you can have one service instance running ten service applications. That means each department could have their own managed metadata service application running for their SharePoint web application and it still works. There aren’t ten different Windows services installed on the server, there’s still just one.

The other side of the many-to-many relationship is that one service application is not completely dependent on a single service instance.

Each Service Instance Can Run on Multiple Service Instances

“Hold on!” you’re thinking. “I thought there was only one service instance!”

Ah-ha! You’ve been paying attention! It’s true that a server only gets one service instance per type, but if you have multiple SharePoint servers in your farm, then guess what? You’ll have multiple service instances, and that means multiple Windows services available to work on those SharePoint service applications. All you have to do (most of the time) is start the service instance.

Benefits of Running a Service Application Across Multiple Service Instances.

When you start the service instance, SharePoint also checks in with the configuration database and “reports for duty.”  This can make the service application run more smoothly as the load is now shared between all servers running the service application, but it also provides some resiliency.

If you’re running SharePoint in multi-server configuration and you lose the only server that is running a SharePoint service instance, then that service is dead in the water. Starting the service instance on multiple servers in your farm is an easy way to add some high-availability in case of a server failure.

Note: Since you’re probably in a virtual environment, you can add some high availability into your farm by not putting all of your VMs on the same host, blade chassis, or storage device. Just remember that you must have a latency of under 1ms between servers, so your servers will still need to be located in the same datacenter. Hopefully the image below clears things up a bit.

In this image, you can see that each server has one service instance, and that’s it. Of course, this is just for one SharePoint service. On your server you’ve got about 15 different service instances. You get a service instance for Search, one for Managed Metadata, one for Excel Services, Access Services, etc. One service instance and one service instance only on each server, and for each service. By default, each service instance is stopped. You’ll have to start them, and you have to specifically start each service instance that you want running on each server you want it to run on.

In the image, I show the service instance running on servers 2 and 4. Each service instance can host multiple service applications, just like Service Instance 2 running Service Application 1 and 3.

Some service applications can be run on individual service instances. The search service is one of those service applications, where each of the six components can be run on one or more service instances. Other service applications are spread across all servers that have that service instance running.

Central Administration

In Central Administration, you find the service instances listed under System Settings, called Services on Server. At the Services on Server, you can use the server drop-down to choose between all of the SharePoint servers in your farm. Once you’ve chosen your server to administer, you can start and stop the service instance as needed.

But I Have a Ton to Do – Can’t I Just Use PowerShell?

You CAN use PowerShell to manage service instances in your farm. You can use the Get-SPServiceInstance cmdlet to retrieve the service instances, then pipe them into either Start-SPServiceInstance or Stop-SPServiceInstance.

The service instances returned in the Get-SPServiceInstance have a GUID, but also a service type as a property of the object. You have to start or stop a ServiceInstance object by using the GUID (or passing the object through the pipeline), but you’re more likely to use the “servicetype” property to filter your serviceinstance objects.

Here is an example:

Get-SPServiceInstance | Where-Object {$_.ServiceType –like “*Search*”} | Start-Service

That’s It!

Well, hopefully you better understand the relationship between service instances and service applications. This is a very important topic that can really help to solidify your understanding about what is going on in your SharePoint farm.

Did this help you? If you have any follow up questions or comments, let us know in the comments below, and be sure to subscribe to get up to date information right in your inbox.