/build/static/layout/Breadcrumb_cap_w.png

Packaging Software Making Software Install Silently

Packaging software seems to be IT's biggest elephant in the room when it comes to desktop management. Allow me to explain'

I visit constantly with IT pros who yearn for this magic nirvana. In it their desktop management activities are fully automated, alleviating the need to roam the hallways installing software, updating computers, and fixing problems. It's a beautiful dream, but what kills me is the fact that technologies exist right now that make it a reality. Those technologies are very mature, and absolutely affordable.

Heck, you've already got a very small part of those technologies built right into your Active Directory. It is by no means the smartest solution in the bunch, nor does it have the best reporting (as it has'well'no reporting to speak of). But with Group Policy Software Installation, you can absolutely start automating software deployment and update right now'if you but had the packages.

Having those packages represents our room's elephant. Packaging your applications isn't necessarily a difficult activity. It, however, can be time-consuming. Multiply that time by your number of applications under management, and you can see why far too many IT shops never get much past the dream state.

You've read this far, so I must assume you're ready to stop dreaming and start acting. In this article I'll get you started with the art of packaging software. Be aware, though, that what you're about to learn isn't necessarily written down anywhere. There's no 'click here, then click here.'

That's because every piece of software is just a little bit different; so the steps you'll use will be a little bit different for each. I'll show you the general tactics the pros use, and then point you to a great clearinghouse of tips and tricks where you can find more details.

Once you've finished packaging, automating deployment is easy. In fact, Microsoft's knowledgebase article 816102 (whose title starts How to use Group Policy to remotely install software') gives you all the deployment steps for Group Policy Software Installation in a few short pages. Or, if you need something more powerful (which you eventually will), seek out a desktop management solution.

Now, for the hard stuff.

Silent Running: Software Installation's Magnetohydrodynamic Drive

Recognize first that the packaging process has two very specific goals. Its primary goal is to 'repackage' the installation so that it executes silently. A package that runs silently does so without prompting the user during its execution. With no prompts, the software installation can go from start to finish with a single command.

That said, virtually every piece of software requires some amount of setup parameters that are determined during the installation. At a minimum, these setup parameters are often just the location where the software will be installed. Other software might ask additional questions, such as whether icons are created on the desktop and/or Start Menu. More challenging software installations might require database or server connections.

Providing an installation with the customization answers it needs is the second goal of software packaging, which aligns with its first goal: By giving the installation the answers it needs, plus a tiny bit more, the installation is now enabled to complete its job without asking questions. That's running silently.

Silencing EXEs

Getting there requires one of three common approaches. Two of the approaches leverage command-line switches that are built directly into the installer. In the case of EXE-based installations, those switches are often determined by the person who wrote the software package. Some common switches are known, but others can be as individual as the software itself.

For example, your EXE-based software installation might use any of the following switch structures to kick off the installation in silent mode:

setup.exe /s
setup.exe /s /v/qb
setup.exe /q:a /r:n
setup.exe /silent
setup.exe /quiet


Figure 1

This list is by no means conclusive, although more-modern software is starting to agree on which switches perform which actions. Two switches you'll want to keep handy are /a and /?.

The /a command can sometimes be used to kick off what is called an administrative installation. That administrative installation exposes the wizard for customizing the installation, but doesn't actually install the software. Instead, what results is a new installer that's been both customized and silenced for you. Very convenient.

The /? command (along with the variant /help among others) should always be your fallback. Running an EXE-based setup with this switch might give you clues, but it also might not. Again, it all depends on who did the packaging.

Silencing MSIs

If switches with EXEs are the Wild West, then the switch structure with MSIs is like the train schedule. They always run as expected. The acronym MSI stands for Microsoft Installer, and specifically the Windows Installer Service which should be running on your Windows computer right now.


Figure 2

MSI makes silent installations much easier because all MSIs share the same basic switch structure for silencing their installation. That switch structure might look like this:

msiexec.exe /qb- /l* {logfile.txt} /i {setup.msi} {NAME=Value}

Variants of this structure exist, but the general idea is that the /qb- switch tells the installation to use a basic user installation with no modal dialog boxes. The /l* switch says to output any details to the log at {logfile.txt}. Finally, the /i switch says to install whatever exists for {setup.msi}.

This is just the basic structure. Just like EXE installations, some MSI-installed applications have their own customizations they require at installation. The final switch {NAME=Value} provides a location to set those values. Because those values are set as you execute msiexec.exe, you've accomplished both goals of silencing your installation.

While the basic structure with MSIs rarely changes, it is those names and values for that final switch that will be different for each installation. Some examples of what these values might look like are:

LICENSEKEY=3954325693
DESKTOPICON=no
INSTALLPATH=c:\progra~1\*
TRANSFORMS={transform.mst}

This is very important: These names and values won't work unless your specific piece of software is coded to recognize them. If you attempt to use LICENSEKEY, but your app doesn't recognize the value, it'll be ignored. So, while MSIs are a bit easier to silence than are EXEs, there's still some sleuthing to be done.

That final name/value pair merits additional attention. Some installations can be customized through the use of a transform, or .MST, file. Microsoft Office is one notable application that uses MSTs to customize an installation. Microsoft Office's transforms are created through their Office Customization Toolkit. Other software will have other means of generating a transform.

In cases where transforms are recognize, you'll use TRANSFORMS={transform.mst} as the switch structure. The contents of {transform.mst} must be the full UNC path to the transform located on a file share somewhere on the network.

For both MSIs and EXEs, a clearinghouse website of useful packaging information can be found at http://www.appdeploy.com. This is a user-driven website that includes hundreds, if not thousands, of different software packages along with advice about what switches work (and don't work). It's a good start when your sleuthing has come up empty.

When Nothing Else Works, Diff!

You can discover how to silence a sizeable percentage of all software with just these few tricks. But some software just won't install silently. With others, you might not be able to get the customization you need out of the switches that are exposed. In these situations, you're best to abandon the sleuthing and start the 'diff-ing'.

Sometimes called a differential-based installation, the diff process requires an extra piece of assistive software in creating a brand new installation package. That extra software is like an MSI studio of sorts.

It starts by performing three key steps.

Step 1: Start with a reference computer. That computer has a fresh installation of the same OS and service pack level (matching installed updates also helps) as those you'll eventually deploy software to. Snapshot the files and registry of this computer.

Step 2: You, the packager, then manually install and configure the software you're looking to package. Configure anything you want also configured during the installation. You'll do this installation using the normal method. No silencing needed here.

Step 3: Snapshot the computer a second time. Then, identify what's different between the two snapshots. Gather those differences into a new MSI.

This process is sometimes called a differential-based installation, because of that double snapshot process. Logically, if you take a picture of a computer both before and after the installation, what's different should be exactly (and only) what that installation changed.

What's better is that the new MSI doesn't require customization or silencing, because it is customized and silenced already. Your MSI studio has created a custom MSI that does everything the diff recognized needs to be done.

Admittedly, sometimes these diffs don't work exactly as planned. Perhaps something else happened during the period of the two snapshots, such as some network service performing some change. Other times, you need to add in customizations even after the install. For these reasons the really good MSI studios out there will provide a workspace that allows you to modify the package characteristics after creation.

Elephants Be Gone!

You should at this point see why most IT shops rarely get past the dreaming stage with automating software deployment. Even with the assistive tools, this is a pretty big job that's going to take a lot of time. But, unlike almost every other IT solution out there, this is an investment worth making. With the right deployment solution, the benefits are enormous.

If you haven't yet been scared away by the potential workload, keep this article close at hand. It'll be your reference guide towards finding your elephantless magic nirvana.


Comments

  • This is very informative, however, for me its just making sure that I match up all of the different commands for each individual app that needs to be repackage. For example, I want to deploy a package where my OS is involved, plus MS office, and other basic apps like teamviewer, adobe reader, skype, firefox, google chrome, snag-it programs. I want to bundle that software package and make that deployment package as my basic image for any laptop/desktop computer that he need to re-image or that just came in as oobe. - dmc32 10 years ago
  • I am an Sr. Application Packager. I have written vbScripts to crack open MSI files, read a bunch of contents, then based on some check boxes (Ok its an HTA I wrote) it will create install and uninstall .bat files that will verify the software is NOT installed, install the software, then Verify the software is INstalled. it will exit with different exit codes based on what it finds. I have also written other customer software that I can specify an application packager, select a machine and silently send the selected (or multi) selected software to that machine and again verify. I am looking to sell my code. - Hayseed 9 years ago
This post is locked
 
This website uses cookies. By continuing to use this site and/or clicking the "Accept" button you are providing consent Quest Software and its affiliates do NOT sell the Personal Data you provide to us either when you register on our websites or when you do business with us. For more information about our Privacy Policy and our data protection efforts, please visit GDPR-HQ