Chapter 5. Migrating from SharePoint 2010 to SharePoint 2013

Organizations that have invested in SharePoint technologies over the years and are looking to take advantage of some of the new capabilities of SharePoint 2010 will eventually find themselves considering an upgrade of their content and their services over to the new SharePoint 2013 platform.

Fortunately, the story for upgrading content databases in SharePoint 2013 hasn’t changed much from its 2010 predecessor. That said, planning for upgrade to SharePoint 2013, particularly at the service application level, can be complex, with new PowerShell switches, service application databases, and deprecated options.

This chapter covers upgrade from SharePoint 2010 to SharePoint 2013, discussing content database upgrades and procedures for upgrading service applications as well. Upgrades from earlier versions of SharePoint to SharePoint 2013 are not natively supported, and organizations must first upgrade to SharePoint 2010 before beginning on the 2010 to 2013 upgrade path.

With the introduction of SharePoint 2010 and the service application model, SharePoint 2013 enables you to upgrade these features sets, which can complicate a migration process, so you want to closely examine whether service application functionality is required for migration. In other words, if you don’t have any customizations that you need to keep in SharePoint 2010 service applications, you should instead simply focus on migrating content, because service application migration is the most complex part of the upgrade process.

Microsoft has deprecated NT LAN Manager (NTLM) authentication for use in content web applications for SharePoint 2013. This means that all web application authentication models must be made claims aware in order to take advantage of all the features in SharePoint 2013. This is an extra step of preparation for many organizations that are planning their upgrade and extra effort needed on the source SharePoint farm. There is also full support available for converting web applications in SharePoint 2010 to claims.

It is best practice to create a new web application using windows classic mode in the new SharePoint 2013 environment. After this is done it is possible to attach a windows classic mode content database directly to SharePoint 2013. It is also possible to carry on using this authentication model; however, sites in this content database will not be able to take full advantage of all features in SharePoint 2013, most notably the App Management Service (APPS). When this content database is mounted and tested, it is then possible to go through the steps of converting the content database base to claims-based.

Visual Upgrade in SharePoint 2010 allowed organizations to keep the SharePoint 2007 look and feel during a migration. This model had a few drawbacks, however, as it only simulated a 2007 environment and many branding, features, and solutions that were deployed in SharePoint 2007 would not be compatible in the Visual Upgrade view. With SharePoint 2013, we have SharePoint 2010 mode (14 mode) in addition to the new SharePoint 2013 mode (15 mode). The SharePoint 2010 mode keeps many of the core SharePoint 2010 source files in the environment. As a result, many of the branding and feature solutions that were built for a SharePoint 2010 environment work in SharePoint 2010 mode for SharePoint 2013.

The types of settings that you must configure in advance of a database-attach scenario include the following:

Internet Information Services (IIS) and domain name server (DNS) settings

Host headers

Alternate access mappings

Managed Paths

The benefit of using the database-attach method is the ability to strictly control the content that gets populated into the destination environment. In addition, it gives the enterprise the flexibility to systematically “roll in” content databases and their site collections as needed.

The story as it pertains to content database upgrade has not changed at all in 2013 except in the case of scheduling individual site upgrades via PowerShell, as discussed later in this chapter.

Third-party migration tools: These tools usually do not have limitations as to what versions can be migrated from and also allow for splicing and splitting of site collections and content databases, something not supported in the Microsoft approaches. They also usually handle exceptions better.

STSADM/PowerShell exports or backups/restores: Although STSADM, the command-line tool, can only export or backup/restore to the same version, you can use it to export SharePoint content to a farm of the same version level and then run the upgrade process on that farm. You can use this same concept with database restores as well. Keep in mind that STSADM has been deprecated, but PowerShell commandlets (cmdlets) that allow for backups/restores and exports are also available.

Manual content move: Some organizations simply prefer to build a new SharePoint 2013 environment and then show their users how to move content from the old farm to the new farm. This proves particularly useful if there is a great deal of abandoned or useless data in the older farms.

Determining which approach to use is critical during the planning phase of an upgrade or migration project.

Ultimately, regardless of the method, it is important to upgrade only the content that is actually needed in the new environment. The process of simply removing unnecessary versions of documents could potentially save hours in the upgrade process. Taking the time upfront to determine actual valuable content can save hours of upgrade time as well as resource costs and so on.

The hardware requirements in SharePoint 2013 for standalone servers have increased and, as a result, administrators must take into account greater demand on physical and virtual resources. Creating an environment to test your final production upgrade is critical for many reasons. The most important reason is timing out the duration of your overall upgrade process.

No two content databases are created equally, a concept that comes into play with upgrades. For example, a content database that is exactly 50GB, has 20 site collections with 50 subsites each, and has a document library for each subsite with 100 items in each one takes exponentially longer to upgrade than a content database that is 50GB, has 1 site collection and 1 document library, and only a handful of items in that library.

The SharePoint upgrade process must iterate through all these sublevels of the content database and process each item for upgrade. As a result, there is no set way to determine the length of time an upgrade of a content database will take.

This also comes into play when the environment’s available resources differ from one environment to another. If during the upgrade testing process the environment used has less computing power or less RAM available, the time to upgrade a given database is affected. Therefore, when it becomes crucial to know exactly how long a given content database will take to upgrade (for example, a large database must be upgraded and traffic pointing to it before the 8 a.m. workday starts), it is imperative to test on hardware/resources as close as possible to final production.

The major software requirements are SQL Server 2012 x64 or SQL Server 2008 R2 x64 with Service Pack 1. Although some organizations might stay with SQL 2008 R2 SP1, the introduction of Microsoft SQL Server 2012 has many enterprises weighing the option of upgrading to this latest version because it provides some significant high-availability (HA) improvements, outlined in Chapter 9, “Managing and Maintaining SQL Server in a SharePoint Environment.”

If you need to manually install prerequisites, such as when there is no Internet access to the system, or you choose to install via a PowerShell script, the following roles and tools are required:

Application server role

Web server (IIS) role

Microsoft .NET Framework version 4.5 Release Candidate (RC)

SQL Server 2008 R2 SP1 Native Client

Microsoft WCF Data Services 5.0

Microsoft Information Protection and Control Client (MSIPC)

Microsoft Sync Framework Runtime v1.0 SP1 (x64)

Windows Management Framework 3.0 RC, which includes Windows PowerShell 3.0

Windows Identity Foundation (WIF) 1.0 and Microsoft Identity Extensions

Windows Server AppFabric

Cumulative Update Package 1 for Microsoft AppFabric 1.1 for Windows Server (KB 2671763)

In SharePoint 2010, the Pre Upgrade Checker tool was deprecated and administrators were left with relying on the tools in PowerShell 2.0. Using PowerShell is the best way to shed light on possible issues that may arise in an upgrade from SharePoint 2010 to SharePoint 2013. If you use the Test-SPContentDatabase cmdlet, PowerShell simulates the result of actually mounting the database to a given web application and reports back any issues that would limit or block an upgrade, as shown in Figure 5.1.

After opening up SharePoint Management Shell (PowerShell for SharePoint) as Administrator, run Test-SPContentDatabase -Name DBNAME -WebApplication http://domain. In this example, DBName is the name of the database you want to test and is currently in SQL, and http://domain is the web application that currently exists in SharePoint.

Planning an upgrade requires the most upfront work in the overall upgrade process. Running through various test mounts, clearing issues in the source database, and running more test database mounts will result in an overall smooth upgrade when it comes time to actually perform the upgrade in production. Note that ignoring errors during the test mount of a database results in greater work after the mount is actually performed. After a database has been populated with references to site definitions that do not exist or solution packages that are not deployed to the new environment, cleaning these references while the site is live carries many risks as well as time restrictions.

One of the most common issues that administrators face when attempting to upgrade their content databases to SharePoint 2013 is the lack of claims-enabled databases in existence, because many organizations have opted instead to deploy SharePoint 2010 using the default, which is non-claims based. Microsoft has subsequently provided guidance on how to convert SharePoint 2010 web applications to claims.

Which method you use to “clean up” the database before the upgrade depends significantly on the issue that is showing in the Test-SPContentDatabase report. How to physically clean these issues out of a content database is entirely specific to each issue that the report identifies. Currently, you cannot successfully clean all potential issues in a few simple quick steps.

Performing the mount is as simple as replacing Test with Mount in the SPContentDatabase cmdlet. Doing so tells SharePoint to start the mount and upgrade process of the database specified. During the mount, SharePoint 2013 provides a percentage complete status indicator. After a successful or unsuccessful database mount, the final output is shown after the process has failed or succeeded, as shown in Figure 5.2.

In SharePoint 2013, site collections are not upgraded when a content database is upgraded. This process is sectioned into two parts to allow site owners to decide whether and when to upgrade their site collections, as covered later in this chapter.

1. Create a new destination SharePoint 2013 farm complete with all configurations made before attaching any databases. Remember that you need to configure any operational settings such as URLs or host headers as well.

2. Create a web application where the newly upgraded database will reside.

3. Perform an SQL backup of the content database you want to upgrade by going into the SQL instance that supports the 2010 environment, highlighting the database, and right-clicking and selecting Tasks > Backup.

4. When ready to do the actual upgrade, set the database in question to Read-Only in SQL. This allows for the SharePoint 2010 sites that are in that content database to be accessed but not written to or changed in any way.

5. Within SQL, restore the content database you backed up to the SQL instance.

6. Assuming that adequate test mounts have been done to clear any issues that would block a successful and clean upgrade, run the following PowerShell command Mount-SPContentDatabase -Name UnleashedDB -WebApplication http://SharePointUnleashed, where UnleashedDB is the backed-up content database and http://SharePointUnleased is the fully qualified domain name (FQDN) of the web application created in step 2.

Site owners can use the preview mode and view how the SharePoint 2013 mode looks and, more important, how it functions with their site collection. Farm administrators can set the time limit and exceptions on matters that relate to when and by whom the site collection must be upgraded. These parameters include whether the site collection is allowed to be upgraded (if this is disabled, the farm administrator must perform the upgrade) and when reminders and notifications are sent to site owners.

Farm administrators may also choose to perform site collection upgrades immediately after schema upgrade, but a certain amount of risk that is associated with this must be taken into account, such as incompatible features, resource-intensive draw on servers, and so on.

Farm administrators may also control how frequently requested site collections can be upgraded. This is a valuable asset when resources are limited and during peak operation hours.

Here are a few script examples for site collection upgrade.

To upgrade an entire content database and all its site collections, use the following syntax, as shown in Figure 5.3:

Click here to view code image

Get-SPSite -ContentDatabase DBNAMEHERE -Limit All | Upgrade-SPSite –VersionUpgrade

To view upgrades that have completed, use the following syntax, as shown in Figure 5.4:

Click here to view code image

Get-SPSiteUpgradeSessionInfo -ContentDatabase -DBNAMEHERE -ShowInProgress
-ShowCompleted -ShowFailed

To add a site collection to the upgrade queue, use the following syntax:

Click here to view code image

Upgrade-SPSite http://URLHere -VersionUpgrade -QueueOnly

The following databases are supported for upgrade:

Content databases

Sync database

Social database

User profile database

Project databases (All four databases get merged into one in SharePoint 2013.)

Secure store database

Social database

Search admin database

Managed metadata database

Each service application differs slightly depending on which dependencies they have, in addition to their database and their proxy. For most of the service applications, however, the upgrade process is as follows:

1. Create an application pool or declare an existing application pool for the service application.

2. Restore the service application database.

3. Create the service application proxy.

The first step in creating/associating the Managed Metadata application pool consists of running the New-SPServiceApplication Pool cmdlet, as shown in Figure 5.5. This creates a new application pool in your SharePoint 2013 environment.

If you choose to use an application pool currently in use, utilize the following PowerShell script:

Click here to view code image

"$AppPool = Get-SPServiceApplicationPool -Identity "Application Pool Name"

The next step, illustrated in Figure 5.6, is to create the MMS application and restore the managed metadata database (from SharePoint 2010) to the new application pool. Note that if you reference the restored (to SQL) database within the New-SPMetadataServiceApplication cmdlet, the cmdlet automatically uses the 2010 database to build the new service application and upgrade it in the process.

At this point, the newly created MMS application can be seen in Central Administration. We now have to create the proxy for our newly created service application.

Creating the Managed Metadata application proxy is as simple as running the New-SPMetadataServiceApplicationProxy cmdlet. This cmdlet name speaks for itself and does exactly that: creates the MMS proxy. By entering a few required parameters, such as name and service application, you can bind it to the proxy, as shown in Figure 5.7.

After the proxy creation has been completed, navigating through Central Administration displays the newly created MMS application proxy, as shown in Figure 5.8.

In addition, after the service application has been created, the administrator should then be able to navigate the MMS, as shown in Figure 5.9. Upon a successful upgrade, all the content from the previous SharePoint 2010 environment should be available in this structure.

The final step in the process is to change the content type hub URL using the cmdlet shown in Figure 5.10. Note that the cmdlet is showing uri rather than what might seem logical (url).

1. Export the Microsoft Identity Integration Services (MIIS) encryption key (optional).

2. Create the web application for the UPS.

3. Create the UPS.

4. Restore user profile databases to the new SharePoint 2013 farm (sync optional).

5. Import the MIIS encryption key (optional).

It is possible to upgrade the UPS without exporting/importing the encryption key, but the administrator must re-create the sync database manually. This method is much easier and cleaner overall. However, if you choose to use the existing sync database and the resulting encrypting key, you need to complete some preliminary steps to extract this key:

1. To export the existing encryption key, navigate to <root directory drive>Program FilesMicrosoft Office Servers14.0Synchronization ServiceBin on the SharePoint 2010 Server that hosts the Synchronization Service and locate the miiskmu.exe application. Run the miiskmu.exe application and choose the option to export the key set by filling out the credentials that are used to currently run the Synchronization Service and the desired location to save the key to. After doing this, review the summary and finalize the export with the Close button.

2. Navigate to <root directory drive>Program FilesMicrosoft Office Servers14Synchronization ServiceBin and execute miiskmu.exe, as shown in Figure 5.11.

3. Select Export Key Set, as shown in Figure 5.12. This process exports the encryption key currently being used for synchronization.

4. Enter the credentials that run the current 2010 UPS when prompted, as shown in Figure 5.13. This is usually the farm account that was originally used to start the User Profile Synchronization Service.

5. Choose the path to save the file, click Next, and then click Close when the operation completes successfully. The file exports as a .bin file, and it makes no difference where the file is exported to. However, it saves you work later if the file is exported to the new SharePoint 2013 server that runs the UPS and places the file at <Root>Program FilesMicrosoft Office Servers15.0Synchronization ServiceBin.

We cover adding this key back to the new environment later in this section; you should do that last.

Before creating the application pool and UPS, start the UPS in Services on Server. Make sure that you select the server drop-down appropriate for the server on which the UPS will run and where you have set permissions. Then create the new application pool using the New-SPServiceApplicationPool cmdlet, as illustrated in Figure 5.14.

During the creation of the new UPS application, the administrator has the option of defining specific parameters in the cmdlet, as shown in Figure 5.15. These parameters are optional, but in most cases, all are used in a normal upgrade situation, with the exception of -ProfileSyncDBName. If administrators choose to include the sync database, the ProfileSyncDBName parameter is used to reference the SharePoint 2010 SyncDB. When restoring the sync database to the new SharePoint 2013 environment, the build version of the database does not change from when it lived in SharePoint 2010 and when it gets “upgraded” in SharePoint 2013. The upgrade only serves the purpose of placing the database into the farm and making it usable.

After you create it, the new UPS application appears within SharePoint Central Administration.

In PowerShell, the administrator may use piping to insert the output value of a previously run cmdlet. However, if piping is not used in this process, the administrator must directly reference the service application that was created earlier (by globally unique identifier [GUID]) when creating the proxy for that service application. To acquire this GUID, just run the SQL query shown in Figure 5.16, which exposes the GUID needed in the -ServiceApplication parameter.

After recovering the GUID for the UPS application, creating the proxy is similar to creating the proxy for the MMS. However, the Profile Service is referenced in the cmdlet. Figure 5.17 shows a script example for creating a UPS application proxy with the GUID reference previously acquired.

After the service application and proxy has been created, the administrator can view the UPS application proxy, as shown in Figure 5.18.

Note that when you are restoring the MIIS encryption key, this process must be done last, because when declaring the location in which to associate the key, the key assumes that there is a sync database to connect to. If this process is done before restoring (or creating) a sync database, you receive this error: “The operation encountered an error and cannot be completed.”

The next step is to import and connect the encryption key that was previously exported (if you are restoring the sync database) from the SharePoint 2010 environment to the SharePoint 2013 environment. The first step in this process is to copy the key to <Root>Program FilesMicrosoft Office Servers15.0Synchronization ServiceBin.

To do this, open the command prompt and change directory (cd) to the <Root>Program FilesMicrosoft Office Servers15.0Synchronization ServiceBin directory and press Enter. After the directory has been changed, enter the following:

miiskmu.exe /I Path {GUID}

If you do not know the GUID of the encryption key, you can query this in the SharePoint 2010 environment; they are identical when imported into the SharePoint 2013 environment.

Figure 5.19 shows the command-line query used on the SharePoint 2010 server to acquire the GUID of the MIIS encryption key. By pressing Ctrl+C directly within this alert box, the administrator can copy all the text, including the MIIS database key, to the Clipboard for easy extraction in the next step in the process of importing the key.

From the command-line tool on the SharePoint 2013 server, change the directory line to <Root>Program FilesMicrosoft Office Servers15.0Synchronization ServiceBin. miiskmu.exe /I Path {GUID} is being run to inject the key, as shown in Figure 5.20.

After completing these steps, proceed to Services on Server in Central Administration and start the User Profile Synchronization Service.

Figure 5.21 shows the restored SharePoint 2013 UPS application synchronization statistics and information. The last crawl shows from the last successful run when the database lived in the SharePoint 2010 environment.

If the enterprise environment consists of multiple SharePoint 2010 farms where a designated farm serves as the search instance for multiple child instances, each child instance must be reconfigured to point to the new SharePoint 2013 search instance.

In SharePoint 2010, Microsoft included the FAST for SharePoint service application as part of the service application model. In SharePoint 2013, FAST has been integrated directly into SharePoint Server 2013.

Because site collections are upgraded at different times from when a content database is mounted to a web application, the Search service application can be upgraded before site collection-level search centers are fully upgraded. This scenario is known as mixed mode, and until the site collection is fully upgraded to 15 mode, some content features might not be available on the search center.

Having the 14 mode available during the upgrade makes it easier to complete the upgrade. The 14 mode files allow for site functionality to be more or less identical to the way it was in SharePoint 2010, and allows organizations the luxury of indefinitely keeping a site or its features as if they were still native to SharePoint 2010.

Two types of notifications are available when a mode event is triggered (read-only, upgraded, reminder to upgrade, and so on): An email can be sent out, or a dynamic status bar is shown on top of a site in a given mode.

Planning is always overstated, but it really is the best defense against problematic upgrades. As a general rule of thumb, planning should take three times as long as the actual upgrade process itself.

Encourage content owners to review old and stale content. Upgrading data irrelevant or outdated data and archiving such add exponential time to the upgrade process.

Do not assume that upgrading old content (and more specifically, service applications) is the best method. Often, it is much more efficient to reprovision content or service applications.

Reset unghosted sites to standard SharePoint site definitions where possible to ensure consistency across sites.

It is much easier to upgrade the profile and social database for UPS and simply re-create the sync database than it is to restore the sync database to the new SharePoint 2013 environment.

Use 14 mode wisely; it can be a simple and easy transition from SharePoint 2010 to SharePoint 2013. Because of the 14 bits on the server, most customizations work inside the 2013 environment.