The Package Installer (Formerly Called Update.exe) for Microsoft Windows Operating Systems and Windows Components
The Package Installer for Windows and Windows Components
On This Page
Introduction
The installation of software updates is typically an automated process that requires little input from you. If you are an information technology (IT) administrator, however, it might be necessary for you to understand the package installer (which was formerly referred to as Update.exe) and the installation process so that you can make informed deployment decisions for your organization.
This paper provides in-depth information about the following:
| • | The files that make up the package installer. |
| • | The processes involved in installing software updates. |
| • | How a software update package is structured. |
| • | Methods you can use to deploy software updates. |
| • | How to remove software updates. |
| • | How to troubleshoot problems you might encounter while installing software updates. |
The information in this paper is current as of March 2005. For updated information about topics covered in this paper, see the Microsoft Web site.
Package Installer Overview
The package installer is used to install software updates for Microsoft® Windows® operating systems and other Microsoft products.
In the past, the package installer was called Update.exe. However, this was not quite accurate because although the package installer does contain a file called Update.exe, it includes other files as well.
Therefore, for the purposes of this document, the term “package installer” refers to the product that includes Update.exe and its supporting files. See Contents of the Software Update Package for more detailed information about the files the software update package contains, including the package installer.
The actual file name of the package is determined by the operating system and the Microsoft Knowledge Base article number that identifies the issues being addressed by the software update.
Software updates for Microsoft Windows 2000 Service Pack 3 (SP3) and later, Windows XP, and Windows Server™ 2003 operating systems include the package installer detailed in this document, which includes the file Update.exe. However, all Windows NT 4.0 and Windows 2000 Service Pack 2 (SP2) and earlier software updates include Hotfix.exe, the predecessor of Update.exe. Other Microsoft products such as Microsoft SQL Server™ and Exchange Server also package some software updates with Update.exe.
Installers for Microsoft products are limited to the package installer and Microsoft Windows Installer (also known as the MSI Installer). For more information about Windows Installer, see the Platform SDK on the Microsoft Developers Network (MSDN).
Installation Overview
Microsoft releases software updates in a software package that is a single, self-extracting, executable file. This file includes Update.exe, the supporting files, and the “payload,” which consists of newer versions of files currently on the system. The package installer updates the files that are currently on the system with these newer versions. The package installer can add new files; delete or replace existing files; add, remove, or update registry keys; and back up files and registry entries that will change before installation.
The following figure provides an overview of the process the package installer uses to install software updates.
Figure 1 - Installation overview
For a more detailed diagram of the process the package installer uses to install software updates see Appendix C –Package Installer Process Flow.
Installation Process
The following sections describe the steps in the installation process.
File Extraction
When you run the executable file for the package, its contents are extracted into a temporary extraction directory. The location of that directory can be randomly generated by the package installer, or you can specify it as part of a command-line option. If you do not specify a path, the package installer determines which drive on the local fixed disks has the most disk space. It then uses a Windows application programming interface (API) to generate a random name for the extraction directory and places the directory at the root of the drive. For more information, see Extracting Update Package Contents Prior to Deployment.
Analysis and Inventory
The software update installation begins from the extraction directory that was just described. The Update.inf configuration file that is a part of the package installer includes the installation logic and registry changes that are required to install the software update. The package installer identifies which files to install and examines the currently installed versions of those files. If the current version is the same as or newer than the version being installed, the package installer does not update the file. In rare cases where the version numbers are identical, but the file hashes are different, the package installer updates the file.
File Archiving
Before any changes are made to the files or the registry, the package installer archives in an uninstall directory a copy of the files that already exist on the system. (For more information about removing software updates, see Removing Software Updates later in this document.) The uninstall directory also contains Spuninst.exe, an executable file that will remove the update, and Spuninst.inf, a configuration file that includes the logic and registry changes needed to direct the removal of the software update.
File Copy and Cleanup
After the package installer has completed the archiving process, it copies the new files to your computer and makes the appropriate registry changes. After the software update is applied, the package installer runs any final processes listed in the configuration file and logs the installation in Event Viewer. It performs a final cleanup that deletes the temporary directories created during the installation and removes from the registry the list of software updates contained in the service pack. In some cases, you might need to restart the computer to complete the installation.
Registry Entries for Software Updates
When you install a software update, entries are added to the registry that document the installation process. These entries include details concerning which files have been installed, and where to find the archive directory if you should ever want to remove the software updates. These registry entries can be used by Microsoft Baseline Security Analyzer V1.2.1 (MBSA), the QFE check tool, Add or Remove Programs, and other non-Microsoft tools to identify and display the fixes that are currently installed on your system. For more information about the QFE check tool, see Qfecheck.exe Verifies the Installation of Windows 2000 and Windows XP Hotfixes on the Microsoft Web site.
A service pack contains all of the software updates released since the previous service pack or commercially released version of the product. When you install a service pack, entries for updates contained in the service pack are removed from the registry and replaced with one registry entry for the service pack itself.
Note: Removing a service pack will restore any previously installed updates, their registry keys, and their entries in Add or Remove Programs.
Two registry locations are written when a software update is installed. These are commonly referred to as the Updates and Add or Remove Programs keys. The Updates key contains details about all Microsoft software updates. The Add or Remove Programs key contains information about Microsoft software updates that are displayed in Add or Remove Programs. A third registry key, called Hotfix, contains limited information about some Windows software updates.
Note: Because many software update installations no longer populate the Hotfix registry key, do not use this registry key to validate that a software update is installed. It might be installed and not appear in this registry key. Instead, use the Updates registry key.
Software updates are identified by the letters KB or Q, followed by the number of the Microsoft Knowledge Base (KB) article. Software updates released in 2003 and later use a preceding KB; software updates released before 2003 are preceded by the letter Q.
The Updates Registry Key
The Updates registry key lists Windows and other Microsoft software updates installed by the package installer. For service packs and some software updates, only the summary information is provided. For most other software updates, however, the Updates registry key provides file list entries in addition to the summary information.
Summary information
The summary information provided in the Updates registry key includes details about the software update. You can find this information at the following location:
HKEY_LOCAL_MACHINE\Software\Microsoft\Updates\Product\SPX\KB######
Product –The product for which the software update is being installed (such as Windows or SQL Server).
SPX – The number of the service pack (SP) in which the software update is contained. For Windows service packs and non-Windows software updates, this part of the registry key might not be present.The following example shows the registry key you would use to obtain this summary information if you were to install a post-Service Pack 1 (SP1) software update for Windows XP:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Updates\Windows XP\SP2\KB823980
The following table lists and describes the registry key values for the Updates key that can apply to a software update. (Not all of the keys listed in the table will necessarily be populated for every software update.)
Table 1 – Summary Registry Key Values for a Software Update
| Key | Description |
PackageName or Description | Name of the software update package. |
PackageVersion | Package version number. For more information, see Package Versioning later in this document. |
Publisher | Always Microsoft Corporation. |
PublishingGroup | Identifies the Microsoft product team releasing the software update. This value is not populated for most updates. |
Releasetype or Type | Type of software update (such as an update, update rollup, service pack, feature pack, critical update, security update, or hotfix). |
ARPLink | Link to Add or Remove Programs key in the registry. |
InstalledBy | User who installed the software update. |
InstalledDate | Date the software update was installed. |
InstallerName | The installer that was used. This is Update.exe for all examples discussed in this document. |
InstallerVersion | Version of the package installer. |
UninstallCommand | The path to the removal command for the software update. You can run this command to remove the software update. If the /nobackup command-line option was used to install the software update, however, this entry will be blank. For more information, see Command-line Options later in this document. |
File list information
The file list registry key provides a list of the files installed by the software update. You can find the file list key at the following location:
HKEY_LOCAL_MACHINE\Software\Microsoft\Updates\Product\Service Pack\KB######\Filelist
The following example shows the location of the file list registry key that would apply if you were to install a post-SP1 update for Windows XP:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Updates\Windows XP\SP2\KB823980\Filelist
Under the file list registry key are subkeys numbered 0 through n, one for each file installed as part of the software update.
The following table lists subkeys and their descriptions. (Not all subkeys listed will necessarily be populated for every software update.)
Table 2 - File List Registry Subkeys
| Subkey | Description |
FileName | Name of the file installed. |
WhyIncluded | Why this file was included in the software update. Affected – The updated file. Dependent Binary – File or files that the updated file is dependent on. Supporting – File or files that the software update requires. Note: This value is not populated for most Windows software updates. |
FileVersion or Version | File version. |
BuildDate | Date file was built. |
BuildCheckSum | File checksum information. |
InstallLocation or Location | Where file is installed. |
Notes: If the software update type listed in the Summary key is service pack, there will not be a file list because the number of files included in a typical Windows service pack is very large. For a list of the files included in a particular service pack, see the corresponding Microsoft Knowledge Base article for that service pack release.
Some Microsoft software updates will not contain file list information because the software updates are cumulative and would therefore cause the size of the registry to increase with duplicate information.
The Add or Remove Programs Registry Key
Software updates are listed individually in Add or Remove Programs in Control Panel. Add or Remove Programs uses the following registry key to track installed software:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall
Information for software updates and other installed programs is available in this registry key. Software updates are listed by their Knowledge Base article number, under the entry for the Microsoft product that has been updated.
You can view installed software updates by performing the following procedure.
To view installed software updates
1. | Open Control Panel, and then double-click Add or Remove Programs. |
2. | In Add or Remove Programs, you will see a list of all programs and software updates installed on your computer. |
3. | To view more information about a particular software update, locate its entry in the list in Add or Remove Programs, and click to select it. |
Note: Software update packages that were built with a package installer version 5.3.18.6 or later, and that were installed using the /nobackup option will include an entry in Add or Remove Programs, but they will not include a Remove button. Software update packages installed with the /nobackup option and with a package installer version prior to 5.3.18.6 might not even include the entry in Add or Remove Programs. For more information, see Appendix A – Installer Versioning and Features.
The following table lists and describes Add or Remove Programs registry keys. (Some keys listed in the table might not be populated for every software update.)
Table 3 - Add or Remove Programs Registry Key Listing
| Key | Description |
Comments | General comments. Not present in all updates. |
DisplayName | Text displayed in the Add or Remove Programs entry. |
DisplayVersion | Version of the update installed. See Package Versioning for more information. |
Helplink | Link to Microsoft Knowledge Base article. |
NoModify | Determines whether the Change button appears in Add or Remove Programs. |
NoRemove | Determines whether the Remove button appears in Add or Remove Programs. |
NoRepair | Determines whether the Repair button appears in Add or Remove Programs. |
ParentKeyName | Registry key name of the application in Add or Remove Programs that the fix applies to. Also used to differentiate between Windows and non-Windows updates. |
ParentDisplayName | Used by Add or Remove Programs when the parent listed in ParentKeyName is not found. This name is used to create a virtual entry if necessary. This is necessary for the operating system, which has no parent in Add or Remove Programs. |
Publisher | Value is Microsoft Corporation for all software updates published by Microsoft. |
RegistryLocation | Registry key for the software update itself. |
ReleaseType | Indicates type of software update. |
UnInstallString | Path to software update removal program. |
URLInfoAbout | URL under the Publisher link in the Support Information dialog box. |
The Hotfix Registry Key
The Hotfix registry location was previously used to record information about the software updates installed. The Hotfix registry location is no longer populated for many software updates.
Registry location
HKEY_LOCAL_MACHINE\Software\Microsoft\WindowsNT\CurrentVersion\Hotfix\KB######
The following table lists and describes Hotfix registry keys and their values.
Table 4 - Hotfix Registry Key Values
| Key | Description |
Backup Dir | Directory where the backup files are stored. |
Comments | Optional comments. |
Fix Description | Update type and Knowledge Base article number. |
Installed By | No longer used. See previous discussion of the Updates registry key. |
Installed On | No longer used. See the previous discussion of the Updates registry key. |
Service Pack | Identifies the service pack in which the software update is projected to be included. |
The Pending File Renames Registry Key
When you install a software update on a computer that is running, some of the files targeted for update might be in use. For some software updates, the package installer automatically shuts down any running services so the affected files can be updated. If a software update packaged with package installer version 6.1.22.0 or later is installed in attended mode, which requires your interaction, you might receive a message that asks you to close one or more applications so the software update can be applied without requiring you to restart your computer. For information about how to determine the version of the package installer, see Appendix A – Package Installer Versioning and Features.
If you do not close the application, or the service cannot be shut down, the file cannot be replaced or deleted at that time. When this occurs, the updated version of the file is added to the Pending File Renames (PFR) queue, a registry key that tracks files that must be replaced or deleted when the computer is restarted. You can find this registry key at the following location:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\
The value is PendingFileRenameOperations, which is of type REG_MULTI_SZ.
When you restart the computer, and the files are no longer in use, they are either replaced with the updated versions contained in the package, or they are deleted. The PFR registry key is removed when the file update is completed.
If a PFR operation is required, the installation is not complete until you restart the computer.
Important: If you are installing a security update and a restart is required, the security update might not take effect until you restart the computer. This can leave your computer in an unprotected state. To help maintain the security of your computer, be sure to restart it as soon as the security update installation is complete.
For more information about the PFR registry key, see article 202071, “PRB: Troubleshooting MoveFileEx() MOVEFILE_DELAY_UNTIL_REBOOT,” in the Microsoft Knowledge Base.
Registry Keys to Determine Restart Status
You can examine certain registry locations to determine whether you must restart your computer in order for a software update installation to be complete and to take effect. You can use Regedit to examine the Pending File Rename registry key described in the previous section for this purpose. However, this is not a reliable method because, even if this key is missing or empty, you might still need to restart your computer before the installation of a software update is complete.
In package installer versions 6.1.22.0 and later, there is a new global restart indicator key that makes it easier for you to determine whether a restart is required. When a restart is required after installing or removing a software update, flags are set in the following registry key:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Updates\UpdateExeVolatile
You can also use Regedit to examine this key.
The following table lists and describes the flag values within this key.
Table 5 – Global Restart Registry Key Values
| Flag Value | Description |
0x00000000 (0) | No restart is pending. |
0x00000001 (1) | A software update removal is pending a restart. |
0x00000002 (2) | A software update installation is pending a restart. |
0x00000003 (3) | Both an installation and a removal are pending a restart. |
If this key is missing, a restart is not pending. However, only software updates that include package installer version 6.1.22.0 or later will set these flags, so this registry key might not always accurately indicate whether a restart is pending.
Advanced Features of the Package Installer
This section reviews some of the advanced functions available in the package installer. These features include application error reporting, service pack file caching, automatic recovery, hotpatching, hotfix migration, blocklists, and branching.
Application Error Reporting
Application Error Reporting is included in package installer versions 5.4.15.0 and later.
With your consent, the package installer sends information to Microsoft if your system fails or stops responding. Microsoft uses this information to improve its software products. All of the information collected through this process is handled according to the policies detailed in article 283768, “Description of the end user privacy policy in application error reporting,” in the Microsoft Knowledge Base.
Windows Service Packs and Optional Components
When you install a Windows service pack, a new baseline is created because many of the operating system files are updated. During a service pack installation, the package installer creates a directory at %WINDIR%\ServicePackFiles for all of the service pack files. The package installer then puts that path in the following registry key:
HKLM\Software\Microsoft\Windows\Currentversion\Setup\servicepacksourcepath
Windows File Protection, which replaces corrupted or missing operating system files, and the Windows Optional Component Manager, which installs Windows components, both use Setup API functions to find the necessary files to install.
When Setup API is asked to retrieve a system file, it follows a sequence to find the file. It first looks for the file in the dllcache directory (%WINDIR%\system32\dllcache). It then looks in the driver cache (%WINDIR%\Driver Cache), and next in the ServicePackFiles directory. The last place it looks is the original installation operating system CD-ROM.
Because the dllcache directory is emptied periodically, the ServicePackFiles directory is the location that holds the newest versions of the operating system files that are not currently in use on the computer. For example, if you install Internet Information Services (IIS) after installing a Windows service pack, and the dllcache was emptied, the Optional Component Manager will look in the ServicePackFiles directory to get the latest files for IIS. The other option would be to retrieve the files from the original operating system CD-ROM, which would have older versions of those files that do not contain any of the updates included in the service pack.
The % WINDIR %\ServicePackFiles directory is created only for a service pack installation, not for other types of software updates.
Automatic Recovery
The package installer used for Windows XP Service Pack 2 (SP2) includes a new automatic recovery process for service pack installations. This version of the package installer (5.5.1005.0) sets indicators in the registry to execute an automated removal of the service pack if the computer restarts unexpectedly while the service pack is being installed.
This mechanism restores the previous service pack level by using saved backup information and a text file that contains file copy information. You can use a similar mechanism to remove software updates manually through the Recovery Console. See To perform a manual removal through the recovery console for details.
The process used for automatic recovery has greatly reduced the potential for startup problems that can result from partial service pack installation. When the computer restarts during an installation of Windows XP SP2, Session Manager starts the recovery process. A message appears stating that Setup was interrupted, and that the prior configuration will be restored. This screen and its message are shown in the following figure.
Figure 2 – Restoring prior configuration screen
As part of this process, the SetupType value in the registry key HKLM\System\Setup is changed to 2. This causes the operating system Setup program to run the command in the CmdLine value of that key, which points to the Spuninst.exe file. This, in turn, triggers the addition of a value to the registry location
HKLM\Software\Microsoft\Windows\Current Version\RunOnce, which provides the informational prompt shown in the following figure.
Figure 3 – Automatic recovery prompt
After the computer restarts, it should be functional, but it might be in an unstable state. As a result, the prompt indicates that you should uninstall the partially installed service pack through Add or Remove Programs in Control Panel. For details, see Removing Software Updates.
Hotpatching
Hotpatching, also known as “in-memory patching,” is designed to reduce server downtime when you install updates onto computers that are running 32-bit versions of Windows Server 2003 with Service Pack 1 (SP1). The goal is to enable the installation of software updates without having to restart your servers.
If a file is in use when you install a software update, it usually cannot be replaced with the new version until the computer restarts. Hotpatching, however, allows for the automatic insertion of code from a simple software update into a running process. This means that system files can be updated while they are in use.
When a file is hotpatched, the new version of a function from the software update is loaded into memory, and a single line of code in the original function is changed to branch to the new version. After the jump to the new function is injected, each subsequent execution of the function points to the new version. (The next figure illustrates this process.) Applications that are in the middle of a call to the function before the software update was applied are allowed to terminate normally.
Hotpatching is complemented by the usual software update process in which the file on disk is replaced, allowing future spawns of the affected process to contain the software update. Hotpatching is possible only for software updates that provide isolated fixes for individual functions; it is not compatible with software updates that update several interdependent functions. The Knowledge Base article that describes a particular software update will clearly indicate that it is compatible with hotpatching if this is the case.
Figure 4 - Hotpatching overview
Not all Windows Server 2003 software updates support installation through hotpatching. See Deploying Hotpatches section for more details.
Using Blocklists to Overwrite Installed Software Updates
Some software updates (typically hotfixes) are released near the end of a service pack release cycle and are not included in the service pack. The released service pack files might contain other changes not included in the versions installed by the software updates. A service pack installation will not overwrite these files because the software update files will have a higher version number than the service pack files. These software updates are known as “blocklisted” software updates. They are listed in the Updtblk.inf file that is included with the service pack package. Blocklisted updates are repackaged after the release of the service pack so they can be installed with the new service pack. To identify which software updates are on the blocklist, see the service pack release notes document in the Microsoft Knowledge Base, or examine the Updtblk.inf file located in %WINDIR%\inf\ after the service pack is installed.
You should download updated versions of those software updates from Microsoft, and then use the package installer’s built-in chaining functionality to combine the software update installation with the service pack installation. See Integrated Installation for details.
During a service pack installation, you will receive the following message if there are blocklisted updates installed on your computer:
This Service Pack contains files that are missing some of the fixes which were previously installed on this computer. To prevent possible problems, these files will not be installed by the Service Pack.
In order to have these fixes contained in both the Service Pack and the previously installed hotfixes, you must obtain and install the updated versions of the following hotfixes prior to or following the installation of the Service Pack. These hotfixes are also listed in the svcpack.log file.
If a pre-service pack release version of the blocklisted software update package is installed on a computer that is running the new service pack, you will receive the following message:
Setup cannot install this hotfix because one or more of its files are out of date. Please download and install the latest version of fix KB######.
You should download the new version of the update package from Microsoft.
This functionality just described was used for Windows 2000 software updates that were released just prior to the release of Windows 2000 Service Pack 3 (SP3) and Windows 2000 Service Pack 4 (SP4). Currently there are no blocklisted software updates for Windows XP or Windows Server 2003, but this might change with future service pack releases for those products.
For more information about blocklisted updates, see the following Microsoft Knowledge Base articles:
| • | 810077 How to Suppress the Warning That Appears When You Install SP3 on a Computer on Which Previous Versions of Post-SP3 Hotfixes Are Installed |
| • | 309601 Some Windows 2000 hotfixes may cause a conflict with Service Pack 3 (SP3) for Windows 2000 |
Migration
The migration feature ensures that software updates installed prior to a service pack installation do not need to be reinstalled after the new service pack is installed. This functionality was used for some Windows XP software updates that were released prior to the release of Windows XP SP2. However, this approach has been retired in favor of branching, which is described in the next section.
These pre-SP2 software updates were released as “dual-mode” packages. They contained two versions of the software update for the two different operating system levels-- one for Windows XP, and one for Windows XP with SP1. Dual-mode packages include an additional supporting file for the package installer, Xpsp1hfm.exe. This supporting file determines which version of the software update to install, and caches the version for the next service pack level in %WINDIR%\$xpsp1hfm$\KB######\. When the new service pack is installed, the package installer retrieves the software update files for the new service pack level from this cache directory and installs them. The migration operations are logged to %WINDIR%\xpsp1hfm.log. The migration makes it unnecessary to reinstall the fix after the service pack is applied.
For information about dual-mode updates for Windows XP, see article 328848, “Description of dual-mode hotfix packages for Windows XP,” in the Microsoft Knowledge Base.
For information about the directory structure used for migration, see Contents of the Software Update Package later in this document.
Branching
The multi-branch-aware structure, also known as “branching,” supports multiple installation scenarios in the same package, much like the dual-mode installation mentioned in the previous section. Branching is used for some Windows XP software updates released prior to Windows XP SP2, all Windows XP software updates released after Windows XP SP2, and all software updates for Windows Server 2003 operating systems.
Besides the scenario described in dual-mode installations, multi-branch-aware software updates can update different development environments of the same service pack level of the operating system. Between service pack releases, Windows software updates are released from two different development environments, also known as “branches.”
Software updates released through Microsoft Windows Update address widespread critical issues. These software updates are created in the developmental environment known as the General Distribution Release (GDR) branch.
Hotfixes are software updates that address unique customer issues. They are distributed by Microsoft Product Support Services. Hotfixes are created in the developmental environment known as the Hotfix branch, which is also known as the QFE (“quick-fix engineering”) branch. The Hotfix branch also includes software updates from the GDR branch. The following figure illustrates these two branches.
Figure 5 – Updates to a file in multiple branches
Having two separate branches helps minimizes the risk when you receive software updates from Windows Update. It does so by making it possible for you to receive software updates that address only critical issues (such as security issues) and does not include additional changes.
Multi-branch-aware software update packages contain multiple versions of the software update. These versions correspond to the GDR and QFE branches for each service pack level. During installation, the package installer uses supporting .inf configuration files to determine whether the files to be replaced are from the GDR branch or the QFE branch. See Contents of the Software Update Package for details. The package installer then installs the appropriate version of the software update. If the version installed is from the branch with fewer cumulative changes (in this example, it would be the GDR branch), the package installer caches the more cumulative versions (in this example, the QFE version) in %WINDIR%\$hf_mig$\KB######\. If a hotfix for one of those files is installed later, the package installer will “migrate” the previously updated files to the QFE versions in order to maintain consistency.
In addition, versions for a higher service pack level (if such versions exist) are also cached so that the software updates can be reapplied when the computer is updated to the next service pack. After the service pack installation, the package installer checks the cache directory at %WINDIR%\$hf_mig$\KB######\ to determine whether there are any software updates to be migrated to the new service pack level. If there are, the package installer installs these software updates from the cache. This method does not use the Xpsp1hfm.exe file that is used in dual-mode packages described previously. Instead, this functionality is built into the package installer itself.
The package installer will “reverse migrate” a software update if the new service pack is removed. It will reapply the original update files for the previous service pack level as part of the service pack removal process.
For more information about branching, see article 824994, “Description of the contents of Windows XP Service Pack 2 and Windows Server 2003 software update packages,” in the Microsoft Knowledge Base.
For information about the directory structure used for migration, see Contents of the Software Update Package.
Fixes from both branches are included in the subsequent service pack, which undergoes extensive testing before public release.
Contents of the Software Update Package
A software update package includes the installer file (Update.exe), supporting files, and the “payload”--the file or files that make up the actual software update. This section discusses the files and directory structure of a software update package.
Package Installer Files
This section describes the core files and the supporting files that are included in the package installer.
Core Package Installer Files
These files are part of the core package installer and change only when a new version of the package installer is released. These files do not change across packages that are built with the same version of the package installer.
The core package installer files are as follows:
| • | Update.exe |
| • | Updspapi.dll |
| • | Spuninst.exe |
| • | Spupdsvc.dll |
| • | Sprecovr.exe |
Package Installer-related Files
These files support the core files; however, they are not all included in every installer package.
The following table lists all package installer-related files.
Table 6 – Package Installer-Related Files
| File | Description | Packages That Contain This File |
Branches.inf | Defines the hierarchal relationship between branches. See .inf Files for more details. | Only Windows XP and Windows Server 2003 |
Custom.dll or Spcustom.dll | Contains functionality not natively provided by the package installer. The name might vary by Microsoft product. The Custom.dll used by Windows is called SPCustom.dll. See Custom.dll for details. | All |
Empty.cat | Security catalog required for software update removal. | Windows 2000 only |
Eula.txt | End-user licensing agreement displayed during attended (interactive) installation. | All |
KB######.cat | Security catalog. (Each update has a unique catalog file.) | All |
Spmsg.dll | Used by the package installer to record events to Event Viewer. | All |
Sprecovr.exe | Performs system recovery if a failure occurs during a Windows service pack installation. | Windows XP SP2 |
Spupdsvc.exe | Windows service that runs after a reboot if the installation requires processes to be executed after a reboot. | All packages with [ProcessestoRun.AfterReboot] or [ProcessestoRunAfterUninstallReboot] sections in Update.inf |
Spuninst.exe | Core file used to remove software updates. | All |
Updspapi.dll | Supporting file for the package installer that contains the necessary Setup API functions. | Package installer versions 6.1.22.0 and later |
Update.exe | Core of the package installer. | All |
Update.inf | Main configuration file that drives the installation. Provides such things as a list of files to install, installation locations, registry keys to update, string information to display during installation, event log names and location, and external processes to run as part of installation process. See .inf Files for details. | All |
Updtblk.inf | Identifies blocklisted software updates. See Using Blocklists to Overwrite Installed Software Updates for details. | Some service pack packages and some other software update packages |
Update.ver | Describes the version, size, and hash information for the newer versions of the files currently on the system. | All |
Update_<branch-SPLevel>.inf | Replaces Update.inf in a multi-branch-aware package, and provides configuration information for installation from the specified branch. Each branch and service pack level to which the software update applies will have its own Update_<branch>.inf file. See .inf Files for details. | Windows XP SP2 |
Updatebr.inf | Defines the default branch, provides pointers to the Update.inf files and the common setup files. See .inf Files for details. | Windows XP SP2 |
Xpsp1hfm.exe | Determines the appropriate version of the fix to install based on the operating system service pack level, and then launches the package installer. | Windows XP dual-mode packages only (prior to Windows XP SP2) |
Custom.dll
The custom.dll file provides specific functionality not native to the package installer. The name of the Custom.dll can vary from one Microsoft software update package to another. Custom actions can be invoked at different times during the installation.
.inf Files
The .inf files provide the package installer with configuration details for the installation. This allows for customization of the installation procedure, depending on the software update being installed.
Update.inf
The Update.inf file is the core configuration file for the package installer. All packages include this file. It takes a modified name for multi-branch-aware installations. See Multi-Branch-Aware .inf Files for details.
The Update.inf file structure is extensible. Update.inf provides the package installer with target operating system version information, files to update, registry entries to modify, and external processes to run during installation. Common sections found in most Update.inf files are listed in Appendix B - The Update.inf File. The syntax of the .inf files used by the package installer is very similar to those documented in Creating an INF file in the Microsoft Developers Network (MSDN) library.
Multi-Branch-Aware .inf Files
To support branching, multiple versions of the Update.inf file are required, which are named Update_<branch-SPLevel>.inf. There are also two additional required .inf files, Updatebr.inf and Branches.inf, which identify the branches and their hierarchy. Installation packages for Windows XP SP2 and Windows Server 2003 contain these files.
Branches.inf
The Branches.inf file defines the known branches and the branch hierarchy. It facilitates comparison of file branches by describing their relationships to one another. This file is also used when you must migrate from an earlier version of a hotfix to a later version. Branches.inf is copied to the %WINDIR%\inf\ directory on the computer during installation. When a later version of this file is released with another software update, the one on the computer will be replaced.
Updatebr.inf
The Updatebr.inf file defines the common files and their location in the multi-branch-aware file structure. It also identifies the default branch in the hierarchy. In a multi-branch-aware installation, there are multiple Update.inf files shipped with the software update to accommodate the need for different file sets, based on the branch being installed. One of the critical uses for the Updatebr.inf file is to link the branch with the appropriate Update.inf file.
File Structure of the Software Update Package
When the contents of the software update package have been extracted, they are placed in subdirectories under the extraction folder on the computer’s hard drive. This directory contains the package installer, the supporting files mentioned previously, and the payload.
There are three possible directory structures available: standard, dual-mode, and multi-branch aware.
The structures and the packages found in each operating system are listed in the following table.
Table 7 – Software Update Package Directory Structure by Operating System
| File Structure | Windows 2000 | Windows XP | Windows Server 2003 |
Standard | X | X | N/A |
Dual-mode | N/A | X (pre-Service Pack 2) | N/A |
Multi-branch aware | N/A | X (SP2) | X |
Standard Package File Structure
The standard directory structure is the simplest. Files are placed in either the root directory where they were extracted, or in the Update directory.
This is illustrated in the following figure.
Figure 6 - Standard file structure
The following table shows each file’s location in the directory structure:
Table 8 - Standard File Structure
| Directory | Files |
Root | Empty.cat |
Root\Update | Custom.dll |
Dual-Mode Package File Structure
The file structure for the dual-mode installation is more complex than the standard installation and directory structure just described. It carries additional files to service two versions of the same operating system. For example, with this structure, one software update could service computers running Windows XP without SP1 as well as computers running Windows XP with SP1 (see the figure later in this section).
Dual-mode installations are available only for Windows XP software update packages prior to the release of Windows XP SP2. This file structure has been retired in favor of the multi-branch-aware file structure, which is described in the next section.
For example, if you were to perform a dual-mode installation on computers that are running Windows XP as well as computers that are running Windows XP with SP1, the dual-mode installation files would be placed in the following directories:
| • | Root – Contains Xpsp1hfm.exe, the file that determines which service pack level version of the software update files to install. |
| • | Common – Contains common installer files used by both versions. |
| • | SP1 – Contains newer versions of the files currently on the system and supporting files for installation on Windows XP without a service pack. |
| • | SP2 – Contains the newer versions of the files currently on the system and supporting files for installation on computers that are running Windows XP with SP1. |
The following figure illustrates the file structure for a dual-mode installation.
Figure 7 – Dual-mode file structure
The following table shows the location of the files in the directory structure.
Table 9 – File Location in a Dual-mode File Structure
| Directory | Files |
Root | Xpsp1hfm.exe |
Root\Common | Custom.dll |
Root\SP1 | Payload files |
Root\SP1\Update | KB######.cat |
Root\SP2 | Payload files |
Root\SP2\Update | KB######.cat |
Multi-Branch-Aware Package File Structure
When the files from a multi-branch-aware software update are extracted into the root directory, an Update subdirectory and multiple subdirectories for the relevant branches are created. See Branching for more details about multi-branch-aware software update packages.
The first part of the directory name reflects the product milestone (for example, RTM is the original, commercially released version of the product; SP1 means Service Pack 1; and so on). The second part of the directory name identifies the branch or development environment from which the update was built.
In the example illustrated in next figure, the files are placed in one of four directories:
| • | Root – Contains core installer files Spuninst.exe and Spmsg.dll. |
| • | Update – Contains common installer and supporting files. |
| • | RTMQFE – Contains the QFE branch version of the newer versions of the files currently on the system and supporting files. |
| • | RTMGDR – Contains the GDR branch version of the newer versions of the files currently on the system and supporting files. |
Figure 8 - Example of multi-branch-aware file structure
The following table shows the location of the files in the directory structure.
Table 10 - Multi-Branch-Aware File Structure Location
| Directory | Files |
Root | Spuninst.exe |
Root\Update | Branches.inf |
Root\RTMGDR | Package files |
Root\RTMQFE | Package files |
Deploying Your Software Updates
Deployment refers to the method you use to install a software update to individual computers. This section discusses package installation types, package versioning, user rights required to install a package, command-line options, and deployment options and methods.
Package Installation Types
Software update packages are built with three installation types that are distinguished by how they obtain their payload files: self-contained, express, and network. Regardless of how the content is obtained, the package installer follows the same process to complete the installation. This is outlined in the Basic Installation section previously described.
Self-contained Installation
The self-contained installation, also referred to as a standard or full installation, is simple—all of the files that must be installed on the computer as part of the software update are included in the package. See Contents of the Software Update Package for details.
The package installer determines what needs to be installed on the computer, based on file versions, and then proceeds with the installation. This is the preferred installation for large installations behind firewalls where individual computers do not have access to the Internet. It is also preferred where there is a policy prohibiting the installation of software updates from the Internet. Hotfixes obtained from Microsoft Product Support Services, and software updates obtained from the Microsoft Download Center and the Microsoft Windows Update Catalog Web site provide self-contained software update packages for Windows.
Express Installation
The express installation package does not carry the entire contents of the software update, so it is much smaller than the full installation package. Instead, the express installation process generates a list of files that are installed based on the versions currently on the computer, and retrieves those files from the Windows Update Web site. Only the necessary files are downloaded and installed. In addition, the package installer can download only the changes to a file, and then synthesize the updated version of the file from the one currently installed on the computer. These packages use a technology called Binary Delta Compression (BDC). Currently, express installation packages are available only from the Windows Update Web site.
For more information about express installation packages and BDC, see Binary Delta Compression on the Microsoft Web site.
Network Installation
The network installation method discussed in the Deployment Methods section of this document has the benefit of reducing the amount of working disk space that the package installer requires. When the content is placed in a network location, the package installer uses that location as its cached working space instead of using the hard disk on the local computer. This can be very helpful for environments where storage space on the local computer is limited.
During a network installation of a Windows service pack, the ServicePackFiles folder is not created on the local computer because the package installer expects the computer to have access to that network shared folder in the future.
The following registry key points to the network shared folder.
HKLM\Software\Microsoft\Windows\Currentversion\Setup\servicepacksourcepath
Setup API functions use this location to retrieve files needed for Windows File Protection or Optional Component Manager. For more information, see Windows Service Packs and Optional Installed Components.For links to network installation resources, see Windows Deployment Guides.
Package Versioning
In addition to the individual versions of files that are included during a software update installation, versioning is applied to the software update package itself. This is useful when an update is re-released. This is because the version number distinguishes the previous and current software update packages even if the Knowledge Base article number is the same for both versions. After installing the software update, the package version number is retained in the registry.
For more in formation, see Registry Entries for Software Updates.
The following procedure demonstrates the steps to follow to determine the version of a software update package released July 2004 or later.
To determine the version of a software update package released July 2004 or later
| • | Right-click the software update package file whose version you want to check, click Properties, and then click the Version tab. |
| • | The package version information is listed in File Version. |
For information about how to determine package installer version, see Determining the Package Installer Version in Appendix A of this document.
To view software update package version for packages released before July 2004, extract the package contents and view the Update.inf file. For more information, see Extracting Software Update Package Contents Prior to Deployment.
You can view the software update package version information in the [Strings] section under the key name BUILDTIMESTAMP.
Note: Version information does not appear in the [Version] section of Update.inf.
For software update packages released before July 2004, the version number is a concatenation of the date and time that the package was built. This versioning information helps you mathematically determine which version of an update is the most recent.
The following table provides an example of a legend you could use to translate versioning information for a package with version 20030102.120145, a software update package released before July 2004.
Table 11 –Software Update Package Versioning for Packages Released Before July 2004
| Digits | Description | Example Values |
1 – 4 | Year that the update was built | 2003 |
5, 6 | Month that the update was built | 01 |
7, 8 | Day of month that the update was built | 02 |
9, 10 | Integer representing the hour of the day | 12 |
11, 12 | Integer representing the minute of the day | 01 |
13, 14 | Integer representing the seconds of the day | 45 |
Deployment Modes
Software updates can be deployed in attended or unattended mode, depending on the level of the interaction you want to have with the computer while the installation is taking place. Installations for both modes can be performed with a combination of command-line options. See Command-line Options for more details.
Attended Mode
Attended mode is the typical installation method for an individually managed environment that requires your interaction. The Software Update Installation Wizard is launched. You must then accept the end-user license agreement, determine whether to back up files, and if so, where to back them up. You must restart the computer if necessary at the end of installation.
Unattended Mode
Unattended mode enables the automated installation of software updates and does not require your interaction. If you specify the /quiet command-line option, the installation can be completely silent, with restarts, if they are needed, occurring automatically. Windows Update uses the /quiet option to install packages onto its client computers. You can also specify the /passive command-line option. This provides you with a progress bar and warns you that a restart will occur if one is necessary.
There are several ways to accomplish unattended installation. These include developing custom batch installations by using the command-line options previously mentioned, or using automation software, such as Systems Management Server (SMS) or Windows Update Services, to install software updates on all computers across a network.
If you install a software update manually or run your installation from Windows Update, the installation runs in the user context. You should be an Administrator with the user rights detailed in the next section, Required User Rights. If a software update is deployed through SMS or Windows Update Services, the package installer is spawned in the System context because the parent process runs as a service.
Required User Rights
Package installer versions 5.4.1.0 and later require you to be an Administrator with certain user rights in order to install the software update. These user rights are listed and described the following table.
Table 12 – User Rights Required to Perform an Installation
| Group Policy Object Display Name | Required | Description |
Restore files and directories | Required | You must have this user right to perform restore operations. This user right lets you set any valid user or group security identifier (SID) as the owner of an object. |
Back up files and directories | Required | You must have this user right to perform backup operations. |
Take ownership of files or other objects | Required | You must have this user right to take ownership of an object without being granted discretionary access. This user right allows the owner value to be set only to those values that the holder may legitimately assign as the owner of an object. |
Manage auditing and security log | Required | You must have this user right to perform many security-related functions, such as controlling and viewing audit messages. This user right identifies its holder as a security operator. This is required to restore the security access control list (SACL) correctly after replacing files. |
Shut down the system | Not required, but preferred | You must have this user right to shut down the computer. Some software updates require that the computer be restarted. If this user right is not available, the user must contact an Administrator with that user right to restart the computer if it is necessary to do so in order to complete the installation. |
Debug programs | Not required, but preferred | You must have this user right in order to debug a process. Package installer versions earlier than 5.4.1.0 might require Administrators to have this user right in order to install software updates. For more information, see article 830846, “Windows Product Updates may stop responding or may use most or all the CPU resources,” in the Microsoft Knowledge Base. |
Package Installer Scenarios
This section describes the three common uses of the package installer: extracting the contents of a software update package, installing a Windows service pack, and installing a simple software update.
Extracting the contents of a software update package
In some cases, you might want to extract the files from the package before installing it. The next section, Extracting Update Package Contents Prior to Deployment, discusses command-line options that you can use to direct the extraction process.
Installing a Windows service pack
For the purposes of illustration, this is described here as though you were installing Windows 2000 Service Pack 4 (SP4).
To install Windows 2000 SP4, you would double-click the file W2ksp4.exe. This extracts the installation files for the service pack and automatically launches the package installer to install the service pack.
Installing a simple software update
For the purposes of illustration, this is described here as though you were installing the software update associated with Knowledge Base (KB) article 810556.
To install the software update associated with KB article 810556, you would run KB810556_WXP_SP1_x86_ENU.exe. This extracts the installation files for the software update and automatically launches the package installer to install the software update.
Extracting Update Package Contents Prior to Deployment
In some cases, you might want to extract the files from the package before you deploy it. This can help you to better understand the changes that will be made when the software update is installed. In this case, the package installer extracts the contents of the package: the package installer executable files, the supporting files for the package installer, and the payload.
This section discusses how to extract the package contents and explains which command-line options you can use to control the extraction of the software update package.
There are several different options for extracting the contents of the package and for controlling where the extraction occurs. The command-line options determine whether user prompts will appear, and where to extract the files.
The following table details the extraction options and their functions.
Table 13 - Extraction Command-line Options
| Command-line Options | Description |
/quiet | Provides no status dialog box during the extraction. Must be used in combination with /extract or /extract:path, or this option will direct the installation to run in quiet mode. /Q can be used for package installer versions earlier than 5.3.24.4. |
/passive | Provides a progress bar during the extraction, but does not prompt you for the destination folder name. Must be used in combination with /extract or /extract:path, or it will direct the installation to run in passive mode. /U can be used for package installer versions earlier than 5.3.24.4. |
/extract | Extracts package files without starting the installation. Prompts you for the path to the destination folder for extraction. /X can be used for package installer versions earlier than 5.3.24.4. |
/extract:path_name | Extracts software update package files to the specified directory without starting the package installer or prompting you for a destination folder. /X:path_name can be used for package installer versions earlier than 5.3.24.4. |
After extraction, the files are placed in the specified folder. If no folder is specified, and the command-line option /extract was used with /passive or /quiet, a randomly named folder (for example, 1ed6b742f546f) is generated and the files are placed there.
The following table provides examples of commands you can use to extract the contents of a software update package.
Table 14 - Examples of Commonly Used Extraction Options
| Example | Description |
Package_name.exe /extract | Prompts for a folder location, and extracts the contents of the package to that location. |
Package_name.exe /extract:C:\Update | Extracts the contents of the package to a newly created folder called Update on drive C:. |
Package_name.exe /extract /passive | Extracts the contents of the package to a randomly generated folder in the root folder of the current drive. |
In package installer versions 5.3.18.6 and later, when the /extract option is specified and a valid path (/extract:C:\path_name) is included, the package installer will suppress the dialog box that confirms the destination folder. Older versions of the package installer will present this dialog box when the /X:path option is specified. To prevent this action, specify /U along with the /X:path command-line option. See Appendix A – Package Installer Versioning and Features for details about package installer features and versioning.
To install a software update package after extracting its contents, run the Update.exe file to begin the installation, or use the command line to specify the options to use with the installation. See Command-line Options for details.
For a dual-mode installation in which the contents of the package were extracted first, use the Xpsp1hfm.exe file instead of Update.exe to run the installation. The same options that apply to Update.exe can be applied to Xpsp1hfm.exe. For more details, see Migration.
Command-line Options
This section describes the command-line options that the package installer supports for installation. You can use these options to modify the default behavior of the package installer for software update installations. The options are passed from the extractable package to the package installer. These options do not affect how the files are extracted, however.
Note: For information about determining which version of the package installer you are using, see Appendix A – Package Installer Versioning and Features.
The options in the following table apply to both the installation and removal of a package unless otherwise noted in the description column. All options listed use a forward slash (/). For compatibility with older versions, a hyphen (-) can still be used in place of the forward slash (/).
Table 15 – Package Installer Command-line Options
| Option | Description | Installer Versions |
/help | Displays command-line Help dialog box. This option must be used alone. | Version 5.3.24.4 and later support the /help option. For compatibility with older versions, the/? option can be used. |
/passive | Unattended mode. No user interaction is required, but installation status is displayed. If a restart is required at the end of Setup, a dialog box appears with a timer and a warning stating that the computer will restart in 30 seconds. | Version 5.3.24.4 and later support the /passive option. For compatibility with older versions, the /u option can be used. |
/quiet | Quiet mode. Same as unattended mode, but no status or error messages are displayed. | Version 5.3.24.4 and later support the /quiet option. For compatibility with older versions, the /q option can be used. |
/norestart | Do not restart the computer when the installation is complete. | Version 5.3.24.4 and later support the /norestart option. For compatibility with older versions, the /z option can be used. |
/warnrestart | Presents a dialog box with a timer and a warning stating that the computer will restart in x seconds. The default is 30 seconds. Intended for use with either /quiet or /passive. | Version 6.1.22.0 and later support the /warnrestart option. |
/forcerestart | Restart the computer after installation, and force other applications to close at shutdown without saving open files first. | Version 5.3.24.4 and later support the /forcerestart option. |
/promptrestart | Presents a dialog box that prompts you to restart if required. Intended for use with /quiet. | Version 6.1.22.0 and later support the /promptrestart option. |
/forceappsclose | If a restart is required, forces other programs to close without saving when the computer shuts down. Not compatible with /integrate or /norestart. | Version 5.4.15.0 and later support the /forceappsclose option. For compatibility with older versions, the /f option can be used. |
/nobackup | Do not back up the files that would later be required to uninstall the software update. The files required to remove the software update will not be backed up during the installation. Although this option can help save disk space, the software update cannot be removed later. Not compatible with /integrate. The /nobackup option is only applicable to package installations. | Version 6.1.22.0 and later support the /nobackup option. For compatibility with older versions, the /n option can be used. |
/overwriteoem | Overwrite OEM files without prompting. During a normal installation in attended mode, if a software update installation will overwrite a file supplied by the computer manufacturer, a notification will ask you to confirm whether the file should be overwritten. Specifying this option turns off that functionality and overwrites the file without notification. Running in unattended mode will not overwrite OEM files unless the /overwriteoem option is specified. This option only applies to package installation. | Version 6.1.22.0 and later support the /overwriteoem option. For compatibility with earlier versions, the /o option can be used. |
/integrate:path | Integrates software updates into the Windows installation source files or service pack files located at the path specified. The specified path must be fewer than 256 characters. For information about how to deploy an integrated installation (sometimes called “slip streaming”), see Integrated Installation. This option applies only to package installation, not to package removal. | Version 5.4.15.0 and later support the /integrate:pathoption. For compatibility with earlier versions, the /s option can be used. |
/log:path | Specifies where to create the log file. The specified path must be fewer than 256 characters. | Versions 6.1.22.0 and later support the /log option. |
/ER | Enable extended error reporting. The default behavior of the package installer is to return one of three standard return codes. See Return Codes for more information. Extended return codes are either standard Win32 codes or codes that are specific to the package installer. See Appendix F - Extended Return Codes and Setup API Error Codes for details. This option applies only to package installations. | Versions 5.3.24.4 and later support the /ER option. |
/verbose | Enable verbose logging. Upon installation, creates the %windir%\CabBuild.log, which details the files to be copied. Using this option can cause the installation to proceed much more slowly. | Version 5.3.24.4 and later support the /verbose option. For compatibility with earlier versions, the /v option can be used. |
/d:path | Specifies a backup directory for Windows service pack installations. The path indicates the destination folder for the backup files. The specified path must be fewer than 256 characters. The default backup location is %systemdrive%\$ntservicepackuninstall$. Only available for Windows service pack installations. | Versions 5.3.16.5 and later are support the /d option. |
/hotpatch:disable | Disables hotpatching functionality. See Hotpatching for details. | Use only with Windows Server 2003 packages that are compatible with hotpatching. See Identifying Hotpatching Compatibility for details. |
Command-line Option Compatibility
In some cases, you can use command-line options together. In other cases, you should not do so because they are incompatible or might default to unexpected behavior.
The following table lists a variety of combinations and notes their compatibility with each other. If the table entry for a particular combination is blank, the options are compatible and you can use them together. If the W symbol appears for a particular combination, it means that the options are incompatible and should not be used together.
Table 16 –Command-line Option Compatibility
Chained Installation
Chained installation streamlines the installation of multiple software update packages because it requires only one restart at the end of installation. All Pending File Rename (PFR) operations associated with the software updates installed in a chained installation are committed after that restart.
During a chained installation, the package installer checks the Pending File Rename queue for any file conflicts, and resolves them after each installation.
The following example illustrates how this is done.
A software update is installed that has to create a PFR entry for version 1.2 of Example.dll. Immediately afterwards, a second software update is installed that creates a PFR entry for version 1.1 of Example.dll. The package installer must ensure that the more recent copy of Example.dll is installed on the computer (version 1.2), so it removes the PFR entry for version 1.1.
In earlier versions of the package installer, it was necessary to manually run a tool called QChain to chain a software update installation. In package installer versions 5.3.12.0 and later, QChain functionality is included in the package installer itself, so running the tool separately is no longer necessary. See Appendix A – Package Installer Versioning and Features for information about how to determine the package installer version.
For more information about the QChain tool, see article 296861, “How to install multiple Windows updates or hotfixes with only one reboot,” in the Microsoft Knowledge Base.
When you are installing software updates that were released before December 2002, or that include package installer versions prior to 5.3.12.0, we recommend that you restart the computer after the installation. For more information, see article 815062, “The correct file is not installed when you chain multiple hotfixes,” in the Microsoft Knowledge Base.
Note: The package installer does not allow for chaining the removal of software updates. After a software update is removed, the computer must be restarted if necessary before you remove another software update.
Language Considerations
Some software updates are language-specific and must match the language on the computer. Others are more flexible, enabling one software update to be applied on any computer, regardless of language or locale.
For Windows software updates to function properly, the language of the software update installed must match the default language on the computer. This might not be a requirement for other Microsoft product software updates. If the related Knowledge Base article does not identify the software update as language-specific or neutral, you can determine whether this requirement applies by reviewing the LanguageType value in the Update.inf file. A language code of 0x0 means that the software update will install on any language. See Appendix B – The Update.inf File for more information about how to read the Update.inf file.
For Multilingual User Interface (MUI) packs, there are no specific MUI software update packages. Consequently, the correct way to update these systems is to install the English release of the software update.
For more information, see Service Pack Release Notes for Windows Multilingual Interface (MUI) Version on the Microsoft Web site.
Deployment Methods
There are several methods you can use to deploy software updates to computers in a networked environment. These include running the package manually with a combination of installation command-line options, using an installation batch file, distributing updates by using a shared network distribution folder, combining software updates with Windows Operating System installation, using Systems Management Server (SMS), using Windows Update Services, downloading directly from Windows Update, and using Sysprep. In addition, some Windows service packs can be deployed by using Windows Installer.
Windows Deployment Guides
The table in this section lists the deployment guides that are the best resources for information about deploying Windows software updates. These deployment guides provide specific information about deploying software updates in environments that include a single computer or multiple computers. You should consult the appropriate deployment guide if you are planning a deployment.
Table 17 - Deployment Guides
| Operating System and Service Pack | Deployment Guide Link |
Windows 2000 operating systems | Microsoft Windows 2000 Hotfix Installation and Deployment Guide |
Windows 2000 – Service Pack 4 (SP4) | Microsoft Windows 2000 Service Pack 4 Installation and Deployment Guide |
Windows XP operating systems | |
Windows XP | |
Windows XP | Microsoft Windows XP Hotfix Installation and Deployment Guide |
Windows XP | Guide for Installing and Deploying Microsoft Windows XP Service Pack 2 |
Windows Server 2003 operating systems | |
Large scale deployments |
Installing from a Network Folder
To install a software update on multiple computers in an individually managed environment, place the software update on a shared network drive. The distribution folder should be a shared network location that is accessible to all of the computers to be updated. (For details, see the appropriate Windows deployment guide in the previous table.)
For example, to install a software update from a distribution folder named Update_Folder, you would type the following:
\\ServerName\ShareName\Update_Folder\update_name.exe
To customize the installation, use the command-line options described in Command-line Options.
Important: Be sure to review Chained Installation before performing multiple installations at the same time.
Installation Batch Files
Multiple software updates can be installed together through the use of batch files. The following batch file samples are based on two of the more common scenarios for installing multiple software updates from a network shared folder.
The first example demonstrates how to combine the installation of a service pack and a hotfix. The second example shows how to determine whether a restart is necessary after installing three software updates together.
Combining a service pack and software updates
This example chains together the installation of a service pack and a hotfix. The restart required by the service pack installation is suppressed so the hotfix can be applied.
@ECHO OFF SETLOCAL REM Location of updates to install SET PathOfFixes=Drive:\hotfix %PATHTOFIXES%\SP_install.exe /norestart /passive %PATHTOFIXES%\Update_A.exe /passive Shutdown /r
The chaining functionality (see Chained Installation) in the package installer enables multiple installations to be chained together. During this type of installation, the Pending File Rename operations from all installations are processed in one restart. See The Pending File Rename Registry Key for details.
In the previous example, this can only be done for software updates that include package installer versions 5.3.12.0 and later, where QChain functionality is included in the package installer itself. See Appendix A – Package Installer Versioning and Features for information about how to determine package installer version.
The previous example uses the /passive option, which instructs the package installer to run in unattended mode, so you are not required to provide input to the process. This example also includes a restart command that restarts the computer after the hotfix installation.
Determining whether a restart is necessary
The following example illustrates how to use a batch file to evaluate the return code from the package installer to determine whether a restart is necessary. This is the recommended procedure when you are using a batch file to install software updates. A restart could be required by any of the software updates.
@ECHO OFF SETLOCAL REM Location of updates to install SET PathOfFixes=Drive:\hotfix REM Flag used to determine if a restart is required, initialize to 0 SET Reboot_Needed=0 %PathOfFixes%\update_a.exe /norestart /passive IF ERRORLEVEL 3010 SET Reboot_Needed=1 %PathOfFixes%\update_B.exe /norestart /passive IF ERRORLEVEL 3010 SET Reboot_Needed=1 %PathOfFixes%\Update_C.exe /norestart /passive IF ERRORLEVEL 3010 SET Reboot_Needed=1 REM force restart here IF %Reboot_Needed%.==1. Shutdown /r
The example checks the return code from the package installer after each software update to determine whether a restart is necessary. See Return Codes for details.
Note: For Windows XP and Windows Server 2003, the shutdown command used in the previous example is part of the operating system and is available by default. For Windows 2000, the same functionality is available through the Windows NT Resource Kit utilities; Shutdown.exe and Shutgui.exe and must be installed separately.
Integrated Installation
An integrated installation is one in which service packs or other software updates are installed together with the operating system. You can use this type of installation, also known as “slipstreaming,” to fully update a computer in a single imaging process. This installation enables the operating system image to be updated with a service pack, software updates, or both, before installation. The /integrate command-line option is used for integrated installations.
A software update can be integrated into the Windows operating system source files. This procedure is useful, for example, if you want to integrate a security update or an entire service pack with the operating system source files. One benefit of this approach is that it can help protect a new operating system installation from being infected with a virus that the security update is designed to prevent.
To perform this type of installation, you create a network shared folder for the Windows operating system installation files. You use the /integrate command-line option to direct the package installer to copy the software update files to the shared network folder you just created. The original operating system files will be overwritten with the updated ones. When the operating system files from this network shared folder are installed onto a computer, the computer will receive the updated versions instead of the original versions. This is illustrated in the following example.
KB123456.exe /integrate:c:\source_files
In this example, the hypothetical software update KB123456 is being combined into a directory with Windows source files.
The following table lists scenarios for integrated installations and indicates whether the functionality in the package installer supports them.
Table 18 – Integrated Scenarios
| Integrated Installation Scenario | Supported |
Integrate a simple software update into an operating system. | YES |
Integrate a Windows service pack into an operating system. | YES |
Integrate a simple software update into an operating system that has previously been integrated with a service pack. | YES |
Integrate a simple software update into an operating system that has previously been integrated with any number of simple software updates. | YES |
Integrate a service pack into an operating system that has previously been integrated with another service pack. | YES |
Integrate a service pack into an operating system that has previously been integrated with a simple software update. | NO |
Integrate a service pack with a simple software update. | NO |
Integrate a simple software update with another simple software update. |