Many organizations are too small to cost-effectively deploy software by using tools such as Microsoft Systems Management Server (SMS). The person responsible for software installation—typically an external IT consultant or an employee with part-time support duties—falls back on manually installing each application on system rebuilds or new installations, which can be a slow and potentially error-prone process. However, by using a simple batch file and cmd.exe’s Start command, it’s possible to speed up the deployment process and reduce the risk of accidental omissions. Let’s look at when and why you’d want to use this method, then walk through how to deal with some of the problems you might encounter.

Why Start?
Cmd.exe’s Start command is a simple tool with features that make it ideal for basic setup automation. In general, any command you can run on a Windows system can be run from a batch file. You can add command-line options as necessary, and the batch file can wait for each command to finish before running the next command.

Why use Start? It’s easy to forget specific applications that you need to install for a system. For example, you might forget to install a small application even though it’s important to a client. At small sites that you rarely visit, you might get distracted by troubleshooting tasks in the middle of configuring a system and forget where you are in a chain of application installations. By wrapping all of the setup launchers into a batch file, there’s no danger of forgetting an application. If you don’t need to install a particular application in the set, you can always cancel its installation and go on to the next one.

It’s also easy to lose specific application sources that are on a network. Again, a batch file will have all of these locations in it, eliminating the headache of searching for those items.

Finally, even when you do know where everything is, you can waste a significant amount of time navigating to files and waiting for applications to start up and shut down. The Start command will shave off some of this start-up time. And when applications have installers that support command-line automation, installation can even proceed while you’re doing other work elsewhere. Let’s look at the proper way to run setups now.

Use the Wait Option
By default, the Start command always spawns an application in a new process and continues on its way. Obviously, it’s not a good idea to start up 17 different installers simultaneously; the resource demand would overload almost any PC. In any case, well-behaved Windows Installer (.msi)–based installation programs will refuse to run if another .msi-based installation is already running, making it easier for Windows to untangle applications. To handle this situation, simply include the /wait option with the Start command. You can abbreviate the /wait option to /w. To run the installer located at z:\dsp xp\WindowsXP-KB926139-x86-ENU.exe, you would start it like this:

start /w z:\dsp\xp\WindowsXP-KB926139
  -x86-ENU.exe

start z:\dsp\legacy\oldapp.exe
echo wait for OldApp to finish
  installing && pause

Although it theoretically doesn’t help in this situation to use the /w option, it’s a good habit to use in creating scripts for setup chaining.

Set the Working Directory
On some occasions, you might need to control the working directory of the launched application. For example, some installers might use user-specific license files or need a local directory for extraction and not automatically get the user’s temp folder. You can force the working directory by using the /d option. If the application needs files from the OldAppData folder in the user’s profile, you can run it like this:

start /w /d %userprofile%\OldAppData
  z:\dsp\legacy\oldapp.exe

Handling Paths with Spaces
The single most significant problem people encounter when using the Start command is its behavior with file paths containing spaces. If you check the command-line options for the Start command, you’ll see why. Omitting some of the options for brevity, the Help display looks like this:

START ["title"] ... [command/program]

When the Start command sees a quoted string in its command line, Start assumes that you want to create a new window with the quoted string as the title. This means that if you try to run the installer z:\dsp\misc\Acme Shipping.msi by using the command

start /w "z:\dsp\misc\Acme Shipping.exe"

you won’t see the Acme Shipping.exe installer start. Instead, an empty command-prompt window will pop up with the title z:\dsp misc\Acme Shipping.exe.

Continue to page 2

You could use the /d option if the directory path had spaces in it, but here our problem is the executable itself. Start offers no way to specify that the quoted string is really the path.

There are two solutions to this problem. One is to provide a quoted string first. For GUI installers, the title won’t matter, but you must provide a quoted title string initially so that Windows will interpret the quoted command path correctly. We can modify the nonfunctional batch file line by adding a quoted string to make it work:

start "" /w "z:\dsp\misc\Acme
  Shipping.exe"

Another alternative is to rename the setup file. This is useful anyway for rarely visited networks, because you can add versioning information to the title while you’re at it, as well as a string to identify the executable as a setup file. If you pick a name such as AcmeShippingSetupv5.1.exe, you get an additional bonus: Windows Server 2008 and Windows Vista will automatically prompt for privilege elevation when invoking an application that has the word “setup,” “install,” or “update” in its name, ensuring that the application installs properly. As a result, if you later do click-and-run installations you’ll get helpful prompting.

Add Command-Line Options
When you use Start to run an application, Start passes everything that follows the application name to the application as arguments, so adding command-line options is straightforward. Suppose you’re installing Windows Defender from the file WindowsDefender. msi. Windows Installer packages universally support certain command-line options. For example, /log followed by a colon and the name of a log file records installation details to the named log. So, if you wanted to log details to c:\install.log and weren’t using the Start command, you could do so by executing the command

z:\dsp\core\WindowsDefender.msi
  /log:c:\install.log

You use precisely the same command if you’re executing it with the Start command. If you want to start the installation and wait, you just use this:

start /w z:\dsp\core\Windows
  Defender.msi /log:c:\install.log

The only special case is if an argument needs quotes. You can use the same technique I demonstrated in the section about handling paths with spaces and include an initial empty quoted string. Therefore, if you were logging installation data to C: Install Records.log, you would use a Start command such as

start "" /w z:\dsp\core  WindowsDefender.msi /log:"C:\Install
  Records.log"

Simple Automation in Minutes
What makes Start commands especially nice is that when you’re ready to perform a sequence of installations, you simply put all the Start commands into a text file—each command on its own line in the order you want to run it, then save the file with a .bat or .cmd extension. You can save the batch file to a network folder located above all the installation media you use, to make it easy to locate each time you need to add or remove a standard installation item.

Given a large infrastructure and budget, a tool such as SMS is still a winner, not least because it does other things in addition to automating software setup. But when you don’t have that tool, using a batch file with the Start command returns a lot of value for the investment of only a little time.