This is a common misconception (that Install
Aware doesn't build a
true native MSI package).
It does.Install
Aware'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 Install
Aware Native Code Setup
Engine, which broke free of any and all
MSI dependencies.
This, then further in time, evolved into Install
Aware 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-softwareThere's even more considerations when you're intending to support installations to the
System account. Install
Aware 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, Install
Aware 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.htmAnd that approach works perfectly, even for
Native Engine setups packaged without any
MSI payloads whatsoever!