Robert McQuhae
This is part 3 of a 3 part series on application packaging.
Here is a list of common Do's (and why you should do them) and Don'ts that we recommend when it comes to application Packaging. This is not a complete list, but many of these we have found over the years of doing this.
Don'ts
Lets get the bad bits out of the way first
Package Source
Don't use 3 party hosting sites for application installers i.e., The Pirate Bay, Major Geeks, Napster. These are really bad locations for getting installations. Even places like Sourceforge and Github can have suspect installations on them as these are community sites and anyone can upload to them.
This is the most important Don't because if you don't get this one right it can introduce many problems in to your environment.
Community Installers
Don't use uncurated community installation solutions e.g. WinGet or Chocolatey.
-
These can be updated by anyone and there may be a malicious installer. This could be accidental or deliberate.
-
Not to say these solutions are necessarily bad, however they should only be pointing to internal curated repositories.
Let Users Install Apps
Don't let users install their own applications. If users are installing their own applications there are several implications:
-
Many applications require the user to be an administrator to install the application. This is a security risk in itself.
-
If the user isn't an administrator, it will likely install the application into the user's profile directory. Allowing any application to be installed to the user profile means that any applications could include Malware/viruses.
-
There is no control or updates for user installed applications.
-
Reporting on applications that a user installs is more difficult.
Have Installations Processes that have User Prompts
Don't have prompts popup when the application installs. This can stop a completely unattended installation process, or worse it can allow a user to customise the installation in a way that was not intended. i.e. changing the installation directory to c:\InstallHere\.
Package Once
Don't package the application just once. There are very few applications that are one-off installations. Applications will regularly have updates. If a rollout takes 3-6 months to complete, you may find that you need to update the versions of applications more than once.
Do's
These are things that you should be concentrating on!
Have a List of Supported Applications
Create a list of standard applications for your business, and mandate these applications. There might be 10 applications to perform a function. However based on licensing, only one is chosen. The following is an example of how this might be used.
The following are password managers:
-
1Password.
-
Keepass.
-
Lastpass.
-
Dashlane.
- I'm sure you can add another 5 to this list.
As a business decision, only 1Password is supported and is available for installation.
Package Source
Choose a reputable location for obtaining the installation files. The following are recommended locations for getting installation media:
-
Vendor sites.
-
CD/DVD from vendors.
-
In house Apps binaries from your development team.
Avoid sites file sharing sites like Major geeks, Napster, The Pirate Bay. Sites like Github or Sourceforge need to have extra care taken when getting installers from these sites, as anyone can upload to these.
Scan Your Installation Files
The installation files should be virus scanned before they are installed into your environment. Adding to this, once the application is installed there should be an additional scan of the installed files. This should be performed as part of the testing process, details further below.
Internal Application Repositories
When using deployment methods like Chocolatey WinGet have curated internal repositories. These should only contain installations from a valid vendor site. Have a list of supported applications that you regularly get updates for and push into your own repo
Use Deployment Tools
For the best way to push out applications, we recommend using a deployment tool such as Intune or SCCM. As these are part of the Microsoft suite they offer better integrations into the rest of the Microsoft ecosystem.
Additionally, using a deployment tool reduces any need to physically install/upgrade applications on endpoint devices.
Upgrade Applications Regularly
Applications and operating systems get updated on a regular basis. Applications such as Chrome, FireFox and Adobe reader can be updated multiple times a month. At times this can even be weekly or daily. This is especially important if there is a critical vulnerability (CVE) released.
Application packaging doesn't stop with packaging an application once. It is an ongoing process.
Test Test Test and Test Some More
Before an Application gets deployed to users it needs to be tested. Testing needs to be in multiple areas:
-
New installations - Brand new machine without ever having the application installed
-
Upgrade - Testing upgrading a range of versions not just the previous version to make sure the applications upgrade successfully.
-
Uninstallation - Making sure the application gets removed correctly.
-
Application repair - If there is an application repair triggered it should re-install itself with the correct. settings.
-
Application usage testing - Make sure the application functions correctly.
Transforms
When using MSI installation files, make sure that you use transforms when customising the installer rather than commandline options. This is really important when it comes to issues with applications. If there is an issue with the application and the application repair is called, some of the customisations might be removed.
Logging of Installations
Do lots of logging. Make sure when you install applications that all the installation logging is turned on. This will include script logging, installer logging and logging into the event logs.
Where possible, standardise this log location and create internal documentation on how to read and remediate issue with application packaging.
Documentation
Do create internal documentation for all application packages that are used and options. This makes life easier for others to support the packages that you already have, and to be able to continue to package in the same manner.
Hopefully this list helps you when creating packages, and gives you hints on what to be mindful of. Keeping these things in the back of your mind when creating packages will help set you up for success.
This rounds off the 3 part series on application packaging. If this is something that you need help with within your organisation, we have a specialist team at SureDeploy that can assist.
Take the complexity out of Microsoft Intune deployments with SureDeploy. Elevate your device management capabilities and enhance your security score.
