Sysprepのエラー 0x80073cf2 とともにMicrosoft Storeアプリのパッケージがログに記録されている場合は、まず対象パッケージと、それがインストールされているユーザーアカウントを特定します。続いてプロビジョニング状態を確認し、必要な箇所だけを修正してから再試行します。最初からすべてのStoreアプリを削除する必要はありません。
この記事は、最新のSysprepログがAppxパッケージの問題を示しているWindows 11／Windows 10環境を対象としています。パッケージを変更する前に、マスターPCの環境と必要なアプリデータを復元できる形で保存してください。当社のWindows環境のバックアップ・展開ソフトでは、トラブルシューティング前の状態をシステムイメージとして保存できます。
SysprepログでStoreアプリのエラーを確認する
直近の実行に対応するsetupact.logとsetuperr.logを読む
マスターPCで次のフォルダーを開きます。
%WINDIR%\System32\Sysprep\Panther\
setupact.logとsetuperr.logで、直近の失敗時刻付近の記録を確認します。0x80073cf2、0x3cf2、Appx関連のエラー、パッケージ識別子を探してください。特に手がかりになるのは、次の英語メッセージです。
was installed for a user, but not provisioned for all users
これは、特定ユーザーにインストールされたパッケージが、すべてのユーザー向けにはプロビジョニングされていないことを示します。その実行時のログから、バージョンとアーキテクチャを含む完全なパッケージ識別子をコピーしてください。再試行の前にログも別途保存します。過去の失敗で記録されたパッケージ名が、現在の原因と一致するとは限りません。
最新の記録が別のコンポーネントやエラーを示している場合は、その原因を調べます。Windowsのインストールを検証できなかったという一般的なダイアログだけでは、Storeアプリ向けの対処が適切とは判断できません。
対象パッケージと影響を受けるユーザーを特定する
次の確認は、Windows PowerShellを管理者として実行して行います。大文字のプレースホルダーを、ログからコピーした完全なパッケージ名に置き換えてください。
$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
このコマンドは情報の取得のみを行います。PackageUserInformationで、どのアカウントにパッケージがインストールされているかを確認してください。後でプロビジョニングを調べる際に使う短い識別名として、Nameの値も控えます。
Get-AppxPackage -AllUsersは、複数のアカウントにわたるパッケージ情報を表示するコマンドで、アンインストールは行いません。一方、削除コマンドに-AllUsersを付けると、影響範囲が広がります。確認用コマンドのパラメーターを、そのまま削除用コマンドへ移さないでください。
StoreアプリがSysprepエラー0x80073cf2を引き起こす理由
ユーザーのインストール状態とイメージのプロビジョニング状態は異なる
Storeアプリには、既存ユーザーへのインストールと、Windowsイメージ内のプロビジョニング済みパッケージという、関連する別々の状態があります。プロビジョニングとは、新しいユーザーにアプリをインストールするための準備です。
| 状態 | 確認する内容 | PowerShellの確認コマンド |
|---|---|---|
| ユーザーにインストール済み | 既存のユーザープロファイルに登録されたアプリパッケージ | Get-AppxPackage |
| イメージにプロビジョニング済み | 新しいユーザーの作成時にインストールするために準備されたパッケージ | Get-AppxProvisionedPackage -Online |
自分のアカウントでアプリが起動できても、両方の状態が整合しているとは限りません。これらのDISMコマンドの-Onlineは、現在起動しているWindows環境を指し、インターネットサービスを意味するものではありません。
アップデートや一部だけの削除で状態が食い違うことがある
たとえば、ユーザーがアプリを更新しても、イメージ側には別バージョンのプロビジョニング済みパッケージが残る場合があります。また、プロビジョニングだけを削除し、ユーザーのインストールが残っている場合もあります。MicrosoftのStoreアプリによるSysprep失敗の解説では、こうした状態がSysprepのAppx処理を中断させる仕組みを説明しています。
確認すべきなのは、そのマスターPCでどのパッケージの状態が食い違っているかです。ユーザーごとにインストールされたアプリがすべて問題になる、あるいは特定の標準搭載アプリがすべての0x80073cf2エラーを引き起こす、と決めつけないでください。
全アプリを削除せずにSysprepエラー0x80073cf2へ対処する
パッケージを変更する前にマスターPCの環境を保存する
アプリをアンインストールすると、展開元の環境が変わり、アプリのデータにも影響する可能性があります。 作業前に、利用できるバックアップがあることと、必要なアプリを復元する方法を確認してください。スナップショットは、マスターPCの運用で対応している場合に限って使用します。
原因となったパッケージ、対象アカウント、Windowsのビルド、すでに行った変更を記録します。最終確認からイメージ取得までの間は、Storeのダウンロードや更新によって新しいパッケージバージョンが追加されないように管理してください。作業方法によっては、マスターPCのインターネット接続を一時的に切断する方法もあります。展開後のPCを更新せずに運用することを勧めるものではありません。
対象アカウントから特定したパッケージだけを削除する
最初の確認で取得したアカウント情報を使います。特定ユーザーのインストールを削除する場合は、そのアカウントにサインインし、そのアカウントの実行コンテキストでWindows PowerShellを開いてください。別の管理者の資格情報でPowerShellを実行すると、現在のユーザーを対象とする操作の対象アカウントが変わります。
新しいセッションを開いた場合は、完全なパッケージ名を再設定します。現在のユーザーと、該当するインストールを確認してください。
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
目的のパッケージが存在し、削除してよいことを確認できた場合は、次を実行します。
Remove-AppxPackage -Package $packageFullName -Confirm
複数のアカウントが対象となる場合は、確認結果で特定した各インストールに対処します。手早く済ませるためにユーザーアカウントを削除しないでください。管理者がより広い範囲の削除を選ぶ場合は、影響を受けるすべてのユーザーを先に確認する必要があります。
削除に失敗した場合は、エラーメッセージを全文保存し、後述の該当する確認項目へ進みます。代わりにアプリのファイルを手動で削除しないでください。
イメージ側のプロビジョニングを確認してから該当する項目を削除する
管理者権限のWindows PowerShellセッションに戻ります。インストール済みパッケージの一覧で控えたNameを指定してください。
$appName = 'PASTE_NAME_FROM_INSTALLED_PACKAGE_LIST'
Get-AppxProvisionedPackage -Online |
Where-Object { $_.DisplayName -eq $appName } |
Select-Object DisplayName,PackageName
次の変更を行う前に、出力を確認します。対応するプロビジョニング済みパッケージが存在し、その削除が選んだ対処方法に含まれる場合は、出力された実際のPackageNameを次のコマンドに指定します。
Remove-AppxProvisionedPackage -Online -PackageName 'PASTE_EXACT_PROVISIONED_PACKAGE_NAME'
プロビジョニング済みパッケージの取得結果にある識別子を使ってください。ユーザーにインストールされたパッケージとはバージョンが異なることがあるため、2つの削除コマンドで別々の文字列を指定する場合があります。表示名が直接一致しない場合は、プロビジョニング済みパッケージの一覧全体を確認し、アプリの識別情報を確かめてから選択します。
MicrosoftのRemove-AppxProvisionedPackageリファレンスによると、プロビジョニングの削除は、そのパッケージが新しいアカウントにインストールされないようにする操作です。既存アカウントからのアンインストールの代わりにはなりません。
対応するプロビジョニング済みパッケージがなければ、このコマンドで削除する該当項目はありません。残っているユーザーのインストールと最新ログを引き続き調べてください。無関係なパッケージが一致するまでフィルターを広げないようにします。
最終イメージに必要なアプリであれば、提供元がサポートする方法での再インストールや再プロビジョニングを計画し、イメージ取得前に結果を検証します。必要なアプリが欠けていることに気づかないまま、イメージを引き渡さないでください。
再試行後は新しいログを読んでから次の変更を判断する
対象を絞った修正が終わったら、Sysprepまたはイメージ取得の処理を再試行します。新しいログを読み、結果を判断してください。
- 元のパッケージエラーがなくなった場合： 処理が最後まで完了するか確認します。
- 別のパッケージが記録された場合： そのパッケージとインストール先のユーザーを個別に確認します。
- 同じパッケージが記録された場合： インストール先アカウント、バージョン、プロビジョニング状態を再確認します。
- 別のコンポーネントで失敗した場合： Appxの削除を繰り返すのではなく、そのエラーを調べます。
準備が成功したら、修正後の状態から新しいイメージを取得し、テスト用PCで検証します。以前に取得したイメージには、マスターPCに後から加えた変更は反映されません。
パッケージが見つからない、または削除できない場合
実際に確認できた状態に応じて、次の確認項目を選びます。変更は、現在のエラーから判断できる範囲にとどめてください。
| 確認できた状態 | 次に調べること |
|---|---|
| 現在のユーザー向けの取得結果は空だが、全ユーザー向けの取得結果にはパッケージがある | 一覧にあるアカウントと、PowerShellを実行しているユーザーを確認します。 |
| 完全な識別子を指定しても結果がない | バージョンとアーキテクチャを含め、最新ログの完全な識別子と比較します。削除前に、取得対象のパッケージの種類や一覧の項目も確認します。 |
| 対応するプロビジョニング済みパッケージが表示されない | 既存ユーザーへのインストールを確認します。プロビジョニングが削除済みでも、ユーザーのインストールは残る場合があります。 |
| 複数のバージョンやパッケージ情報が表示される | 各項目の実際の識別情報と対象アカウントを照合します。似た名前の項目を同じものとして扱わないでください。 |
| Windowsからパッケージを削除できないと通知される | エラーを保存し、対象コンポーネントとWindowsのビルドを調べます。さらに変更すると必要な機能が損なわれる場合は、マスターPCの環境を復元します。 |
| 次の実行で別のパッケージが原因になる | 残ったアプリを一括削除せず、新しく記録されたパッケージを特定し直します。 |
処理を無理に通すために、WindowsAppsの所有権を取得したり、パッケージデータベースを削除したり、Sysprepの状態情報を書き換えたりしないでください。把握すべきパッケージ状態の確認を迂回することになり、変更後の環境を評価しにくくなります。
イメージ取得までStoreアプリの状態を変えない
マスターPCの環境が正常になったら、最終確認からイメージ取得までの状態を管理します。予定していたアプリの変更を完了し、必要なパッケージを記録してください。その間はStoreのセッションを開いたり、追加のテスト用プロファイルを作成したりすることを避けます。
イメージの準備と、展開先PCの日常的な保守は分けて考えます。取得時のStore動作の一時的な制限を、展開後のアプリに更新プログラムを適用しない恒久的な運用にしないでください。
マスターイメージとともに、Windowsのビルド、必要なアプリ、パッケージの変更内容、取得日、テスト結果を簡潔に記録しておきます。イメージを更新した後に同じ問題が再発したとき、変更点を探しやすくなります。
代表的な展開先PCで、利用予定のアカウントにサインインして必要なアプリを起動します。イメージを正常に取得できることと、展開先でアプリ環境が実用できることは、それぞれ確認が必要です。
アプリを含む既存のWindows環境をそのまま展開するには
必要なアプリとアカウントを設定済みのWindows環境を再現したい場合、Wittytool Disk Cloneでは、事前にSysprepを実行せずに展開できます。設定済みの元システムをバックアップし、そのイメージを複数のPCへ展開する方法です。必要に応じて、展開先PCのWindows SIDも変更できます。
当社のイメージ展開では、元イメージのアプリ、ローカルアカウント、設定、Microsoft Storeアプリのコンテンツを引き継げます。アプリのライセンス認証、クラウドサービスへのサインイン、デバイス登録は、展開先で個別に確認が必要です。この方法は取得した環境を再現するものであり、元のPCですでに不具合のあるアプリを修復するものではありません。
次のPC群のキッティングを始める前に、Wittytool Disk Cloneをダウンロードして元システムをバックアップしておけば、作成済みの設定を保存できます。その後、少数のPCへのテスト展開で、取得した環境と展開先のSID設定を確認してください。
展開先PCを接続する前に、必要なファイルをバックアップし、書き込み先ディスクを確認してください。展開時には、選択した展開先ディスクの既存パーティションが削除され、イメージが書き込まれます。 元イメージのアプリを引き継ぐことは、展開先ディスクにすでにあるファイルを保護することではありません。
基本の流れは、Wittytool Disk Cloneでシステムイメージを作成し、展開用サーバーを設定してクライアントを接続し、展開先の設定を確認してから復元したシステムを検証する、という手順です。イメージはWittytool Disk Cloneで作成したものを使用します。詳しい流れは、設定済みのWindows環境をSysprepなしで複数PCへ展開する手順をご覧ください。
よくある質問
Sysprepエラー0x80073cf2の原因は何ですか？
最新のSysprepログにAppxパッケージが記録されている場合、ユーザーにインストールされたアプリと、イメージ内のプロビジョニング状態の不一致が原因となることがあります。対処方法を選ぶ前に、正確なパッケージと対象アカウントを確認してください。
Microsoft Storeアプリをすべて削除する必要がありますか？
いいえ。現在のログに記録されたパッケージから確認します。インストール先のユーザーとプロビジョニング状態を調べ、対象を絞って変更してください。無関係なアプリを削除すると、実際の原因を解決しないままマスターPCの環境が変わる可能性があります。
Get-AppxProvisionedPackageでアプリが表示されないのはなぜですか？
イメージ内のプロビジョニングが削除された後も、既存ユーザーにはアプリのインストールが残る場合があります。比較している名前とバージョンが正しいかも確認してください。プロビジョニング済みの項目がないことは、ユーザーのインストールも削除済みであることを意味しません。
パッケージを1つ削除してもSysprepが再び失敗するのはなぜですか？
次の実行では別のパッケージが原因になっている場合や、元のパッケージが別のアカウントに残っている場合があります。追加の変更を行う前に、最新ログと実際のパッケージ情報を比較してください。
アプリを削除せずに現在のWindows環境を展開できますか？
Wittytool Disk Cloneでは、設定済みシステムのイメージを作成し、事前にSysprepを実行せずに展開できます。元の環境のアプリとアカウントを保持できますが、展開前には展開先のデータをバックアップし、復元後のPCでアプリの動作、ライセンス認証、サインインを確認してください。