Configure a server farm for minimal downtime during software updates (Office SharePoint Server 2007)

Applies To: Office SharePoint Server 2007

This Office product will reach end of support on October 10, 2017. To stay supported, you will need to upgrade. For more information, see , Resources to help you upgrade your Office 2007 servers and clients.

 

Topic Last Modified: 2016-11-14

This article describes how to update Office SharePoint Server farms with minimal downtime. By following the procedures in this article, you can update servers to add the latest service pack or cumulative update without incurring significant downtime for users. This article describes a step-by-step process for Office SharePoint Server farms that incorporate SQL Server mirroring. You can achieve similar results on Office SharePoint Server farms that are set up in a clustered server environment. For more information, see System requirements and technical specifications.

The steps to implement this solution are listed in the following table.

It often takes several teams or roles in an organization to configure, upgrade, and maintain a server farm environment. To implement this solution, you must confer with network engineers, SQL Server database administrators, and all affected SharePoint farm administrators. The administrative role of the person who usually performs each step is also listed. The roles can vary among different organizations.

Step	Administrative Role
Before you begin	To be read by all participants
Step 1: Prepare the solution	SQL Server and SharePoint farm
Step 2: Pause mirroring and set content databases to read-only	SQL Server
Step 3: Stop the Windows SharePoint Services Timer service	SharePoint farm
Step 4: Use a SQL Server alias to redirect user traffic to read-only content databases	SharePoint farm
Step 5: Disable network traffic to front-end Web servers in Group A	Network
Step 6: Install the software update on front-end Web servers in Group A	SharePoint farm
Step 7: Confirm that the content databases are updated	SQL Server
Step 8: Redirect network traffic to front-end Web servers in Group A	Network
Step 9: Begin the update process on front-end Web servers in Group B	SharePoint farm
Step 10: Remove the SQL Server alias	SharePoint farm
Step 11: Start the Windows SharePoint Services Timer service	SharePoint farm
Step 12: Complete the update process on the front-end Web servers in Group B	SharePoint farm
Step 13: Route network traffic to all front-end Web servers	Network
Step 14: Resume mirroring	SQL Server
Step 15: Mirrored content databases receive updates	None

Before you begin

This article offers a solution for updating enterprise-level Office SharePoint Server farms while incurring minimal downtime. It is not a comprehensive guide to deploying software updates, and should be used together with the instructions found in Deploy software updates for Office SharePoint Server 2007. Before you begin the update process, make sure that you read Before you begin in that article for important recommendations.

Intended audience

This solution requires the technical expertise of a SQL Server administrator, a SharePoint farm administrator, and a network engineer or administrator. This article is written for all participants in the solution, and includes specific instructions for SQL Server administrators and SharePoint farm administrators. Before implementing this solution, it is important that the project lead has a full understanding of the complete process, and that all participants understand their roles.

System requirements and technical specifications

The solution described in this article is a resource-intensive solution that requires the preexistence of a fully implemented and functional mirrored server farm. It is designed for a highly available enterprise network. The solution works for both synchronous and asynchronous mirrored systems.

In addition to the system requirements that are described in Determine hardware and software requirements (Office SharePoint Server), the farm must be running the following software versions:

• Microsoft SQL Server 2005 or Microsoft SQL Server 2008

• Office SharePoint Server 2007 with SP2

Note

Although you can run the solution on farms that are not running Office SharePoint Server 2007 with SP2, users will receive error messages when they perform certain operations that write information to the read-only database. For detailed information about the error messages, see Knowledge Base article 894631: Using Microsoft Windows SharePoint Services with a content database that is configured as read-only in Microsoft SQL Server (https://go.microsoft.com/fwlink/?LinkID=117362).
For a better user experience, we highly recommend that you upgrade your Office SharePoint Server 2007 farm to SP2 before you implement this solution.

Alternate system configurations

This article describes how to configure a mirrored Office SharePoint Server farm for minimal downtime during an installation of software updates. This section describes alternate configurations that can benefit from the general principles of the solution, but that require different implementation techniques.

Services

The solution in this article requires you to temporarily set the content databases in a secondary farm to be read-only. Services databases cannot be read-only; they must be read/write. To upgrade services with minimal downtime, consider the following two options:

• Consume the services from a parent farm that can be available throughout the upgrade process.

• If the parent services farm must be active while it is being upgraded, you must have two distinct farms. You can then consume services from one farm while you upgrade the other farm.

Clustered servers

You can achieve minimal downtime during an update in a clustered server environment either by breaking an existing SQL Server cluster into two separate hosts, or by providing an auxiliary SQL Server host to handle user requests during the update process. If it is critical that the SQL Server data be kept constantly current, we recommend that you use an auxiliary computer that is running SQL Server to set up a mirroring environment of the SharePoint farm databases. After you designate an auxiliary computer, you must allocate sufficient disk space to accommodate the copied databases.

If it is not critical to keep the SQL Server data constantly current, you can achieve minimal downtime by following these steps:

• Perform a backup of all SharePoint Server databases.

• Restore the SharePoint Server databases to an auxiliary computer that is running SQL Server and set all databases to read-only.

• Run all the procedures in this article except for the steps that are specific to mirroring.

• After you route the read-only database queries back to the main computer that is running SQL Server, discard the auxiliary databases.

The auxiliary database server can be a spare server that is specifically allocated for this task, or it can be an existing passive node in a SQL Server cluster that is removed and designated for this purpose.

Important

If you use the passive node as the auxiliary server, you are downgrading the high-availability protection that is offered by the cluster. When possible, we recommend that you use a spare server instead of a passive node for the auxiliary role.

Understanding and using the configuration example

The configuration that is used to demonstrate this solution is shown in the following figure.

As shown in the figure, there are two groups of front-end Web servers — Group A and Group B. The SharePoint Central Administration role resides in Group A.

The example databases are the configuration database (SharePoint_Config.db) and content databases. The content databases represent any quantity of content databases. The databases that are connected to Database Server A are the primary databases. The databases that are connected to Database Server B are mirrored databases.

Step 1: Prepare the solution

Before you schedule a maintenance window for installing updates, you must complete the following tasks. All the remaining steps in this guide assume that you have performed these tasks.

Write and test scripts

Scripts are usually written and tested by a SQL Server administrator.

You should write and thoroughly test the scripts that are used in Step 2: Pause mirroring and set content databases to read-only and Step 14: Resume mirroring of this solution. If a script fails during testing, recovery is a fairly simple matter. If an untested script fails during an actual software update, you might have to restore servers from backups, which can result in significant downtime.

Download software updates

Software updates are usually downloaded by an Office SharePoint Server farm administrator.

You can find Office SharePoint Server software updates at the Microsoft Download Center (https://go.microsoft.com/fwlink/?LinkID=24367). Download the appropriate software update onto each front-end Web server that is to be updated. See Deploy software updates for Office SharePoint Server 2007 for a detailed guide to software updates.

Important

Do not install the software update on any server at this point.

Schedule a maintenance window and notify users

Maintenance scheduling and notifications are tasks that can be shared between a SQL Server administrator and an Office SharePoint Server farm administrator.

Notify users that the content databases will be read-only for the expected time. The time period required depends on the type and size of the updates being applied. For a full description of the expected user experience in a read-only Office SharePoint Server farm environment, see User experience on read-only sites.

Note

At a minimum, you should complete Steps 2 through 8 of this solution within a single maintenance window.

Step 2: Pause mirroring and set content databases to read-only

This step is usually performed by a SQL Server administrator.

You must pause database mirroring and set the mirrored content databases to read-only. Pausing preserves the session state and suspends mirroring. When a session is paused, the principal database remains available. Pausing sets the state of the mirroring session to SUSPENDED, and the mirrored content database no longer synchronizes to the principal content database.

For more information about database mirroring and the effects of pausing and resuming mirroring, see the following articles:

• Configure availability in a single farm by using SQL Server database mirroring

• SQL Server 2008 Books Online, Pausing and Resuming Database Mirroring (https://go.microsoft.com/fwlink/?LinkID=153518)

After you pause mirroring, set the previously mirrored content databases to read-only. These content databases will continue to be available to users while the primary content databases are being updated. By setting the content databases to read-only, you provide limited functionality throughout the update process. When the databases are mirrored again after they are updated, all the databases will be synchronized because no read/write data operations occurred during the update phase.

Important

To follow this step, you must be a member of the db_owner fixed database role in each database.

To pause mirroring and set the content databases to read-only, run the following SQL Server scripts against the mirrored server. Replace the "<database>" variable with the database name.

Use master; 
--Pause mirroring
Alter database "<database>" set partner off
--Set databases to read-only
Restore database "<database>" with standby = 'c:\empty_file.ndf'
-- where c:\empty_file.ndf is any file name at any location (this file has no use beyond this point)

Repeat this step for each mirrored database.

Step 3: Stop the Windows SharePoint Services Timer service

This step is generally performed by a SharePoint farm administrator.

Some timer jobs do not work correctly against read-only content databases. To avoid large log files, you should disable the Windows SharePoint Services Timer service during the software update.

Note

You must be a member of the Farm Administrators SharePoint group to disable the Timer service.

Stop the Timer service on all front-end Web servers in Group B

1. Click Start, point to Administrative Tools, and then click Computer Management.

2. Expand Services and Applications, and then click Services.

3. Scroll down the list of displayed services, right-click Windows SharePoint Services Timer, and then click Stop.

Step 4: Use a SQL Server alias to redirect user traffic to read-only content databases

This step is generally performed by a SharePoint farm administrator.

When you redirect database queries to the read-only content databases, you ensure that users cannot connect to and receive errors from the content databases that are currently being updated.

Redirect clients to the read-only content databases by running the SQL Server Native Client Network Utility on the front-end Web servers in Group B.

Set up a SQL Server alias

1. Click Start, click Run, and then type the command \%SYSTEM%\cliconfg.exe in the Run box. Click OK.

2. Click the Alias tab, and then click Add.

3. In the Network libraries area, select TCP/IP.

4. In the Server alias box, type an alias.

5. In the Connection parameters area, in the Server name box, type the server name to associate with the alias, and then click OK.

6. Perform standard internal tests to make sure that the Group A front-end Web servers no longer receive user queries.

Step 5: Disable network traffic to front-end Web servers in Group A

This step is generally performed by a network administrator or engineer.

After you internally redirect SQL Server queries, disconnect front-end Web servers in Group A from any incoming network traffic. Redirect all incoming network traffic to front-end Web servers in Group B.

No specific instructions are included for this step. Details about network reconfiguration are outside the scope of this article.

Step 6: Install the software update on front-end Web servers in Group A

This step is generally performed by a SharePoint farm administrator.

Install the software update

1. Install the software update on the front-end Web server that hosts the Central Administration Web site. When the dialog box about installation in a server farm opens, do not click OK. Instead, leave the dialog box that contains the following message open:

   You must run Setup to install new binary files for every server in your server farm. If you have multiple servers in your server farm, run Setup and the configuration wizard on the other servers now, and then return to this server and click OK to continue.

2. Install the update on the application servers.

3. Install the update on the rest of the front-end Web servers.

4. When the dialog box from Step 1 in this procedure is displayed on all the application servers and Web servers in the server farm, use the Web server that hosts the Central Administration Web site to finish the installation.

For more details about how to install updates, see Installation steps.

Step 7: Confirm that the content databases are updated

This step is generally performed by a SQL Server administrator.

Database updates are handled by the update process and require no direct action. However, you should not continue with the next step until you confirm that the content databases are successfully updated.

Note

If the applied software update contains no database updates, you can skip this step.

Confirm that the content databases are successfully updated

1. In SQL Server Management Studio, right-click the updated content database, and then click New Query.

2. In the Query pane, type the following command and then execute it.

   SELECT * FROM VERSIONS
   

   The Version value in the second column of the result should match the version of the software update.

For more information about how to verify that an update has successfully completed, see Verify installation.

Step 8: Redirect network traffic to front-end Web servers in Group A

This step is generally performed by a network administrator or engineer.

After the front-end Web servers in Group A and their connected content databases are successfully updated, disconnect the front-end Web servers in Group B from any incoming network traffic. Reroute incoming network traffic to the front-end Web servers in Group A. This step puts the primary front-end Web servers in Group A back into service.

Important

You should complete at least this much of this solution within a single maintenance window.

No specific instructions are included for this step. Details about network reconfiguration are outside the scope of this article.

Step 9: Begin the update process on front-end Web servers in Group B

This step is generally performed by a SharePoint farm administrator.

This step repeats the first three steps of the procedure that is listed in Step 6: Install the software update on front-end Web servers in Group A, on the front-end Web servers in Group B.

Begin the update process on front-end Web servers in Group B

1. Install the software update on the front-end Web server that hosts the Central Administration Web site. When the dialog box about installation in a server farm opens, do not click OK. Instead, leave the dialog box that contains the following message open:

   You must run Setup to install new binary files for every server in your server farm. If you have multiple servers in your server farm, run Setup and the configuration wizard on the other servers now, and then return to this server and click OK to continue.

2. Install the update on the application servers.

3. Install the update on the rest of the front-end Web servers.

Important

Do not finish the update process by running the Products and Technologies Configuration Wizard. You will complete the update process on Group B servers in Step 12: Complete the update process on front-end Web servers in Group B.

Step 10: Remove the SQL Server alias

This step is generally performed by a SharePoint farm administrator.

This step effectively reverses the action taken in Step 4: Use a SQL Server alias to redirect user traffic to read-only content databases.

To remove the SQL Server alias, perform the following procedure on all front-end Web servers in Group B.

Remove the SQL Server alias by using SQL Server Native Client Network Utility

1. Click Start, click Run, and then type the command \%SYSTEM%\cliconfg.exe in the Run box. Click OK.

2. Click the Alias tab.

3. Select the alias to remove, and then click Remove.

4. Perform standard internal tests to make sure that the Group A front-end Web servers can now receive user queries.

If the alias change does not take effect immediately, restart Internet Information Services (IIS) by using the following procedure.

Restart IIS

1. Click Start, click Run, type cmd in the Run box, and then click OK.

2. At the command prompt, type iisreset, and then press ENTER.

3. Type exit, and then press ENTER to close the Command Prompt window.

Step 11: Start the Windows SharePoint Services Timer service

This step is generally performed by a SharePoint farm administrator.

This step effectively reverses the action taken in Step 3: Stop the Windows SharePoint Services Timer service. Perform the following procedure on all front-end Web servers in Group B.

Start the Windows SharePoint Services Timer service

1. Click Start, point to Administrative Tools, and then click Computer Management.

2. Expand Services and Applications, and then click Services.

3. Scroll down the list of displayed services, right-click Windows SharePoint Services Timer, and then click Start.

Step 12: Complete the update process on the front-end Web servers in Group B

This step is generally performed by a SharePoint farm administrator.

This step applies the fourth step of the procedure that is described in Step 6: Install the software update on front-end Web servers in Group A, to the front-end Web servers in Group B.

Complete the update for Group B

1. If a dialog box that contains the following message appears on the server that hosts the Central Administration Web site in Group B, click OK to complete the installation. If the dialog box does not appear, perform Step 2 of this procedure on the Group B server that hosts the Central Administration Web site.

   You must run Setup to install new binary files for every server in your server farm. If you have multiple servers in your server farm, run Setup and the configuration wizard on the other servers now, and then return to this server and click OK to continue.

2. Click Start, point to All Programs, point to Administrative Tools, and then click SharePoint Products and Technologies Configuration Wizard.

3. Follow the wizard steps to complete the configuration.

Step 13: Route network traffic to all front-end Web servers

This step is generally performed by a network engineer or administrator.

After the SQL Server alias is removed and the front-end Web servers in Group B are successfully updated, you can reconfigure the network so that all front-end Web servers receive network traffic. This step brings the front-end Web servers in Group B back into service.

No specific instructions are included for this step. Details about network reconfiguration are outside the scope of this article.

Step 14: Resume mirroring

This step is generally performed by a SQL Server administrator.

This step effectively reverses the actions taken in Step 2: Pause mirroring and set content databases to read-only. It re-creates high availability in the SharePoint farm.

Resume mirroring and reset the content databases to read/write

1. Use the following script to back up the transaction logs for the updated databases that are attached to the principal computer that is running SQL Server.

   USE "<database>";
   BACKUP Log "<database>"
   TO DISK = 'c:\backup\<database>_log.bak' 
   WITH FORMAT
   

2. Copy the backed up transaction log files that you created in Step 1 of this procedure to a local drive on the mirrored computer that is running SQL Server.

3. Clear all the connections to the mirrored databases by either restarting the MSSQLSERVER service, or by setting the mirrored databases to single-user mode by using the following script.

   Alter Database "<database>" SET SINGLE_USER WITH ROLLBACK IMMEDIATE; 
   

4. Restore the copied transaction log backup files by using the following script.

   RESTORE log "<database>" FROM DISK = 'c:\backup\<database>_log.bak' WITH NORECOVERY;
   

5. If you set the databases to single-user mode in Step 3 of this procedure, use the following script to reset the databases to multiuser mode.

   Alter Database "<database>" SET MULTI_USER WITH ROLLBACK IMMEDIATE; 
   

6. Reestablish mirroring to the mirrored databases by using the following script.

   Alter Database "<database>" SET PARTNER = TCP://<PrincipalServer>:<port>'
   

7. Reestablish mirroring from the principal databases by using the following script.

   Alter Database "<database>" SET PARTNER = 'TCP://<MirrorServer>:<port>'
   

Alternatively, you can reestablish mirroring (Steps 6 and 7 of this procedure) by using one of the methods described in the following articles:

• How to: Resume a Database Mirroring Session (Transact-SQL)

• How to: Pause or Resume a Database Mirroring Session (SQL Server Management Studio)

Step 15: Mirrored content databases receive updates

When mirroring resumes, software updates will be installed on the mirrored content databases. This step is provided to show process flow only; no action is required.

See Also

Concepts

Run a farm that uses read-only databases (Office SharePoint Server)
Plan for availability (Office SharePoint Server)

Other Resources

Using database mirroring (Office SharePoint Server) (white paper)
Downloadable book: Plan and configure availability within an Office SharePoint Server 2007 farm
Case Study of High Availability for SharePoint Server by Using Virtualized Environments and Database Mirroring
Case Study: Creating a Highly Available Microsoft Office SharePoint Server Environment by using Microsoft SQL Server 2005 Database Mirroring