Is User scoped installs on Windows still supported?

[byjrack]

Looking at the WIX I can see bits of the flow to handle a User install, but attempts to use the MSI Properties hasn't worked and the UI just pushes you into Admin/UAC based after the license prompt.

I get the privileged service wouldn't be available, but given it makes maintenance of the app in the environment far more complicated (our users can't complete a UAC) I wanted to toy with the tradeoffs.

If it's not available any longer well that's the answer, but wanted to make sure I was just not missing something.

[jandubois]

You are supposed to be able to install as a regular user, into your local app directory, and of course without getting the privileged helper.

@mook-as should give you a more definitive answer next week; I only ever do system-wide installation myself.

[byjrack]

Yup i don't know if WIX is picking up a remnant of an old install and skipping the prompt for User v Machine or something. It seems like you should if you accept the limitations and that is what i want to experiment with. Tried to clean up what I would expect would trigger that UI bypass, but no luck.

It's purely so auto-update will work as I am finding if folks install as Machine they stay on that old version because since they don't have UAC they need to jump through some hoops for admin. Wanted to test out the experience with a couple of the common use cases to see if the limitations are more hassle than just having folks swing through self-service workflows for an update.

[jandubois]

You won't be able to upgrade from a system install to a user install because part of the upgrade would have to remove the previous system install, which you can't as a regular user.

But you should be able to do a clean install as a user, and that version should be able to auto-upgrade to a newer user install. If that doesn't work, it is a bug (please file an issue).

[byjrack]

Yup i did an uninstall as admin and tried to look for any remnants in PF and HKLM, but was still not given the User/System dialog when running the MSI as User after. In all cases it prompted for UAC.

I am guessing WIX is checking some fingerprint i missed in the cleanup so it assumes it should do a machine scoped install. Good news is it should work if I can figure out what is triggering it to request UAC and follow the machine path.

[byjrack]

I think I am closing in on it as I found a machine that would give the option. I believe its tied to the WSLKERNELINSTALLED check. Based on the comments I think because there is no previous version it assumes it has to do the KERNEL which requires Admin. Now why I had one machine that did offer the option after uninstall is curious as you would think it would be consistent.

Trying to isolate that specific test to see why it sees it when run by one user, but not by another. I am leaning toward how WSL itself was installed so the user v machine installed list is generating a different outcome.

[jandubois]

I think we may soon switch to requiring a specific minimum WSL2 version from the Store, and no longer support or install the inbox version and kernel update.

That would resolve the issue for you too, wouldn't it?

[byjrack]

If the installer doesn't check I am guessing it would always ask for user vs machine so I guess so? Still trying to figure out the difference in the machines when it comes to the kernel package. Guessing it's the scope of the productid, but be nice to match works and doesn't work to the wix logic.

Tying to the store version should be fine and then check appx installs for presence.

[byjrack]

And best that I can gather trying to get beyond the blackbox of MSI

1. We start w 1C3DB5B6-65A5-4EBC-A5B9-2F2D6F665F48 which i grabbed from the WIX check
2. That becomes 6B5BD3C15A56CBE45A9BF2D2F666F584
   1. credit to https://stackoverflow.com/a/46607603 on how the Ids are stored in the registry
3. Which maps to HKEY_CLASSES_ROOT\Installer\UpgradeCodes\6B5BD3C15A56CBE45A9BF2D2F666F584
4. Which has a single value E752FE635D127F4448157029A3C864E5
5. Which maps to HKEY_CLASSES_ROOT\Installer\Products\E752FE635D127F4448157029A3C864E5
6. Which has a 32 DWORD Version value of 50a0010 (in my case)
7. Which I think is 05 0a 0010 which maps to what I see in win32_product of 5.10.16

So likely a custom check could be written on the old kernel model as well that works User and Machine.

Now on one machine that has the WSL 2.0 prerelease running and functioning I don't get a match for the kernel update package because it likely is all baked into that single AppX. So it gives a false negative and requires Admin in the UI.

And the change from wsl --status to --version is only an additional annoyance at how to do all these checks and validations objectively by parsing output.

Been dealing with a number of challenges with Store and especially the WSL install because of the interaction with Host Network Service as a User context so the chaos of os features, updates, store apps, etc. is giving me ptsd. 😅

[jandubois]

Just FYI there is some 🚧 work in #5600 that will hopefully deal with this in the future.

[byjrack]

Yeah our use of WSL is much broader than RD so good to know the abstractions will get better the inconsistencies and workarounds needed because of MSIX will plague us all for a while.

[byjrack]

Going to close this one out.

Yes they are still supported and if you don't get the prompt after the License acceptance than check your wsl kernel package status. wsl --status or --version depending on your wsl release. If the kernel was not installed or you are cutover to Store based completely than the installer may think there isn't a WSL kernel when there is. https://wslstorestorage.blob.core.windows.net/wslblob/wsl_update_x64.msi will need Admin though to install even if installing RD after can be done as User.

Move to making Store install the RD prereq and not just wsl/kernel package in the future should avoid this.