In the last couple of blogs I’ve been showing you how to automatically build Win32Apps for Intune. If you’ve played with the script from my post Windows 365 – Building an Automated Win32App Factory using Evergreen, PMPC and WinGet you’ve probably noticed that in just a few weeks a lot of new versions have been released.
Creating these applications are more or less straight forward as long as you have a well architected application delivery plan. As I mentioned in the post, it was just a PoC and no further thoughts where spent on it. However over the holiday weekends, I started to deep dive to figure out a way to update existing user based installed applications (Available for enrolled devices).
In the perfect world you would use AD / AAD groups and Required Assignments, but the world is not always perfect. In many cases you want to make an application available to everyone that might want to install it, think AppStore. In this post I’m going to show you the solution I came up with and the issues I needed to fix in the first version of the PoC.
Detection Rule(s) in SCCM / Intune is used to determine if the application was installed correctly and / or checking if the application is already installed. The first issue I discovered was that 7-Zip changes their MSI Product code, so if someone installed 7-Zip 21.06, and then later installed 7-Zip 21.07, then 7-Zip 21.06 would report “The application was not detected after installation completed”. Literally blowing up your deployment statistics.
Another issue from a user experience standpoint, is that the Company Portal will be filling up with the same application, just with different version numbers. The resolution to that is to us Supersedence. By using Supersedence, the Company Portal will only present the latest version to the users. I’ve not been able to do this automatically yet, so for now it’s a manual action. I’ve told you many times before, if you want the perfect solution go buy yourself PathMyPC. Trust me, it’s worth every cent!
The first draft I had in my script, was just using install path + uninstaller, but normally the version number hardly changes for the uninstaller itself. Therefore I added a new section in the XML file called DetectionFile. That way I can check the version number on the executable itself to determine if an upgrade is needed (Required).
PatchMyPC already wrote a great blog post explaining the details here The Challenges We Encountered Developing Third-Party Patch Management in Microsoft Intune
The way we are implementing third-party patching in Microsoft Intune is to have two separate Win32 applications for each product. One of the Win32 applications will be designed for initial deployments. The update version of the Win32 application will be designed only to be required when an outdated version is detected.
So that’s what I did. I created a new script that creates the applications (Available for enrolled devices) and an Update version (Required) which meets the Requirement Rule with version number less than the new application version.
Please be aware that Paint.NET have a file version number of 4.307.8039.30451 which doesn’t work because it’s not less than 4.3.7 (it’s actually greater than).
So what happens behind the scene, is that the Intune Management Extension will check the version number because the Update package is assigned as a Required Installation.
As I mentioned above, there’s lots of new releases, currently we have 17 applications enabled and 9 updates has been released in less than a 2 weeks!
My good friend CTP Aaron Parker (the mastermind behind the Evergreen Module) said it best in his latest blog post Hosting a Patch My PC Publisher server in Microsoft Azure.
Deploying and managing Windows PCs, Azure Virtual Desktop, and Windows 365 etc., requires that applications are kept current to protect an organization from malware and attackers. Most organizations will fail to achieve this goal if they are manually packaging and updating applications – today’s application environment moves far too quickly to keep pace. A solution to automatically package applications is part of the answer.
Now, if I buy PathMyPC will that cure all my problems? No, as of today there is no support for private repo’s so the content that I’m sharing will apply to everyone that also supports licensed Line of Business applications like Adobe, Autodesk, SAP and others. In an upcoming post I’ll show you how to automatically build Win32Apps for Intune using a private repo or static URL.
You can find the new code on my Github repo. And that’s it.