When running Test-SPContentDatabase in SharePoint 2013 or SharePoint 2016 you may receive the following message as one of the results, even if the database is from a claims authentication web application:
Message: The <WebApplicationName> 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 .
During a SharePoint 2010 to SharePoint 2013 upgrade this was pretty normal and indicated that you would need to convert the users from classic to claims authentication during the migration process. However, when upgrading from SharePoint 2013 to SharePoint 2016, this is less expected as most SharePoint 2013 web applications are already in claims mode for authentication. Looking at the details of the test will clarify why you may receive this message even when the source database is from a claims enabled SharePoint 2013 web application.
This test runs a SQL query that returns the first site collection administrator for the first site collection in a content database and checks to see if the site collection administrator login name starts with an identity claims prefix for a user's identity (i:). If it sees a string starting with anything other than "i:" it will report that that the database is intended to be used with a classic mode web application.
To understand why you may see a false positive when using an AD group as site collection administrator it's necessary to understand how claims encoding in SharePoint works. For a primer, please see Victor Wilen's excellent explanation. In summary:
- Individual Users are in the format: i:0#.w|<Domain\UserName>
- Groups are in the format c:0+.w|<GROUP SID>
Therefore, because this test uses "i:" as the comparison, using an AD group as a site collection administrator may cause a false positive.
If you want to replicate the test and see the specific reason the test triggered, you can run this SQL query against a non-production copy of the content database in question. Before doing so please review the Read Operations Addendum in the article Support for changes to the databases that are used by Office server products and by Windows SharePoint Services.
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:%'
First, determine if you are using AD groups as site collection administrators. You can use this PowerShell sample to scan a content database, web application, or the whole farm for site collections that are using AD groups as either the primary or secondary owner. Please note that this script will only return valid results for claims enabled web applications.
If you find any groups that are site collection administrators, consider changing them to individual users and re-running Test-SPContentDatabase. Alternatively, if you are confident that the database is from a claims authentication web application in the source farm you may consider ignoring the result and continuing with the upgrade progress.
For more information on resolving other Test-SPContentDatabase findings please see:
Post Upgrade Cleanup – Missing Server Side Dependencies
Removing Orphaned Sites: PowerShell Replacement for stsadm -o deletesite
Test-SPContentDatabase Classic to Claims Conversion
List all site collections AD groups as Owner or SecondaryContact is an AD group
How Claims encoding works in SharePoint 2010