Export (0) Print
Expand All

Install a software update (SharePoint 2013)

Published: February 12, 2013

Summary: Learn to install a software update on servers in a SharePoint 2013 farm.

Applies to:  SharePoint Server 2013 | SharePoint Foundation 2013 

Before you begin

Verify the update strategy

Before you start to deploy a software update, verify that the update strategy that you plan to use is optimal for your SharePoint 2013 environment. There are several factors, such as downtime reduction, cost, and complexity that determine the strategy to use to deploy a software update. Use the flowchart in the "Determine Update Strategy" section of Prepare to deploy software updates for SharePoint 2013 to verify the update strategy that you want to use: in-place, database-attach, or a combination.

Monitor installation progress

Monitor the process that deploys updates to verify that the update is proceeding as planned. There may be issues that will block the update or that will result in an updated farm that has elements that do not work as expected. Pay extra attention to database synchronization and customizations.

We recommend that you use the Upgrade and Migration page in Central Administration as the primary tool to view product and patch installation status, data status, and update status in real time.

After Setup runs, you can also view the log files and use Windows PowerShell to obtain the current results of the installation progress.

Handle update failures

SharePoint 2013 can handle upgrade failures after the patching phase finishes. If an update fails, you can restore the SharePoint 2013 database. After you resolve the update issue for the site, you can resume the update. Completed tasks do not run again. For more information, see Test and troubleshoot an upgrade to SharePoint 2013.

Confirm update scenarios

Make sure that you chose an appropriate update scenario. Review the "Determine an update approach" section in Prepare to deploy software updates for SharePoint 2013.

For more information about how the database-attach process works, see the diagrams in Overview of the upgrade process to SharePoint 2013. Note that these articles and other links in this article are about how to upgrade across software versions instead of how to install software updates. However, the general process is similar.

The following illustration shows the farm topology that is used as an example for each patching scenario that is described in this article.

Shows an example of a farm topology for a patching scenario

Initial state and required conditions

The preceding illustration shows the initial state of the farm before you install an update. Verify that the following conditions are true:

  • All the front-end web servers are load balanced together and are in rotation with the load balancer.

  • All the farm servers are operating correctly.

  • All the databases are active and operating correctly.

Do not start the update if any of the preceding conditions are not true. Resolve all issues before you continue.

Use the in-place method without backward compatibility

In this scenario you disable incoming requests to the front-end web servers to shut down the complete farm and then install the update on all the farm servers. This strategy combines the update and the upgrade phase described in the "Software Update Process" section of Software updates overview for SharePoint 2013.

The following illustration shows the sequence of steps to follow to install the update on the farm.

Illustrates how you take each front-end web server offline, patch it and bring back online. Run SharePoint Products Configuration Wizard on each application server, and then run SharePoint Products Configuration Wizard on each front-end web server.

Use the preceding illustration as a guide for to follow the recommended steps in the following procedure.

To install an update without backward compatibility

  1. Remove the web servers (WEB-1 to WEB-4) from rotation in the load balancer, or pause the load balancer to stop incoming requests to the servers.

  2. Run the executable file to install the update on the application server that hosts Central Administration (APP-1).

  3. Run the executable file to install the update on the application server that hosts the search query component (APP-2).

  4. Verify that all the servers were updated successfully by reviewing the Updates.log file.

  5. Log on to the first web server (WEB-1).

  6. Run the executable file to install the update on the web server.

  7. Run the executable file to install the update on the remaining web servers (WEB-2, WEB-3, and WEB-4).

  8. Verify that all the servers were updated successfully.

  9. Run the SharePoint Products Configuration Wizard on the Central Administration server (APP-1) to upgrade the configuration database and upgrade each content database serially.

  10. Run the SharePoint Products Configuration Wizard on the application server that hosts the search query component (APP-2).

  11. Run the SharePoint Products Configuration Wizard on the first web server (WEB-1).

    note Note:

    Run the configuration wizard to ensure that if an update fails for a specific server, the error is not propagated to the other web servers. For example, a failed update for one server could make the update fail for one or more site collections.

  12. Repeat the preceding step for each remaining web server.

  13. Verify update completion and success. For more information, see Verify update completion and success.

  14. Add the web servers (WEB-1 to WEB-4) to the rotation in the load balancer, or start the load balancer to enable incoming requests to the servers.

  15. Notify users that the servers are available.

Use the in-place method with backward compatibility

This scenario takes advantage of the backward compatibility of SharePoint 2013 and the deferred upgrade feature to reduce the downtime that is required to deploy a software update. However, downtime is not completely eliminated. The sites and services will not be available while the database content is being upgraded.

This software update scenario uses two phases to install the update on farm servers. These phases are as follows:

  • Update to install the update on the farm servers.

  • Upgrade to complete the patching process.

During the update phase, the farm can continue to be in production with minimal downtime. However, during the upgrade phase, the farm will be unavailable. If you attempt to access content while the farm is upgrading, the result could be failed upgrades or excessive slowdowns in the upgrade process because of resource contention and locking. Such an attempt is unsupported and untested.

For more information about the software update process, see "The Software Update Process" section in Software updates overview for SharePoint 2013.

Update phase

The following illustration shows the sequence of steps that are required to install the update on the farm.

Illustrates how in-place with backward compatibility method works by take half of web server offline, patch it, bring back online, then repeat same for the remaining web servers. Note, the SharePoint Products Configuration Wizard is not run in this step.

Use the preceding illustration as a guide to follow the recommended steps in the following procedure.

To install the update on farm servers

  1. Remove half of the web servers (WEB-1 and WEB-2) from rotation in the load balancer, or pause the load balancer to stop incoming requests to the servers.

  2. Run the executable file to install the update on each web server that is out of the load-balancing rotation (WEB-1 and WEB-2). Do not run the SharePoint Products Configuration Wizard on either of these servers. Verify that both of the web servers were updated successfully.

  3. Remove the remaining web servers (WEB-3 and WEB-4) from rotation in the load balancer, or pause the load balancer to stop incoming requests to the servers. At this point none of the front-end web servers are receiving requests for the farm.

  4. Add the updated web servers (WEB-1 and WEB-2) back into the load-balancing rotation.

  5. Run the executable file to install the update on each web server that is still out of the load-balancing rotation. Do not run the SharePoint Products Configuration Wizard on either of these servers. Verify that both of the web servers were updated successfully.

  6. Add the updated web servers (WEB-3 and WEB-4) back to the load-balancing rotation.

  7. Run the executable file to install the update on the application server that hosts the search query component (APP-2). Do not run the SharePoint Products Configuration Wizard on this server.

  8. Run the executable file to install the update on the Central Administration server (APP-1). Do not run the SharePoint Products Configuration Wizard on this server.

  9. Verify that both of the application servers (APP-1 and APP-2) were updated successfully.

  10. Verify update completion and success. For more information, see Verify update completion and success.

At this point in the process, the databases and other components such as settings, features, and site-level data must still be upgraded because the SharePoint Products Configuration Wizard was not run on any of the farm servers. However, the farm should be capable of running in backward compatibility mode.

Upgrade phase

The following illustration shows the steps that upgrade the farm servers to finish the patching process. During this process, the sites that are being upgraded will not be available to users.

Steps to use during the upgrade phase of an in-place software update

Use the preceding illustration as a guide to follow the recommended steps in the following procedure.

Important Important:

Monitor the status of the upgrade on each server before you upgrade the next server in the sequence. We recommend that you create a backup of the farm before you begin to upgrade.

The following procedure shows all the steps to upgrade the farm. You can upgrade all components within the same outage window, or you can take some smaller outage windows and upgrade separate parts of the farm at different times. If you want to break up the upgrade stage, you can upgrade the following components in separate outage windows:

  • Services

    If the software update contains updates to services that must be applied, you can upgrade the service, and then resume operating the farm (steps 7 and 8 in the procedure) until it is possible to take a longer farm outage to complete the content and farm upgrade.

  • Content databases

    You can take a short farm outage to upgrade only a few content databases (steps 1 through 3 in the procedure) each time and then resume farm operation (steps 7 and 8). You can repeat the process over successive outage windows until you upgrade all content and the farm servers are ready to be upgraded.

    You can also upgrade individual content databases in parallel for a very small number of content databases at the same time. However, do not attempt to upgrade too many content databases in parallel because it will slow down the overall upgrade process and extend the outage time. We recommend that you do not upgrade more than two content databases on the same SQL Server volume at a time. Start the upgrade for each content database that will occur in parallel several minutes apart to prevent lock contention as the upgrade process starts. In addition, limit the number of content databases that you upgrade on a single web server or application server. Each additional upgrade process will consume a relatively large amount of resources. The typical number of content databases that you can upgrade per web server or application server is four databases. However, be sure not to exceed the number of databases that are being upgraded per SQL Server volume, no matter which web server or application server originates the upgrade.

To upgrade the farm

  1. Remove the web servers (WEB-1 to WEB-4) from rotation in the load balancer, or pause the load balancer to stop incoming requests to the servers.

    Important Important:

    The sites and services will not be available until upgrade is complete and the servers are returned to an active load-balancing state.

  2. Upgrade specific services, as needed.

    Some updates might also require you to run additional Windows PowerShell cmdlets to upgrade specific service applications. Notes for a software update might indicate that you have to upgrade a specific service so that it will continue to operate after patching. This applies to a service that cannot operate in backward compatibility mode, for example.

    You can create a short offline period to upgrade the service without having to upgrade the complete farm. The additional Windows PowerShell cmdlets to upgrade specific service applications should be in the notes if this is required.

  3. Use the Windows PowerShell Upgrade-SPContentDatabase cmdlet to upgrade each content database.

    This is an optional step, but it will help ensure that all content databases are upgraded first. It has the advantage of enabling some parallelism to reduce the outage time. If it is not performed, all remaining non-upgraded content databases will be upgraded serially when you run the SharePoint Products Configuration Wizard to upgrade the farm servers.

    Important Important:

    Run the Upgrade-SPContentDatabase cmdlet for each database. You can run this cmdlet from any of the upgraded web servers or application servers. Note that the content for each database will be unavailable while this process is running on that database.

  4. Run the SharePoint Products Configuration Wizard on the Central Administration server (APP-1).

    Important Important:

    The SharePoint Products Configuration Wizard also starts an immediate upgrade of the configuration database and all other databases that are not already upgraded. Because it is likely that the content databases are the only databases that have already been upgraded, as described in the previous step, all the service application databases are also upgraded in this step. Your sites will not be available while this process runs.

  5. Run the SharePoint Products Configuration Wizard on the remaining application server (APP-2).

  6. Run the SharePoint Products Configuration Wizard on the web servers (WEB-1 to WEB-4).

  7. Verify update completion and success. For more information, see Verify update completion and success.

  8. Add the upgraded web servers (WEB-1 to WEB-4) back into rotation in the load balancer.

Use the database-attach method for high availability of existing content

To ensure high availability for existing content, this scenario uses read-only databases on the existing farm. You install the update on a new farm and route user traffic to the new farm after updates are complete.

The following illustration shows the sequence of steps to follow to install the update on a new farm by using the database attach method. For more information, see Upgrade content databases to SharePoint 2013.

Install a software update using database attach for high availability of existing content

Use the preceding illustration as a guide to follow the recommended steps in the following procedure.

To install the update by using the database-attach method

  1. Create a new farm where you will install the software update. This farm does not require front-end web servers. For more information, see Create the SharePoint 2013 farm for a database attach upgrade.

    note Note:

    If the original farm uses a database mirror, configure mirroring after you deploy the software update on the new farm.

  2. Configure the databases on the existing farm so that they are in a read-only state.

    note Note:

    If the existing farm is mirrored, pause mirroring before setting the databases to read-only.

    For more information about how to configure read-only databases, see the "Set the Previous Version Databases to Be Read-Only (Database Attach with Read-Only Databases)" section in Upgrade content databases to SharePoint 2013 and Run a farm that uses read-only databases in SharePoint 2013.

  3. Configure the service application databases on the existing farm so that they are in a read-only state. This prevents unexpected changes to service applications.

  4. If you are patching the User Profile Service service application database, which is not in SharePoint Foundation 2013, you must export the User Profile Synchronization Service encryption key from the old database and then import the key to the new database. This key is also known as the Microsoft Identity Integration Server (MIIS) key, the Synchronization Service encryption key, and the Forefront Identity Manager 2010 (FIM 2010) key. If you do not export and then import the key correctly, the Synchronization Service will not start. To export the encryption key, complete these steps:

    1. Use farm administrator credentials to log on to the computer that contains the old User Profile Service service application database.

    2. Open the Command Prompt window, and then change to the following folder:

      %Program Files%\Microsoft Office Servers\15.0\Synchronization Service\Bin\

    3. Type the following command, and then press Enter:

      miiskmu.exe /e <Path>

      Where <Path> is the full path of the file to which you want to export the key.

  5. Back up the content databases on the existing farm. For more information, see Plan for backup and recovery in SharePoint 2013.

  6. To import the encryption key, complete these steps:

    1. Use farm administrator credentials to log on to the computer that contains the new User Profile Service service application database.

    2. Attempt to start the User Profile Synchronization service. Because you have not yet imported the encryption key, the service will not start. Confirm that the service did not start by using the ULS log or by making sure that the status of the service is Stopped.

    3. Open the Command Prompt window, and then change to the following folder:

      %Program Files%\Microsoft Office Servers\15.0\Synchronization Service\Bin\

    4. Type the following command, and then press Enter:

      miiskmu.exe /i <Path> {0E19E162-827E-4077-82D4-E6ABD531636E}

      Where <Path> is the full path of the file to which you exported the key.

    5. (Optional) To check that the encryption key was imported correctly, at the command prompt, type the following command, and then press Enter:

      miiskmu.exe /c {0E19E162-827E-4077-82D4-E6ABD531636E}

  7. Restore the content databases to the new database server.

  8. Create service applications on the new farm for each existing service application in the old farm.

    Duplicate all the settings from your existing farm.

  9. Use the database-attach method to create the databases on the new farm. For more information, see Upgrade databases from SharePoint 2010 to SharePoint 2013 and Attach and restore a read-only content database in SharePoint 2013.

  10. Verify that there are no issues with the new farm.

  11. Enable the new farm as the production farm by configuring DNS to point to the new farm or by making sure that the new farm is load balanced. Verify that users can access the new farm.

  12. Allow time for users to switch from cached DNS, and then decommission the old farm.

  13. Verify update completion and success. For more information, see Verify update completion and success.

Verify update completion and success

Regardless of the update strategy that you use and the monitoring that you do during the software update, you must verify update completion and success. For more information, see Verify database upgrades in SharePoint 2013.

Was this page helpful?
(1500 characters remaining)
Thank you for your feedback
Show:
© 2014 Microsoft