Deploying Applications

One of the primary advantages of Terminal Server is that you can significantly decrease your software deployment timeframe since you need to install applications only once on a server instead of dozens of times on client devices. However, as your Terminal Server environment grows, it quickly becomes apparent that you need a solution for your servers. With a large environment you must install applications onto dozens of servers. Although installing applications on dozens of servers is less work then installing them on hundreds of workstations, it is still a significant task that can be automated.

Fortunately, Terminal Servers are the perfect candidates for using automated software distribution tools to install and update your applications on multiple servers. Before examining the details and design components of these tools, let's look at how automated software distribution works in general.

An Overview of Automated Software Distribution

Automated software distribution is conceptually the same anywhere it is used, regardless of platform or tools. ZENWorks, SMS, Tivoli, Unicenter, and IntelliMirror all work in exactly the same way.

Fundamentally, no software distribution tool has the ability to "push" software applications to target computers. These distribution tools simply evaluate a set of conditions on a target computer. If these conditions indicate that software should be deployed, the distribution tool causes the target computer to execute a command that launches the automatic software installation.

Software distribution environments are made up of three components. These components apply to all software distribution programs listed previously.

• Software Package This is a collection of files (the software application's source installation files) that are to be installed on the target computer.

• Installation Command This is the command used to launch the installation of the software.

• Software Distribution Agent This term describes the program that decides whether the software should be deployed. If so, it executes the installation command on the target computer.

Imagine that you want to install Notepad onto some computers. You create a software package that contains your source files—notepad.exe in this case. Then, you specify the command to be used to install the software. In this case, that command is not notepad.exe. To understand this, let's look at what happens on the target computer.

When the time came for the package to be installed, your software distribution agent would connect to the network location where your package was stored and run the installation command line. In this case, if you specified the installation executable as notepad.exe, when the software installation was scheduled to begin, the Notepad application would be launched (because you specified notepad.exe). The user would be confused, wondering why Notepad opened all by itself. He would close it and continue working. In this case the software distribution program did exactly what you wanted it to—it connected to the network share and ran notepad.exe. In fact, the software distribution program would report that there was a successful installation, because notepad.exe ran and exited successfully. In this scenario, the software distribution utility did its job. However, the administrator that configured it did not.

In order to successfully deploy Notepad with a software distribution utility, you must create an installation procedure. In this simple case, that is most easily done with a batch file. Let's create a batch file called install.bat made up of the following line:

 copy \\networkserver\share\notepad.exe %system- root%\system32\ 

As you can see, this "installation program" will copy notepad from the network share to the target computer's local hard drive. It's important to note here that the %systemroot% variable is used to specify the location on the target computer. That way, your program will work no matter how the target computer's drives are configured.

Once this installation program is complete, update your software package. Your new package will contain two source files—notepad.exe and install.bat. You must also update your installation procedure. Instead of running notepad.exe, your package is now launched by running install.bat.

Now, when the software distribution agent needs to install your package, it will work whether or not a user is logged on and will not interrupt them while he's working. As you have seen, this improvement step had nothing to do with a bug in the software distribution utility. It had everything to do with the skill of the people creating the package.

Let's take a look at another example. Imagine that you want to deploy Microsoft Office 2003 to 100 computers. Ordinarily, you would go to each computer and execute setup.exe. That setup program prompts you for several options, configurations, and information. When it has all the information it needs, the actual installation begins.

When using automated software distribution utilities, this process is no different. If the software distribution utility decides that a computer needs to have an application installed, then the software distribution utility instructs the computer to run the application's installation program.

If you simply copy the contents of the Microsoft Office 2003 CD to a network share and then instruct the target computers to run the command setup.exe to install Office 2003, each target computer would run the full GUI version of setup.exe. This GUI version requires user input along the way to enter the options, installation path, and CD key. Imagine what would happen in the real world if the executable for an Office 2003 distribution was setup.exe:

• Some computers would have no one logged on so the software distribution would fail, because Office 2003's setup.exe requires a user to be logged onto the computer in interactive mode.

• Other users would see the box pop up that said "Microsoft Office 2003 Setup." They would think to themselves, "Why is this happening? I didn't run this!" Then, they would immediately cancel the installation.

• Still other users would continue through the installation. In these cases, each user would probably choose different options, meaning that the Office 2003 installation is different on each computer.

If you want to deploy Microsoft Office 2003 to a large group of servers, you must create a software installation package for it.

In your package, specify the location of the source files and the command line needed to kick off the installation. Instead of specifying setup.exe to launch the installation, it is possible to create a "silent" installation of Microsoft Office 2003. Silent installation involves creating a configuration file that specifies all of the options that you want, and then running setup.exe with special commandline parameters that instruct it to read settings from the custom configuration file. This is done with the same methods used to specify "silent" installs of the RDP client software in Chapter 10.

To summarize, when using any software distribution environment you must first create the "silent" installation routine for your application before you can distribute it to any target computers (or target Terminal Servers in this case).

Automated Software Distribution Considerations

If you're thinking that using automated software distribution is too much work, consider this: Would you rather spend some time up front building packages for and testing your applications, or would you rather install your application over and over and over until it is on all your servers?

The decision of whether to use automated software distribution can be a difficult one to make. Fundamentally, everyone wants to use automated software distribution because on the surface, it simplifies the management of software and software updates. However, in the real world, it's not always that easy. To help you decide whether or not to use automated software distribution for your applications, ask yourself the following questions:

• How difficult is it to package your applications?

• How often are your applications updated?

• How long do these updates take to deploy?

How difficult is it to package your applications?

For each application, consider whether it comes to you ready to go in Windows Installer package or whether you need to manually create the application package. If you have an MSI file, then your application package is ready to go without much effort on your part. But if you must manually create an application package, you must do some testing to figure out how long it will take you to create that package.

Too often people spend four days trying to create a software installation package that they could have manually deployed to their servers in two days.

How often are your applications updated?

If you have an application that will need to be updated frequently, it may be worth your time to create an application package. Once you figure out the tricks you should be able to package new versions of the application quickly. On the other hand, if your application is only updated every 18 months, it might not be worth it.

How long do these updates take to deploy?

If the application updates only take ten minutes each and you have ten servers, then you can manually deploy all of your updates to all of the servers in less than two hours. Most likely, it will take longer than that to create an application package. But if you have 100 servers, it could take two full days to deploy all of the updates. If you can make an application package in one afternoon, then it's worth it.

Factors that May Lead to Automated Software Deployment

• Many Terminal Servers.

• Frequent application updates.

• Applications are easy to package, such as MSI applications.

• Good test lab environment.

Factors that May Prevent Automated Software Deployment

• Small number of Terminal Servers.

• Infrequent application updates.

• Complex applications that require significant effort to package.

• No test lab environment.