Upgrading to Sharepoint 2013 : Upgrading Site Collections

After restoring your content database in SQL, testing it against your SharePoint 2013 web application, and mounting it in SharePoint, you’re in the home stretch. You’re so close you can almost smell that newly upgraded SharePoint 2013 site collection.

Another difference between the upgrading process in SharePoint 2010 versus SharePoint 2013 is that it is no longer scoped at the web level, but at the site collection level. The upgrade process can also be delegated to site collection administrators, or it can be done by farm administrators. This section mainly covers how the site collection administrators can upgrade their site collections in the browser, but the PowerShell is also included so farm administrators can join in on the fun on the back end.

When you browse to any of the site collections in newly mounted SharePoint 2010 content databases you’re likely to feel a little underwhelmed. OK, a lot underwhelmed. As shown in Figure 1, it looks and acts almost exactly like SharePoint 2010. The only exception is the red bar at the top begging you to upgrade it. Not a lot of payoff for all that work you’ve done. This is expected, however. As mentioned earlier, SharePoint goes out of its way to not upgrade SharePoint 2010 site collections to SharePoint 2013 when the databases are attached. You must upgrade them deliberately.

FIGURE 1

Site collection administrators have three upgrade-related options they can run for their site collections: run a heath report, create an eval site, or upgrade the site collection to SharePoint 2013. Each option is an important cog in the upgrade wheel.

Before SharePoint 2013 can upgrade your SharePoint 2010 site collection, it runs a health check looking for seven things that it hopes you didn’t do in that earlier version. You can manually trigger that health check to get a heads up on potential issues before you’re ready to run the upgrade. Log into your SharePoint 2010 site collection as a site collection administrator and select Site Actions ⇒ Site Settings. Toward the bottom of the Site Collection Administration section is a link to Site collection health checks. This page is pretty simple; there’s one button, Start checks. Click that button to have SharePoint 2013 run the health checks on the site collection and let you know if it found any issues. Figure 2 shows the health check from the database we attached earlier.

FIGURE 2

You can see SharePoint checked for the following seven things:

• Conflicting Content Types
• Customized Files
• Missing Galleries
• Missing Parent Content Types
• Missing Site Templates
• Unsupported Language Pack References
• Unsupported MUI References

Our site collection didn’t do too badly. It got passing grades on the last five items. It has a conflicting content type of Video that should be removed before upgrade. SharePoint 2013 was also kind enough to indicate that several pages have been customized and they might cause problems after upgrade. There’s even a link provided to convert them to their default. How handy is that? Running the health check is completely optional. SharePoint will run it before it does an upgrade. Running it manually gives you the chance to get the jump on any potential issues you might have before you do the actual upgrade.

If you’re a farm administrator you can use the PowerShell cmdlet Test-SPSite to do the same tests. Of course, because it’s in PowerShell it’s easy to script and loop through many site collections at once. In typical PowerShell fashion, the output isn’t pretty but it’s serviceable. Figure 3 shows an example of what you can expect.

FIGURE 3

Test-SPSite also has an optional parameter, -Rule, that you can use to run an individual rule if you don’t want to run all seven.

After clearing up any health errors, it’s time to see what this site collection will look like with a little SharePoint 2013 shine on it. Unlike SharePoint 2010, you don’t have a Visual Upgrade option. A site collection is either in SharePoint 2010 mode or SharePoint 2013 mode. In place of the Visual Upgrade mode available when upgrading to SharePoint 2010, you now have the option to create upgrade evaluation site collections. When creating an eval site, SharePoint 2013 creates a copy of your SharePoint 2010 site collection and appends its path with “-eval.” You should always upgrade the site collection at the root of a web application first. When you do, its eval site is created at http://webapp/sites/root-eval. Then it upgrades the -eval site to SharePoint 2013. You can use this eval site to see how well the upgrade went and to look for issues. Figure 4 shows the dialog for creating this eval upgrade from the browser. To access this dialog, log into a SharePoint 2010 site collection as a site collection administrator, where you should see a red bar at the top extolling the virtues of upgrading. Clicking the “Start now” option takes you to the upgrade page, where you can click the option to upgrade the site collection or click the Try a Demo Upgrade link on the right to take the upgrade for a test drive. We’ll do that first.

FIGURE 

Clicking the demo upgrade link brings up the dialog shown in Figure 5. You have to love the casual wording in SharePoint 2013. “Before you take the leap” they want you to try the upgrade. How very nice of them. The eval sites are not created immediately. As the dialog says, it will take a day or two before it’s created.

FIGURE 5

Upgrading site collections is a very expensive operation in terms of SQL I/O. Copying an entire site collection and then upgrading it is even worse. To prevent an eval upgrade from making your servers less responsive for normal SharePoint traffic, the eval sites are created by a timer job, which runs once a day at 1:00 a.m. As shown in Figure 6, you’ll get an e-mail when your eval site is ready for you to kick the tires.

FIGURE 6

I don’t know about you, but I’m pretty impatient. I think even Minute Rice takes too long to cook. I certainly don’t want to wait two days for my eval site collection to be created. Fortunately, you can give that eval timer job a kick in the pants and run it before it is regularly scheduled to run at 1:00 am. Each web application has a “Create Upgrade Evaluation Site Collections job” timer job. From Central Admin, select Monitoring ⇒ Review job definitions, find that job, and click the Run Now button in its definition. Figure 7 shows the job definition for web application we’re using for upgrade. Clicking the Run Now button will fire off this timer job, which will start a series of events that results in an -eval site for the root of our upgrade web application.

FIGURE 7

You can also do this in PowerShell. The job’s PowerShell name is “job-create-upgrade-eval-sites,” so some quick PowerShell can filter that out of the list of timer jobs in the farm and execute it. The first line of the following PowerShell will find all the eval site timer jobs in the farm; the second line will execute them:

Get-SPTimerJob | Where-Object { $_.name -eq "job-create-upgrade-eval-sites" } | 
 select name, WebApplication
Get-SPTimerJob | Where-Object { $_.name -eq "job-create-upgrade-eval-sites" } | 
 Start-SPTimerJob

Figure 8 shows this PowerShell masterpiece at work.

FIGURE 8

If you don’t want to run it for all the web applications in the farm, you can filter by web application as well.

After the timer job runs, it will create a copy of your site collection and then run the upgrade process on that copy. The time this will take varies wildly according to the size of the site collection, the makeup of the site collection, and the horsepower of your SQL server.

After the eval site collection is created and you have received your congratulatory e-mail, fire up your browser and take it for a spin. This is your chance to see things the upgrade might screw up. Be sure to test things such as workflows, content types, and fancy SharePoint magic you’ve shown off to your buddies. Those are the kinds of things that will give the upgrade some heartburn.

It’s very important to understand that the eval site is temporary. It will be deleted in 30 days. Don’t do anything in this site collection that you’ll miss. Unlike the Visual Upgrade in SharePoint 2010, you can’t switch back and forth. Continue to use the SharePoint 2010 version of your site collection until you do a proper upgrade. If you prefer to use PowerShell to request an eval site collection, you can use the Request-SPUpgradeEvaluationSite cmdlet.

Eval site collections are typically created by site collection administrators, and they’re the best people to verify that their site collection upgraded correctly. When planning your upgrade, ensure that good documentation is in place specifying who is responsible for testing what. You should also have a list of things to check. Make sure new webs can be created, make sure documents can be uploaded — common tasks like that. In addition, ensure that any third-party software you have is functioning correctly. After you have poked around the eval site and you think everything is in good shape, go ahead and upgrade the site collection to SharePoint 2013.

Site collection administrators can upgrade their site collection by starting the same way they did the eval. Click the link in the red bar or select Site Actions ⇒ Site Settings ⇒ Site Collection Upgrade. Both paths will lead you to the screen shown previously in Figure 4. Instead of clicking the link for the demo upgrade, click the Upgrade this Site Collection link to do the actual upgrade. After you do that, you’re greeted with the friendly dialog shown in Figure 9.

FIGURE 9

Assuming you didn’t click it by accident, click the “I’m ready” button. If you lose your nerve and need to get back to the SharePoint 2010 version, click the “Let’s hold off” button. These buttons have street cred, that’s for sure.

When you click “I’m ready,” your site collection is added to the list of site collections to be upgraded. There’s no one- or two-day waiting time now. Now you’re in the big leagues. The next page you’ll see is shown in Figure 10.

FIGURE 10

You can stay on this page to see the status of the upgrade, or, if you’re impatient like me, you can browse back to the site collection and see the upgrade in action. If you get there quickly enough you might get a page like the one shown in Figure 11.

FIGURE 11

You can see SharePoint swapping out the sprites and generally making a mess of things. It sorts itself out, though. If you wait long enough it turns into a site like the one shown in Figure 12.

FIGURE 12

Now, as tempting as it might be to say, “The front page loaded up, it must be good,” you should investigate further to verify that everything upgraded correctly. After a site collection has upgraded, the Site Collection Upgrade link no longer leads to a page offering to upgrade the site collection. Instead it takes you to a page like the one shown in Figure 13, containing a link to the upgrade status.

FIGURE 13

Clicking Review Site Collection Upgrade Status takes you to a page like the one in Figure 14. It gives you an overview of how the upgrade went. It also includes a link to the upgrade log file for that particular upgrade.

FIGURE 14

If you click the log file link, another tab will appear and an upgrade log file very similar to the ones you saw when you attached your content database will open. Figure 15 shows the first few lines from this site collection’s upgrade.

FIGURE 15

This log, and the logs from any other upgrade operations you’ve done, are stored in a hidden library in the site collection. You can get to it manually by browsing to /_catalogs/MaintenanceLogs/ in your site collection. When you do, you’ll see something similar to Figure 16. These logs are also on the server in the 15 Logs directory. Their names all start with “SiteUpgrade-.”

FIGURE 16

While this upgrade strategy was very clearly planned, with the site collection administrator doing most of the heavy lifting, it can also be done by a farm administrator with PowerShell. The cmdlet Upgrade-SPSite will upgrade a site collection as well. Because the Upgrade-SPSite cmdlet does both build-to-build (b2b) upgrades after a patch and version-to-version (v2v) upgrades as in this situation, you must use the -VersionUpgrade parameter to force PowerShell to upgrade the site collection to SharePoint 2013.

Throttling and Governance

Upgrading site collections is a very expensive operation when it comes to SQL I/O. Nearly the entire process takes place on the SQL server, as it runs stored procedures to make changes in the database. That’s why eval site collection creation is relegated to running in the middle of the night when that burden is felt the least. Because site collection upgrades happen immediately, some other throttles have to be put in place to ensure that the farm isn’t taken down by multiple upgrades happening at the same time. Site collections with less than 10MB in content and fewer than 10 webs are upgraded in the web application app pool. This is throttled to five app pool upgrades per web app. Site collections that are larger than 10MB or have more than 10 webs are upgraded via a timer job. You can adjust these values in PowerShell. They are stored in the SiteUpgradeThrottleSettings property of the web application. Use the following PowerShell to see a web app’s current settings:

(Get-SPWebApplication http://upgrade.contoso.com).SiteUpgradeThrottleSettings

These limits are in place for a reason, so be very careful if you adjust them. Each content database is also throttled to 10 upgrades at the same time, which you can also adjust in PowerShell. Here is the PowerShell to see the current setting:

(Get-SPContentDatabase wss_content).concurrentsiteupgradesessionlimit

As a farm administrator you may want to control some aspects of the upgrade process. Fortunately, there are some other knobs and dials that can be tweaked. Web applications have three properties that apply to upgrades:

• UpgradeEvalSitesRetentionDays — Defines how many days elapse before the eval site collections are deleted by a timer job. By default it’s 31 days.
• UpgradeMaintenanceLink — Creates a link to a custom upgrade maintenance page.
• UpgradeReminderDelay — Enables you to configure how many days a site collection admin can ignore the reminder bar. Its default value is 30 days. If this is set to 0 the reminder bar will say “Upgrade Required” instead of “Upgrade Available.”

While this isn’t strictly an upgrade issue, it is also possible to prevent users from creating fresh SharePoint 2010 mode site collections in SharePoint 2013. Any site collection that is created in SharePoint 2010 mode will eventually need to be upgraded, so preventing this can save you time down the road. Use the following PowerShell to restrict new site collections to only the SharePoint 2013 mode:

$wa = Get-SPWebApplication http://upgrade.contoso.com
$wa.CompatibilityRange = 15
$wa.update()

Not to be left out, the site collection has some PowerShell tricks up its sleeve as well. If you want to prevent site collection administrators from doing the upgrades on their own, you can specify that at the site collection level by setting the AllowSelfServiceUpgrade property to $false. Following is an example of PowerShell you could use to restrict Self Service Upgrade to all the site collections in a database you recently attached:

Get-SPSite -ContentDatabase wss_content_tk_com -Limit All | ForeachObject { 
$_.AllowSelfServiceUpgrade = $false }

After that PowerShell is executed, all the site collections in the content database wss_content_tk_com will have to be upgraded by a farm admin with the Upgrade-SPSite cmdlet. While that sounds like more work, it does have a couple of advantages. First, it can be scripted, resulting in less work to upgrade multiple site collections. The following PowerShell code will walk through a content database and upgrade all the site collections at once:

Get-SPSite -ContentDatabase wss_content_tk_com -Limit All | Upgrade-SPSite -
VersionUpgrade -QueueOnly

The -QueueOnly option puts the upgrade job in the Timer Job queue which gives it some flexibility over where the upgrade takes place and can save time.

Second, Upgrade-SPSite has a parameter, -Unthrottled, that allows the site collection to be upgraded even if the throttling limits have been met. It’s like a first-class ticket that allows your site collection to jump to the front of the queue and be upgraded straightaway.

Once SharePoint upgrade fever has infected your company, it can be easy to lose track of the upgrades in process and the upgrades in queue. Again, PowerShell dons its Superman cape and comes to the rescue. The cmdlet Get-SPSiteUpgradeSessionInfo will report back all the pending upgrades, eval sites, and full upgrades. To remove one from the list, you can use Remove-SPSiteUpgradeSessionInfo.