Open benkehoe opened 1 year ago
wsl --install
command enables some core components of Windows OS with DISM APIs. It does require administrator privileges. Though you can enable WSL feature as admin and install Linux distributions in WSL as normal user (assuming that the install path has r/w permission to that user).
Right, I'm not expecting not to get prompted for elevated privileges, I'm expecting that the privilege elevation prompt happens in the session where I'm trying to install WSL. Or, that it simply fails. But what's happening is that a privilege escalation prompt is appearing in a different user's (the admin's) session, and no indication that this is happening is given in the session where the install is being attempted.
@benkehoe - the second elevation prompt (and the problematic one) is one for "Host Process for Windows Services"? Right?
Is the behavior of wsl.exe --install different than something else that prompts for elevation, say regedit.exe?
Yes, that's the one, "Host Process for Windows Services". I have never seen or heard of an elevation prompt appearing in a different user's session for anything. Any tool that prompts multiple times, it's always in the same session as where the tool is running, even when using a different user's credentials to approve the escalation.
Yah agreed, it's not ideal (the second prompt really shouldn't be needed). That one is coming from the app platform when installing the WSL msix package. We've filed a bug on them to not pop that dialog if the calling process is already elevated. I'll check on the status of that.
@benhillis any update on this? I hit it today because wsl --install runs as part of my bootstrap script for setting up a new PC. I kick off that script from elevated PS, but wsl --install still throws a Host Process for Windows Services UAC prompt. That blocks script execution since it's waiting for you to answer the UAC prompt (which it has no reason to be throwing since it's all running from elevated PS already).
This was on a fully patched Win11 22H2 22621.1265 install.
Any updates here? I am encountering this when running the install from the MS Store, from a non-elevated command prompt, and from an elevated command prompt. Problem is that it's a corporate machine and I do not have the credentials for the admin user the UAC prompt is for.
Any solution to avoid this UAC for "Host Process for Windows Services"?
We want to install WSL for our users using MECM (SCCM) but this UAC makes it impossible for users that do not have an admin account.
Adding my name to the pile on trying to use "wsl --update" after WSL OS is installed and reboots completed, but the HPWS popup makes that a non-starter
@benhillis is that bug on a public tracker we can link here? And if the process is not elevated is there a way to suppress that integration in the WSL MSIX? Guessing its to do with the systemd/init work?
With the release of 2.0 in the Store I definitely got a storm of folks doing updates via the UI or via the command and all had the UAC issue which led to 80240066 errors when they had to cancel out.
The MSI release seems to be fine to run background, but we would much rather give the user the ability to use the existing channel.
I ran into this too. What worked for me after I determined I could install wsl from admin powershell was to install sudo on my non-elevated powershell and run sudo wsl --install
These were the steps I took.
Set the Execution policy as “RemoteSigned” and restrict its scope to only “CurrentUser”. This operation will permit the current user to run both local and downloaded scripts:
Step 1: Set Execution Policy
Set-ExecutionPolicy RemoteSigned -Scope CurrentUser
Step 2: Install scoop
irm get.scoop.sh | iex
Step 3: Install Sudo
scoop install sudo
Step 4: Verify Sudo
sudo
Step 5: Install WSL with Sudo
sudo wsl --install
Any news on this UAC issue to be able to install WSL in the OSD process (with MDT, Config Manager, etc.)?
Thanks.
Do we think there will be a resolution for this? I had planned to offer the WSL installer in our Intune Company portal by publishing from the Store, but the UAC will drive too much call volume. The workaround continues to be to maintain the MSI install as a Win32 app installed as User, but far from ideal.
We are primarily 11 22h2 in case this has been resolved by KB in later releases of 11. If so knowing the KB may help us get this resolved quicker.
Hi @byjrack
We've solved this problem installing WSL2 during OSD (i.e. Features in the WIM + latest WSL2 MSI from GitHub).
And letting the user install his distro ONLY WHEN WSL has been provisioned to him (~15 minutes after first login).
We've explained this method in this Twitter thread: https://twitter.com/manelrodero/status/1760937740235932141.
Regards.
Yeah thats not really an option for us given our demographic of users is a small slice of overall population so WSL (VMP, WSL OS, kernel, and WSL MSIX package) is always post-deploy. MSI based we are already rolling with in Company Portal without the UAC issue as a Win32 app that does it all. It just means the normal version chase though winget is helping there.
Preference though is to be able to use the Store copy via the CP/Store integration to lower that maintenance for the custom script.
Version
Microsoft Windows [Version 10.0.22621.674]
WSL Version
Kernel Version
N/A
Distro Version
N/A
Other Software
No response
Repro Steps
This occurred on a fresh machine, where I set it up with a primary user account that has a Microsoft account, which then is an admin. I then created a local user (as a regular user, not an administrator), and signed in as that local user (while leaving the admin session active as well), and ran
wsl --install
from PowerShell.Expected Behavior
I should be able to install WSL, using the admin account to approve elevated permissions, staying logged in with the local account.
Actual Behavior
The command hung at the "Installing WSL..." message, without showing the progress bar. A prompt for elevating privileges appeared, which I approved using the admin account's credentials. The trouble was, there was a second elevation prompt for Windows Host Services that wasn't appearing there in the local account, only in the admin account's session when I switched back to it. Even approving there, and switching back to the local account session, the installation stopped hanging but said the elevation failed.
This was solved by making my local user an admin; approving the first elevation prompt with the local account's credentials then caused the second prompt to appear there as well and installation completed.
Diagnostic Logs
No response