Automating Application Setups
I've always dreamed about a completely automated, voice-activated program for installing Windows 2000 and the applications and service packs I need, from start to finish. I've stopped dreaming and started building the program myself, using Microsoft Remote Installation Services (RIS) as the foundation. I tailored RIS to ask installing users about specific configuration items and to modify the users' Win2K Professional installation according to their responses. Although being able to customize Win2K Pro installations is extremely useful, few organizations want to install only Win2K Pro. Therefore, I took RIS a step further and added application-setup routines to RIS's list of unattended-installation chores.
Recap
In "Superior RIS: Customizing Win2K Installs," April 2001, I outline steps for specifying customized parameters to extend RIS's functionality and individualize your Win2K deployments. In short, you modify RIS's .osc files that the installing user sees in the form of OSChooser screens and tweak the template files that the installation process uses. You modify the .osc files so that the Client Installation Wizard's OSChooser screens prompt installing users for information about the configuration they want to install (e.g., IP addresses to use, components to install). This user-supplied information translates into environment variables in template files that the Win2K Pro installation process references.
Few desktop systems are complete, however, without additional applications. But RIS installs only Win2K Pro, right? Wrong. You can modify unattended installation files to automate mostif not allof your application installations.
See Gui. See GuiRun. See GuiRunOnce.
A standard Win2K or Windows NT unattended installation file has a [GuiRunOnce] section. During the installation process, this handy section automatically puts the section's entries into the computer's RunOnce registry subkey. When the computer's first user logs on, the computer executes any commands in the RunOnce registry entry, then removes the commands from the registry. Because a RIS-based Win2K Pro setup automatically performs an administrative logon after the setup has completed, anything in the [GuiRunOnce] section will also execute automatically with this unattended installation.
[GuiRunOnce] entries are great kickoffs for application installation and setup routines. The syntax for the [GuiRunOnce] section is simple. For example, assume that you want to automatically update the target system to Service Pack 1 (SP1) as part of the RIS-based installation. You can call a copy of SP1's update.exe stored on a network share by simply inserting two lines in the [GuiRunOnce] section:
[GuiRunOnce]
"net use n: \\<server>\<share>
password /USER:username
/persistent:no"
"n:\sp1\update.exe"
You need to enclose all commands in the [GuiRunOnce] section in quotation marks. At the first logon, Win2K will execute each of these commands in order. The first command connects the N drive to your network sharethe share that holds the source code for SP1 and update.exe. The second command launches update.exe to start the SP1 installation. To use the [GuiRunOnce] section to install a service pack, the system from which you run the automated installation must be running under a user account with sufficient rights to update the OS. Adding
"Autologon=Yes"
"Autologoncount=1"
to the [GuiUnattend] section of the system's template (.sif) file makes sure that the file runs under an administrative account.
Adding commands to the [GuiRunOnce] section of the ristndrd.sif unattended installation file is easy, and I haven't yet discovered a limit to the number of commands you can add to the section. You can install as many applications as you want through this process. The key is getting all the applications to install in an unattended fashion that requires no input from the user.
When you consider the mixture of applications and patches that most organizations use, automating everything seems a daunting task, but it's doable. You only need to know the optionsbe they documented or undocumentedfor performing automated installations. Most applications use an installer technology, such as the Windows Installer and InstallShield Software's programs. Conveniently, these programs can run unattended installations.
Automating Service Packs
Simply running SP1's update.exe from the [GuiRunOnce] section requires input from the user, which foils your goal for a completely automated installation. Back in the NT-development days, however, Microsoft started adding installation options to service packs. Somewhere around NT SP3, Microsoft added an unattended installation option in the form of the -u command line. The -u option causes update.exe, the service pack installation, to run unattended and display only the installation status on the user's screen.
By default, service pack installations will reboot your system after the installation has completed. If SP1 is the only application you're installing, the reboot is acceptable. However, if you intend to install additional applications after you apply the service pack, you can prevent the reboot with the -z option. If you add the -z option to the -u option in your update.exe command line in [GuiRunOnce], as follows
"n:\sp1\update.exe -u -z"
then you can install SP1 automatically on each of your RIS-deployed systems and run additional application installations. However, this process can get tricky if some of your applications expect SP1 to be in place: Until your system reboots, it doesn't recognize the SP1 installation. Keep this fact in mind when you're figuring out the best approach and sequence for your installations.
Automating Windows Installer
If you're familiar with Win2K, you've probably encountered Windows Installer technology, Microsoft's new standard for installing applications such as Office 2000 and Win2K Server Terminal Services Client. Microsoft even contradicted previous statements that Windows Installer couldn't deploy SP1 and recently released a Windows Installer package for the service pack. Windows Installer will quickly become Microsoft's installer of choice, so you need to know how to automate it.
Automating an application installation that uses Windows Installer technology is simple with the /q command-line switch. The /q switch tells Windows Installer to set the setup UI to a specified level. Table 1 lists the levels that Windows Installer supports. The /qb switch suffices in most circumstances.
The "Superior RIS" articles by Douglas Toombs are excellent. I have something to add to "Superior RIS: Automating Application Setups" (May 2001). The author writes that a drawback to Windows Installer installations is that you can't change the installation parameters. Good news! You can modify the properties for a Windows Installer (.msi) database with a Windows Installer transform (.mst) file.
<br><br>
After you create an .mst file with customized parameters, you can deploy it with the TRANSFORMS property of msiexec.exe. The Microsoft article "How to Use Property Reference Command-Line Parameters with Msiexec.exe" (http://support
.microsoft.com/support/kb/articles/
q230/7/81.asp) documents what to do. The command
<br><br>
msiexec.exe /i MyApp.msi TRANSFORMS=MyTransform.mst
<br><br>
installs the MyApp application with the customized parameters in MyTransform.mst.
Christian Schindler July 12, 2001