• Design detection logic serviceability into your products by collaborating with the product team and servicing team. Design your detection logic model to be as simple and as exhaustive as possible.
  
  
• Design your detection logic models with your intended detection tools in mind.
  
  
• Know which installer technologies are supported by your detection logic tools. For example, Windows Installer is supported by WSUS.
  
  
• Help your partners to implement their own detection logic based on your detection logic models.
  
  
• Use detectoids to abstract common update prerequisites, such as installed products and product service pack levels. Detectoids also help reduce the number of test passes.
  
  
• Be aware of the restrictions imposed on detectoid models by Prerequisite detection logic in WSUS. Update Prerequisites detectoid models can be only two levels deep and can be combined using only logical AND and logical OR, but not logical NOT.
  
  
• Make sure your detection logic explicitly accounts for the possibility of multiple updates.
  
  
• Recognize that system registries can be changed, intentionally or otherwise, and that non-standard configurations may break the best-designed detection logic.
  
  
• Always write registry keys and values intended for use in detection logic under HKEY_LOCAL_MACHINE.
  
  
• Always store the base paths under which your application files live in the system registry under HKEY_LOCAL_MACHINE. Application file paths can be specified relative to these registry-stored base paths.
  
  
• Make sure that your detection logic can satisfy all the relevant scenarios.
  
  
• Enable detection logic that is as granular as possible, not just granular enough for your scenarios. It is easier to aggregate detection logic methods than it is to decompose them later.
  
  
• Consider a dense matrix of product editions, product languages, processor architectures, and any other dimensions across which you will deploy or service your product.
  
  
• Share detection logic across localized product or update versions when those products or updates are supported only on localized operating systems with the same locale.
  
  
• Consider previous and future product versions in your detection logic models. Remember that you will need to distinguish between the current product version and the next as soon as the next version is released.
  
  
• Make sure that your detection logic can determine the service pack level of each independently serviced or independently installed product. This will allow you to account for side-by-side scenarios.
  
  
• Consider building sticky service packs and sticky hotfixes into your product servicing scenarios.
  
  
• Try to have the same hotfix account for both n and n-1. This will enable superior detection logic scenarios.
  
  
• Remove all product and child service pack and hotfix detection logic whenever each product or service pack is uninstalled.
  
  
• Understand how your detection logic models behave in admin deployment scenarios.
  
  
• Consider how related or orthogonal products are likely to intersect with (or interfere with) your detection logic models.
  
  
• Make sure your updates can install in System context.
  
  

The following is a partial list of known issues or things to avoid doing when planning for a new product release or building a detection logic model for any new or existing product

• Don’t let detection logic serviceability be an afterthought.
  
  
• Never design a Prerequisite detectoid model that requires logic more complex than a single level of logical OR statements nested under a single level of logical AND statements.
  
  
• Never assume that the binaries in an update are mutually exclusive unless you have explicitly implemented them to be so.
  
  
• Never assume that end-user machines always have the standard configuration, or that the registry has not been changed.
  
  
• If your product installer technology already supports detection logic, do not implement an elaborate detection model except as needed.
  
  
• Don’t expect to offer n-1 hotfixes side-by-side with Service Pack n. Such scenarios are problematic.
  
  
• Do not use your product's code-name in detection logic keys. Code names are prone to accidental re-use across time. Use your product’s marketing name instead.