[Question] Provisioning of Windows Terminal to LTSC 2021

[levicki]

I add latest Windows Terminal v1.23.20211.0 (Windows10_PreinstallKit) via offline provisioning along with license and all dependencies to Windows 10 Enterprise IoT LTSC 2021 install.wim.

• When I enter audit mode it's there and it works.
• When I go through OOBE it's unprovisioned from the image by the time I try to run it and I see the remnants of the package in C:\Program Files\WindowsApps\DeletedAllUserPackages.

I have also integrated Windows Store and Winget, and a bunch of video and image codecs and this happens only with Windows Terminal.

I even tried letting store update it in audit mode it appears in the library but once I recapture and reinstall it's gone again.

So it looks like Windows Store might be nuking it, but I can't prove it (can't find any logs) and much less figure out why or how to prevent it.

If you have any ideas where to look as to why this is happening I am all ears.

[levicki]

Ok, apparently in Applications and Services Logs > Microsoft > Windows > AppXDeployment > Operational there is a Verbose entry with ID 327 where it says Windows Terminal will be removed. However I still can't find any reason given.

[levicki]

Ok, found the "reason" — HKLM\Software\Microsoft\CurrentVersion\Appx\AppxAllUserStore\Deleted — both under:

• Applications
• EndOfLife

But as far as I know Windows Terminal is not EOL and neither is Windows 10 IoT Enterprise LTSC 2021 yet?

@DHowett I hope you guys have an answer for this weird behavior.

[DHowett]

I hope you guys have an answer for this weird behavior.

We sure don't!

[DHowett]

Can you grab the Terminal PFNs from all three of those keys? They should have version numbers and architectures.

[levicki]

Can you grab the Terminal PFNs from all three of those keys? They should have version numbers and architectures.

Sure. I originally tried with the latest release from here, then I used the version which the store installs (I downloaded it from the store manually and redone / reprovisioned the image with it) but after installation in a VM it deprovisioned that one too:

Weird part is it still shows up under staged:

And it is not listed under Deprovisioned key but dism /Get-ProvisionedAppxPackages doesn't show it anymore.

I had my share of issues with making custom images and I am far from a n00b on the subject but this is the first time I am seeing anything like this.

For the record, this is what I have in the image:

I don't think I missed any pre-requisites for this x64 image and so far only Windows Terminal is giving me trouble.

EDIT:

I'd like to point out that latest SSU and LCU (non-ESU of course) were slipstreamed into the image. When I booted to audit mode for the first time Windows Update was erroneously showing that OS is EOL. That message went away after I performed online update and didn't come back. I did a full cleanup and resetbase after that and recaptured the image so I don't think that should be causing this issue (and why only with WT? Makes no sense).

[DHowett]

You know, I've got a terrible hunch. Just a terrible horrible idea.

The PFNs in your Deleted/EndOfLife keys have version numbers beginning with 3000. While that number doesn't itself mean anything (and is likely not the cause of the issue in/of itself), that is the versioning strategy we use for our bundles specifically (see #12819). It is suspicious that the deleted PFNs are the ones specific to our msixbundle.

If you extract WindowsTerminal's msixbundle and provision just the .msix, does it still get deleted? I think the same license file is going to apply, but let me know if it doesn't.

[levicki]

You know, I've got a terrible hunch. Just a terrible horrible idea.

Believe me, you can't have anything worse than I have — I am wrestling with this image for 2 days and I am all out of ideas. If I wasn't so stubborn I'd have given up long ago so I welcome all terrible horrible ideas you can throw at me.

If you extract WindowsTerminal's msixbundle and provision just the .msix, does it still get deleted?

I will try that first thing in the morning, but I'd really prefer if I knew the correct, app-specific, steps to provision it to begin with. I am working based on general instructions.

I think the same license file is going to apply, but let me know if it doesn't.

I will of course, but to be clear you are suggesting I provision just CascadiaPackage_1.23.13503.0_x64.msix out of the bundle directly?

[DHowett]

I will try that first thing in the morning, but I'd really prefer if I knew the correct, app-specific, steps to provision it to begin with. I am working based on general instructions.

I do not have app-specific instructions for Windows Terminal, because until we started hearing about audit mode deprovisioning Terminal I would have thought it was "just follow the general instructions as for any other app" 🥲

I will of course, but to be clear you are suggesting I provision just CascadiaPackage_1.23.13503.0_x64.msix out of the bundle directly?

Yep! Exactly that.

[levicki]

Yep! Exactly that.

Out of curiosity, do you expect that instaling just that will affect the store infrastructure ability to perform updates on it as well?

[DHowett]

Great question! I don't think so, but this entire journey has been a surprise.

[levicki]

Great question! I don't think so, but this entire journey has been a surprise.

By the way I just redid the whole image (ok not whole but this time I did updates online instead of preinstalling them to avoid OS EOL notice from broken LCU). Guess what? Windows Terminal still deleted.

Now off to try just the x64 package as you said...

[levicki]

By the way, preinstallation kit link on this documentation page does not point to actual preinstallation kit for Windows Terminal.

[levicki]

@DHowett Believe me or not, Gemini 3 solved the problem.

I complained about the issue randomly while I was waiting for image dismount to finish and I told it what I reported to you here — bastard pointed me to #12023 and #18998 and told me to try provisioning it for all regions (/Region:all).

It worked.

Here's what the bot said:

In the Terminal repo (Issue #12023), it was confirmed that if an AppX package is provisioned without a specific region and isn't a "pinned" inbox app, the OOBE "cleanup" phase (which runs right after region selection) assumes the package is "orphan" or "unsupported" for the current region/edition and nukes it.

Because you are on LTSC, the "Inbox App" list is incredibly strict. If it's not on that list, it has to be "bulletproofed" during provisioning.

The Fix: Provision with -Regions all
When you add the package to the .wim (or online in Audit mode before recapture), you must explicitly tell Windows that this package belongs in every region. Without this, the OOBE transition sees the lack of regional metadata and marks it for deletion.

I have no idea if that means there is some issue with Windows Terminal bundle or that it just has to be provisioned like this. In any case adding an Installation section to the readme wouldn't hurt.

[DHowett]

THANK YOU. This is so immensely helpful; I can also bring it to the folks who own app provisioning. I'll get it added to the documentation.