No, this blog is not dead. Illness and vacation had it on a hiatus for a bit, but now I'm back. The next topic I want to discuss is response file variables, which I think is a very powerful addition to an administrator's arsenal for deploying products in Installation Manager. I'll cover a bit of background on them today, and next week we'll dive some more into how to use them and where we see the value in this concept.
Originally Installation Manager had two methods for using it in a headless fashion: silent and command line. Silent install used a response file to specify the properties to use for the installation, such as install location or features. This was created either by recording an install, or hand editing a file such as a sample response file. The record method fit the GUI oriented model Installation Manager was originally designed around, and was a straightforward way of creating a response file.
The drawback to the response file is that it was a static thing. Once the values are set, that response file couldn't be modified at run time. This caused clients with varied environments to have to maintain a library of response files, and have a method for invoking the correct one in the correct instance. If something about the offering changed, such as new features, this would require a new response file to be added to the library.
The command line method for driving an install was intended to provide a more flexible method for driving installs. It allows you to specify all of the properties for the install as a single command, and execute that. This allows for using a script to drive the deployment, which can then modify the values used easily.
The drawback here is that you need to know the internal names for the properties you want to set, and you need to know if there are values that do not have defaults so that you can provide those. While it has greater flexibility, it's also more difficult to use.
Bridging the gap
The response file variable concept is in between those two methods in terms of flexibility and ease of use. Administrators wanted a standard template they could use to minimize what they needed to maintain in their environment, but with the flexibility to adapt to different environments or use cases. Response files, which were introduced in Installation Manager 1.7, address this desire.
The basic concept is that an administrator records a response file for a given package. After recording the response file, the administrator adds in the variables they want to use, and uses them to handle the values for the desired properties in the response file. When calling the response file from their deployment script, they can modify the variables on the fly to handle different environments or use cases.
So how do you create them and use them?
That's a great question! We'll get to that on Monday. :) For now, here's the Installation Manager Info Center topic on response file variables. On Monday, we'll dive in to how do you create the variables, how do you use them in your response file, and how do you provide the values for the variables on the command line.