It’s been a while since I don’t write new entries in my blog, so I decided to get back on track with a few articles about packaging applications. But, the approach won’t be from the virtual applications perspective, will be focusing on that strange matter of building the right installation, configuration and deployment process for your applications.

What We Will Cover

Packaging applications represents a very vast set of topics that we can discuss, even if we take the virtualization off the table. Here’s a short summary of what we will cover in this set of posts:

1. Understanding Application Packaging
2. Silent installations vs. MSI customized packages
3. Benefits of Application Packaging
4. Packaging Best Practices
5. Packaging Applications without 3^rd Party Tools (silent installations): Reviewing best practices; Packaging Examples; Troubleshooting .
6. Packaging Application with 3^rd Party Tools: Reviewing the Windows Installer; Reviewing best practices; Packaging Examples; Troubleshooting.

Understanding Application Packaging

Let’s take a moment to talk about application packaging and the statement I’m using about using or not 3^rd party tools to achieve it.

Application packaging can actually have several definitions by itself, and it can definitely vary depending on each situation and the outcome we are looking for. But, in a simple manner, I can say that application packaging represents the process from which we can get an automated method to deploy applications with the proper configurations for our environment.

To achieve that, basically, we have two alternatives: Using silent and customized installations or using 3^rd party tools (like AdminStudio or Advanced Installer). This second alternative can generate for us, from “capturing” a valid installation, a customized MSI file with the personalization we need for that application (keep in mind that MSI files are, by definition, installation files that can be silently installed).

Silent installations vs. MSI customized packages

Considering silent installations and MSI customized files as valid forms of packaging, we need to establish when we want silent installations or capturing MSI files for deployment.

The answer will depend on these two initial questions:

1. Does the software provider support silent installations and how many parameters can we introduce?

Many providers give us the opportunity to achieve silent installations with all the necessary configurations for our environment. Autodesk and Adobe are great examples, since they provide their own engine to generate “answer files” for the installation process and achieve automated and customized installations.

Many others include in their “User Guide” the right parameters we can use to get similar results in the installation process and some just not provide any method for an automated process.

This is what Autodesk offers us to create our own packages (applies for any suite). A simple wizard to follow and create a “deployment type”; the outcome we can later deploy automatically with all necessary customizations.

2. How many customizations I need to perform in my package in order to have it ready for deployment?

In some cases we have the possibility to perform silent installations with personalized configurations, but sometimes these are not enough. There are several examples of licensed software that require introducing licenses using a manual process; this could be an example of applications that might need for 3^rd party tools for packages creation.

Take a closer look to the documentation available for the application and review the parameters we can use to deploy the applications without generating a customized MSI.

In my personal opinion I always try to use the silent installation method as the preferred one. This is because, if the software provider gives us the chance to install and customize the software automatically, then we have an official support and “guarantee” that this software is going to be installed in a proper manner.

If we decide to capture and create an MSI of our own, the package will depend on the software and type of “capture” we will be using for this application; and of course having the risk to exclude files and registries that will be required later using the app.

Benefits of Application Packaging

Let’s take a quick moment to analyze why application packaging is highly recommended in almost any company:

1. Customizing the application so it can fit to our company’s needs and policies: No matter if you are using silent installations or customized MSI, you should be looking for a way to configure your applications properly among all users.

2. Provides an easy, predictable and repeatable way to deploy our applications: Removing the complexity in deployments and the possibility of user misconfigurations not only saves us troubleshooting time but money we need to invest in admins for deployment and support.

3. Helps us standardize our users’ desktops: Related to the previous benefit mentioned, having the standard method to deploy applications also facilitates us in the OS and applications life-cycle; easier to maintain and update.

4. Gives you the possibility to limit the administration rights delegation: When you are using non-packaged apps, you will depend on users or delegated admins to install, reconfigure and/or uninstall applications. Having packaged applications and a deployment tool to deliver the applications, you can annul distributing admins rights to users or help desk personnel for example.

First Approach to Packaging Best Practices

Prior to get our hands into some examples of packaging applications, I want to take a moment to review some of the general best practices when we are packaging applications. When we start talking about some examples, we will take a deeper look into these best practices and some other specific for silent installations or using 3^rd party tools for packaging.

1. Understand the application and the environment you are using.

Review applications requirements, documentation (if any) and the scenario you will need to deploy each application. Understand the purpose of the application and targeted users. Understand the environment you will be using for deploying the applications: The distribution method available, operating systems involved, and so on. We usually tend to use a comfortable and predictive environment for packaging the application, this most likely won’t be the environment you’ll be deploying it.

2. Review and write down common use cases for each application so you can test it properly.

Once we completed packaging an application we need, of course, to test it. And it is important to remember that we cannot complete a test just by verifying the installation has completed, we need to have a small group of tests to run on each application, consider having a talk earlier with each application owner to verify the tests you might need to run in order to validate the app functionality.

3. Don’t start packaging until you have the final OS image ready.

Operating systems represents an important part in the packaging process; applications behavior should vary depending on the Service Pack level installed, features implemented (a good example is .Net Framework), other basic components and software to be installed, configurations to be used (for instance, UAC enabled/disabled). If we are using an image as an assumption for the targeted operating systems, we could find several problems with packages not being able to install or applications malfunctions.

4. Prepare a virtual machine with OS “gold image” and use snapshots for packaging.

It is important to have a fresh OS image available whenever you are going to package a new application. And using the term “fresh” doesn’t refers on having a Windows OS without any application installed, should be the “gold image” from which the applications will be later deployed. Having the possibility to virtual machines and snapshots will be crucial to facilitate the process.

5. Try using silent installations as the first option for packaging.

Like I mentioned earlier, using silent installations is the preferred method to start packaging an application. With that, we are ensuring that our app will be installed and supported by the vendor involved. Using a customized MSI file we could have a higher level of personalization and even improving package size and deployment, but it could also result on having to later troubleshoot the application functionality because we excluded necessary files in the app environment.

Also keep in mind that several applications are not suited to be re-packaged into a new MSI and even though you can create a customized packaged, the deployment process won’t succeed.

6. Try not to think applications to be packaged as independent from their OS or other applications.

Since we are not virtualizing applications, these packages won’t exist in a “bubble”, they will have dependencies with OS components as well with other applications. We usually try to package an application in the best scenario, like a fresh installation using from a virtual machine snapshot. We must pay attention if the application could require a reboot for completion, if we are deploying several applications our process could be stopped waiting for a reboot from the previous package. Also, one application requirement could be conflicting with the requirement from a different application.

Try to think out-of-the-box and review any dependencies that could appear in production.

7. Be methodical in the application packaging process

Plan your packaging and deployment processes; document what you are going to do and the tests you perform; prepare checklists and any other thing that can help you and others along the process. If any constraints are found in the packaging process (for instance, applications that require a reboot to complete deployment) write it down and use that information to adjust your planning in the deployment process.

Having a predictable way to package applications will help you and colleagues in their jobs.

In the next post I’ll be reviewing some examples and hands-on processes for applications silent and customized installations.