Inside Update.exe: The Package Installer for Windows and Windows Components by eletronicaparamakers

Windows XP OEM Preinstallation Kit Design Notes Microsoft Windows Family of Operating Systems

Inside Update.exe: The Package Installer for Windows and Windows Components

The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication. This white paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, AS TO THE INFORMATION IN THIS DOCUMENT. Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation. Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property. Microsoft does not make any representation or warranty regarding specifications in this document or any product or item developed based on these specifications. Microsoft disclaims all express and implied warranties, including but not limited to the implied warranties or merchantability, fitness for a particular purpose and freedom from infringement. Without limiting the generality of the foregoing, Microsoft does not make any warranty of any kind that any item developed based on these specifications, or any portion of a specification, will not infringe any copyright, patent, trade secret or other intellectual property right of any person or entity in any country. It is your responsibility to seek licenses for such intellectual property rights where appropriate. Microsoft shall not be liable for any damages arising out of or in connection with the use of these specifications, including liability for lost profit, business interruption, or any other damages whatsoever. Some states do not allow the exclusion or limitation of liability or consequential or incidental damages; the above limitation may not apply to you. Unless otherwise noted, the example companies, organizations, products, domain names, e-mail addresses, logos, people, places and events depicted herein are fictitious, and no association with any real company, organization, product, domain name, e-mail address, logo, person, place or event is intended or should be inferred. ÂŠ 2004 Microsoft Corporation. All rights reserved. Microsoft, Win32, Windows, Windows NT, WindowsÂŽ 2000, Windows Server 2003, Systems Management Server (SMS), and Windows XP Service Pack 1 (SP1) are either registered trademarks or trademarks of Microsoft Corporation in the United States or other countries or regions. The names of actual companies and products mentioned herein may be the trademarks of their respective owners.

Contents Introduction .............................................................................................................................. 4 Common Update Package Types ............................................................................................ 4 Standard Update (Hotfix) ..................................................................................................... 5 Service Pack ....................................................................................................................... 5 Installer Execution and Return Codes ...................................................................................... 5 Extracting Update Package Contents.................................................................................. 5 Command-line Switches...................................................................................................... 6 Return Codes ...................................................................................................................... 9 Deployment .............................................................................................................................. 9 Elements of Deployment ..................................................................................................... 9 Deployment Methods ........................................................................................................ 15 Deployment Timing ........................................................................................................... 19 Contents of the Update Package ........................................................................................... 20 Binaries ............................................................................................................................. 20 Installer Log Files .............................................................................................................. 22 File Structure ..................................................................................................................... 23 Summary................................................................................................................................ 27 Appendix A – Installer Versioning and Features .................................................................... 28 Versioning ......................................................................................................................... 28 Installer Features by Version............................................................................................. 28 Appendix B – The Update.inf File .......................................................................................... 29 Appendix C – Detailed Installer Process Flow ....................................................................... 34 Appendix D – Sample Installer Log ........................................................................................ 41 Appendix E – Standards for A/RP Entries.............................................................................. 44 Registry Values ................................................................................................................. 44 Appendix F - Extended Return Codes ................................................................................... 45

Introduction This white paper discusses the Package Installer for Windows also known as Update.exe. Update.exe is generally used to install a service pack or an update (also referred to as a hotfix) for Windows operating systems and other Microsoft products. The Package Installer has been in use for a number of years servicing the operating system, and, recently, other teams at Microsoft adopted the Installer to service their products. This white paper presents an in-depth discussion of package types, deployment methods, the internal mechanisms of the update package, and an installation overview. The information contained in this document was current as of December 2003. As the Package Installer for Windows evolves, this document will evolve with it. Updated versions of this document can be found at the original download location. Please check Microsoft TechNet frequently for new versions. All updates from the Windows Sustained Engineering (WinSE) team are released via the Package Installer for Windows, but with one exception: NT4 updates are released with Hotfix.exe, the predecessor of Update.exe. To standardize use of the Installer, Microsoft has developed an Installer Convergence plan. Besides other improvements underway, the plan will limit the number of Installers for servicing Microsoft products to Update.exe and the MSI Installer. This document discusses the Update.exe Installer. Details on the MSI Installer can be found at About Windows Installer. Because the same Installer is used to apply service packs and hotfixes to a computer, Microsoft designed the Installer to function for both types of update without conflict. For either an update or a service pack, the Installer can add new files; delete or replace existing files; add, remove, or update registry keys; and back up files that will change before installation. At its simplest, the process flow used by the Installer will be as follows:

Graphic 1 - Installer Overview

A flowchart describing the process flow used by Update.exe to install service packs and hotfixes is in Appendix C – Detailed Installer Process Flow.

Common Update Package Types In general terms, “update package” (often referred to as simply “package”) refers to the shipping product or executable file that contains the Installer, the supporting files, and the payload (DLLs, executable files, or scripts to be installed on the computer). Together, these three components are called the package contents (see Package

Inside Update.exe: The Package Installer for Windows and Windows Components â&#x20AC;&#x201D; 5

Contents for details). This paper focuses on the two major categories of packages:

standard update and service pack.

Standard Update (Hotfix) The standard update (also referred to as a hotfix) is the simplest form of update packages. It contains an Installer, the supporting files for the Installer, and the payload.

Service Pack A service pack is usually the largest of the update packages. In general, a service pack contains all of the updates released since the release of the previous service pack or RTM (Release to Market) version of the product. Like the other types of update packages, the service pack contains the Installer, the supporting files for the Installer, and the payload.

Installer Execution and Return Codes Microsoft releases service packs and updates in a single executable file which contains all of the necessary files as mentioned above, including the install logic and registry changes. When the package is executed without any command-line switches, it extracts the contents of the package to a temporary folder, executes the Installer (Update.exe), and proceeds to install the update. The three common uses of the Installer are: 1. To install a service pack For example, to install Windows 2000 SP4, run W2ksp4.exe. This extracts the installation files for the service pack. Update.exe then automatically runs and installs the service pack. 2. To install an update For example, to install the update associated with Knowledge Base (KB) article 810556 run Q810556_WXP_SP1_x86_ENU.exe. This extracts the installation files for the update and automatically launches Update.exe to install the update. 3. To extract the contents of a package For example, to install previously extracted files, run Update.exe directly from the folder where it was extracted. This document will discuss Installer execution for all three usage scenarios. The third scenario, Extracting Update Package Contents, will be discussed first. Options for installing updates and service packs are discussed in the Command-line Switches section. Note: The only process recommended and supported by Microsoft for installing the package is to use the Windows Package Installer documented in this white paper or in the deployment guides. Alternatively, update releases using the MSI technology should be installed using that technology.

Extracting Update Package Contents In some cases (for example, usage scenario 3), it may be desirable to extract the files from the package before execution. Many organizations do this to gain a better understanding of the changes that will be made when the update installs. In this case, the Installer unpacks the contents of the package yielding the Installer executable files, the supporting files for the installation, and the payload. The following section discusses

Inside Update.exe: The Package Installer for Windows and Windows Components — 6

how to extract the package contents and which command-line switches to use to control the installation of the update. There are a number of different options for extracting the contents of the package and for controlling where the extraction occurs. The command-line switch options determine whether user prompts will appear and where to extract the files. The following table details the extraction switches and their functions: Command-line Switches

Description

Provides no status dialog during the extraction.

Does not prompt for the folder name to extract to; requires the /X or /X:path switch. When used with the /X switch, the switch is a directive to the extractor, not Update.exe.

Extracts service pack files without starting Update.exe. Prompts for the path to the destination folder for the files.

/X:”foldername” (path_name)

Extracts service pack files to the specified folder without starting Update.exe or prompting.

Table 1 - Extraction Switches

Specifying Directories After extraction, the files are placed in either a chosen folder, or if no folder is specified, then in a randomly named folder. For example, with the extraction switch combination of /X /U and no prompt for a folder, the extractor will create a random folder name— something like 1ed6b742f546f. Table 2 shows common examples of extracting the contents of a package. Command-line Switches

Use

Update_name.exe /X

Prompts for a folder location and extracts the contents of the package to that location.

Update_name.exe /X:C:\Update

Extracts the contents of the package to a newly created folder called Update on drive C.

Update_name.exe /X /U

Extracts the contents of the package to a randomly generated folder. The Installer creates the folder in the root folder of the current drive and randomly generates a name.

Table 2 - Common Examples of Command-line Switch Use

Depending upon the version of the Installer used, the /U switch may or may not be necessary to suppress the dialog box (prompt). Starting with the Q2 versions of the Installer, when the /X switch is specified and a valid path (/X:C:\path_name) is included, the Installer will suppress the dialog box by default. Older versions of the Installer will use a dialog box to confirm the destination folder when the /X switch is specified. (See Appendix A – Installer Versioning and Features for details on Installer features and versioning.)

Command-line Switches The following section describes the command-line switch options supported by Update.exe. These switches can be used to modify the default behavior of the Installer for update and service pack installations. The switches are passed from the extractable package to Update.exe. The switch options do not affect how the files are extracted, however. The list below explains each switch option.

Inside Update.exe: The Package Installer for Windows and Windows Components — 7

Note: With the latest release of Update.exe, commonly referred to as the Q4 installer, there is additional functionality that enables the integration of hotfixes into a service pack. For information about how this feature has been implemented, see KB article 832475. For information about determining which version of the installer that you are using, see Appendix A – Installer Versioning and Features.

Command-line Switch Options All of the switch options listed below use a forward slash (/), but a hyphen (-) can be used instead. The switches work the same way with either symbol. •

/U – Unattended mode All default switch options are used during the service pack installation. This installation does not prompt for any input, but it displays a progress bar throughout the installation process.

•

/Q – Quiet This switch option installs SP4 the same way as an unattended installation. However, neither the progress bar nor any errors that might occur appear during this installation.

•

/F – Force restart If this switch option is used for installation, the user must close all applications and then restart the computer after the installation is completed. To force applications to close without saving files, use the /F switch option. Use this switch option in conjunction with other command-line switch options, except /S (used for integrated installation mode), /L (used to list installed hotfixes), and /Z (used to prevent an automatic restart after the installation).

•

/N - No backup and no uninstallation The files required to remove the service pack will not be backed up during the installation. Although this switch option can help save disk space, the service pack cannot be removed later, even from the command line. Use this switch option in conjunction with other command-line switches, except /S (used for integrated installation mode) and /L (used to list installed hotfixes). This functionality will vary depending upon the version of the Installer used. For Installer versions earlier than Q2, there will be no entry in Add or Remove Programs (A/RP); for Q2+ Installer versions there will be an entry in A/RP but there will not be an option to remove the update.

•

/O – Overwrite OEM-supplied files During a normal installation in attended mode, if an update or service pack installation will overwrite a file supplied by the manufacture of the machine, a notification will confirm whether the file should be overwritten or not. Specifying this switch turns off that functionality and overwrites the file without notification. Running in unattended mode will not overwrite OEM files unless the /O switch is specified.

•

/Z - Suppresses restart Use this switch option to install hotfixes, without restarting the computer automatically after the service pack is installed. Use it in conjunction with other command-line switch options, except /S (used for integrated installation mode) and /L (used to list installed hotfixes). After the hotfixes are installed, restart the computer immediately to complete the service pack installation process.

•

/L – List Windows hotfixes

Inside Update.exe: The Package Installer for Windows and Windows Components — 8

Use this switch option to display all of the Windows hotfixes installed on the computer. This switch option is not designed for use with any other switches. When specified, the Installer reports the fixes installed from the hotfix section of the registry as defined in Registry Entries for Patches. For more information about viewing the updates installed, see Article 282784, “Qfecheck.exe Verifies the Installation of Windows 2000 and Windows XP Hotfixes”, and Article 304864, "Qfecheck hotfix Tool Reports False Need to Reinstall Freshly Installed hotfixes”. •

/S:foldername – Extract to network folder Use this switch to extract to a shared network folder for integrated installation To deploy Windows 2000 with Service Pack 4 (SP4) as an integrated installation, use this switch option to build an integrated shared network folder that contains files for Windows 2000 and SP4. Use this shared folder to save time by installing Windows 2000 and the service pack together. For information about how to deploy Windows 2000 with SP4) as an integrated installation (sometimes called slip streaming), see Scenario 1: Installing Windows 2000 Integrated with the Service Pack.

•

/D:foldername- Back up files to a specified folder Specifies a backup folder directory for the service pack; this feature is not available for updates other than service packs and is available only in the Q1 Installer and later versions (see Appendix A – Installer Versioning and Features). To back up files when not specifying a folder, the files will be backed up to the default location: $ntservicepackuninstall$

•

/ER – Enables extended return codes Extended return codes return to the calling application a code other than the three standard return codes (Success; Success, Reboot required; Failure). The return codes will fall into one of two categories, either a standard Win32 error or errors specific to the Installer (See Extended Return Codes in Appendix F - Extended Return Codes for more details.)

Recently, Microsoft moved to a standard for Installer switches and it will be available in the Q4 Installer (see Appendix A – Installer Versioning Features for details on Installer versioning). For /D and /S switches, even though there are no new defined switches for this purpose, the old switches are still valid. The following table lists the new and legacy switches: Legacy Switch

New Switch

Description

None

/Uninstall

Uninstalls the update or service pack.

/Help

Displays help text.

/D:foldername

None

Backs up files to the specified folder (only for service pack installations).

None

/ER

Enables extended return codes (See Extended Return Codes in Appendix F - Extended Return Codes for more details.)

Forces other applications to close when the computer restarts after the installation.

None

/Forcerestart

Forces restart after installation finishes.

Lists installed hotfixes (Windows updates only).

Does not back up files for removing the service pack or hotfix. In Add or Remove Programs, there is no Remove button for the hotfix so it cannot be uninstalled. Requires Q2 or later version of Update.exe. (See Installer Features by Version for

Inside Update.exe: The Package Installer for Windows and Windows Components — 9

details.) /O

Overwrites OEM files without prompting.

/Quiet

Uses quiet mode, which is the same as unattended mode, except that the user interface is hidden. No prompts will appear during the installation.

/S:foldername

None

Combines the operating system image with SP4 in a shared distribution folder for an integrated installation (service pack feature only).

/Passive

Uses unattended Setup mode. Only critical errors and a progress bar appear during Setup.

/Norestart

Does not restart the computer after the installation finishes.

Table 3 - Standardized Switches

Return Codes When calling the Installer from a batch file (see Installation Batch files for details), it is possible to receive feedback from the Installer on the success or failure of the installation. These values are returned to the calling process through a return code. The return code can help users determine the next course of action. The Installer returns one of three values: Failure, Success, or Success, Reboot Required. When the Installer finishes, it will pass a numerical value back to the calling program. The following table lists the three values and their corresponding error codes: Values

Error Code

Description

1603

ERROR_INSTALL_FAILURE

Failure

ERROR_SUCCESS_REBOOT_REQUIRED

Success

3010

ERROR_SUCCESS_REBOOT_REQUIRED

Success, Reboot Required

Table 4 - Return Codes

For more information about working with the Installer from a batch file, see the examples in Installation Batch files. For more detailed information about the changes that the Installer has made, see Appendix D – Sample Install Log.

Deployment Deployment refers to the method used to install the service pack or update to the individual machines. However, before discussing the details of deployment, the next section will first review the general elements of deployment available in the Installer. This section will end with a short discussion about timing of deploying updates between service packs.

Elements of Deployment Pending File Renames When installing to a running system, it is possible that some files targeted for update are in use. In that case, the updated version of the file is added to the Pending File Renames (PFR) queue, which is a registry key that tracks files that need to be replaced during the system restart. If a PFR operation is required, the installation is not finished until the system has been restarted. It is possible to detect the need for a system restart by examining the Installer log or the return code.

Inside Update.exe: The Package Installer for Windows and Windows Components — 10

Install Chaining (QChain) The technology known as QChain streamlines the installation of multiple hotfix packages, or a service pack and hotfix packages. Chaining installations enables one restart to commit the Pending File Renames (PRF). In earlier versions of the Window Installer, it was necessary to manually execute QChain to install multiple updates with one restart. With the later versions of Update.exe, QChain functionality is built into the Installer. For more information about the specifics of QChain, read How to Install Multiple Windows Updates or Hotfixes with Only One Reboot. When installing updates that were released before December 2002, restarting the computer after the installation is recommended. This is because of changes that the Installer made to the state of the computer, which cannot be reset to the default state after installation. (See KB Article 815062 for more details about when a restart is required.)

Updates and Optionally Installed Components When applying updates to a computer there is the possibility that the component being updated has not yet been installed. This occurs when, during the initial machine set up, optional components were not installed. In order to manage the patching of optionally installed components, a feature called sticky updates is implemented. Sticky updates, when fully implemented, enable optionally installed components to be updated. When an update is installed that affects an optionally installed component there are two possibilities: either the optional component is installed and will be updated or the optional component has yet to be installed. If the optional component has not been installed, the files required to update the component are cached on the disk for future use. While sticky updates are not fully implemented at this time, some of the functionality associated with sticky updates is currently visible after the installation. The directory location where the cached files are stored on the disk is visible in the registry. This value is stored under the registry key, ServicePackCachePath, at the registry location HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Setup. Whether this registry location is populated depends on what optional components were installed and whether updates for these optional components have also been installed.

Language Considerations Some updates will require a language-specific update to match the language on the computer. However, others are more flexible, enabling one update to be applied on any computer, regardless of language or locale. For Windows updates to function properly, the language of the update installed must match the default language on the computer. For updates released by other Sustained Engineering teams this may not be a requirement. If the related KB article does not identify the update as language-specific or neutral, the status can be determined by reviewing the LanguageType value in the .inf file; a language code of 0x0 means the update will install on any locale. (See Appendix B – The Update.inf File for more information about reading the .inf file.) For Multilingual User Interface (MUI) packs, there are no specific MUI installations. Consequently, the correct way to update these systems is to install the English release of the update or service pack, because a MUI-specific version is not available. For a more detailed discussion about updating MUI-enabled computers, read the Service Pack Release Notes for Windows Multilingual User Interface (MUI) Version.

Inside Update.exe: The Package Installer for Windows and Windows Components — 11

Update Package Versioning Besides the individual versioning of DLL files to be installed in an update, there is also versioning applied to the update package itself. This is useful when an update is released again; the version number distinguishes the updates. After installing the update, the version number is retained in the registry. (See Registry Entries for Updates for details.) To view the update version before installation, unpack the package and view the .inf file. The update version does not appear in the [Version] section of the .inf file; it is found in the [Strings] section under the key name BUILDTIMESTAMP. For details about how to extract the contents of the package, read Extracting the Contents of a Package. The update version number is a concatenation of the date and time that the package was built. For example, a version of 20030102.120145 breaks down as shown in Table 5. This method of versioning enables you to determine mathematically which version of an update is greater (that is, to determine the latest version). (See Table 5 below.) Digits

Value

Sample Values

1–4

Year that the update was built

2003

5, 6

Month that the update was built

7, 8

Day of month that the update was built

9, 10

Integer representing the hour of the day

11, 12

Integer representing the minute of the day

13, 14

Integer representing the seconds of the day

Table 5 - Update Versioning

Registry Entries for Updates When an update is installed, it adds a number of entries to the registry documenting the update installation and providing details about what has been installed and where to find the uninstallation. These registry keys are used by The Microsoft Baseline Security Analyzer (MBSA), QFE Check, Add or Remove Programs (A/RP), and external tools to identify and display fixes currently installed. Three registry locations are written when an update is installed and these are commonly referred to as the Hotfix, Update, and Add or Remove Programs (A/RP) locations. Details only relating to installed Windows fixes are located in the hotfix location. The Update section contains details about all fixes installed from Windows and other teams, and the A/RP section contains information about hotfixes shown in A/RP. Note: If the package was installed with the /N switch, the A/RP entry may be suppressed. Older packages, installed with a pre Q2 Installer (see Appendix A – Installer Versioning and Features) and the no-uninstallation option will not appear in A/RP. Updates are identified in these locations by the alpha KB or Q, followed by the number of the Knowledge Base (KB) article. Older updates are preceded by the letter Q and the post-2002 updates use a preceding KB. Using KB followed by the KB article number is the current Microsoft standard. The use of Q is being phased out over the course of 2003. During a service pack installation, the registry keys added during the individual update installation are cleaned up. One of the primary goals of a service pack is to roll up hotfixes that were released since the release of the previous service pack. With the

Inside Update.exe: The Package Installer for Windows and Windows Components — 12

installation of a service pack, individual registry entries for updates already installed and contained in the new service pack are removed from the registry and replaced with one entry for the service pack installation visible in A/RP. Uninstallation will restore the hotfixes and their entries.

Update Registry Entry Location The update registry entry key identified below is used by the Windows Sustained Engineering (WinSE) team and other sustained engineering teams at Microsoft, and should be used instead of the hotfix key listed later in this section. Depending upon what type of package (service pack vs. hotfix) is installed, this key will take one of two forms: for service packs, the summary information will be completed; for updates, the summary information and the file list entries will be defined as follows: •

Summary information HKEY_LOCAL_MACHINE \Software\Microsoft\Updates\[Target Product]\[Target SP]\KB###### [Target Product] – Identifies the product: Windows, Office, etc. [Target SP] – Identifies the service pack: SP1, SP2, etc. Example: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Updates\Windows XP\SP2\KB823980 Further subkeys vary, depending upon the needs of the group that owns them; many groups choose to identify the release by the target service pack as shown in the previous example. In the key that identifies the individual fix, the subkeys listed in Table 7 may be populated. Key

Description

Default

Not used

Description

Description of the update (for example, the title of the update, such as “Windows XP Hotfix – KB######”)

Installed By

The user who installed the update

InstalledDate

Date that the fix was installed on the computer

Type

Type of installation (currently, this is limited to either service pack or hotfix). For more information about types of packages, go to http://support.microsoft.com/?kbid=824684. If the type is service pack, there will not be a file list. Listing all the files included in the service pack is outside the scope of what can be contained in the registry.

UninstallCommand

The location of the uninstallation command for the hotfix. If the fix was installed with the /N switch, this key will be blank. If there is no back directory to restore the previous files from, the hotfix cannot be uninstalled.

Table 6 - Registry Key Values for An Update

•

File list keys File list keys provide a detailed list of the files installed, their installation location, version, etc. and can be found at: HKEY_LOCAL_MACHINE \Software\Microsoft\Updates\[Target Product]\[Target SP]\KB######\Filelist [Target Product] – Identifies the product Windows, Office, etc.

Inside Update.exe: The Package Installer for Windows and Windows Components — 13

[Target SP] – Identifies the service pack: SP1, SP2, etc. Example: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Updates\Windows XP\SP2\KB823980\Filelist Under this are subkeys numbered 0 through n, one for each file installed as part of the update. The keys shown in Table 8 are common for the file list entry. Key

Description

Default

Not used

BuildDate

Date that the file was built

FileName

Name of the file

Location

Location of the installed file

Version

Version of the installed file

Table 7 - Registry Key Values for the File List Entry

Add or Remove Programs Keys Service packs and updates are considered additions to the RTM image and are tracked in Add or Remove Programs (A/RP) as such. A/RP uses the registry key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninsta ll to track the installed software and how to uninstall those programs. Hotfix information, as well as information related to other programs installed, is available in this key. The updates are organized by either the KB or the Q number. (See Table 9 below.) Updates that have been installed can be viewed by going to Add or Remove Programs in Control Panel. Installed updates are listed after installed programs. Microsoft has defined a set of standards for A/RP entries. See Appendix E –Standards for A/RP Entries for more information.

Note: If a package is installed with the /N switch, the A/RP entry may be suppressed. Older packages, installed with a pre-Q2 Installer (see Appendix A – Installer Versioning and Features) and the no-uninstallation option will not appear in A/RP. Key

Description

Default

Not used

Display Name

Text displayed in A/RP

Display Version

Version of the update installed (see Patch Versioning for more information)

HelpLink

Support text and link to KB article

NoModify

Determines if the Change button appears in A/RP.

NoRepair

Eliminates the Repair button in the Support Information dialog.

Publisher

The company that publishes the fix

Uninstall String

The string that A/RP calls to uninstall the hotfix

URLInfoAbout

URL link under the publisher link on the Support Information dialog box

Table 8 - Registry Key Values for Add or Remove Programs

Inside Update.exe: The Package Installer for Windows and Windows Components â&#x20AC;&#x201D; 14

Hotfix Registry Entry Location The hotfix registry entry identified below is a legacy location and used only by WinSE. Some of the keys are no longer used; all information included in this portion of the registry is detailed in Table 9 below. Example: HKEY_LOCAL_MACHINE\Software\Microsoft\WindowsNT\CurrentVersion\Hotfix\K B###### Key

Description

(Default)

Not used

Backup Dir

Directory where the backup files are stored

Comments

Update type and KB number

Fix Description

Update type and KB number

Installed

Identifies whether the update has been installed or not. This is necessary because updates are cumulative. For example, update 1 and update 2 contain abc.dll, and were released in January and February, respectively. If, in June, you installed update 2, then in July tried to install update 1, the installed registry entry for update 1 would be zero (0), signifying that the update was not installed but the functionality was already on the computer because update 2 had already been installed and superseded the changes made to abc.dll by the original update 1.

Installed By

No longer used. See Update key below.

Installed On

No longer used. See Update key below.

Service Pack

Identifies the service pack that the fix is planned to be rolled up into, assuming that there is going to be another service pack released for the particular product and other reasons for not including the update in the service pack are not found

Valid

No longer used; always set to 1.

Table 9 - Registry Key Values for a Hotfix

Package Installation Types When installing either a service pack or an update, the payload for the update can be self-contained in the installation package or be an express installation where the payload is determined dynamically. Currently, express packages are available only from the Windows Update Web site. Customers looking for the complete self-contained package, can find it in the Windows Update catalog. No matter how the payload for the installation is attained, the Installer follows the same process to complete the installation. Update.exe uses the same code path to identify what files to install. During the installation process, Update.exe examines the files installed on the computer looking for files that are the same or newer than what is contained in the update. If the same or newer version file is already installed on the computer, there is no need to update the file. Both the express and self-contained types of installations use this technique. Below is a further exploration of these two types of installation.

Inside Update.exe: The Package Installer for Windows and Windows Components â&#x20AC;&#x201D; 15

Self-contained install (Full Install) The self-contained installation, also referred to as a standard or full installation, is simpleâ&#x20AC;&#x201D;all of the files that must be installed on the computer as part of the update are included in the installation package. With the entire payload, Update.exe determines what needs to be installed on the computer and proceeds with the installation. This is the installation technique of choice for large installations behind firewalls where the individual computers do not have access to the Internet or where there is policy prohibiting installation from the Internet. Express install Unlike the self-contained installation, the express installation does not carry the entire payload for the update. Instead, through an understanding of what files that the update requires, it generates a list of files that need to be installed on the computer and retrieves those files from the Windows Update server. It generates the list of files needed for the installation and the files on the computer are compared against the update file list; only files contained in the update that are newer than what is installed on the computer are downloaded and installed. Network install The network installation method, discussed in Deployment Methods, has the unique benefit of reducing and thus limiting the amount of working disk space required by the Installer. By placing the payload on a network location, the Installer will use the network location as its cached working space instead of using the local hard disk. This can be very helpful for environments in which storage space on the local computer is limited. For details about using a network installation, please refer to the appropriate deployment guide.

Debug Symbols Debug symbols are no longer included in packages downloaded from the Windows Update Web site because they were rarely used. The removal of symbols resulted in an average package size reduction of 30 percent. If debugging symbols are required, read the KB article, Hotfix Packages Do Not Include Debug Symbol Files, for details about how to download and install the symbols.

Deployment Methods There are optional methods for deploying service packs and updates to the computers in a networked environment. These include running Update.exe manually with a combination of installation options, using Systems Management Server (SMS), using the Windows Installer, Sysprep, distributing updates by using a shared network distribution folder, or by downloading the hotfixes from the Microsoft Download Center. In general, both service packs and updates can be deployed in a very similar manner.

Windows service pack deployment The best resource for deployment options for a service pack is one of the deployment guides detailed in Table 10 below. These documents provide specifics on deploying the service pack to single- and multiple-computer environments and should be consulted before planning a deployment to the operating system. Applicable to

Document Name

Link to Deployment Guide

Inside Update.exe: The Package Installer for Windows and Windows Components — 16

Windows NT4 – Service Pack 6A

Windows NT Server Deployment

http://www.microsoft.com/ntserver/techreso urces/deployment/default.asp

Windows 2000

Microsoft Windows 2000 Hotfix Installation and Deployment Guide

http://www.microsoft.com/windows2000/do wnloads/servicepacks/SP4/HFDeploy.htm

Windows 2000

Microsoft Windows 2000 Service Pack 4 Installation and Deployment Guide

http://www.microsoft.com/windows2000/do wnloads/servicepacks/sp4/spdeploy.htm

Windows XP

Microsoft Windows XP Hotfix Installation and Deployment Guide

http://www.microsoft.com/WindowsXP/pro/ downloads/servicepacks/sp1/hfdeploy.asp

Windows XP

Deploying Windows XP Part I: Planning

http://www.microsoft.com/technet/treeview/ default.asp?url=/technet/prodtechnol/winxp pro/deploy/depovg/depxpi.asp

Windows XP

Deploying Windows XP Part II: Implementing

http://www.microsoft.com/technet/treeview/ default.asp?url=/TechNet/prodtechnol/winx ppro/deploy/depovg/depxpii.asp

Windows Server 2003

Microsoft Windows Server 2003 Deployment Kit

http://www.microsoft.com/windowsserver20 03/techinfo/reskit/deploykit.mspx

Large scale deployments

Microsoft Solutions for Management on TechNet

http://www.microsoft.com/technet/treeview/ default.asp?url=/technet/itsolutions/msm/D efault.asp

Table 10 - Deployment Guides

Slipstream or combined installation for Windows service packs For service packs there is an option not available to other types of updates—the combined or slipstream method. This method preinstalls the service pack on the operating system before installing the operating system. The slipstream installation enables the operating system image to be updated with a service pack and/or updates before installation. This type of installation enables a computer to be fully updated in a single imaging process. This style of installation is available when installing the entire Windows 2000, Windows XP, or Windows Server 2003 operating systems. (For a full discussion on how to implement a combined install, see Table 10.)

Application error reporting (Watson Reporting) One of the features included in the Q4 version of the Installer, available in December 2003, is the addition of Application Error Reporting (also known as Watson reporting). With the user’s consensus, this functionality reports back to Microsoft details relating to activities at the time of a data crash. All data is handled in accordance with the policies detailed in the End User Privacy Policy in Application Error Reporting document. To understand if a specific version of the Installer supports Application Error Reporting see Appendix A – Installer Versioning and Features.

Update Deployment Various methods and options for installing service packs and hotfixes are as follows:

Inside Update.exe: The Package Installer for Windows and Windows Components â&#x20AC;&#x201D; 17

Attended mode Attended mode is the typical installation method for the home user or individually managed environment requiring user interaction. Typically, the installation is completed with a combination of switches, as documented in Command-line Switches. Installing from a network folder To install the update on multiple computers in an individually managed environment, place the update on a shared network drive and follow the process below. In this example, the distribution folder is a shared network location accessible to all the computers to be updated. 1. On the network location or the computer, create a distribution folder for the update files 2. Navigate to the distribution folder, right-click the folder, and then click Properties 3. Click the Sharing tab and then click Share This Folder 4. In Share Name, enter the name of the distribution folder 5. Click Permissions, and then type in permissions to allow users to install hotfixes from this folder. 6. If there is an NTFS file system partition, click the Security tab, confirm the permissions listed do not conflict with those on the Sharing tab, and then click OK 7. Copy the hotfix package to the distribution folder created in step 1 8. To install the hotfix from the shared network distribution folder, run [update name].exe For example, to install the hotfix from the distribution folder named Update_Folder, type the following: \\servername\sharename\ Update_Folder\[update_name].exe Use the command-line options described in Command-line Switch options to customize the installation. Important: Please review Install Chaining before chaining installations together. Installation batch files Multiple hotfixes can be installed together through the use of batch files. The following batch file samples cover two of the more common scenarios for installing multiple hotfixes from a network share. The first example demonstrates how to batch the installation of the service pack and multiple hotfixes together; we recommend that you use this method whenever possible to enable the Installer to determine if a restart is required. The second example details how to determine if a restart is necessary. 1. Mixing a service pack and updates This example batches together the installation of a service pack and a hotfix installation. The restart on the service pack is suppressed so the update can be applied. Even if a restart was not required by an update (identified as Update_A in the example below), Update.exe will notice that a restart was necessary for the previous installation and will call for a restart when completed. @ECHO OFF SETLOCAL REM Location of updates to install

Inside Update.exe: The Package Installer for Windows and Windows Components â&#x20AC;&#x201D; 18

SET PathOfFixes=Drive:\hotfix %PATHTOFIXES%\SP_install.exe /Z /U %PATHTOFIXES%\Update_A.exe /U

The QChain functionality in the Installer enables multiple installations to be chained together and processes the Pending File Renames from all installations in one restart. This example uses the /U switch, which suppresses the user interface, so the user is not requested to provide input to the process. 2. Determining if a restart is necessary Use the following batch file to evaluate the return code from the Installer and determine if a restart is necessary because the restart could be called for by any of the 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 /Z /U IF ERRORLEVEL 3010 SET Reboot_Needed=1 %PathOfFixes%\update_B.exe /Z /U IF ERRORLEVEL 3010 SET Reboot_Needed=1 %PathOfFixes%\Update_C.exe /Z /U IF ERRORLEVEL 3010 SET Reboot_Needed=1 REM force restart here IF %Reboot_Needed%.==1. Shutdown /r

The previous example is checking the return code from the Installer to determine if a restart is necessary. This is the recommended procedure when installing updates. Note: In Windows XP, 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; or Shutgui.exe; and must be installed separately. 3. Unattended installation methods The unattended functionality of the Installer enables automated installation of updates and service packs, thus eliminating user intervention. There are a number of ways to accomplish unattended installation, ranging from developing custom batch installations using Command-line Switches to using automation software such as SMS or SUS to install the update or service pack on all computers across a network. The best resource for studying options for unattended installation is the Microsoft Windows 2000 Guide to Unattended Setup document, also known as Unattend.doc. This document is located on the supporting CDs of Windows 2000 distribution disks. For Windows XP installations, an alternative to building an unattended installation via Update.exe is to use Sysprep. Read How to Use Sysprep: An Introduction for more information.

Inside Update.exe: The Package Installer for Windows and Windows Components — 19

Deployment Timing Hotfix Migration Hotfix migration is available only for Microsoft Windows XP and Windows Server 2003. In these environments, hotfix migration maintains the same update level when the service pack is upgraded. Different processes are used for each platform, but they both achieve the same effect. In the last few weeks before a service pack release, there is a period in which released hotfixes may not be included in the service pack. When this happens, WinSE provides a hotfix that can be migrated to ensure that when the service pack is installed it will not be necessary to reinstall the hotfix. This is done by installing the fix for the current operating system revision level and caching the hotfix for the next service pack level. When the later service pack is installed, the hotfix is migrated to the later version. For information about dual-mode hotfixes for Windows XP, review the KB article, Description of Dual-Mode Hotfix Packages for Windows XP; for information about hotfix migration for Windows Server 2003, read Description of the Contents of a Windows Server 2003 Product Update Package. For information about the directory structure used for the hotfix migration, read Contents of the Update Package. For the dual mode installs, the package contents contain an additional file. Xpsp1hfm.exe manages the migration of the new update to the upgraded service pack installation and determines which version of the update must be installed. For a dual-mode install in which the contents of the package were extracted first, execute the unpacked xpsp1hfm.exe file instead of Update.exe to run the installation; the same switches that apply to Update.exe can be applied to Xpsp1hfm.exe.

Blocklists - Overwriting Installed Updates Blocklisted fixes are updates released at the end of the service pack cycle and are not included in the new service pack. There are a limited number of these “delta” updates created during a small window in the service pack. During service pack installations, these updates will be overwritten and an Installer log entry identifying the updates will be added in unattended mode or in interactive mode. During the Inspecting your current configuration phase of the installation, users will receive the following message: “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.” Updates overwritten during the service pack installation must be installed again. To identify which updates may be overwritten when a service pack is installed, refer to the service pack release notes or examine the Updtblk.inf file. After identifying the updates that will be overwritten, download an updated version of the update and chain it onto the end of the service pack installation. Blocklisted updates are also relevant when installing updates. In this case, it just means that the version of the installed update is out of date. When encountered, a blocklisted update requires a download and the installation of a later version of the update. The message delivered to the user is as follows:

Inside Update.exe: The Package Installer for Windows and Windows Components — 20

“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######.” For more information about blocklisted updates, read the following KB 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

Contents of the Update Package Besides the Package Installer, an update package contains the supporting files for the Installer (.inf files, etc) and the payload (files to update). This section discusses the binaries, log files, and the file structure of those two sets of files.

Binaries Referring to a package generally means talking about the contents of the service pack or update. Keep in mind that the same logic and installation technology are used for both. The following table refers to Installer binaries and applies to both service pack and hotfix installations: Binary

Description

Branches.inf

Defines the hierarchal relationship between the branches.

Custom.dll or spcustom.dll

A custom .dll file provided so that functionality not natively provided by the Package Installer can be added by other teams using the Package Installer. As more teams within Microsoft adopt the Package Installer, more custom.dll files will be used. The custom.dll used by the Windows Sustained Engineering team is called SPCustom.dll. (See Custom.dll for more details on its use.)

Event logging DLL (Spmsg.dll)

Used by the Installer to record events to the event viewer. There is a SPmsg.dll that is released with each service pack and hotfix. All versions of the operating system use the same Spmsg.dll.

Spnres.dll

Resource binary for service packs; supporting new resource strings added to the service pack

SpunInst.exe

Located in the uninstallation directory with the files that will be restored.

Update.exe

Core of the Package Installer, it is an .inf-driven Installer working from the .inf files released with the package.

Update.inf

Drives the installation, providing variable information to the Installer, including files to install, install locations, registry keys to update, string information to display during installation; specifies event log name and location, etc.

Update.ver

Describes the version, size, and hash information for the payload.

Update_RTMGDR

One of the Update.inf files for a multi-branch-aware installation.

Update_RTMQFE

One of the Update.inf files for a multi-branch-aware installation.

Updatebr.inf

Defines the default branch, provides pointers to the Update.inf files and the common Setup files.

Table 11 - Installer Binaries

Inside Update.exe: The Package Installer for Windows and Windows Components — 21

Custom.dll Using a custom.dll is a way to provide custom functions not supported by the Package Installer. Sustained engineering teams use this to provide specific functionality not native to the Package Installer. The name of the custom.dll is customizable and is provided by specifying the name in the [Configuration] section of the .inf file. Custom actions can be invoked at different times during the installation.

.inf Files The .inf files provide the Installer with installation details on the specifics of the installed files. This eliminates the need for custom actions to be defined in the Installer for every new, released update. For the Windows Package Installer, there is a number of .inf files used, depending upon the type of package installed. All packages will have an Update.inf file and, depending upon the type of package; others may have Branches.inf and Updatebr.inf files. See Contents of the Update Package for information about what files are contained in each package.

Update.inf The Update.inf file is at the core of the directives provided to Update.exe. This file takes a modified name (Update_rtmgdr.inf and Update_rtmqfe.inf) for multi-branch-aware installations (see Multi-Branching .inf Files for more information). The Update.inf file structure is very extensible. At the highest level, Update.inf provides Update.exe with operating system version information to update, registry entries to modify, and custom functions to run during installation. The .inf files used by the Package Installer are very similar to those documented in Creating an INF file in the Microsoft Developers Network (MSDN) library; there are some differences, but, in general, the syntax of the file is the same. There are a number of common sections found in most Update.inf files used to install patches; the common sections are listed in Appendix B – The Update.inf File.

Multi-Branch-Aware .inf Files To support multi-branching, two versions of the Update.inf file are required, Update_gdr.inf and Update_qfe.inf (the names must be different because they are both located in the same directory). There are also two additional required .inf files, Updatebr.inf and Branches.inf, which identify the branches and their relationships. Branches.inf This file defines the known branches that the update could have been developed from and the branch hierarchy. During installation, the computer is compared to Branches.inf to determine which branch must be installed; this file is also used when migration from an earlier version of a hotfix to a later version is necessary. The Branches.inf file is copied to the computer during the installation and, because it is versioned, determines when a later version is available. When a later version releases with another update, it will be updated. Updatebr.inf The Updatebr.inf file serves two purposes: it defines the common files and their location in the multi-branch-aware file structure, and it defines the relationship between the branches being installed and the Update.inf file. In a multi-branch-aware installation, there are multiple Update.inf files shipped with the update to accommodate the need for different file sets, based on the branch being installed. One of the critical uses for the

Inside Update.exe: The Package Installer for Windows and Windows Components — 22

Updatebr.inf file is to link the branch with the appropriate Update.inf file— Update_rtmqfe.inf or Update_rtmqfe.inf.

Installer Log Files The Installer log files are generated during the installation of an update or service pack. The logs contain status and other useful information related to the installation. For every service pack or update installed, a new log file is generated. The Installer log files are located in the Windows root (%WINDIR%) directory and are named for easy identification. For example, to install the update associated with KB article 824146, the log file would be named KB824146.log. Appendix D – Sample Install Log contains a sample Installer log with annotations on what is logged.

Log Name and Location The name (not location) of the Installer log is defined by the Update.inf file. The .inf file lists an entry for the name of the log file (see the InstallLogFileName variable under the [Strings] section, that is usually set to %SP_SHORT_TITLE%.log, which resolves to the name of the update). Standard Windows Sustained Engineering log file names are in the following list: • • • •

Service Pack Installation – Svcpack.log Service Pack Uninstallation – Spuninst.log Hotfix Installation - Q123456.log Hotfix Uninstallation – Q123456UnInst.log

Log Contents The following list provides a quick summary of some of the information in the log file: • • • • • • • • •

Command-line arguments Package installation location Pending file renames from the registry Timing statistics Disk usage calculations OEM file-check results File copy operations Registry updates Processes executed from the Custom.dll and return codes

In the Q4 and later versions of the Installer, the log mechanism of the Installer will be more robust. The comments documented here and in the appendix are relevant to the Q3 Installer. For more information about Installer versioning, see Appendix A – Installer Versioning and Features.

Log Entries The Installer log contains a number of entries that seem to be errors, but are meant to be informative. This is because the Installer uses the standard Windows SetupAPI and control over the format and entries are somewhat limited. The following table lists common entries in the Installer log that may be confused with errors: Condition

Details

DoInstallation: CleanPFR failed:

Cleaning up the PFR list in the registry, this indicates that there were no entries in PFR .

Inside Update.exe: The Package Installer for Windows and Windows Components — 23

FetchSourceURL: SetupOpenInfFile Failed to open file: d:\20fc32a210eecc6746827750294191c b\i386\update\update.url

This is only an error if in patching mode and part of the update is installed from the Internet. If all files needed for the update are local, it is not an error.

DoInstallation: FetchSourceURL for d:\20fc32a210eecc6746827750294191c b\i386\update\update.inf Failed

This is only an error if in patching mode and part of the update is installed from the Internet. If all files needed for the update are local, it is not an error.

BuildCabinetManifest:SetupOpenInfFile failed with error INVALID_HANDLE_VALUE

Indicates that it is verifying whether the file was included in the package, this error indicates the file was not part of the package.

Failed Deleting C:\WINNT\system32\msiinst.tmp 2

To ensure that all directories and files created were cleaned up, indicates that the file was not created, so there was nothing to delete.

RegisterFile:RegOpenKeyEx for SOFTWARE\Microsoft\Updates\Window s 2000\SP4\Q811493\Filelist\3 Failed: 0x2

Informational; looking for a registry key that does not exist. In this example, it may be that update Q811493 was not previously installed.

LoadFileQueues: SetupGetSourceFileLocation for halacpi.dll failed: 0xe0000102

Any errors referencing hal*.* files are generally not errors. The Installer always searches the package hal*.* files and, if it finds them, installs those files.

Table 12 - Log Entries That Seem to Be Errors

The log entries for Update.exe are under review and will change substantially in future versions of the Installer. The previous log entries are applicable to the Q3 and earlier versions of the Installer; if your log file is substantially different, evaluate the version of the Installer that created the log. (See Appendix A – Installer Versioning and Features for more details.)

File Structure When the contents of the package have been extracted, they are placed in subdirectories under the extraction (or destination) folder on the hard drive. The folder name (extraction folder) will be either specified or randomly generated by the Installer off the root directory of the current drive. For extracted package contents, the term “root directory” means the same as the folder to which the package was extracted. The contents of this directory will consist of the Installer, supporting files, and the payload. There are three possible directory structures available. The final choice is dependent upon the age of the package, the type of package, and the operating system that the update is intended for. The directory structures for the Standard, Dual Mode, and MultiBranch-Aware structures and the packages most likely found in each operating system are in the following table: Directory Structures

Windows 2000

Windows XP

Windows Server 2003

Standard

N/A

Dual Mode

N/A

Multi-Branch-Aware

N/A

Table 13 - Directory Structure by Operating System

Standard File Structure The standard directory structure is the simplest (see Graphic 2 below); files are placed in one of two locations, either the root directory where they were extracted or the update directory.

Inside Update.exe: The Package Installer for Windows and Windows Components — 24

Graphic 2 - Example of Standard File Structure

For an example of this file structure, download the 823980 update for Windows 2000 and see Security Bulletin MS03-026.. The following table shows the files’ location in the directory structure and their use: File Name

Installation Location

Use

Spuninst.exe

Root

Uninstallation program installed with the executable file

Spmsg.dll

Root

Messaging DLL for writing messages to the event log

Spnres.dll

Root

Resource DLL for including new resources in the service pack (see SPnRes.dll below for more information)

Empty.cat

Root

Security catalog (Windows 2000 only)

Eula.txt

Root\Update

Licensing agreement displayed during interactive setup

KB######.cat

Root\Update

Security catalog

Custom.dll

Root\Update

Contains custom functionality for installation

Update.exe

Root\Update

Installs the fix.

Update.inf

Root\Update

Provides variables and supporting information for the installation

Updblk.inf

Root\Update

Identifies blocklisted updates (see Blocklists – Overwriting Installed Updates for more information)

Update.ver

Root\Update

Describes the version, size, and hash information for the payload.

Package payload

Root

Files to install as part of the update

Table 14 - Standard File Structure Use and Location

Dual-Mode File Structure The file structure for the dual-mode install is more complex than the standard install. It carries additional payload to service two versions of the same operating system. For example, one update could service Windows XP RTM and Windows XP SP1 (see Graphic 3 below). Dual-mode installs are available for Windows XP only. For this discussion, it is assumed that the dual-mode install package was developed to update Windows XP RTM and Windows XP SP1. For more information about dual-mode installs and why they are necessary, read Hotfix Migration under Deployment Timing. In this case, the dual-mode install files are placed in one of four directories: • • •

The root directory – Contains the executable file that determines which payload must be used The common directory - Contains files used by both installation versions The RTM directory – Contains the payload-supporting files for SP1 installation

Inside Update.exe: The Package Installer for Windows and Windows Components — 25

•

The SP1 directory – Contains the payload-supporting files for SP1 installation Structure Root Common RTM SP1

Graphic 3 - Example of Dual Mode File Structure

For an example of this file structure, download the 823980 package for Windows XP and see Security Bulletin MS03-026.. The following table shows the files’ location in the directory structure and their use: File Name

Installation Location

Use

Xpsp1hfm.exe

Root

Dual mode only, determines the appropriate version of the fix to install and launch the Installer

Spuninst.exe

Root\Common

Uninstallation program installed with the executable file.

Spmsg.dll

Root\Common

Messaging DLL for writing messages to the event log.

Spnres.dll

Root\SP1 and/or SP2 directorie(s)

Resource DLL used for including new resources into the service pack (see SPnRes.dll below for more information). Included in package when necessary.

Eula.txt

Root\Common

Licensing agreement displayed during interactive Setup

KB######.cat

Root\SP1\Update Root\SP2\Update

Security catalog

Custom.dll

Root\Common

Contains custom functionality for installation.

Update.exe

Root\Common

Installs the fix.

Update.inf

Root\SP1\Update Root\SP2\Update

Provides variables and supporting information for the installation.

Updblk.inf

Root\SP1\Update Root\SP2\Update

Identifies blocklisted updates (see Blocklists – Overwriting Installed Updates for more details).

Update.ver

Root\SP1\Update Root\SP2\Update

Describes the version, size, and hash information for the payload.

Payload

Root\SP1 Root\SP2

Files to install on the computer

Table 15 - Dual Mode File Structure Use and Location

Multi-Branch-Aware File Structure The multi-branch-aware structure, applicable to Windows Server 2003 only, supports multiple installation scenarios in the same package, much like the dual-mode

Inside Update.exe: The Package Installer for Windows and Windows Components — 26

installations. Besides the scenario described in dual-mode installations, multi-branchaware updates can update two different development environments of the same service pack level of the operating system. Between service pack releases, updates are released from two different development environments referred to as branches; the general distribution releases (GDR) branch and the hotfix branch. Product updates released to address widespread critical issues, such as security vulnerabilities, are broadly released by Microsoft and are known as GDRs and are distributed through Windows Update. These product updates are created in a GDR branch separate from all other hotfixes. Hotfixes are distributed by Microsoft Product Support Services (PSS) to address unique customer issues and are not tested as thoroughly as GDR releases. These two separate branches effectively minimize the risk to customers when they accept a GDR by enabling them to receive a fix that addresses only widespread critical issues (such as security vulnerabilities) and does not include the hotfix code changes. For more information about multi-branching, see Description of the Contents of a Windows Server 2003 Product Update Package. No matter what branch the patch was created in, the fix should be rolled up in the next service pack. When the files from a multi-branch-aware update are extracted, there is an update directory under the root directory, plus multiple directories under the root directory containing the binaries for the relevant branches. Example names are shown in Graphic 4. The first part of the directory name reflects the product milestone (for example, RTM means Release To Market, and SP1 means Service Pack 1, etc). The second part of the directory name identifies the branch (development environment) that the update was built from. In the following example, this is either GDR or QFE (the multi-branch-aware updates use the abbreviation “QFE” as an equivalent to hotfix, which is the current standard name for this branch). In this structure, the directories are broken down by Installer and payload; the Installer with all the supporting files necessary to install the update is stored in the Update directory and the payload is contained in the RTMQFE and RTMGDR directories. Structure Root Update RTMQF RTMGDR Graphic 4 - Example of Multi-Branch-Aware File Structure

For an example of this file structure, download the 823980 package for Windows Server 2003 and see Security Bulletin MS03-026. The following table shows the files’ location in the directory structure and their use: File Name

Installation Location

Use

Spuninst.exe

Root

Uninstallation program installed with the executable file

Spmsg.dll

Root

Messaging DLL for writing messages to the Event log

Eula.txt

Root\Update

Licensing agreement displayed during interactive Setup.

Inside Update.exe: The Package Installer for Windows and Windows Components — 27

KB######.cat

Root\Update

Security catalog

Custom.dll

Root\Update

DLL containing custom functionality for installation

Update.exe

Root\Update

Installs the fix.

Update_rtmgdr.inf

Root\Update

Provides variables and supporting information for the RTMGDR installation.

Update_rtmqfe.inf

Root\Update

Provides variables and supporting information for the RTMQFE install

Branches.inf

Root\Update

Defines the branches hierarchy of a multibranch-aware install

Updatebr.inf

Root\Update

Defines the default branch for a multibranch-aware install

Updblk.inf

Root\Update

Identifies blocklisted updates (see Blocklists – Overwriting Installed Updates for more details)

Update.ver

Root\Update

Describes the version, size, and hash information for the payload.

Spnres.dll

Root\RTMGDR Root\RTMQFE

Resource DLL for including new resources into the service pack (see SPnRes.dll below for more information). In this example, the file receives no special treatment and is included as part of the payload when necessary.

Package payload

Root\RTMGDR Root\RTMQFE

Files to install on the computer

Table 16 - Multi-Branch-Aware File Structure Use and Location

Summary The Windows Package Installer is a full-featured Installer devoted to delivering service packs and updates to the operating system and installed product. The Installer will continue to evolve to meet the needs of customers and product groups. Installations can be accomplished through standalone mode, a network installation, or a hybrid with an installation batch file to drive the Installer. The deployment guides that are released with the service packs are the best resource for deployment methods. The detailed view into the Installer functionality discussed in this document provided the reader with a fairly solid understanding of what actions the Installer performs other then just copying files. Also covered was a detailed explanation of what registry changes are made and how they are used, information about what is written to the installation log files, and information about the structure of the package, including the different types of commonly found package structures. This white paper was current with the Installer technology as of December 2003; look for future revisions of this document as the Installer changes to meet customer needs.

Appendix A â&#x20AC;&#x201C; Installer Versioning and Features Versioning In an effort to consolidate Installers, product groups are turning to Update.exe to release code fixes to the public. To provide greater efficiencies, in 2003 the development team responsible for Update.exe has switched to a quarterly development cycle, where new versions of the Installer are released every three months; in 2004, releases will occur on a trimester cycle, delivering a new release every four months. All hotfixes are matched and tested with current Installer functionality. Therefore, it is important not to distribute hotfixes using versions of Update.exe other than what they were released with, to avoid introducing errors to the environment.

Installer Features by Version The following table identifies the major features added to each revision of the Installer and the approximate date they entered into production. For specific Installer functionality, Table 17 cross-references the Update.exe version with functionality. Many of the features defined below may not be directly applicable for end users. While the update Package Installer is being adopted by other teams at Microsoft, many features are being added for other Microsoft teams. Name

Version

Significant Features

Released

5.3.16.5

Improved logging in Update.exe Updated uninstallation user interface Ability to uninstall from recovery console User-friendly Add/Remove Program entries for hotfixes Printable End User Licensing Agreement (EULA)

March 2003

5.3.18.6

Warn if an installation/uninstallation is attempted in Safe mode Uninstallation switch added to Update.exe Packages installed with /N show in Add or Remove Programs

June 2003

5.3.24.4

Addition of a prerequisite section in the .inf file Integration of Watson reporting for non-crash errors Support for standard command-line Installer switches

September 2003

5.4.15.0

Feature details for this version of Update.exe can be found in KB article 832475.

April 2004

Table 17 - Installer Features by Version

Note: Previous Windows Server 2003 updates were released with the Q2 Installer version 5.3.17.9. The feature set for this version is the same as the Q2 Installer previously described.

Determining the Installer Version After understanding what features have been added to the Installer, it is important to differentiate one Installer version from another. To do this, extract the contents from the shipping package. Once extracted, use the tables in the Extracted package directory

Inside Update.exe: The Package Installer for Windows and Windows Components — 29

structure to find Update.exe. To view the version number, right-click Update.exe, and

then click Properties on the shortcut menu that appears. From the update.exe Properties dialog box, click the Version tab. (See Graphic 5 below.)

Graphic 5 - Sample Installer Version

Appendix B – The Update.inf File A fully documented example of the common sections of an Update.inf file follows. When using this reference, keep in mind that an entry's position in the .inf file in irrelevant, but there is a standard order followed by most files. In the following sample file the order has been rearranged for clarity: [Version] – Provides information about the version of the product that the update applies to. In the entries in the version section, a range of versions is specified that the update is applicable to. The ToUpdate value specifies the minimum version where Max… specifies the maximum version to be updated by the update (this is validated against the registry entry HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ CurrentBuildNumber). Common entries for the [Version] section: •

Signature = "signature-name"

Inside Update.exe: The Package Installer for Windows and Windows Components — 30

Update.exe only supports installing on the Windows NT platform so the signature will always be $Windows NT$. •

NtBuildToUpdate = build number Minimum required Windows build number (four digits) that this package will apply to.

•

MaxNtBuildToUpdate = build number Maximum required Windows build number (four digits) that this package will apply to.

•

NtMajorVersionToUpdate = minimum operating system major version number Minimum required major version number the package will apply to.

•

MaxNtMajorVersionToUpdate = maximum operating system major version number Maximum required major version number the package will apply to.

•

NtMinorVersionToUpdate = minimum operating system minor version number Minimum minor version number the package will apply to.

•

MaxNtMinorVersionToUpdate = maximum operating system minor version number Maximum minor version number the package will apply to.

•

MinNtServicePackVersion = minimum service pack level number Minimum service pack level for installation. (Number is SP level * 256.)

•

MaxNtServicePackVersion = maximum service pack level number Maximum service pack level for installation. (Number is Sp level * 256.)

•

ThisServicePackVersion = current service pack level number Current service pack level that is package will apply to. (Number is service pack level * 256.)

•

LanguageType = %LangTypeValue% System language value for this package, must match distribution CDs. If this field is left blank or set to 0x0, this package will install on all languages. %LangTypeValue% is a variable defined in the following [String] section:

•

CatalogFile = catalog file Catalog file to vouch the .inf file [Version] Signature="$Windows NT$" LanguageType=%LangTypeValue% NtBuildToUpdate=3790 MaxNtBuildToUpdate=3790 NtMajorVersionToUpdate=5 MaxNtMajorVersionToUpdate=5 NtMinorVersionToUpdate=2 MaxNtMinorVersionToUpdate=2 MinNtServicePackVersion=0 MaxNtServicePackVersion=0 ThisServicePackVersion=0 CatalogFile=%SP_SHORT_TITLE%.cat

DirectoryID.Include – Determines the installation location at runtime through the use of a process.

Inside Update.exe: The Package Installer for Windows and Windows Components — 31

In this example, AddDirID points to the [RISAdm.DirID] section later in the .inf file. The [RIDAdm.DirID] section identifies what to run; in this case, it is a function in the SPCustom.dll RISAdminSection. [DirectoryId.Include] AddDirId = RISAdm.DirId … [RISAdm.DirId] DirId = 65625 CustomFunction = SpCustom.dll,GetRISAdminPathName InstallFromSection = RISAdminSection CopyFlags = SP_COPY_FORCE_NEWER | SP_COPY_REPLACEONLY

ProductCatalogsToInstall – Provides the name and location of the catalog installed. The variable %SP_SHORT_TITLE% used in the following example is resolved in the [Strings] section of the .inf file: [ProductCatalogsToInstall] %SP_SHORT_TITLE%.cat, update\%SP_SHORT_TITLE%.cat

ProductInstall.CopyFilesAlways – Identifies the section detailing the files that should always be copied onto the system during the installation. [ProductInstall.CopyFilesAlways] CopyFiles=CopyAlways.System32.files CopyFiles=CopyAlways.Inf.files

ProductInstall.CopyFilesAlways.platform_name – Defines the files to install in all cases by platform name; notice the platform name at the end of the section name. Information about professional and server platforms are in the following example: [ProductInstall.CopyFilesAlways.Professional] CopyFiles=CopyAlways.Prf.System32.files [ProductInstall.CopyFilesAlways.Server] CopyFiles=CopyAlways.Srv.System32.files CopyFiles=CopyAlways.Srv.Inf.files

ProductInstall.ReplaceFilesIfExist – Identifies files to replace if they already exist. The actual details of the files to copy are contained in separate sections identified by the CopyFiles directives. In this case, it references two sections to identify the files to copy: System32.files and Cache.files. [ProductInstall.ReplaceFilesIfExist] CopyFiles=System32.files CopyFiles=Cache.files … [System32.files] urlmon.dll,RTMGDR\urlmon.dll [Cache.files] urlmon.dll,RTMGDR\urlmon.dll

Inside Update.exe: The Package Installer for Windows and Windows Components — 32

ProductInstall.GlobalRegistryChanges.Install – Identifies the section that contains registry keys to add during the installation. In this case, the AddReg entry references the [Product.Add.Reg] section of the .inf file containing the keys. ProductInstall.GlobalRegistryChanges.Install] AddReg=Product.Add.Reg … [Product.Add.Reg] HKLM,SOFTWARE\Microsoft\Windows NT\CurrentVersion\Hotfix\%SP_SHORT_TITLE%,"Installed",0x10001,1 [ProductInstall.CopyFilesAlways.Professional]

DestinationDirs – Defines the destination of the files to install. In this case, it defines the system directory as %WINDIR%\system32 and the system .dll cache directory as %WINDIR%\system32\DllCache. Note: This section references the System32.files and Cache.files entries, which will follow in the .inf. The [DestinationDirs] section provides the target directory and a pointer to the section containing the list of files to install. After reading the [DestinationDirs] sections, the Package Installer will retrieve the file names and the source location for the installation from the System32.files and Cache.files entries of the .inf file. [DestinationDirs] System32.files=11 Cache.files=65619

; %WINDIR%\system32 (replace if exist) ; %WINDIR%\system32\DllCache (replace if exist)

ArchiveCatalogFilesOnly – Defines the name of the catalog file to archive in the uninstallation directory. The variable %SP_SHORT_TITLE% is resolved in the [String] section of the .inf file. [ArchiveCatalogFilesOnly] %SP_SHORT_TITLE%.cat

SourceDisksNames – Identifies the disk ID and the disk description for the installation disk; if there are multiple installation disks, there will be multiple entries. In the section below, the disk ID is 1 and the description is contained in %ServicePackSourceFiles%, which is defined in the [String] section at the end of the .inf file. [SourceDisksNames] 1=%ServicePackSourceFiles%

SourceDisksFiles – Names the source files (files to install) and identifies the source disks where those files can be found. SourceDiskNames is identified in the previous paragraph. [SourceDisksFiles] RTMGDR\mshtml.dll=1 RTMGDR\shdocvw.dll=1 RTMGDR\urlmon.dll=1

Strings – Defines the string tokens used elsewhere in the .inf file. [Strings] BUILDTIMESTAMP=20030914.180726

Inside Update.exe: The Package Installer for Windows and Windows Components — 33

ServicePackSourceFiles="Windows Server 2003 Hotfix Source Files" SP_SHORT_TITLE="KB828750" SP_TITLE="Windows Server 2003 Hotfix - KB 828750" SERVICE_PACK_NUMBER=1

Configuration – Appears last in an .inf file by convention, every .inf file must have a configuration section which defines the type of installation, event log DLL name, and other information critical to the installation of the package. [Configuration] InstallationType=Hotfix InstallLogFileName=%SP_SHORT_TITLE%.log UnInstallLogFileName=%SP_SHORT_TITLE%Uninst.log UnInstallDirName=$NtUninstall%SP_SHORT_TITLE%$ EventLogKeyName=NtServicePack EventLogDllName=spmsg.dll

Inside Update.exe: The Package Installer for Windows and Windows Components — 34

Appendix C – Detailed Installer Process Flow

Inside Update.exe: The Package Installer for Windows and Windows Components â&#x20AC;&#x201D; 35

Was /n switch passed to exe

Create backup directories

YES

Parse update.inf file building list of files to be installed

Create inventory thread, passing list of files to be installed

Is Setup in interactive mode

Initialize component manager

YES

Display EULA and wait for agreement

Read update.ver

Obtain file names, sizes, hashes and version information for each file. SetupAPI; Scan file queue for costing informaiton NO SetupAPI; Scan file queue collecting target and source paths

Wait for inventory thread to finish

Commit the file queue

Analyze files to copy porcedure

Inside Update.exe: The Package Installer for Windows and Windows Components â&#x20AC;&#x201D; 36

Run - ConfirmInstallation procedure - ProcessBeforeArchive section from inf file.

Is SP install without /n switch

YES

Does Directory already exist?

YES

Cleanup previous uninstall directory

Create uninstall directory

Archive old files

Archive KB#### ##.cat

Run ArchivingComplete

Archive registry entries

Create spuninst.inf in backup directory

Copy to Uninstall dir - spuninst.exe - svcpack1.dll

Inside Update.exe: The Package Installer for Windows and Windows Components — 37

Interactive Mode

YES

Point of no return, disable cancel button in UI

YES

Turn off System File Protection

NO Install and register SPmsg.dll

If W2K/SP2 or less

NO Stop services to avoid open file conflicts

Was /n switch given

YES

Delete old uninstall directory, if exists

If W2K or newer

YES

Install Catalog files

YES

Delete LastGood and LastgGood.tmp folder

If Windows SP patch

Inside Update.exe: The Package Installer for Windows and Windows Components — 38

Copy queued files

Execute ProcessToRun (after file copy) function

If XP or newer w/side by side assemblies

YES

Install side by side assemblies

If W2K or XP

YES

Prune non-cumulative catalogs

NO Call custom.dll CopyComplete procedure

Update registry from Product.add.Reg key in update.inf

Call custom.dll ProcessesToRun procedure

If Windows SP

YES

Check for and delete any old LastGood and LastGood.tmp dir’s

Inside Update.exe: The Package Installer for Windows and Windows Components â&#x20AC;&#x201D; 39

Clean up marked files and folder

SP or update install

Update

SP Log Event and register update Log event and register SP

Create MIF and SMS deployment files

Was /n switch passed to exe

YES Registry cleanup; delete previous installed update information.

Run SuccessInstallation procedure

Delete dups from PFR, leaving superior file.

Delete old uninstall directory if exist

Inside Update.exe: The Package Installer for Windows and Windows Components — 40

Start services previously shut-down

Call Custom.dll DirectoriesToCleanup and DirectoriesToCleanup. AfterInstall procedure

Delete extracted files

Is reboot required?

YES

NO Run ProcessToRunAfter Reboot function

End

Graphic 6 Analyze Detailed Installer Process Flow

Shutdown system

Inside Update.exe: The Package Installer for Windows and Windows Components — 41

Analyze Component Procedure

For each file in list

Does target file exist

Is flagged replace if exist

YES

Mark file not to copy

Next file

NO Mark file to copy

YES

Is target versioned

YES

Is source version higher

Next file

YES

Is file OEM Supplied

YES

Was /o supplied

Do not overwrite file, mark to not copy

YES NO NO

Do hashes match

Are file version equal

YES

Are file hashes equal

Do not overwrite file, mark to not copy

Mark file to copy

Yes

Do not overwrite file, mark to not copy

Mark file to copy

Next file

YES

Do not overwrite file, mark to not copy

Next file

NO Mark file to copy

Graphic 6 - Analyze Component Procedure

Appendix D – Sample Installer Log For a complete review of the Installer logs, see Installer Logs before using this appendix. The following sample Installer log has been annotated to provide information about each entry; where there are multiple instances of the same type of entries, they have been removed for clarity. Each entry in the log file is followed by three asterisks (***). Added comments follow the string of asterisks.

Inside Update.exe: The Package Installer for Windows and Windows Components â&#x20AC;&#x201D; 42

service pack started with following command line: -q /Z *** The command-line switches are used to call the package. For more information, see Command-line Switches. DoInstallation: CleanPFR failed: 0x2 *** This is effectively sorting the PFR queue to ensure that the right versions of the files are updated. For more information, see Pending File Renames and Install Chaining. FetchSourceURL: SetupOpenInfFile Failed to open file: c:\090947fef595ce12d15a\update\update.url *** Documented above in Log Entries. DoInstallation: FetchSourceURL for c:\090947fef595ce12d15a\update\update.inf Failed *** Documented above in Log Entries. CreateUninstall = 1,Directory = C:\WINDOWS\$NtUninstallQ815485$ *** Note: This is the creation of the uninstallation directory. All .dll and .inf files needed for the uninstallation of the update will be placed in this directory. LoadFileQueues: SetupGetSourceFileLocation for halacpi.dll failed: 0xe0000102 *** Known failure, see Installer Log Files. BuildCabinetManifest:SetupOpenInfFile failed with error INVALID_HANDLE_VALUE *** Known failure, see Installer Log Files. AnalyzePhaseZero used 0 ticks *** Millisecond-based timing of a process internal to the Installer. No c:\windows\INF\updtblk.inf file. *** Note: Checking for the Blocklist File. SetupFindFirstLine in LoadExclusionList Failed with error: 0xe0000102 *** Installer is looking for the load exclusion list, which is the list of files to exclude from the installation. In this case, there is none. Oem driver C:\WINDOWS\System32\DRIVERS\e100b325.sys is signed by oem0.CAT and will not be replaced *** Builds the list of files that are OEM files and must not be overwritten during the installation. AnalyzePhaseOne: used 53517 ticks *** AnalyzePhaseTwo used 20 ticks *** AnalyzePhaseThree used 0 ticks

Inside Update.exe: The Package Installer for Windows and Windows Components â&#x20AC;&#x201D; 43

*** AnalyzePhaseFive used 0 ticks *** AnalyzePhaseSix used 0 ticks *** AnalyzeComponents used 53787 ticks *** Downloading 0 files *** bPatchMode = FALSE *** Inventory complete: ReturnStatus=0, 54208 ticks *** This is the return from the inventory thread (see Appendix C for details on the inventory thread). Return status from this function = 0, indicating success. Num Ticks for invent : 54208 *** Timing for the completion of the inventory thread to build a list of files to be installed and to validate them (see Appendix C for details). Allocation size of drive C: is 4096 bytes, free space = 36897738752 bytes *** Determines free space on disk before installation of the update or service pack. Drive C: free 35188MB req: 13MB w/uninstall 32MB *** Determines free space on disk before installation of the update or service pack. LoadFileQueues: SetupGetSourceFileLocation for halacpi.dll failed: 0xe0000102 *** Known failure, see Installer Log Files. Num Ticks for Backup : 260 *** Times above process. Num Ticks for creating uninst inf : 201 *** Times above process. Registering Uninstall Program for -> Q815485, Q815485 , 0x0 *** Creates uninstallation information in registry; these are the entries used by Add or Remove Programs. LoadFileQueues: SetupGetSourceFileLocation for halacpi.dll failed: 0xe0000102 *** Known failure, see Installer Log Files. System Restore Point set. *** Sets the system restore point used by the operating system to return the system to a known state.

Inside Update.exe: The Package Installer for Windows and Windows Components — 44

RegisterFile:RegOpenKeyEx for SOFTWARE\Microsoft\Updates\Windows XP\SP2\Q815485\Filelist\0 Failed: 0x2 *** Looks for the existence of this key, see Installer Log Files. Copied file: C:\WINDOWS\System32\DRIVERS\ndis.sys *** File copy confirmation to working directory. Copied file: C:\WINDOWS\System32\DllCache\ndis.sys *** File copy confirmation to DLLCache directory. Copied file (delayed): C:\WINDOWS\System32\SET14.tmp *** This is an entry being made for PFR. Num Ticks for Copying files : 7611 *** Times file copy operation. Num Ticks for Reg update and deleting 0 size files : 10 *** Times registry updates. ---- Old Information In The Registry -----*** This section summarizes the old registry information followed by the new registry information. This information pertains specifically to the update, not any functional changes that the update may require. Source:C:\WINDOWS\System32\SET13.tmp Version: 5.1.2600.1181 *** ---- New Information In The Registry -----*** Source:C:\WINDOWS\System32\SET13.tmp Version: 5.1.2600.1181 *** RebootNecessary = 1, WizardInput = 1 , DontReboot = 1 *** Flags returned by the Installer relating to the Installer state at finish. In this case, a restart was necessary (RebootNecessary = 1) but was not restarted (DontReboot = 1) because the /Z switch was specified at the beginning of the installation.

Appendix E – Standards for A/RP Entries The Sustained Engineering Cabinet has assembled the following standard on what must be documented for A/RP registry entries. All sustained engineering teams at Microsoft will use the standard entries shown in the following table:

Registry Values The following entries can be found at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninsta ll

Inside Update.exe: The Package Installer for Windows and Windows Components â&#x20AC;&#x201D; 45

Regkey

Value Type

Comments

Example Value

Comments

This package addresses the vulnerability documented in the Microsoft Security Bulletin MS03-026.

Optional

DisplayName

Security Update for Windows Server 2003 (KB123456)

Must follow standard format.

DisplayVersion

Package version

Helplink

http://support.microsoft.com?kbi d=######

NoModify

DWOR D

Eliminates the Change button in A/RP.

NoRemove

DWOR D

Does not eliminate the Remove button in A/RP.

NoRepair

DWOR D

Eliminates the Repair button in the Support Information dialog box.

ParentKeyName

operating system

Registry Key Name of the application in A/RP that the fix applies to. Also used to differentiate between Windows and non-Windows updates.

ParentDisplayName

Windows Server 2003 Updates

Used by A/RP when the parent listed in ParentKeyName is not found. This name will be used to create a virtual entry if necessary. This will be necessary for the operating system, which has no parent in A/RP.

Publisher

Microsoft Corporation

RegistryLocation

HKEY_LOCAL_MACHINE\ SOFTWARE\Microsoft\ Updates\Windows Server 2003\SP1\KB123456

Additional registry location

ReleaseType

security update

Must follow standards as defined at http://support.microsoft.c om/?lid=824684

UnInstallString

C:\spuninst.exe

Path to uninstallation program

Table 18 - Registry Values

Appendix F - Extended Return Codes Extended Return codes provide more granular information related to an error generated during the installation than standard return codes. Passing the /ER switch to the Installer enables extended return codes. Even when the /ER switch is passed for the installation, the Installer will still return the standard return codes as applicable. Extended return

Inside Update.exe: The Package Installer for Windows and Windows Components — 46

codes are available starting with the Q3 Installer (see Appendix A – Installer Versioning and Features). When the extended return codes are enabled through the /ER switch, valid return codes will be from one of two categories; either the standard Win32 errors that are documented in the Platform SDK; System Error Codes or return codes that are specific to the Installer. Many of the extended return code messages have parts of their text inserted at runtime. The Description column in Table 19 shows the messages. The text to be inserted into the message may represent a language, an operating system version, a KB article number, or a disk drive, etc. Whenever there is text to insert into the message, it will be identified by a % followed generally by a number, but, potentially, by the characters. When reading the following messages, take into consideration that there may be some words missing from text. STATUS_CHECKED_FREE_ MISMATCH

%1 Setup cannot update a checked (debug) system with a free (retail) version of %2.

61443

STATUS_NOT_ENOUGH_ SPACE

There is not enough disk space on %%s to install %1. Setup requires a minimum of %%d additional megabytes of free space or if you also want to archive the files for uninstallation.

61444

STATUS_INSUFFICIENT_ PRIVS

You do not have permission to update %1. Please contact your system administrator.

61445

STATUS_UNKNOWN_ PRODUCT_TYPE

None

61446

STATUS_SETUP_LOG_ NOT_FOUND

Setup could not find the Setup.log file in your repair directory.

61447

STATUS_CANT_FIND_INF

Setup could not find the Update.inf file needed to update your system.

61448

STATUS_UPDATE_ SUCCESSFUL

%1 has been updated. Remove any disks from the floppy disk drives and choose OK to restart your computer. If you change or add any components to your system.

61449

STATUS_UPDATE_ UNSUCCESSFUL

%1 Installation did not complete. %1

61450

STATUS_SHUTDOWN_ UNSUCCESSFUL

Setup was unable to shut down system. Please shut down your system manually.

61451

STATUS_FILE_NOT_ FOUND_IN_SETUP

Could not locate entry for HAL.DLL in SETUP.LOG to determine type of HAL to update.

61452

STATUS_INVALID_INF_FILE

The %1 %2 file is not correct. %1

61453

STATUS_USER_ CANCELLED

%1 Setup canceled. %1

STATUS_USER_ CANCELLED

STATUS_ERROR_ RUNNING_WIZARD

None

61164

STATUS_PLATFORM_ MISMATCH

This %1 is for a different hardware platform. %1

61442

Inside Update.exe: The Package Installer for Windows and Windows Components — 47

STATUS_BUILD_VERSION_ MISMATCH

Setup has detected that the build version of the system installed does not match the update you are applying to it. You can install this update only on build %d.

61473

STATUS_SP_VERSION_ GREATER

Setup has detected that the Service Pack version of the system installed is newer than the update you are applying to it. You can only install this update on a computer with no service packs installed.

STATUS_SP_ VERSION_GREATER

STATUS_NT_VERSION_ MISMATCH

None

61474

STATUS_CANT_SPAWN_ HOTFIX

%1 Setup could not start the hotfix installation program. %1

61475

STATUS_CANT_FIND_TAG

%1 Setup could not locate the %2 files. %1 Service Pack/Hotfix %2

61476

STATUS_OVERWRITE_ UNINSTALL

WARNING: You have chosen to overwrite your existing uninstall: %s If you continue

61477

STATUS_128BIT_VERSION_ DETECTED

61472

STATUS_WININET_LOAD_ FAILED

This Web-based version of service pack Setup requires Internet Explorer 3.0 or later. For instructions on how to download a version of the Service Pack that does not require a Web connection during installation, go to the %1 Service Pack Web site and select Problems Downloading the Service Pack.

61479

STATUS_CANT_INSTALL_ SP_ON_DTC

This %1 has not been qualified by your hardware vendor for installation on this copy of %2 Datacenter Server. Please contact your hardware vendor for additional information about obtaining a %3 that has been qualified for your system configuration. %1 Service Pack/Hotfix %2 OS %3

61480

STATUS_NECESSARY_ FILES_NOT_PRE

Not all files necessary to perform an integrated installation are present.

61481

STATUS_SPOOLER_NOT_ STARTED

Cannot install %1. The Print Spooler service is not started. %1

61482

STATUS_MUST_RESTART_ FIRST

The system must be restarted before installing the %1

61483

STATUS_NOT_ENOUGH_ WITH_UNINST

You do not have enough free disk space on %%s to archive the uninstall files. To install %1 with backup files for uninstall, an additional %%dMB is required.

61484

STATUS_CANT_FIND_ RSAENHS

Unable to locate RSAENHS.DLL in the update directory.

61478

Inside Update.exe: The Package Installer for Windows and Windows Components — 48

61485

STATUS_CANT_FIND_ ENCININF

Unable to locate UPDENCIN.INF in the update directory.

61486

STATUS_CANT_FIND_ ENCTSINF

Unable to locate UPDENCTS.INF in the update directory.

61487

STATUS_ENCINST_ PROCESS_FAILED

High encryption ENCINST process failed.

61488

STATUS_ENCINST_ UPGRADE_FAILED

High encryption upgrade failed.

61530

STATUS_CANT_OPEN_LOG

Error opening %1 file Svcpack.log.

61540

STATUS_INVALID_VER_ FILE

The Update.ver file is not correct.

STATUS_SP_VERSION_ GREATER_1

Setup has detected that the Service Pack version of the system installed is newer than the update you are applying to it. You can only install this update on Service Pack %d.

61547

STATUS_SP_VERSION_ GREATER_2

Setup has detected that the Service Pack version of the system installed is newer than the update you are applying to it. You can only install this update on a computer with no Service Packs installed.

61548

STATUS_FPNW_FIXUP_ FAILED

Setup failed to access or correctly modify your SETUP.LOG file.

61549

STATUS_WRONG_ PLATFORM

The version of software you are running does not match the system you are running it on.

61550

STATUS_FAILURE_ COPYING_FILES

Failed to completely copy all of the updated files.

61551

STATUS_FAILED_TO_SET_ DIR

Failed to set the directory.

61552

STATUS_SETUP_ERROR

An error in updating your system has occurred.

61553

STATUS_RUNNING_DS_ PREVIEW

None

61554

STATUS_RUNNING_HYDRA

None

STATUS_RUNNING_ STEELHEAD

None

61555

STATUS_HOTFIX_ ALREADY_INSTALLED

None

61556

61546

61557

61558

STATUS_SUCCESS_ NOREBOOT

%1 has been updated. You must reboot for these changes to take effect. If you change or add any components to your system, you will need to reapply the Hotfix.

STATUS_SP_VERSION_ LESSER

Setup has detected that the version of the Service Pack installed on your system is lower than what is necessary to apply this hotfix. At minimum, you must have Service Pack %d installed.

Inside Update.exe: The Package Installer for Windows and Windows Components — 49

61559

STATUS_NOT_RUNNING_ STEELHEAD

None

61560

STATUS_NO_UNINSTALL_ AVAILABLE

You cannot uninstall, since an uninstall for %1 has not been created.

61561

STATUS_NOT_RUNNING_ HYDRA

None

61562

STATUS_SUCCESS_ NOREBOOTNEC

%1 has been updated. If you change or add any components to your system, you will need to reapply the Hhotfix.

61563

STATUS_UNINST_ NOREBOOTNEC

%1 Hotfix successfully uninstalled. %1

STATUS_BUILD_VERSION_ MISMATCH2

Setup has detected that the build version of the system installed does not match the update you are applying to it. You can only install this update only on Build %d.

STATUS_VLK_BLOCKED

The Product Key used to install Windows is invalid. Please contact your system administrator or retailer immediately to obtain a valid Product Key. You may also contact Microsoft Corporation’s Anti-Piracy Team by emailing piracy@microsoft.com if you think you have purchased pirated Microsoft software. Please be assured that any personal information you send to the Microsoft Anti-Piracy Team will be kept in strict confidence.

STATUS_KERNEL_NONSTD

The core system file (kernel) used to start this computer is not a Microsoft Windows file. The Service Pack will not be installed. For more information, see Knowledge Base article %s at http://support.microsoft.com.

STATUS_SP_BUILD_TO_ BUILD

The build to next build install you are trying is not supported. To install the Service Pack build, you must first uninstall it.

61668

STATUS_WINDOWS_ VERSION_NEWER

The version of Windows you have installed is newer than the update you are trying to install. There is no need to install this update.

61669

STATUS_PACKAGE_NOT_ APPLICABLE

This package does not apply to the operating system you are running

61638

61643

61644

61663

Table 19 - Extended Return Codes