Intune published WSL Store app duplicates ID

[byjrack]

Windows Version

10.0.22631.5335

WSL Version

2.0.9.0

Are you using WSL 1 or WSL 2?

• [x] WSL 2
• [ ] WSL 1

Kernel Version

5.15.133.1-1

Distro Version

n/a

Other Software

No response

Repro Steps

Publish the Store UWP WSL app in Company Portal (https://apps.microsoft.com/detail/9p9tqf7mrm4r) and install

> winget list Microsoft.WSL
Name                        Id            Version Available Source
------------------------------------------------------------------
Windows Subsystem for Linux Microsoft.WSL 2.0.9.0 2.4.13    winget
Windows Subsystem for Linux Microsoft.WSL 2.0.9.0           winget

Expected Behavior

WSL store will install the latest and keep the installed up to date

Actual Behavior

WSL is not being kept to the latest revision by Store auto-update possibly because of the ID duplication?

Diagnostic Logs

I don't believe it is WSL related. May be able to override Store update process w wsl --update but would prefer Store be keeping things up to date.

Not exactly sure where the Intune AgentExecutor stores logs related to Store based UWP app orchestration, but trying to get some more detailed logs.

[github-actions[bot]]

Logs are required for review from WSL team

If this a feature request, please reply with '/feature'. If this is a question, reply with '/question'. Otherwise please attach logs by following the instructions below, your issue will not be reviewed unless they are added. These logs will help us understand what is going on in your machine.

How to collect WSL logs

Download and execute collect-wsl-logs.ps1 in an administrative powershell prompt:

Invoke-WebRequest -UseBasicParsing "https://raw.githubusercontent.com/microsoft/WSL/master/diagnostics/collect-wsl-logs.ps1" -OutFile collect-wsl-logs.ps1
Set-ExecutionPolicy Bypass -Scope Process -Force
.\collect-wsl-logs.ps1

The script will output the path of the log file once done.

If this is a networking issue, please use collect-networking-logs.ps1, following the instructions here

Once completed please upload the output files to this Github issue.

Click here for more info on logging If you choose to email these logs instead of attaching to the bug, please send them to [email protected] with the number of the github issue in the subject, and in the message a link to your comment in the github issue and reply with '/emailed-logs'.

[byjrack]

/question

[github-actions[bot]]

Diagnostic information

Found '/question', adding tag 'question'

[craigloewen-msft]

This seems like a Winget packaging / version issue. Will check on the Winget repo.

[byjrack]

In this case winget/AppInstaller is how Intune facilitates the Store based install of the apps via Intune. The install should be coming from Store CDN and not from winget-pkgs

[byjrack]

So seeing https://github.com/microsoft/winget-pkgs/pull/258400 added the msix installers in addition to the wix ones. And checked today and only getting a single instance when checking Microsoft.WSL from winget.

So seems like this is fixed? I can't test if the auto-updates are working until the 2.5.x is moved to release, but the duplication seems to be resolved.

[byjrack]

Going to count this one as done and keep the manifest as a possible cause of dupes with Store based

[byjrack]

Hmm so had a user still having issues and saw that the duplication still seems to be out there

I tried to have the user run a winget source update and no change on their machine. The impact is that Intune won't update using 2.4.13 as it seems to see 2.0.9.0 as latest and folks seem to be stuck. I have looked in AgentExecutor and you don't even see an attempt to run the app as the detection being run is as far as it gets for an install/reinstall.

@craigloewen-msft any thoughts around an action i can take to clean up the duplication on the client?

[craigloewen-msft]

I think this could be due to how we have our winget page set up. I've opened 4 PRs to fix this. You can see the details here.

https://github.com/microsoft/WSL/pull/12946#issuecomment-2906143849

They should get merged soon, would you be able to try this again then after? I would expect it would work and wouldn't have duplicates.

If it does, then this is a deeper winget issue and we should file it on the winget repo.

[byjrack]

Yeah def will have folks give it a go when it hits. This is the first I have seen this show up on any packages.

Given intune plays loose and fast with winget to republish Store apps under the winget source it could definetly be a corner case.

[byjrack]

So had the folks seeing additional dupes run winget list Microsoft.WSL and they are getting the 2.0.9.0 with 2.4.13 as Available and no dupes, but the upgrade doesn't seem to be triggering. User hit Reinstall and in AgentExecutor the detection scripts are running, but don't seem to be triggering from the Store based install (via Company Portal). Basically still shows Installed status and unlike the actual Store app you don't get a Get Updates option. The log entries for detection scripts are uuid based so knowing the actual return code for the WSL app is not trivial.

I am sure a winget update would get things going, but the distribution channel will be via Company Portal so trying to replicate what the end users would experience.

[craigloewen-msft]

Ok so it seems we have fixed the duplicate problem right? The root issue for this?

But it sounds like there is another issue? Around winget updating?

[byjrack]

So maybe? The core of the issue was updating/installing from Intune published Store WSL which I believed to be because of the duplication. Now we have solved the duplication (using winget as the test), but Intune doesn't see WSL 2.14.3 as applicable even though current is on 2.0.9.0 and winget notes an update is available.

There is something odd in the detection process for the WSL app (I can only see the posh runs of opaque guids in AgentExecutor logs). For manual win32s we manually load up into Intune we can look at the Detection routine since we configure it, but for Store published thats all hidden. WSL is also a UWP so would expect the install/update checks to be pretty straightforward compared to a win32 Store app.

I am good to open a separate issue as agreed i think the duplication is fixed, but may be that the duplication had nothing to do with CP detecting WSL as already installed so it doesn't trigger the update on a install/reinstall request.

I also expect winget update (or wsl update) would work, but given we are using the Store installer I was hoping the normal Store auto-update would work for the long term. I have other Store apps published and getting auto-updates so i know the background process works for some, but something is unique about the detection routine used for WSL in the Store app.

[byjrack]

@craigloewen-msft any thoughts about the Detection rules on the Store WSL that might explain the inability to update? AgentExecutor just shows the rules being run, but there is no additional logging so why the update isn't firing is the mystery. I had thought it might be the duplicates, but given those are fixed and the detection isn't triggering a download and update there is something else going on. Beyond AgentExecutor i don't know of any other places where there might be some logging that might indicate why Detection is saying Installed with no updates.

I can open a new Issue if you want to close this one out on the duplicates resolution if it helps with organization.

[craigloewen-msft]

I actually think the issue that you're talking about is identified here and owned by the winget team:

https://github.com/microsoft/winget-cli/issues/5491

If you could please confirm that that looks right, then I can close out this issue and we can use that winget issue to track it.

[byjrack]

Got it and yeah makes sense

A more interesting result came from one of the folks reporting the issue w updates not working

So guessing Intune detection checks areas outside of how winget is checking so we get a disconnect in Intune showing Reinstall action and Installed status. Then trying a Reinstall fails silently because there is an internal error on this MSI v MSIX disconnect. I was poking around DiagOutputDir and expected to see a sign of this, but no exceptions jumping out.

I am sold that the cli error is the real cause, but now I need to figure out how to resolve that for folks trying to install via Intune who have never used winget directly. 😅