What You Need to Know about SharePoint 2016's MinRole

Now that SharePoint 2016 IT Preview is available to play with and test, the first thing you need to understand before you even think about installing is what the MinRole is. In a nutshell, MinRole allows you to define the purpose of the SharePoint server. By selecting a specific role, SharePoint automatically configures the services it needs and optimizes performance of the farm based on that topology. The following table outlines each role that is available:

Table originally posted https://msdn.microsoft.com/en-us/library/mt346121(v=office.16).aspx

How does this work, you ask?

SharePoint is built and run by using a core set of base services and instances of those services that are required by the specific role of that server. In the past, you would need to define what roles and services were enabled on which. In some cases, the process caused confusion--and often issues--when completed incorrectly.

The MinRole option allows users--right at the start of setup, whether for a new farm or the addition of a new server to an existing farm--to define its role and have SharePoint automatically enable or disable services. It also lets us provision services and optimize for that specific role. This means that we now have the ability to demote and promote server roles, and not have to worry about what services should be disabled or enabled, or provisioned or un-provisioned--it's all done automatically.

What are the real, tangible benefits to the use of MinRole?

I am a great advocate of template-type deployment of SharePoint Servers. We have the ability using PowerShell or other tools to ensure that when we deploy an environment, the process is completed in a way that is repeatable, without odd little things being left out. Too often issues with SharePoint environments are caused by slight misconfigurations, because the process being used is not repeatable or even scripted.

The benefits of using the MinRole approach are not only that it can be scripted to make it an even better template approach, but that deployment is now simplified. By deploying the servers using the Microsoft-recommended MinRole topology, we can now focus on what actually needs to be enabled in the feature stack.

The MinRole model also brings with it better performance tweaks than we could probably have figured out ourselves due to Microsoft running it in the cloud. As you know, the model has always been "cloud first." As such, we in the On-Premises world get those benefits in SharePoint 2016. As the deployed services are optimized as part of the MinRole approach, we should get better reliability and network latency.

The final benefit is really around capacity planning. As I mentioned before, I am an advocate of deploying environments using the "template" approach, whether scripted or not. The new role approach allows for predictable and prescriptive capacity planning guidance, and for topologies to be designed and delivered. Adding servers to scale is now even easier due to the automated process used for provisioning of services specifically for the designated roles.

What topologies are recommended when using the MinRole?

Microsoft currently recommends the following server topologies:

These topologies will allow for better server farms; however, if we look at what the minimum should be, we are now moving into using more servers than before.

Microsoft has stated the minimum 100% supported environment using MinRole is a four-server farm. The farm would not offer any resiliency or recovery as such, so larger farms will be needed. The example used by Microsoft is moving the standard four-server farm to be a fully resilient topology, which would mean the minimum would now be nine servers.

We would also need to add SQL to this, and you would probably be using Always On Availability Groups--using multiple servers that could then scale to a minimum of two servers or more, which would take our total to about 11 servers!!

This does not mean that you have to have something this large. You still have the ability to build out servers as needed, starting with a two-server farm. Of course, my recommendation would be to build out a much larger, more resilient environment. Now, remember, you can opt out of the MinRole setup process, as SharePoint 2016 Preview supports the backward-compatible approach using the Custom role. You can setup your SharePoint 2016 farm in this manner, and then choose to modify later by using the standard role change options that are now available within Central Administration. To change a server role simply modify its role.

So no more worries about manually changing the services and roles if you are using the MinRole process. And, as an advocate for making our SharePoint environments more secure, i encourage you to consider that the MinRole model--though not a security function--goes a long way toward reducing the footprint and surface area of attack on these servers, which can only help us in the long term.