Minroles under the hood

Today I was playing with the minroles, a new concept inside SharePoint 2016. Basically, the idea of minrole is to streamline and “templatize” deployment of SharePoint farms. You need another web front end? No problem, just deploy another server with the “Front-End” minrole, and voila, there you go – no need to think about services which should run on that server, Microsoft is doing that sort of thinking for you now.

It can help. I’ve seen a lot of (and I mean: a lot of!) screwed up SharePoint deployments. Sure, you can argue that minroles are not customizable, they are what they are, and that you’ll do better on your own. And if you know what you are doing, you are probably right, I’ve already heard plenty of arguments pro and contra minroles. I don’t want to go there, here I just want to explore the architecture under the minroles, and actually to test new Open Live Writer which appeared on the github today 😉

So, the minroles. Each server joined to the farm can be member of one of the following minroles:

(information from )

Front-end
Service applications, services, and components that serve user requests belong on Front-end web servers. These servers are optimized for low latency.

Application
Service applications, services, and components that serve backend requests (such as background jobs or search crawl requests) belong on Application servers. These servers are optimized for high throughput.

Distributed cache
Service applications, services, and components that are required for a distributed cache belong on Distributed Cache servers.

Search
Service applications, services, and components that are required for searching belong on Search servers.

Custom
Custom service applications, services, and components that do not integrate with MinRole belong on Custom servers. The farm administrator has full control over which service instances can run on servers assigned to the Custom role. MinRole does not control which service instances are provisioned on this role.

Single-server farm
Service applications, services, and components required for a single machine farm belong on a Single-Server Farm. A Single-Server Farm is meant for development, testing, and very limited production use. A SharePoint farm with the Single-Server Farm role cannot have more than one SharePoint server in the farm.

GUI Options in the Central Admin

When we deploy the farm, in Central Administration -> System Settings, in servers and services management, we can see some minrole specific options:

In the server management, we can see which server got assigned which minrole, and if the server is actually compliant with that role. In this case, “compliant” means that the services on that server correspond to the services meant to be in that minrole. You could, after server is deployed, start some more service instances on that server, which are not in correspondence with that role. For example, starting Word Automation Services on a server with Front-End Role would bring that server in “not compliant” state. Central Admin will hereby allow you to identify, and to repair such the issues with one (or few) clicks, and to bring that server back to the compliant state.

The same way, you can – on the service management page – see if the services installed on farm are compliant. That’s the flip side, you would see the Word Automation Service here not being compliant, in the above mentioned case, because it runs on the server where it is not supposed to run (server with the Front-end minrole).

Behind GUI

So, that’s GUI. I don’t know how far/deep will it go with PowerShell cmdlets, I’ve seen scripts which can be used to change server minrole (basically to disconnect server from the farm, and to rejoin it with a new role), and that’s already well documented in the abovementioned link, and in Bill Baer’s blog post (). But, let’s see what server side object model is offering us. Yes, server side – we are dealing with on-prem administrative feature here, so it’s ok. Writing PowerShell is easy when we know what is in the treasure chest.

First of all, we’ll notice SPServerRole enum in Microsoft.SharePoint.Administration namespace:

/// <summary>Specifies the role of the server with respect to the Windows SharePoint Services deployment.</summary>
public enum SPServerRole
{
    /// <summary>Specifies that the server does not have a registered role in the configuration database.</summary>
    Invalid,
    /// <summary>Specifies that the server is a front-end Web server within the Windows SharePoint Services deployment.</summary>
    WebFrontEnd,
    /// <summary>Specifies that the server runs a Web application.</summary>
    Application,
    /// <summary>Specifies that the server is the only server in the Windows SharePoint Services deployment.</summary>
    [System.Obsolete("Use SPServerRole.SingleServerFarm instead.")]
    SingleServer,
    SingleServerFarm,
    DistributedCache,
    Search,
    Custom = 8
}

This enum was there in the earlier versions of SharePoint, but only with “WebFrontEnd”, “Application”, “SingleServer” and “Invalid” values (“Invalid” for the servers for which the server role could not be determined). The values “WebFrontEnd” and “Application” have been reused for the minroles with the same or similar names, and “SingleServer” has been deprecated. For the SharePoint 2016 servers with “Single Server” minrole, the value “SingleServerFarm” is now used.

The values “DistributedCache”, “Search” and “Custom” have been added to this enum in SharePoint Server 2016, for new minroles with the same names.

Next, we’ll notice that SPService object (Microsoft.SharePoint.Administration) has got the “CompliantWithMinRole” boolean property, which determines if that service is compliant with the role of the server where it runs. So, basically, you can iterate services in farm, to determine if all of your services / servers are in the minrole compliant state:

//get the farm
SPFarm farm = SPFarm.Local;

//We need to get service instances, running on each server
//and to see if it is compliant with the minrole that server has been assigned to
//of course we can ignore the custom minrole
foreach (SPServer server in farm.Servers)
{
    //get a server from farm
    Console.WriteLine("Server name: " + server.Name);
    Console.WriteLine("Server role: " + server.Role.ToString());

    Console.WriteLine("-------------------------------");

    //a bool variable where we will check if the server is compliant with its role
    bool serverCompliantWithRole = true;

    //get all service instances provisioned on this server
    foreach (var instance in server.ServiceInstances)
    {
        //get the parenet service for selected instance
        SPService service = (SPService)farm.GetObject(instance.Service.Id);

        //determine if service is compliant with the minrole associated with this server
        bool isServiceCompliant = service.CompliantWithMinRole.HasValue ? service.CompliantWithMinRole.Value : true;

        //list it in console
        Console.WriteLine("Compliant with " + server.Role.ToString() + " : " + isServiceCompliant.ToString());
        Console.WriteLine("");

        //and it with server compliance status, it all has to be "true"
        serverCompliantWithRole = serverCompliantWithRole && isServiceCompliant;
    }

    Console.WriteLine("-------------------------------");

    //output if the whole server is compliant with minrole
    Console.WriteLine("Is server compliant with MinRole: " + serverCompliantWithRole.ToString());
}

But, how does the property SPService.CompliantWithMinRole know if the service on that server is minrole compliant? If we reflect that property, it will very soon take us to the classes “SPServerRoleManager” and “SPServerRoleConversionUtil”, which offer all those beautiful things like configuring servers for a specific minrole, checking server states, repairing server states, bringing server back to the compliant mode, etc. The only problem with those classes is – they are internal, and they are sealed. Now, whoever thought that Microsoft might not be sandboxing SharePoint after all, there is the answer. They are.

Anyway, reflecting these classes gives us some valuable insights in how minroles actually work. One of the interesting things is, there is no “database” or “definite list”, which would state which services are compliant with which minrole. More the less, each service instance has “ShouldProvision()” method, which accepts the minrole as the only parameter, and outputs a boolean value which gives that information. That is what SPService.CompliantWithMinRole property is invoking.

So, if you really want to know which services belong to which minrole, you should iterate service instances (yes, instances) on a vanilla deployment, which includes all roles, and then take a look what is there:

//first get all possible minroles
Array minRoleValues = Enum.GetValues(typeof(SPServerRole));

//now initialize a dictionary, which will contain roles as keys, and all services belonging to a role as a list of string values
Dictionary<SPServerRole, List<string>> servicesInRole = new Dictionary<SPServerRole, List<string>>();
foreach (SPServerRole minrole in minRoleValues)
{
    servicesInRole.Add(minrole, new List<string>());
}

//now iterate all service instances - 
//this is where the information if service belongs to a minrole is stored - 
//and check to which service it belongs

//get services in farm
foreach (SPService service in farm.Services)
{
    //get instances of the service
    foreach (var instance in service.Instances)
    {
        //check in which minrole can an instance live
        //iterate through all of the minroles
        foreach (SPServerRole minrole in minRoleValues)
        {
            //check for a specific minrole
            if (instance.ShouldProvision(minrole))
            {
                //add it if there, and if not already added
                if (!servicesInRole[minrole].Contains(service.TypeName))
                {
                    servicesInRole[minrole].Add(service.TypeName);
                }
            }
        }
    }
}

//list it in console
foreach(SPServerRole role in servicesInRole.Keys)
{
    Console.WriteLine(role.ToString());
               
    foreach (string serviceTypeName in servicesInRole[role])
    {
        Console.WriteLine(serviceTypeName);
    }
    Console.WriteLine("");
}

Conclusion

It is noteworthy to mention that the minroles are sealed concept. You cannot change or create your own minroles or change anything about comliant/not compliant definition. And, as we’ve seen it, the “juicy” APIs are concealed, and only the basic functionality is exposed. It is as it is – if you would like it to be changed, vote at SharePoint UserVoice here –

Appendix – Services / Minroles compliancy list

At the moment of writing this article, the following services are compliant with the following roles:

WebFrontEnd

• Access Services
• Access Services 2010
• App Management Service
• Business Data Connectivity Service
• Claims to Windows Token Service
• Information Management Policy Configuration Service
• Machine Translation Service
• Managed Metadata Web Service
• Microsoft Project Server Calculation Service
• Microsoft Project Server Events Service
• Microsoft Project Server Queuing Service
• Microsoft SharePoint Foundation Administration
• Microsoft SharePoint Foundation Database
• Microsoft SharePoint Foundation Sandboxed Code Service
• Microsoft SharePoint Foundation Subscription Settings Service
• Microsoft SharePoint Foundation Timer
• Microsoft SharePoint Foundation Tracing
• Microsoft SharePoint Foundation Usage
• Microsoft SharePoint Foundation Web Application
• Microsoft SharePoint Insights
• PerformancePoint Service
• Portal Service
• Project Server Application Service
• Request Management
• Secure Store Service
• Security Token Service
• SharePoint Server Search
• SSP Job Control Service
• User Profile Service
• Visio Graphics Service

Application

• App Management Service
• Application Discovery and Load Balancer Service
• Business Data Connectivity Service
• Claims to Windows Token Service
• Information Management Policy Configuration Service
• Machine Translation Service
• Managed Metadata Web Service
• Microsoft Project Server Calculation Service
• Microsoft Project Server Events Service
• Microsoft Project Server Queuing Service
• Microsoft SharePoint Foundation Administration
• Microsoft SharePoint Foundation Database
• Microsoft SharePoint Foundation Incoming E-Mail
• Microsoft SharePoint Foundation Subscription Settings Service
• Microsoft SharePoint Foundation Timer
• Microsoft SharePoint Foundation Tracing
• Microsoft SharePoint Foundation Usage
• Microsoft SharePoint Foundation Web Application
• Microsoft SharePoint Foundation Workflow Timer Service
• Microsoft SharePoint Insights
• Portal Service
• PowerPoint Conversion Service
• Project Server Application Service
• Request Management
• Secure Store Service
• Security Token Service
• SSP Job Control Service
• User Profile Service
• Word Automation Services

SingleServerFarm

• Access Services
• Access Services 2010
• App Management Service
• Application Discovery and Load Balancer Service
• Business Data Connectivity Service
• Claims to Windows Token Service
• Distributed Cache
• Information Management Policy Configuration Service
• Lotus Notes Connector
• Machine Translation Service
• Managed Metadata Web Service
• Microsoft Project Server Calculation Service
• Microsoft Project Server Events Service
• Microsoft Project Server Queuing Service
• Microsoft SharePoint Foundation Administration
• Microsoft SharePoint Foundation Database
• Microsoft SharePoint Foundation Incoming E-Mail
• Microsoft SharePoint Foundation Sandboxed Code Service
• Microsoft SharePoint Foundation Subscription Settings Service
• Microsoft SharePoint Foundation Timer
• Microsoft SharePoint Foundation Tracing
• Microsoft SharePoint Foundation Usage
• Microsoft SharePoint Foundation Web Application
• Microsoft SharePoint Foundation Workflow Timer Service
• Microsoft SharePoint Insights
• PerformancePoint Service
• Portal Service
• PowerPoint Conversion Service
• Project Server Application Service
• Request Management
• Search Administration Web Service
• Search Host Controller Service
• Search Query and Site Settings Service
• Secure Store Service
• Security Token Service
• SharePoint Server Search
• SSP Job Control Service
• User Profile Service
• Visio Graphics Service
• Word Automation Services

DistributedCache

• Claims to Windows Token Service
• Distributed Cache
• Microsoft SharePoint Foundation Administration
• Microsoft SharePoint Foundation Database
• Microsoft SharePoint Foundation Timer
• Microsoft SharePoint Foundation Tracing
• Microsoft SharePoint Foundation Usage
• Microsoft SharePoint Foundation Web Application
• Microsoft SharePoint Insights
• Portal Service
• Request Management
• Security Token Service
• SSP Job Control Service

Search

• Application Discovery and Load Balancer Service
• Claims to Windows Token Service
• Microsoft SharePoint Foundation Administration
• Microsoft SharePoint Foundation Database
• Microsoft SharePoint Foundation Timer
• Microsoft SharePoint Foundation Tracing
• Microsoft SharePoint Foundation Usage
• Microsoft SharePoint Insights
• Portal Service
• Search Administration Web Service
• Search Host Controller Service
• Search Query and Site Settings Service
• Security Token Service
• SharePoint Server Search
• SSP Job Control Service