This section briefly describes recommended best practices for creating and managing custom updates to help administrators avoid common problems.

Custom Update Supersedence

Custom update supersedence occurs when a custom update that is sent to a client is older than the update already on the client. In SMS 2003, when a client receives a custom software update and a newer version of the update already exists on the client, the installation process should not initiate and the update should not be installed.

To ensure that the client always has the most recent version of the update and that it is never downgraded to an older version, create Applicability rules for the custom update that makes the update only applicable to clients that have an older version of the custom update. For example, assume that MyFile.exe needs to be updated to version 2.2.0.0 with a creation date of 05/01/06 12:01:29. An Applicability rule can be created for the custom update to ensure that clients with a newer version of the file will not be updated with an older version. The following two examples show how a simple Applicability rule can be created to check for newer versions of the file, and if the result is False, the update is not installed on the client.

Example 1

Rule Type: File Version

Common Paths: PROGRAM_FILES

Path: \MyFolder\Myfile.exe

Comparison: Less Than

Version: 2.2.0.0

Example 2

Rule Type: File Creation Date

Common Paths: PROGRAM_FILES

Path: \MyFolder\Myfile.exe

Comparison: Less Than

Created Date: 2006/05/01 12:01:29

Custom Update Supersedence Information in Titles

When there are related software updates with varying versions, it is recommended that each custom software update is created with a title that meets the following conditions:

  • The custom update titles are created so they can be grouped together in the Custom Updates Publishing Tool and in the Software Updates node of the SMS 2003 Administrator console.

  • It can be easily determined by visual inspection titles which software updates refer to different (superseding) versions of the same update.

  • Optional: This practice may also prove useful when grouping by attributes other than Title.

For example, assume that the following software updates titles have been created:

  1. Firmware XYZ version 1.0

  2. Firmware XYZ version 1.1

  3. Firmware XYZ version 1.1.5

  4. Firmware 123 version 4.0

  5. Firmware 123 version 4.1

  6. Firmware 123 version 4.2

  7. Firmware 123 version 4.3

  8. Firmware Super123 version 1.7

  9. Firmware Super123 version 1.8

It is obvious from the titles that the following is true regarding the supersedence of the software updates:

  • Software updates 1, 2, and 3 are superseding versions of the Firmware XYZ update.

  • Software updates 4, 5, 6, and 7 are superseding versions of the Firmware 123 update.

  • Software updates 8 and 9 are superseding versions of the Firmware Super123 update.

Per-User MSI Issues

If you use MSI rules, the inventory tool cannot detect Windows Installer packages that were installed per-user. If you must use MSI rules, always configure additional detection rules, such as file versions or registry key values, so that the MSI can be properly detected whether or not the package was installed per-user or per-machine.

Every time you create an MSI rule, the inventory tool displays a warning. Disabling this setting is not recommended because you might inadvertently configure the inventory tool to detect an MSI without configuring the additional detection rules and might mistakenly assume that the MSI has been properly detected.

See Also