Deploying SharePoint Server 2010 updates on mission critical sites
Applies to: SharePoint Server 2010
This article describes a build-to-build upgrade that uses the database attach approach to deploy a software update on a Microsoft SharePoint Server 2010 farm.
In this article:
Introduction
Goals of the update strategy
Database attach conceptual overview
Update phases, guidance, and key tasks
Automation as part of an update strategy
Logical step-by-step approach for a database attach upgrade on a single farm
Logical step-by-step approach for a database attach upgrade on a federated farm
Appendix A. Supported upgrade options
Appendix B. Configuring a SQL Server database as read-only
Appendix C. Guidance for deploying customizations
Appendix D. Techniques for replicating farm content and data
Appendix E. Service application migration reference
Appendix F. Automation resources
Appendix G. Additional Resources
Introduction
During the lifetime of a typical SharePoint Server 2010 environment, one or more software updates will have to be installed, typically in the form of a cumulative update or a service pack. By selecting the appropriate upgrade method, creating a detailed deployment plan, automating by using scripts, and conducting extensive tests, you can make sure that deploying a software update will meet your organization's requirements for availability, user experience, and rollback, should it prove necessary.
This article describes how to deploy a software update on a single farm and on a federated farm using the database attach method for a build-to-build upgrade of the farm servers.
Note
Planning for a build-to-build upgrade is out of scope for this article. We recommend that you refer to Plan and prepare for upgrade (SharePoint Server 2010) for planning guidance.
About software updates
It is important to understand that deploying updates in a SharePoint Server 2010 environment is a two-phase process: patching and upgrading. The term patch is used in this article to differentiate between updating the software and upgrading the software.
Each phase has specific steps and results. It is possible to postpone the upgrade phase but inconsistent farm behavior may result from postponing the upgrade for more than several days. The longer the postponement, the greater the risk is that farm behavior issues will occur.
Patch phase
The patch phase has two steps, the patching step and the deployment step. During the patching step, new binary files are copied to the Central Administration server. Any services that are using files that have to be replaced are temporarily stopped. Stopping services reduces the requirement to restart the server to replace files that are being used. However, there are some instances when you must restart the server.
The second step in the patch phase is the deployment step. In this step, the installer copies support files to the appropriate directories on the server that is running Microsoft SharePoint Server. This step ensures that all the Web applications are running the correct binary files and will function correctly after the update is installed. The update phase is complete after the deployment step.
The next and final phase to deploy software updates is the upgrade phase.
Upgrade phase
After you finish the patch phase, you must complete the update installation by starting the upgrade phase. The upgrade phase is task intensive and, therefore, takes the most time to finish. The first action is to upgrade all the SharePoint Server processes that are running. After the processes are upgraded, the databases are crawled and upgraded. Because the upgrade process can run on a single server, the other servers in the farm can continue to serve requests.
Goals of the update strategy
We recommend the software update strategy that is used in this white paper for SharePoint farms that support mission-critical applications. Mission critical applications are typically defined as applications that are necessity for the normal running of a business. Application unavailability or failure to complete an update within a specific time frame, which is also called a recovery time objective (RTO), significantly affects an enterprise's business. For example, earnings, regulatory requirements, and contractual obligations might be affected.
Our update strategy is designed to meet the following goals and objectives, which are also key indicators of a successful update.
Reduce and manage downtime – The strategy should strive to return full service to users as soon as possible to reduce impact to the users, maintain a high degree of user satisfaction, and meet service-level agreements by managing downtime effectively.
Provide recoverability – If a catastrophic failure occurs during an update, administrators must restore the farm and applications to the pre-update state as quickly as possible to return full service to users.
Provide consistency - After the update, all servers running Microsoft SharePoint Server should be updated to the same version level and have the same configuration. An inconsistent environment will most likely lead to unplanned downtime, bugs, and issues.
Provide expected functionality – After the update, the farm should be in the expected functional state. This includes the functionality that existed before the software update and any new or improved functionality that was expected by installing the service pack or cumulative update.
Database attach conceptual overview
To meet the stated goals and objectives, notably reduced and well-managed downtime, as well as the ability to recover to a pre-update state, you must use the database attach approach. This approach provides the highest level of availability during the software update and the least degree of risk compared to the other supported method, the in-place update.
For more information about upgrade options, see Appendix A. Supported upgrade options, which provides a detailed comparison of the two upgrade methods and a flowchart that captures the decision points that you can use to determine your upgrade approach. This flowchart also provides a high-level view of the steps for installing a software update.
Important
The software update process described in Software update process (https://technet.microsoft.com/en-us/library/ff806329.aspx#updateprocess) highlights a key task that is required for the in-place upgrade and that may be required for a database attach upgrade. You must run the SharePoint Products and Technologies configuration wizard on all the farm servers to finish the update.
Description
The database attach approach involves creating a duplicate of the production farm that will be updated with the service pack and the cumulative update refresh. The new farm, which we'll call bNext (next build), includes the production farm infrastructure, applications, and data. The bNext farm is updated, without content, to the desired build, and then the content databases are attached. The following diagram shows an abbreviated version of the database attach approach, where bCurrent (current build) farm is the existing farm and bNext farm is the copy of the bCurrent farm.
.gif "Install update using database attach")
Referring to the previous illustration, it is important to note that multiple databases can be upgraded in parallel. This capability can significantly reduce the amount of downtime during the upgrade.
Update phases, guidance, and key tasks
The process for a database attach upgrade consists of the following major phases:
Testing the upgrade in a pre-production environment
Provisioning the new farm
Locking down the production farm
Replicating production content and data
Upgrading the new farm with production content and data
Finishing the upgrade on the new farm
Validating the upgrade on the new farm
Restoring full service
Testing the upgrade in a pre-production environment
Before starting the full upgrade it is very import to test all aspects of the upgrade and results in a pre-production environment. After you create the pre-production environment, we recommend that you test the following aspects and elements of the planned upgrade.
Ideally, the farm that is used in pre-production testing is a duplicate of the production farm. However, this is not a mandatory requirement. Typically pre-production farms may not be scaled out to the same extent as a production farm. For example, there might only be two front end Web servers instead of three or four, and the farm databases are not configured to be highly available. The important thing is to have a test environment that is suitable for fully testing the upgrade and its possible effect on the production environment.
Note
If you intend to test only functionality and not performance, then a virtual environment can be used instead of physical computers.
You can use the pre-production farm infrastructure again for the bNext farm. As a best practice, we recommend that the servers that are used for pre-production testing are wiped clean. This includes the operating system. Rebuild them for the new farm. Cleaning off the servers is not mandatory. However, if you choose to re-use the pre-production farm, make sure that you remove all artifacts from the pre-production testing environment. For more information, see Clean up an environment before upgrade (SharePoint Server 2010) (https://go.microsoft.com/fwlink/p/?LinkId=225682).
After you create the pre-production environment we recommend that you test the following aspects and elements of the planned upgrade.
Review the instructions that are provided with the cumulative update or service pack. A software update may contain additional steps or workarounds that are required for the upgrade.
Review your update plan and checklists. Use pre-production testing to validate and adjust your update planning documents. We recommend that you use the Checklist for database attach upgrade (SharePoint Server 2010) article as a guide to deploy a software update.
Test the behavior of the current farm in read-only mode. During the process of moving farm content and service application data to the bNext farm, the existing farm is in a read-only state. Complete functional tests on the existing farm to make sure that the user experience is acceptable during the upgrade. We recommend that you consult the User experience on read-only sites (SharePoint Server 2010) article before locking down the production farm as part of the upgrade planning process.
Use build automation to provision farms. We recommend that you take advantage of automation wherever possible instead of using manual processes to create the pre-production and bNext environments. Automation guarantees configuration consistency across the farm servers and eliminates errors that can be introduced when provisioning servers manually. Test the scripts, tools, and processes that are related to automation.
Use the script collections in Appendix F. Automation resources as guides for developing custom automation for your environment. These scripts use Windows PowerShell 2.0 to deploy SharePoint Server and configure a farm.
Establish a benchmark for downtime window. It is very important that you know how long that it will take to complete the upgrade. The most important element is the time that the production farm will have to be in read-only mode. Use this information to revise your update plan if it is necessary.
Verify the results of the upgrade. Verify that the results of the upgrade are as expected and identify regression bugs that may require a workaround.
Provisioning the new farm
The bNext farm, with the software update installed, is the upgraded version of the current production farm. When you provision the bNext farm, make it a duplicate of the current production environment. This includes, for example, the farm topology, the number of sites, server specifications (physical or virtual), logins, and security settings. We strongly recommend that you do not implement any physical design changes because changes complicate the upgrade and introduce unknowns, which can increase the risk factor for the upgrade.
As was the case with the pre-production environment, we recommend that you use build automation to create and test the bNext farm. Taking advantage of build automation will significantly reduce the possibility of configuration errors and decrease overall build time. In addition, automated testing helps in the discovery of any misconfigurations that might affect the upgrade.
Before proceeding further, conduct tests to verify that the farm configuration is correct before attaching the content database and creating the service applications.
Locking down the production farm
After the upgrade process is tested and the bNext farm built, it is time to put the production environment into a read-only state to complete the upgrade. Locking down the farm guarantees content fidelity by preventing content creation, deletion, or updating on the production farm during the upgrade.
Important
If the farm uses database mirroring, you must pause mirroring before you set the read-only flag on any database.
At a minimum, the content databases must be in read-only mode while the new farm is being upgraded to the same build level. You can also configure a read-only setting to any of the service application databases that support running in read-only mode. For more information, see Appendix E. Service application migration reference.
Note
When a database is set to read-only, all connections except the one that is setting the read-only flag are stopped. The database does not commit pending changes. After the read-only flag is set, other connections are enabled.
For information about how to configure a database as read-only, see Appendix B. Configuring a SQL Server database as read-only.
For information about how to run a read-only Microsoft SharePoint Server farm, see Run a farm that uses read-only databases (SharePoint Server 2010).
Replicating production content and data
To update the bNext farm by using the database attach method, copies of all content databases and service application databases have to be installed on the bNext database server. You must make a backup of the databases on the production farm and then copy the backups to bNext. The next steps are to restore the backups on bNext and then attach them to the database server.
Note
There are other techniques for replicating content and data. For more information, see Appendix D. Techniques for replicating farm content and data.
Upgrading the new farm with production content and data
After the content and service application database backups are copied and restored to the bNext environment’s servers that are running SQL Server, the actual database attach process can occur. Attach and upgrade steps differ from database to database and require slightly different techniques.
Add service applications to the new farm
You will have to use more than one method to add the production farm's service applications to the bNext farm. This is because many service applications have specific requirements for moving the service application or restoring the service application. There is not a single method that works across all service applications. For more information, see Appendix E. Service application migration reference. One of the following methods will enable you to add a service application to the bNext farm.
Database attach – The service application database is created by restoring and attaching the database that is copied from the production farm.
Recreate – The service application is recreated from scratch in the new bNext environment. We recommend that you use automation to migrate settings from the production farm to the bNext farm.
SharePoint backup and restore – The service application is backed up by using Central Administration or Windows PowerShell, and then restored to the bNext farm.
In addition to the content and service application databases, you have to create the following configuration databases again on the bNext farm:
WSS_Search
SharePoint Configuration
SharePoint Admin Content
Add the content database to the new farm
Before you attach the content database to the new farm, make sure that that the target web application to which you will mount the database does not already have site collections with URL paths that collide with site collections in the database that you are restoring. Attach the database using the following steps:
Test the database that you want to mount using the Test-SPContentDatabase cmdlet.
Mount the content database to the target web application by using the Mount-SPContentDatabase cmdlet.
Finishing the upgrade on the new farm
Some tasks that are required for the upgrade can only occur after the databases are attached and active. Some of these steps include (but are not limited to) the following:
Verify the SQL Server configuration - Verify that the required maintenance plans are restored correctly and configured correctly for the bNext farm. For example, check maintenance jobs to maintain statistics and indexes, backup jobs, database mirroring, and so on.
Run profile import - We recommend that you start an incremental import of user profile data to make sure that the profile database is up-to-date and to make sure that profile sync is working correctly in the new environment.
Content crawl - Start an incremental crawl to make sure that the index is synchronized with the upgraded content database and to make sure that crawl is functioning correctly.
Validating the upgrade on the new farm
Functional tests are run against the bNext farm as the final step before redirecting users to the new production farm. These can be manual but we recommend that you use automation which enables more rigorous testing than manual tests. Additionally, automation means that tests are consistent across the farm servers.
We recommend that you use the guidance and troubleshooting steps in the following articles to validate the upgrade:
Restoring full service
When the bNext farm is fully operational and ready to accept user requests, the traffic that is currently being directed to the read-only production farm must be redirected to the bNext farm. We recommend that this redirect be configured at the load-balancer (if applicable). This makes sure that the virtual IP addresses of applications do not change, bypassing the requirement to push out DNS changes to the environment which can take hours to complete for all clients.
Automation as part of an update strategy
Automation can play a key role in deploying software updates in large or complex SharePoint Server 2010 environments. Automated provisioning to servers and farms helps impose build consistency between the current SharePoint Server environments and the new environment that is created as part of the upgrade. In addition to build consistency and error reduction, automation decreases farm build time which will decrease overall environment upgrade time.
An automation solution should include the follow elements:
Infrastructure provisioning – If you are running SharePoint Server 2010 in a virtual environment, this would include creating and provisioning virtual machines, disks, virtual networks, and other infrastructure components of a virtual environment.
Operating system installation and configuration – This includes automatically installing and configuring Windows Server and important updates. Multiple deployment techniques including images that you have prepared to deploy by using the System Preparation Tool (Sysprep), Windows Deployment Services, and scripted operating system configuration can be used to automate provisioning.
Server installation and configuration – After the server is provisioned, SQL Server and SharePoint Server 2010 can be installed and configured. You can use Windows PowerShell 2.0 scripts to install and configure both products. Remember to upgrade these products to the current update version level; which can also be done by using scripts.
Application Migration and Restoration –The final element of automating the bNext farm build is automating the migration and upgrade of databases, final application configuration, and functional testing. When you plan and implement the automation scripts, consider scripts for the following tasks:
Changing the current farm to read-only mode
Changing the current farm back to read/write mode (if upgrade has to be rolled back)
Configuring the load balancer
Installing custom SharePoint Server solutions
Moving databases from the current farm's database server to the upgraded database server
Mounting databases on the bNext farm database server
Functional testing
Automation architecture
The following model shows a layered, conceptual architecture of a SharePoint Server automation solution.
.gif "Architecture for automating software updates")
At the highest level is the SharePoint Server "Workload." A workload represents the logical function of an environment, for example, a .COM web content management workload. The workloads are made up of one or more farms. In the web content management scenario, this might be the production and staging farms. Each farm will have a topology of servers depending on the workload and environment. Finally, the configuration of the servers will require the successful execution of one or more "Build tasks." For example, a build task could be "join server to farm."
If you reduce the target environment to discrete build tasks, you can design and build automation scripts that have limited scope, which makes them much easier to design, build, and stabilize. After you have unit tested a set of build task scripts, you can use them in higher level orchestration scripts or orchestration products such as Opalis, which works with Microsoft System Center. For more information, see the Microsoft Server and Cloud Platform page (https://go.microsoft.com/fwlink/p/?LinkID=186236).
Automation tools and resources
Multiple technology options can automate the deployment and configuration of a SharePoint Server environment. Typically, an automation solution will use a combination of the following techniques.
Windows PowerShell 2.0
Windows Server 2008, SharePoint Server 2010, and SQL Server 2008 all support automation by using Windows PowerShell. Windows PowerShell is a powerful, robust scripting language and runtime which makes it the preferred technology for automation. Windows PowerShell can also use product-specific cmdlets, .NET API calls, and command-line tools.
Command-line tools
Windows Server 2008, SharePoint Server 2010, and SQL Server 2008 also ship command-line tools to enable automated deployment and configuration. However, many command-line options for these technologies are deprecated and replaced with Windows PowerShell cmdlets. (Before you use another command-line tool, determine whether there is a Windows PowerShell option that supersedes the command).
.NET API
Windows Server 2008, SharePoint Server 2010, and SQL Server 2008 use supported APIs, most of which can be accessed by using the Microsoft .NET Framework, to expose product functionality. If a particular product automation capability does not exist as a Windows PowerShell cmdlet or command-line tool, you may be able to use the product APIs to achieve the level of required automation.
Existing script collections
The following script collections can be used to deploy SharePoint Server and to configure a farm. They can be used as is or serve as a guide for developing custom scripts for your environment.
SPModule.zip. The SPModule.zip file is an unsupported sample of a Windows PowerShell module written by members of the SharePoint Product Group. The module can be used to perform simple administrative tasks that are related to installing a SharePoint farm. Download SPModule.zip (https://go.microsoft.com/fwlink/p/?LinkId=229657).
AutoSPInstaller. This project consists of Windows PowerShell 2.0 scripts, an XML input file, and a standard Windows batch file that is used to start the deployment and configuration process. Download the AutoSPInstaller project (https://go.microsoft.com/fwlink/p/?LinkId=229659).
Run book automation
Run Book Automation (RBA) enables you to fully automate the provisioning of a SharePoint Server environment. RBA lets you define, build, orchestrate, manage, and report on the workflows that you create for your system and network operational processes. Orchestration enables you to execute build tasks in a particular order as part of a workflow that can include complex dependency and validation logic. The recommended approach to implement orchestration is to use a product such as Opalis, but other products and techniques can be used for this purpose.
Logical step-by-step approach for a database attach upgrade on a single farm
The farm topology in the following illustration shows a typical three tier farm that provides high availability.
.gif "Three tier SharePoint Server 2010 farm")
Referring to the previous illustration, notice the following:
The two front-end Web servers (WEB-1 and WEB-2) are load balanced together and are in rotation with the load balancer. These servers are running Windows Server 2008 R2, updated to the same version level as the bCurrent farm.
Two application servers (APP-1 and APP-2) are used to provide high availability for search. The third server, APP-3, hosts Central Administration and the service applications. These servers are running Windows Server 2008 R2, updated to the same version level as the bCurrent farm.
The farm database server (DB-1) is mirrored (DB-2) to provide high availability. These servers are running Windows Server 2008 R2 and Microsoft SQL Server 2008 R2, updated to the same version level as the bCurrent farm.
Upgrade steps for a single farm
Our step-by-step approach to deploy a SharePoint update is divided into two parts. The first part addresses the pre-production environment. Tasks in the second part cover the creation and configuration of the new farm (bNext).
The pre-production farm
The following steps describe how to configure the pre-production test farm.
Create a test farm that contains the core components of the production farm topology. Consider using automation for server provisioning and farm deployment. The lessons learned can carry forward to implementing automation for the bNext farm.
For pre-production testing, you only need the minimum number of servers that are required for running tests. Based on the single farm scenario shown in the preceding illustration, the following servers are the minimum required for pre-production testing:
Two front-end web servers. This is the minimum requirement for load balancing.
One application server. If redundancy is not required for testing, you can use this server for Central Administration and all the services that are installed on the production farm.
One database server. If redundancy is not required for testing, a mirrored database server is not needed.
Configure the test farm to match the configuration of the bCurrent farm. Use the following steps as a guide to provision a test farm, and then completing a minimum set of pre-production tests.
Important
You must customize the test topology and tests to reflect your production environment.
Restore a full content backup of the production farm to the test farm. Gather benchmark information, such as elapsed times for copying files or for restoring backups, which can be used to plan the upgrade.
Install a copy of the applications and customizations that are on the production farm. Record any benchmark data that can be used for planning, upgrade, and troubleshooting. For information about customizations, see Determine how to handle customizations (SharePoint Server 2010).
Download a copy of the software update and prepare the installation source. For more information, see Obtain the software update and prepare the installation source (optional). You can use this installation source for pre-production testing and for installing the update on the bNext farm.
Test the software update. Ensure that expected SharePoint Server functionality exists after the software update is installed. That is to say, there are no regression bugs.
Monitor production farm functionality. Monitor the functionality of the production farm when content and service application databases are set to read-only.
Validate processes and tools. Validate the processes for the upgrade and test the tools that are used to automate the upgrade or post-upgrade testing.
The bNext farm
The following steps describe how to provision and configure the bNext farm so that it can be put into production as the new bCurrent farm.
Note
If you reuse the pre-production servers, we recommend that you rebuild the servers from the operating system up. This approach is best to make sure that that there are no test artifacts that may affect the bNext farm SharePoint Server deployment.
Use automation scripts to provision the servers that are required for the bNext farm. In this scenario in this article, this includes the following servers: three-front end Web servers, three application servers, and the farm database server, which is mirrored.
Provisioning includes updating the operating system to at least the same service pack level or software update level as the servers in the production farm. If applicable, and appropriate, apply the latest operating system updates to the bNext servers.
Provision the bNext database server. This includes the following tasks:
Install SQL Server and during setup, configure it to match the settings of the production farm.
Update SQL Server to at least the same version level as the production farm.
Copy the bCurrent logons and permissions to the bNext database server.
Configure the required services, firewall settings, and then verify database functionality.
Important
Do not mirror the primary database until you have run the SharePoint Products and Technologies configuration wizard to complete the farm software update.
Install the SharePoint Server binaries on the bNext servers.
Install SharePoint Server but do not run the configuration wizard.
Install the cumulative update or service pack binaries but do not run the configuration wizard.
Run the SharePoint Products and Technologies Configuration Wizard to create a new farm.
Important
Do not create any service applications. You will create or restore them from backups later in the process.
Complete the following tasks to prepare bNext as a copy of the production farm:
Configure the general farm settings.
Create and configure the web applications.
Copy your custom solutions from the bCurrent farm to the bNext environment. Note any dependencies that may affect the successful deployment of these solutions. For example, there may be a dependency on a service application that does not exist at this point in the farm configuration. For more information, see Appendix C. Guidance for deploying customizations.
Do a full backup of the production farm's databases. This includes the content databases and the service application databases that support SQL Server backup and recovery.
Start taking transaction log backups of the databases described in the previous step. We recommend transaction log backups instead of differential backups for the following reasons:
They minimize work loss exposure.
Because the backup files are smaller, they take less time to transfer over a network. In addition, you can copy the backup files to the bNext farm daily, instead of all at the same time.
File size and design enable you to fully restore the production databases to the bNext farm. For more information, see Working with Transaction Log Backups (https://go.microsoft.com/fwlink/p/?LinkId=152194).
Restore the full backups of the production databases to the bNext SQL Server environment.
Important
Use the NORECOVERY option to restore the backups so that backups of transaction logs can be restored on to the full backups. For more information, see Understanding How Restore and Recovery of Backups Work in SQL Server (https://go.microsoft.com/fwlink/p/?LinkId=134473).
Change the production farm (bCurrent) content database and appropriate service application databases to ready-only mode. Take note of the following points before you lock down the production farm:
Some service applications do not support read-only mode and others, such as Microsoft SharePoint Server Search and Usage and Health Data Collection, will not work if their databases are set to read-only. For more information, see Appendix E. Service application migration reference.
There might be changes to configuration settings and service applications while the farm is locked down. For example, the Search service will not work in read-only mode; therefore it is possible for an administrator to change settings. This change will not be carried over to the new farm. You have to consider and plan for this so that you can minimize the downtime window to reduce the potential for data loss.
When a database is set to read-only, all connections except the one that is setting the read-only flag are stopped. After the read-only flag is set, other connections are enabled.
If the existing farm is mirrored, as is the case with our example farm, you must pause mirroring before setting the databases to read-only. For more information, see Database Mirroring Administration How-to Topics (Database Engine) (https://go.microsoft.com/fwlink/p/?LinkId=225804).
Complete the following tasks to prepare to install Microsoft SharePoint Server Search on the bNext farm:
Use SharePoint backup to take a backup of the search databases and copy these backups to the bNext farm.
Copy the index partitions to the application servers on the bNext farm.
Export the search topology to an XML file, and then copy this file to the bNext database server.
Complete the following tasks to restore Microsoft SharePoint Server Search on the bNext farm:
Unless the bNext servers have the same names as the bCurrent servers, you have to edit the XML file that contains the exported search topology. Edit this file and provide the new server names.
Use the Restore-SPEnterpriseSearchServiceApplication cmdlet to restore search.
Recreate farm services on bNext and, where applicable, associate services with application service databases that are restored from bCurrent backups.
Install the SharePoint custom solutions in the bNext environment.
Important
We recommend installing customizations after the services are recreated because the extent and nature of the customizations may have a dependency on a service.
Complete the following tasks after you install the custom solutions:
Delete all the empty content databases that were created when the web applications were first created on the bNext farm.
Use the Test-SPContentDatabase cmdlet to test content databases against the newly created web applications to make sure that all required customizations are deployed and no issues exist.
Mount the content databases on bNext farm by using the Mount-SPContentDatabase cmdlet.
Important
If there is more than one content database, mount the database that contains the root site collection first.
Upgrade the content databases on the bNext farm by using the Upgrade-SPContentDatabase cmdlet.
After the upgrade is complete, complete the following database server tasks:
Re-establish database mirroring if it was enabled on the bCurrent farm.
Restore and test all the database maintenance jobs.
Start the following SharePoint processes:
Search Crawl
Profile Import
Verify that all the required services are running.
Perform functional tests against the bNext farm to verify that the upgrade was successful. For more information, see Verify upgrade and review upgraded sites (SharePoint Server 2010).
Redirect user requests to the bNext farm. Keep the read-only bCurrent farm in case you have to roll back the upgrade.
Continue testing and monitoring the new bCurrent farm (bNext) during the stabilization period that you defined in the upgrade plan. When you are confident that you will not have to roll back to the previous build, you can delete the old bCurrent farm and recycle the servers so you can use them for other purposes.
Take an inventory of the new farm's configuration so that you have up-to-date information that can be used for future software updates.
Logical step-by-step approach for a database attach upgrade on a federated farm
Installing a SharePoint Server 2010 update on a federated farm requires more preliminary planning than installing an upgrade a single farm. However, the philosophy and fundamental approach to using the database attach method to install an update on a federated farm is the same as for a single farm. Depending on the architecture of the federated environment, the nuances of patching and upgrading farm servers may vary between the farms.
Upgrade order and backwards compatibility
The most frequently asked question about upgrading a federated farm environment concerns the patching order and n-1 backwards compatibility across farms. For SharePoint Server 2010 you can upgrade the federated services farms in either of the following sequences:
Upgrade the provider farm first, and then upgrade the consumer farm
Upgrade the consumer farm first, and then upgrade the provider farm
Known issues with Microsoft SharePoint Server 2010 Service Pack 1 (SP1)
There is the potential for n-1 compatibility issues when patching the services consumer farm first without running the SharePoint Products and Configuration Wizard (psconfig.exe) to upgrade the provider services farm. Potential issues include: the SharePoint Server Search service does not work; the SharePoint Server indexing service does not work; and claims requests do not work for user deployed solutions.
Important
If you choose to upgrade the consumer farm first, we recommend that stay in the n-1 state for a short a time as possible after you patch the consumer farm to SP1. For more information, visit the Updates for SharePoint 2010 Products (https://go.microsoft.com/fwlink/p/?LinkID=209614) site.
Upgrade steps for a federated farm
The federated farm environment shown in the following illustration is used as an example to show the sequence and steps that are required to install a SharePoint Server update across three farms.
.gif "Federated services farm with two consumer farms")
The federated farm in the preceding illustration consists of the following elements:
One federated service provider farm with federated search ("Provider farm" in the illustration)
Two federated consumer farms ("Consumer A" and "Consumer B" in the illustration)
For the purpose of illustration, the provider farm is upgraded first, followed by the two consumer farms.
Before continuing with the upgrade of the services provider farm, we recommend that you familiarize yourself with the information and guidance about pre-production environments and the database attach method that is already provided in this article.
The bNext provider farm
The following steps describe how to provision and configure the bNext provider farm so that you can it put into production as the new bCurrent provider farm.
Use automation scripts to provision the servers that are required for the bNext farm. In this scenario in this article, this includes the following servers: three-front end Web servers, three application servers, and the farm database server, which is mirrored.
Provisioning includes updating the operating system to at least the same service pack level or software update level as the servers in the production farm. If applicable, and appropriate, apply the latest operating system updates to the bNext servers.
Provision the bNext database server. This includes the following tasks:
Install SQL Server and during setup, configure it to match the settings of the production farm.
Update SQL Server to at least the same version level as the production farm.
Copy the bCurrent logons and permissions to the bNext database server.
Configure the required services, firewall settings, and then verify database functionality.
Important
Do not mirror the primary database until you have run the SharePoint Products and Technologies configuration wizard to complete the farm software update.
Install the SharePoint Server binaries on the bNext servers.
Install SharePoint Server but do not run the configuration wizard.
Install the cumulative update or service pack binaries but do not run the configuration wizard.
Run the SharePoint Products and Technologies Configuration Wizard to create a new farm.
Important
Do not create any service applications. You will create or restore them from backups later in the process.
Complete the following tasks to prepare bNext as a copy of the production farm:
Configure the general farm settings.
Create and configure the web applications.
Copy your custom solutions from the bCurrent farm to the bNext environment. Note any dependencies that may affect the successful deployment of these solutions. For example, there may be a dependency on a service application that does not exist at this point in the farm configuration. For more information, see Appendix C. Guidance for deploying customizations.
Do a full backup of the production farm's databases. This includes the content databases and the service application databases that support SQL Server backup and recovery.
Start making transaction log backups of the databases described in the previous step. We recommend transaction log backups instead of differential backups for the following reasons:
They minimize work loss exposure.
Because the backup files are smaller, they take less time to transfer over a network. In addition, you can copy the backup files to the bNext farm daily, instead of all at the same time.
File size and design enable you to fully restore the production databases to the bNext farm. For more information, see Working with Transaction Log Backups (https://go.microsoft.com/fwlink/p/?LinkId=152194).
Restore the full backups of the production databases to the bNext SQL Server environment.
Important
Use the NORECOVERY option to restore the backups so that backups of transaction logs can be restored onto the full backups. For more information, see Understanding How Restore and Recovery of Backups Work in SQL Server (https://go.microsoft.com/fwlink/p/?LinkId=134473).
Change the production farm (bCurrent) content database and appropriate service application databases to ready-only mode. Take note of the following points before you lock down the production farm:
Some service applications do not support read-only mode and others, such as Microsoft SharePoint Server Search and Usage and Health Data Collection, will not work if their databases are set to read-only. For more information, see Appendix E. Service application migration reference.
There might be changes to configuration settings and service applications while the farm is locked down. For example, the Search service will not work in read-only mode; therefore it is possible for an administrator to change settings. This change will not be carried over to the new farm. You have to consider and plan for this so that you can minimize the downtime window to reduce the potential for data loss.
When a database is set to read-only, all connections except the one that is setting the read-only flag are stopped. After the read-only flag is set, other connections are enabled.
If the existing farm is mirrored, as is the case with our example farm, you must pause mirroring before setting the databases to read-only. For more information, see Database Mirroring Administration How-to Topics (Database Engine) (https://go.microsoft.com/fwlink/p/?LinkId=225804).
Complete the following tasks to prepare to install Microsoft SharePoint Server Search on the bNext farm:
Use SharePoint backup to take a backup of the search databases and copy these backups to the bNext farm.
Copy the index partitions to the application servers on the bNext farm.
Export the search topology to an XML file, and then copy this file to the bNext database server.
Complete the following tasks to restore Microsoft SharePoint Server Search on the bNext farm:
Unless the bNext servers have the same names as the bCurrent servers, you have to edit the XML file that contains the exported topology. Edit this file and provide the new server names.
Use the Restore-SPEnterpriseSearchServiceApplication cmdlet to restore search.
Recreate farm services on bNext and, where applicable, associate services with application service databases that are restored from bCurrent backups.
Install the SharePoint custom solutions in the bNext environment.
Important
We recommend installing customizations after the services are recreated because the extent and nature of the customizations may have a dependency on a service.
Complete the following tasks after you install the custom solutions:
Delete all the empty content databases that were created when the web applications were first created on the bNext farm.
Use the Test-SPContentDatabase cmdlet to test content databases against the newly created web applications to make sure that all required customizations are deployed and no issues exist.
Mount the content databases on bNext farm by using the Mount-SPContentDatabase cmdlet.
Important
If there is more than one content database, mount the database that contains the root site collection first.
Upgrade the content databases on the bNext farm by using the Upgrade-SPContentDatabase cmdlet.
After the upgrade is complete, complete the following database server tasks:
Establish database mirroring again if it was enabled on the bCurrent farm.
Restore and test all the database maintenance jobs.
Start the following SharePoint processes:
Search Crawl
Profile Import
Verify that all the required services are running.
Perform functional tests against the bNext farm to verify that the upgrade was successful. For more information, see Verify upgrade and review upgraded sites (SharePoint Server 2010).
Redirect user requests to the bNext farm. Keep the read-only bCurrent farm in case you have to roll back the upgrade.
Continue testing and monitoring the new bCurrent farm (bNext) during the stabilization period that you defined in the upgrade plan. When you are confident that you will not have to roll back to the previous build, you can delete the old bCurrent farm and recycle the servers so you can use them for other purposes.
Take an inventory of the new farm's configuration so that you have up-to-date information that can be used for future software updates.
The bNext consumer farm
The following steps describe how to provision and configure the bNext consumer farm, "Consumer A" in our example, so that it can be put into production as the new bCurrent consumer farm.
Use automation scripts to provision the servers that are required for the bNext farm. In this scenario in this article, this includes the following servers: three-front end Web servers, three application servers, and the farm database server, which is mirrored.
Provisioning includes updating the operating system to at least the same service pack level or software update level as the servers in the production farm. If applicable, and appropriate, apply the latest operating system updates to the bNext servers.
Provision the bNext database server (CADB-1, CADB-2). This includes the following:
Install SQL Server and during setup, configure it to match the settings of the production farm.
Update SQL Server to at least the same version level as the production farm.
Copy the bCurrent logons and permissions to the bNext database server.
Configure the required services, firewall settings, and then verify database functionality.
Important
Do not mirror the primary database until you have run the SharePoint Products and Technologies configuration wizard to complete the farm software update.
Install the SharePoint Server binaries on the bNext servers.
Install SharePoint Server but do not run the configuration wizard.
Install the cumulative update or service pack binaries but do not run the configuration wizard.
Run the SharePoint Products and Technologies Configuration Wizard to create a new farm.
Important
Do not create any service applications. You will recreate or restore them from backups later in the process.
Complete the following tasks to prepare bNext as a copy of the production farm:
Configure the general farm settings.
Create and configure the web applications.
Copy your custom solutions from the bCurrent farm to the bNext environment. Note any dependencies that may affect the successful deployment of these solutions. For example, there may be a dependency on a service application that does not exist at this point in the farm configuration. For more information, see Appendix C. Guidance for deploying customizations.
Do a full backup of the production farm's databases. This includes the content databases and the service application databases that support SQL Server backup and recovery.
Start making backups of transaction logs of the databases described in the previous step. We recommend backups of transaction logs instead of differential backups for the following reasons:
They minimize work loss exposure.
Because the backup files are smaller, they take less time to transfer over a network. In addition, you can copy the backup files to the bNext farm daily, instead of all at the same time.
File size and design enable you to fully restore the production databases to the bNext farm. For more information, see Working with Transaction Log Backups (https://go.microsoft.com/fwlink/p/?LinkId=152194).
Restore the full backups of the production databases to the bNext SQL Server environment.
Important
Use the NORECOVERY option to restore the backups so that backups of transaction logs can be restored on to the full backups. For more information, see Understanding How Restore and Recovery of Backups Work in SQL Server (https://go.microsoft.com/fwlink/p/?LinkId=134473).
Change the production farm (bCurrent) content database and appropriate service application databases to ready-only mode. Take note of the following points before you lock down the production farm:
Some service applications do not support read-only mode and others, such as Microsoft SharePoint Server Search and Usage and Health Data Collection, will not work if their databases are set to read-only. For more information, see Appendix E. Service application migration reference.
There might be changes to configuration settings and service applications while the farm is locked down. For example, the Search service will not work in read-only mode; therefore it is possible for an administrator to change settings. This change will not be carried over to the new farm. You have to consider and plan for this so that you can minimize the downtime window to reduce the potential for data loss.
When a database is set to read-only, all connections except the one that is setting the read-only flag are stopped. After the read-only flag is set, other connections are enabled.
If the existing farm is mirrored, as is the case with our example farm, you must pause mirroring before setting the databases to read-only. For more information, see Database Mirroring Administration How-to Topics (Database Engine) (https://go.microsoft.com/fwlink/p/?LinkId=225804).
Complete the following tasks to prepare to install Microsoft SharePoint Server Search on the bNext farm:
Use SharePoint backup to make a backup of the search databases and copy these backups to the bNext farm.
Copy the index partitions to the application servers on the bNext farm.
Export the search topology to an XML file, and then copy this file to the bNext database server.
Complete the following tasks to restore Microsoft SharePoint Server Search on the bNext farm:
Unless the bNext servers have the same names as the bCurrent servers, you have to edit the XML file that contains the exported topology. Edit this file and provide the new server names.
Use the Restore-SPEnterpriseSearchServiceApplication cmdlet to restore search.
Recreate farm services on bNext and, where applicable, associate services with application service databases that are restored from bCurrent backups.
Install the SharePoint custom solutions in the bNext environment.
Important
We recommend installing customizations after the services are recreated because the extent and nature of the customizations may have a dependency on a service.
Complete the following tasks after you install the custom solutions:
Delete all the empty content databases that were created when the web applications were first created on the bNext farm.
Use the Test-SPContentDatabase cmdlet to test content databases against the newly created web applications to make sure that all required customizations are deployed and no issues exist.
Mount the content databases on the bNext farm by using the Mount-SPContentDatabase cmdlet.
Important
If there is more than one content database, mount the database that contains the root site collection first.
Upgrade the content databases on the bNext farm by using the Upgrade-SPContentDatabase cmdlet.
After the upgrade is complete, complete the following database server tasks:
Establish database mirroring again if it was enabled on the bCurrent farm.
Restore and test all the database maintenance jobs.
Start the following SharePoint processes:
Search Crawl
Profile Import
Verify that all the required services are running.
Perform functional tests against the bNext farm to verify that the upgrade was successful. For more information, see Verify upgrade and review upgraded sites (SharePoint Server 2010).
Redirect user requests to the bNext farm. Keep the read-only bCurrent farm in case you have to roll back the upgrade.
Continue testing and monitoring the new bCurrent farm (bNext) during the stabilization period that you defined in the upgrade plan. When you are confident that you will not have to roll back to the previous build, you can delete the old bCurrent farm and recycle the servers so you can use them for other purposes.
Take an inventory of the new farm's configuration so that you have up-to-date information that can be used for future software updates.
After you finish testing the "Consumer A" farm, repeat the preceding steps to provision, update, and configure the remaining bNext consumer farm, "Consumer B" in our example, so you can put into production as the remaining new bCurrent consumer farm.
Conclusion
The guidance and steps provided in this article will work on farms of different sizes and complexity. They can also be used together with the in-place upgrade in a multi-farm scenario. You can, and should, customize these steps to suit your environment. We recommend that you use these steps and the record of your upgrade experience as a template for installing future software updates.
Appendix A. Supported upgrade options
As noted in the introduction, there are two supported options for installing SharePoint Server 2010 software updates in a build-to-build upgrade scenario: in-place and database attach. Each has advantages and disadvantages, which you have to consider in the context of the environment that you are upgrading.
In-place upgrade
An in-place upgrade occurs on the same hardware as the current version of the SharePoint Server installation. The software update is installed on the computers in a production environment. When an in-place upgrade is used, all the servers in the farm are upgraded to a new build level as part of a single, fixed process.
Advantages of the in-place upgrade
The in-place upgrade has the following advantages over the database attach upgrade method:
There is no need for additional infrastructure – the existing environment’s infrastructure continues to be used after the upgrade.
Farm-wide settings are preserved and upgraded.
Customizations are available in the environment after the upgrade, although manual steps may be required to upgrade or rework them.
Disadvantages of the in-place upgrade
The in-place upgrade has the following disadvantages compared to the database attach upgrade method:
Long production downtime - The upgrade proceeds continuously. Consequently, you must allocate enough time for all content to be upgraded in sequence. In addition, the production farm must be stopped to perform the upgrade portion of the installation. Although some approaches can be used to update farm servers in a manner that does not take all the servers down, when the upgrade is running against the farm to update the databases, the whole farm is unavailable to service requests.
Inability to uninstall – Cumulative updates and service packs cannot be uninstalled if there is an upgrade failure. The only supported method of “rolling back” would be to restore farm server images to their pre-upgrade state, or rebuild the SharePoint farm. In both cases the content databases must be restored from pre-upgrade backups.
Consistency across environments – Unless the upgrade is tested in a pre-production environment, it is possible that configuration differences and errors will cause the upgrade to fail. Even with pre-production tests, it is possible to encounter upgrade errors because of differences that were not observed or because of human error during the upgrade process.
For more information about an in-place upgrade, see Install a software update (SharePoint Server 2010).
Database attach upgrade
The database attach upgrade happens on a new farm that is created for the upgrade. This farm is a duplicate of the farm that is getting upgraded.
Advantages of the database attach upgrade
The database attach upgrade has the following advantages over the in-place upgrade method:
For large and mission-critical sites, there is some degree of availability during the upgrade.
It enables effective management of downtime and, therefore, a more predictable upgrade.
If a catastrophic failure occurs during the upgrade, the existing production environment is readily available to users.
Disadvantages of the database attach upgrade
The database attach upgrade has the following disadvantages compared to the in-place upgrade method:
Cost. The strategy relies on duplication of infrastructure (physical or virtual) and duplication of data which increases the overall cost of the upgrade.
Complexity. From a configuration and operations perspective, the process is more complex than an in-place upgrade, for example:
A secondary production SharePoint Server environment has to be created, upgraded, configured, and validated.
It requires the complete recreation of some service applications and the reconfiguration of other service applications.
It requires a load balancing or DNS solution to redirect users from one farm to another.
Although the original farm is available during the upgrade, this strategy does not provide 100% read/write availability for users during the upgrade. The production farm will be in a read-only state during the upgrade. The duration of this status depends on individual environments and includes factors such as database size and complexity, and the automation capability.
Decision points and processes for software updates
The following flowchart shows the key decision points that have to be considered when planning a software update. The flowchart also shows the high-level processes and their sequence when you install a software update.
.gif "Software update decision points and process.")
Appendix B. Configuring a SQL Server database as read-only
Setting a SQL Server database to read-only for the farm update requires the following actions:
Disable AUTO_UPDATE_STATISTICS_ASYNC
Stop all the running asynchronous statistics update jobs
Set the database to single-user mode
Set the database to the desired state (READ_ONLY)
For more information, see ALTER DATABASE (Transact-SQL) (https://go.microsoft.com/fwlink/p/?LinkID=148619). This article also provides information about how to configure a database to be read/write, which requires setting the database back to multi-user mode and then re-enabling the AUTO_UPDATE_STATISTICS_ASYNC option.
Appendix C. Guidance for deploying customizations
Special care should be taken to make sure that customizations are deployed without any issues during the upgrade. Use the following guidance to deploy customizations on the test farm:
Test customizations in read-only mode. Make sure customizations continue to function or gracefully disable themselves when the farm is put into read-only mode.
Test solution deployment and feature activation. Ensure that customizations can be deployed successfully without content. The solution packages are deployed as part of the farm build process before databases are attached. Test solution package deployment and feature activation without data.
Remediate issues before you attempt the upgrade. We recommend that you immediately address customization issues found during testing. The database attach method is a complex process. Adding additional complexity by using workarounds to deploy customizations will put the upgrade at risk of failure.
Appendix D. Techniques for replicating farm content and data
Several techniques can be used for replicating production farm content and data so that it can be used on a new farm.
File copy
Traditional file copy of each supported database to the new environment.
| Advantages | Disadvantages |
|---|---|
|
|
SQL Server backup and restore
This involves using a combination of SQL Server full, differential, or incremental backups to replicate the production content which is then restored in the new environment.
Note
Incremental backups are faster than differential because an incremental backup backs up only the changes since the last incremental backup. A differential backup on the other hand, backs up all changes since the last full backup. Typically time and storage space are the determining factors in selecting one back up method over the other. For more information, see Backing Up and Restoring Databases in SQL Server (https://go.microsoft.com/fwlink/p/?LinkID=215815).
| Advantages | Disadvantages |
|---|---|
|
|
Database mirroring
Database mirroring is a feature of SQL Server where SQL Server will write to two databases at the same time. In most cases, you do this for the high availability of both the database server and the data. This approach for replicating content for upgrade requires that one half of the mirror be broken so that the mirrored databases can be copied and upgraded. For more information about SQL Server database mirroring see Database Mirroring (https://go.microsoft.com/fwlink/p/?LinkID=216767).
| Advantages | Disadvantages |
|---|---|
|
|
Log shipping
Log shipping can be used to replicate transaction logs and ship them to the new environment so that they can be replayed to reconstitute the data on database servers. For more information, see Log Shipping (https://go.microsoft.com/fwlink/p/?LinkID=149021)
| Advantages | Disadvantages |
|---|---|
|
|
Data Protection Manager or third party backup and restore
SQL Server supports Microsoft and third-party backup utilities that can decrease backup times and increase storage efficiency. For information about Microsoft System Center Data Protection Manager, see the Microsoft Server and Cloud Platform (https://go.microsoft.com/fwlink/p/?LinkID=179139) web site.
| Advantages | Disadvantages |
|---|---|
|
|
Appendix E. Service application migration reference
The following table describes the supported methods for moving each SharePoint Server service application to another database server.
| Service application | Database | Supported approach | Supports read-only | Notes |
|---|---|---|---|---|
Access Services |
None |
not available |
not available |
|
Application Discovery and Load Balancing |
None |
not available |
not available |
|
Application Registry Service |
Application Registry Service |
Recreate |
No |
|
Business Data Connectivity |
Business Data Connectivity |
|
||
Excel Services |
none |
not available |
not available |
|
Microsoft SharePoint Foundation Subscription Settings |
Subscription |
Database attach |
||
Managed Metadata Service |
Managed Metadata Service |
|
||
PerformancePoint Services |
PerformancePoint Services |
Recreate |
||
PowerPoint Service |
None |
not available |
not available |
|
Project Server service application |
|
Database attach |
No |
For more information, see Database-attach full upgrade to Project Server 2010 |
SharePoint Server Search |
|
|
No |
|
Secure Store |
Secure Store |
|
The pass phrase for the new database must be identical to the source database. |
|
Security Token Service |
Recreate |
|||
State Service |
State |
Recreate |
No |
|
Usage and Health Data Collection |
Logging |
Recreate |
No |
|
User Profile |
|
|
Profile requires the restoration of an encrypted FIM key |
|
Visio Graphics Service |
None |
not available |
not available |
|
Web Analytics Service |
|
|
||
Word Automation Service |
Word Automation Services |
Recreate |
not available |
|
Word Viewing Service |
None |
not available |
not available |
|
Appendix F. Automation resources
Scripts
The following script collections can be used to deploy SharePoint Server and configure a farm. They can be used as is or serve as a guide for developing a custom scripts for your environment.
SPModule.zip. The SPModule.zip file is an unsupported sample of a Windows PowerShell module written by members of the SharePoint Product Group. The module can be used to perform simple administrative tasks that are related to installing a SharePoint farm. Download SPModule.zip (https://go.microsoft.com/fwlink/p/?LinkId=229657).
AutoSPInstaller. This project consists of Windows PowerShell 2.0 scripts, an XML input file, and a standard Windows batch file that is used to start the deployment and configuration process. Download the AutoSPInstaller project (https://go.microsoft.com/fwlink/p/?LinkId=229659).
Appendix G. Additional Resources
We recommend that you consult the following resources before and during the upgrade.
| Article | Description |
|---|---|
Provides links to articles that help you plan and prepare for upgrading from Microsoft Office SharePoint Server 2007 toMicrosoft SharePoint Server 2010. |
|
Testing and troubleshooting upgrade (SharePoint Server 2010) |
Provides links to articles about how to test an upgrade and use the information from the test to predict how much time and how much space that you will need for upgrade. Articles also include steps that you can take to clean up your environment before you perform an actual upgrade. |
Provides best practice guidance for conducting accurate and useful tests of the upgrade process. |
|
Checklist for database attach upgrade (SharePoint Server 2010) |
A checklist for all the necessary steps required to prepare for upgrade, perform the upgrade, and perform post-upgrade steps. |
Provides links to articles that describe how to use database attach to perform a version-to-version upgrade. |
|
Perform post-upgrade steps for a database attach upgrade (SharePoint Server 2010) |
Describes additional steps to make sure that the infrastructure that supports that content is ready to start servicing user requests again. |
Provides links to reference information about how to install Microsoft SharePoint Server by using the Psconfig command-line tool, Config.xml, and Windows PowerShell. |