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.
Here’s some more information about the public preview for Win32 app deployment.
And the video from Ignite: https://myignite.techcommunity.microsoft.com/sessions/64593?source=sessions#ignite-html-anchor
For those of you adding additional suggestions in the comments, please create them as new suggestions. When Win32 app deployment comes out of public preview, we’ll call this one complete and I don’t want your requests to get lost!
Thanks again for your support!
It would be nice to see the ability to add dependencies. We have several apps that require additional files (e.g. reg, xml, ini) to install.
Marissa Van Opens commented
The ability to add MSTs to LOB msi's would be a welcomed edition.
Hi everyone, glad to see this feature being extended into Intune.
Question -- seems like this assumes the admin already has some experience with SCCM and Transforms, and needs that experience for preparing the installation package. I was hoping that once this feature got implemented it would automate some of that for you, but seems not. Am I wrong?
Anyone have a good tutorial or set of documentation for the preparation steps? Looking for something that provides reliable/trustworthy information on "what's being done" and not just how to do it.
I've been testing this for a couple of days now and so far the results work great. I have found one bug, which once the application is installed successfully, if the user clicks the option to "Reinstall" the application, the state of the application from Company Portal will remain "Download Pending" indefinitely. PC and service restarts have no effect. The logs seem to indicate the action was taken, but the state of the application simply never changes from "Download Pending".
The only solution I've found so far is to manually uninstall the application, and the Intune client will then install the application and change the state as it should.
Peter Löfgren commented
Something that is dearly missing is the ability to test this quickly. This includes the ability to test the complete chain using the .intunewin file butwithout uploading the file to intune and waiting for policy sync.
Something like "Test-Intuneapplication -Path <path to intunewin file> -Command "setup.exe /s /norestart"
John Jones commented
Cathy great start with adding the Win32 deployment type. It’s been long awaited.
If possible, we would also like to see the introduction of some of the maturity we currently enjoy with the SCCM product. Such as, the ability to define and add dependencies, to Supersede applications and the ability to automate the complete setup of a packaged app in Intune, ready for deployment testing.
It would also be great if we could see some improvements made to the “Intune Win32 App Packaging Tool”. The first one would be to change the name and get rid of the term Packaging because it isn’t a packaging tool 😊.
On a more serious note, If the tool and the resulting payload could accommodate the following it would be much appreciated:
Ability to specify
• Custom name for the application
• Custom command lines for install and uninstall (basic ones aren’t usually used)
• Custom detection methods
Unfortunately, this is tied to the Intune Management Extension, which in turn requires AzureAD Join. So devices that are MDM only joined (literally all 9K of our Win 10 devices) are SOL. They need to look at removing this requirement somehow, if I can deploy MSI's to the devices', why is it so difficult to deploy Win32 apps to them without AzureAD joining?
Public previews coming soon.
Do we have any kind of ETA on the availability of this feature? I know this is early but would like to get a rough idea now that this now being started.
Devon Edwards commented
yay! excited for the ability to use .exe now
Devon Edwards commented
Leroy D'Souza commented
I'm currently uploading install files to blob storage and executes them via Powershell as a workaround.. Would like it to be possible to publish powershell based applications to company portal.
Microsoft need to add a feature which will allow .EXE file extensions to be added into the Azure portal.
Rob de Roos commented
Microsoft is developing MSIX. I think that is what will become a solution for this issue. Only time will tell.
Could we please get some feedback on this request? We're forced to use PowerShell combined with other solutions or package our own MSI files to support deploying the necessary applications for our environment.
Noor A. commented
As the most top idea/suggestion/need from customers pending for 2 years now, its clearly MS have no intention to resolve this issue, I'm adding my vote and 2 cents hoping this will change
Business small/large, have tons of in house built-in apps in addition to those standard that allow customization (ex adobe with transform file), without have a proper way to deploy and manage application life cycle, MDM management becomes a feature for only managing MS product and settings, we hear a lot about vendors talking to each other to provide better services to customers yet we need to see an outcome, this idea was submitted 12/2016, how much longer it takes MS to acknowledge it!
Janne Boman commented
+ 1 for this. We are a fairly large ~2000 employee company. We got a fresh start when our company was actually carved out from a larger enterprise. This gave IT the possibility to go for a "clean slate approach", including an evergreen strategy where we generally use the latest versions of pretty much everything with a cloud-first thinking. This meant that we will never ever deploy SCCM. Great, but now I face the challenge to deploy +2gb SW installations (design software, etc...) and this with Intune is... well, not possible. I would really like to see MS supporting more this kind of setups, after all, if the cloud is the hype then please also "walk the talk..."
What they should do is allow you to hook in a package feed as if it were an app store and assign the exact same way you do other mobile apps. Wrap your packages into an Intune compliant format, create a repository, then hook your repo into Intune. Maybe move toward having a built-in Intune repo. Basically do what Chocolatey is trying to do so you can side-step support every installer's requirements. It works better over all even if there is some more work in developing your packages (usually not much more).