Sysprep AppX validation broken on Windows 2025

Thomas Verschuere 10 Reputation points
2026-04-22T21:03:36.2266667+00:00

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

Windows for business | Windows Server | Devices and deployment | Set up, install, or upgrade

3 answers

Sort by: Newest
Most helpful Newest Oldest
  1. Thomas Verschuere 10 Reputation points
    2026-09-24T14:10:02.1533333+00:00

    Microsoft confirmed that running Sysprep under the Local System account is an unsupported scenario. This includes launching Sysprep through mechanisms such as Task Scheduler running as SYSTEM, PsExec as SYSTEM, or other service-based contexts.

    I raised the question of what Microsoft considers the supported approach for a fully unattended image build pipeline on Windows Server 2025, since many image automation platforms operate under a service or SYSTEM context. Microsoft was unable to provide a documented supported method for performing a fully unattended Sysprep workflow under these conditions.

    Their final position was:

    • Running Sysprep as SYSTEM is unsupported.
    • They currently do not have a documented, supported alternative that enables a completely unattended image creation workflow when automation runs under a service/SYSTEM account.
    • The observed behavior is considered by support to align with current product design and documented limitations rather than a product malfunction.
    • Any request for a supported unattended alternative would need to be pursued as a Design Change Request (DCR) through Unified/Premier Support for product group review.

    What remains unclear is how Microsoft expects organizations to implement secure, non-interactive image creation pipelines for Windows Server 2025 when Sysprep must be executed from an elevated administrator context rather than a service context. That question was not answered during the case.

    Was this answer helpful?

    0 comments
  2. HLBui 13,260 Reputation points Independent Advisor
    2026-04-23T14:00:06.0333333+00:00

    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

    Was this answer helpful?

  3. AI answer

    2026-04-22T21:04:00.86+00:00

    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.

    Was this answer helpful?

    1 person found this answer helpful.

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.