How much can you automate your software packaging process? An IT Pro perspective.

Written by Alex Marin · May 22nd, 2020

#MSIX #MSI

Automation. A word heavily used around industries, especially the software one. A word that arouses great interest for every manager, service, or business owner.

For a business, automation achieves three important things:

Faster delivery times
Eliminates human errors
Adds more revenue while reducing costs

We live in times where almost everything you buy or use has an automation process in the background. Your car is built mostly with automation processes behind your phone, tablet, headphones, and so on.

Remember when everything was bought with cash? You physically had to go to purchase something, and the idea of using a credit card on the internet was scary, or even seemed like something from a SciFi movie.

A few decades later, online shopping is growing faster and faster, becoming something normal. But, if you think of it, your whole online purchase process is automated.

However, as in any business, human input and knowledge are still needed.

So how does automation apply to the software packaging department?

Before we get into the automation part, let’s see the types of packages present in an infrastructure. You have your classic Win32 applications, and you also have virtualized applications.

There are many types of virtualized applications, starting with App-V , MSIX, or other 3rd party solutions like VMWare AppVolumes.

Virtualized applications are, in short, applications that run inside a container, meaning that everything is placed or executed separated from the system. When you install or uninstall a virtualized application, nothing changes in your system; it only uses designated areas for the specific virtualization type.

Automating your virtualized applications

The repackage and deployment of an application is heavily dependent on the technology type; thus, we approach it accordingly.

In terms of repackaging - virtualized applications are easier to handle and repackage.

As stated before, virtualized applications run in their own container and don’t change the system. This is their main attribute, quality, and purpose.

After you repackaged your application, you can basically deploy it in your infrastructure. And if your capture contains junk information-- it doesn’t matter-- it won’t affect your system.

The junk will be ignored because the application itself doesn’t use it and the rest of the system doesn't see it since it is inside the app’s container.

User data can be ignored in virtual applications because they know how to handle it.

So if you want to automate the repackaging process, you are in luck because all you need to do is design some PowerShell scripts to:

Start a capture
Install the desired application
Perform any additional changes
Stop the capture
Save the virtualized application

With Advanced Installer, you can perform the above-mentioned steps using the provided PowerShell cmdlets.

Microsoft APP-V Sequencer added support for Powershell cmdlets so you can follow the automation sequence associated with PowerShell.

Of course, you still need to test the application afterward, but you can, indeed, perform high degree automation for this area.

The main challenge here in repackaging is to find a way to automate the process of customizing the software, because most of the installers have some form of silent installation, and that part is easy.

Automating your Win32 Applications

For Win32 classic apps, you have the following packaging methods:

MSI - is the commonly used way to deploy applications in an infrastructure
EXE - either perform silent installs for vendors or make an EXE bundle yourself
Scripts - Batch, VBScript, PowerShell or other desired choice in scripting language can be used to create and install a package

Although MSI is the preferred way when it comes to deployments, not all vendors adopted the technology, even if it’s been out for quite some while. This is just one of the problems.

For many enterprise customers, a straightforward installation of an app with its defaults is not enough. Most of the time, customizations must be applied during the repackaging phase.

In order to repackage an EXE, you must:

Recapture the installer using Advanced Installer Repackager
Clean up the capture
Customize the capture (add extra desired registry/files, place an upgrade for the previous version, perform custom actions)
Build the MSI

It may sound simple at first, but every application is different. You might encounter differences even from one version to another for an application. You may ask why don’t you simply make a silent install of the EXE or the Script provided by the vendor?

Those are usually last resorts, because:

you don’t know the installation success rate of a custom EXE - with MSI, as John Vintzel mentions: “we know that IT Pros spend a bunch of time either repackaging or using different types of tools to get that Success rate up to the mid 90%".
many custom EXEs don’t document, or simply don’t have the option to create or place log files where you need it. Without log files, no application should ever reach the deployment phase. Period.

You may think that if you tested it on 1-2 virtual machines and it works, but trust me -somebody, somewhere, will have a problem with it. And when that ticket comes from the support desk to ask you what is wrong with it...you will have absolutely no clue what is happening there with no log to check.

Consider also the extra work needed to customize the software. Some applications require many changes in terms of registry and files, and if you perform them via script is going to take a long time for you to make a package.

One argument to that statement would be “I can create a customization MSI”. Yeah sure, you could do that...but why? Why hustle to find out how to customize an application, create a separate MSI, hide the MSI entry, create a script that installs your EXE silent, and your MSI? Why load the system with unnecessary installers?

What about reporting? Why show two installers for the same product when custom reports are pulled out of SCCM? What if you forget sometimes to uninstall the customization MSI, a newer version is released and installed, and the reporting shows both apps installed on the machine?

And the list of questions can continue. The simple answer is, it leads to high human error risk exposure.

These are some of the main issues and questions that appear when you start to repackage a classic Win32 application.

And, we haven't even started the repackaging process yet, right? We just explored possibilities until now.

Win32 - 1st Scenario - MSI vs Other

Ok, let’s assume we decide that, if the vendor’s installer is an MSI - we automate the creation of transforms, and if the vendor is of any other kind - then we automate the repackaging process.

Transforms

Transforms cannot be automated, period.

In order to know how an MSI works, you must first open it, look at it, install it, and then you will figure out what really happens there.

But with transforms is easier, because, once you create a transform, you can copy that transform for the next version of the vendor MSI and just change tiny little things that have been modified in the latest release.

So, transforms might be harder to create at first, but afterward, everything is easier and it’s almost no time-consuming.

I think that no automation is needed here. If a transform doesn’t work, you still have to know what to do with it, so change it and add it again.

Repackaging

Let’s start with repackaging the other kind of installers

Assumption 1: we already developed an automation script to install and configure the software as we desire. That’s cool.

Assumption 2: we automate the capture process (start capture, install/configure application/ stop capture). That’s cool too.

Challenge1: How do we automate the cleanup of the capture?
Each and every system is different (yes, even virtual machines). You can’t possibly know what’s present in the capture. And even if you somehow knew that you will still need some powerful tools and scripts to perform the cleanup.

Challenge 2: There is a common problem with classic installers, and it’s called USER DATA.
Unlike APP-V, we cannot ignore it, because it must be properly added into the MSI for it to prevent the Windows Installer to ask for media when a repair is performed.

So what do you do with such data?
The best practice is to place any files/folders that are related to the user profile somewhere in the per-machine installation, usually in a subfolder called “Userdata”. Afterward, create a custom action in VBScript that copies the specified folder/files to the appropriate location during Active Setup.

Did I say Active Setup? Well, I guess we should add a new component that contains the Active Setup registry. So add that too in the automation script.

But wait. You should delete the Active Setup from the HKCU as well during uninstall as a best practice, right? So we need to add another custom action into the MSI in the form of a VBScript. So add that too in the automation script.

There is, of course, the third-party tools issue. In some cases, you must use third-party tools to perform some sorts of changes to your application.

One example that comes to mind is adding custom certificates in the cacerts file for Java. In order to modify the cacerts file, third party tools must be used. And no tool has automation to it, because each added certificate must be validated. There are cases where I had to add 600 certificates by hand, one by one. Trust me - I tried to find any sort of automation. I haven’t found any yet.

Let’s face the truth: Some customizations may never be automated.

But even so, all the examples above require a lot of work to create a “magical” automation script. Just think of all the resources you use to create and test such a script. And the effort multiplies with the number of applications you intend to automate.

And only if we do not consider the natural evolution of an application with all its changes over time. It all leads to adding another dimension to the automation process.

Is any automation possible, though?

I’m sure you’re like: What are you saying? No automation is possible here?

Yes, it’s possible, but I would not call it automation.

After you have captured the application, cleaned it up, and done all the changes you needed, with Advanced Installer you can save your project as a template.

Next time you receive a new version of the app, just check what changes were made by the vendor, open your template, and perform them there. When opening a template, all the product codes are dynamically generated by default, so you don’t have to worry about it.

It’s not perfect automation, but it does minimize the time needed to perform a repackaging process to your application.

Another tip is to create templates for small but consistent things that you are always adding in your package and just start the project with them. This way you never forget about the mandatory changes and it saves you time.

Conclusion

Full automation is possible only when it comes to virtualized applications. It implies straightforward applications and a lot of scripting to install and configure the application silently.

Regarding ordinary win32 applications, the best you can do is use some sort of templates, or only perform small changes on your previous MSI’s (if you know how to configure them afterward).

Full automation of win32 applications will never be possible.

Before you even start thinking of automating anything, think of the time investment in the scripts and who will perform them. If you hire a specialist for a one-time job to write these scripts, when the application changes, you will find that you must hire the specialist on a full-time basis, to constantly update the scripts.

There will always be a need and an objective to execute repetitive tasks with some form of automation. And that’s fine. The human mind will find ways to skip the tedious tasks.
Do not expect, though, to replace the human input with robots - but rather set your goals in supporting the pursuit of automation to make your packaging teamwork more efficient, productive, and error-free.