SharePoint HealthReport – Claims/Classic mismatch

This is part of a series on SharePoint Health Report issues, because I can never remember what to do about them.

Claims/Classic mismatch

The warning looks like this:

Category        : Configuration
Error           : False
UpgradeBlocking : False
Message         : The [SharePoint] web application is configured with claims
                  authentication mode however the content database you are
                  trying to attach is intended to be used against a windows
                  classic authentication mode.
Remedy          : There is an inconsistency between the authentication mode of
                  target web application and the source web application.
                  Ensure that the authentication mode setting in upgraded web
                  application is the same as what you had in previous
                  SharePoint 2010 web application. Refer to the link
                  "http://go.microsoft.com/fwlink/?LinkId=236865" for more
                  information.
Locations       :

The obvious solution is that the warning is correct and there is a configuration mismatch:
Either the ContentDatabase was migrated or the authentication scheme for the WebApplication was changed: In this case, you probably forgot to run Convert-SPWebApplication to convert all logins to claims.

On the other Hand, it is possible that Convert-SPWebApplication has been run properly but not everything was converted properly: Trevor Seward explains that the rule to create above message will simply report that

SELECT TOP 1 [tp_SiteID],[tp_Login] FROM [UserInfo] WITH (NOLOCK) WHERE tp_IsActive = 1 AND tp_SiteAdmin = 1 AND tp_Deleted = 0 and tp_Login not LIKE 'i:%'

yielded results.

In his post, Trevor explains that deleted AD users are not converted and could be the root cause of the
warning.
In my case someone added an AD-Group as SiteCollection administrator. For one this simply does not work
and also – as AD-Group claims start with c: this will also result in above warning.

In any case: Removing the offending entries (using PowerShell or manually from the UI – do not delete things from the ContentDatabase!) will solve the problem.

Leave a Reply

Your email address will not be published. Required fields are marked *