Why does installer fail after removing elevated privilege requirement?

Question

I followed the instructions in this answer about making a setup.msi work for non-elevated users: https://stackoverflow.com/a/55700346/11860907

I have used these instructions for a different application with success.

When I run the .msi as it is, it requires admin permission to install but otherwise installs with no issue.

Here is the .bat file I ran to remove the admin permission prompt

"C:\Program Files (x86)\Windows Kits\10\bin\10.0.18362.0\x86\MsiInfo.exe" "C:\Users\jbrown\source\repos\Step File Generator\Step File Tool\Release\Step File Tool.msi" -w 10
pause

After I ran this bat and tried to install the msi, it continued past the part that usually asks for admin permission but then why do I get the following error?

The installer has encountered an unexpected error installing this package. This may indicate a problem with this package. The error code is 2920.

I researched this error code without helpful results. The following suggested I get an msi log: https://www.itninja.com/question/the-error-code-is-2920

When I try to run the msi through powershell with this command:

msiexec /l*v "H:\log.log" /i '.\Step File Tool.msi'

I get the following error:

This installation package could not be opened. Verify that the package exists and that you can access it, or contact the application vendor to verify that this is a valid Windows Installer package.

And the the following is the log output:

=== Verbose logging started: 12/11/2020  11:31:47  Build type: SHIP UNICODE 5.00.10011.00  Calling process: C:\WINDOWS\system32\msiexec.exe ===
MSI (c) (84:A0) [11:31:47:820]: Font created.  Charset: Req=0, Ret=0, Font: Req=MS Shell Dlg, Ret=MS Shell Dlg

MSI (c) (84:A0) [11:31:47:820]: Font created.  Charset: Req=0, Ret=0, Font: Req=MS Shell Dlg, Ret=MS Shell Dlg

MSI (c) (84:A0) [11:31:47:839]: Resetting cached policy values
MSI (c) (84:A0) [11:31:47:839]: Machine policy value 'Debug' is 0
MSI (c) (84:A0) [11:31:47:839]: ******* RunEngine:
           ******* Product: .\Step File Tool.msi
           ******* Action: 
           ******* CommandLine: **********
MSI (c) (84:A0) [11:31:47:841]: Machine policy value 'DisableUserInstalls' is 0
MSI (c) (84:A0) [11:31:47:884]: Note: 1: 1324 2: . 3: 1 
MSI (c) (84:A0) [11:31:47:884]: MainEngineThread is returning 2
=== Verbose logging stopped: 12/11/2020  11:31:47 ===

Does that MSI target per-machine folders inaccessible for normal users? Does it try to write to HKLM? Is this your own MSI or a third party MSI? I have never seen the use of Msiinfo.exe like that, but it does modify the Summary Information Stream (which is risky to do). — Stein Åsmul, Dec 11 '20 at 19:15
There is code in the program that changes a local environment variable: `Environment.SetEnvironmentVariable("UGII_LOAD_OPTIONS", location + @"\Resources\load_options.def", EnvironmentVariableTarget.User);` Would that write to HKLM? The program also writes to the local Temp dir. I can't think of any per-machine folders it tries to write to. — Jay Brown, Dec 11 '20 at 19:18
@SteinÅsmul Is there a different way you would suggest to modify my MSI or package it in a way that won't require elevated permissions? — Jay Brown, Dec 11 '20 at 19:23
How do you build the MSI? Is it your own MSI? There are many ways to approach this (transform, edit the MSI, repackage the files after an admin image, etc...) all depends. — Stein Åsmul, Dec 11 '20 at 19:27
It is my own MSI, built with visual studio with a basic "windows installer project" that I added my program's dependent files to. — Jay Brown, Dec 11 '20 at 19:30
I also just remembered that the program has a function to check if a dependent program is installed by searching the registry. Would that be something that is making it require admin privileges? — Jay Brown, Dec 11 '20 at 19:35
I have a silly little sample of per user setups using WiX here: https://github.com/glytzhkof/WiXPerUserSample - there is another one from someone else [here](https://github.com/deepak-rathi/Wix-Setup-Samples/blob/master/6.%20Wix%20Simple%20Setup%20Per%20User%20Installer/Wix%20Simple%20Setup%20PerUser%20Installer/Product.wxs) (not tried). You need to target per-user folders, not write to HKLM or HKCR, etc... There are many restrictions: https://www.advancedinstaller.com/user-guide/single-package.html — Stein Åsmul, Dec 11 '20 at 20:12
My ["WiX quick start and miscellaneous link collection here"](https://stackoverflow.com/a/25005864/129130). [List of MSI tools here](https://stackoverflow.com/a/50229840/129130). And the last you want: [some reasons to not use VS Installer projects](https://stackoverflow.com/a/47944893/129130). — Stein Åsmul, Dec 11 '20 at 20:15
I had it set private, now it should be there: https://github.com/glytzhkof/WiXPerUserSample — Stein Åsmul, Dec 11 '20 at 23:03

Stein Åsmul · Accepted Answer · 2020-12-12T21:30:46.073

Limited Per-User Setups: Per user setups must adhere to a number of restrictions: https://www.advancedinstaller.com/user-guide/single-package.html

I find it hard to deliver setups that work properly for both per-machine and per-user deployment scenarios. It has to do with the above restrictions conspiring on you. I would select one or the other (per-machine or per-user only - some more complexities here with per-machine setups that can hide shortcuts from other users).

Samples: Here are some per-user samples using WiX:

The core of making a limited privilege setup is to adhere to the limitations listed in the link above, and - if you are using WiX - to set the Package element appropriately (for other tools you need to set these parameters in the appropriate GUI - Summary Information Stream settings in the MSI):

<Package InstallerVersion="200" Compressed="yes" InstallScope="perUser" InstallPrivileges="limited" />

MSI Tools: Visual Studio Installer projects have many limitations. Some reasons not to use them.

Why does installer fail after removing elevated privilege requirement?

1 Answers1