Distribute updates for Office 2013 products

Applies to: Office 2013

Summary: Explains the software updates process and how to deploy updates for Windows Installer-based (MSI) Office 2013, Project 2013, and Visio 2013.

Audience: IT Professionals

After a new release of Office, Microsoft makes available a series of software updates to help improve application security, performance, and reliability. This article lists and describes the types of software updates that are available for Windows Installer-based Office and the deployment methods that are used to deploy software updates for Office 2013, Project 2013, and Visio 2013 clients.

In this article:

• Windows Installer versions

• Maintaining existing Office 2013 installations

• Using enterprise deployment tools to deploy updates

• Choosing an update strategy

Microsoft releases the kinds of software updates that are listed in the following table.

Types of software updates for Office

Software updates are released as full-file updates that replace all files that are changed by an update. Because complete files are installed, full-file updates typically do not require access to the original Office installation source.

Note that service packs for Office products are available only as updates 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 2013 update deployment is Windows Installer 3.1. Note that Windows Installer 4.5 was released with 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 website:

• Windows Installer

• Released versions of Windows Installer

• Standard Installer Command-Line Options

Maintaining existing Office 2013 installations

Deployment features in Office 2013 simplify the process of selecting an updating strategy. You distribute all updates directly to the client to make sure that your existing Office 2013 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. Users can apply the update in most cases, even if they do not have access to the source. Office 2013 Setup creates a local installation source on users' computers as part of the default installation process. Setup installs all Office 2013 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 or elevated rights are required to install Office 2013 and product updates. Elevated rights refers to an account or process that is operating or logged into the computer that has full administrator rights or permissions. The recommended approach in enterprise environments is to use a software distribution tool such as Microsoft System Center 2012 Configuration Manager to deploy the updates. System Center 2012 Configuration Manager uses elevated rights. For more information about Office 2013 deployment, see Deployment methods for Office 2013.

Distributing updates locally

Setup copies installation files to a hidden folder on the local computer when users install Office 2013. 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 Required local installation source in Overview of Setup architecture for Office 2013.

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 action that requires access to the source.

Supported baselines

The original release of the Office 2013 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 2013 Service Pack 2 (SP2) becomes available to users who have updated to Service Pack 1 (SP1).

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 2012 Configuration Manager

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

Microsoft Update

Microsoft Update (Windows Update on computers that are running Windows 7) 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, such as Windows and Office. For more information about Microsoft Update, see Microsoft Update Home.

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 2013\Disable Items in User Interface node in the Group Policy Management Console Microsoft Management Console (MMC) snap-in.

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 provides Office software updates. For information about Group Policy and how to configure Group Policy settings, see Overview of Group Policy for Office 2013.

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 organization’s network. WSUS connects to Microsoft Update to retrieve the latest software updates and synchronizes the updates with your organization’s 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.

System Center 2012 Configuration Manager

System Center 2012 Configuration Manager 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 System Center 2012 Configuration Manager to first deploy Office, you can use it to distribute product updates to a mixture of Microsoft Windows clients.

When you use System Center 2012 Configuration Manager to maintain Office, you can set a precise control over the deployment process. For example, you can use System Center 2012 Configuration Manager 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 System Center 2012 Configuration Manager, see Microsoft System Center 2012 Configuration Manager and Software Updates in Configuration Manager.

Microsoft Self-Extractor files

Microsoft Self-Extractor is used to combine software installation updates, 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 System Center 2012 Configuration Manager 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.

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

Command-line switches

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.

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 can continue. Note that both the batch file and the script are intended as examples. You might have to configure them for your specific scenarios.

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 put 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 that is 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 Office 2013 by using Microsoft Self-Extractor files, you can use a text editor, such as Notepad, to change 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 Outlook 2013 (KB2737132) 32-Bit Edition 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 Outlook 2013 (KB2737132) 32-Bit Edition.

2. Save the download .exe file (which is outlook2013-kb2737132-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:\Office2013Updates.

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:\Office2013Updates folder.

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

Updates folder

If you are deploying an initial installation of Office 2013 and you also have to deploy Office 2013 software updates, such as service packs or hotfixes, Setup can apply them as part of the initial installation process. If you are installing Office 2013 after Office 2013 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 are located in the installation point in the Updates folder. Only one Setup customization .msp file per product in the Updates folder is supported. A Setup customization .msp file is created by using the Office Customization Tool (OCT).

During the initial installation, Setup checks the Updates folder for.msp files that are relevant to the Office 2013 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 .msp file together with Office updates, you should change the file name of the customization .msp file to make sure that it is installed first. For example, change Custom.MSP to 1_Custom.MSP.

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

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

• Deploying software updates with an initial Office 2013 installation

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

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

• SetupUpdates Syntax

• Using the SetupUpdates element in Config.xml

Deploying software updates with an initial Office 2013 installation

Administrators can use the Updates folder to incorporate the installation of updates with an initial installation of the Office 2013 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 .msp file, we recommend that you rename the customization file so that it is installed first. Setup.exe processes only one .msp file 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 make sure that it is processed first.

The following procedure uses the Update for Microsoft Outlook 2013 (KB2737132) 32-Bit Edition as an example. It shows how to install the update package (outlook2013-kb2737132-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.

To install software updates by using the Updates folder

1. Download the Office 2013 ISO image and burn the image to a DVD, and then copy the content to a network location. For information, see Deploy Office 2013 from a network installation point.

2. Use the Office Customization Tool to make any necessary modifications to the installation. Save the Setup customization .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 (OCT) reference for Office 2013.

3. To change 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 change 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 reference for Office 2013.

   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 2013 source files.

4. Download the Update for Microsoft Outlook 2013 (KB2737132) 32-Bit Edition.

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

   outlook2013-kb2737132-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 2013 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.

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

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

   Office2013-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 2013 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 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 2013 applications that will be installed on users’ computers.

2. Run Microsoft Update to apply all the necessary Office 2013 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 the required .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 2013 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.

SetupUpdates attributes

Using the SetupUpdates element in Config.xml

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

To use 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 reference for Office 2013.

Choosing an update strategy

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

Criteria for determining appropriate software update solutions

See also

Overview of Setup architecture for Office 2013
Config.xml file reference for Office 2013
Office Customization Tool (OCT) reference for Office 2013