Windows 11 24H2 BYOL WorkSpaces Image — Protected Staged AppX Packages Blocking Image Checker — Cannot Remove

It appears you have identified a specific conflict between the Windows 11 24H2 (Build 26100) hardened system packages and the current logic used by the AWS WorkSpaces Image Checker.

Since these packages (SecHealthUI, DesktopAppInstaller) are flagged as "Protected" in 24H2, the standard Remove-AppxPackage cmdlet will consistently return error 0x80070032. The fact that they appear after the initial WorkSpace provisioning suggests that the AWS specialized setup (or Windows OOBE triggers during the first boot of the WorkSpace) is moving these from a "hidden" state to a "staged" state.

I would try the following:

1. Force-Deprovision via DISM (The "Deep Clean" Approach)

Since PowerShell's AppX module respects the "Protected" flag, try bypasssing the API using DISM directly. Run this in an elevated PowerShell session:

# Attempt to remove the staged provisioned packages at the image level
dism /online /get-provisionedappxpackages | Select-String "Microsoft.DesktopAppInstaller" -Context 1
# If found, use the PackageName to remove:
dism /online /remove-provisionedappxpackage /packagename:PACKAGENAME_FROM_ABOVE

2. Registry "Neutralization" (Use with Caution)

The Image Checker looks at the AppxAllUserStore in the registry. If DISM fails, you can sometimes "trick" the checker by removing the state entries for these specific packages, though this is a last resort:

• Navigate to: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Appx\AppxAllUserStore\Staged
• Locate the keys matching the offending packages and back them up (export).
• Deleting these keys often allows the Image Checker to pass, as it no longer "sees" them as pending staged packages.

3. Modify the Image Checker Script (The "Bypass" Method)

If you are confident that these packages are not interfering with Sysprep (which they shouldn't, as they are native 24H2 components), you can temporarily modify the AWS Image Checker PowerShell script:

• Locate the AmazonWorkSpacesImageChecker.ps1 (usually in C:\Program Files\Amazon\WSP\).
• Search for the function checking for AppX packages.
• Add an exclusion filter for the specific package names (Microsoft.SecHealthUI, etc.) so the script returns a "Pass" despite their presence.

4. Why "Is this even a word" is relevant: As far as I understand ... Yes, "unrebuildable" is perfectly understood in this context! However, the behavior you're seeing suggests that the BYOL ingestion pipeline for 24H2 needs an update from AWS to ignore these specific system-staged packages that are now "permanent" in the OS.

PS: In your post, you might want to clarify if you used the "Cleanup-Image" command before running the checker: dism /online /cleanup-image /startcomponentcleanup Sometimes this flushes the "Staged" queue for system components that have finished their update cycle.

Hope that helps !

Thank you for the detailed and well-reasoned response — this was significantly more useful than what I received through official AWS Support and pointed me in the right direction for further investigation.

I wanted to follow up with results from testing each of your suggestions.

Option 1 — DISM Force-Deprovision

Neither Microsoft.SecHealthUI nor Microsoft.DesktopAppInstaller appeared in the output of:

dism /online /get-provisionedappxpackages

DISM has no visibility to these packages at all, which rules out removal via this path.

Option 2 — Registry Neutralization via AppxAllUserStore

This is where it gets interesting. The packages were not present under the Staged key as your post suggested, but a recursive search of the full AppxAllUserStore hive located them under a user SID subkey:

HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Appx\AppxAllUserStore<SID>
Microsoft.DesktopAppInstaller_2026.306.1850.0_neutral_~_8wekyb3d8bbwe Microsoft.SecHealthUI_1000.29510.1001.0_x64__8wekyb3d8bbwe

Both keys had Path, Regions, LastReturnValue, and NumberOfAttempts values — consistent with failed installation attempts left behind by the WorkSpace OOBE process.

I exported a backup, deleted both keys, confirmed their removal, and immediately re-ran the Image Checker. The staged state persisted unchanged. Get-AppxPackage -AllUsers still reports all four packages as staged.

This tells us the AppX deployment service maintains its authoritative state in the binary AppRepository database at C:\ProgramData\Microsoft\Windows\AppRepository — the registry entries appear to be derived metadata only. Deleting them has no effect on what the service or the Image Checker actually sees.

Current staged packages that cannot be remediated:

• Microsoft.SecHealthUI_1000.29510.1001.0_x64 (Staged, Installed)
• Microsoft.DesktopAppInstaller_1.28.220.0_x64 (Staged, Installed)
• Microsoft.WindowsAppRuntime.1.7_7000.785.2325.0_x64 (Staged)
• Microsoft.WindowsAppRuntime.1.7_7000.785.2325.0_x86 (Staged)

Option 3 — Image Checker Script Modification

I have not attempted this yet. Given that the Image Checker downloads and validates a signed imagePrepValidation.ps1 from an AWS S3 VPC endpoint at runtime, I am not certain a local modification would survive that process. Has anyone confirmed this approach works when the script is being pulled fresh each run?

Your point about the BYOL ingestion pipeline needing an update from AWS to account for permanently staged Protected components in 24H2 appears to be exactly correct. I have escalated to AWS Support with full technical documentation and am specifically asking whether the Image Checker has been validated against Windows 11 24H2 Build 26100.

I will post back here with whatever AWS Engineering comes back with. If anyone else has encountered this on 24H2 and found a working resolution, I would very much appreciate hearing about it.

Based on the available documentation, there are several approaches to address AppX package issues during the BYOL image creation process:

Standard AppX Package Remediation: The most common reason for image validation failures is that Modern AppX Packages have not been uninstalled for all users. You should use the Remove-AppxPackage PowerShell cmdlet to remove the AppX Packages. During the BYOL import process, offending AppX packages will be cleaned up and Sysprep will be retried automatically. If the image import process continues to fail after this automatic cleanup, it means AppX packages will need to be manually cleaned up.

Image Validation Process: When creating a custom image, it's critical to run the Image Compatibility Checker, which performs a series of tests and provides guidance on resolving any issues. All failures and warnings must be resolved before an image can be created. After your VM passes all tests and you receive a "Validation Successful" message, you should shut down the VM and export it before running Sysprep.

Important Consideration for Windows 11 24H2: It's worth noting that image creation is not supported on Windows 11 systems that have been upgraded from one version to a newer version. While your situation involves a fresh 24H2 build rather than an upgrade, this limitation suggests there may be version-specific considerations for newer Windows 11 releases.

Recommended Approach: If manual removal attempts continue to fail, you may need to contact AWS Support for assistance with unknown errors during the image preparation process, particularly given that this appears to be specific to the 24H2 release and the WorkSpaces provisioning process. The documentation indicates that AWS Support should be contacted when standard troubleshooting steps don't resolve image creation issues.

Given that your original EC2 AMI conversion succeeded but the issue appeared after WorkSpace provisioning, this suggests a potential interaction between the WorkSpaces provisioning process and Windows 11 24H2 that may require AWS Support's involvement to resolve.
Sources
List of SysPrep error messages and error fixes - Amazon WorkSpaces
Troubleshooting A WorkSpace custom image creation error - Best Practices for Deploying WorkSpaces
Bring Your Own Windows desktop licenses in WorkSpaces - Amazon WorkSpaces