-
Notifications
You must be signed in to change notification settings - Fork 821
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
WSL msi will not install via Intune #10906
Comments
Hi I'm an AI powered bot that finds similar issues based off the issue title. Please view the issues below to see if they solve your problem, and if the issue describes your problem please consider closing this one and thumbs upping the other issue to help us prioritize it. Thank you! Open similar issues:
Closed similar issues:
|
Thank you @AlanAbluestem. Can you share the MSI logs ? You can get them via:
|
Just saw that you already did that. We haven't received them yet. If you're OK with this feel free to just put them here. MSI logs shouldn't contain anything private. |
Hi guys, I have exactly the same issue with exactly the same version 2.0.9.0. When I run it with powersheel deployment toolkit under my admin account, its working normally but when I deploy it with Ivanti Endpoint Management installing it under SYSTEM local account, I got 1603 error. Meanwhile today I found that theres 2.0.14.0 version so I would try my luck with this but to me it looks like theres an issue when at least 2.0.9.0 msi package is installed as "SYSTEM" which is necessary for us. Regards |
Our Security rules are pretty strict and I am not allowed to publish them publicly. I had to bend a few rules just to send them the other method. I guess we will have to wait until they make their way to you via that channel, sorry. |
Update: currently I tested also version 2.0.14.0 but unfortunately with the same error 1603. just to clarify the method:
-> is this msi installer build to be handled correctly by SYSTEM account?
I dont want to post whole install log, we also have strict policy but theres nothing extra telling what is wrong and its outcome is:
Here is info about user (our local SYSTEM account has regular full permissions btw):
If you need something specific from the log, please let me know. Br |
Unfortunately what you shared isn't enough to root cause the issue. There's most likely another error in the logs. Can the post the whole log ? Feel free to redact user names and paths if that helps. |
Yeaaah I thought it wouldnt be enough. :D OK I cleaned the log from sensitive stuff (its btw from version 2.0.14 from yesterday but its the same as for 2.0.9):
|
Thank you @AlanAbluestem. Looking at the install log, this is the issue:
This means that something went wrong during the MSIX package installation. To dig deeper, can you try to collect WSL /logs while the installation is running ? That should allow us to see why the MSIX installation is failing. |
I emailed the WSL logs this morning with this issue number in the subject. I did neglect to add a link to my comment, sorry. |
If I might jump in.
The error is occurring because system cannot register MSIX apps. Under AppX-Deployment-Server on event viewer there is an error on the same time, event id 404 |
Thank you @AlanAbluestem. Looking at the logs I see:
Which unfortunately doesn't tell us a lot more. Can you try to run the installation again and then share the output of (elevated powershell): This should give us more info about what exactly is failing. |
Same issue here on a recent up-to-date-patched h2 win10, with WSL2, 2.0.14, applying packages with SYSTEM (admin works fine). A real blocker for upgrading our ancient WSL2 -versions to our organisation, as everything is applied with SYSTEM and it worked fine for older versions of wsl2 (pre WS2 1.0 at least:). Hope this is an prioritized issue to fix. Cheers, Thanks. |
🤨🤨🤨 |
"Closed as completed" so is it fixed then?
Nothing official indicates this problem was solved, and if not, it should be reopened. @schenardie was in the middle of a dialog with sharing logs and problem solving. I reported the same problem in a comment above. |
I'm back from PTO, but looks like this issue was automatically closed??? Can we re-open this issue as we never received a resolution? My last action was to send the additional log info (via email) as requested above. |
@OneBlue ^ bump ^ |
@AlanAbluestem: Unfortunately this issue will require a Windows update to be fixed. I'll update it once it's released. |
@OneBlue Awesome & thank you for reopening this issue. Any idea on a timeline for this fix? I need to update my leadership and I'm sure others do as well. I'm not asking for something carved in stone, just an idea if it will be in the next few CU's, a stand alone update, or if we will have to wait for 24H2. |
I'm sure you are on to it alredy as it seems, but just to add anyway, we had the same (non-working as system) experience for Win10 with fresh wsl 2.0.14 and intune, thanks for reopening. |
Same here, sorry I was on holidays. Thanks to all guys issuing this. I will wait for the update. Will it be announced in this thread or somewhere else? Just to know what to track. ;-) Thanks and best wishes to the new year. |
Legend, can confirm it works. When can we expect that to be promoted to latest? Thanks |
Windows Version
Windows 11 22H2 build 10.0.22621.2715
WSL Version
msi version 2.0.9
Are you using WSL 1 or WSL 2?
Kernel Version
unknown
Distro Version
n/a
Other Software
n/a
Repro Steps
Our goal is to deploy WSL, along with a distribution, via Intune so standard users can install WSL without admin rights.
Downloaded the latest msi release (2.0.9) from https://github.com/microsoft/wsl/releases
We imported this MSI into Intune as a LOB app but after deployment, the app would not show up on target devices.
We then used the Intune Win 32 content prep tool to wrap the msi along with a powershell script to call it. This deployed normally but the msi failed with exit code 1603.
command in Powershell to call the msi: start-process .\wsl.2.0.9.0.x64.msi "/norestart /quiet -Wait;
We later added the /L*vx switch with a path/log location to capture verbose logging.
The same command line works when running from an Administrative cmd prompt or PoshPrompt.
Expected Behavior
The WSL MSI would install successfully
Actual Behavior
The installation fails with error code 1603.
Diagnostic Logs
log file emailed to [email protected] with notes per the Contributing.md file linking it to this bug report.
The text was updated successfully, but these errors were encountered: