You should perform a number of tasks before you start a migration. Following best practices, you should—ideally—make a full survey of the current environment before doing any other task. Making a thorough list of all your SharePoint components can help you determine what needs to be cleaned up before migration as well as the steps involved in the migration process. The following items need to be surveyed:

This list is intended to help you determine what needs to be upgraded as well as what items need to be redone on the SharePoint 2013 system (such as blocked file types).

With SharePoint 2010, you could do an in-place upgrade from SharePoint 2007—meaning that you could install SharePoint 2010 on the same server as SharePoint 2007. SharePoint 2013 doesn’t support in-place upgrades, which means that you have to install SharePoint 2013 on a different server from the one on which SharePoint 2010 is installed. For some organizations, this presents additional costs, but some benefits have been gained as well. This was done to separate the process of upgrading the software and databases with the process of upgrading the site collections.

The database-attach method requires that a separate farm be installed and configured before the migration process can begin. After this is accomplished, the databases need to be moved over and upgraded. All content databases can be upgraded, as can some of the service application databases. The following service applications can be upgraded to SharePoint 2013:

After you conduct a thorough survey, you need to clean up your environment (and make any necessary adjustments to the survey). First, you need to remove any underused or unused site collections. As part of the survey, you can determine the sites that are truly needed. Also, if any sites can be archived during this process, you can move them to content databases that can be migrated later (or possibly left on SharePoint 2010 until they have been disposed of). Make sure that you communicate with the site users during this process to ensure that the sites required for reporting, compliance, and other business needs aren’t deleted.

The next stage of cleanup is to manage lists and document libraries. Lists or libraries with a large number of items should be trimmed, if possible. By default, list throttling is turned on in SharePoint 2013 just as it is in SharePoint 2010 and could cause problems if the lists are too large. Plus, now is a good time to look at your lists to see if some of the data can be deleted or archived, thereby speeding up the migration process when it occurs. Additional benefits include speeding up crawl times and decreasing the size of the search index, thus improving the overall quality of searches.

Also consider that lists with a large number of columns can actually cause an upgrade to fail. You can test a content database for this problem by running the following PowerShell command:

Test-SPContentDatabase

You should test all your content databases to ensure that no lists have too many columns. If you do have a list with too many columns, you can remove extraneous columns and run the command again, or you can leave the lists as they are rather than migrate them to SharePoint 2013.

Another potential source of trouble in migration is content databases with too many site collections. SharePoint 2010 had a hard limit of 15,000 site collections per content database and a default warning level of 9,000 site collections; SharePoint 2013 has a suggested limit of 5,000 site collections per content database and a default warning level of 2,000 site collections. If the number of site collections exceeds 5,000 in a content database that will be migrated, it could result in broken site collections and leave you in an unsupported situation. Deleting unneeded site collections is the best way to clean up a content database, but if all the site collections need to be migrated, you should create additional content databases and migrate some of the site collections over to the new databases. The maximum number of site collections per database can be changed, but more than 10,000 site collections isn’t supported. A list of content database supported limits follows:

Large numbers of document versions also can greatly increase the amount of time needed to migrate. Verify that you really need to keep all these versions before you waste precious migration time. Determining which versions to delete can be a large task that’s best handled by governance and some programming. Individually removing versions from hundreds or thousands of lists and libraries can take considerable more resources than are available.

Removing unused items such as features, site templates, and web parts also increases the likelihood of a successful migration. The survey used in the earlier part of this objective can help you determine which of these items are being used. You can use the stsadm command EnumAllWebs to double-check that you aren’t removing a web part or feature that’s actually in use:

stsadm - enumallwebs -databasename <database name> -includefeatures -includewebparts

This command also lists setup files and event receivers associated with the web.

A couple types of sites aren’t supported and must be removed before the upgrade:

Web Analytics also needs to be stopped. The architecture of Web Analytics is different in SharePoint 2013 and doesn’t upgrade. The presence of Web Analytics information in content databases could cause errors during the upgrade.

The preceding pre-check tasks can definitely help prepare you to begin the migration process; it’s your job to make the SharePoint 2010 environment as clean as possible before the upgrade. For example, if the environment had originally been a SharePoint 2007 environment, make sure that all the visual upgrades are finished. This goes for any tasks that might have been left over from the previous upgrade. Deleting or archiving as much data as possible has additional benefits, such as a cleaner search experience and reduced crawl times, and you can save money on storage as well (both for storing the data and the backups).

The preceding section introduced the PowerShell command Test-SPContentDatabase, a tool that helps you determine whether the SharePoint content databases are ready to be migrated. Every content database needs to have Test-SPContentDatabase run against it and any migration-blocking issues resolved. You can run the command against attached and unattached content databases in two ways.

The first way is just against the content database. The full syntax here is followed by a description of the parameters:

Test-SPContentDatabase [-Identity] <SPContentDatabasePipeBind> [-AssignmentCollection
<SPAssignmentCollection>] [-DatabaseCredentials <PSCredential>] [-ExtendedCheck
<SwitchParameter>] [-ServerInstance <SPDatabaseServiceInstancePipeBind>] [-ShowLocation
<SwitchParameter>] [-ShowRowCounts <SwitchParameter>]

The second method of using Test-SPContentDatabase involves testing a web application with a content database. This verifies customizations that are associated with the web application. The only difference in parameters is that Test-SPContentDatabase uses Name instead of Identity, and strings must specify the database name and the WebApplication (which can be the web app’s URL or GUID). The full syntax is as follows:

Test-SPContentDatabase -Name <String> -WebApplication <SPWebApplicationPipeBind>
[-AssignmentCollection <SPAssignmentCollection>] [-DatabaseCredentials <PSCredential>]
[-ExtendedCheck <SwitchParameter>] [-ServerInstance <SPDatabaseServiceInstancePipeBind>]
[-ShowLocation <SwitchParameter>] [-ShowRowCounts <SwitchParameter>]

Example:

Test-SPContentDatabase -Name WSS_Content -WebApplication http://contoso

Test-SPContentDatabase lists all the issues that it found, whether an issue will block an upgrade, the issue’s remedy, and the message of what the issue is. It returns the following items for each issue it finds:

The authentication methods of the web application must match when doing an upgrade. If you are migrating from a claims-based web application, the path is pretty straightforward because the default authentication method in SharePoint 2013 is claims. Running Test-SPContentDatabase on the content database that you want to upgrade can help you determine whether you need to configure the web application before the upgrade. If you need to do additional configuration, one of the issues found by running Test-SPContentDatabase should match the following criteria:

If you are facing this issue, you should upgrade your SharePoint 2010 web application from classic-mode authentication to claims-based authentication before you upgrade. Converting the web application to claims-based authentication while still in the SharePoint 2010 environment allows for testing of claims before the migration and allows for any potential fixes before migration (such as making sure the search application still functions in claims-based mode). Converting it after the database-attach upgrade process is also possible. If for some reason you absolutely need to stick with the classic authentication method, you can create a SharePoint 2013 web application that uses classic authentication.

Converting a SharePoint 2010 web application from classic-mode authentication to a SharePoint 2010 claims-based authentication involves the following steps:

After the web application is converted, it should be fully tested to ensure that the change to a claims-based authentication process was successful. This includes running a full crawl on the search service to ensure that the search account has the proper permissions. Validation of search results should also be done. If everything appears to be in order, migrating the web application to SharePoint 2013 is an easy process—as far as authentication goes.

If you want a SharePoint 2013 web application that uses classic-mode authentication (such as a custom solution that requires classic-mode authentication that can’t be rewritten due to budget and/or time constraints or comes from a third party), use PowerShell. Using classic-mode authentication requires an overwhelming need because claims-based authentication is the preferred method of authentication for SharePoint 2013 going forward. This process, via PowerShell, involves the following steps (when you create a web application via Central Administration, classic-mode isn’t an option):

After creating the classic-mode web application in SharePoint Server 2013, you will see a warning whenever you go to the web application page. This warning indicates that the web application is using the classic-mode authentication. This is to emphasize that claims mode is the preferred authentication mode.

Converting a SharePoint 2013 classic-mode web application to a claims-based web application is a fairly straightforward process. You need to open the SharePoint 2013 Management Shell with the proper permissions and run the following command:

Convert-SPWebApplication -Identity "http:// <servername>:port" -To Claims
–RetainPermissions [-Force]

Again, whenever you switch authentication modes, you should thoroughly test the web application to make sure that nothing permissions-related is broken. This is especially true for any search-related items.

Orphan objects are items that exist in a database but have no reference to an existing item—for example, a site that has no parent site, or a site collection or a document library that has no parent site. Orphaned objects can cause an upgrade to fail because when SharePoint reaches an orphaned item, it doesn’t know where to put it. Orphaned objects can be caused by various reasons, such as the following:

Regardless of how the orphans occurred, they need to be cleaned up before you upgrade. Before you dive into cleaning up the database, you should check your survey information against the list of sites found in each content database to locate missing sites and duplicate sites. You can get a list of all the sites in a content database by using the stsadm command enumallwebs:

stsadm -o enumallwebs -databasename <database name> [-databaseserver <database server
name>]

You also can use the enumallwebs command can to list all the features and web parts, as shown earlier.

After you determine orphaned or duplicate sites (and after you choose which one to keep), you should remove them by using the PowerShell command Remove-SPSite:

Remove-SPSite [-Identity] <SPSitePipeBind> [-AssignmentCollection
<SPAssignmentCollection>] [-Confirm [<SwitchParameter>]] [-DeleteADAccounts
<SwitchParameter>] [-GradualDelete <SwitchParameter>] [-WhatIf [<SwitchParameter>]]

The Identity parameter can be either the URL of the site or the GUID that the enumallwebs command can obtain. The other important parameter to consider when dealing with a production environment is the GradualDelete parameter, which allows for a gradual rather than immediate deletion. A large site or site collection deletion can potentially make a SharePoint farm unresponsive for several minutes (or longer).

SharePoint 2010 provides some additional tools to help you detect and repair orphans. These tools can also help to repair other issues, such as the following:

The available tools are the stsadm command databaserepair and the PowerShell Repair function that exists on database objects. Both tools show the corruption that exists and provide the option of repairing it. Before attempting any database repairs, however, you should always make a backup, as with any operation that changes the database significantly. The first tool to look at is the stsadm command databaserepair:

stsadm -o databaserepair -url <url name> -databasename <database name>
[-deletecorruption]

The deletecorruption parameter is required if you truly want to delete the corruption. Don’t run this command while the database is being used during your company’s usual production hours. You can also delete corruption with the SharePoint 2010 Management Shell (PowerShell). Both options are included here because stsadm and PowerShell coexist; although stsadm eventually will be deprecated, it’s still widely used. The PowerShell method of deleting corruption is done by opening the SharePoint 2010 Management Shell and running the following commands:

$db = Get-SPContentDatabase "<content database name>"
$db.Repair($true)

If you want to use these PowerShell commands just to list the corruption, you would use $db.Repair($false) instead of $db.Repair($true). Use of these tools is highly recommended to remove orphans of various types before beginning the migration process.

Missing files can cause upgrades to fail or, if an upgrade succeeds, can cause sites not to work correctly and pages not to display correctly. SharePoint Server 2013 supports both the SharePoint 2010 experience as well as the SharePoint 2013 experience. It does this by maintaining both a 14 directory and a 15 directory (sometimes referred to as the SharePoint hive or SharePoint folder) under %COMMONPROGRAMFILES%Microsoft SharedWeb server extensions. The SharePoint 2010 files are located under the 14 directory, and the SharePoint 2013 files are located under the 15 directory. This allows for both experiences to exist on the same farm but prevents an in-place upgrade.

All the customizations that you want to keep have to be brought over and installed on the SharePoint 2013 farm. This can cause some confusion over where some files should exist. SharePoint files reside in four main areas:

These four directories will be where missing files need to be placed. Finding out what files are missing is often a difficult task. After installing all the customizations from your SharePoint 2010 farm to your SharePoint 2013 farm, you might want to make some comparisons to ensure that all necessary files were copied over. Luckily, you have tools available, such as Windiff and comp, to help you do this.

comp.exe C:WinntSystem32*.dll \<other computer name>C$WinntSystem32*.dll

When migrating to SharePoint 2013 from a customized SharePoint 2010, you need to be concerned about a number of configuration issues. You can’t simply copy over configurations, and the lack of an in-place upgrade means that all configuration customizations required have to be created on the SharePoint 2013 farm. The survey listed earlier in this objective can help you determine the configuration issues you need to copy over. The following configuration items might present issues:

This list is by no means exhaustive, but it gives you an idea about the kinds and amount of configuration required on a SharePoint farm. Diagnosing the cause of configuration issues can be one of the most difficult tasks in configuring a SharePoint farm. Fortunately, you have diagnostic tools available to help. This section focuses on the SharePoint Diagnostic Studio.

The SharePoint Diagnostic Studio is part of the SharePoint Administrator’s Toolkit. At the time of this writing, the latest version is the SharePoint 2010 Administrator’s Toolkit, which also works well with SharePoint 2013. The toolkit includes the following tools:

After you install the SharePoint 2010 Administrator’s Toolkit, you can run reports and get diagnostic information by following these steps:

After you connect to the server, you can run a number of reports to help determine configuration issues. For instance, you can click Failed User Requests in the Availability section under Reports to determine which users have tried to access the SharePoint server and failed. This could show you that the authentication method in use isn’t configured correctly. Another useful report in figuring out configuration issues (as well as other issues) is the ULS Trace Issues report. This displays the ULS (Universal Logging Service) items in a grid-like format and can help diagnose a wide range of issues, including configuration issues.

Some issues, such as IIS configuration, are best tackled through the use of proper documentation. This is also true for SSL configurations, but SharePoint Diagnostic Studio can help you with this by identifying failed https requests. Tools can definitely help with identifying issues, but they can’t always help with solving the issues, especially customizations such as forms-based authentication or third-party claims authentication methods.

Answer the following questions to test your knowledge of the information in this objective. You can find the answers to these questions and explanations of why each answer choice is correct or incorrect in the “Answers” section at the end of this chapter.

Part of your migration process might include the removal of servers on the SharePoint 2010 farm so that they can be used in the SharePoint 2013 farm. This strategy would enable the gradual transition of content to the new server farm.

SharePoint servers shouldn’t just be turned off. You need to remove the SharePoint 2010 servers in a way that allows the farm or farms to function as long as necessary for your organization’s requirements. Several tasks might be involved in the removal process, such as the following:

The most important issue to consider is keeping all the services necessary for SharePoint to function correctly to be running on at least one server at all times. This generally means turning on a service on a server before turning it off on another server. Central Administration is one service that must be functioning at all times for SharePoint to be functional. Luckily, Central Administration can be running on any server in the SharePoint farm and can even be on multiple servers at the same time.

psconfig.exe -cmd adminvs -provision -port <port number>
             -windowsauthprovider onlyusentlm

psconfig.exe -cmd adminvs -unprovision

The upgrade path to SharePoint 2013 requires the use of the database-attach upgrade method. This process can take a long time, especially if you are upgrading one database at a time. Luckily, content databases can be upgraded in parallel. Before looking at the process of configuring a parallel upgrade, you should look at the different phases of the upgrade process. The process typically follows this order:

Notice that the content databases should be upgraded after the service applications. Database upgrades are a resource-intensive process, but enabling them to proceed in parallel can decrease the amount of time it takes. The number of databases that can be upgraded in parallel depends on the type of hardware being used.

Content databases are attached to a web application. If you have more than one content database that needs to be attached to the web application, the one that contains the root site collection needs to be the first one attached. A content database needs to be connected to a web application with the following PowerShell command:

Mount-SPContentDatabase -Name <Database Name> -DatabaseServer <Server Name>
-WebApplication <URL>

The act of mounting the database to the web application begins the upgrade of the database to SharePoint 2013. You can monitor the progress of the upgrade by navigating to the Upgrade Status page in Central Administration. After you upgrade the first content database and verify its success, you can begin the parallel upgrade of the remaining content databases. To perform parallel upgrades of the content databases, follow these steps:

The speed of the parallel upgrades depends on the hardware capabilities of the servers involved and the databases being upgraded. Upgrading very large content databases individually is advisable because the parallel upgrade process can result in a slower upgrade experience. If you plan to upgrade many content databases at the same time, you should monitor the performance on both the SQL Server instance where the databases are being upgraded and the SharePoint server where the database upgrade is initiated. The following factors can affect the speed of the upgrade process:

Migrating content in a production environment is a tricky process that takes careful planning and scheduling to minimize the impact on production as well as keep people from losing any work. The loss of work can be minimized by making the content databases read-only before they are migrated. A communication plan should be in place to let users know before the content databases are made read-only so they can prepare by saving their work ahead of time. Any open documents can’t be saved after the database is made ready-only, which results in lost work unless users save the items to another location.

The method used to make content read-only varies depending on your needs (such as making site collection read-only before making the content database read-only). For example, if you have a huge number of site collections (such as personal sites), you probably want to make just the content database(s) read-only, but if you have a set of heavily used site collections within a content database, you might want to make the site collections read-only first so that the content can be made read-only gradually. Site collections can be made read-only by following these steps:

You can also use PowerShell to set a site collection to read-only:

Set-SPSite -Identity "<URL of site collection>" -LockState "ReadOnly"

Setting a site collection (or a content database) to read-only affects the end-user experience for that content. Many items that allow for addition and/or modification of data are removed from the user interface, to help prevent users from trying to add or modify content. Some items that are removed or disabled are as follows:

If users aren’t warned ahead of time, making a site read-only will most likely result in a lot of confusion because users will see the items as broken and will report them as such. Other items will appear to be available, but the OK button will be disabled. This can cause some concern as well, but at least the functionality is removed so that users won’t get an error. However, some items will display an error message if they are clicked:

Additional error messages appear in other locations. Again, let end users know that such errors might show up and that they aren’t truly errors but are a result of the content being read-only.

To set the entire content database to read-only, you can go through SQL Server. Setting a content database as read-only makes the entire set of site collections contained within as read-only. Follow these steps:

The end-user experience will be similar to that when a site collection is made read-only through Central Administration, so you still need to alert users. After you make a content database read-only, it can be copied safely to the SQL Server instance that’s being used for SharePoint 2013. Attaching a database with the Mount-SPContentDatabase PowerShell command makes the database read-write.

As mentioned earlier, when you attach a content database using the Mount-SPContentDatabase it begins the upgrade process (and hence can’t remain read-only). The content database and all the site collections within are ready to use after the database is attached and upgraded, but it’s still in the SharePoint 2010 user experience. Each site collection needs to be upgraded to the SharePoint 2013 user experience individually. This can be done by the site collection administrators or by the farm administrators.

The SharePoint 2013 farm should be configured before content is upgraded. This helps ensure that the content is ready to use after the upgrade process. The first step after you install SharePoint 2013 on the servers in the farm is to start applying the configuration needed based on the survey information that you gathered earlier during the pre-upgrade datagathering step. Some of the configuration items that need to be reviewed and documented before migrating content databases are as follows:

After the farm is configured with these items, the service applications needs to be configured if they will be upgraded. Service applications require special consideration when being upgraded and need to be addressed individually.

You need to perform a few important steps after the SharePoint 2013 farm is installed. Before you start configuring the service applications, you should install the language packs for SharePoint 2013. Even if you aren’t upgrading the service application, you should install the language packs before you start upgrading any of the content databases. After you install the language packs, you should run the SharePoint Products Configuration Wizard.

After the language packs (if any) are installed, the service applications should be upgraded and/or configured. One of the first steps is to configure the Secure Store Service, which requires that you have the passphrase. If you don’t know the passphrase, you can refresh the key and then back up the Secure Store database. The passphrase is required so that you can use it in the SharePoint 2013 farm.

The next important step has to do with the User Profile service. If you want to upgrade the User Profile Sync database, you need to export the encryption key for the User Profile Synchronization service application. This key is stored separately from the database. This key must be imported into the SharePoint 2013 environment after you upgrade the User Profile service application. This fairly complicated process typically isn’t performed on servers, so the following steps are for the export process:

You should now have an encryption key that can be imported into the SharePoint 2013 farm. After the User Profile databases are upgraded using the database-attach method, you need to import the key into the SharePoint 2013 environment on the server that runs the User Profile Synchronization service (the server that runs the FIM services).

Before you upgrade any content databases, you must upgrade all the service applications that need to be migrated. Any service applications that aren’t being migrated also should be created before the content database upgrades. The following service applications can be upgraded:

The process of upgrading service applications follows a general set of rules for each application. After the service application databases are copied over to the new server, you can perform the following steps to upgrade them:

After the User Profile service application is created, you need to import the encryption key that you exported earlier. The same command, miiskmu.exe, can be used to import it on the SharePoint 2013 server. After you import the encryption key, you can start the User Profile Synchronization service.

A test farm is the best way for you to test the performance of upgrading your content databases. Getting your test farm to be an exact replica of your production farm might not be possible, but you can still get a fairly decent measurement of performance if your SQL Server instance in the test environment is close to the one that will be in production and you’re using actual backups of your content databases. Performance varies greatly for content databases of the same size, depending on how the data is organized. You can’t say that a database that’s twice the size will take twice as long; it could take the same amount of time or go many times longer. The only way to properly determine how long a content database or set of content databases takes to upgrade is to measure how long it takes to upgrade them on a test environment. After you create your test environment, you can start measuring the performance of the upgrades and determine whether actions need to be taken to improve performance before the actual migration.

After you create a test farm and configure it to be as close to production as possible, you can copy over the content databases you want to test by first backing them up and then copying them over to the SQL Server instance to which you want to attach them. Some of the items that you should keep track of are as follows:

The amount of time required to upgrade content databases (whether singly or in parallel) is fairly straightforward because you simply monitor how long it takes.

You should also measure how much disk space is used during the upgrade process; a lot of temp space is potentially used by the paging file, the temp database, and the transaction log on the database that’s being upgraded. You might have to shrink the log file by backing up the database after it’s upgraded and then checking for empty space on both the log file and the data file. Depending on your SQL Server hardware, you could gain significant improvements simply by adding more memory. To monitor CPU and memory usage, follow these simple steps:

To start the Resource Monitor by itself, type resmon.exe in the Start text box. The Resource Monitor allows for some very detailed information about several performance-related items, such as the following:

The Overview tab gives you an overview of all four performance items, as shown in Figure 3-2.

Figure 3-2. Overview tab in Resource Monitor

From the Resource Monitor you can determine what’s causing your bottleneck. In Figure 3-2, physical Memory is topping out at 96 percent. Depending on which operation is using that much memory, you could determine that if you added more memory, performance would increase.

You should test all your scenarios of content database upgrades—and site collection upgrades, if those are to be done as part of the upgrade—to determine how long you can expect the upgrades to take. This helps with user expectations, the amount of downtime, and possible ways to improve performance.

You need to consider many factors when determining an installation sequence for your SharePoint farm. The main factor is whether you plan to use all new hardware or reuse some (or all) of the existing hardware. Three main components must exist before you can start creating or migrating content:

All these components can exist on the same server (a standalone installation), but because this exam is about advanced solutions, assume that at least the SQL Server installation is on a separate server:

You might want to combine these roles if you plan to reuse the SharePoint 2010 servers in your new farm. A whole set of brand-new servers (and the cost of the software that goes on them) can be cost-prohibitive.

As you move content databases and web applications off SharePoint 2010, you can reuse the servers on the SharePoint 2013 farm. The sequence depends on the organization’s needs and the load on each web application. For example, after you move over a heavily used web application, you might decide to allocate a WFE or two to the SharePoint 2013 farm. Whenever you move a server from the SharePoint 2010 farm, you should do a fresh install of the Windows Server software to help keep any setting or DLL conflicts from occurring.

Answer the following questions to test your knowledge of the information in this objective. You can find the answers to these questions and explanations of why each answer choice is correct or incorrect in the “Answers” section at the end of this chapter.

You should run a health check to determine any issues before upgrading a site collection to the SharePoint 2013 user experience. Health checks can be done by the site collection owner. They are also automatically run in repair mode (as covered later in this objective). The pre-upgrade health check examines a site collection by using several health check rules, reports back on the issues that need to be resolved, and (in many cases) suggests how to fix them. Health checks use the following rules:

Before you start using the health check process, make sure that all configurations and customizations have been performed on the SharePoint 2013 farm. Of course, the content database on which the site collection resides must be upgraded to SharePoint 2013 before any health check on the site collections can be performed. To run the pre-upgrade health check on an individual site collection, follow these steps:

When you run the health check, you should see a list of the items that were checked and any issues that need to be fixed. The health check can be run repeatedly so that you can be sure the site collection is ready to be upgraded to the SharePoint 2013 experience.

You can also perform the pre-upgrade health check by using PowerShell. The health check can be run in two modes: test mode and repair mode. If you want to run in test mode, the account running the PowerShell command must have the securityadmin server role on the SQL Server database and the db_owner role on the content databases that are being analyzed. The account must also be a site collection administrator or be given the full read permission. The following PowerShell command performs the health check in test mode:

Test-SPSite -Identity <SiteURL> [-Rule <RuleID>]

The RuleID is available if you want to run the command for just an individual rule. If the Rule parameter isn’t specified, all the rules are applied.

You can also run the pre-upgrade health check in repair mode. The account running the health check in repair mode must also have the same rights as running the health check in test mode except that it needs to be a site collection administrator or have full control over the site collection being analyzed. The syntax for the PowerShell command to run the health check in repair mode is as follows:

Repair-SPSite -Identity <SiteURL> [-Rule <RuleID>]

If it can, repair mode tries to repair the issues that it finds (such as unghosting a file and setting it to the default). When a site has all its issues resolved, it can be upgraded to an evaluation site or directly to the SharePoint 2013 user experience.

The pre-upgrade provides information on the issues that it found that will affect the upgrade as well as a way to correct them in some cases. Running the health checks in the site settings of the site collection by clicking Start Checks displays the lists of issues it found, grouped by the rule that found it. For some of the items, you are given an option to fix it. For instance, in the Customized Files section of the report, you could see a line such as the following:

http://contoso/search/Pages/default.aspx - Reset page to default

Reset Page To Default is a link that can be used to ghost the file (set it to default). Simply clicking that link takes you to the Reset To Site Definition page (see Figure 3-3), where you are given the option of resetting that one page or resetting all the pages in the site to the site definition version.

Figure 3-3. Reset To Site Definition section

Choosing the Reset All Pages In This Site To Site Definition Version option causes you to lose all the customizations, and you can’t get them back unless you retrieve them from the original SharePoint 2010 site.

A customized page isn’t a serious issue because it affects only that one page. The look and feel of the page might be affected depending on the level of branding and customization, but it won’t stop the upgrade. However, you might discover some other issues that can cause your site collection not to function. One issue that the health checker looks for is conflicting content types. SharePoint 2013 has many new content types that might conflict with ones that were created in your SharePoint 2010 sites. A typical example of this would be the Video content type, which is used in SharePoint 2013 for better multimedia support but is also one that many organizations might have created. Having two content types with the same name would cause issues. This type of issue could even affect the site’s functionality. To rename the existing site content type, follow these steps:

In the health check report, you can click Tell Me More to get additional information that can help to resolve these issues. Whenever you make changes that affect the health check issues, you should rerun the health check to verify that you’ve solved all your issues.

If you have a missing gallery (such as site columns that could have been corrupted or accidentally deleted), SharePoint 2013 attempts to rebuild it for you when you do the health check. If an error occurs, you might have to delete it and try to rerun the health check to get it repaired. Any custom data in the gallery could potentially be lost. This data can be recovered from the SharePoint 2010 site collection, assuming that it’s still available (and not corrupted or deleted).

One rule run by the health checker makes sure that all the content types have parents. If content type is found to be orphaned, you need to do one of the following:

Modifying content types can be done on the Site Settings page by clicking Site Content Types in the Galleries section. Orphans could be the result of accidentally deleting a parent site content type, or perhaps of adding and removing a solution that relied on content types, but the solution not removing cleanly.

The absence of a site template can cause the upgrade to the SharePoint 2013 experience to fail. This might occur for a couple of reasons:

In any case, the absence of a site template needs to be resolved before upgrading to the SharePoint 2013 experience. If for some reason the site template isn’t available, the site needs to be re-created using an available site template. This issue might require the importation and export of data (lists and document libraries) to succeed.

Missing language packs are another issue that must be resolved before a site collection can be upgraded to the SharePoint 2013 user experience. The pre-upgrade site collection health check shows which language packs aren’t available and which must be installed. If the language pack you need isn’t available for some reason, you can’t upgrade until it is available. (Most, if not all, language packs should be available on the Microsoft download site.)

The last health check rule that’s run by the health check tests for unsupported MUI references. The MUI allows for user interface items such as the ribbon, navigation bars, and column headings to appear in the default language of the user’s browser. These issues will probably be similar to those found in the missing language pack rule, but the MUI check might cause additional issues to surface. You won’t be prevented from upgrading to the SharePoint 2013 if issues are found, but the functionality of being able to use multiple languages will be affected until the language pack is found and installed.

By default, site collection administrators are allowed to upgrade their site collections to the SharePoint 2013 experience whenever they want. This might or might not be what your organization wants. Some site collections will need extensive testing before they are upgraded, and the decision of when to upgrade the site collection shouldn’t fall within the site collection administrator’s realm. Sites that might fall under this group might include the following:

Identification of sites that need to be upgraded by the farm administrator should be identified early (before the content database upgrade) to ensure that a site collection isn’t accidentally upgraded to the SharePoint 2013 experience.

When a site collection is available for upgrade, a banner appears at the top of the site collection, indicating that it’s available for upgrade but hasn’t been upgraded (see Figure 3-4).

Figure 3-4. Upgrade option banner on pre-upgraded site collections

The reminder delay and the maintenance link can both be modified using PowerShell commands. Your organization’s needs determine the amount of time and the link to be used and can vary as much as you want. The modifications are at the web application level and are modified by using the following PowerShell commands:

$webApp=Get-SPWebApplication <Web App URL>
$webApp.UpgradeReminderDelay <Value in Days>
$webApp.UpgradeMaintenanceLink='<Link to Maintenance Page>'

The reminder delay is in number of days as indicated in the code. That is the only option available; no option exists for a particular site collection. Remember that only site collection administrators can see the reminder.

Farm administrators can determine the site creation mode for an application as well. The options are to be able to create site collection in 2010 mode, 2013 mode, or allow the site collection administrator to be able to choose either one. The choice depends on your business needs and the schedule of migration to the SharePoint 2013 user experience. You can determine which versions of the SharePoint experience are supported for a web application by using the following PowerShell command:

$webApp=Get-SPWebApplication <Web App URL>
$webApp.CompatibilityRange

You are returned a minimum and a maximum compatibility range as well as the default compatibility level. The SharePoint 2010 experience is compatibility level 14, and the SharePoint 2013 experience is compatibility level 15. Those are your only two choices in SharePoint 2013. If you want to modify the range for a web application, you can do this with PowerShell by specifying a range (RangeName) for a web application. The available RangeName options are as follows:

You can use the following PowerShell commands to limit a web application to either the SharePoint 2010 experience or the SharePoint 2013 experience:

$webApp=Get-SPWebApplication <Web App URL>
$webApp.CompatibilityRange=[Microsoft.SharePoint.SPCompatibilityRange]::<Range Name>
$webApp.Update()

This way, you can limit web applications to just having one of the SharePoint experiences available or switch back to allowing for both SharePoint options available. Going forward, limiting it to just the SharePoint 2013 user experience is probably wise so that the next upgrade will be smoother. Of course, knowing the future is impossible, but keeping your sites as current as possible is always a good idea when looking toward future upgrades.

Part of the planning process for upgrading to the SharePoint 2013 experience involves determining which sites will allow site collection administrators to do self-service upgrades and which sites won’t. By default, self-service version-to-version upgrades are available to site collection administrators, as long as the throttle limits for content haven’t been exceeded. You should use PowerShell to control the self-service ability on site collections if you want to keep site collection administrators from upgrading their site collections themselves. The following PowerShell commands can be used to disable self-service upgrade on an individual site collection:

$site=Get-SPSite <URL>
$site.AllowSelfServiceUpgrade=$FALSE

If this command is run, the site collection in the <URL> parameter will require that the upgrade to the SharePoint 2013 experience be done by the farm administrator. If you want to turn self-service upgrades back on, just replace $FALSE with $TRUE in the preceding command.

If you have many site collections to disable (or enable) for an entire web application, doing so manually would take a long time. You can use piping to enable or disable self-service site collection upgrades via a single PowerShell command. The syntax for disabling an entire collection is as follows:

Get-SPWebApplication "<Web App URL>" | Get-SPSite -Limit ALL | ForEach-Object{ $_.AllowS
elfServiceUpgrade=$FALSE}

The command might take a while, depending on the number of site collections contained within the web application. This command also covers all content databases used by the web application. Depending on your business needs, you might want to turn off all site collections and then turn back on just the ones that you want users to be able to self-service. In any case, this command allows bulk control of version-to-version self-service upgrades.

Generally, you should plan an upgrade to the SharePoint 2013 experience in stages. The default is for everything to be turned on so that site collection administrators can use self-service upgrade. This causes a lot of confusion if end users haven’t had any training, because they will encounter both the SharePoint 2010 and the SharePoint 2013 experiences. This means they will have two different user interfaces to deal with because it’s highly unlikely that all the site collection administrators will decide to upgrade at the same time.

If you have any questions about how your site collection will look in the SharePoint 2013 experience, you should use an evaluation site first. An evaluation site provides a preview of how a site collection will look after it’s upgraded to the SharePoint 2013 experience. Site collection administrators and farm administrators can request an evaluation site.

Requesting an evaluation site for each site collection will end up being quite tedious for most farms, but representative site collections can be evaluated to determine how other sites will look and perform when they are upgraded. An evaluation site leaves the site to be upgraded alone so that you’re in no danger of losing functionality.

An evaluation site is set to expire (and be deleted) after a certain amount of time; the default is 30 days. You can change this value depending on your organization’s needs. An evaluation site is also be deleted when the site collection it’s based on is upgraded to the SharePoint 2013 experience.

Evaluation sites are created by using a snapshot or by using backup and restore, depending on the SQL Server version used by the SharePoint farm. The SQL Server snapshot option is available for SharePoint installations that use either the Microsoft SQL Server Enterprise edition or Microsoft SQL Server Datacenter edition. If another version is used, the backup and restore APIs are used. The main difference is that SQL Server snapshots don’t require an outage, but the backup and restore APIs require that the site collection be made read-only during the backup process, keeping users from writing to the database during the backup process. Users are notified of the read-only status through System Status Notifications.

The creation of evaluation sites can be a resource-intensive process, using up valuable SQL Server disk space as well as CPU and memory resources. By using PowerShell, farm administrators can determine whether site collection administrators can request an evaluation site collection. This is done at the site collection level via the SPSite object. You can use the following PowerShell syntax to disable the ability to request an evaluation site collection:

$site=Get-SPSite <URL of site collection>
$site.AllowSelfServiceUpgradeEvaluation=$FALSE

If a site collection can have an evaluation site, its site collection administrator can request an evaluation site by following these steps:

The evaluation site collection is put into a queue, and the site collection administrator is emailed when the evaluation site is available. The request is added to the timer job Create Upgrade Evaluation Site Collection, which is run once daily (between 1 AM and 1:30 AM locally, by default). This means that up to 24 hours can pass before the evaluation site collection is available. One Create Upgrade Evaluation Site Collection timer job is created per web application, so if you want to change the timer job to create a more responsive experience, you need to modify all the timer jobs for each application. The changes required depend on your business needs and can vary per web application.

Farm administrators can request evaluation site collections by using the PowerShell Request-SPUpgradeEvaluationSiteCollection command. The account requesting the evaluation site collection needs the following permissions:

The syntax for the PowerShell command to request an evaluation site collection is as follows, where the URL of the site collection refers to SharePoint 2010 site collection that you want to evaluate:

Request-SPUpgradeEvaluationSiteCollection -Identity <URL of site collection>

Giving site collection administrators the ability to upgrade site collections to the SharePoint 2013 user experience can take a large load off farm administrators by allowing site collection administrators to determine when a site collection is ready to be upgraded. When the site upgrade process is initiated, a job is created and placed in a queue, even if the process starts immediately. The job is removed from the queue when it is finished or has failed. If the job is stopped midstream for some reason, such as hardware failure or service unavailability, the job is restarted as soon as the timer service can start it.

Farm administrators can manage the queue. Sites can be added, removed, or manually upgraded. Each web application has its own queue, and farm administrators can view the sites in each queue for each content database associated with the web application. To manage the site collection upgrade queue, the account being used should have the following permissions:

After the necessary permissions are validated, farm administrators can use PowerShell commands to control the queue. To view all the site collections (those in progress, those completed, and those failed) in the queue for a content database, use the Get-SPSiteUpgradeSessionInfo PowerShell command:

Get-SPSiteUpgradeSessionInfo -ContentDatabase <Content Database Name>
                             -ShowInProgress -ShowCompleted -ShowFailed

If you want to see the sites now being processed, use just the ShowInProgress parameter and leave off the others. To see whether a site collection is now in the queue, use the Get-SPSiteUpgradeSessionInfo command by passing it the URL of the site to be queried, as follows:

Get-SPSiteUpgradeSessionInfo -Site <URL of site>

You can add site collections to the queue manually by using the PowerShell command Upgrade-SPSite. You might want to do this for several reasons. For example, if you’ve turned off self-service upgrades, you need to add the site collections to the queue manually. If you have a site that you want to upgrade but the throttle limit has been exceeded, you can override the throttle with the command and allow for the site collection to be upgraded sooner that it would be otherwise.

Be aware of a couple of considerations when using Upgrade-SPSite:

The syntax for adding a site collection to the upgrade queue using the PowerShell command Upgrade-SPSite is as follows:

Upgrade-SPSite <URL of site> -VersionUpgrade -QueueOnly

The absence of the QueueOnly parameter causes the upgrade process to start immediately. If you want to put all the site collections for a web application into the upgrade queue, you can use the piping feature of PowerShell.

After a site collection is moved to the queue, it can be removed with the following PowerShell command:

Remove-SPSiteUpgradeSessionInfo -Identity <URL of site>

You might want to use this command if you’ve added a lot of site collection upgrades by using piping but want to remove a few site collections from the list, such as ones that might have lots of customization and need more testing or will take a very long time to upgrade. Doing so might save a lot of typing time. If you use this method, put it all in a script so that it can be run all at the same time.

The process of upgrading site collections to the SharePoint 2013 experience can consume significant server resources, such as disk space, CPU, and memory. To minimize the impact that upgrading can have, farm administrators can throttle the number of site collections that can be in the upgrade queue at any specific time by upgrading the site collection manually; farm administrators can also override this manually by starting an upgrade with the Unthrottled parameter.

Farm administrators can use PowerShell to view the throttle settings of a web application. The SiteUpgradeThrottleSettings property of the SPSite object returns the throttle values of the site:

$webApp=Get-SPWebApplication <web app URL>
$webApp.SiteUpgradeThrottleSettings

The results from running these PowerShell commands should look similar to the following results:

AppPoolConcurrentUpgradeSessionLimit : 5
UsageStorageLimit                    : 10
SubwebCountLimit                     : 10
Name                                 :
TypeName                             : Microsoft.SharePoint.Administration.
                                       SPSiteUpgradeThrottleSettings
DisplayName                          :
Id                                   : a3097994-1acb-4947-9979-7889d6305e1d
Status                               : Online
Parent                               : SPWebApplication Name=SharePoint - 80
Version                              : 722459
Properties                           : {}
Farm                                 : SPFarm Name=SharePoint_Config
UpgradedPersistedProperties          : {}

A lot of data is listed here, and what’s being throttled isn’t readily apparent because throttles are built in at the web application, content database, and content levels. The following list shows the items and their default values:

That three different throttle options are available can provide for tricky scenarios because the most restrictive throttle will win out. For example, if you have one web application, one WFE, and one content database, you could process only five concurrent version-to-version upgrades at one time, assuming that they were all under the content-level throttle threshold. Most site collections will exceed the content throttle threshold because 10 MB is a very low limit for a site collection, and ten subsites is also a low limit for most production site collections (except for personal sites).

Throttle settings can be set in two areas: in the web application and in the content database.

The first area is the web application, where you can set the limits for concurrent session, storage, and subsites by modifying the property values of the SPSite object. The properties related to throttling are as follows:

You can use PowerShell to change these limits, but keep in mind that version-to-version upgrades can consume considerable resources. SharePoint might even become non-responsive if the load becomes too heavy. The syntax for changing the properties is shown in the following PowerShell script, where <value> is an integer:

$webApp=Get-SPWebApplication -URL <URL of web application>
$webApp.SiteUpgradeThrottleSettings.AppPoolConcurrentUpgradeSessionLimit=<value>
$webApp.SiteUpgradeThrottleSettings.SubwebCountLimit=<value>
$webApp.SiteUpgradeThrottleSettings.SubwebCountLimit=<value>
$webApp.Update()

If site collection administrators exceed the throttle settings for the AppPoolConcurrentUpgradeSessionLimit, the version-to-version upgrades are placed in the queue and processed when a spot becomes available. If the SubwebCountLimit or UsageStorageLimit is exceeded, a farm administrator must perform the upgrade via PowerShell; otherwise, the throttle limits must be changed. Content-level throttles prohibit self-service upgrades, and only a farm administrator can upgrade the site collections that exceed the throttle limits.

The second area where throttling can occur is with the content database. Each content database can have its own throttle rule that works with the web application throttle limits. If a content database has a lot of site collections or if you want to minimize the effects of upgrades, you should consider modifying the throttle from the default of 10. The appropriate throttle limit is best determined by performing thorough throttle testing in a test environment that’s close to the production environment.

You can view the throttle settings for a content database by using PowerShell commands. The permissions required for the account used for viewing or modifying the throttle limits are as follows:

The number of concurrent sites that can be upgraded is shown by the ConcurrentSiteUpgradeSessionLimit of the SPContentDatabase object. The syntax for the script is as follows:

$db=Get-SPContentDatabase <Database Name>
$db.ConcurrentSiteUpgradeSessionLimit

PowerShell commands can also be used to modify the throttle settings. The syntax is similar to the following:

$db=Get-SPContentDatabase <Database Name>
$db.ConcurrentSiteUpgradeSessionLimit=<value>

Content databases, such as the ones that store personal sites, can have thousands of site collections. These content databases should be considered for throttling. Typically, site collections are upgraded in bulk because most users find out at about the same time. The special case of personal sites (SkyDrive Pro locations in SharePoint 2013) is that each individual in the organization is a site collection administrator. Either these users need some training, or the site collections need the version-to-version upgrade performed for them. If you plan to allow self-service upgrades on personal site collections, you want to look at the throttle values on both the content databases and the web applications to make sure that the upgrades don’t affect the overall performance of the SharePoint farm.

Answer the following questions to test your knowledge of the information in this objective. You can find the answers to these questions and explanations of why each answer choice is correct or incorrect in the “Answers” section at the end of this chapter.

In this thought experiment, you were told to decide how to proceed with upgrading to a SharePoint 2013 claims-based authentication web application from a SharePoint 2010 classic-mode authentication web application. You have a couple of options here:

If for some reason you still want to stick with classic-mode authentication, you can create a classic-mode authentication web application using the SharePoint 2013 Management Shell.

In this thought experiment, you were assigned the task of doing an upgrade on several content databases in the shortest amount of time possible. The first step would be to upgrade the content database that contains the root site collection. Second, upgrade the large content database and wait for that process to complete. Third, upgrade the rest of the content databases in parallel. Because they are smaller content databases, they should upgrade in parallel without issue.

In this thought experiment, you were asked to determine what changes were required so that 20 concurrent version-to-version upgrades can occur on the content database where the personal sites are located. Because the farm has four WFEs, the throttle limit is 20 by default for the web application that’s hosting the personal sites. Theoretically, it can support 20, assuming that the requests are spread across the four servers. You might want to increase the number of concurrent session per app pool to account for uneven distribution of self-service upgrade requests though. Two hard limits need to be changed: