Software packaging methods

Users also have a great advantage: it allows them to install software with zero technical knowledge with clicking a button. Additionally, all settings can be pre-set so that a user can install a piece of software and begin using right away. There are generally 3 steps in the packaging process: application discovery, application packaging and user acceptance testing. Some organizations also add a QA step in the process.

During the application discovery process, the application source file is validated and verified as functional. This is an important step because it is the basis of the application package that will eventually be created. The next step is creating the package.

During the discovery stage you will have mapped out the necessary requirements and therefore the second step is typically rather straightforward. The last step is UAT. This step serves to check that the package works as it is supposed to before it is sent to production.

In this step you want to make sure that the application is running as it was defined in the discovery phase. Due to often requiring a significant initial investment, some organizations doubt the efficiency and necessity of the packaging process. However, there are several benefits for any company. Lowering support costs — The process may be expensive at first, but in the long run it reduces support costs.

This is because the process creates a stable environment that allows IT teams to address issues immediately and on a large scale. Not only that, during the application process, there are multiple rounds of testing, guaranteeing that by the time the software reaches the end user, issues will have been discovered already.

This also reduces support costs in the long run. Ease of distribution — For large companies, this is a major advantage. Application packaging allows you to distribute to all users, no matter where they are easily and quickly.

Software management — Once the software has been installed on the relevant devices, IT teams are responsible for keeping everything working well, adding devices, fixing issues, etc. Using a Configuration Manager, IT teams are able to manage and deploy software in a significantly easier manner than without.

Minimizing security risks — Cybersecurity is a major threat today, and application packaging helps reduce the threat for organizations. Security issues can also come to light during the packaging process and be taken care of before becoming threats.

Control over software installation — No company wants to find itself installing unnecessary, or illegal, copies of software. This is because all software that is installed goes through the IT department. You can even deploy applications using task sequences for your more complex installs. With so many options, you have the flexibility to use whatever you feel like or whatever is easiest on a per-app basis.

A recurring theme in the deployment tool migrations that I have been involved in is that companies got stung by using proprietary application deployment features from other products. The company I worked for that using Enteo took advantage of their extremely useful framework for wrapping the installs. In some cases, they modified a registry key, copied some files and then ran the vendors.

Almost all of the applications used that wrapper in one way or another. Another customer I worked for used Marimba and had also created packages that used Marimba features for making changes to the desktop rather than through the install string or package. Using custom features left both in a tricky spot when they wanted to use SCCM. And SCCM was not the problem! If they wanted to move to another tool such as Altiris, they would have run into the same problem!

So before you decide to throw caution to the wind, I would suggest that you consider your migration an opportunity to standardize on your application packaging.

In my opinion, packaging is not something you do in a deployment tool! So, if you found this article by searching: Using SCCM to package applications , let me stop you right there!

With that out of the way, how should you package your Windows applications to deploy your desktops or servers using SCCM? This package type has been around since but never received the widespread adoption it deserved. When deploying an MSI you avail of some killer features which are still as useful today as they ever were, such as the ability for the install to gracefully rollback and undo what it had done to the point of failure.

This is so much better than scripted installs which can fail part of the way through and leave your users systems in an unknown state. Applications deployed with MSI could also auto-repair.

If a user accidently removed files belonging to the application, it would simply fix itself. The file table does not contain any files.

This completely negates the features of MSI such as the graceful rollback but in fairness, who can blame them? Windows app package is still relatively new. Microsoft has released a beta desktop converter tool for moving your Win32 applications into the new format but as of writing, I would have to say this is nowhere near ready for prime time yet! Web application is just for deploying a shortcut with the target set to a website URL.

This is not the best way to publish or advertise sites to your users. Not listed in the screenshot is the option for a scripted install or task sequence. In certain cases, you may want to use a scripted install or task sequence.

A scripted install can be useful when deploying a large application that must be deployed using the vendor provided installation media. To give you an example, I worked on an SQL product which had a. I discovered some SQL patches were actually being executed as part of the exe.

I had no choice! I had to deploy with the. Task sequences can be great when you have multiple installers or require multiple reboots during an installation. Microsoft App-V!! App-V uses a tool called the Sequencer to do a snapshot of an application install. 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.

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 think that if you tested it on 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 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.

Yeah sure, you could do that 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. 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.

I think that no automation is needed here. Assumption 1 : we already developed an automation script to install and configure the software as we desire.

Challenge1 : How do we automate the cleanup of the capture? Each and every system is different yes, even virtual machines. And even if you somehow knew that you will still need some powerful tools and scripts to perform the cleanup.