Deploy software updates for Windows SharePoint Services 3.0

Applies To: Windows SharePoint Services 3.0

 

Topic Last Modified: 2009-11-02

In this article:

-
Intended audience and article scope

-
Understanding software updates

-
Available updates

-
Recommended installation sequence for updates

-
Installing a software update

  -   
    Before you begin

  -   
    Pre-installation steps

  -   
    Installation steps

  -   
    Verify update completion and success

  -   
    Add new servers to the farm (optional)

  -   
    Update language template packs

Intended audience and article scope

The information provided about software updates is aimed at all IT professionals who maintain Windows SharePoint Services 3.0 or Microsoft Office SharePoint Server 2007. However, the specific instructions for installing a software update are intended for IT professionals who have to install software updates on a SharePoint server farm. As noted in the following section, installation of software updates for stand-alone installations does not involve the steps that are required to install software updates on a SharePoint server farm.

Stand-alone installations

If you chose Basic installation (single server with a SQL Server Embedded Edition instance named Windows Internal Database) when you installed Windows SharePoint Services 3.0 on your Web server, you do not have to follow the process and procedures in this article. In this case, if you have Automatic Updates enabled, your computer is updated automatically. If you do not have Automatic Updates enabled, you can use either the Windows Update (https://go.microsoft.com/fwlink/?LinkId=133349&clcid=0x409) Web site or the Microsoft Update (https://go.microsoft.com/fwlink/?LinkId=133353&clcid=0x409) Web site to view the available software updates and choose the updates you want to install.

If you install a service pack on a stand-alone installation of SharePoint, the SharePoint Products and Technologies Configuration Wizard (Psconfigui.exe) starts automatically and updates the databases for SharePoint Products and Technologies. However, if you install a hotfix that was released in an installer package on a stand-alone installation, you are prompted to manually run the SharePoint Products and Technologies Configuration Wizard.

If the update is a public update and you have a stand-alone installation with automatic updates configured, the update silently runs Psconfigui.exe, and does not display the user interface until the update is installed. A localized update has the same behavior on a stand-alone installation as a public update. For more information about the different kinds of SharePoint software updates, see Understanding software updates.

For any deployment other than a deployment on a stand-alone server configured by using the Basic installation, you must visit the Microsoft Download Center (https://go.microsoft.com/fwlink/?LinkID=24367&clcid=0x409) to download and then install the software update that you want.

Note

Software updates that have limited distribution, such as a hotfix, must be obtained by a request to Customer Support Services or a Technical Account Manager, or by filling out a request form contained in the Knowledge Base (KB) article for the hotfix you want to download.

In a server farm environment software updates are not installed automatically, even if the Automatic Updates feature is enabled on your Web servers. You cannot use the Windows Update (https://go.microsoft.com/fwlink/?LinkID=133349&clcid=0x409) Web site or the Microsoft Update (https://go.microsoft.com/fwlink/?LinkID=133318&clcid=0x409)Web site to initiate the software update installation.

The software update program checks the Windows Registry and blocks automatic installation on any Web server that does not contain the value "Serverrole"="SINGLESERVER" in the HKEY_LOCAL_MACHINE\Software\Microsoft\Shared Tools\Web server extensions\12.0\WSS\ key.

Tip

You can use the Registry Editor to check the value of the HKEY_LOCAL_MACHINE\Software\Microsoft\Shared Tools\Web server extensions\12.0\WSS key to determine whether you have to manually download and install critical software updates.

Understanding software updates

Microsoft provides several different kinds of software updates for Windows SharePoint Services and Microsoft Office SharePoint Server. Before you study the details of these updates, it is recommended that you learn the key terminology. The following table provides information about the software update terminology used by Microsoft.

Software update concepts and terminology

Concepts and terms Description and definition

Hotfix

A single cumulative package composed of one or more files used to address a problem in a product. Hotfixes address a specific customer situation and may not be distributed outside that customer organization.

Public update

A public update is usually a security-related hotfix that is released publically and is available for download.  The Windows update configuration can identify these updates and install them automatically. You link to public updates from security bulletins. Typically, these hotfixes are released as required. Service packs are another example of a public update.

Service pack

A tested, cumulative set of all hotfixes, security updates, critical updates and updates, as well as additional fixes for problems found internally since the release of the product. Service packs can also contain a limited number of customer-requested design changes or features.

Scheduled delivery model

Microsoft Office is moving away from the current priority-driven hotfix release model to a scheduled delivery model. In the scheduled delivery model, hotfixes are released every two months. This schedule creates more predictability for customers. Customers who need an emergency fix can request a shorter turnaround time for a hotfix.

The following delivery mechanisms support this new approach.

  • cumulative update (CU)

  • critical on-demand (COD) hotfix

For more information, see Cumulative updates are available from the Microsoft Office team to deliver hotfixes for reported problems.

Cumulative update

A collection of hotfixes released every two months. A cumulative update (CU) rolls up previously released hotfixes and cumulative updates. A CU is sometimes called an update rollup.

Available hotfixes include the following:

  • Fixes for issues that meet hotfix acceptance criteria. These criteria include workaround availability, effect on customers, reproducibility, and the complexity of the code that must be changed.

  • Any critical on-demand hotfixes that are currently released.

  • Any critical security or non-security updates that are currently released.

For more information, see the Office hotfixes to be delivered on a defined schedule in the form of Cumulative Updates (https://go.microsoft.com/fwlink/?LinkId=133358&clcid=0x409) blog post.

Critical on-demand (COD) hotfix

A critical on-demand (COD) hotfix is available to address critical problems that cannot be handled via the cumulative update delivery cycle. COD fixes are limited to emergency situations, for example, one in which the issue is blocking normal business operations for the customer, and/or for which there is no effective workaround. Critical on-demand (COD) hotfixes are included in the next cumulative update that is released.

Note

COD releases have the versioning pattern 12.0.xxxx.500X. An example is a CU released with the version 12.0.6327.5000, with a COD hotfix subsequently required. In this example, the version of the COD hotfix is 12.0.6327.5001. If additional hotfixes are required before the next CU, the next version number is 12.0.6327.5002, and so on until the next CU is released.

Package

The downloaded item, an executable (.exe) file that is downloaded for a update rollup or hotfix. A package can contain one or more patches. Depending on the download mechanism that is provided, this executable file might be wrapped inside another password-protected executable file. After you extract the package, you have one or more .exe files that use a Knowledge Base (KB) number as part of its name; for example, Webfldrs-KB907306-ENU.exe. In this example, most customers run the Webfldrs-KB907306-ENU.exe executable file when they update their SharePoint servers.

Patch

Patches are stored inside packages. The patches run Windows Installer program (msiexec.exe) to update the original installation packages (which have the .msi file name extension) with new information or binaries. Patches that are installed by the Windows Installer program have the .msp file name extension.

You can extract patches to a common folder to create a slipstream version of the patch. For more information, see Create an installation source that includes software updates (Windows SharePoint Services 3.0) or Create an installation source that includes software updates (Office SharePoint Server 2007).

Localized patch

A localized patch, or local patch, contains updates to language-specific strings or related code. 

Global patch

A global patch is language-agnostic and can be applied to any server regardless of the base installation language or whether language packs are installed. Most software updates are delivered by means of global patches.

Upgrader

An upgrader is a specific piece of the product that evaluates the current state of related objects and possibly alters them to match newer schema, enable new functionality, or correct known issues.

Additional information about software updates is provided in the following sections:

  • Cumulative updates

  • Packages

  • Patches

  • Global and localized patches

Cumulative updates

As noted in the preceding software terminology table, cumulative updates provide a predictable cycle for delivering software updates to customers and make it easier to manage installation of software updates for Windows SharePoint Services and Office SharePoint Server. Although the first cumulative update was released in August 2008, the December CU (2008) is the first full implementation of all aspects of the new update delivery model for SharePoint. Starting with the December CU, each cumulative update will ship a package that contains the latest version of every hotfix that we have shipped. This change makes it easier to create a new Office SharePoint Server and lets you patch it to the current update level by applying the following four updates:

  • The latest service pack for Windows SharePoint Services

    Note

    While recommended as a best practice, installation of the latest service pack is not required. If you cannot install the latest service pack, we support installation of a cumulative update on top of an older service pack that is still within lifecycle (For more information, see https://www.microsoft.com/lifecycle (https://www.microsoft.com/lifecycle) ).

  • The latest service pack for Office SharePoint Server

  • The latest cumulative update for Windows SharePoint Services

  • The latest cumulative update for Office SharePoint Server

Keep the following information in mind about the structure of the new update format:

  • Windows SharePoint Services continues to remain separate and is not included in the Office SharePoint Server package.

  • All of the latest global and local patches for Windows SharePoint Services are in the Windows SharePoint Services package.

  • All of the latest global and local patches for Office SharePoint Server and other Microsoft Office server products (for example, InfoPath Forms Services and Microsoft Office Project Server) are contained in the Office SharePoint Server package.

  • The list of package content is an accumulation of what we have shipped since RTM, including the Infrastructure Update, which no longer has to be installed as a separate update.

For more information regarding the specific fixes within a cumulative update, refer to the KB article for the update.

For more information about cumulative updates, read the Office hotfixes to be delivered on a defined schedule in the form of Cumulative Updates (https://go.microsoft.com/fwlink/?LinkId=133358&clcid=0x409) blog post.

To obtain information about Microsoft Office cumulative updates as Microsoft releases them, we recommend that you subscribe to the Office Sustained Engineering blog (https://go.microsoft.com/fwlink/?LinkId=133359&clcid=0x409).

Packages

Packages use the following naming convention.

Software update naming convention

The pattern for the software update naming convention is productnamerrr-kby-xnn-fullfile-lang**.exe**, where:

  • productname is a short identifier for the name of the released product.

  • rrr is a description of the release; for example, Service Pack 1 is sp1.

  • y is a number that corresponds to the Knowledge Base article about the software update.

  • nn is a number indicating the hardware architecture, either x86 or x64.

  • lang is the language of the software update; for example, U.S. English is en-us.

For example, the file name for the Windows SharePoint Services 3.0 with Service Pack 1 (SP1) file, in U.S. English and for x86-based hardware, is wssv3sp1-kb936988-x86-fullfile-en-us.exe.

After you run the executable .exe files to install a package it is recommended that you can verify that the update was installed.  You can do this as follows for Windows Server 2003 and Windows Server 2008:

  • Windows Server 2003 — View the history of installed updates: Click Control Panel, and then click Add or Remove Programs. Select the Show updates check box.  The file name and a corresponding reference to the KB article number are displayed. For example, the Currently installed programs and updates list displays "Update for Microsoft Windows SharePoint Services 3.0 (KB932091)" if it was installed.

  • Windows Server 2008 — View the history of installed updates: Click Control Panel, and then click Programs and Features. On the Tasks bar click View installed updates. A list of updates appears; for example, "Update for Microsoft Windows SharePoint Services 3.0 (KB932091)".

In either of the preceding examples you can browse to https://support.microsoft.com/kb/\<kbnumber>, where <kbnumber> is the KB article number, you can read the article that provides more information about the package.

Regarding packages, note also the following:

  • Patches are cumulative. Therefore, if two packages contain the same patch or patches, the package with the higher build number contains everything that the package with the lower build number contains.

  • The properties of a package show you the number of the build that contains the package.  This is important because the build number is sometimes higher than the versions shown for the files in the package, and is a better reference point for the package contents*.

  • You can extract packages to examine the patch contents by opening a Command Prompt window and typing the following command at the prompt: <packagename>.exe /extract:.\<hfx>, where <packagename> is the name of the package and \<hfx> is a folder name. The preceding command extracts the package contents to a folder named hfx under the directory path of the current command prompt. You can change the \<hfx> parameter to specify a directory location and folder name that suits your requirements.

  • A package name can include the letters glb, which indicate that the package contains global patches; for example, office-kb950487-fullfile-x86-glb.exe.

  • A package name can include regional codes such as en-us (English, United States) or de-de (German, Federal Republic of Germany), which indicate that the package contains localized patches; for example, wss-kb948957-fullfile-x86-en-us.exe.

Patches

You can install an individual patch manually. However, if you install an individual patch manually, the upgrade process occurs automatically, which might start an upgrader. If you run the .exe package instead, automatic upgrades are suppressed when the package is installed.

Within Windows SharePoint Services and Office SharePoint Server 2007, patches that are associated with a service pack have names different from patch names in update rollups, public updates, and hotfixes.  For example, in a cumulative update, the global patch for Windows SharePoint Services is named sts.msp (.msp is the file name extension for the Windows Installer update package) and patches the sts.msi patch that was installed from the original media.  Another example is Service Pack 1, which contains a file named stswwsp1.msp that patches the sts.msi patch installed from the original media.  Even though the patch file names are different in the preceding examples, both patches update the same files. The following table shows the most common mappings that are used for Windows SharePoint Services and Office SharePoint Server.

Product Windows Installer update package

Windows SharePoint Services 3.0

In the following list, <region> is the code for the base language, such as en-us.

  • sts.msp

  • wssmui-<region>.msp

Office SharePoint Server 2007

In the following list, <region> is the code for the base language, such as en-us.

  • coreserver.msp

  • coreservermui-<region>.msp

  • dlc.msp, where "dlc" is the identifier for Document Lifecycle, which encompasses Workflows and Policies

  • dlcmui-<region>.msp

  • ifswfe.msp, where "ifs" is the identifier for InfoPath Forms Services

  • xlsrvapp.msp, where "xls" is the identifier for Excel Calculation Services

  • In some cases the patch name may contain the string "x-none", which indicates that this is a global patch.

Global and localized patches

Global patches affect parts of the product that are language-agnostic.  That is, the patches alter only items that do not have any language-specific relationships.  The design of the SharePoint product ensures that any language-specific string is in its own location so that it can be updated separately.  As a result, global patches can be applied to any server regardless of the base installation language or whether language packs are installed.

Localized patches, also called local patches, are patches that contain updates to language-specific strings or related code.  A code change in a localized patch might not be for a specific string shown in the user interface, but would be close enough to those strings to form part of that localized patch.

A common question is whether to install the global patch, localized patch, or both.

The decision about which patch to install is based on what you want to accomplish with the installation. The following points provide guidance in making this decision:

  • Most of the product updates are contained in global patches. As noted in the product design information, care was taken to separate language-specific parts of the product code, which does not constitute the bulk of the code base.

  • There are some code fixes that require both the global and local patch for full implementation. If you install only one of the patches, specific functionality remains broken in the same way that it was before you applied the patch.

  • Because a service pack updates everything, the first dependency is introduced at some point after a service pack is applied. This dependency continues to exist until the next service pack. Installing either the global patch or the localized patch does not necessarily affect the overall operation of your server, but if you want to ensure that you have all the fixes, install the global patch and the localized patch.

  • Microsoft Customer Support Services (CSS) strongly recommends that you install both patches across your SharePoint environment to ensure that you get the maximum benefit from the fixes and maintain the same software update level across your platform.

Additional resources

To help you better understand the update deployment process, refer to the Presentation: Understanding and deploying hotfixes, public updates, and service packs (https://go.microsoft.com/fwlink/?LinkId=121946&clcid=0x409), which was given by Daniel Winter at the SharePoint Products and Technologies conference in March 2008. This presentation provides valuable information about the different kinds of software updates that Microsoft releases for Windows SharePoint Services and Office SharePoint Server.

Using Windows SharePoint Services 3.0 with SP1 and Office SharePoint Server 2007 with SP1 as examples, Daniel Winter provides detailed information about pre-upgrade steps, deploying the upgrade, validating the upgrade, and troubleshooting the upgrade. It is strongly recommended that you view the presentation before you read the remainder of this article and before you deploy a software update.

Available updates

The following updates have been released for Windows SharePoint Services 3.0.

Tip

The Updates Resource Center for SharePoint Products and Technologies (https://go.microsoft.com/fwlink/?LinkId=133360&clcid=0x409) provides a single point for accessing information about software updates.

Major updates for Windows SharePoint Services 3.0

Name Description and owssvr.dll version number

Windows SharePoint Services 3.0

The release-to-manufacturing (RTM) version of Windows SharePoint Services.

owssvr.dll version number: 12.0.4518.1016

October public update (2007)

Release of nine security updates across two bulletins. For more information, see Important Security Hotfix MS07-059 (https://go.microsoft.com/fwlink/?LinkId=133361&clcid=0x409) on the Microsoft SharePoint Team Blog.

owssvr.dll version number: 12.0.6039.5000

Note

Although Windows SharePoint Services shows as build 12.0.6040 you see it display 12.0.0.6039 in Site Settings because the Microsoft Software License Terms changed in 6040, and as a result there were no binary changes from 12.0.0.6039 to 12.0.0.6040. Your Windows SharePoint Services Database in the Central Administration user interface will reflect the RTM build version 12.0.0.4518 because a binary change does not occur on the backend.

Service Pack 1

Service Pack 1 (SP1) includes a number of hot fixes across Office SharePoint Server 2007 and Windows SharePoint Services 3.0, new Stsadm commands for repartitioning databases and renaming host site collections, and updates to product documentation that address performance and capacity planning concerns. For more information about what this service pack contains, read the introductory white paper, Service Pack 1 for Windows SharePoint Services 3.0 and Microsoft Office SharePoint Server 2007 (https://go.microsoft.com/fwlink/?LinkId=105704&clcid=0x409).

owssvr.dll version number: 12.0.6219.1000

Post-Service Pack 1 rollup

This rollup provides fixes that were made after the code was locked for SP1. For more information, see the following KB articles, Description of the Windows SharePoint Services 3.0 post-Service Pack 1 hotfix package: January 31, 2008 (https://go.microsoft.com/fwlink/?LinkID=102044&clcid=0x40c).

owssvr.dll version number: 12.0.6300.5000

Infrastructure Update (IU)

The Infrastructure Update fixes several issues in Windows SharePoint Services 3.0. For more information, see Description of the Infrastructure Update for Windows SharePoint Services 3.0 (https://go.microsoft.com/fwlink/?LinkId=133362&clcid=0x409) and Issues that are fixed in Windows SharePoint Services 3.0 by the Windows SharePoint Services 3.0 Infrastructure Update (https://go.microsoft.com/fwlink/?LinkId=133363&clcid=0x409).

owssvr.dll version number: 12.0.6320.5000

August Cumulative Update

For more information about this update, refer to the following KB articles:

owssvr.dll version number: 12.0.6327.5000

October Cumulative Update

To learn about the issues that are fixed in this update see Description of the Windows SharePoint Services 3.0 hotfix package (Sts.msp): October 28, 2008 (https://go.microsoft.com/fwlink/?LinkId=133366&clcid=0x409)

owssvr.dll version number: 12.0.6331.5000

December Cumulative Update

This update contains hotfixes for all the Windows SharePoint Services 3.0 issues that have been fixed since the release of Windows SharePoint Services 3.0. For more information, see Description of the Windows SharePoint Services 3.0 cumulative update package (WSS server-package): December 16, 2008 (https://go.microsoft.com/fwlink/?LinkId=139517).

owssvr.dll version number: 12.0.6335.5000

This update contains:

  • Dw20w-x-none.msp

  • Sts-x-none.msp

  • Wssmui-en-us.msp (and all the other languages for the product)

February Cumulative Update

To learn about the issues that are resolved in this update see Description of the Windows SharePoint Services 3.0 cumulative update package : February 24, 2009 (https://go.microsoft.com/fwlink/?LinkId=146627&clcid=0x409)

owssvr.dll version number: 12.0.6341.5000

Service Pack 2

Service Pack 2 (SP2) provides full support for Windows Server 2008 and Internet Information Services (IIS) 7, extended browser support, new operations and properties for the Stsadm command-line tool, improved functionality for existing features, and hot fixes for known issues.

Service Pack 2 includes SP1 and all the updates released up to this service pack. For a description of SP2, see Description of Windows SharePoint Services 3.0 SP2 and of Windows SharePoint Services 3.0 Language Pack SP2 (https://go.microsoft.com/fwlink/?LinkID=149885&clcid=0x409)

owssvr.dll version number: 12.0.6421.1000

April Cumulative Update

The April cumulative update (CU) provides very important fixes for Stsadm, in particular the mergecontentdbs operation. For more information, see Description of the Windows SharePoint Services 3.0 Cumulative Update Server Hotfix Package (Sts.msp): April 28, 2009 (https://go.microsoft.com/fwlink/?LinkId=1549817).

For a description of this update, see KB 968850 (https://go.microsoft.com/fwlink/?LinkID=149888)

owssvr.dll version number: 12.0.6504.5000

June Cumulative Update

For a description of this update for Windows SharePoint Services 3.0, see Description of the Windows SharePoint Services 3.0 Cumulative Update Server Hotfix Package (WSS server-package): June 30, 2009(https://go.microsoft.com/fwlink/?LinkId=157329).

This update provides several fixes for Windows SharePoint Services 3.0. For more information, see Description of the Windows SharePoint Services 3.0 Cumulative Update Server Hotfix Package (Sts.msp): June 30, 2009(https://go.microsoft.com/fwlink/?LinkId=157330).

Build number: 12.0.6510.5001

August Cumulative Update

For a description of this update for Windows SharePoint Services 3.0, see Description of the Windows SharePoint Services 3.0 Cumulative Update Server Hotfix Package (WSS server-package): August 25, 2009 (https://go.microsoft.com/fwlink/?LinkId=164621).

This update provides several fixes for Windows SharePoint Services 3.0. For more information, see Description of the Windows SharePoint Services 3.0 Cumulative Update Server Hotfix Package (Sts.msp): August 25, 2009(https://go.microsoft.com/fwlink/?LinkId=164623).

owssvr.dll version number: 12.0.6514.5000

Cumulative update build number: 12.0.6514.5000

October Cumulative Update

For a description of this update for Windows SharePoint Services 3.0, see Description of the Windows SharePoint Services 3.0 Cumulative Update Server Hotfix Package (WSS server-package): October 27, 2009(https://go.microsoft.com/fwlink/?LinkId=169313).

This update provides several fixes for Windows SharePoint Services 3.0 and improved functionality for the Pre-Upgrade Checker. Notable changes to the Pre-Upgrade Checker are improved reports, new rules, and additions to the stsadm –o EnumAllWebs operation so that you can now list Web Parts, event receivers, features, or SetupPath-backed files.

For more information, see Description of the Windows SharePoint Services 3.0 Cumulative Update Server Hotfix Package (Sts-x-none.msp): October 27, 2009 (https://go.microsoft.com/fwlink/?LinkId=169314): October 27, 2009).

owssvr.dll version number: 12.0.6520.5000

Cumulative update build number: 12.0.6520.5000

Although Microsoft does not enforce the update installation sequence, we recommend that you install the post-RTM updates for WSS that you require in the following sequence:

  1. Service Pack 2 for Windows SharePoint Services 3.0 (KB 953338)

  2. The October CU for Windows SharePoint Services 3.0 (KB 975002)

For information about creating a slipstream installation source using the December CU, see How to create a SharePoint slipstream using the latest updates (https://go.microsoft.com/fwlink/?LinkId=139512) blog post.

Important

Remember to run either the SharePoint Configuration Wizard or Psconfig.exe at the command prompt on every server in your farm to complete the update. You are not required to run the SharePoint Configuration Wizard or Psconfig between each step in the sequence. You can wait until all updates are installed on a given server before you run the SharePoint Configuration Wizard or PSconfig.

Installing a software update

In order to successfully install a software update on your server farm we recommend that you follow the pre-installation, installation, and verification steps that are provided in this article.

Before you begin

Before you start the pre-installation steps, note the following:

  • Microsoft recommends that you schedule the installation of the software update for a time that causes the least amount of disruption for your users. Communicate the proposed schedule to the users and the key people involved with the Web sites hosted on the servers that run Windows SharePoint Services 3.0 and, if necessary, adjust your installation schedule.

  • Do not install a beta version of the Windows SharePoint Services 3.0 software update in a production environment.

  • You must download the correct software update file for your hardware and software language.

  • If you previously installed a hotfix, and the problem that it addresses is not fixed in this widely available software update, you must obtain the updated version of that hotfix to address specific issues in your environment by contacting Microsoft Customer Support Services (https://go.microsoft.com/fwlink/?LinkId=99201).

  • You must remove the Web servers that run WSS 3.0 from service for the duration of the software update installation. The reason for doing this is that the software update might make schema changes to the SQL Server database, and user authoring during the upgrade might result in the front-end and back-end servers having different content.

  • If you install updates on Web servers that run Windows SharePoint Services 3.0 in a server farm, the following occurs: After the software update is installed on the first Web server in the server farm, the file versions on that Web server and the databases in that server farm are different from the file versions on the other Web servers. This mismatch prevents the server farm from working correctly, and causes even valid requests to result in errors. When the software update has been installed on all of the Web servers in the server farm, results are returned to users as expected.

  • In server farm deployments, you must update all the Windows SharePoint Services 3.0 Web servers to the same software update version.

  • To deploy software updates in a server farm you must be logged on to the Web server or application server as a domain account. The domain account must have the following permissions:

    • Member of the Administrators group on the Web server computer.

    • Member of the Administrators group on the server that runs SQL Server. Or, owner of the fixed database role db_owner for all SharePoint Products and Technologies databases.

    To ensure that you have the correct permissions to install the software update and run the SharePoint Products and Technologies Configuration Wizard, Microsoft recommends that you add the account for the SharePoint Central Administration v3 application pool identity to the Administrators group on each of the local Web servers and application servers and then log on by using that account. These changes are only required for installing the update and then running the SharePoint Products and Technologies Configuration Wizard to complete the upgrade. After you finish installing the update, remove the account on each of the local Web servers and the application servers.

  • In many IT environments, database administrators (DBAs) create and manage databases. Security policies and other policies in your organization might require that DBAs create the databases that Windows SharePoint Services 3.0 uses. For information about how to deploy Windows SharePoint Services 3.0 in an environment in which DBAs create and manage databases, see Deploy using DBA-created databases (Windows SharePoint Services) (https://go.microsoft.com/fwlink/?LinkID=86818&clcid=0x409).

  • You can install the software update by logging on to the server directly or by connecting through a Terminal Services console session. For information about how to use console sessions, see Microsoft Knowledge Base article 278845: How to Connect to and Shadow the Console Session with Windows Server 2003 Terminal Services (https://go.microsoft.com/fwlink/?LinkId=98317).

Pre-installation steps

Before you install a software update, it is recommended that you do the following:

  • Check the status of Timer Jobs. When you first installed Windows SharePoint Services on the Web servers in your server farm, if you used an upgrade method — either in-place or gradual — and upgrade jobs remain in progress, the software update installation might fail. You must verify that none of the upgrade processes are running. Go to the SharePoint Central Administration site, click Operations, and in the Global Configuration section click Timer job status. If any upgrade jobs are listed, you must allow the upgrade to complete before you install the software update.

    The upgrade jobs that appear on the Timer Job Status page result from either or both of the following operations:

    1. Sites are in the process of being upgraded.

    2. You chose the in-place upgrade option in the SharePoint Products and Technologies Configuration Wizard.

      Note

      When you run an in-place upgrade, all content and configuration data are upgraded in place, at one time. When you start the in-place upgrade process, the Web server and Web sites remain offline until the upgrade has been installed. When you perform an in-place upgrade, you cannot pause or roll back to the previous version.

    After you have verified that no upgrade items are listed on the Timer Job Status page, you can continue to install the software update.

  • If there are orphaned objects in the content databases — orphans are items that do not have any parent or child relationships — the software update installation fails. To ensure that the installation succeeds, you must either fix the relationship of objects or drop the orphans before you begin the software update installation. For more information about a resolution of the problem of one or more orphaned objects in the content database, see the Microsoft Knowledge Base (KB) article titled Error message when you try to upgrade Windows SharePoint Services 2.0 to Windows SharePoint Services 3.0: "Upgrade has encountered one or more lists that were not updated by Prescan.exe and must exit" (https://go.microsoft.com/fwlink/?LinkId=105755).

  • If you customized a predefined site template by directly modifying the site template files — an action that Microsoft does not recommend — the software update installation might overwrite some of the files that you modified, and your customizations in those files will be lost. You must reapply any site-template customizations after you install the software update.

  • Stop the World Wide Web publishing service (W3SVC) on all front-end Web servers to disconnect all the users from the server farm. In server farms with multiple front-end Web servers, if you allow users to connect after the files and databases have been updated on one Web server but not on other Web servers, users cannot browse the Web sites.

    Note

    If you manually stop the World Wide Web Publishing service, you must manually start it at the end of the installation.

  • Before you start the backup, clean up your environment by performing the following steps:

  • If any of your databases contains more than the number of site collections recommended in the Information Architecture Recommendations of the download Planning and Monitoring SQL Server Storage for Windows SharePoint Services: Performance Recommendations and Best Practices (white paper), load-balance your site collections across multiple databases.

  • Follow the best practices for content database sizing before you perform any upgrade operations.

  • Ensure that you follow the recommendations concerning the SQL Server page-fill factor and other storage planning best practices before you begin the upgrade. For more information about storage best practices, see Performance recommendations for storage planning and monitoring (https://go.microsoft.com/fwlink/?LinkID=105890&clcid=0x409).

  • Back up the server farm before you start the software update installation. Create a backup of search and all databases. For more information about how to perform backups, see Prepare to back up and restore a farm (Windows SharePoint Services 3.0). Microsoft recommends that you carry out the following processes:

    • Configuration database and Central Administration content database: You must back up your databases by using SQL Server tools after you have stopped your farm. Use the simple recovery model so that your transaction log is truncated. This backup is not for purposes of immediate restoration, but can help you accurately rebuild a configuration database if rebuilding is required. For more information, see Move all databases (Windows SharePoint Services 3.0).

    • Content databases: Perform a full backup operation with either Stsadm or SQL Server to back up all content databases. If you are using SQL Server, use the full recovery model, so that your transaction log is not truncated.

      Because your Content databases contain the data for your web sites, it is important to maintain uncommitted transaction logs containing that data, please be sure that all Content databases are backed up via full recovery model.

      Important

      The simple recovery model is inappropriate for production systems for which the loss of recent changes is unacceptable. In these cases, we recommend that you use the full recovery model.

    • Front-end Web server: If you customized the front-end Web server, ensure that you accurately documented all your customizations so that you can rebuild the server at any time. As a last resort, if you did not document your customizations, or are unsure of the extent of the customizations to your Web applications, it is recommended that you make a backup image of your front-end Web server. Ensure that you have a backup of any solution packages that you deployed on your front-end Web servers.

      Tip

      Ideally, if you are customizing front-end Web computers, the customization is managed by using a robust build process or script that allows the customizations to be applied to a new computer.

      If you experience an unrecoverable failure during upgrade, you might have to reinstall SharePoint and restore your server from the backup image you created. You would have to manually apply any customizations to your front-end Web server.

      Important

      Microsoft recommends that you back up the server farm after you verify that the software update installation is successful.

      After you back up all of your databases, use the SQL Server DBCC shrinkfile command to free unused log space, making the logs as empty as possible. For more information, see Shrinking the Transaction Log (https://go.microsoft.com/fwlink/?LinkId=105233). It is a best practice to verify that you can restore the databases.

  • In server farms that have a large number of sites, installing a software update with the content databases attached can result in too much downtime. To minimize downtime, Microsoft recommends that you perform the additional step of detaching the content databases.

    Important

    If your content database contains Office Project Server sites, do not detach it from your farm. Refer to the article Extract Project Web Access site data to a new content database before proceeding.

Installation steps

This section includes all of the procedures that are required to install a software update successfully in any size server farm. If you update a large server farm, read the Large farm optimization section in this document.

You must install the software update on each Web server that is running Windows SharePoint Services 3.0 to the point that the files are copied to all Web servers in the server farm. You return to one Web server to complete the installation. After the installation is complete on the Web server that you selected, you complete the installation on each of the other Web servers.

The following procedure lets you do the following:

  • Make all software update files available on all servers in your server farm.
  • Complete the update on the server hosting the main Central Administration site.
  • Finish updating the remaining servers in the server farm.

Note

You must perform step 1 though step 6 in the following procedure on every Web server in the server farm before you complete the installation on any one Web server.

To install a software update

  1. Disconnect users from the server farm by stopping the World Wide Web Publishing Service (W3SVC) on all Web servers.

    Note

    This manual step is done as a precaution to ensure that the service is fully stopped.

  2. Download and install the appropriate Windows SharePoint Services 3.0 software update for all servers in your server farm.

  3. At the end of the software update installation, the SharePoint Products and Technologies Configuration Wizard starts.

    Note

    If the wizard does not start automatically, click Start, point to All Programs, point to Administrative Tools, and then click SharePoint Products and Technologies Configuration Wizard.

  4. On the SharePoint Products and Technologies Configuration Wizard Welcome page, click Next.

  5. In the dialog box that notifies you that some services might have to be restarted during configuration, click Yes.

  6. On the Completing the SharePoint Products and Technologies Configuration Wizard page, click Next.

  7. When the dialog box about installation in a server farm opens, do not click OK. Instead, leave each server with the following dialog box displayed:

    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.

  8. When the dialog box from the previous step is displayed on all Web servers in the server farm, use one Web server that hosts the Central Administration Web site to finalize the installation.

  9. On the server you selected in the previous step, click OK.

  10. In the Configuration Successful dialog box, click Finish.

  11. After you finish updating one Web server that hosts the Central Administration Web site, follow the procedures in the Verify update completion and success section in this article to ensure that the software update installation on this one Web server was successful.

  12. Continue updating the remaining computers in the server farm, one at a time, by clicking OK in the dialog box.

    Note

    It is important that the SharePoint Products and Technologies Configuration Wizard perform the configuration procedures on only one computer at a time.

  13. When the software update installation and configuration is complete on all the Web servers in the server farm, make the Web servers available to users by manually starting the World Wide Web Publishing service on each server on which you manually stopped the service.

If you completed the "To detach content databases" procedure described later in this document and if you configured additional computers to upgrade the content databases, you must use one of the following procedures to attach the content database after the software update installation is complete.

Note

If you did not follow the "To detach content databases" procedure, you can skip the following procedures to attach the content database.

If you did not configure additional computers specifically to upgrade the content databases, you must follow the next procedure, "To attach the content database at the command prompt". This procedure attaches and initiates an upgrade of the content database.

To attach the content database at the command prompt

  • To attach the database, open a Command Prompt window and type the following at the command prompt:

    stsadm -o addcontentdb -url <http://backupservername:port> -databasename <ContentDBName> -databaseserver <NewPrincipalServer>

If you configured additional computers specifically to upgrade the content databases, you can use the following procedure to attach the content database to the updated computers.

To attach the content database

  1. Click Start, point to All Programs, point to Administrative Tools, and then click SharePoint 3.0 Central Administration.

  2. On the Central Administration site, click Application Management.

  3. On the Application Management page, in the SharePoint Web Application Management section, click Content databases.

  4. On the Manage Content Databases page, click Add a content database.

  5. In the text boxes, enter the information for the content database that you detached earlier.

  6. Repeat step 4 and step 5 for every content database you want to attach.

You must perform the following procedure on servers that are running the Windows SharePoint Services search service in your server farm if either of the following conditions is true:

  • You are running in a least-privileges scenario.

  • The account that you are using for the search service is of the following:

    • Not an Administrator on the local computer

    • Not a member of the server farm administrator account

To start the search service

  1. Open a Command Prompt window and navigate to the %COMMONPROGRAMFILES%\Microsoft Shared\web server extensions\12\bin directory.

  2. To identify the computers that are running an instance of the online Windows SharePoint Services search service, type the following at the command prompt:

    stsadm -o spsearch -action list

  3. Log on (either locally or through a remote connection) to each computer that is returned in the list from the preceding step, and type the following at the command prompt:

    stsadm -o spsearch -action start

Large farm optimization

In very large server farms, installing a software update with the content databases attached can result in too much downtime. If where there are multiple sites or many Web servers, then to minimize the downtime required to upgrade, it is recommended that you perform the additional step of detaching the content databases. For the best performance with the upgrade operations, you should use four or five front-end Web servers per database server.

Note

Unless you are dealing with a very large server farm, you do not have to follow this procedure.

To detach content databases

  1. To detach a content database using Stsadm, open a Command Prompt window and navigate to the %COMMONPROGRAMFILES%\Microsoft Shared\Web server extensions\12\Bin directory.

  2. Type the following at the command prompt:

    **stsadm -o deletecontentdb -url http://**computername-ContentDatabaseName

    In this operation, -url specifies the Web application from which the content databases will be detached and -databasename specifies the name of content database to be detached.

    Note

    If your database server is on a separate server, you need to use the -databaseserver parameter to specify the database server name.

After you upgrade your server farm, you must reattach the content databases to the server farm. You can attach only one content database to the server farm at a time, because when you attach the databases to the upgraded server farm, the content database is upgraded automatically.

If you want to streamline the upgrade process even further, you can configure additional computers as Web servers running Windows SharePoint Services 3.0 with SP1 in a single-computer server farm; four to five Web servers are recommended. You must configure alternate access mappings on these temporary front-end Web servers to match the original servers. If the alternate access mappings are not identical, the content databases might be upgraded with the wrong URLs within their site content. This results in the inaccurate display of certain pages; you must contact Microsoft Product Services to correct the problem. Then, to perform a parallel upgrade of the content databases, use these Web servers to upgrade the content databases while they are detached from the original server farm.

After you detach the upgraded content databases from the temporary Web server, and attach them back to the original server farm, the content databases are ready for service. At this point, you have to remove any content databases from the previous version and then back up the server farm.

Note

If you detach and reattach a content database, be aware that the next time the content within that content database is crawled, a full crawl will occur — even if an incremental crawl was requested. Because a full crawl recrawls all content, regardless of whether that content was previously crawled, full crawls can take significantly more time to complete than incremental crawls.

If you are running the Infrastructure Update for Windows SharePoint Services 3.0, the identifier (ID) of each content database is retained when you restore or reattach the database by using built-in tools. Default change log retention behavior when using built-in tools is as follows:

  • The change logs for all databases are retained when you restore a farm.

  • The change log for a content database is retained when you reattach the database.

  • The change log for a content database is NOT retained when you restore just the content database.

When a database ID and change log are retained, Search continues crawling, based on the regular schedule defined by crawl rules. When a change log is not retained, Search performs a full crawl during the next scheduled crawl.

For more information, see Move all databases (Windows SharePoint Services 3.0) and Back up and restore the farm (Windows SharePoint Services 3.0).

The limiting factor for this method is that you cannot simultaneously update more than one content database for each Web application — even if you use multiple computers.

Verify update completion and success

After you install a software update, verify that the installation was successful by using one of the following techniques:

  • View the upgrade log file. In addition to viewing the results of the installation in Upgrade.log file, you can use this logfile to troubleshoot a failed installation.

  • Check version numbers on certain files and registry keys. If you have to investigate the success of the software update installation in more depth, use this procedure to verify version numbers on certain files and verify certain keys in the registry.

  • Examine the SQL schema. You can also verify that the software update installation was successful by using SQL Query Analyzer to examine the SQL Server schema. Although the version of the DLL files and the registry are updated during the first part of an upgrade — when the files are being copied — the SQL Server schema is only upgraded after the SharePoint Products and Technologies Configuration Wizard is run. Use this procedure to determine whether the SharePoint Products and Technologies Configuration Wizard was run after the software update.

  • View the version number on the Servers in Farm page. You can use the SharePoint Central Administration Web site to view the version number on the Servers in Farm page. However, note that this page only displays the version number for Windows SharePoint Services 3.0.

To view the upgrade log file

  1. In Windows Explorer, change to the following directory:

    %COMMONPROGRAMFILES%\Microsoft Shared\Web server extensions\12\LOGS

  2. Use a text editor to open the Upgrade.log file.

  3. Scroll to the date on which you installed the software update.

  4. Search, or visually scan, for the following entries:

    Finished upgrading SPFarm Name=<Name of Configuration Database>

    In-place upgrade session finishes. Root object = SPFarm=<Name of Configuration Database>, recursive = True. 0 errors and 0 warnings encountered.

    If you find these entries, the installation was successful.

  5. If you do not find the entries in the preceding step, you can identify specific issues that might have contributed to the failure by searching, or visually scanning, the Upgrade.log file for the following terms:

    • fail

    • error

    After you identify and resolve the blocking issues, use the "To force a software update" procedure that is provided later in this section.

In some configurations, the SharePoint Timer Service (OWStimer) account — which, by default, is the same account used by the SharePoint Central Administration v3 application pool—is configured with credentials that do not have permission to access the LOGS folder in %COMMONPROGRAMFILES%\Microsoft Shared\Web server extensions\12\. If this is the case, part of the Upgrade.log is stored in the temporary storage folder of the account that is running the SharePoint Timer service.

To write all available logging information, including verbose output and detailed debugging information, to the log files for the software update installation, run the following command:

msiexec /p <PatchPackage> /l*vx %temp%\patch.log

where PatchPackage is the path to the extracted software update file (.msp)

You can find the log file in the temporary file location with the file name msi*.log.

Note

You can enable Windows Installer logging before you start the software update installation again. To enable logging for Windows Installer, see Microsoft Knowledge Base article 99206: How to enable Windows Installer logging (https://go.microsoft.com/fwlink/?LinkID=99206).

To check version numbers on certain files and registry keys

  • You can examine the version number of specific files in %COMMONPROGRAMFILES%\Microsoft Shared\Web server extensions\12\ISAPI.

    Check the owssvr.dll version number for the update that you installed against the Windows SharePoint Services 3.0 owssvr.dll version numbers that are provided in the "Major updates for Windows SharePoint Services 3.0" table.

  • Verify that the value is correct in the Version key in the following location:

    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\12.0

    Check the owssvr.dll version number for the update that you installed against the Windows SharePoint Services 3.0 owssvr.dll version numbers that are provided in the "Major updates for Windows SharePoint Services 3.0" table.

To verify through direct examination of the SQL schema

  • This SQL Server query can be run on any SharePoint Products and Technologies database to track all the upgrades run on the database in the GUID 00000000-0000-0000-0000-000000000000:

    SELECT * FROM Versions

    The highest value that maps to the preceding GUID should equal the current version of the product. For Service Pack 1 the version should include 6211.

If the installation did not succeed, you can run the SharePoint Products and Technologies Configuration Wizard again, or you can use the following procedure to complete the configuration at the command prompt.

Note

You can enable Windows Installer logging before you start the software update installation again. For information, see Microsoft Knowledge Base article 99206: How to enable Windows Installer logging (https://go.microsoft.com/fwlink/?LinkID=99206).

To force a software update

  1. Open a Command Prompt window and at the command prompt change to the following directory:

    %COMMONPROGRAMFILES%\Microsoft shared\Web server extensions\12\Bin

  2. Type the following command:

    psconfig -cmd upgrade -inplace b2b -wait -force

To view servers in the Farm page

  1. Use one of the following methods to open the servers in the Farm page:

    • On the Central Administration home page, click Operations. Then, on the Operations page, in the Topology and Services section, click Servers in farm.

    • From Internet Explorer, view the following Web page:

      http://ServerName:Port/_admin/FarmServers.aspx

      Where ServerName is the name of the server, and Port is the port that is configured for the Central Administration Web site.

  2. On the Servers in Farm page, next to Version, check the version number of each server in the farm to verify that each one has been updated to the new binary version.

You can verify that the Windows SharePoint Services 3.0 version number for the software update is correct by checking the "Major updates for Windows SharePoint Services 3.0" table.

If the version number matches the version number for the software update, you have succeeded in updating the server. If the version number is not correct, the software update installation did not complete successfully. To identify and resolve the blocking issues, follow the "To view the upgrade log file" procedure earlier in this article.

Add new servers to a server farm (optional)

If you have to build a new server to join an existing server farm, it is recommended that you use an installation source in which the software update files are included. When you use this installation source to add new servers to your server farm, the software update is already applied to the new server and the version of the new server matches the rest of the servers in your server farm.

You can download Windows SharePoint Services 3.0 with SP1 as an updated version at the following location:

You can use the updates folder to create an installation source location that already contains the software updates that match those installed on your server farm by using the updates folder. For more information, see the topic Create an installation source that includes software updates (Windows SharePoint Services 3.0).

If you have to build a new server to join an existing server farm, but you have not created an updated installation source, you must use the following procedure.

To build a server to join an existing farm

  1. Install the product without any software updates and do not run the SharePoint Products and Technologies Configuration Wizard.

    Note

    By not running the SharePoint Products and Technologies Configuration Wizard, you do not define the location for the configuration database by creating the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared Tools\Web server extensions\12.0\Secure\ConfigDB.

  2. Install the software update.

  3. Run the SharePoint Products and Technologies Configuration Wizard at the command prompt.

If you do not follow this process and if you run the SharePoint Products and Technologies Configuration Wizard after you install the released product, the SharePoint Products and Technologies Configuration Wizard reads the ConfigDB registry key and the SharePoint Products and Technologies Configuration Wizard displays the following: Exception: System.InvalidOperationException: Operation is not valid due to the current state of the object. To address this problem, you must either modify the registry or use the command line to force the configuration to complete successfully.

Use Registry Editor to modify the contents of the ConfigDB registry key and then run the SharePoint Products and Technologies Configuration Wizard.

To force an installation after a failed configuration by modifying the registry

  1. Install the software update and do not allow the SharePoint Products and Technologies Configuration Wizard to run.

  2. Use Registry Editor to modify the setup type to a clean installation. Change the registry key to the following:

    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared Tools\Web server extensions\12.0\WSS\"SetupType"="CLEAN_INSTALL"

  3. Run the SharePoint Products and Technologies Configuration Wizard to perform a disconnect operation.

  4. Run the SharePoint Products and Technologies Configuration Wizard to connect to your server farm.

Use the Psconfig command-line tool.

To force an installation after a failed configuration (command line)

  1. Install the product without any software updates and do not run the SharePoint Products and Technologies Configuration Wizard.

  2. Install the software update and do not run the SharePoint Products and Technologies Configuration Wizard.

  3. Open a Command Prompt window and at the command prompt type the following:

    psconfig -cmd configdb -connect -server <SQLServerName> -database SharePoint_Config_<dbname> -user <domainusername> -password <password> -cmd helpcollections -installall -cmd secureresources -cmd services -install -cmd installfeatures -cmd applicationcontent -install

Update language template packs

For each language template pack installed on a server that renders content, you must install updated language template packs. To install the language template packs, you can download updated language template packs through the Microsoft Download Center. However, it is recommended that you browse to the Microsoft Update or Windows Update Web sites to detect the language template packs installed on your front-end Web server. An updated language template pack is installed for each language template pack that is currently installed.

You must run the SharePoint Products and Technologies Configuration Wizard after updated language template packs have been installed for each currently installed language template pack.

To create an installation location that you can use to install the language template packs with software updates already applied, see the topic Create an installation source that includes software updates (Windows SharePoint Services 3.0).

See Also

Other Resources

Windows SharePoint Services TechCenter