Windows Software Deployment

Windows software installers have not changed much since the days of XP, much software is distributed as a .exe which then contains a self extracting installer for putting file into the appropriate place and adding registry entries etc. The .msi file format brought some standardisation, and now with Intune, there is a new format, the intunewin.

The intunewin format is a container format for the files for the software installer, which is created by the packager, and is then encrypted and signed by Intune with a certificate that can be verified by an endpoint that has joined to the O365 tenant. There is an install and and uninstall command that needs to be set for the intunewin file in Intune for the actual deployment.

There are many blog posts across the Internet that cover the installation of specific applications that they have had issues packaging for Intune, frequently using an install.cmd to perform tasks that are not able to be set as a command line option. For one application that I recently packaged, I created an install.cmd that deployed two firewall rules before then installing the software with a msiexec /i etc. Without these firewall rules in place, on first running of the application, a Firewall popup (that a user is not able to accept) woudl occur, and the applicatio n would not function correctly. The application vendor a/ does not support Intune, and b/ suggests that installs should be performed by an Administrator. With the rise of MDM for managing endpoints, Application vendors need to start packaging their Windows software with a similar mindset to creating IOS/Android software, everything packaged in a simple to deploy  manner that can deployed with modern deployment methods.