Distribute product updates for Office 2010

 

Applies to: Office 2010

Topic Last Modified: 2011-09-10

Learn about the deployment methods that are used to deploy software updates for Microsoft Office 2010, Project 2010, and Visio 2010 clients.

In this article:

• Windows Installer versions

• Maintaining existing Office 2010 installations

• Using enterprise deployment tools to deploy updates

• Choosing an update strategy

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 (https://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.

Windows Installer versions

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:

• Windows Installer (https://go.microsoft.com/fwlink/p/?LinkId=111108)

• Released versions of Windows Installer (https://go.microsoft.com/fwlink/p/?LinkID=201918)

• Standard Installer Command-Line Options (https://go.microsoft.com/fwlink/p/?LinkId=111106)

Maintaining existing Office 2010 installations

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.

Distributing updates locally

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.

Supported baselines

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 (https://go.microsoft.com/fwlink/p/?LinkId=108468).

Using enterprise deployment tools to deploy updates

You can use any of the following methods to distribute software updates to users in your enterprise environment:

• Microsoft Update

• Windows Server Update Services

• System Center Configuration Manager 2007

• Microsoft Self-Extractor files

• Updates folder

  Note

  The Updates folder method is used only for deployment of software updates when you are performing an initial installation of Office 2010.

Microsoft Update

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 (https://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):

• Contact Us: Launches the default client browser to Office.com for product support contact information.

• Getting Started: Launches the default client browser to the Office.com website.

• Check for Updates: Launches the default client browser to the Microsoft Update website.

The Disable commands under File tab | Help policy does not prevent users from searching the Microsoft Download Center for updates or from directly using the Microsoft Update site, which also provide Office software updates. For information about Group Policy and how to configure Group Policy settings, see Group Policy overview for Office 2010 and Use Group Policy to enforce Office 2010 settings.

Windows Server Update Services

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.

For information about WSUS, see Windows Server Update Services 3.0 SP2 Step By Step Guide (https://go.microsoft.com/fwlink/p/?LinkID=199899).

System Center Configuration Manager 2007

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.

For more information about Configuration Manager 2007, see System Center Configuration Manager 2007 (https://go.microsoft.com/fwlink/p/?LinkID=119683) and Deploy software updates (https://go.microsoft.com/fwlink/p/?LinkID=201489).

Microsoft Self-Extractor files

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.

For information about how to use the Updates folder for updates that are deployed with initial installations, see Deploying software updates with the initial Office 2010 installation.

The following sections provide information about how to use Microsoft Self extractor files:

• Microsoft Self-Extractor command-line switches

• Deploying all Microsoft Self-Extractor packages in a folder

• Sample batch file

• Sample script

Microsoft Self-Extractor command-line switches

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.
/forcerestart	Forces a restart of the computer when the update is complete.
/? /h /help	Displays a help message.

For more information about the command-line switches, see Microsoft Knowledge Base article 912203: Description of the command-line switches that are supported by a software installation package, an update package, or a hotfix package that was created by using Microsoft Self-Extractor (https://go.microsoft.com/fwlink/p/?LinkId=108354).

Deploying all Microsoft Self-Extractor packages in a folder

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.

Sample batch file

The following batch file first deletes an existing log file and then it installs all the Microsoft Self-Extractor files that are contained in the directory in which you have placed the batch file.

@echo off

del %temp%\oupdates.txt /q

for /f "delims=-; tokens=1,2,3,4,5" %%i in ('dir /b *kb*.exe') do echo %%j-%%i-%%k-%%l-%%m >> %temp%\oupdates.txt

for /f "delims=-; tokens=1,2,3,4,5" %%i in ('type %temp%\oupdates.txt') do %%j-%%i-%%k-%%l-%%m /log:%temp%\officeupdates.log /passive /norestart

Sample script

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.

Dim wShell 'As WshShell

Dim fso 'As FileSystemObject

Dim f 'As File

Dim sLogName 'As String

Dim sPatchFolder 'As String

Dim sPatchCmd 'As String

Const kTempFolder = 2

On Error Resume Next

sPatchFolder = Replace(Wscript.ScriptFullName, Wscript.ScriptName, "")

Set fso = CreateObject("Scripting.FileSystemObject")

Set wShell = CreateObject("WScript.Shell")

For Each f In fso.GetFolder(sPatchFolder).Files

If UCase(Right(f.Name, 4)) = ".EXE" Then

sLogName = fso.GetSpecialFolder(kTempFolder) & "\" & Left(f.Name, Len(f.Name) - 3) & "log"

sPatchCmd = f.Path & " /quiet /norestart /log:" & sLogName

wShell.Run sPatchCmd, 0, True

End If

Next

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 (https://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

1. Download the software update file. For example, download the Update for Microsoft Office 2010 (KB2202188) 32-bit Edition (https://go.microsoft.com/fwlink/p/?LinkId=201488).

2. 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.

3. Run the customized batch file or script (based on the samples in Deploying all Microsoft Self-Extractor packages in a folder) to install all the Microsoft Self-Extractor files that are contained in the C:\Office2010Updates folder.

For information about how to use the Updates folder to incorporate the installation of updates with an initial installation of the Office 2010 products, see Deploying software updates with the initial Office 2010 installation.

Updates folder

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:

• Deploying software updates with an initial Office 2010 installation

• Testing and verifying the Windows Installer patch (.msp) files

• Modifying the Config.xml file to specify an alternate location for updates

• SetupUpdates Syntax

• Modifying the SetupUpdates element in Config.xml

Deploying software updates with an initial Office 2010 installation

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.

Note

The following procedure pertains only to initial installations of Office 2010. For information about how to deploy software updates after an initial installation of the Office 2010 by using Microsoft Self-Extractor files, see Deploying all Microsoft Self-Extractor packages in a folder.

To install software updates by using the Updates folder

1. Copy the compressed Office 2010 CD image to a network location. For information, see Create a network installation point for Office 2010.

2. 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.

3. 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.

4. Download the Update for Microsoft Office 2010 (KB2202188) 32-bit Edition (https://go.microsoft.com/fwlink/p/?LinkId=201488).

5. 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.

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

7. 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

1. 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:

   Office2010-kbxxxxxxx-fullfile-x86-glb.exe /extract:"c:\UpdatesToInstall"

2. Navigate to the UpdatesToInstall directory. Type the following at the command prompt:

   cd c:\updatestoinstall

3. For each .msp file that is extracted in the C:\UpdatesToInstall folder, run the msiexec /update [update.msp] command. For example, type the following at the command prompt:

   msiexec.exe /update clview.msp /l*v "clview.log"

   After the .msp files are extracted, you can also double-click the .msp file to install the updates. However, double-clicking the .msp does not provide additional logging.

   Note that you can also install multiple .msp files at the same time by separating the file names with a semicolon (;). For example, type the following at the command prompt:

   msiexec.exe /update clview.msp;access.msp /l*v "updates.log"

Testing and verifying the Windows Installer (.msp) files

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

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

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

3. Verify that your applications are running as expected.

4. 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."

   oWShell.Popup sMessage,20,"Office Patch Collector"

   'Get all applied patches

   Set Patches = oMsi.PatchesEx(PRODUCTCODE_EMPTY,MACHINESID,MSIINSTALLCONTEXT_MACHINE,MSIPATCHSTATE_APPLIED)

   On Error Resume Next

   'Enum the patches

   For Each patch in Patches

      If Not Err = 0 Then Err.Clear

       'Connect to the patch file

       Set msp = oMsi.OpenDatabase(patch.PatchProperty("LocalPackage"),MSIOPENDATABASEMODE_PATCHFILE)

       Set SumInfo = msp.SummaryInformation

       If Err = 0 Then

           If InStr(SumInfo.Property(PID_TEMPLATES),OFFICEID)>0 Then

               'Get the original patch name

               Set qView = msp.OpenView("SELECT `Property`,`Value` FROM MsiPatchMetadata WHERE `Property`='StdPackageName'")

               qView.Execute : Set record = qView.Fetch()

               'Copy and rename the patch to the original file name

               oFso.CopyFile patch.PatchProperty("LocalPackage"),sTargetFolder&"\"&record.StringData(2),TRUE

           End If

       End If 'Err = 0

   Next 'patch

   oWShell.Run "explorer /e,"&chr(34)&sTargetFolder&chr(34)

5. Verify that all needed .msp files are in the target folder (%Temp%\Updates).

6. Copy all .msp files from %Temp%\Updates on the test computer to the Updates folder on the Office 2010 network installation point.

Modifying the Config.xml file to specify an alternative location for updates

Administrators can direct Setup to look for updates in a folder other than the Updates folder by using the SetupUpdates element in the Config.xml file.

SetupUpdates Syntax

SetupUpdates in Config.xml uses the following syntax:

<SetupUpdates [CheckForSUpdates="Yes" | "No"] [SUpdateLocation="path-list"]/>

The SetupUpdates attributes are listed in the following table.

Attribute	Description
CheckForSUpdates	Setup uses the path list in SUpdateLocation to find Setup customization files. The default value is Yes. 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.

Modifying the SetupUpdates element in Config.xml

Administrators can modify the SetupUpdates element in the Config.xml to specify an alternative location for updates.

To modify the SetupUpdates element in Config.xml

1. Open the Config.xml file in a text editor tool, such as Notepad.

2. Enter the options that you want to use for the SetupUpdates element, as shown in the following syntax example:

   <SetupUpdates CheckForSUpdates="Yes" SUpdateLocation="\\server1\share;\\server2\share" />

   In this case, path-list lists the fully qualified paths to folders, separated by semicolons ("\\server1\share;\\server2\share").

3. Save the Config.xml file in the same folder that contained this file before you edited it.

For more information about the SetupUpdates element of the Config.xml file, see SetupUpdates element in Config.xml file in Office 2010.

Choosing an update strategy

Use the criteria in the following table to help determine the recommended software update solution for your organization.

Customer type	Need	Recommended solutions
Large enterprise	Advanced software update management	System Center Configuration Manager 2007 Updates folder (only for initial installations) Note If the customization is different for different groups of users, you might want to select a different location for the .msp files.
	Distribution of Microsoft Updates only	Windows Server Update Services
Medium enterprise	Advanced software update management	System Center Configuration Manager 2007 Updates folder (only for initial installations) Note If the customization is different for different groups of users, you might want to select a different location for the .msp files.
	Distribution of Microsoft Updates only	Windows Server Update Services
Small business	Distribution of Microsoft Updates in environments that have at least one Windows-based computer and one IT administrator	Windows Server Update Services
	All other scenarios	Microsoft Update Microsoft Self-Extractor files Updates folder (only for initial installations) Note The Updates folder is only applicable for .msp files.
Consumer	All scenarios	Microsoft Update

See Also

Concepts

Setup architecture overview for Office 2010
Deploy Office 2010 by using System Center Configuration Manager 2007
Config.xml file in Office 2010
Office Customization Tool in Office 2010
Error codes for Office 2010 update packages