Wenn in den Protokollen neben dem Sysprep-Fehler 0x80073cf2 ein Paket einer Microsoft Store-App genannt wird, ermitteln Sie zuerst das genaue Paket und die Benutzerkonten, in denen es installiert ist. Prüfen Sie anschließend seinen Bereitstellungsstatus, nehmen Sie gezielte Änderungen vor und wiederholen Sie den Vorgang. Es ist nicht erforderlich, zunächst sämtliche Store-Apps zu entfernen.
Diese Anleitung gilt für Windows 11 und Windows 10, wenn die aktuellen Sysprep-Protokolle auf ein Appx-Paketproblem hinweisen. Sichern Sie vor Paketänderungen die Referenzumgebung und benötigte Anwendungsdaten so, dass Sie sie wiederherstellen können. Unsere Software für Windows-Sicherung und Image-Verteilung kann ein Systemabbild erstellen, um den aktuellen Zustand vor der Fehlersuche zu bewahren.
Den Store-App-Fehler in den Sysprep-Protokollen bestätigen
setupact.log und setuperr.log des letzten Versuchs prüfen
Öffnen Sie auf dem Referenzcomputer diesen Ordner:
%WINDIR%\System32\Sysprep\Panther\
Prüfen Sie in setupact.log und setuperr.log die Einträge zum Zeitpunkt des letzten Fehlers. Suchen Sie nach 0x80073cf2, 0x3cf2, einem Appx-bezogenen Fehler und einer Paketkennung. Besonders aufschlussreich ist diese englische Meldung:
was installed for a user, but not provisioned for all users
Sie bedeutet, dass das Paket für einen Benutzer installiert, aber nicht für alle Benutzer bereitgestellt wurde. Kopieren Sie die vollständige Paketkennung dieses Versuchs einschließlich Version und Architektur. Sichern Sie die Protokolle separat, bevor Sie den Vorgang wiederholen. Ein Paketname aus einem älteren Fehler muss nicht mehr zum aktuellen Problem gehören.
Verweisen die neuesten Einträge auf eine andere Komponente oder Fehlerursache, untersuchen Sie diese. Ein allgemeiner Dialog, dass die Windows-Installation nicht überprüft werden konnte, belegt allein noch kein Store-App-Problem.
Das Paket und die betroffenen Benutzerkonten ermitteln
Öffnen Sie Windows PowerShell als Administrator für die folgende Prüfung. Ersetzen Sie den großgeschriebenen Platzhalter durch den vollständigen Paketnamen aus dem Protokoll:
$packageFullName = 'PASTE_EXACT_PACKAGE_FULL_NAME_FROM_LOG'
Get-AppxPackage -AllUsers -PackageTypeFilter Main,Framework,Resource,Bundle |
Where-Object { $_.PackageFullName -eq $packageFullName } |
Format-List Name,PackageFullName,PackageUserInformation
Diese Abfrage liest nur Informationen aus. Prüfen Sie unter PackageUserInformation, für welche Konten das Paket installiert ist. Notieren Sie außerdem das Feld Name. Diese kürzere Kennung benötigen Sie später zur Prüfung der Bereitstellung im Image.
Get-AppxPackage -AllUsers zeigt Paketinformationen aus mehreren Benutzerkonten an und deinstalliert nichts. Bei einem Entfernungsbefehl hat -AllUsers eine andere, weiterreichende Wirkung. Übernehmen Sie den Parameter deshalb nicht automatisch von der Prüfung in die Bereinigung.
Warum Store-Apps den Sysprep-Fehler 0x80073cf2 auslösen können
Benutzerinstallation und Bereitstellung im Image unterscheiden
Eine Store-App kann sowohl für einen vorhandenen Benutzer installiert als auch als Paket im Windows-Image bereitgestellt sein. Diese zusammenhängenden Einträge erfüllen unterschiedliche Aufgaben:
| Zustand | Was Sie prüfen | PowerShell-Abfrage |
|---|---|---|
| Für einen Benutzer installiert | Das in einem vorhandenen Benutzerprofil registrierte App-Paket | Get-AppxPackage |
| Im Image bereitgestellt | Das für die Installation bei neu angelegten Benutzern vorbereitete Paket | Get-AppxProvisionedPackage -Online |
Dass sich die App in Ihrem Konto öffnen lässt, bestätigt noch nicht, dass beide Zustände zusammenpassen. In diesen DISM-Befehlen bezeichnet -Online die aktuell ausgeführte Windows-Installation und keinen Internetdienst.
Updates und unvollständiges Entfernen können Abweichungen verursachen
Beispielsweise kann ein Benutzer eine App aktualisieren, während im Image eine andere Version bereitgestellt bleibt. Ebenso kann die Bereitstellung entfernt worden sein, obwohl die App für einen Benutzer weiterhin installiert ist. Microsoft beschreibt in der Anleitung zu Sysprep-Fehlern mit Store-Apps, wie solche Situationen die Appx-Verarbeitung von Sysprep unterbrechen können.
Entscheidend ist, welche Paketzustände auf diesem Referenzcomputer nicht zusammenpassen. Gehen Sie nicht davon aus, dass jede benutzerbezogene App unzulässig ist oder eine bestimmte vorinstallierte App jeden Fehler 0x80073cf2 verursacht.
Sysprep-Fehler 0x80073cf2 gezielt beheben
Die Referenzumgebung vor Paketänderungen sichern
Das Deinstallieren einer App verändert die Quellumgebung und kann sich auf deren Daten auswirken. Stellen Sie vorab sicher, dass eine nutzbare Sicherung vorhanden ist und Sie benötigte Anwendungen wiederherstellen können. Verwenden Sie einen Snapshot nur, wenn Ihr Verfahren für den Referenzcomputer dies unterstützt.
Dokumentieren Sie das fehlerauslösende Paket, betroffene Konten, den Windows-Build und bisherige Änderungen. Verhindern Sie während der abschließenden Vorbereitung und Image-Erfassung, dass Store-Downloads oder Updates neue Paketversionen einbringen. Je nach Arbeitsablauf kann es sinnvoll sein, die Internetverbindung des Referenzcomputers vorübergehend zu trennen. Daraus folgt keine Empfehlung, verteilte Computer dauerhaft ohne Updates zu betreiben.
Nur das ermittelte Paket im betroffenen Konto entfernen
Orientieren Sie sich an den zuvor ermittelten Kontoinformationen. Melden Sie sich für eine gezielte benutzerbezogene Entfernung im betroffenen Konto an und öffnen Sie Windows PowerShell im Kontext dieses Kontos. Wenn Sie PowerShell mit den Anmeldedaten eines anderen Administrators starten, bezieht sich ein Vorgang für den aktuellen Benutzer auf dieses andere Konto.
Legen Sie den genauen Paketnamen erneut fest, falls Sie eine neue Sitzung geöffnet haben. Prüfen Sie die aktuelle Benutzeridentität und die passende Installation:
whoami
$packageFullName = 'PASTE_EXACT_PACKAGE_FULL_NAME_FROM_LOG'
Get-AppxPackage -PackageTypeFilter Main,Framework,Resource,Bundle |
Where-Object { $_.PackageFullName -eq $packageFullName } |
Format-List Name,PackageFullName
Wenn das gewünschte Paket vorhanden ist und Sie bestätigt haben, dass es entfernt werden kann, führen Sie diesen Befehl aus:
Remove-AppxPackage -Package $packageFullName -Confirm
Sind mehrere Konten betroffen, bearbeiten Sie die durch die Abfrage ermittelten Installationen. Löschen Sie Benutzerkonten nicht als routinemäßige Abkürzung. Bevor ein Administrator eine umfassendere Entfernung wählt, muss er die Auswirkungen auf alle betroffenen Benutzer berücksichtigen.
Schlägt die Entfernung fehl, bewahren Sie die vollständige Fehlermeldung auf und nutzen Sie den passenden Prüfhinweis weiter unten. Löschen Sie stattdessen nicht manuell die Dateien der App.
Die Bereitstellung im Image vor dem Entfernen des Eintrags prüfen
Wechseln Sie zurück zu einer Windows PowerShell-Sitzung mit Administratorrechten. Setzen Sie den zuvor aus der Liste installierter Pakete notierten Wert Name ein:
$appName = 'PASTE_NAME_FROM_INSTALLED_PACKAGE_LIST'
Get-AppxProvisionedPackage -Online |
Where-Object { $_.DisplayName -eq $appName } |
Select-Object DisplayName,PackageName
Prüfen Sie die Ausgabe, bevor Sie eine weitere Änderung vornehmen. Existiert ein passender Bereitstellungseintrag und gehört dessen Entfernung zum gewählten Reparaturweg, übernehmen Sie seinen tatsächlichen Wert PackageName in diesen Befehl:
Remove-AppxProvisionedPackage -Online -PackageName 'PASTE_EXACT_PROVISIONED_PACKAGE_NAME'
Verwenden Sie die Kennung aus der Abfrage der bereitgestellten Pakete. Deren Version kann von der Benutzerinstallation abweichen, sodass die beiden Entfernungsbefehle unterschiedliche Zeichenfolgen benötigen. Stimmen die Anzeigenamen nicht direkt überein, prüfen Sie die vollständige Liste der bereitgestellten Pakete und bestätigen Sie die Identität der Anwendung, bevor Sie einen Eintrag auswählen.
Laut Microsofts Referenz zu Remove-AppxProvisionedPackage verhindert das Entfernen der Bereitstellung, dass dieses Paket für neue Konten installiert wird. Es ersetzt nicht die Deinstallation aus vorhandenen Konten.
Ist kein passendes bereitgestelltes Paket vorhanden, gibt es keinen entsprechenden Eintrag, den Sie mit diesem Befehl entfernen können. Prüfen Sie stattdessen die verbliebene Benutzerinstallation und das aktuelle Protokoll weiter. Erweitern Sie den Filter nicht so lange, bis er unbeteiligte Pakete erfasst.
Wird die Anwendung im fertigen Image benötigt, planen Sie eine vom Hersteller unterstützte Neuinstallation oder erneute Bereitstellung und prüfen Sie das Ergebnis vor der Image-Erfassung. Geben Sie kein Image weiter, in dem eine erforderliche Anwendung unbemerkt fehlt.
Den Vorgang wiederholen und das neue Protokoll auswerten
Wiederholen Sie nach den gezielten Änderungen Ihren Sysprep- oder Image-Erfassungsvorgang. Prüfen Sie anhand des neuen Protokolls das Ergebnis:
- Der ursprüngliche Paketfehler ist verschwunden: Prüfen Sie, ob der Vorgang vollständig abgeschlossen wird.
- Ein anderes Paket wird genannt: Untersuchen Sie dieses Paket und seine Benutzer gesondert.
- Dasselbe Paket wird weiterhin genannt: Prüfen Sie erneut die zugehörigen Konten, die Version und den Bereitstellungsstatus.
- Eine andere Komponente schlägt fehl: Gehen Sie diesem Fehler nach, statt die Appx-Entfernung zu wiederholen.
Erstellen Sie nach erfolgreicher Vorbereitung ein neues Image des erreichten Zustands und testen Sie es auf einem Testcomputer. Ein bereits erfasstes Image übernimmt spätere Änderungen am Referenzsystem nicht automatisch.
Wenn das Paket fehlt oder sich nicht entfernen lässt
Wählen Sie die nächste Prüfung anhand des tatsächlich beobachteten Zustands. Beschränken Sie Änderungen auf das, was sich aus dem aktuellen Fehler ableiten lässt.
| Feststellung | Nächste Prüfung |
|---|---|
| Die Abfrage für den aktuellen Benutzer bleibt leer, die Abfrage für alle Benutzer findet das Paket jedoch | Prüfen Sie das angegebene Konto und die Benutzeridentität, unter der PowerShell ausgeführt wird. |
| Die Abfrage mit der genauen Kennung liefert keinen Treffer | Vergleichen Sie die vollständige Kennung mit dem neuesten Protokoll, einschließlich Version und Architektur. Prüfen Sie verfügbare Pakettypen und Einträge, bevor Sie etwas entfernen. |
| Es erscheint kein passender Bereitstellungseintrag | Prüfen Sie die Installationen vorhandener Benutzer. Eine App kann für einen Benutzer installiert bleiben, obwohl ihre Bereitstellung bereits entfernt wurde. |
| Mehrere Versionen oder Paketeinträge erscheinen | Ordnen Sie jeden Eintrag seiner tatsächlichen Kennung und seinem Konto zu. Ähnliche Namen sind nicht austauschbar. |
| Windows meldet, dass sich das Paket nicht entfernen lässt | Sichern Sie die Fehlermeldung und untersuchen Sie die betroffene Komponente und den Windows-Build. Stellen Sie die Referenzumgebung wieder her, wenn weitere Änderungen benötigte Funktionen beschädigen würden. |
| Beim nächsten Versuch blockiert ein anderes Paket den Vorgang | Ermitteln Sie die Details des neuen Pakets, statt alle verbliebenen Apps auf einmal zu löschen. |
Übernehmen Sie nicht den Besitz von WindowsApps, löschen Sie keine Paketdatenbanken und bearbeiten Sie keine Sysprep-Statusdaten, um einen erfolgreichen Durchlauf zu erzwingen. Solche Eingriffe umgehen die zu untersuchenden Paketzustände und erschweren die Beurteilung der resultierenden Umgebung.
Store-App-Änderungen während der Image-Erfassung vermeiden
Sobald die Referenzumgebung funktioniert, halten Sie den Zeitraum zwischen den letzten Prüfungen und der Image-Erfassung unter Kontrolle. Schließen Sie geplante Anwendungsänderungen ab, dokumentieren Sie benötigte Pakete und vermeiden Sie in dieser Phase Store-Sitzungen sowie zusätzliche Testprofile.
Trennen Sie die Image-Vorbereitung von der regulären Wartung der Zielcomputer. Eine vorübergehende Begrenzung von Store-Aktivitäten während der Erfassung sollte nicht dazu führen, dass verteilte Anwendungen dauerhaft keine Sicherheitsupdates erhalten.
Bewahren Sie mit dem Referenzimage ein kurzes Änderungsprotokoll auf: Windows-Build, benötigte Apps, Paketänderungen, Erfassungsdatum und Testergebnis. Tritt das Problem nach einer Aktualisierung erneut auf, lässt sich damit leichter feststellen, was sich geändert hat.
Melden Sie sich auf einem repräsentativen Zielcomputer mit dem vorgesehenen Konto an und starten Sie die benötigten Anwendungen. Eine erfolgreiche Image-Erfassung und eine tatsächlich nutzbare Anwendungsumgebung auf dem Zielcomputer sind zwei getrennte Prüfpunkte.
Die vorhandene Windows-Umgebung samt Apps verteilen
Wenn Sie eine Windows-Umgebung mit bereits eingerichteten Anwendungen und Konten auf weitere PCs übertragen möchten, bietet Wittytool Disk Clone einen Weg ohne vorherige Sysprep-Ausführung. Sie können das konfigurierte Quellsystem sichern und dieses Image auf mehrere PCs verteilen. Dabei lassen sich bei Bedarf die Windows-SIDs der Zielcomputer ändern.
Unsere Image-Verteilung kann Anwendungen, lokale Konten, Einstellungen und Microsoft Store-App-Inhalte aus dem Quellimage übernehmen. Anwendungsaktivierungen, Cloud-Anmeldungen und Geräteregistrierungen müssen Sie auf den Zielcomputern gesondert prüfen. Das Verfahren bildet den erfassten Zustand nach; eine bereits auf dem Quellsystem fehlerhafte App wird dadurch nicht repariert.
Laden Sie Wittytool Disk Clone herunter und sichern Sie das Quellsystem, um die bereits erstellte Konfiguration vor der Vorbereitung der nächsten PC-Gruppe zu bewahren. Anschließend können Sie die erfasste Umgebung und die SID-Einstellungen der Zielcomputer zunächst in einer kleinen Testverteilung prüfen.
Sichern Sie vor dem Anschließen der Zielcomputer alle dort benötigten Dateien und überprüfen Sie den Zieldatenträger. Die Image-Verteilung löscht dessen vorhandene Partitionen und schreibt das Image. Die Übernahme von Anwendungen aus dem Quellsystem bewahrt keine Dateien, die sich bereits auf diesem Zieldatenträger befinden.
Der Ablauf umfasst das Erstellen eines Systemimages mit Wittytool Disk Clone, das Einrichten des Verteilungsservers, das Verbinden der Clients, die Prüfung der Zieleinstellungen und die Validierung der wiederhergestellten Systeme. Verwenden Sie ein mit Wittytool Disk Clone erstelltes Image. Unsere Anleitung zum Verteilen einer eingerichteten Windows-Umgebung ohne Sysprep erläutert den vollständigen Ablauf.
Häufig gestellte Fragen
Was verursacht den Sysprep-Fehler 0x80073cf2?
Wenn das neueste Sysprep-Protokoll ein Appx-Paket nennt, kann der Fehler auf eine Abweichung zwischen der App-Installation eines Benutzers und dem Bereitstellungsstatus im Image hinweisen. Prüfen Sie das genaue Paket und die betroffenen Konten, bevor Sie einen Reparaturweg wählen.
Muss ich alle Microsoft Store-Apps entfernen?
Nein. Beginnen Sie mit dem Paket aus dem aktuellen Protokoll. Prüfen Sie, für welche Benutzer es installiert ist und wie es im Image bereitgestellt wird. Nehmen Sie anschließend gezielte Änderungen vor. Das Entfernen unbeteiligter Apps kann die Referenzumgebung verändern, ohne die eigentliche Fehlerursache zu beheben.
Warum fehlt die App in Get-AppxProvisionedPackage?
Eine App kann für einen vorhandenen Benutzer installiert bleiben, nachdem ihre Bereitstellung im Image entfernt wurde. Prüfen Sie außerdem, ob Sie den richtigen Namen und die richtige Version vergleichen. Ein fehlender Bereitstellungseintrag belegt nicht, dass auch die Benutzerinstallation entfernt wurde.
Warum schlägt Sysprep nach dem Entfernen eines Pakets erneut fehl?
Ein weiteres Paket kann den nächsten Versuch blockieren. Ebenso kann das ursprüngliche Paket noch für ein anderes Konto vorhanden sein. Lesen Sie das neueste Protokoll und vergleichen Sie die tatsächlichen Paketeinträge, bevor Sie weitere Änderungen vornehmen.
Kann ich die aktuelle Windows-Umgebung verteilen, ohne zuvor ihre Apps zu entfernen?
Wittytool Disk Clone kann ein Image des eingerichteten Systems erstellen und ohne vorherige Sysprep-Ausführung verteilen. Anwendungen und Konten aus der Quellumgebung bleiben dabei erhalten. Sichern Sie vor der Verteilung die Daten der Zielcomputer und prüfen Sie anschließend die Funktion der Anwendungen, ihre Aktivierung und die Anmeldungen auf den wiederhergestellten Computern.