starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-02-03 21:25:34 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

[Question] Provisioning of Windows Terminal to LTSC 2021 #24016

New Issue
Closed
opened 2026-01-31 08:59:04 +00:00 by claunia · 13 comments
claunia commented 2026-01-31 08:59:04 +00:00
Owner
Copy Link

Originally created by @levicki on GitHub (Jan 27, 2026).

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.

Originally created by @levicki on GitHub (Jan 27, 2026). 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.
claunia added the Needs-TriageNeeds-Tag-Fix labels 2026-01-31 08:59:05 +00:00
claunia commented 2026-01-31 08:59:06 +00:00
Author
Owner
Copy Link

@levicki commented on GitHub (Jan 27, 2026):

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 commented on GitHub (Jan 27, 2026): 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.
claunia commented 2026-01-31 08:59:06 +00:00
Author
Owner
Copy Link

@levicki commented on GitHub (Jan 27, 2026):

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.

@levicki commented on GitHub (Jan 27, 2026): 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.
claunia commented 2026-01-31 08:59:06 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Jan 27, 2026):

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

We sure don't!

@DHowett commented on GitHub (Jan 27, 2026): > I hope you guys have an answer for this weird behavior. We sure don't!
claunia commented 2026-01-31 08:59:06 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Jan 27, 2026):

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

@DHowett commented on GitHub (Jan 27, 2026): Can you grab the Terminal PFNs from all three of those keys? They should have version numbers and architectures.
claunia commented 2026-01-31 08:59:06 +00:00
Author
Owner
Copy Link

@levicki commented on GitHub (Jan 27, 2026):

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:
Image

Weird part is it still shows up under staged:
Image

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:
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).

@levicki commented on GitHub (Jan 27, 2026): > 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: <img width="593" height="139" alt="Image" src="https://github.com/user-attachments/assets/8a4fe8f6-c4cf-4fd2-babb-dd9bbb7afbfe" /> Weird part is it still shows up under staged: <img width="576" height="295" alt="Image" src="https://github.com/user-attachments/assets/0b69b874-bc08-4ca2-831e-fcc544744e2e" /> 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: <img width="616" height="424" alt="Image" src="https://github.com/user-attachments/assets/e72ade85-79a1-4fb3-a4bb-3d8f0d2da3c5" /> 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).
claunia commented 2026-01-31 08:59:07 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Jan 27, 2026):

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.

@DHowett commented on GitHub (Jan 27, 2026): 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.
claunia commented 2026-01-31 08:59:07 +00:00
Author
Owner
Copy Link

@levicki commented on GitHub (Jan 27, 2026):

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?

@levicki commented on GitHub (Jan 27, 2026): > You know, I've got a terrible hunch. Just a terrible horrible idea. Believe me, you can't have anything worse than I have &mdash; 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?
claunia commented 2026-01-31 08:59:07 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Jan 28, 2026):

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.

@DHowett commented on GitHub (Jan 28, 2026): > 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.
claunia commented 2026-01-31 08:59:07 +00:00
Author
Owner
Copy Link

@levicki commented on GitHub (Jan 28, 2026):

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?

@levicki commented on GitHub (Jan 28, 2026): > 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?
claunia commented 2026-01-31 08:59:08 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Jan 28, 2026):

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

@DHowett commented on GitHub (Jan 28, 2026): Great question! I don't _think_ so, but this entire journey has been a surprise.
claunia commented 2026-01-31 08:59:08 +00:00
Author
Owner
Copy Link

@levicki commented on GitHub (Jan 28, 2026):

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 commented on GitHub (Jan 28, 2026): > 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...
claunia commented 2026-01-31 08:59:08 +00:00
Author
Owner
Copy Link

@levicki commented on GitHub (Jan 28, 2026):

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

@levicki commented on GitHub (Jan 28, 2026): By the way, preinstallation kit link on [this documentation page](https://learn.microsoft.com/en-us/windows/terminal/distributions) does not point to actual preinstallation kit for Windows Terminal.
claunia commented 2026-01-31 08:59:08 +00:00
Author
Owner
Copy Link

@levicki commented on GitHub (Jan 28, 2026):

@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.

@levicki commented on GitHub (Jan 28, 2026): @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 &mdash; 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.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
⛺ Reserved
A11yCO
A11yMAS
A11ySev1
A11ySev2
A11ySev3
A11yTTValidated
A11yUsable
A11yVoiceAccess
A11yWCAG
Area-Accessibility
Area-AtlasEngine
Area-AzureShell
Area-Build
Area-Build
Area-Chat
Area-CmdPal
Area-CodeHealth
Area-Commandline
Area-CookedRead
Area-DefApp
Area-Extensibility
Area-Fonts
Area-GroupPolicy
Area-i18n
Area-Input
Area-Interaction
Area-Interop
Area-Localization
Area-Output
Area-Performance
Area-Portable
Area-Quality
Area-Remoting
Area-Rendering
Area-Schema
Area-Server
Area-Settings
Area-SettingsUI
Area-ShellExtension
Area-ShellExtension
Area-ShellExtension
Area-Suggestions
Area-Suggestions
Area-TerminalConnection
Area-TerminalControl
Area-Theming
Area-UserInterface
Area-VT
Area-Windowing
Area-WPFControl
AutoMerge
Blocking-Ingestion
Culprit-Centennial
Culprit-WinUI
Disability-All
Disability-Blind
Disability-LowVision
Disability-Mobility
External-Blocked-WinUI3
Fixed
Gathering-Data
good first issue
HCL-E+D
HCL-WindowsTerminal
Help Wanted
Impact-Compatibility
Impact-Compliance
Impact-Correctness
Impact-Visual
In-PR
InclusionBacklog
InclusionBacklog-Windows TerminalWin32
InclusionCommitted-202206
Issue-Bug
Issue-Docs
Issue-Feature
Issue-Feature
Issue-Question
Issue-Samples
Issue-Scenario
Issue-Task
Needs-Attention
Needs-Author-Feedback
Needs-Bisect
Needs-Discussion
Needs-Repro
Needs-Tag-Fix
Needs-Tag-Fix
Needs-Triage
No-Recent-Activity
Priority-0
Priority-1
Priority-2
Priority-3
Product-Cmd.exe
Product-Colortool
Product-Colortool
Product-Colortool
Product-Conhost
Product-Conpty
Product-Meta
Product-Powershell
Product-Terminal
Product-WSL
pull-request
Mirrored from GitHub Pull Request
 Resolution-Answered
Resolution-By-Design
Resolution-Duplicate
Resolution-External
Resolution-Fix-Available
Resolution-Fix-Committed
Resolution-No-Repro
Resolution-Won't-Fix
Severity-Blocking
Severity-Crash
Severity-DataLoss
spam
this-will-be-a-breaking-change
Tracking-External
WindowsTerminal_Win32
Work-Item
zAskModeBug
zInbox-Bug
No Label Needs-Tag-Fix Needs-Triage
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#24016
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?