Upgrading to Sharepoint 2013 : Upgrading Content - Creating the Web Application, Testing the Content Database

While there are several steps to successfully upgrade content from SharePoint 2010 to SharePoint 2013, the process is relatively straightforward. This section describes the steps necessary to attach a SharePoint 2010 database to a SharePoint 2013 farm and upgrade it.

Creating the Web Application

Recall that our only option when upgrading content to SharePoint 2013 is to attach a SharePoint 2010 content database to a SharePoint 2013 web application. Therefore, the first step is to create a web application in your SharePoint 2013 farm. This can be the web application in which the data will permanently reside, or a temporary web app used only for upgrading. This flexibility is important if your SharePoint 2010 web application uses classic-mode authentication, rather than claims-based authentication (CBA, or just “Claims”). If you’re not completely up to speed on CBA. In SharePoint 2010, CBA was an option, but a lot of farms continued to use classic-mode authentication as they had in previous versions of SharePoint. In SharePoint 2013, Claims is an integral part of SharePoint; and it is necessary for most new SharePoint 2013 functionality to work. If your SharePoint 2010 environment uses classic-mode authentication, it will have to be converted to Claims in order to get the most out of SharePoint 2013. This conversion can be done either in SharePoint 2010 before the upgrade, or in SharePoint 2013 after the upgrade. Either method works fine, so use whichever method works best for your situation. Here are some things to consider.

To upgrade to Claims in SharePoint 2010 before upgrade:

• It must be done in production, so that carries some risk.
• If the upgrade to SharePoint 2013 isn’t done immediately, some SharePoint 2010 functionality may be lost.
• The process to convert to Claims in SharePoint 2010 is more complicated than in SharePoint 2013.
• You can upgrade content and authentication separately, which enables easier troubleshooting.
• All SharePoint 2013 functionality works immediately after upgrading.

To upgrade to Claims in SharePoint 2013 after upgrade:

• You must go to extra effort to create a classic-mode web app in SharePoint 2013.
• Upgraded content won’t have full functionality in SharePoint 2013 until after authentication is switched to Claims.
• The process for upgrading to Claims is smoother in SharePoint 2013 than in SharePoint 2010.

If you choose to upgrade to Claims in SharePoint 2010, this is the process:

$wa = Get-SPWebApplication http://webapplication
$wa.UseClaimsAuthentication = $true
$wa.Update()

$wa.MigrateUsers($true)

$wa.ProvisionGlobally()

Any accounts, including the Search content crawl account, that have been given web application policies in Central Admin will have to be given those policies again. If the portalsuperuser and portalsuperreader accounts have been defined, they must be reset with their claims-based version; otherwise, the web application may not render. Finally, if any alerts do not work correctly, they may need to be re-created by the user. If you choose to convert to Claims after the upgrade to SharePoint 2013, you need to create a classic-mode web application in SharePoint 2013 using PowerShell. The PowerShell you would use looks like this:

New-SPWebApplication -name "Classic Web App" -Port 80 -url 
http://upgrade.contoso.com -ApplicationPool "ClassicAppPool" -ApplicationPoolAccount
(Get-SPManagedAccount "domain\sp_webapps") -DatabaseName WSS_Content_Classic

This web app will be the one the classic-mode SharePoint 2010 databases are attached to when they’re upgraded. After the databases have been attached, use the following PowerShell command to convert them to Claims:

Convert-SPWebApplication -Identity http://upgrade.contoso.com -To Claims -
RetainPermissions

The preceding command will upgrade both the web application and the user mappings from classic to Claims. If additional classic SharePoint 2010 databases are attached to the now-converted web application, simply rerun the Convert-SPWebApplication command to convert the user mappings in the newly attached database.

Regardless of the approach you take, make sure the web application you create in your SharePoint 2013 farm matches the authentication method used in the databases that are attached to it. It’s also a good idea to create a site collection at the root of the web app before any upgrading takes place. This gives you a site collection to browse to in order to ensure that all of the underlying framework is working. This way, if there’s a problem with DNS or something else, you’ll know about it before you attach any SharePoint 2010 databases — and you know the problem isn’t caused by the upgrade.

Testing the Content Database

There are several steps to attaching your SharePoint 2010 content database to your SharePoint 2013. This section will walk you through each of them.

Restoring the Database in SQL Server

The first step in getting your database into SharePoint 2013 is getting it into the SQL Server instance that SharePoint 2013 is using. When testing the upgrade, your latest database backup should suffice. When you’re actually doing the upgrade, you’ll need to shut down all your SharePoint 2010 servers and then do full backups of all your SharePoint 2010 databases.

Whichever step you’re doing, copy the database backups over to the SQL instance that SharePoint 2013 is using and restore them. Many of the database’s properties are stored in the backup, and you might have to change them before you start using the database with your SharePoint 2013 farm. If the databases were not already using the Simple recovery model, it’s safe to switch them to that after the restore. If anything goes wrong with the upgrade, you just revert back to your backups, so having transaction logs won’t really do you any good. After the upgrade is complete, you’ll start backing the databases up regularly and you can change them to the Full recovery model if that’s what your disaster recovery strategy uses.

You also have to change the permissions to your databases in SQL Server. The database’s permissions are maintained during the backup and restore process. Using the same service accounts in two different SharePoint farms is a bad idea — like juggling chainsaws bad. Like juggling torches bad. Like juggling chainsaws on fire bad. Your SharePoint 2013 farm should have completely different service accounts than the farm from which your databases came. This means your SharePoint 2013 farm won’t be able to access the databases to test them or mount them. You’ll have to give two accounts permission to your databases after you restore them.

The first account is whatever account you’ll be running PowerShell as when you run the test and mount the cmdlets. Ideally, this will be a dedicated SharePoint administration account and not one of your SharePoint service accounts. The blog post at http://www.toddklindt.com/sp_farm explains why this is a good idea and how to configure it.

The second account to which you’ll need to give access to your newly restored databases is whichever service account is going to access it. In the case of content databases, this will be the app pool ID of the web application to which you’re attaching the database. This will be the sp_webapp account. If the database is a service application database, then that service application’s app pool ID will need access to it.

Each of these accounts needs the db_owner role on the database. You can give this permission in SQL Service Management Studio (SSMS). Open SSMS and navigate to Security ⇒ Logins in the Object Explorer. Find the account to which you want to grant access to the new database. Right-click it and select Properties. When the Properties dialog appears, navigate to the User Mapping page and find the restored database. Select the db_owner roles and click OK. Figure 1 shows giving the CONTOSO\sp_webapps account the db_owner roles for the WSS_Content_tk_com database.

FIGURE 1

Do this for all the databases you restore. If you forget this step you will probably get the following error message in PowerShell when you try to test or mount the database:

Cannot open database "wss_content_tk_com" requested
by the login. The login failed.
Login failed for user 'CONTOSO\sp_webapps'.

If you don’t get an error like that, then the account you’re running PowerShell as has permissions to that database through a server role.