This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(12.8, 6%, 11%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EBD%3C/text%3E%3C/svg%3E)
I have a database on SharePoint 2016 that was upgraded from SP2010 to SP2016 and finally to SP2016. The database attached, upgraded, and I can query users in the SPWebs without issue.
When I mount that database to SharePoint 2019, it upgrades and sites load without issue. PSCONFIG will complete successfully.
When I attempt to Get-SPUser in any of the SPWebs, it returns the following:
There is a version mismatch between the Web server and the content databases, and connections to the data have been
blocked to avoid data loss. This can happen when a service pack is not completely installed. Notify your server
administrators so that they can upgrade the Web server and the databases to the same version. For more information
about installing service packs and updates, see the Microsoft Web site (http://go.microsoft.com/fwlink?LinkID=177163).
At line:1 char:1
If I dismount the content database and attempt to mount it back up to the farm, it tells me
Mount-SPContentDatabase : This content database has a schema version which is not supported in this farm.
I have about 10 databases on this farm in a similar state and Upgrade-SPContentdatabase returns:
WARNING: Database [SPContentDatabase Name=ARCHIVE_015] cannot be upgraded.
What can I do to bring these SPSites and the Content Database to a good working condition?
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(313.6, 51%, 40%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EED%3C/text%3E%3C/svg%3E)
Thank you for your question.
We are currently looking into this issue and will give you an update as soon as possible.
Thank you for your understanding and support.
Hi @Bradway, Drew ,
If you managed to execute the Move-SPSite successfully to move contents from a corrupted Content Database to a "clean" one than you should be safe.
It would be considered unsupported if you have altered manually the DB Version table using T-SQL
As far as I understood, you made a lot of migrations as originally the DBs where on SP2010 and you went through all versions till SP2019 (correct me if I'm wrong).
SP2010 -> SP2013 (both upgrade for content DB and Branding upgrade) -> SP2016 -> SP2019
I do believe that during all this chain, at some point, the upgrade was not executed in a clean way and it left the Content DB in a limbo.
The versioning in the 1st screenshot about Affected Database Entries are indeed wrong
Agree fully. I have since decided to take a much more conservative approach to fixing this issue by avoiding editing or replacing the Versions table. I am running into space issues and speed issues with Commvault so I am still waiting to confirm this process works and will update this accordingly. My process is now as follows:
1: Copy SP2010 Database to SP2013 SQL Server and attach to SP2013
2: Remove any broken Features from all SPWebs
3: Run Upgrade-SPSite on all sites in Database
4: Detach from SP2013, Attach to SP2016
5: Move-SPSite to new/known good SP2016 Databases
6: Move new Database to SP2019 SQL Server and attach to SP2019 Farm
7: Run User Migration Script
I suggest you install the latest CU for the SharePoint 2019 server. Then run following PowerShell.
PSConfig.exe -cmd upgrade -inplace b2b -wait -cmd applicationcontent -install -cmd installfeatures -cmd secureresources -cmd installcheck -noinstallcheck
If the answer is helpful, please click "Accept Answer" and kindly upvote it. If you have extra questions about this answer, please click "Comment".
Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.
Sorry, I should have mentioned. Latest CU is installed and I ran that PSCONFIG line. No change.
You could check ULS logs to find more clues.
I checked the ULS logs and they mentioned database schema versions. After some research, I pulled the dbo.Versions table from the affected database and compared it with a known good database that I created on the SharePoint 2019 farm. I believe the problem lies with the following entries:
Notable Affected Database Entries:
Comparable Known Good DB Entries:
Using this data, I took a copy of the dbo.Versions table from a known good database and used it to replace the dbo.Versions table on the affected database. The result allowed me to query SPWebs and SPUsers, but gave a generic server error when attempting to load the page. From there, I created a new database and used Move-SPSite to move the sites from the affected database to a new database. After the sites moved and I ran IISRESET, the sites load and the ULS now shows no schema version errors. I have deleted the affected database and now have reason to believe that although this fix is considered unsupported, the farm and databases should now be in a supported state, since the content was moved but the corruption did not copy over. I do wonder why the entries with version 4.0.x.y were marked as the active, or current versions rather than the 16.0 or 17.0 versions. Since this farm will serve as an archive data store, I feel that this may be an acceptable outcome but would like professional input on this as well to confirm.
Thanks for your sharing.
Hi @Bradway, Drew ,
I have adapted the process based on my previous experiences:
0 (new): Check and Ensure your Web Application in SP2010 is already migrated/created as Claim Authentication Based
---> IF the application is still in Classic Mode Authentication then you have to convert it (https://learn.microsoft.com/en-us/sharepoint/upgrade-and-update/migrate-from-classic-mode-to-claims-based-authentication-in-sharepoint-2013)
I recommend you to do this part at the very beginning before moving forward to SP2013. It means you have to do it once as preliminary step in your current production
1: Copy SP2010 Database to SP2013 SQL Server and attach to SP2013
---> Correct (Mount-SPContentDatabase "WSS_Content_XXX" -WebApplication "XYZ" -Confirm:$false)
---> Verify your SP2013 is running within SP1 + latest CU applied
2 (new): Upgrade DB Schema Version to SP2013
---> Upgrade-SPContentDatabase "WSS_Content_XXX" -Confirm:$false
3: Remove any broken Features from all SPWebs
---> Correct (Test-SPContentDatabase "WSS_Content_XXX" -WebApplication "XYZ") -- in case you want to take track of possible missing features before removing them
4 Run Upgrade-SPSite on all sites in Database
---> Correct (Upgrade-SPSite -identity "http://XYZ" -VersionUpgrade) -- depending on the number of site collections you can create a foreach loop
5 (new): Verify the sites are functional and no major issues when browsing them in SP2013
---> This is important because you have done already few important steps: Claim Auth Based - DB Upgrade - Site Col Upgrade so it's important you verify everything is under control
---> You may check already at this point the DB Version in the SQL Table. You should see something like 15.0...
6: Detach from SP2013, Attach to SP2016
---> Correct
5: Move-SPSite to new/known good SP2016 Databases
---> Not Needed: IF everything OK, at this point, you should simply take another SQL Backup and restore the *.bak files in SP2016 as you did previously
Once restored then perform again a Mount-SPContentDatabase as you have done in the 1st jump to SP2013 (there is no need to do the Move-SPSite)
6: Move new Database to SP2019 SQL Server and attach to SP2019 Farm
---> Correct
7: Run User Migration Script
---> Why would you do that ? Are you changing also domain while migrating from a SP platform to another ?
Last couple of shots:
This is excellent, thank you. I will incorporate this into my process. The user migration script is due to the fact that the old 2010 farm uses Ping authentication for SSO, and the Archive farm will only be using AD claims.
You're welcome, unfortunately I never covered Ping as SSO only pure Microsoft ADFS tech so I cannot help on that :(
Same here, but the basics seem to be very similar. It seems to work very much the same in setting the SPTrustedIdentityTokenIssuer as well as the claims migration.
Concerning the jump from SP2010 to 2013, this is well documented in the article here: https://www.sharepointdiary.com/2013/09/migrate-from-sharepoint-2010-to-2013-step-by-step.html