This issue is still under investigation – current I think this issue occurs, when SharePoint is installed, followed by a Language Pack and then the creation of the farm. Checking the compliance status of the min role at this particular time will result in a not compliant state.
Microsoft introduced with SharePoint 2016 a new feature called “MinRoles”. MinRoles offer a new way on how to create SharePoint topologies. The following MinRoles are available:
- Front-End
A role made for all loads in context of serving SharePoint - Application
This role is optimized for all services that need to run in a SharePoint Farm – without the Search loads - Distributed Cache
Hosting the Distributed cache service - Search
All services associated to the search load of SharePoint - Custom
This role is needed if you plan on using Business Intelligence loads, as they are not pat of the other MinRoles - Single-Server farm
In October 2016 Microsoft release Feature Pack 1 (FP1) for SharePoint 2016. The FP1 offers two new MinRoles (MinRolesV2):
- Front-end with Distributed Cache
- Application with Search
These two roles combine the prior roles, so that customers can create high available (HA) farms for SharePoint with less servers. Prior to FP1 you did need at least two servers of (each) role: 2 WFE, 2 App, 2 Search, 2 Distributed Cache. In total 8 servers. After you install FP1 you can switch to the combined min roles and will be able to create a SharePoint HA Farm with 4 servers instead. This offering focuses on SharePoint customers with HA requirements, but not enough workload for hosting 8 SharePoint servers.
With each MinRole a set of services can be run on a server. SharePoint 2016 enforces the state of these services. For a complete list of all services that belong to a role, visit the technet documentation.
Behind the scenes
New “Services in Farm” experience in Central Administration
The following screenshot shows the “Services in Farm” page of SharePoint 2016 Central Administration:

A soon as any MinRole is defined the Services on Server page will show the selected servers role and for each service the status and its compliance state. SharePoint offers you some options:
- you can stop a service
- you can fix a non-compliant state of a service with one click
Where does this MinRole compliance information come from?
In a recent customer engagement I stumbled across something, that bothered me. The customers SharePoint Farm uses MinRolesV2 and I did check the Microsoft Documentation for wich services are allowed on the server. After a while I had a service in a not compliant state and did not know why. I reached out to the community, but did not end up, with a define answer:
Today I spend some time with the SharePoint source code and did find the answer:
SharePoint Service instances are represented by the SPServiceInstance class. Every SharePoint Service Instance (e.g. SPWindowsTokenServiceInstance) derives from this class and overrides the following method:
// Microsoft.SharePoint.Administration.SPServiceInstance public virtual bool ShouldProvision(SPServerRole serverRole) { }
There is a additional internal method: ShouldProvisionInternal, which does some additional the tests for the following roles:
- SPServerRole.WebFrontEndWithDistributedCache
- SPServerRole.ApplicationWithSearch
When your server is of the roles above, the ShouldProvision method will be called with both single roles and the combined role. If any of these tests returns true, then this role is compliant.
Not knowing, whether the documentation is wrong or the code, I did investigated the SPWindowsTokenServiceInstance code.
// Microsoft.SharePoint.Administration.Claims.SPWindowsTokenServiceInstance public override bool ShouldProvision(SPServerRole serverRole) { return SPServerRole.SingleServerFarm == serverRole || SPServerRole.Application == serverRole || SPServerRole.WebFrontEnd == serverRole || (SPServerRole.DistributedCache == serverRole && !SPServerRoleManager.IsMinRoleV2Enabled()) || (SPServerRole.Search == serverRole && !SPServerRoleManager.IsMinRoleV2Enabled()) || SPServerRole.Custom == serverRole; }
The implementation above, does not include tests for the MinRolesV2 – but the non V2 roles are introduced through the ShouldProvisionInternal method anyway. Following this, there is no error in the code or the documentation. This applies for the Microsoft.SharePoint.dll in Version: 16.0.4561.1000
So what is wrong with my farm (Januar CU 2018):
// Microsoft.SharePoint.Administration.Claims.SPWindowsTokenServiceInstance public override bool ShouldProvision(SPServerRole serverRole) { if (SPServerRole.SingleServerFarm != serverRole && SPServerRole.Application != serverRole && SPServerRole.WebFrontEnd != serverRole && (SPServerRole.DistributedCache != serverRole || SPServerRoleManager.IsMinRoleV2Enabled()) && (SPServerRole.Search != serverRole || SPServerRoleManager.IsMinRoleV2Enabled())) { return SPServerRole.Custom == serverRole; } return true; }
The code above is taken from a Microsoft.SharePoint.dll in File Version: 16.0.4639.1002
This means the current documentation does not reflect the code properly. In case, that I read the code properly, the the only allowed role to host C2WTS with the MinRoleV2 is the Custom role.
Conclusion: There is a drift in the documentation. When I’m not mistaken, I do not need the C2WTS in a non-BI enabled farm. The BI enabled farm does need a MinRole Server “Custom” to run reporting services and other roles. This answers why, the C2WTS is no longer allowed in any other role. Maybe someone should update the documentation…
Update 2018-03-23:
I did double check the code of the ShouldProvisionInternal and ShouldProvision methods and have a strong believe, that there is something wrong to determine the MinRole compliance. Find below a screenshot of what I think the returns should be, but somehow are not!

Following this code: The result should be that the MinRoleV2 ApplicationWithSearch should be able to run the Claims to Windows Token service.
I really hope, someone can me help me to figure this out. Is there any part, I do not read correctly?