Hi All
We are midway through testing of a migration from SharePoint 2010, to SharePoint 2013.
We have no functional issues, but there are 2 'non-errors' listed when we run Test-SPContentDatabase against each of the upgraded Content Databases - and the question for both is - are these safe to ignore?
ISSUE 1)
The background is that in 2010 they were using Classic auth and we don't have the option to change that to CBA pre-migration. So, in following TechNet guides, we created scripts to create the 2013 Web Application using Classic Auth, Dismount the temp DB
created as part of the Web App creation, then mount the migrated 2010 Content DB, allowing it to do the upgrade to 2013 format - thereafter we run the CBA conversion, and then MigrateUsers, then Visual Upgrade; as per the following:
New-SPWebApplication -Name $webAppName -Port 80 -HostHeader $hostHeader -URL $webAppUrl -ApplicationPool $appPoolName -AuthenticationMethod "NTLM" -DatabaseName $TEMPcontentDB -Path $virtDirectoryPath
#Mount DB
Dismount-SPContentDatabase $TEMPcontentDB -confirm:$false
Mount-SPContentDatabase -Name $contentDB -DatabaseServer $databaseServer -WebApplication $webAppUrl -confirm:$false
$db = Get-SPContentDatabase $contentDB
$db.RefreshSitesInConfigurationDatabase()
Convert-SPWebApplication -Identity $webAppUrl -To Claims -RetainPermissions -force
$wa = Get-SPWebApplication -identity $webAppUrl
$wa.MigrateUsers($true)
#Visual Upgrade
Upgrade-SPSite $webAppUrl –VersionUpgrade
Now, all seems fine, but we have the following on every migrated Site Collection; regardless of what we do - can this be ignored, or does anyone have any ideas?
Category : Configuration
Error : False
UpgradeBlocking : False
Message : The [SharePoint - DC SOURCE 2013 TEST MIGRATE] 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 :
ISSUE 2)
This one is much simpler.
Post-migration, again for every Site Collection migrated, I am getting:
Category : SiteOrphan
Error : True
UpgradeBlocking : False
Message : Database [SP13_DEV1_ClientRel_Content_01] contains a site (Id = [4278a1f0-e14d-4af4-b663-a099ec375dad], Url = [/]) whose id is already associated with a different database (Id = [a3e39217-27bb-4fda-b2c8-4f056b53a814],
name =
[SP13_DEV1_ClientRel_Content_01]) in the site map. Consider deleting one of these sites which have conflicting ids.
Remedy : The orphaned sites could cause upgrade failures. Try detach and reattach the database which contains the orphaned sites. Restart upgrade if necessary.
Locations :
I checked and it is referring to the Root of each Site Collection; BUT the
sitemap=true. I tried dismount, remount and then:
$db = Get-SPContentDatabase $contentDB
$db.RefreshSitesInConfigurationDatabase()
Yet the 'non-error' persists.
Is this something that can be ignored? As I understood, if you see sitemap=false it means the site must be deleted; but if sitemap=true; can it be ignored?