Productivity solutions

Skill: Plan an upgrade process

Now that we’ve covered some of the planning and evaluation required for a SharePoint 2016 farm upgrade, we can begin to discuss how the actual implementation might proceed. Consideration at this point should be given to resourcing and which team members might be involved in the creation and migration efforts going forward.

Plan removal of servers in rotation

As more and more users are moved between SharePoint environments (from 2013 to 2016), the user load on the SharePoint 2013 environment will decrease and increase on the SharePoint 2016 environment. Combining this fact with the potential change in topology and need for resiliency, it becomes likely that some SharePoint 2013 servers might be repurposed as members in the SharePoint 2016 farm, if for no other reason than economy.

Prior to removing a server from any SharePoint 2013 farm, it’s a good idea to see what role(s) and services the individual server is hosting. Part of the documentation you are doing for the actual migration comes in handy here, allowing you to ask questions like these:

• What role(s) did the server host (Front end, batch, and so on)?

• Can the availability requirements for certain tiers in the farm be reduced while the migration is taking place?

• Is there more than one server in this tier? If so, how many? Are they configured identically from a services perspective?

• Are there any specialized services or service applications in this tier that require PowerShell configuration before servers can be removed?

As users are migrated, a careful review of performance at each tier (along with answers to the preceding questions) will determine which servers (if any) can be removed from the SharePoint 2013 farm and repurposed.

Specialized services and service applications

At first blush, removing a server from the SharePoint farm might seem straightforward because all you’d have to do is run the configuration wizard and unjoin it from the farm. This most often is not the case, however, as removing the role of the server in the farm might require extra steps to reconfigure:

• Search servers To remove a server from the search topology, you must first clone that topology, remove the server from the cloned topology, and then make it the active topology. Search servers often exist in both the web and application tiers of a traditional topology.

  Need More Review?

  Altering the search topology in SharePoint 2016 isn’t a difficult task, but if done incorrectly, it can cause the loss of the current search index or a failure in SharePoint Search. Prior to making any topology changes, review the TechNet article “Manage the search topology in SharePoint Server 2013” at https://technet.microsoft.com/library/jj219705.aspx.

• User Profile servers Two services are associated with the User Profile service application: User Profile Service and User Profile Synchronization Service. The latter “Sync” service is only installed on one server in the farm, and thus cannot be removed (unless you move this function to a different server in the farm).

  Need More Review?

  As a SharePoint farm administrator, you might not often have the requirement to interact with or alter the User Profile Services or User Profile service application. Reviewing the TechNet article “Overview of the User Profile service application in SharePoint Server 2013” at https://technet.microsoft.com/library/ee662538.aspx will reacquaint you with the concepts required to alter these servers.

• Servers in the distributed cache cluster A single server can provide distributed cache services in a SharePoint farm. A cluster of these servers (3–16 per farm, a two-server installation is not allowed) can also exist. If you have multiple servers in the farm and wish to remove them from the cluster, you can do so via PowerShell. You cannot simply shut down this service from Services on Server, as this does not remove the server from the cluster and will render your farm in an unsupported state.

  Need More Review?

  Removing a server from the distributed cache cluster is done via PowerShell, and can result in a nonfunctioning or unrecoverable configuration if performed improperly. Two major steps are required: Perform a graceful shutdown of the distributed cache service and then remove a server from the cache cluster. Carefully review and understand the TechNet article “Manage the Distributed Cache service in SharePoint Server 2013” at https://technet.microsoft.com/library/jj219613.aspx before proceeding with any change.

• Workflow Manager servers Workflow Manager servers may exist either inside or outside of the SharePoint farm itself. These servers would not be a good option for removal until the farm is being shut down. If you must remove a Workflow Manager server, ensure that the server is made to leave a farm before proceeding.

  Need More Review?

  Workflow Manager is maintained outside the realm of the SharePoint Server farm, although it might exist on a SharePoint server (depending on your existing configuration). Information on how to remove a Workflow Manager server from a farm can be found in the MSDN article “Leaving a Farm” at https://msdn.microsoft.com/library/jj193527(v=azure.10).aspx.

• Office Web App servers If you have multiple Office Web Apps servers in your existing SharePoint 2013 farm, these are optimal servers for refit into Office Online servers for use in your 2016 farm. As these servers are likely behind a load balancer, each could be removed from the load balancer configuration before being removed from the Office Web Apps server farm and then shut down, as only one server is required in the Office Web Apps farm for it to be used with SharePoint (watch your performance characteristics as you remove each server).

Configure a parallel upgrade

Close coordination with your SQL administration team can provide opportunities for improving the SharePoint upgrade process. Working with the storage, storage area network (SAN), and network attached storage (NAS) teams, the SQL admins might be able to provide configurations that provide more processing, I/O, and storage resources. For example, they might be able to temporarily move the storage of your new farm over to a faster set of disks (say, from standard hard drives to solid-state drives [SSD]) to improve upgrade speed.

Upgrading the SharePoint farm, then, is directly dependent on the performance levels of the underlying SQL configuration. It could be that you have a constrained window of time in which to perform your upgrades, so it stands to reason that you take advantage of every possible optimization strategy.

It is likely that, while your SharePoint and SQL environments are upgrading a single content database, they are not fully utilizing the processing, memory, or I/O performance available in the farm. Fortunately, it is entirely possible (and fully supported) to attach and upgrade more than one content database at a time, a concept known as parallel upgrades.

There is no particular configuration requirement for performing parallel upgrades; however, there are a handful of recommendations.

• PowerShell sessions Use a separate PowerShell session to run each content database upgrade, giving you the opportunity to monitor each separately (and monitor the performance levels of the SQL and SharePoint servers performing the upgrade).

• Start times Separate the start time for each new database upgrade session by several minutes, especially when connecting multiple content databases to a single web application. This is necessary to avoid temporary locking, which will cause an error in the upgrade session.

Configure read-only access for content

It could be that your organization has a requirement for allowing users read access to content in your SharePoint 2013 system while you are upgrading to SharePoint 2016. This is actually not a limiting factor, but additional effort will be required to coordinate upgrade schedules with the site collection administrators and business stakeholders associated with a particular content database.

If this configuration is required for your organization, then it’s entirely possible to set an originating (SharePoint 2013) content database to read-only mode, copy it to the SharePoint 2016 environment, and then mount and upgrade the content database.

Prior to the read-only and copy activities, verify the following:

• The account used to copy the databases has access to SSMS on both the SharePoint 2013 and SharePoint 2016 environments (data tier), and has access to a network location accessible by both environments.

• The account used to set the databases to read-only or read-write is a member of the db_owner fixed database role on the content databases that you are upgrading.

• The content databases to be upgraded have been checked for database consistency errors (and repaired, if required).

• The appropriate service pack or cumulative update (CU) has been applied (and the update verified in the content databases) to the SharePoint 2013 environment.

Configure upgrade farms

Although there were three versions of SharePoint 2013 (Foundation, Standard, and Enterprise), SharePoint 2016 only comes in two distinct versions: SharePoint Server 2016 Standard and SharePoint Server 2016 Enterprise. The upgrade path chosen for SharePoint 2016 will depend on the current version of SharePoint in use within your organization.

• SharePoint 2010 and previous SharePoint only allows an upgrade from the immediately preceding version. If your organization is upgrading from an older version of SharePoint to SharePoint 2016, you have two options: perform a step upgrade through previous versions (for example, upgrade to SharePoint 2013 and then upgrade again to SharePoint 2016), or use a third-party tool to extract information from your existing SharePoint environment and restore this information to your new environment.

• SharePoint Foundation 2013 There is no similar product in the SharePoint 2016 product line, so you will use a content database attach upgrade to either a SharePoint 2016 Standard or Enterprise farm.

• SharePoint 2013 Standard Use a content database attach upgrade to SharePoint 2016 Standard and then optionally upgrade the license to SharePoint 2016 Enterprise farm.

• SharePoint 2013 Enterprise Use a content database attach upgrade to a SharePoint 2016 Enterprise farm. Although technically possible, it’s not recommended to migrate from SharePoint 2013 Enterprise to SharePoint 2016 Standard, due to expected solution and feature functionality used in the content databases.

Measure upgrade performance

If you’ve installed SharePoint in an enterprise on-premises setting, it’s likely that you’ve built more than one SharePoint instance (development, staging, production). These environments are used to vet new development efforts, evaluate third-party solutions, and to test configuration and performance changes intended for production.

When it’s time to evaluate an upgrade scenario, you might decide to repurpose the staging environment as a test environment for the new SharePoint farm. This environment usually has the same specifications as its production counterpart, and should be identical from a per-server processor, RAM, and I/O standpoint. If this option is chosen, you might want to add servers to this environment to more accurately reflect the MinRole configuration that will be used in the SharePoint 2016 production environment.

Whether you choose to repurpose or reconfigure the existing staging environment or build a new test environment for your SharePoint 2016 upgrade plans, the fact remains that the resulting environment should perform identically to the eventual SharePoint 2016 production farm.

Storage evaluation

In addition to being memory- and resource-intensive, a SharePoint upgrade can require a significant amount of space. This space is manifested in two separate components:

• Content database growth A content database usually grows in size while the upgrade is taking place, causing growth of the database itself.

• Transaction log growth The matching transaction log can grow significantly during the upgrade process, as backups will likely not yet be configured.

Performance evaluation

Upgrade performance should be evaluated for the entire test farm; however, some metrics will be captured explicitly from the SQL server (data tier), as it commits most of the effort from a resourcing standpoint to the upgrade effort. Environmental and database factors will both heavily influence the captured performance metrics.

Environmental factors that affect the performance of database and site collection upgrades have to do with the physical configuration of servers in the farm, and include the following:

• Simultaneous (parallel) upgrades As we discussed previously, every content database being upgraded requires resources from the SQL server attached to the farm.

• SQL Server disk IOPS The number of input/output operations per second (IOPS) provided by the storage layer to the SQL server has a direct correlation to the upgrade speed of the farm as a whole.

• SQL Server database to disk layout Multiple content databases may occupy the same physical set of disks; optimally, these disks will be spread across multiple I/O channels and sets of disks, thus minimizing the amount of load on any particular set of disks.

• SQL Server temporary database optimizations The TempDB database on the SQL database server itself should be optimized, with the correct number and size of TempDB files.

• SQL Server CPU and memory characteristics Sometimes the SQL data layer servers are on their own server, but sometimes the SQL layer is but a single instance of SQL on a larger SQL database server. The amount of processing power and memory available to the instance has a direct bearing on how transactions are carried out (and databases are upgraded).

• Web server CPU and memory characteristics The rest of the servers in a SharePoint installation have an influence (albeit a great deal smaller) on upgrade performance. As is the case within SQL, the processor and memory characteristics should be configured so as to not bottleneck performance (and slow or halt the upgrade process).

• Network bandwidth and latency While the upgrade is occurring, there will be a considerable amount of communication between the different tiers of the SharePoint server farm. If possible, consider having the intrafarm communications exist on a different virtual local area network (VLAN).

Database factors that affect the performance of database upgrades have to do with information contained within the content database itself, and include the following:

• Site collections Each site collection is itself upgraded as part of the content database upgrade process; if the upgrade of a single database will take too long, consider building another content database in the SharePoint 2013 environment prior to upgrade and move a portion of the site collections to the new database.

• Subwebs As site collections are subject to upgrade, the number of webs contained within the site collection has a direct effect on the upgrade speed for the site collection.

• Lists Lists within SharePoint can contain hundreds, thousands, or more individual items that are part of the upgrade process. Consider working with the site collection administrator to clean large lists if possible.

• Rowspan within lists Lists with a significant number of columns (known as wide lists) cause a phenomenon known as rowspan within the underlying SQL content database.

• Document versions (number and size) Although this is not as significant an issue as when upgrading from SharePoint 2010, upgrades from SharePoint 2013 to SharePoint 2016 nevertheless have to address each major and minor version of a document to be upgraded. Versions retained can be configured via the GUI or via the object model.

• Documents Documents within a SharePoint library can be fairly significant in size and number. Work with your site collection administrator and users to see about removing any outdated or discarded documents. Don’t forget to empty the Recycle Bin for the library itself.

• Links Links function identically to lists, and are subject to the same corrective actions.

Plan an installation sequence

The installation process for a new SharePoint farm is largely unchanged from previous versions. Essentially, the order of installation starts with the data tier and works its way up (even in a MinRole farm):

1. SQL servers This environment is technically configured separately from the rest of a SharePoint environment, but sets the tone for the performance and operation of the entire farm. Items addressed at this level are high availability data recovery efforts and Business Intelligence Services.

2. Application servers Once the SQL server is ready to present a database instance to SharePoint, the next step is to set up application servers. The first server set up in a SharePoint 2016 farm is the de facto Central Administration server (easily changed later if required).

3. Distributed cache servers A SharePoint farm is not valid without at least one distributed cache server present. Remember that if you required resiliency at this tier that a farm with two distributed cache service boxes is not supported, so you must have a minimum of three (or up to 16 total).

4. Search servers Although this MinRole is optional, this grouping of servers should be put in place prior to the Front-end servers if Search is to be required in the farm. The search topology can be configured after the Front-end servers have been configured.

5. Front-end servers The Front-end servers require the least amount of interaction for setup, and would be the last servers required to complete the SharePoint farm.

Migrate SharePoint on-premises to SharePoint Online or a hybrid topology

So far, we’ve been discussing the effort required to upgrade from SharePoint 2013 to SharePoint 2016 on premises. It might be that part of your upgrade strategy is to move portions of the environment to SharePoint Online and leave portions on premises, or you could decide that the entire environment should be moved to the cloud.

This conversation becomes important when talking about migrating an on-premises environment wholly to the cloud, because there might be custom functionality that is not supported by SharePoint Online or Office 365. If this is the case, the good news is that you can host the “custom” part of the environment in Azure; configuration and upgrade functions are identical for this environment to what they are on premises.

The remaining functionality can be hosted in SharePoint Online, and must be migrated from an on-premises environment by some means. This is the same effort as is required for moving certain hybrid content to the cloud.

Content migration mechanisms

Although we could task users with moving content manually (by using Sync for their libraries, and so on), this might not be efficient in the long run, either from an efficiency or accuracy standpoint. Instead, we have a series of migration methods to put content in the cloud:

• Microsoft FastTrack This is a service intended to help push content to the cloud by engaging a Microsoft Partner.

• SharePoint Online Migration API By using the object model, content can be moved from file shares and SharePoint Server sites to SharePoint Online and OneDrive Migration.

• Windows PowerShell cmdlets By using PowerShell cmdlets, content can be moved from file shares and SharePoint Server sites to SharePoint Online and OneDrive Migration.

The SharePoint Online Migration API and PowerShell options are intended for importing files to Office 365 by network upload. Depending on the amount of data, both of these options might be inadequate for an efficient transfer to the cloud.

If this is the case, there is another mechanism available: importing files to Office 365 by shipping drives. There are few requirements for this mechanism, specifically the types of drives and adapters and the requirement for BitLocker encryption.

This mechanism requires a connection to SharePoint Online to gather information and prepare the migration.

1. Download and install the drive preparation tool.

2. Download the SharePoint Online Management Shell.

3. Connect to the SharePoint Online tenant.

4. Get the storage account key.

5. Create a SharePoint Online Migration package manifest and data.

6. Prepare the drives.

7. Prepare a mapping file.

8. Upload the drive files and mapping file.

9. Ship the drives.

10. Enter shipping information in the Office 365 admin center.

Once this effort is complete and Microsoft has received the drive, information can be transferred to your Office 365 tenancy.