Productivity solutions

This chapter shifts the focus away from the purely technical aspects of the farm, moving instead toward SharePoint farm users. Each of the solutions covered can comprise a major portion of the user’s day-to-day interaction with SharePoint, including upgrade methods, customizations, and functionality provided within the farm itself to improve productivity and business process.

Skill: Evaluate content and customizations

Implementing a successful migration from one version of SharePoint to another requires a great deal of planning and coordination on the part of the SharePoint administration team. This planning effort will concentrate on the roles and responsibilities required to carry out the four upgrade stages:

• Creating the SharePoint 2016 farm

• Copying databases to the new farm

• Upgrading service applications

• Upgrading the content databases and site collections

The coordination effort concentrates on (1) what other systems will be affected by the upgrade (for example, SQL, Storage, Exchange, Skype, and Infrastructure), and (2) what steps are required to communicate with each of these teams. The level of interaction required with these teams is greatly influenced by how much integration SharePoint 2013 previously had with each of these environments (for instance, existing server-to-server (S2S) protocol trusts, authentication mechanisms, high availability and disaster recovery (HADR), and User Profile service application (UPA) configurations with Active Directory).

This skill pays particular attention to the documentation and verification of the existing farm’s suitability for upgrade, concentrating on the health of the databases, authentication mechanisms, and file systems of the servers themselves.

Perform migration precheck tasks

Before beginning the process of migrating or upgrading the SharePoint 2013 environment, the existing environment must be assessed. This assessment should concentrate on documentation and evaluation efforts.

Documenting the existing farm

When SharePoint implementations are first carried out, documentation that describes the initial state of the farm is usually included. As time passes and farm requirements change, configuration and functional changes are often not captured in updated documentation.

The documentation created for the upgrade effort should be able to capture the current state and interactions of the existing farm, including:

• Server topology and the resulting configuration of service applications and roles

• The resiliency capability at each layer or service of the farm

• Existing S2S relationships with other server types (SharePoint, Exchange, Skype, Office 365)

• Configuration and capacity metrics for web applications and content databases

Evaluating the existing farm

With the documentation effort complete, the results can now be evaluated for upgrade suitability. The evaluation effort allows the upgrade team to determine the current health and upgrade potential of the existing farm, including:

• Current patch state of the farm and content databases

• Orphaned items in content databases

• Compatibility level of site collections in content databases

• Alignment with published boundary, threshold, and supported limits

The eventual result of this effort should be a remediation plan that details steps required to get from the existing farm state to that of a prepared farm migration environment.

Introducing Test-SPContentDatabase

One mechanism for comprehensive evaluation of a content database is to use the Test-SPContentDatabase PowerShell cmdlet. This cmdlet is used to evaluate each content database for use with SharePoint Server 2016 prior to upgrade.

Evaluating a content database for upgrade is always done from the destination system (SharePoint 2016, in this case), and requires the following steps:

• From SQL Server Management Studio

  • Back up a copy of the SharePoint 2013 content database and restore it to the SQL instance used with SharePoint 2016.

• From SharePoint 2016 farm

  • Create a new web application and supporting content database.

  • Match the authentication mode of the SP2013 content database, either classic or claims-mode.

  • Discard the supporting content database (we won’t be using it).

  • Run the Test-SPContentDatabase cmdlet, specifying the SP2013 content database to be tested against the web application. Output the test results to a text file.

As we progress through this chapter, understand that Test-SPContentDatabase cmdlet can indicate (but not correct) issues with the SharePoint 2013 content databases. These corrections are usually carried out on the farm to be migrated (SharePoint 2013) prior to being migrated, although some (such as authentication) can be remedied in the destination environment (SharePoint 2016).

Analyze content database test results

Upgrades to SharePoint 2016 are directly dependent on the state of the underlying content databases; as a result, each content database must be inspected and tested prior to upgrade.

Version status

The version of the SharePoint content database should be inspected from within the SharePoint 2013 environment. When a content database is attached to a SharePoint 2016 environment, the environment reviews the attached content database to obtain its version status. If the version status is not up to the minimum upgradable status, the attachment of the content database will be blocked outright.

Checking a content database for its version status is a fairly straightforward (but commonly overlooked) process, involving only three steps:

1. Determining the farm patch level.

2. Determining if one or more content databases has not upgraded.

3. Determining what the actual schema of the content database is.

From Central Administration on the original SharePoint environment, from System Settings, select Manage Servers In This Farm. The Farm Information items (Figure 4-1) show the configuration database version (the patch level applied to the configuration database, and perhaps the entire SharePoint farm), as well as the configuration database server and name.

Now that the update level for the configuration database has been captured, it can be compared to that of an individual content database. Selecting Review Databases Status from Upgrade and Migration in Central Administration presents the Manage Databases Upgrade Status page. On this page, you will see the content databases (indicated in blue text and hyperlinked) and their current status, as well as the configuration and service application databases.

Note that the screenshot shown in Figure 4-2 shows a status of Database Is In Compatibility Range And Upgrade Is Recommended for the WSS_Content_MeasureMe database, indicating that this database is not currently upgraded to the same level as the other content databases and the configuration database.

Selecting the content database on the Manage Databases Upgrade Status page allows us to inspect the update levels. When the Manage Content Database Settings page opens (partially shown in Figure 4-3), the last line under Database Schema Version indicates two values:

• Microsoft.SharePoint.Administration.SPContentDatabase Current Schema Version This value represents the current SharePoint database schema version for the selected content database.

• Maximum Schema Version Also known as the Maximum SharePoint Database Schema Version, this indicates the current update level of the farm or configuration database.

A current schema version that is lower than the maximum schema version indicates that this content database has not successfully upgraded to the current update level of the farm, whereas a match between these two values indicates that the database has been successfully made current.

SharePoint 2010 site collections

During the process of upgrading to SharePoint 2016, content databases will also be inspected to see if they have any SharePoint 2010 mode site collections (compatibility level 14) requiring upgrade. If these site collections are not upgraded to SharePoint 2013 mode (compatibility level 15), the content database attach will be blocked and not upgraded to SharePoint 2016.

SharePoint 2010 site collections can be identified by using the Get-SPSite PowerShell command and inspecting the compatibility level:

• To test all site collections in a farm:

  Get-SPSite -Limit All | ?  { $_.CompatibilityLevel – eq 14 }

• To test site collections within a specific content database:

  Get-SPSite -ContentDatabase <database name> -Limit All | ?  {
  $_.CompatibilityLevel –eq 14 }

Configure web application authentication for upgrade

In Chapter 1, “Infrastructure,” we discussed the different authentication modes, types, and methods. The authentication types (Windows authentication, forms-based authentication, and Secure Application Markup Language [SAML] token-based authentication) and methods (for Windows authentication only: NTLM, Kerberos, Digest, and Basic) are unchanged from SharePoint 2016.

Authentication mode

The largest change in SharePoint 2016 with regard to authentication has to do with the authentication mode. As was the case with the upgrade from SharePoint 2007 to SharePoint 2010, the upgrade from SharePoint 2010 to SharePoint 2013 didn’t necessarily require that you alter the authentication method in a web application from classic-mode authentication to claims-mode. Unfortunately, this means that there are still SharePoint farm environments in use that do not use claims-mode authentication, even though this configuration is not recommended going forward.

If your environment happens to be among those still using classic-mode authentication and you are planning for the upgrade to SharePoint 2016, you will need to make the conversion from classic-mode to claims-mode authentication to configure the new farm in a supported state.

Converting a web app from classic-mode to claims-mode authentication

Although the process for converting to claims mode isn’t terribly difficult, you have two options to consider. Either:

• Convert SharePoint 2013 classic-mode web applications to claims-based authentication in the SharePoint 2013 farm, then attach copies of these content databases to SharePoint 2016 claims-mode web applications,

or

• Configure SharePoint 2016 classic-mode web applications, attach copies of the SharePoint 2013 classic-mode content databases, and then convert the SharePoint 2016 classic-mode web applications to claims-based authentication.

Resolve orphan objects

Orphaned objects are items in a database that are lacking a hierarchical relationship; for instance:

• Child sites without a reference to a parent site

• Lists or libraries without a site reference

• Apps that are not accessible within a content database

These orphans can be created by any number of causes, including site collections failing to fully provision, incomplete or halted restore operations, features not deploying properly, and so on. Orphans in the content database cannot be reassigned to a reference; thus, they should be deleted from the affected content database.

SharePoint 2013 has two built-in Health Analyzer Rule Definitions (in the Availability category) that help identify these issues prior to upgrade, one of which looks for orphaned apps, and one that looks for all other orphan types. Both of these rules are run on a monthly basis, although you can run them ad hoc before copying a content database.

An alternate solution to allowing the health rule to repair content databases is to use PowerShell cmdlets. This allows you to repair one content database at a time, providing for finer control of this process.

1. Get the content database, assigning it to a variable.

   $cdb = Get-SPContentDatabase -Identity <content database name>

2. Inspect the content database to see if repairs are needed.

   $cdb.repair($false)

   At this point, you should receive output from the SharePoint PowerShell console (Figure 4-4). If the OrphanedObjects count is zero, then the database is ready for upgrade. If there are orphaned objects in the content database, a full backup of that database should be completed before proceeding.

   

   FIGURE 4-4 Verifying that there are no orphaned objects in a content database

3. (Optional) If the content database has orphaned objects, then these must be removed.

   $cdb.repair($true)

Regardless of why these orphans exist, the fact remains that their existence in content databases can prevent the upgrade of a content database from SharePoint 2013 to SharePoint 2016.

Resolve missing file system components

Missing file system components won’t necessarily prevent an upgrade to SharePoint 2016, but they will gladly replicate existing errors and issues found in your SharePoint 2013 farm. Although missing file system components appear on occasion within the Unified Logging Service (ULS) logs of the SharePoint 2013 farm, they are not usually viewed in a group until Test-SPContentDatabase is run from the SharePoint 2016 farm.

Essentially, missing file system components are those needed by solutions, branding, Add-ins (apps), and other components that are referenced in the content database. These file system components are expected on the local drives of the individual SharePoint farm servers, and are obviously missing.

Correcting missing files

A first best effort at correcting these issues is ensuring that solutions, assemblies, and third-party products have been installed in the newly configured SharePoint 2016 farm. Remember that it’s not only possible but sometimes necessary to run the Test-SPContentDatabase cmdlet several times, each time capturing the output of what files a content database is expecting but not receiving.

Removing solutions and features

Solutions and features that are not necessary (or available) in the new SharePoint 2016 environment should be removed prior to copying the SharePoint 2013 content database. This action can have severe consequences in the SharePoint 2013 environment, so a backup of the farm is recommended (including the web applications) prior to the removal of any solution.

Resolve configuration conflict issues

The discussion of configuration conflicts takes us all the way back to the beginning of this section. Documentation that describes the existing SharePoint 2013 environment and its configurations suddenly becomes the focus of our efforts.

This documentation forms the framework that describes the SharePoint farm integration topics such as these:

• Server-to-Server (S2S) connectivity Interactions between the SharePoint 2013 farm and other farms might have resulted in a significant arrangement of trusts between farms on premises (and potentially in the cloud). Each of these S2S relationships will need to be re-created between the new SharePoint 2016 farm and its counterparts.

• Authentication mechanisms Changes in the authentication architecture for the SharePoint 2016 farm might negate the need for certain authentication types. For instance, are external users going to continue to log in via Forms or are they being moved to an Active Directory Federation Services (AD FS)-connected authentication mechanism?

• On-premises secure configurations If your current SharePoint 2013 farm is part of a larger Business Intelligence (BI) infrastructure, it’s likely that Kerberos has been implemented. If this is the case, Service Principal Names (SPNs) must be created in the new environment that allow the existing BI infrastructure to be implemented.

• Moving away from Excel Calculation Services Many organizations make regular use of Excel Calculation Services within their SharePoint 2013 configuration. Excel Calculation Services functionality has been moved away from being a service application and into the Office Online Server configuration (which is an on-premises server product outside SharePoint, superseding existing Office Web Application functionality).

• Business Connectivity Services Any existing Business Connectivity Services (BCS) connections must be re-established within the new environment, including the creation of the appropriate external content types. This configuration might be affected by plans for utilizing BCS services available in Office 365.

• User profile services and application changes In SharePoint 2013, user profile information can be pushed from the SharePoint farm to Active Directory by way of the Forefront Identity Manager (FIM) component found within SharePoint 2013. In SharePoint 2016, this component is replaced by Microsoft Identity Manager 2016 (MIM). It might be desired to move the configuration of the FIM server into MIM to maintain functionality previously available in the SharePoint 2013 farm.

• Load balancer configuration External hardware load balancers are commonly in use with SharePoint 2013 farms. The configuration for the SharePoint 2016 farm will involve re-creating the SharePoint 2013 load balancer configuration, but could change based on the architecture chosen; for instance, changes in topology from traditional to streamlined (MinRole) might affect the configuration.