In years gone past, I built an automated packaging tool to take a dump of packages from SCCM and convert them one by one to App-V. It worked ok for some apps but left a lot to be desired. Like many others, I also tried other 3rd party products like Automated Application Converter from Flexera but found I had a relatively low success rate due to the way they handled converting the apps to App-V and ThinApp.
What I found through experience is that you can’t substitute the old manual packaging of applications with a programmatic alternative. There are just too many different variables to consider since vendors do not follow best practices with their installers BUT the good news is, I found a much better solution and it’s a lot more straight forward and technically accessible to the masses than traditional scripting, which not everyone enjoys.
RPAS
Robotic Process Automation products like Microsoft’s Power Automate and Automai for example provide the ability to automate workflows exactly as they are. You simply click record then carry out your workflow, when complete click stop and that is your automation script created. When you run that script in future, the robot repeat the steps exactly as you did when you manually carried them out.
It is not running PowerShell cmdlets, Python scripts or anything like that…though, if you would like the Robots to run scripts like that, they can. This is because rather than relying on scripted functions, the RPAs rely only on the sequential steps of the workflow using the recorded screenshots and recorded inputs such as mouse clicks and keystrokes. If you know how to how to complete a workflow then you can easily automate that workflow with an RPA. I am excited that Microsoft have released a free product to the market BUT it is very limited if you don’t pay for the premium version. Frankly, when comparing products, I believe Automai is more feature rich and mature so for this blog post, I will be using Automai as my point of reference and for my demos.
Thought Process
When deciding to try this for packaging there were a few things I wanted to ensure. I wanted to design it in such a way that I avoided duplication of effort as much as possible and potentially to make it so simple that an Application Owner may use ScenarioBuilder for creating their Install Instructions and Test Instructions instead of supplying this in Word. (If you have never worked in app delivery for large organizations or as part of a packaging factory, it is common to have set install instructions and test instructions with all packaging requests.)
All 3rd party products I have used for converting apps usually only focused on the likes of App-V and ThinApp. Nowadays, MSIX and MSIX App Attach gain some focus for support but other products like Liquidware FlexApp and Numecent Cloudpaging are not accounted for. That is a shame. For my automation, I wanted to make it easily interchangeable between all products.
The How
To do this, I just put the product specific steps in Global Scenarios. Global Scenarios can be played within any of your Process Scenarios within your project so you may re-use them as often as you like. When creating a Process Scenario for an application, I simply play the Global Scenario steps sequentially as it makes sense. For my workflows I also used a CSV file with a list of my package names and descriptions. This worked out very well is that the App-V Sequencer, Cloudpaging Studio and MSIX Packaging Tool really only needed those two fields. I used the name for the Package Name and when saving the packaging output and all tools had a Description Field. Since MSIX Packaging Tool now auto-populates the Publisher Name field via the code signing cert properties, it made it a perfect fit. The scenarios reference the CSV to populate these names as using variables e.g. %NAME%.
When the packaging tool of choice is ready to monitor the installation, my Process Scenario executes the script with the unique steps for that app but again these steps are in a Global Scenario so I may have a Process Scenario to create a package for that app in Cloudpaging and another Process Scenario to create the app in App-V or MSIX but each is using some of the same scripts to avoid duplication of effort. When complete, the final global script runs to copy the completed package off and to return the VM to the pristine state.
The way I created my scripts, If there hasn’t been a big change to the vendor’s installer, I can re-use the same Process Scenarios when a new version of the same app needs to be packaged. I simply just have an RPA or script that copies the latest installer to my source location and have Automai execute the workflow running the Process Scenario via the AWPlayer.exe on a set schedule or I could simply use Automai’s AppVerify tool to manage the schedule centrally. I can also ensure it only runs IF a new version has been detected.
As a Packager what I like about this is that if there is an application that is a little tricky, I can figure it out and record the steps needed to get it to work.
Essentially, I could put the up front effort on an App Owner or Junior Tech to just record the steps required to install and configure the app. If there is some nuance or technical challenges beyond their skillsets, I can do it instead. For me, it’s not a big ask to do this. Where I have worked as part of the app packaging process there has been an Application Package Intake process that included Install Instruction and Test Instructions, so that is not a new ask. Also, I always create a recipe of how I packaged the app too…so the documentation has always happened but now the recording of those steps IS the bulk of the human effort here. The Robot does the rest.
Automated App Packaging Factory with Automai from Rory Monaghan on Vimeo.
I can understand, if you are not familiar with the terminology, it may be confusing. I suggest watching the video to get an idea of how it works.
Likewise, if you would like to learn the terminology and some general tips and how to get started with Automai, you can check out the video above via the hyperlink above.
Updated: I added this brief demo showing how I have integrated the new Windows Package Manager into the automation process.
Conclusion
RPAs open up automation to those who are not strong coders. It also adds an extra tool to every IT Pro’s toolbelt, even those who ARE strong coders. The fact is, not everything can be scripted and even some things that can be scripted require too much effort to do so and it acts as a deterrent from even trying. Automai makes the difficult simple and enables you to automate pretty much anything you can imagine including application packaging and delivery. Numecent Cloudpaging can successfully package and deliver any application (at least in my experience and those I have talked to in the Cloudpaging User Group). With Automai and Cloudpaging together, I’m thinking that I should be able to automate all Application Packaging. If I wanted to, I could possibly combine things. I could have the Robot attempt MSIX first and then On-Failure when testing or if a failure is detected during the packaging workflow, I can set the robot to alert me that the workflow failed and have it automatically output the app in Cloudpaging instead. The possibilities are endless!
Photos by NeONBRAND and Possessed Photography
