Sysprep AppX validation broken on Windows 2025

Thomas Verschuere 10 Reputation points

Hi

We are preparing a Windows Server 2025 image in Azure for local use.

To automate the whole process, we're using Azure DevOps pipelines.
The pipeline allows us to update an image (e.g. when we have an update of our software) without having to interactively log in.
Since the latest Windows Server 2025 Build, the pipeline itself did not break, but when testing the new image (on a local VM in hyperV), it does go through OOBE, up until you can login. At this point we have a grey desktop, by opening task manager with the keyboard shortcut, I can run powershell.exe and some other programs. When opening event viewer, I can see explorer.exe crashed and keeps crashing when trying to open it.

Running the following results in having a working desktop environment again:
Get-AppxPackage -AllUsers | ForEach-Object {

if ($_.InstallLocation -and (Test-Path "$($_.InstallLocation)\AppXManifest.xml")) {

Add-AppxPackage -DisableDevelopmentMode -Register "$($_.InstallLocation)\AppXManifest.xml"

}

}

This is the behavior when we run the original code of our pipeline.

Sysprep is the very last step in our pipeline.

What I figured out so far:
Interactively logging in with RDP to execute Sysprep.exe works and results in a working image without the issues above.
--> this means the pipeline, which executes sysprep as SYSTEM is broken since last build?

I tried to overcome the issue by using az vm run-command create with --run-as-user option, but that gives me inconsistent sysprep errors:

  1. When I run it when being connected with RDP and executing the command from the pipeline --> everything works as normal
  2. When I run it without being RDPd (let the pipeline do its work) --> sometimes 'winget' needs to be removed, other time 'edge', another time 'wsl'. --> not always all three together?

I think Sysprep broke to run as SYSTEM since the last build, but this is so far my only option to have it fully automated.

Our images on Windows Server 2022 did not have this behaviour so far.

Appreciate having help on this, I'm open to have a call with one of the engineers to help me figure this out.

Moved from: Windows for home

  1. Himanshu Shekhar 6,710 Reputation points • Microsoft External Staff • Moderator

    Thank you for reaching out regarding your Windows issue. We are currently investigating the matter and will provide our recommendations as soon as possible. If you have any further information or concerns, please feel free to share them. We appreciate your patience as we address this issue.

  2. Himanshu Shekhar 6,710 Reputation points • Microsoft External Staff • Moderator

    Hey Thomas, it sounds like Sysprep under SYSTEM is tripping over leftover or reprovisioned AppX packages in your Server 2025 image. When Explorer crashes during OOBE, that’s usually Sysprep’s AppX cleanup provider failing on per‐user or provisioned apps that aren’t in a clean state. Here’s what you can try in your pipeline, just before you call Sysprep:

    1. Remove all per-user AppX packages 
      
 Get-AppxPackage -AllUsers |

 Remove-AppxPackage -ErrorAction SilentlyContinue
    2. Remove all provisioned (all-user) AppX packages from the image 
      
 Get-AppxProvisionedPackage -Online |

 Remove-AppxProvisionedPackage -Online -ErrorAction SilentlyContinue
    3. (Optional) If you need certain inbox apps on your generalized image, re-provision them properly: 
      
 # Re-register any AppX manifests you still want in the final image

 Get-AppxPackage -AllUsers |

 ForEach-Object {

 if ($_.InstallLocation -and (Test-Path "$($_.InstallLocation)\AppXManifest.xml")) {

 Add-AppxPackage -DisableDevelopmentMode -Register "$($_.InstallLocation)\AppXManifest.xml"

 }

 }
    4. Double-check no pending Windows Updates (reboot & run Get-WindowsUpdateLog) and remove any extra user profiles that aren’t needed.
    5. Now run Sysprep as SYSTEM in your pipeline.

    This follows the guidance in the Microsoft docs on “Sysprep fails after you remove or update Microsoft Store apps that include built-in Windows images” (look for the 0x80073cf2 section) and the Azure VM Image Builder troubleshooting article on AppX/Sysprep cleanup.

    If you still hit inconsistent errors around winget, Edge or WSL packages, grab your Sysprep logs (%WINDIR%\System32\Sysprep\Panther\setupact.log & setuperr.log) and search for 0x80073xxx codes. Those entries will pinpoint exactly which package is choking the generalize pass.

    Hope that gets your Server 2025 pipeline back on track!

    Reference list

    • Remove machine specific information by deprovisioning or generalizing a VM before creating an image -
  3. Thomas Verschuere 10 Reputation points

    Hi

    Did a few new runs with the provided info.

    The result of 1.``Remove all per-user AppX packages does not do it for all packages, I still got an error one time where Microsoft.DesktopAppInstaller was still present.

    The result of 2.``Remove all provisioned (all-user) AppX packages from the image returns:

     "message": "Remove-AppxProvisionedPackage : Removal failed. Please contact your software vendor.\nAt C:\\Packages\\Plugins\\Microsoft.CPlat.Core.RunCommandWindows\\1.1.22\\Downloads\\script1.ps1:399 char:38\n+ ... e -Online | Remove-AppxProvisionedPackage -Online -ErrorAction Silent ...\n+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n + CategoryInfo : NotSpecified: (:) [Remove-AppxProvisionedPackage], COMException\n + FullyQualifiedErrorId : Microsoft.Dism.Commands.RemoveAppxProvisionedPackageCommand\n "

    The interesting part:
    The first time I ran both commands in the pipeline, I got a working version, but full of errors in the output of the specific commands.

    The second time I ran it without removing AppxPackage / ApxProvisionedPackage, just to test something else --> broken explorer at new boot.

    The third time I ran the following for better error handling:

    $packages = Get-AppxPackage -AllUsers

foreach ($pkg in $packages) {
 try {
 Write-Host "Removing $($pkg.PackageFullName)"
 Remove-AppxPackage -Package $pkg.PackageFullName -AllUsers -ErrorAction Stop
 }
 catch {
 Write-Warning "Failed to remove $($pkg.PackageFullName): $($_.Exception.Message)"
 }
}

    This results in the following (partial due to restricted length) output:

    "message": "moving Microsoft.UI.Xaml.2.8_8.2511.26001.0_x64__8wekyb3d8bbwe\nRemoving Microsoft.SecHealthUI_1000.29554.1001.0_x64__8wekyb3d8bbwe\nWARNING: Failed to remove Microsoft.SecHealthUI_1000.29554.1001.0_x64__8wekyb3d8bbwe: Removal failed. Please contact \nyour software vendor.\n\n\n\nDeployment DeStage operation with target volume C: on Package \nMicrosoft.SecHealthUI_1000.29554.1001.0_x64__8wekyb3d8bbwe from: failed with error 0x80070032. See \nhttp://go.microsoft.com/fwlink/?LinkId=235160 for help diagnosing app deployment issues.\nRemoving Microsoft.ECApp_10.0.26100.32690_neutral__8wekyb3d8bbwe\nWARNING: Failed to remove Microsoft.ECApp_10.0.26100.32690_neutral__8wekyb3d8bbwe: Removal failed. Please contact your \nsoftware vendor.\n\n\n\nDeployment DeStage operation with target volume C: on Package Microsoft.ECApp_10.0.26100.32690_neutral__8wekyb3d8bbwe \nfrom: failed with error 0x80070032. See http://go.microsoft.com/fwlink/?LinkId=235160 for help diagnosing app \ndeployment issues.\nRemoving Microsoft.LockApp_10.0.26100.32690_neutral__cw5n1h2txyewy\nWARNING: Failed to remove Microsoft.LockApp_10.0.26100.32690_neutral__cw5n1h2txyewy: Removal failed. Please contact \nyour software vendor.\n\n\n\nDeployment DeStage operation with target volume C: on Package Microsoft.LockApp_10.0.26100.32690_neutral__cw5n1h2txyewy\n from: failed with error 0x80070032. See http://go.microsoft.com/fwlink/?LinkId=235160 for help diagnosing app \ndeployment issues.\nRemoving Microsoft.UI.Xaml.CBS_9.2601.4001.0_x64__8wekyb3d8bbwe\nRemoving Microsoft.WindowsAppRuntime.CBS.1.8_8000.694.2228.100_x64__8wekyb3d8bbwe\nRemoving MicrosoftWindows.57242383.Tasbar_1000.26100.32684.0_x64__cw5n1h2txyewy\nWARNING: Failed to remove MicrosoftWindows.57242383.Tasbar_1000.26100.32684.0_x64__cw5n1h2txyewy: Removal failed. \nPlease contact your software vendor.\n\n\n\nDeployment DeStage operation with target volume C: on Package \nMicrosoftWindows.57242383.Tasbar_1000.26100.32684.0_x64__cw5n1h2txyewy from: failed with error 0x80070032. See \nhttp://go.microsoft.com/fwlink/?LinkId=235160 for help diagnosing app deployment issues.\nRemoving MicrosoftWindows.59336768.Speion_1000.26100.32684.0_x64__cw5n1h2txyewy\nWARNING: Failed to remove MicrosoftWindows.59336768.Speion_1000.26100.32684.0_x64__cw5n1h2txyewy: Removal failed. \nPlease contact your software vendor.\n\n\n\nDeployment DeStage operation with target volume C: on Package \nMicrosoftWindows.59336768.Speion_1000.26100.32684.0_x64__cw5n1h2txyewy from: failed with error 0x80070032. See \nhttp://go.microsoft.com/fwlink/?LinkId=235160 for help diagnosing app deployment issues.\nRemoving MicrosoftWindows.59337133.Voiess_1000.26100.32684.0_x64__cw5n1h2txyewy\nWARNING: Failed to remove MicrosoftWindows.59337133.Voiess_1000.26100.32684.0_x64__cw5n1h2txyewy: Removal failed. \nPlease contact your software vendor.\n\n\n\nDeployment DeStage operation with target volume C: on Package \nMicrosoftWindows.59337133.Voiess_1000.26100.32684.0_x64__cw5n1h2txyewy from: failed with error 0x80070032. See \nhttp://go.microsoft.com/fwlink/?LinkId=235160 for help diagnosing app deployment issues.\nRemoving MicrosoftWindows.59337145.Livtop_1000.26100.32684.0_x64__cw5n1h2txyewy\nWARNING: Failed to remove MicrosoftWindows.59337145.Livtop_1000.26100.32684.0_x64__cw5n1h2txyewy: Removal failed. \nPlease contact your software vendor.\n\n\n\nDeployment DeStage operation with target volume C: on Package \nMicrosoftWindows.59337145.Livtop_1000.26100.32684.0_x64__cw5n1h2txyewy from: failed with error 0x80070032. See \nhttp://go.microsoft.com/fwlink/?LinkId=235160 for help diagnosing app deployment issues.\nRemoving MicrosoftWindows.59379618.InpApp_1000.26100.32684.0_x64__cw5n1h2txyewy\nWARNING: Failed to remove MicrosoftWindows.59379618.InpApp_1000.26100.32684.0_x64__cw5n1h2txyewy: Removal failed. \nPlease contact your software vendor.\n\n\n\nDeployment DeStage operation with target volume C: on Package \nMicrosoftWindows.59379618.InpApp_1000.26100.32684.0_x64__cw5n1h2txyewy from: failed with error 0x80070032. See \nhttp://go.microsoft.com/fwlink/?LinkId=235160 for help diagnosing app deployment issues."

    Just want to emphasize this has been working over the past year, but it broke since the last Windows Build.

  4. Thomas Verschuere 10 Reputation points

    I uninstalled the last update, took a snapshot from it. Ran the pipeline again as it was before and now everything works, which makes me very confident it's the latest Windows Build that messed up.

    KB5082063 / build 26100.32690 introduced the regression.

    Where can I report this issue? Or will this be followed up?

Sign in to comment

2 answers

  1. AI answer

    Sysprep running under SYSTEM is hitting AppX/package validation issues on newer Windows Server 2025 builds. This matches known Sysprep/AppX failure patterns where provisioned or updated Microsoft Store apps are in an inconsistent state for the account that runs Sysprep.

    Key points from the behavior described:

    • Sysprep as an interactive user (via RDP) succeeds and the image boots with a working Explorer.
    • Sysprep as SYSTEM (pipeline) completes, but the first logon hits a broken AppX state: Explorer crashes until all AppX packages are re-registered with the PowerShell loop.
    • When trying to force Sysprep via az vm run-command as a user, the failing package varies (winget, Edge, WSL), which is typical of AppX provisioning inconsistencies.

    On current Windows builds, Sysprep fails or leaves the image in a bad state if:

    • A provisioned Store app (built into the image) has been updated or removed only for some users, or
    • The account running Sysprep still has that app installed while provisioning metadata is inconsistent.

    The supported remediation pattern is:

    1. For the account that runs Sysprep (in this case SYSTEM or the service context used by the pipeline), identify AppX packages that are installed for that account but not consistently provisioned.
    2. Remove those AppX packages for that account.
    3. Remove their provisioning from the image.

    The documented steps are:

    1. Enumerate AppX packages and their user bindings 
       Import-Module Appx
 Import-Module Dism
 Get-AppxPackage -AllUsers | Where PublisherId -eq 8wekyb3d8bbwe | \
 Format-List -Property PackageFullName,PackageUserInformation
      • This lists Microsoft-published packages and shows for which users they are installed.
      • For non-Microsoft publishers, use: 
         Get-AppxPackage -AllUsers | \
 Format-List -Property PackageFullName,PackageUserInformation
    2. For packages that show as Installed for the account that will run Sysprep (and that are causing issues), remove them for that account: 
       Remove-AppxPackage -Package <PackageFullName>
    3. Remove provisioning for those packages from the image: 
       Remove-AppxProvisionedPackage -Online -PackageName <PackageFullName>

    In an automated pipeline, this logic must run in the same security context that will later execute Sysprep (SYSTEM or the chosen service account) and before Sysprep is invoked. That ensures Sysprep does not encounter partially provisioned or user-updated AppX packages and avoids the broken Explorer state.

    If the goal is to keep the image fully automated and avoid interactive RDP, incorporate the above AppX cleanup into the image build just before the Sysprep step, then run Sysprep with the recommended options for VM images:

    C:\Windows\System32\Sysprep\sysprep.exe /generalize /oobe /mode:vm

    (plus /shutdown or /quiet /quit depending on whether capture is manual or automated).

    If Sysprep has already run and the image is corrupted (Explorer crashes at first logon), the official guidance is to re-create the image rather than trying to repair it post-Sysprep.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.
  2. HLBui 6,755 Reputation points • Independent Advisor

    Hi

    What you’re running into is tied to how Sysprep behaves when it’s executed under the SYSTEM account in the latest Windows Server 2025 builds. Explorer crashing after OOBE is usually a symptom of AppX packages not being re‑registered properly, which is why your PowerShell workaround brings the desktop back. The fact that RDP + manual Sysprep works fine tells us the pipeline’s SYSTEM context is missing some user‑level package registrations that Sysprep now expects.

    A couple of things you might try:

    Run Sysprep explicitly under a user context (not SYSTEM) as part of the pipeline, even if it means wrapping it in a scheduled task that impersonates a local admin.

    If you stick with SYSTEM, add a post‑Sysprep step to re‑register critical AppX packages (like ShellExperienceHost, Edge, and WSL) before sealing the image. That way explorer.exe won’t choke on first boot.

    • Keep an eye on the release notes for Server 2025 there have been subtle changes in how Sysprep handles modern apps compared to Server 2022, and this looks like one of those regressions.

    I’d suggest testing with a minimal repro pipeline (just OS + Sysprep) to confirm it’s not your custom software layer causing the crash. If that passes, then it’s definitely a Sysprep/system‑context issue introduced in the new build

    Hope that helps you move forward

    1. Thomas Verschuere 10 Reputation points

      Still having the issue.
      I did a reproduction as suggested by creating a new Windows 2025 Datacenter VM (non-Azure edition).

      Left everything blank and ran sysprep.
      Result was again a broken desktop environment.

      So I'm very sure it's broken since that build.

    Sign in to comment
Sign in to answer

Your answer