SharePoint 2010 Site Experience With SharePoint 2016

While testing an upgrade today, I was reminded of a requirement when upgrading to SharePoint 2016 using the database attach method – you must upgrade all site collections to the SharePoint 2013 experience before you attempt to attach the database to a SharePoint 2016 farm.

My test today is using a SharePoint 2010 content database and attempting an upgrade to SharePoint 2016. I first performed a database attach upgrade with a SharePoint 2013 farm, then performed the Test-SPContentDatabase PowerShell command on the database from my SharePoint 2016 farm.

SharePoint 2010 experience with 2016 Upgrade
SharePoint 2010 experience with 2016 Upgrade

It is important to notice that the LegacySiteDetected error shown above is an UpgradeBlocking error, meaning the upgrade will fail if you proceed. Following the direction listed in the Remedy section will fix the issue, but it does require working in the SharePoint 2013 farm to upgrade the site’s experience to 2013. More information on how to perform that operation can be found here: Expand Upgrade a site collection to SharePoint 2013 [TechNet]

Upgrade SharePoint 2010 to 2016 Release Candidate

It is a frequent question – can I skip a SharePoint version when upgrading? For example can I do a direct upgrade from SharePoint Server 2007 to 2013? The answer is no, you can’t without having to use a migration product – which isn’t really “upgrading.” The path to upgrade SharePoint 2007 to 2013 includes an upgrade to SharePoint 2010 first.

In March of 2015, Bill Baer, Senior Product Marketing Manager at Microsoft, asked if there was any demand for skipping ahead when doing a SharePoint upgrade (a.k.a. N-2 upgrade).

My response was similar to many other SharePoint administrators and architects: Yes! Absolutely!

I recently decided to give it a shot – upgrade a SharePoint 2010 site collection via database upgrade to SharePoint Server 2016 Release Candidate (RC). As of this post’s writing, SharePoint 2016 has not been released to production (RTM), but since we have been told the RC is close to the what will be delivered in RTM, it would be a good trial.

I installed Service Pack 2 and the December 2015 CU to my 2010 farm and after the typical issues, I was ready to go.

I took a backup of the 2010 content database and restored it as a new database appropriately named SP10_to_SP16RC_Content. On my SharePoint 2016 RC server, I performed a Test-SPContentDatabase Powershell call on the database.

Test-SPContentDatabase SharePoint 2016 RC
Test-SPContentDatabase SharePoint 2016 RC

The result:

Test-SPContentDatabase 2016 RC on SharePoint 2010 Database
Test-SPContentDatabase 2016 RC on SharePoint 2010 Database

Lots of red text! It appears the test failed when seeing a table column name ‘PlaformVersion’. So, from this, we can gather that the upgrade will fail. Just to confirm, I went ahead with the upgrade.

Mount-SPContentDatabase 2016 RC on SharePoint 2010 Database
Mount-SPContentDatabase 2016 RC on SharePoint 2010 Database

SharePoint Server 2016 Release Candidate will not upgrade a SharePoint 2010 database via the database attach method. The database version required, as noted in the error message, is 15.0.4420.1017 – that’s SharePoint 2013 RTM. To upgrade to 2016 RC, you will need to first upgrade the 2010 database to 2013, then you will be able to go to 2016 RC.

SharePoint 2010 Updates and 503 Error

Today I updated a SharePoint Server 2010 test virtual machine with service pack 1 (SP1; Foundation and Server) and the August 2011 cumulative updates for SharePoint Foundation and SharePoint Server. I ran the SharePoint configuration wizard after installing all the updates.

When I rebooted the server (suggested when encountering the User Profile sync problem after applying the patches) and tried to open one of the team sites, I received a 503 Service Unavailable error (as shown in the picture below).

Service Unavailable – HTTP Error 503. The service is unavailable.ServiceUnavailable503

Once I got over the “what did I do??!?” moment, I of course recognized this as an IIS error, not a SharePoint error. I opened the Internet Information Services (IIS) Manager MMC and noticed that none of the SharePoint Application Pools were running. After starting all the needed Application Pools, everything is back to normal.

Error Connecting to Database Server

I recently setup yet another SharePoint farm (this time using virtual machines) and ran into a problem that happens all too often.

The scenario is this: I setup MS SQL server in preparation for getting SharePoint installed on a separate server. After setting up your service accounts in Active Directory and installing MS SQL on Server1, I set off installing SharePoint on Server2. When I got to the screen in the Specify Configuration Database Settings within the SharePoint configuration wizard, I received the following error:

Cannot connect to database master at SQL server at ServerName. The database might not exist, or the current user does not have permission to connect to it.

Knowing the database ‘master’ did exist, I setout to solve the “current user does not have permission” issue. I opened the SQL Management Studio and checked to make sure my account had permission to connect.


I checked the permissions for the service account and everything looked good. So, what’s going on?!?

Since I don’t follow a setup script anymore (I have done this hundreds of times, so I know what I am doing, right?), I had forgotten one step. MS SQL listens for incoming traffic on port 1433. When setting up your SQL server, you have to make sure you create a firewall rule to allow that incoming port. This is elementary and I should have remembered this step, but no one is perfect, right?

So, I opened Windows Firewall (if you are using a different firewall product, the steps should be similar).


I selected Inbound Rules in the left window and then chose New Rule… from the Actions menu on the right.

Select Port for the type of rule you want to create, click Next, and then type in 1433 in the port field.
Click Next and then select to Allow the connection. Go through the rest of the wizard by clicking Next and filling in the appropriate content.


Again, this is not rocket science, but I hope this information can be helpful to the next person who forgets the important step of allowing inbound connections to their SQL server!