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).
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.
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.
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).
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
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 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:
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.
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.
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.