In the morning of SPC2012 day 3 I attended the SharePoint 2013 Upgrade Deep Dive by Sean Livingston. This was a part two by Sean who did an Overview on the first day of the conference. Sean started off by showing us a particularly interesting flowchart that depicted the Check Site Collection Health, Request Site Collection Upgrade, and Create Evaluation Site Collection components work.
Compatibility level is the successor to Visual Upgrade which was introduced in SharePoint 2010. Similar to what we saw in 2010, if a site is in SharePoint 2010 or 14 mode then it only has those SharePoint 2010 features. It is not until you upgrade to SharePoint 2013 or 15 mode you will be able to use the newer features. The compatibility level designation is only found on the site collection level and can be found within PowerShell at the following object level SPSite.CompatibilityLevel.
Because both exist it is possible to create both SharePoint 2010 and 2013 site collections. There are some exceptions to this because of deprecated features including:
- Web Analytics
- PowerPoint Broadcast
- Work Group Templates
Also because of this split architecture it is important to note that when installing SharePoint Solutions you will also need to specify which environment this is deploying out to. Options for CompatibilityLevel include:
- 14 – to install in the 14 directory
- 15 – to install in the 15 directory
- “14,15” – installs in both directories
- “AllVersions” or “All” installs in both directories
- “OldVersions” or “Old” installs in the 14 directory
- “NewVersion” or “New” installs in the 15 directory
Another important component is wrapped around the ability for SharePoint 2013 for Site Collection Administrators to upgrade from SharePoint 2010 to 2013. To prevent all 30 Site Collection Administrators from upgrading all at once and taxing your memory and SQL IOPS there is a throttle in place. The upgrade queue will handle 10 upgrades per content database or 5 per web application. It is first come first server when it comes to upgrades. As the upgrades are processed there is a monitor that will allow you to check the progress: Queued, In Progress, Failed, or Success. This is accomplished by using the following command:
Get-SPSiteUpgradeSessionInfo -ContentDatabase -ShowProgress -ShowCompleted
It is possible to adjust the number of upgrades that the queue can handle, which is done at the web application level using the SPWebApplication.SiteUpgradeThrottleSettings.UsageStorageLimit or the SPWebApplication.SiteUpgradeThrottleSettings.SubwebCountLimit object model within PoSH. However a word of warning, only do this if you have an environment with hardware to handle the increase load. SharePoint PoSH also includes the capability of evicting an upgrade that is currently in queue. Also if you do not have Site Collection Administrators that will be doing the upgrade you can as a Farm Administrator run the Upgrade-SPSite for any of the site collections. This command will still honor the database throttling that has been established. The following command will add all site collections all at once:
Get-SPSite | upgrade-spsite -versionUpgrade –QueueOnly
Along with the upgrade throttling there is a Evaluation Site Collection throttling. As a reminder this is the capability of a SharePoint 2010 Site Collection to preview an upgrade to 2013. This create an “Evalulation” copy of the site collection. This process works with SQL server that supports Snapshots, otherwise it will use backup and restore. Besides the throttling, SharePoint 2013 also includes a timer job that will run to put up those in queue and process them. Because this is a copy of the site collection, it will take up more space in the database to ensure there is enough room to handle this overhead. There is also an expiration date of 30 days after creation. This can be changed using PoSH.
Another interesting component for SharePoint 2013 is that when create web applications, the default security is now going to be Claims. This was not true in SharePoint 2010. It is highly recommended that you use Claims since it is a more secure environment, but if you do not currently have Claims setup in your environment it is recommended that you upgrade to Claims prior to migration to SharePoint 2013.
All in all this was a very informative session on the inner workings of the SharePoint 2013 upgrade avenue. I know I will be using doing this more and more in the upcoming months.