In presentations that I’ve made the last few years I have been mentioning the increasing need for Enterprises to get focused on how they handle the lifecycle of applications. I touched upon this briefly in a recent post on App-V Migration and have blogged about parts of the process in the past, but the topic deserves a separate blog covering what you should be striving for today and providing a prioritization over the different parts.
Why?
The days of the “install-and-forget” mentality of handling the application lifecycle have come to an end. Just as the Operating System has a shortened supportability timeframe, so do the applications you install. Staying secure means keeping up not only patching the OS, but all of those of the applications as well. Those applications are built using frameworks and including redistributable runtime components that have vulnerabilities in addition to those of the application developer.
It is now more important than ever to set up a plan to keep those applications patched. This can be done by leveraging automation to make the job much easier, but this requires forethought.
Getting Started
The image below is an overview of what I think the full application packaging cycle looks like. We can automate this process significantly, but you also don’t have to automate everything on day one.
App Definition Datastore
You need to track applications; to have a place to store assets, documentation, and status. This can be a single place, however it can be the loose collection of folders, files, and spreadsheets that you use today. While you can probably use to get more organized than what you are currently doing here, you shouldn’t let creating organization here get in the way of getting started.
Priority:
- This is high priority item to ensure you have a well-defined place for everything, and well-communicated to your teammates.
- But this is a low priority item that you can improve upon over-time.
Update-Discovery
While you don’t necessarily want to take every release from a vendor automatically, you need to have a mechanism to discover that they exist and evaluate the need to update. There are efforts out there that you can leverage to help you with this task.
Vendors, such as Flexera, with their Software Vulnerability Management | Flexera product can detect and report when your applications have known security vulnerabilities, often whether patches from the vendor are available or not.
Open source tools, such as Introduction – Evergreen (stealthpuppy.com) allow you to automate the detection of vendor updates, even downloading the update installer to a folder for you. This is something you can run monthly, weekly, or even daily and have a list of available updates when you come in to work.
Package Managers like Chocolatey Software | Chocolatey – The package manager for Windows and GitHub – microsoft/winget-cli: Windows Package Manager CLI (aka winget) can be adapted for this purpose as well.
Priority:
- This is a lower priority than the next two items.
Install-Configure
You probably already have a reasonably good handle on how to install and configure the applications in your portfolio. If this consists of written documentation, you will want to move towards automation (which can serve as the documentation).
It starts with scripting of the vendor installer, using silent or passive installation techniques. Sites, such as Silent Install HQ – Silent Install & Command Line Switch Knowledge Base can help with the basics. Additional sites, such as GitHub – TimMangan/App-Info: A community sourced information store about applications or App Tips – AppDeployNews often also include additional help on application specific configuration changes typically made by enterprises (such as defeating the autoupdater).
Your goal should be to fully automate the installation and pre-configuration of every application. If you aren’t doing this today, then a PowerShell module like PassiveInstall (tmurgent.com) might make it easier to get started.
Priority:
- Automated Installation and Pre-Configuration of applications should be the top priority.
Packaging
With fully scripted install-configure, you may not need packaging. But often Enterprises are using packaging as part of their deployment process. In the past this might have been repackaging into MSI or App-V. But repackaging into MSIX, App Layering products, or other proprietary forms might be in your mix. Depending on the format, this can also often be automated.
A full automated packaging solution must not only consume the automated install-configure of the application, but needs to be flexible enough to automate the pre-packaging effort to lay down dependencies.
In the past, I’ve blogged about automating this for App-V Life with the App-V AutoSequencer – Confessions of a Guru (tmurgent.com) and for MSIX Automated MSIX Repackaging with PSF – Confessions of a Guru (tmurgent.com).
I will be updating the GitHub project GitHub – TimMangan/msix-packaging2 that has the scripts for automatically packaging into MSIX by chaining the Microsoft MSIX Packaging Tool output directly into TMEditX shortly. I plan to release another script/blog early this summer to address automating App-V packages into MSIX and using TMEditX to fixup those packages as well.
Today, I have 95 packages that I can create packages in App-V or MSIX (fixed with TMEditX) from the Install-Configure scripting I have set up. The final output can be MSIX or CIM (for AppAttach). Most of the time I can also take the App-V packages and automate the conversion and fixing into MSIX, however there is more work to do to make that more successful.
Priority:
- Second, once the Install-Configure scripting is ready.
Robo-Testing
Each year I perform testing on a slew of packages as part of compatibility testing on MSIX The MSIX ReportCard for 2003 – Confessions of a Guru (tmurgent.com). This was a lot of work installing, configuring, packaging, and testing all of those apps three times each to cover the three scenarios. And while I don’t post the results every time, I actually do this about 4-5 times a year. In the past I had automated the Install-Configure and Packaging for all of those apps, allowing me to push a button to get all of the packages created for a given scenario in less than a day, but then it would take about 2 weeks to validate the quality of the packaged apps in that scenario.
My app datastore already contains the documented testing criteria that I use for my “high-fidelity” testing of each of those apps. So, this spring I opted to move into automating the testing.
There are vendors, like Digitally transform your world faster, smarter, and easier. | Rimo3 that have comprehensive application lifecycle systems you can invest in. But being cheap, I decided to try Microsoft’s Power Automate. While the full-blown capabilities of Power Automate are expensive and intended for different usage, you can use Power Automate for free as part of a M365 subscription to perform UAT-style testing of desktop apps on your own equipment. In 3 weeks, I was able to learn Power Automate (and Power Apps), build a testing framework, and create the application-specific test apps for 80 apps (DISCLAMER: I already had packages, a full understanding on what to test for each app, and I’m awesome). When I complete the rest of the apps, I expect to be able to have the automated testing for almost all of the packages in the scenario complete in under 4 hours. There will probably remain a couple of the packages that I have to test by hand due to how the vendor builds their app and I’ll need another hour to review the results, but reducing that load from 2 weeks to a day is great.
I’m not sure how I’ll be able to share what I do, as export/import capabilities are restricted to the fully licensed version, but maybe there will be a video or training class way to share this in the future.
Keep in mind that automated testing, through whatever means will not eliminate the need for the UAT test later on. Working with the UAT test person, you can cover 100% of what they do via automation on many apps but consider this a much higher quality smoke test than you probably do today, performed much more efficiently and accurately.
Priority:
- This is probably the lowest priority; important, but you need to get the other items done first.
Conclusion
Application lifecycles are reducing. The frameworks that developers rely on are shrinking. While most of the Win32 API is still in support (because so much of Windows itself depends upon it), much of the .Net Framework is either already out of support or will be soon. The modern .Net releases of just a few years ago (.Net 1,2,3) are already out of support, and the newer ones run with alternating 3- and 5-year lifecycles. Vendors don’t release new software using the latest .Net the day after Microsoft releases it, so that might mean that the vendor only has a year left on the support when they get out their first release using it. And they might have their own security flaws to patch.
Staying secure means keeping up not only patching the OS patches, but all of those of the applications as well.
You should start on a journey that will allow you to handle the shortened lifecycle of applications with less work that what you do today. It doesn’t need to be a full-blown automation project. You can add the incremental steps outlined in this post over time against all your packages. But you can also decide to take on the full list of things here, but only for a small number of applications that you see being updated frequently today, and then expand the included application list over time.
In closing, I’ll note that I am not alone in thinking this is important to you. As I was writing this, I saw Rory Monahan’s article Automating Application Packaging and Patching – Rorymon.com that you can check out as well.
