Extend MDM MSI deployment
I would like the MDM MSI deployment (to MDM enrolled Win8.1+ clients) to be extended. Currently, only single MSI's are supported, I'd like this to include MSI's with .cab's, MSP files to patch installed MSI apps, and to be able to deploy .exe installers.
Douglas Plumley commented
Support for .exe installers is a must, there just needs to be more flexibility in deploying apps, period.
Ben Reader commented
It's absolutely mind boggling that this isn't part of Intune.
Unfortunately most businesses / organisations do not live in the dream world that we all wish existed - most have legacy software or applications that do not provide single file MSI installation media.
Without the ability to deploy multi file install media or non MSI media, Intune is all but useless for a large swathe of the corporate market.
We need to be able to configure our own detection methods, point to installation media folders and use the tried and true method of scripted installation (powershell / exe / msi all need to be available)
Robbie De Sutter commented
Powershell script is not (yet?) a work around / solution as that currently only support devices that are AAD only registered. It does not work on the hybrid domain-joined + AAD joined.
So for us: either extend MDM MSI deployment as this suggestion, or allow powershell scripts to be used with Hybrid Joined devices (as suggested here: https://microsoftintune.uservoice.com/forums/291681-ideas/suggestions/32916943-allow-powershell-scripts-to-be-used-with-hybrid-jo)... and preferably, both options :)
@ON: I'm not sure where you're seeing that the IME PoSh script is only executed at enrollment time. As best I can tell, it is a "run until succeeded" mechanism that you can deploy to any system that is already enrolled.
Furthermore, MSI apps are not only installed at enrollment time, you can deploy MSI apps to systems anytime you want (subject to a short propagation delay, in my experience it's been around 30 minutes or less).
I think your scenario of "app vulnerability" is sufficiently remedied by simply uploading a new MSI and pushing that to enrolled devices, no need to bother the user at all....
If you're seeing something different then we are having completely different experiences.
@JB : the problem with Intune Management Extension/PowerShell script is (at time of writing), that you cannot trigger them centrally when you want : the scripts are only triggered at enrollment, so if there is a new version of the MSI you want to deploy on top of existing one, Powershell scripts will not really help you.
Example : let's say you have your own MSI LoB app in Intune, that was installed on all your machines , and you must push in emergency a new version to your employees, because of a security flaw in that app. Then would you ask all your employees to un-enroll and re-enroll their machines, just because you want a new version of an app be installed through your PowerShell configuration scripts? Unrealistic :-).
We need a better mechanism, to "reset" the installation history of a specific MSI file/LoB app, to take into account "emergency app pushes". The software inventory being made every 7 days, is also an unrealistic approach : would you wait 7 days maximum to perform automatic inventory upload, to have all your devices patched? The devices might be "hacked" during that 7 days period of time, and your only option is to...be patient.
Folks, see my comment from Nov. 7 regarding the Intune Management Extension.
I do wish expanded MSI and EXE deployment capabilities were provided directly in Intune; however, it looks like now that we have remote PowerShell scripting capabilities all of this should be possible thru this avenue. We would have to do a little development of course, so I would still prefer direct integration into the Azure Intune UI; but if anyone has critical needs right now, along with some PoSh development skills in-house, please check out the IME and perhaps report back here on your experiences if you can help out the rest of the community.
Sami Ojala commented
Really important feature, single msi is not enough!!!
+1. Needed absolutely ASAP!
Alphacom Finland commented
We would also need support for .exe packages.
Currently we are using 'legacy' silverlight intune portal where .exe packages are supported. We have done lot of development & functionalities inside the .exe packages... Any estimates/road map for .exe support are very much appreciated.
+1, and another feature I think is missing is the ability to deploy a file or set of files alongside a software installation. This feature was available in the Classic portal (include files/folders), but is no longer present in the Azure portal.
That said, I came across the Intune Management Extension the other day and it seems that this feature will be rolling to Prod in the near future?
This may solve a lot of these problems for us, if we can do a little scripting to close the gaps. Am I wrong?
Morten Schaumann commented
@Thomas Kurth - thank you for sharing your information. I will look into that.
We have done some testing utilizing the 'Desktop Bridge' provided by Microsoft, transforming elder software including subfolders to .appx applications. From there we add the applications to the Windows Business Store and distribute via Intune.
Works fine so far. But we have only tested a number of software packages. There might be problems with very old or complicated setup configurations.
So far so good... :-)
I do think this will be the official answer from Microsoft at some point. But that is my take and not an official statement.
Thomas Kurth commented
We had the same issues in our Intune Projects, therefore we created a solution on Syntaro which gives us the needed features like (multi file, other executables, BranchCache and Chaining of Packages) for Intune.
Perhaps it helps you to realise more projects with Intune.
Steve Crookston commented
WE can push out apps that .msi but not .exe
Rob de Roos commented
When customers want a new windows 10 based solution with azure ad joined devices. Software deployment is the biggest problem we experience. Customers are too small to use SCCM. And the Intune Agent is also not an option because of the lack of policies that can be used when using that agent. This is a realy big showstopper in most projects.
+1 for Multiple file MSI installs, and to support EXE (Powershell scripts would be awesome)
If you look at the MDM competitors for other desktop platforms (like "Jamf Pro" for Macs), they offer to install multiple "packages" (in their case PKG files) in one "policy rule", or multiple bash shell scripts, which can in turn, trigger manually other "policy rules".
This offer a chain of actions, that are well-controled by the MDM/scripting IT admins.
Aaron Marks commented
Please allow us to deploy software to MDM enrolled Windows 10 computers with the same controls that are available to deploying software to SCCM enrolled PCs. In the field/real-world this feels like the most valuable features Intune could implement.
I would like MDM MSI and Intune client support chained package, one MSI with multiple MSI packages inside. I have some prerequisite MSI packages (VC++2017 Redistributable) need to be installed after the main package.
Justin Howard commented
This is something that is proving very problematic for us as we are essentially unable to deploy updated versions of software at the moment as we cannot deploy .exe's or an .Msi with multiple files like CABs or certificates.
I too would like this feature - but until then I have developed a work around that will allow me to deploy complex MSI packages, EXE based installations and even execute PowerShell scripts (in system context). I create a PowerShell wrapper script to do what I want - Install MSI with MSP, install EXE file etc. and then convert that to a .EXE.... Then I use an MSI creation tool to create a single MSI with all required files and to execute the .EXE version of my PowerShell script..... It all works well, but there are some issues that prevent wider scale adoption. Each package is listed twice in Add/Remove Programs (once for the Installer wrapper I create and once for the actual application that gets installed) and InTune only monitors the Installer Wrapper to determine if an app is still installed. - Nearly there, but not quite
Alan Dooley commented
A good example of where this is a problem. Microsoft Visual C++ redistributables. All of these are provided in .exe. I've got a number of .msi packages which need visual C++ install first. I cannot do this with the MDM approach.