Detection Logic Scenarios

 

Applies To: Windows Server Update Services

When you are designing an application, you should include serviceability as one of the requirements. You will need to support some or all of the following scenarios at some time during the life of the application. Your product installation and uninstallation procedures should allow your detection logic to provide unambiguous answers about the product, SKU, version, and patch level on any computer.

Instead of defining your detection logic model just to fit the known servicing scenarios, you should make it as specific as possible. It is easier to aggregate fine-grained items than it is to decompose coarse-grained items into something finer at a later date.

Your detection logic should determine whether your application is installed or not. You should use IsInstallable detection logic for service packs and updates, as well as IsInstalled detection logic if you deploy your product with a detection logic tool such as WSUS.

Multiple Product Versions

Most development organizations plan to release multiple versions of products. Your detection logic must be able to differentiate among the different versions. It should be able to find multiple versions that are installed side-by-side, and to detect the correct version when other detection logic is not sufficient to do so.

Multiple Product Editions

Many products release multiple editions. For example, Windows XP has Professional and Home editions, and Visual Studio 2005 has Professional and Team Suite editions. The different editions may be installed side-by-side, so that both Visual Studio 2005 Professional edition and Visual Studio 2005 Team edition may exist on a single computer. Your detection logic should be able to differentiate all uniquely serviceable product editions.

Service Packs

Your detection logic should determine the service pack level of each serviceable entity within your product. Your installation procedures should ensure that IsInstallable detection logic can distinguish updates that target different service packs or multiple service packs, and also ensure IsInstalled detection logic is valid for each service pack itself. Service packs generally must be deployed using WSUS, but might be manually installed. IsSuperseded scenarios are also possible for both service packs and updates.

System_CAPS_ICON_note.jpg Note

IsSuperseded detection logic models are difficult to implement and are not generally recommended.

A single service pack installer commonly targets multiple products. For example, customers install a Visual Studio 2005 service pack only once, no matter how many target Visual Studio 2005 editions they have on their computers.

The service pack level of each installed product edition should be determined independently. For example, if a computer has Visual Studio 2005 Professional with Service Pack 1, and Visual Studio 2005 Team Suite is installed afterwards, then the service pack level of Visual Studio 2005 Team Suite is RTM, while the level of Visual Studio 2005 Professional is SP1. Different service pack levels need to be determined in order to offer different versions of updates for the different levels. For example, different versions of a security update may target different editions of the same product.

Updates

Your detection logic should be able to determine whether a given update is installed on the computer. It should ensure IsInstalled detection logic is available for the current update as well as IsSuperseded detection logic for superseded updates. Just as with service packs, a single update installer may target multiple installed products.

Uninstall/Reinstall

Your detection logic should support the uninstallation and reinstallation of an application. The only exceptions here are products that are installed as a part of the operating system and cannot be uninstalled. For example, NET Framework is part of some operating systems, and it should never be uninstalled.

All product, service pack, and update detection logic must be removed when the product is uninstalled, and re-added when the product is reinstalled.

Globalization/Localization

Localized products are built uniquely for a given locale. Globalized products install and function correctly even on operating systems with different locales. For example, it is possible to install English Visual Studio 2005 on a German operating system. Time zone settings, date and currency formats, and other configuration settings default to values appropriate to the operating system locale. Globalized products are often also localized.

Products that are both localized and globalized often support side-by-side installation of multiple product locale versions. This makes it necessary to determine which localized versions are installed, what the service pack levels are, and which updates are installed or needed for each version.

Products that are localized but not globalized are generally supported only on operating systems with the same locale. It may be possible to share detection logic keys across localized products, since the operating system locale is sufficient to differentiate them. For example, .NET Framework 1.1 is localized but not globalized on x86 versions of Windows Server 2003. An update targeting .NET Framework 1.1 on these operating systems has multiple update installers, one per operating system locale, but each installer has the same detection logic.

Trial Editions

If your product provides trial editions, you will need to decide whether or not these editions will receive updates and service packs. If they are not supported, your detection should be able to differentiate between trial and non-trial editions.

Admin Images

Admin deployment (Active Directory deployment) allows system administrators to prepare an admin image of an application as it should be installed across their network, including pre-installed service packs and updates.

Applications, service packs, and updates that are deployed using admin deployment are typically not uninstallable and not detectable. Registry entities used to enable uninstallation are not written during admin deployment. Therefore, a detection logic model that uses those registry values may not work correctly with admin images.

User Context

Different detection logic tools run in different user contexts. For the most part, detection logic tools must run under the Administrator or System context. This means that updates may need to install in the System context.

User-interactive detection logic tools typically run in the context of an Administrator user. For example, you must be an Administrator in order to access the Microsoft Update or Windows Update Web sites.

Detection logic tools that can run without user interaction generally run in the System context. Your updates need to install in the System context as well. Automatic Updates runs in the System context when run in scheduled mode or when updates are installed on shutdown.

Code names versus marketing product names

Your detection logic model should use the marketing name rather than the code name for the product. It is always possible that another product will use the same code name, while the marketing name should remain the same over time and should not conflict with any other name.

Community Additions

ADD
Show: