|
Downloads |
Using the Start command in batch files for basic setup automation is an ideal way for small organizations to speed up the software deployment process and reduce the risk of accidental omissions. As I wrote in “Use Cmd.exe's Start Command to Simplify Setup Automation,” I've used it for years. However, using the Start command to run an application makes a batch file much more complex. Is it really necessary? Does the Start command really add necessary features for installing software?
The primary reason I began using the Start command everywhere years ago was that most of the software that I installed was very finicky about the working directory it used for setups; Start let me specify that directory without needing to continually switch working directories as a distinct part of the batch file. Recently, as a test, I decided to grab a large collection of modern software packages (which I decided meant "released since 2003"), that I currently install or that are freely available, and use Start in batch files and see which ones had problems.
None of the applications I installed automatically had problems. I probably shouldn't have been surprised; the issues I did have in the past primarily centered around applications that were still generally designed for 16-bit Windows. This older generation of installers generally worked with a large collection of pre-extracted files co-located in or under the folder where the installer executable resided; if you tried running the executable from the command line with another folder as your working directory, the installer would get lost and die.
In contrast, modern installers almost always package the application into a single blob that automatically extracts to the user's temporary folder. So if an application has a monolithic setup file, you usually don't need to worry about the working directory.
This means you can dramatically simplify running installers in most cases. All you need to do is specify the path to the installer file as a command in the batch file. There's no need to make the batch file wait: When a batch file launches a graphical executable directly, it automatically pauses until the application closes. You can also put quotes around a path containing spaces without any worries; the batch file correctly interprets this as the path to a file, unlike the Start command.
On my test network, I have a server named Apps with various installers available through a share named dsp. The executable for 7-Zip 4.58 and the Windows Installer (MSI) package for ActiveSync 4.5 are both in the folder, and I can install them like this:
\\Apps\dsp\7z458.exe \\Apps\dsp\AS 45.msi
The Start command can still be useful, but after my recent testing experiences, I think the best way to start writing a batch file to chain together modern installers is to simply use the path to each application, quoting it if necessary. If you encounter an application that does need to have its working directory explicitly set, you can modify the command for that particular installer. This makes the entire process much less painful.
Automating Installer X
Many common application installers have command-line options that you can use to further automate the installation process. Documentation for these options is spotty at best and sometimes not at all available from an application developer. Fortunately, there are a couple of ways to find out what options are available for installers. One useful resource is the administrator-friendly sites on the Internet that document installer options. The most notable such site is the Open Source Software Deployment and Distribution Wiki. The Sourceforge Unattended projectand the AppDeploy database also document command-line options for a wide range of software installers.
It's also useful to remember that command-line options are generally a characteristic of the installer software used, not the application you are installing. For example, the Nullsoft Scriptable Install System (NSIS) by default creates installers that support a /S switch to force silent installation with default settings. Version 3 of misexec.exe, the Windows Installer application, has a /passive option that makes it install an MSI package automatically but shows a progress dialog box. You can completely automate the 7-Zip and ActiveSync installation with the following two commands:
\\Apps\dsp\7z458.exe /S "\\Apps\dsp\AS 45.msi" /passive
In the case of MSI package files, it's also possible to do your own research on properties to specify on the command-line by manually installing the software application once with the customizations you desire. If you log the MSI activity using the command-line logging switch, you can later look through the installer file for special properties that get passed to an installer to control its activities. To log the activities of a manual installation of the ActiveSync 4.5 package, you could use this command for an installation once:
"\\Apps\dsp\AS 45.msi" /l*v "c:\tmp\as45.log" /passive
This is not an automated installation, but will log the installation details to the file c:\tmp\as45.log. If you then inspect the log file later, you will find various global properties that were set to a specific value during the installation process on lines with the phrase PROPERTY CHANGE embedded. For example, when installing for all users on a computer, you'll usually encounter the following comment in an MSI's log file: "PROPERTY CHANGE: Adding ALLUSERS property. Its value is 1." This comment tells you that if you want to force installation for all users during an automated installation, all you need to do is add
ALLUSERS=1
to the installer's command-line. You should be aware of some tradeoffs in doing the research needed to fully automate installers. Particularly when you're working in a multi-network external support environment, you need to consider whether the work involved is worth the cost. Fully automating an installer is almost always worthwhile if the application is easy to automate or if you install it on many machines on many networks. For example, suppose you use 7-Zip as a free unzipping tool for several clients. Once you know the automation switch is /S, you can reuse that information everywhere, which could translate into dozens or hundreds of automated installs a year.
However, an obscure application used on one network where you install software only a couple of times a year is more questionable. Doing more than a brief check for options to automate installation is likely to consume more time than you'll save from total automation. Time might not be the only factor, of course. If the application installation needs to be customized, and you can perform the customization with command-line switches, it still may be worthwhile. In my experience, unique applications that need customization during installation often can be worth the extra investment in time. If a hapless new technician gets sent out to set up a new PC on a network with one of these obscure applications, it's highly likely that no one will remember to inform the technician of little tidbits, and it's a virtual certainty that someone will be making a follow-up service call within a day or two. An extra hour spent figuring out how to automate everything isn't going to cost you any more time than a follow-up service call, and prevents a possible customer relationship problem.
A Complete Installation
The StandardInstall.cmd batch file shown in Listing 1 is a complete example of how a PC might be configured completely with freely available applications. Although the application set was selected to demonstrate automatic installation in general, this is a realistic specialty configuration. It's similar to what I've done on new or rebuilt home PCs belonging to employees of small organizations, prepping their PCs for occasional work-from-home use.
Callout A shows several installations for several free applications that use various installers which support automation. All of these are installed silently.
Callout B contains MSI-based installers. The first portion of Callout B consists of various Microsoft Office document viewers (allowing home users to at least view and print documents in Office applications); in other scenarios, if the ability to create and edit such documents at home without an Office license were important, I would probably substitute Open Office (available from http://www.openoffice.org) for these first applications. The second portion of Callout B consists of mobility/communication applications: Skype, the Citrix client for remote Metaframe access, and ActiveSync 4.5 to allow Mobile PC synchronization.
Callout C is the one application in the set which didn't have any known command-line options for automation. For efficiency, it's generally a good idea to group non-automated installers together, at the beginning or the end of the installation sequence.
Finally, in Callout D I import a REG file containing organization-specific special settings. The REG file can take the place of post-installation configuration steps for many applications.
Your Only Investment is Time
Small and medium organizational support is typically expensive and labor-intensive. A large part of this problem is the fact that so many familiar enterprise management tools simply aren't usable in these smaller settings. Setting up batch-file–based installations is a useful technique for improving one portion of the manageability process.
This process still involves some effort up front, but unlike most software systems for managing setups, there's no direct cost in purchasing and installing management software, and it's easy to at least begin implementing batch setups incrementally. Best of all, you don't actually need to make a sizable investment as a consultant in order to try the technique. Simply choose a couple of clients or a branch office where you perform manual software installations, and use the techniques I've discussed here to chain together the installations. Then automate each application installation as much as you easily can using the information sources I've mentioned. It's fairly likely you will encounter some applications where you can only implement minimal setup automation, but the applications you do automate this way will pay you back significantly by saving time, standardizing setups, and increasing client satisfaction.
