After a new release of Microsoft Office, Microsoft makes available a series of software updates to help improve application security, performance, and reliability. Microsoft releases the kinds of software updates that are listed in the following table.

Update

Definition

Service pack

A tested, cumulative set of hotfixes, security updates, critical updates, and software updates. Service packs might also contain a limited number of customer-requested design changes or features. A service pack represents a new baseline version of the product.

Security update

A widely released fix for a product-specific, security-related vulnerability. Security-related vulnerabilities are rated based on their severity, which is indicated in the Microsoft security bulletin as critical, important, moderate, or low.

General update

A widely released fix for a specific problem that addresses a very important issue that is not security-related.

Hotfix

A single, cumulative package that is made up of one or more files that address a problem in a product. Hotfixes address a specific customer situation and might not be distributed outside the customer organization.

Software updates are released as full-file updates that replace all files that are modified by an update. Because complete files are installed, full-file updates typically do not require access to the original Office installation source. For information about the latest updates for Office 2010 and related products, see the Update Center for Microsoft Office, Office Servers, and Related Products (http://go.microsoft.com/fwlink/p/?LinkId=197069).

Note that service packs for Office products are available only as patches to the installed product. They are not integrated with the base Office system products.

The minimum version of Windows Installer that is required for Office 2010 patch deployment is Windows Installer 3.1. Note that Windows Installer 4.5 was released with Windows Vista with Service Pack 2 (SP2) and Windows Server 2008 with Service Pack 2 (SP2). Windows Installer 5.0 was released with Windows Server 2008 R2 and Windows 7. For more information about Windows Installer, see the following resources on the MSDN Web site:

Deployment features in Office 2010 simplify the process of selecting an updating strategy. You distribute all updates directly to the client to ensure that your existing Office 2010 system installations have the latest software updates.

Users can apply multiple full-file updates directly to client computers. For example, a user can apply a full-file security update, followed by a full-file critical update, and so on. Full-file updates completely replace all files that are affected by the update. For example, you can send the full-file update if a user's local installation source is corrupted and the user does not have access to a source on the network. Users can apply the update in most cases, even if they do not have access to the source. Office 2010 Setup creates a local installation source on users' computers as part of the default installation process. Setup installs all Office 2010 products in a two-step process. Setup first copies the compressed installation source files to users' computers, and then Setup calls Windows Installer to perform the actual installation from the local installation source. After the installation, the local installation source remains available for any Setup maintenance operations that require access to the original source, such as applying software updates, for example.

Administrative rights are required to install Office 2010 and any subsequent product updates. This means that users must also be administrators of their computers, or you must be able to grant administrative privileges to users to perform the installation. For more information, see Deploy Office 2010 to users who are not administrators.

Note

In Microsoft Office 2003, large organizations typically installed the product from an administrative installation point. Installing the product from a local installation source was optional. In Office 2010 and in the 2007 Office system, the administrative installation option does not exist. The local installation source is required. Because you apply all updates directly to clients, the network source remains unchanged. Client installations remain synchronized with the original source.

Setup copies installation files to a hidden folder on the local computer when users install Office 2010. Windows Installer uses this local installation source to install Office at first and to repair and update Office later. For more information about the local installation source, see Setup architecture overview for Office 2010.

We recommend that you use a local update strategy in most cases, especially if you:

Distribute software updates to different groups of users or at different times.

Have network bandwidth limitations.

Support users who have limited or unreliable network access, for example, traveling users.

Because a local installation source is always available, offline users can perform any operation that requires access to the source.

The original release of the Office 2010 represents the initial baseline of the product, and each successive service pack represents a new baseline.

Full-file updates are typically supported on the two most recent baselines. For example, you can deploy an update that is released after Office 2010 Service Pack 2 (SP2) becomes available to users who have updated to Service Pack 1 (SP1).

Note

The previous baseline is supported for only 12 months after release of the latest service pack. For example, software updates are supported on SP1 for 12 months after Office 2010 SP2 is released. After the 12-month period, full-file updates target only client computers that are updated with SP2. For more information about the Microsoft Support Lifecycle, see Microsoft Support Lifecycle policy (http://go.microsoft.com/fwlink/p/?LinkId=108468).

Microsoft Update (Windows Update on computers that are running Windows 7, and Windows Vista and Windows Server 2008 families) allows users who connect directly to the Internet to manage their own computers and download the latest software updates. Users can set up an automatic schedule to periodically check for and retrieve updates. We recommend that users use Microsoft Update, which provides a centralized and automated software update solution for Microsoft products, including Windows and Microsoft Office. For more information about Microsoft Update, see Microsoft Update Home (http://go.microsoft.com/fwlink/p/?LinkId=201921).

In an Active Directory managed environment, you can control access to Office.com and Microsoft Update from Office applications by using the Disable commands under File tab | Help Group Policy setting. This setting is available in the User Configuration\Administrative Templates\Microsoft Office 2010\Disable Items in User Interface node in the Group Policy Object Editor Microsoft Management Console (MMC) snap-in.

If you enable the Disable commands under File tab | Help policy setting, you can decide to disable the following options (which are available in the user interface of Office 2010 applications by clicking the File tab, and selecting Help in the Microsoft Office Backstage view):

Windows Server Update Services (WSUS) is a free tool that you can use to deploy the latest Microsoft product updates within your corporate network. WSUS connects to Microsoft Update to retrieve the latest software updates and synchronizes the updates with your corporate WSUS server. You can configure an automatic or manual synchronization. The primary WSUS server can be used to update other WSUS servers on the network.

System Center Configuration Manager 2007 is a software distribution tool that is designed for medium- and large-sized organizations that manage many clients in a complex and quickly changing business environment. In addition to using Configuration Manager 2007 to first deploy Office, you can use it to distribute product updates to a mixture of Microsoft Windows clients.

When you use Configuration Manager 2007 to maintain Office, you can set a precise control over the deployment process. For example, you can use Configuration Manager 2007 to query client computers for software requirements before you install Office, and you can target the installation to computers that meet your criteria.

Microsoft Self-Extractor is used to combine software installation updates, patches, and hotfixes into self-extracting executable files called Microsoft Self-Extractor packages. Administrators can install these packages by double-clicking the .exe file or by running the .exe file at a command prompt. This deployment option is useful if you do not have Configuration Manager 2007 or WSUS.

You can use a switch to specify package deployment and logging options when you run the .exe file to install a package at the command prompt. You can also run the .exe file by using the Search box on the Start menu, or by clicking Start, and then clicking Run.

Note

We recommend that you do not extract and run the .msp files from product patch .exe files. Incorrect application of the .msp files generates an error if the patch does not apply to the product that is installed on the computer. Also, the product might not be completely updated until all required .msp files are applied. The package contains detection logic to determine exactly which patches are applicable and to install only the patches that are needed.
However, if the update is being applied during the initial installation of Office, we recommend that the .msp files be extracted to the Updates folder for installation together with the Office product.
The Microsoft Office Hotfix Installer (Ohotfix.exe) that was used with previous versions of Office is not supported for Office 2010 (or the 2007 Office system). Office 2010 uses a new Microsoft Self-Extractor technology that is incompatible with Ohotfix.

To determine which switches are available for a package, use one of the following Help switches:

/?

/h

/help

The command-line switches that are supported by Microsoft Self-Extractor are listed in the following table.

Switch

Description

/extract:[path]

Extracts the content of the package to the path folder. If a path is not specified, a Browse dialog box appears.

/log:[path of log file]

Enables verbose logging for the update installation. You must also include the file name in addition to the path information. The command does not create a new folder. Therefore, you must use an existing folder name. In addition to the specified file name, a separate log file is created for each .MSI file that you run.

/lang:lcid

Sets the user interface to the specified locale when multiple locales are available in the package.

/quiet

Runs the package in silent mode.

/passive

Runs the update without requiring user interaction.

/norestart

Prevents prompts to the user when a restart of the computer is needed.

This section includes examples of a batch file and a Visual Basic script that can be used to deploy all the Microsoft Self-Extractor packages that are contained in a folder. The batch file and script code is written so that, if a single installation fails, succeeding installations are able to continue. Note that both the batch file and the script are intended as examples. You might have to configure them for your specific scenarios. As mentioned previously, the Microsoft Office Hotfix Installer tool, Ohotfix.exe, is not supported for Office 2010 updates.

The following Visual Basic script provides functionality similar to the previous batch file. This script installs all Microsoft Self-Extractor files that are contained in the folder in which you place the script. The code specifies that the Microsoft Self-Extractor packages be installed silently, and enables logging so that the log files are generated in the user’s %temp% temporary folder, for example, C:\Users\<username>\AppData\Local\Temp\<officeupdate>.log. These switches are not intended for executable (.exe) files other than Microsoft Self-Extractor files. Therefore, we recommend that you do not include other kinds of .exe files in the folder that contains the Self-Extractor files.

If you are deploying software updates after an initial installation of the Office 2010 by using Microsoft Self-Extractor files, you can use a text editor, such as Notepad, to modify the Visual Basic script and batch file samples in this section to suit your specific requirements. Save the files after you complete customizations. You can then run the script or batch file to chain the installation of the new Microsoft Self-Extractor packages. In this case, the basic process is as described in the following procedure, which uses Update for Microsoft Office 2010 (KB2202188) 32-bit Edition (http://go.microsoft.com/fwlink/p/?LinkId=201488) as an example. The information applies to other Office updates also.

To deploy all the Microsoft Self-Extractor packages that are contained in a folder

Save the download .exe file (which is office-kb2202188-fullfile-x86-glb.exe in this example) to your hard disk drive in the same folder that contains the script or batch file that you are using to deploy the Microsoft Self-Extractor packages. For example, save the file to C:\Office2010Updates.

If you are deploying an initial installation of the Office 2010 and you also have to deploy Office 2010 software updates, such as service packs or hotfixes, Setup can apply them as part of the initial installation process. If you are installing Office 2010 after Office 2010 product updates have been released, we recommend that you store those updates in the Updates folder. You can store the updates for any Office-related products that reside in the installation point in the Updates folder. Only one Setup customization .msp patch in the Updates folder is supported. A Setup customization .msp patch is created by using the Office Customization Tool (OCT).

During the initial installation, Setup checks the Updates folder for patches (.msp files) that are relevant to the Office 2010 product that is being installed and applies only one Setup customization .msp file during the installation. Windows sort order is used to determine the order in which to install the first .msp file. The remaining product update files in the Updates folder are installed at the end of the installation. If you are installing a customization patch together with Office updates, you should change the file name of the customization patch to ensure that it is installed first. For example, change Custom.MSP to 1_Custom.MSP.

Setup identifies the customization .msp file that typically resides in the Updates folder during initial deployment. Setup detects customization patches at the beginning of the setup process and passes the patches directly to Microsoft Windows Installer as it installs the Windows Installer (MSI) files for the product. This ensures that the correct option states and other settings that are specified by the administrator are established before applying the product patches. As a result, users receive the latest updates together with Office.

Important

The Updates folder can only be used to deploy software patches during an initial installation of Office 2010. If there is a combination of one Setup customization .msp patch and product update patches, only the Setup customization patch is applied during the deployment phase, and the product update patches are applied after the installation is finished. As noted previously, the Setup customization patch must be deployed first to ensure that modifications such as product key and quiet mode settings are applied.
You cannot use the Updates folder to deploy product updates after the initial installation of Office.

The following sections provide information about how to use the Updates folder:

Administrators can use the Updates folder to incorporate the installation of updates with an initial installation of the Office 2010 products. Only Windows Installer patch files that are contained in this folder are installed during the initial installation. Therefore, you must extract these patches from the Microsoft Self-Extractor package. You can also use this method to install customization patches.

If you use the Office Customization Tool to create a Setup customization patch, we recommend that you rename the customization patch file so that it is installed first. Setup.exe processes only one patch during installation. All other patches that are contained in the folder are chained at the end of the installation. You can rename the customization patch by adding a "1" at the beginning of the file name to ensure that it is processed first.

The following procedure uses Update for Microsoft Office 2010 (KB2202188) 32-bit Edition as an example. It shows how to install the update package (office-kb2202188-fullfile-x86-glb.exe in this example) and highlights the steps that are required to populate the Updates folder with the update patches. The information applies to other Office updates also.

Use the Office Customization Tool to make any necessary modifications to the installation. Save the Setup customization patch (.msp file) to the Updates folder. As noted previously, ensure that the file name begins with “1.” For information about customizations, see Office Customization Tool in Office 2010 and Customize Office 2010.

To modify the Config.xml file, use the Config.xml file that is located in the root of the product folder for the product that you are installing. Use a text editor such as Notepad to modify the file. For example, you can specify installation options (such as the path of the network installation point, the product to install, and custom setup options) and specify the languages to install. For information, see Config.xml file in Office 2010.

When you complete the Config.xml customizations, save the Config.xml file. You can use the /config Setup command-line option to specify the location of the Config.xml file, as shown in the following example:

\\server\share\setup.exe /config \\server\share\ProPlus.WW\config.xml

where \\server\share is the network location that contains the Office 2010 source files.

To extract the .msp patches from the Microsoft Self-Extractor file (office-kb2202188-fullfile-x86-glb.exe in this example), run the .exe file with the /Extract:[extract folder path] switch. For example, type the following at the command prompt:

office-kb2202188-fullfile-x86-glb.exe /extract:"c:\ExtractFiles"

This command begins to extract the .msp files. Prior to beginning the extraction process, Microsoft Software License Terms are displayed. After you accept the license terms, the files are extracted to the location that you specify (C:\ExtractFiles in this example). You do not have to use the quotation marks with the path. However, it does make it easier to read the command line. By using quotation marks, you can also avoid problems with paths that contain spaces.

Copy the Windows Installer patch (.msp) files to the Updates folder.

Repeat the process for any other Office 2010 update packages that you want to install. The Windows Installer patch file names are unique. Therefore, there should be no risk of a file being accidentally overwritten, which could cause a problem with the installation. If you are deploying the product is with additional language packs, the language pack service packs will be added to the Updates folder.

After you complete the previous steps, you can deploy the product.

Note

In some scenarios, customers may be unable to install updates by using the Microsoft Self-Extractor file. A generic error message that resembles the following may display: "The installation of this package failed." In such cases, customers can use the following method to install the updates.

To install a specific software update by using the .msp file

To extract the .msp patches from the Microsoft Self-Extractor file (Office2010-kbxxxxxxx-fullfile-x86-glb.exe in this example), run the .exe file with the /extract:[extract folder path] switch. For example, type the following at the command prompt:

If you want to test updates and verify the list of .msp files before you copy them to the Updates folder on the Office 2010 network installation point, you can first install updates on a test computer, use a Visual Basic script to extract the .msp files to a target folder, and then copy the .msp files from the target folder to the Updates folder. This method is further described in the following procedure.

To extract the .msp files from a test computer and copy them to the Updates folder

On the test computer, install all Office 2010 applications that will be installed on users’ computers.

Run Microsoft Update to apply all the necessary Office 2010 updates on the test computer.

Verify that your applications are running as expected.

Save the following Visual Basic script as “CollectUpdates.vbs.” Then run it to extract the update files that are installed on the test computer to a target folder. The script uses %Temp%\Updates as the target folder, where %Temp% is the Windows temporary folder.

Dim oMsi,oFso,oWShell

Dim Patches,SumInfo

Dim patch,record,msp

Dim qView

Dim sTargetFolder,sMessage

Const OFFICEID = "000-0000000FF1CE}"

Const PRODUCTCODE_EMPTY = ""

Const MACHINESID = ""

Const MSIINSTALLCONTEXT_MACHINE = 4

Const MSIPATCHSTATE_APPLIED = 1

Const MSIOPENDATABASEMODE_PATCHFILE = 32

Const PID_SUBJECT = 3 'Displayname

Const PID_TEMPLATES = 7 'PatchTargets

Set oMsi = CreateObject("WindowsInstaller.Installer")

Set oFso = CreateObject("Scripting.FileSystemObject")

Set oWShell = CreateObject("Wscript.Shell")

'Create the target folder

sTargetFolder = oWShell.ExpandEnvironmentStrings("%TEMP%")&"\Updates"

If Not oFso.FolderExists(sTargetFolder) Then oFso.CreateFolder sTargetFolder

sMessage = "Patches are being copied to the %Temp%\Updates folder." & vbCrLf & "A Windows Explorer window will open after the script has run."

If the value is set to No, Setup does not search for Setup customization files by using the path list in SUpdateLocation.

SupdateLocation="path-list"

Specifies a list of fully qualified paths to folders, separated by semicolons.

Setup looks in all the specified folders for Setup customization files that were created for the product that is being installed, and applies them in alphabetical order, by file name. If a Setup customization file is specified on the Setup command line, that file is applied first, followed by any files that were found in the folder that was specified by the SetupUpdates element.

Customization files are product-specific. Setup applies only those files that are relevant to the product being installed. However, if you store more than one customization file for the same product in the Updates folder, Setup applies all files to the user's configuration in alphabetical order.