Publishing MSI files - there's an anomaly that I am trying to understand

***Disclaimer: Publishing MSI packages will not be known to many here. In fact, apart from me and EE user Vadim Rapp, I can't remember seeing anyone here doing it ;-)
So if you are not perfectly familiar with publishing (no, it's not done per-machine), you will very probably know less about it than me, so please refrain from answering***

This "issue" is rather shared here to extend my knowledge than in order to solve a problem.
I downloaded Visio 2016 Viewer from here: https://download.microsoft.com/download/D/B/7/DB790874-4414-417F-ADF6-348B29572B9F/visioviewer_4339-1001_x86_en-us.exe
I extract the executable using 7-zip and get an MSI and a cab file and a EULA file.

If install that .msi manually, it works as expected. All users of the machine may open .vsd files.
If I publish that MSI file inside the user section of a GPO, users may install it on demand using ->appwiz.cpl ->install a program from the network and it works for them, too.
However, other users, like my administrative account cannot open .vsd files on the same machine where the user installed it, nor will visio viewer 2016 even show up in the list of installed programs. My admin user will have to open appwiz.cpl ->install programs from the network and install it again for it to work for him.

That was different with previous versions of the viewer which we used to deploy on demand as well (2007/2010). Before, the package was visible in appwiz.cpl's list and was usable by all users of that machine

Why is that? What is special about this very .msi that it behaves differently when installed manually versus installed using the GPO and the process via appwiz.cpl?
I'd simply like to learn.
LVL 63
McKnifeAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

MaheshArchitectCommented:
If you have published app, when user logs on and installs application, it will be installed for current user only

If application is assigned for users, it will be installed for every user automatically

actually what user application gpo does, it initialize application user specific registry and binaries for current user and make application available to that user and no changes are made in local computer specific registry
If another user logon, he must need to install / initialize published application, this is default behaviour unless you assigned application
otherwise it will defeat purpose of application publishing to users

If you assign app, it will get automatically installed for all users

The below document is self explanatory

https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc738858(v=ws.10)
McKnifeAuthor Commented:
Hi Mahesh:

I wrote, that I have done that before with a different MSI and it behaved differently. It worked for all users.
Cliff GaliherCommented:
This is not an issue with publishing as much as it is the "context" in which the MSI is installed.

Install packages can define a default behavior (per machine, per user are the common ones, but "custom actions" in the MSI can actually do others as well.)   But those defaults can be overridden.

Without downloading the viewer and actually inspecting it, it sounds like the viewer defaults to "per machine" so a manual install is doing a per-machine install.  This would be the same behavior if you used GPSI and were assigning software.

GPSI, specifically when publishing, overrides the default and if the MSI supports a "per-user" install, it'll install that way.  Chances are you could get this behavior manually using a command flag with msiexec (again, depends on the MSI) and you'd see the same behavior.  It may be that they didn't expose the behavior though and you'd have to use an MST to set the property (which is what GPSI does.)

Chrome is a good example of a program that also has this behavior.  If you run the chrome installer manually as a non-admin user, it'll want to escalate (UAC) to install per-machine, but it actually has custom-action logic to offer to install per-user if the permissions aren't granted to install per-machine.  All of that is bundled in the MSI itself.  Publishing simply pre-sets the property and skips that UAC promprt.

MSI custom actions are actually a bit of a problem for Microsoft now, and it is one of the things they want to get away from with the new MSIX format. But it does mean that each MSI you publish may behave differently and is not really a behavior of the "publish" action in GPSI as much as it is how the MSI reacts to the default properties that publishing sets.
Determine the Perfect Price for Your IT Services

Do you wonder if your IT business is truly profitable or if you should raise your prices? Learn how to calculate your overhead burden with our free interactive tool and use it to determine the right price for your IT services. Download your free eBook now!

McKnifeAuthor Commented:
Hi Cliff.

Where inside the MSI would I see how it will behave?
If I open that MSI in for example Orca, I see the property "Allusers" with a value of "1". So that can't be it.
I am trying to learn where to look, since it will be somewhere.
McKnifeAuthor Commented:
Wait... gotta read https://docs.microsoft.com/en-us/windows/desktop/msi/allusers a little closer since the behavior is different for different OS'/Windows installer versions. That seems to be it.
McKnifeAuthor Commented:
Hm. read and understood. Nevertheless, I see no difference to other packages, when it comes to MSI properties. Changing the properties mentioned and re-publishing has no effect at all.
So it seems, it depends on how "the package has been authored" acccording to https://docs.microsoft.com/en-us/windows/desktop/msi/msiinstallperuser - unfortunately, I don't know a way for me to determine that.

Well, I could stop here and simply test future packages for different users (as we normally do, anyway), so I will know for sure how it behaves.

By now, I have tried several MSI packages (old visio viewer 2010 and the current 7-zip 18.06) and to my surprise, both install per-user, no matter who opens appwiz.cpl - so maybe this has been different in earlier versions of windows? I am not sure when the behavior was different, although I am sure it was. Oh well... :-)

Final thoughts, anyone?
McKnifeAuthor Commented:
I took one last surviving win7 machine that we have here and guess what, it had visio 2010 installed using the on demand method via appwiz.cpl - and it was indeed installed and usable per machine.

This win7 was upgraded from vista. So although this is a win7 machine, I am sure that visio 2010 viewer was installed when it was on vista, already. Vista comes with windows installer in version 4/4.5 depending on the service pack, while win7 already has v5 onboard.

Conclusion (could be): the behavior changed with windows installer 5 and 5 respects flags that 4.x does not respect, so 5 will install per-user unless the package is setup to force per-machine-installations, even when installing via appwiz.cpl.

Do you agree with that theory?
McKnifeAuthor Commented:
Ok, I think I am a little wiser now and ready to close this.

I tested on a 2008 ("R1") server, which runs windows installer 4.5, which showed the same behavior as windows installer 5.0, so I will conclude that what I remembered to happen (for example visio viewer 2010 being usable for all users after one user installed it via appwiz.cpl) was maybe not even happening after all but was wrongly remembered.

So what I see here is:
-appwiz behaves the same for all packages I have here, no matter if the user is admin or not
-appwiz never asks for credentials no matter what package is used (tried current versions of chrome enterprise, visio viewer, 7-zip)
-the applications are always installed into the programs files directory, so never in user locations like %appdata%
-context menu entries are created only for the user that used appwiz
-file associations for visio are only created for the user that used appwiz
-uninstall entries in appwiz only exist for the user who used appwiz

So the suggestions were somewhat helpful and made me distrust my own memory (thanks ;-), but first of all, the question itself was not correct.
McKnifeAuthor Commented:
See above

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Installation

From novice to tech pro — start learning today.