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 most—if not all—of 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 share—the 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 options—be they documented or undocumented—for 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.

To tell Windows Installer to perform an installation, you also need to include the /I switch before the name of the .msi package in the command line. For a program with an .msi file called packagename.msi, your \[GuiRunOnce\] command will look like this:

"msiexec /I packagename.msi /qb"

The drawback to automating Windows Installer installations is that you need to accept the application's default settings; I haven't yet discovered a way to change the installation parameters to customize target directories and individual components to install, for example. However, InstallShield applications don't suffer from such limitations.

Automating InstallShield
InstallShield's ability to perform unattended installations is exciting. InstallShield is popular because it lets you perform unattended installations of many applications.

InstallShield's unattended capability, and the ease with which you can use it, isn't a new development. The company doesn't publicize this functionality, however, except as buried in the support documents. "HOWTO: Creating a Silent Installation," an article on InstallShield Software's support site at http://support.installshield.com, reveals the secret to automating InstallShield-based application installations: the -r and -s switches.

You perform a typical installation of your InstallShield-based application to create a template for automated installations. However, starting the setup.exe command with the -r option records your responses to the installation panels. This option instructs the installation routine to write your responses to an InstallShield Silent Response File (.iss).

Even when you use the -r option, InstallShield diligently installs the application on your computer. After the installation program writes the .iss file, I recommend that you immediately remove the application from your system. InstallShield automatically puts the .iss file it writes into your Windows folder, which isn't necessarily the first place you'd look for the file. Copy the setup.iss file from your Windows folder to the same directory as the application's source code, then use the -s switch with setup.exe to reinstall the application, this time in silent mode.

Silent installations (or unattended installations that use your recorded responses) work for most InstallShield-based applications, of which many are on the market. However, InstallShield Software documents scenarios in which silent installations might not work, such as with applications that use custom installation dialog boxes that aren't programmed to obey the -r command. Fortunately, I haven't encountered any InstallShield-based installations I couldn't run in silent mode. Nevertheless, you need to test the application's silent installation before you incorporate the commands into the \[GuiRunOnce\] section of your unattended installation file.

Whether you see dialog boxes, prompts, or graphics after you start the InstallShield silent installation depends on the application's installation routine. You'll probably see increased hard disk activity while the installation proceeds. Knowing when the installation process is finished, however, can be difficult; look on the Windows Start menu or in Windows Task Manager to verify the installation.

If, when you run the silent installation, your application doesn't install properly, look for error messages in the setup.log file that the installation process creates. The silent installation process writes into this log file status codes that you can use for troubleshooting. InstallShield Software's documentation about silent setups contains information about error messages you might find.

If your application installs correctly, you can then use the -s option in the \[GuiRunOnce\] section, as the following example shows:

"setup.exe -s"

For more information about the \[GuiRunOnce\] section of unattended installation files and other options for automating your installations, see Sean Daily, "Customizing Unattended Win2K Installations," January 2001.

Putting the Pieces Together
Assume that your customized RIS-based Win2K Pro installation works well and you want to add SP1, Adobe Systems' Acrobat Reader, and Terminal Services Client installation for an OS complete with necessary applications. You want each application to install unattended. You install each application on a server and write only four lines in the \[GuiRunOnce\] section to complete your task. The section might look like this:

\[GuiRunOnce\]
"net use n: \\<server>\<share>
        password /USER:username /persistent:no"
"n:\sp1\update.exe -u -z"
"n:\adobe\setup.exe -s"
"msiexec /I n:\TSCpackagename.msi /qb"

You run RIS to install Win2K Pro, and the unattended application installations follow. You've put the pieces together, and your system is ready to use.

Tips
Automating multiple installations through the \[GuiRunOnce\] section might produce strange installation behaviors. Specifically, all applications might install simultaneously. Simultaneous installations might step on one another by, for example, trying to change the same files at the same time. If you want each application installation to wait for the previous installation to finish, try prepending the Start /wait command to each installation command in \[GuiRunOnce\]. In many circumstances, this command causes each installation to wait to begin until the previous installation has completed and results in cleaner installations.

But what if you want even more control over your unattended installations? What if you want to install only certain applications on certain systems? What if, for example, you want to install Terminal Services Client on only select computers? You can use your knowledge about customizing RIS and edit OSChooser screens to ask installing users whether they want to install Terminal Services Client. You can then put users' responses in an environment variable and build a batch file (install.bat in the example below) that installs Terminal Services Client or skips the installation according to the variable. For example, the following command, when in the \[GuiRunOnce\] section, calls a batch file and passes the user's response to the batch file:

"n:\tsc\install.bat %TSC%"

The Project Continues
Imagine sitting down at your desk and, within minutes, launching an installation that runs a completely customized installation of Win2K Pro, your virus-checking program, Office 2000, and all your other applications. With enough development time, you can build a completely automated setup and installation system that will deploy Win2K Pro with the options you want and deploy the third-party applications you need.

Imagine, too, expanding RIS functions even further. My next article about customizing RIS will teach you how to use RIS to execute any program you want, not just setups. Do you want to run a diagnostic program straight from your RIS menu? You can, with a superior RIS deployment.