SYNOPSIS

In this guide, The Definitive Guide to Windows Software Deployment, industry expert Chris Long discusses essential concepts of Windows software deployment, including deployment methodology, network infrastructure considerations, and best-of-breed installation tools.

CHAPTER PREVIEWS

Chapter 1: The Foundation of Software Deployment

Spouses of auto mechanics are the first to admit they have the least maintained cars. Often this isn't an idle complaint—it’s true. What they mean more than anything else is that their car isn’t maintained as well as it should be considering there's an auto mechanic in the family.

I would imagine the same holds true for plumbers, carpenters, lawn maintenance professionals, and software developers. Hah! Caught you off guard didn't I? I admit the last one may be localized to only my household, but it's an example I can share with you. Often, when someone is good at something and they do it for a living, they don't have the time to spare or the inclination to apply that talent within their own lives. Call it human nature. After banging on a computer all day, I'm not eager to jump on the computer when I'm at home.

Last year my wife and I purchased a nice computer. Given all the computer books and computer training classes available, I've been impressed with the computer abilities of an eight-year old and his six-year old brother who have no access to these resources.

With minimal guidance, they've managed to enter my email address into every conceivable online contest, download cartoon screensavers, install desktop themes (usually involving spaceships and aliens), browse the Internet, play online games, and even let me know how much gaming systems are going for on eBay.

The obvious result of all of this tweaking is that user interface design has certainly improved over the past 10 years. These boys also managed to cripple the printer (repeated paper jams) and generate inconsistent hardware errors (the recordable CD drive is no longer reliable). Not to mention all the disk space these activities consume. Amidst the grumbling, I'm trying desperately to rationalize why my own home computer is in such a mess.

Typically, none of these problems have been big enough to disrupt my weekend. After all, I do most of my work in the office. Only when the family computer comes grinding to a near halt does maintaining the home computer escalate to the “A1” (with a bullet) priority on my To Do list. The squeaky wheel gets the attention and all of that.

After a few months of listening to these complaints, I am eager to reduce the impact on my weekend. I’ve since created separate logon accounts for the boys, the printer became off limits for all activities except printing, downloading software became an “On Approval” only action, and the recordable CD drive was replaced with a newer model. Sure I haven’t solved all of all the problems, but the ones I have fixed certainly reduced my workload and I now have more time to enjoy the new DVD player.

Chapter 2: Conformance Evaluation

Whew! Conformance evaluation are big words for such a simple concept: How willing are you to install or upgrade software? For you and I as individual software users, the answer to this question revolves around cost, need, and expectations. Companies releasing software internally must ask the same kind of questions on a much larger stage.

If we're interested in a software package and its minimum requirements exceed those of our 3- year old home computer, how likely are we to upgrade our computer to use the software package? Odds are not good if the need for the software package is half-hearted. We're more likely to upgrade a personal computer to move to the latest version of Microsoft Office than to Wing Commander. But it’s a function of disposable income and other non-related priorities.

If you spend a few minutes thinking about the software you’ve purchased, you’ll probably realize that you invested more than the simple cost of purchase. You’ve spent the time installing the software onto your computer. This process may have involved clearing up some disk space and removing some older software. The install program may have involved tinkering with your system to get the install program to work—installing an updated Internet browser for example. More than likely, you also spent some time learning the software—either through the manuals or online Help. We can safely say that you’ve developed a type of relationship with your new software.

Chapter 3: Repackaging

In the first two chapters, we discussed the general background of software deployment, how to justify getting software, and methods of distributing the software. If you’re reading this book with the thought that it will show you the one single method of getting your application packaged and delivered, this chapter will start to dispel those thoughts rather quickly. Very simply put, the “best” method of deployment depends on several factors:

• OS
• Size of the deployment
• Required timelines
• Your preference, skill level, and comfort zone with a deployment method
• The needs of the application to be deployed
• Security considerations

This chapter is going to focus on packaging (or repackaging) an application for deployment. In addition, I’ll give you a list of best practices that includes testing your package and lightly touch on the deployment mechanisms you can use. Chapter 4 will cover the deployment methods in greater detail. For this chapter, the term repackaging refers to the process of getting a software application prepared for deploying to your environment. How to handle MSI, Wise Installer, and InstallShield-type applications will be explained in a later chapter.

Chapter 4: Methods for Deploying Software

You now have a package ready to deploy. Your application is tested and installs on all your test machines; its functionality works just as you planned and there are no incompatibility problems with the multitude of applications on your test machines. The job is done, right? Oh, wait. You have to get the packaged application deployed somehow.

Like everything else about computers, there is a multitude of ways to ensure your workstations get the application. The choice is yours. This chapter will discuss various methods of deployment, the pros and cons of each method, and provide some practical tips.

Choosing the method of deployment is just as important as the actual deployment. Although you might usually send out all your applications using a commercial deployment-software application such as New Boundary Technologies’ Prism Deploy or Microsoft’s SMS, circumstances for a particular deployment might require using an entirely different method. For example, if you need to load a small application on only two workstations that are right next to you, manually deploying the application is easier than any other method.

Having a regular method established lets you package your applications to a known set of policies and standards. Understanding the needs of the deployment can assist you in making the proper choice of methods. Do you follow the company standard or is the manual method the way to go this time? The answer has to be evaluated for each application deployment.

Chapter 5: Deploying to Remote Users

The thought of getting a deployment out to a remote user can bring even a strong network administrator to the edge of a panic attack—especially for that first company-wide deployment when the project has a white hot spotlight of attention on it. However, this task does not need to be a difficult endeavor. Just like the slogan says No Fear—you’ve already got the information and as an administrator, you’ve got the attitude, all you need is the experience. For a remote administration, the principles that we’ve talked about in previous chapters still apply:

• A package is delivered to the target machine
• The install process is started

Physical distance is not a large issue. A target machine can be sitting next to you or half a world away, and the deployment method is basically the same. That is, unless you try to Sneakernet the install. I’m sure the company travel department and your finance administrator will have something to say about all the travel.

Chapter 6: Deploying in the Enterprise

I’ve talked so far about creating a package, how to get the package out, and how to handle deployment to remote users and machines. The focus so far has been from the application point of view. It’s all been about the mechanics of the process and how to make the deployment do what you want. I’ve talked about testing methodologies and about some of the different technologies for delivery and packaging. Now along comes this chapter about deploying in the enterprise, and you’re probably wondering “Hasn’t this topic been discussed?” Well, sort of. The discussion up to this point has been centered on the technical aspects of getting the first package out. The goal of the early stages of the book was to provide enough data to get your packages up and out that first time. Although there have been casual mentions of doing deployments in repetitive forms or multiple deployments, the main theme has been on just one package at a time. Software deployment is not a one time function nor does it entail only the technical details. Windows software deployment is an entire process that must be repeatable in both the technical and procedural arenas, and the process must show a reduction in effort (and basic expense) as the numbers of deployments continue.

In this chapter, I’m going to delve into the area that all technologists dream about: Process, procedures, and documentation. To make it sound a little more technical, I’ll refer to this topic as PP&D.

PP&D is just as critical to software deployments as the actual creation of the package. Remember that the deployment system you use within your enterprise must be repeatable by others, not just by you. The steps to create a package, the standards to use, the SLAs, and the methods to use must all be known to the technical staff responsible for the work. Management must be aware of the process as well as informed about the work you’ve already done. Because you most likely enjoy taking a day off here and there and dream of an actual vacation that is not interrupted by work calls, documenting everything to the level that others can follow is critical. It’s all about making your life just a little easier.

Before I get too deep into the chapter, let’s define a few terms that I’ll use frequently:

Enterprise—This term has come back into vogue in recent years. For this chapter, it will be interchangeable with business unit, company, division, department section, or any other term you like that describes a group focused on making the business run. It’s a good generic term, as it can cover the large company as well as the mom-and-pop shop.

Shops—The IT department. It can be one person that does everything or several thousand specialists. Adjust the term to fit your situation.

Chapter 7: Installation Tool Alternatives

Being the expert software deployment technician that you obviously are, you keep abreast of all the new technology. You have a list of favorite Web sites to review, you keep up on Microsoft changes, and you know your workstations. Making new changes are not that big of a deal. So if a new process comes along that is not compatible with your existing environment, you have a bag of tricks available that will help you solve the problem, right?

No matter what type of deployment method you have in your environment, there will come a time when you will need to adjust or modify the standards. To that end, you need to stay up on the various methods and tools available to you. The biggest tools out in the Windows world right now are Windows Installer and the resource kit utilities.