SharePoint / Guide 3

Services and server roles (MinRole)

Which services run on which servers, how MinRole works, and how Microsoft changed the model.

Which services run on which servers decides how well a farm performs, how it survives a server failure, and how painful patching is. Microsoft has changed the model several times, and the current one, MinRole, does most of the work for you.

How the model changed

Version How services were placed
2007 Servers were described by what they ran: web front ends, an index server (only one per SSP), query servers, and Excel Calculation servers. Shared services lived in the Shared Services Provider.
2010 Service applications replaced the SSP. Admins started and stopped each service instance by hand on "Services on Server" in Central Administration.
2013 Same manual model, with two new heavyweights: the rebuilt search components and Distributed Cache. Dedicated search and cache servers became common in larger farms.
2016 MinRole: you choose a role for each server and SharePoint starts only the services that role needs, and fixes drift automatically.
2016 Feature Pack 1 Shared roles for smaller farms: Front-end with Distributed Cache, and Application with Search.
2019 and Subscription Edition Same MinRole model. In Subscription Edition, Distributed Cache no longer depends on the retired AppFabric product.

Microsoft brings these changes in through new versions and, since 2016, through feature packs and feature updates in the regular cumulative updates. That's why reading the release notes of each update matters, not just installing it.

The MinRole roles

Role PowerShell name Runs
Front-end WebFrontEnd Services that serve user requests with low latency. Handles page requests.
Application Application Background and batch services: timer jobs, workflow, Word Automation, Machine Translation and similar.
Distributed Cache DistributedCache Distributed Cache only.
Search Search Search components only.
Front-end with Distributed Cache WebFrontEndWithDistributedCache Both (shared role, 2016 FP1 and later).
Application with Search ApplicationWithSearch Both (shared role, 2016 FP1 and later).
Custom Custom Whatever you start by hand; MinRole leaves it alone.
Single-Server Farm SingleServerFarm Everything, for test and development only.

For the exact list of services each role runs on your version and update level, check Microsoft's "Services on MinRole-managed servers" reference, or run Get-SPServiceMatrix.ps1 to see what actually runs where.

Typical farm layouts

Small, highly available (4 servers): two Front-end with Distributed Cache servers behind a load balancer, and two Application with Search servers.

Medium (6 to 8 servers): two Front-end, two Application, two or three Distributed Cache, and two Search servers.

Large: add Front-end servers for user load and Search servers for index size and crawl volume, and consider dedicated crawl targets so crawling doesn't slow down user traffic.

Whatever the size, have at least two servers of every role that users depend on, so one server can be patched or fail without an outage. That's also what makes zero-downtime patching possible.

Changing a server's role

From 2016 Feature Pack 1 onward you can change a server's role without removing it from the farm:

Set-SPServer -Identity SP-APP01 -Role ApplicationWithSearch
Get-SPServer | Select-Object Name, Role, CompliantWithMinRole

When a server drifts (someone starts a service by hand), the Health Analyzer reports that the server isn't compliant with its role, and a timer job can fix it for you.

Distributed Cache: handle with care

Distributed Cache holds the logon token cache, newsfeed data and other shared state in memory. A few rules save a lot of pain:

  • Don't run it on servers that are also busy with search or other memory-hungry work.
  • Never just stop the service. Remove a cache host gracefully so its data moves to the others:

powershell Stop-SPDistributedCacheServiceInstance -Graceful Remove-SPDistributedCacheServiceInstance

  • Size the cache memory consistently on every cache host, and patch cache hosts one at a time.

Classic farms (2010 and 2013)

Without MinRole, keep the same principles by hand:

  • Web servers: Microsoft SharePoint Foundation Web Application service, plus services that need low latency.
  • Application servers: service applications, timer-heavy services and anything that does batch work.
  • Search: on its own servers once the index or crawl load grows.
  • Distributed Cache (2013): on its own servers in medium and large farms.

Document what runs where (the service matrix script gives you a CSV for this), and check it after every change. Undocumented services started "just to test something" are a classic source of problems during upgrades.