Robert McQuhae
Read Time : 15 Minutes
This is part 2 of a 3 part series on application packaging.
This is Part 2 of our series on Application packaging. Why is app packaging important? Can't I just get an installation package from the internet and double click it? Are you looking to improve your security posture? Or are you working on improving your operating environment?
Application packaging here refers to the Enterprise level Application packaging services. This goes above and beyond just having a silent installation, but making sure the application works correctly within your environment. This will include making sure it upgrades successfully, and all settings are retained (or cleared if it is implicitly required).
What is app packaging?
For a more thorough delve into app packaging, please see Part 1. This is an extension of part one's silent installations. In this part we are going to take a little bit more of a dive into silent installation process.
As a reminder Silent installations are installation or upgrades that not only have no user interaction, but they also have no visible processes that can make the user aware an installation is happening.
Additional considerations with silent installations
Creating a silent installation package is just as simple as adding a switch to the installer e.g.
-
/QN
-
/silent
-
/s
-
--silent
The are many options here, and these will all be dependent on the type of installation media that the software is packaged in. The thing is, it really doesn't stop with just having an installation switch. Many applications have additional configurations that need to be set during installation.
-
Allow auto upgrade
-
Server location
-
License server location
-
License key
-
Database connection strings
-
Add (or remove) shortcuts
-
Allow the installation to perform a reboot
-
Install all the required dependencies
This is before we have even looked at what options we need for upgrades. Upgrades become a little trickier as we need to make some decisions around whether the application will keep the user's current settings, or if we want to deliberately clobber those settings.
Next, we need to make sure that settings are retained if there is an issue with the application, or it has an error. If there is a required file that is either missing or corrupt, some applications can run a self-repair function. However, if the installation is not configured correctly, there is a high likelihood that the installation will revert back to its default settings. Any customisations that you have made when installing will be lost.
Lastly we will need to make sure that there is logging of the installation processes. If there is an issue with the installation routing, it will make it easier to troubleshoot if we have some logs of where it went wrong. This will not just be installation logs, but event viewer logs as well.
Deployment methodologies
So, now we have our silent installation, we need to get this pushed to the device and run. This could be either on demand or forcefully pushed.
The following are solutions that can assist with getting installations to devices:
-
Intune
-
SCCM
-
GPO
-
Logon Scripts
-
PDQ
-
ManageEngine
-
Steve, and Stella from the Service Desk having to walk around to every device with a USB key and run the installer (no-one wants this option, not just Steve and Stella, but this is a big impact to the end users)
Each of these will have a time and a place to be utilised. I am going to have a bias here to Intune and SCCM. These are solutions that are from Microsoft, and in my opinion are the best options. Intune is really a great extension from SCCM that has the option to push packages out to devices as long as there is an internet connection.
These solutions will allow for the silent installation process to run as either the current user that is logged on, or the system user. This gives the most flexibility for either user based, or administrator based installations.
The last part, and quite possibly the most important part, is the reporting that the installation has been completed successfully (or errors).
Extra bits that aren't in the installation
What about those times when it is not possible have the installer do everything. The following are some extra bits, and some possible ideas of where to address them
-
Extra packages/Dependent packages
-
This is handled really well in Intune with the ability to specify dependencies for applications
-
-
Settings per department e.g. Google Chrome or Citrix workspace configurations
-
Not all settings can be handled at installation time pushing settings like Chrome or Workspace have their own ADMX templates that can easily be imported into Active Directory and pushed out via a GPO
-
Intune also has the ability to push out These types of settings, including importing ADMX.
-
-
Pre or post items
-
These could include extra installation options
-
Uninstalling specified unrequired applications
-
These type of options are recommended to be pushed out with some form of scripting.
-
You may need to get creative for where these scripts are run
-
-
Upgrades
Upgrading applications is one of the more in depth processes within application packaging. Let us step through what happens during a normal upgrade process.
-
There is an existing application
-
The upgrade installation happens
-
There is a check if the version is a supported upgrade version
-
Depending on the location of the settings for the application these may be backed up
-
The original application is uninstalled
-
The new version is installed
-
If the settings are in the same location they are retained
-
Settings otherwise will need to be restored.
-
There are two main reasons that upgrades are important:
-
To add new features and functionality
-
Remediate a security vulnerability.
The latter is probably the more important of the two. While the process to have an upgrade performed on an application is important, it is also important to be able to report that 87.35% of your fleet of devices are on a specific version of an application. This is an important consideration for regulatory and compliance needs.
Testing
Testing is one of the most vital parts of application packaging. It is all well and good to install an application but how do you know that it is working as needed/specified?
Depending on the level of testing required, testing may take longer than the packaging process itself. The following are some high level steps for testing, and is broken up into 3 phases:
Discovery/Initial testing
This is the first phase of testing. This testing involves some of the following processes
-
Manual installation testing
-
Upgrade testing (from a manual installation)
-
Testing for required applications
-
Testing that the application opens and there are no errors when opening.
Quality Assurance testing
The second phase of testing. This is done with our silent installations and chosen deliver methods.
-
Test Silent installation is successful
-
Test deploying using appropriate delivery method
-
Testing that all dependencies are installed
-
Testing that application opens and runs as expected.
-
Ensuring that the application is reporting back to the delivery method that it is installed correctly.
Pilot Testing
The final phase is piloting this with a small percentage of the user base. This is done to limit the impact if there is an issue with the application. It is much easier to fix 13 devices if there is a misconfiguration in the package rather than 1300 devices.
Application packaging is such an important piece to create standardisation within your environment. This ensures that all your devices have all the required applications, and they are all installed in a consistent manner.
Creating an environment that is consistent for all of your users. This is just one part of the overall Standard Operating Environment (SOE), which is also important for organisations seeking to improve their security posture, or adhere to frameworks such as CIS and Essential Eight.
From deployment to maintenance, SureDeploy's robust endpoint management solutions empower your team to easily oversee, secure and optimise your entire endpoint fleet.
Share this
