Microsoft Intune Support

[BartWilson]

We are finding one of our product MSI packages that we've built will not install in a Microsoft Intune deployment. Is there any documentation on things that need to be set in InstallAware project files to help this work? We've found that if the msi is edited with ORCA and then we uncheck the "UAC Compliant" in the System Information along with adding a "ALLUSERS" with a value of "2" in the properties that the installation will work. I haven't found anything in the InstallAware project file that points me at changes I can make at the project level or in the MSI code.

After reading the UAC Forum post I'm wondering if the option we are using is causing us issues here. Was just curious what others experiences are here and any suggestions.

[FrancescoT]

For what I know, deployment on InTune it should not differ as when deploying a setup package on the latest Windows versions.

I can understand that the "ALLUSERS" property needs to be set to 1 or 2 (PER-MACHINE installation - If the value of the ALLUSERS property is set to 2, the Windows Installer always resets the value of the ALLUSERS property to 1 and performs a per-machine installation). I find strange instead, that the "UAC Compliant" setting is not needed or required by InTune.

Are you sure it's not enough just to set the ALLUSERS property?

For what concerns the ALLUSERS property, this can also be set via MSI script.

Code: Select all

Set Variable ALLUSERS to TRUE

Btw, the same can be also done with invoking the MSI package from command line:

Code: Select all

> setup.msi CMDLINE="ALLUSERS=TRUE"

Or by injecting command line parameters into the MSI using the "Group Policy Wizard" tool (included with IA - This wizard creates a single MSI file that may be used in corporate deployment scenarios).

For what concerns the the "UAC Compliant" setting, this cannot be changed at project level (this due the fact that such setting is MANDATORY from Windows Vista and higher versions). At any rate, doing some researches, the "UAC Compliant" setting should be controlled by the "MSIDEPLOYMENTCOMPLIANT" property.
https://docs.microsoft.com/en-us/windows/win32/msi/msideploymentcompliant

You may try with passing "MSIDEPLOYMENTCOMPLIANT=0" from command line, or you may inject it through the "Group Policy Wizard" tool.

GrpWizard.png (25.96 KiB) Viewed 12359 times

[BartWilson]

Thanks for the notes.

In regards to the UAC Compliant option, this was found along with the ALLUSERS=2 property during testing of our MSI on Intune. I'm not sure where the tester found the information to set both of these options.

I've been curious if we've used the wrong project template to support the installation on Intune also. I had created this new project by copying from an older project and now I'm wondering if we should start from scratch. That is another reason I posed in the forum to see if anyone else has experience in understanding what is needed for Intune.

I'm working on the Installers for our products as best I can given it isn't my primary role in the company but I seem to be the one with the most experience working with Windows Installers.

[FrancescoT]

As I previously said, at far as I know, deploying on InTune it should not differ as when deploying a setup package on the latest Windows versions.

I'm not sure how you cloned your project. If you are using x13 or higher versions, the currently active project can be easily cloned using the integrated "Clone Project Wizard" tool.

clone_wizard.png (25.41 KiB) Viewed 12343 times

Alternatively if you prefer to create a new project from scratch, you may generate it from the "Basic Setup" project template.

prj_templates.png (27.3 KiB) Viewed 12343 times

Hope this helps you.

[BartWilson]

Thanks again for the reply. We tried an installation with the command line options you mentioned and it didn't install through the MS Intune (<msi file> CMDLINE=”MSIDEPLOYMENTCOMPLIANT=0 ALLUSERS=TRUE”).

I may give it a try to create a project from scratch and pass that onto the person testing the installations in MS Intune.

One curious question here is that the person testing claims that the MSI that I provide him appears to be a wrapper around having another MSI embedded in it. To me I'm not sure how that would work but I do kind of see that given we provide the application runtime dependencies with our installations also. Could the application runtimes be causing an issue?

[FrancescoT]

I don't think that the application runtimes my be at root of the issue. At least it should not.
At any rate, you may do a quick test with removing such dependency.

[BartWilson]

We are still trying to figure this out. Our Microsoft Intune tech has been able to make other MSI packages work (non-company), just not the MSI that I've worked on. We've run tests where we find manual installations on the same system after everything is configured works, just not through Intune.

I'm curious if there are paid support resources in InstallAware that have worked with Intune that could provide more insight here. I can see that we can pay for consulting and/or add in Gold support (can we do so after license purchase?). Since I'm not an expert at MS Intune or InstallAware I'm just trying to find something.

[BartWilson]

Earlier this year I discovered that indeed creating a .msi package from InstallAware was causing some of the issues with Intune. This is because the .msi is a wrapper around the .exe which in itself wraps around another .exe/.msi pair. I found that if I add the ALLUSERS=true to the top of the MSICode in the project and only build a .exe installer, that I can then follow the MS Intune process to turn the "Win32app" into an Intune package (https://docs.microsoft.com/en-us/mem/in ... 32-prepare) I seem to have better luck with the whole process.

I guess this does pose the question, does InstallAware support building a true native .msi that isn't a wrapper around another .exe that wraps around an .exe/.msi? I've seen these .exe/.msi packages while working on adding it Pre-Compress and Post-Compress Events to the application if those events fail.

[JohnGaver]

This is a common misconception (that InstallAware doesn't build a true native MSI package).

It does.

InstallAware's own setup engine (the .EXE file) bootstraps this pure MSI, extending Windows Installer's default behavior by removing the straitjacket it normally comes bundled with

This setup engine over time evolved into the InstallAware Native Code Setup Engine, which broke free of any and all MSI dependencies.

This, then further in time, evolved into InstallAware Multi Platform - which is, basically, the Native Engine ported to run on Linux, macOS, and back-ported to Windows again!

So yes, unless you're using Native Engine setups and/or disabling MSI generation as part of your build process, you're already Windows Installer based (or bound, depending on how you look at it).

The Group Policy Wizard really is only intended to work around deployment platforms unable to accept .EXE bootstrappers for whatever reason.

It's not meant to "trojan horse" random EXE packages through Active Directory, for example - because it still talks to your deployment packager in a manner that it would understand, and passing on whatever the deployment manager is trying to do to the actual MSI located underneath it all.

The fact that you have success with ALLUSERS=TRUE is also interesting to note.

I don't know if this means the Microsoft Intune import process cannot understand packages that are installed only for the current user, versus packages installed for all users. This changes things like shortcut locations, for example - so the Microsoft Intune import app could just be buggy, or may have even made well-founded assumptions for whatever their reasons, regarding the installation mode of your app.

It's easy to see you'd have problems with Group Policy deployments when ALLUSERS=FALSE for example, and the package is actually being pushed out for the computer at large. Please see the section on assignment to computers below:

https://learn.microsoft.com/en-us/troub ... l-software

There's even more considerations when you're intending to support installations to the System account. InstallAware has been made as easy to use with respect to all of the preceding (ex: patches to the core product so it works when certain user-only folders cannot be found during System account installations), but there's only so much abstraction you can build into a product to isolate the developers using it when third party endpoints have moving parts which defy those abstractions.

Last but not least, InstallAware Direct Deploy may be an interesting read, whereby you could just directly push out your packages natively through Active Directory, without any intermediary third party deployment manager such as Group Policy:

www.installaware.com/direct-deploy.htm

And that approach works perfectly, even for Native Engine setups packaged without any MSI payloads whatsoever!

[BartWilson]

Thanks for the information John. Honestly with the limited understanding of the Microsoft Intune stuff I may have missed some information. I did find that I could not plug into the Intune use the built .msi like other .msi packages. As mentioned in my earlier post I built an .exe instead and followed the https://docs.microsoft.com/en-us/mem/in ... 32-prepare process to create a "32bit" application to install through Intune which seemed to work. Since this work was almost 2 years ago, it is unknown if I could have used the .msi built item at that point given I didn't try. I do know that we are still looking at Intune support but hopefully I can find someone eventually that has the knowledge to help out with that application.

[BartWilson]

As a follow on to my original post of trying to get things to work, I found that you must set the ALLUSERS variable to true at in the MSIcode to help when doing an Intune package. Then you can use the apps-win32-prepare tool to create a intune based package. The Intune application must be a Win32 package as trying to use a native MSI never worked for my testing.

I found that working in Intune that how you check to see if something is installed was better to look at the versioning of the main .exe of the application being installed than the MSI ID because in we have products where any installation of a new product will remove the previous and install the new one. Thus if you are trying to make sure an upgrade downgrade works, having the version in the .exe helped us.

The Intune prep tool, doing an Win32 package, and how you check for something being installed were the biggest issues I had over two years ago. We now have a process to install packages through Intune and have other packages Supersede ones already installed.