This post is a continuation of a series related to product configuration management (PCM) patterns. Here, I discuss the implementation, features and drawbacks of the install-time PCM pattern. With this PCM pattern, a single product release can be used to install multiple product configurations.
The install-time PCM pattern is traditionally implemented through the use of command line parameters specified when running the product installer, or through UI selections in the setup wizard. For the command line, available options can either be specified individually on the command line, or the name of a file containing the option settings can be specified. In order for these command line options to have their desired effect, the product installer must be crafted to look for and handle the options. Here are some examples of the types of changes that the product install might make for a specific option:
- Install different versions of a given file
- Change the value of a registry entry
- Modify the product configuration file
- Install an alternate product configuration file
- Change the location where the product is installed
- Change identifying characteristics of the product (name, version, brand, etc.)
- Create a desktop icon
- Establish file extension associations
The install-time PCM pattern makes the control of configuration settings available to the one installing the product, which is often the end-user. As such, there is very little protection available to prevent the user from changing these settings at will. For cases where the software will be pre-installed on OEM systems, the configuration control will be with the OEM, not the end-user. While this improves configuration security somewhat, many OEM systems also ship with a CD containing the installers for the pre-installed software in case the user needs to re-install any of the software. The only other security protection available for command line installer options is lack of public documentation. If the options are undocumented, and not easily discoverable, it is less likely that an end-user will be able to take advantage of them. Overall, installer options are considered insecure, so they are generally suitable for controlling those product configuration options that have low intrinsic value.
Another implementation form of the install-time PCM pattern is frequently employed by products being deployed through system OEM vendors, though it can be used in any scenario where the software product has some form of hardware dependency. In this implementation scheme, the installer performs a hardware detection operation, and then configures its installation activities automatically based on the hardware that was found. For example, a software product to be used for OEM pre-installs may have its installer designed to detect that it is running on a specific OEM‘s hardware before allowing the installation to proceed. This can be used to help prevent the product installer from being pirated for use on other computers.
Another case where this implementation form might be used is when certain product features are dependent upon the existence of certain hardware. In such a case, the installer might only install certain feature capabilities if a particular hardware device is present. The OEM may pay the ISV different amounts for installation on systems with and without the target hardware device. While two different product installers could be used to achieve the same result, it would then place the burden on the OEM to decide when and how to install which version of the product. Having the installer make the choice automatically simplifies the process and reduces the likelihood of mistakes. One caveat to this approach is that it potentially allows the end-user to receive the hardware-dependent feature without paying for it if they purchase the hardware device at a later point, and then re-install the software from the system recovery CD. If this poses a significant risk to revenue, then any of the following additional precautions can be taken:
- Don’t provide the install-time PCM installer on the system recovery CD. Use a different, non-configurable version of the installer that matches the shipped hardware configuration.
- Make the hardware check specific to the exact brand and model of the hardware used by the OEM. This will prevent other brands/models of the hardware from activating the feature.
- Have the installer create a “signature” on the system that will be left behind if the product is uninstalled. This signature should contain information about the original configuration of the product. Then on re-install, the installer can look for this signature and configure itself per the original configuration.
The install-time PCM pattern differs from the code-time, build-time and release-time PCM patterns in that it passes the configuration work onto the customer. Once the ISV has developed the configuration capabilities, there is no further work aside from periodic maintenance updates to the product or installer code base. In turn, the customer receives both the responsibility and the power to control the available product configuration options. It’s a win-win situation in scenarios where customer-controlled configuration options are viable.
Most product installers already have some configuration options presented in the setup wizard, however not all provide equivalent command line functionality. It is very useful to be able to specify all configuration options on the command line, along with suppressing the setup wizard UI, in order to support fully automated installations. This is a key requirement for volume license partners (VLPs), since they need to perform mass deployments of applications to large numbers of computers within an enterprise. If the installation cannot be completely automated, they generally will not even consider the product for mass deployment.
As far as the ISV is concerned, all of the work involved with supporting the install-time PCM pattern is in the preparation effort. In this case, the preparation work is focused mainly on the installer, with functionality added to support various UI and command line based options. Each option will typically be handled as a unique case, and the complexity involved with handling each option may vary dramatically. Some of the options may be handled through native capabilities of the installer engines, such as through the use of optional product features with Windows Installer; others may require custom code development.
As with the release-time PCM pattern, it is possible to substantially optimize the testing process for products that use the install-time PCM pattern. QA can rely on a single code base and set of binaries as the foundation for testing. Individual configuration options can easily be tested with simple installer UI selection or command line options. This provides QA the ability to instantly generate any desired configuration for testing purposes.
Since the actual configuration changes have been pushed out beyond release to the customer, there is no need for configuration testing. Only the proper functioning of individual configuration options needs to be verified. This effectively eliminates the test/fix cycle for configuration changes.
Following is a summary of the approximate effort involved in handling multiple product configurations using the install-time PCM pattern:
|Worker Time||Machine Time||Work Description|
|80 hours||Insert conditional install-time checks|
|80 hours||Develop UI configuration functionality|
|80 hours||Develop command line configuration functionality|
|80 hours||Test preparation for configuration options|
|320 hours||0 hours||Sub-total – preparation effort|
|320 hours||0 hours||Total effort|
All of the effort involved with managing configurations in the install-time PCM pattern is in the preparation phase. The preparation effort is a relatively large, but one-time, cost which is offset by an elimination of configuration effort. The install-time PCM pattern is an ideal approach when the universe of desired configuration combinations is extremely large or unpredictable in advance. By pushing the configuration responsibility to the customer, any conceivable configuration combination can be produced without any additional effort on the part of the ISV. Since the customer has full control over the configuration choices, the install-time PCM pattern is not well suited to controlling options that require any level of security protection.