Windows Serverのイメージ作成や展開を行う際に欠かせないツールとして知られるSysprepですが、Windows Server 2025 (24H2) ビルド 26100.2314では、特定のアプリケーションが原因でエラーが発生しやすいと報告されています。今回は、このSysprepエラーの原因と対処法を中心に、実務ですぐに役立つ具体的な手順をわかりやすくまとめました。ぜひ最後までご覧いただき、スムーズなイメージ化を実現するためのヒントをつかんでください。
Sysprepの概要と役割
SysprepはWindowsオペレーティングシステムの展開やクローン作成の際に利用される、Microsoft純正の準備ツールです。以下のような場面で特に力を発揮します。
- 大量の同一イメージを複数サーバーへ展開
- 仮想マシンのテンプレートを作成してクローン
- WindowsがプリインストールされたPCを顧客や従業員へ配布
Sysprepを行うことで、OSが固有に保持するSID(Security Identifier)やドライバ、各種構成をリセットし、配布後に新しい環境として問題なく動作させることができます。いわゆる“汎用化(Generalize)”を行うことで、重複SIDによるセキュリティリスクやコンフリクトを防ぎ、確実なライセンス認証やWindowsアップデートが行える状態にするのが目的です。
Windows Server 2025 (24H2)におけるSysprepエラーの特徴
Windows Server 2025 (24H2) ビルド 26100.2314でSysprepを実行すると、特定のストアアプリやユーザー単位でのみインストールされているアプリが原因となりエラーが発生することがあります。特に次のような現象が確認されています。
- 「Generalize」フェーズでの失敗
- ログに
Microsoft.Winget.Source_～のようなパッケージが原因である旨の記載 0x80073cf2などのエラーコードが表示される
これらのエラーは主に、ストアアプリ（Appxパッケージ）が「すべてのユーザーにプロビジョニングされていない」状態で存在している場合に起こるとされています。SysprepはOSイメージの汎用化を行うにあたり、すべてのユーザーに同一状態で提供されているアプリのみが残っていることを求めます。そのため、ユーザーごとにインストールされている状態のアプリがあるとエラーの引き金となるわけです。
エラーのログ出力例
Windowsのセットアップログ（C:\Windows\System32\Sysprep\Panther\setuperr.logなど）を見ると、以下のようなエラーメッセージが確認されます。
Error SYSPRP Package Microsoft.Winget.Source_... was installed for a user,
but not provisioned for all users...
Error SYSPRP Failed to remove apps for the current user: 0x80073cf2.「installed for a user, but not provisioned for all users」というフレーズは、まさにユーザー単位インストールであることを示唆しています。
エラーの原因と背景
ユーザー単位インストールのストアアプリ
Windows 10以降のOSやWindows Serverではストアアプリの配布や更新をWindows Storeに依存するケースが増えています。システム全体にアプリを展開する「プロビジョニング」と、特定のユーザーだけに追加インストールされる「ユーザー単位のインストール」は別の扱いです。
- プロビジョニング(AppxProvisionedPackage)
すべてのユーザーが利用できるようにアプリを組み込む仕組み。OS初期インストール直後や管理者権限での一括配布などにより設定される。 - ユーザー単位インストール(Get-AppxPackage)
ログオンしている特定ユーザーが手動またはストア経由でインストールしたもの。別のユーザーアカウントからは利用できない。
Sysprepでは、OSイメージ汎用化を行うときに「プロビジョニングが不完全なアプリ（特定ユーザーだけがインストールしたアプリ）をどう扱うか」を厳密にチェックします。これが合わないとエラーを返します。
なぜMicrosoft.Winget.Sourceが問題になりやすいのか
Windowsパッケージマネージャー（winget）は比較的新しい仕組みであり、ユーザーごとにインストールが行われる形態をとるケースがあります。特に「Microsoft.Winget.Source_～」というパッケージは、ストアアプリとして管理される部分があり、管理者権限で使用していても環境によってはユーザースコープにのみ存在してしまうことがあります。
このアプリがユーザー単位でのみインストールされていると、SysprepのGeneralizeフェーズで「全ユーザー向けではないアプリがある」と判断され、エラーが発生してしまうのです。
エラー解消のための具体的な対処法
ここからは、実際にエラーを解消するための手順をいくつか紹介します。ポイントは「ユーザー単位インストールのアプリを排除する」か「全ユーザーに正しくプロビジョニングする」かのどちらかです。
1. 不要なアプリのアンインストール
もっとも単純かつ確実な手法が、問題となるアプリをアンインストールしてしまうことです。たとえばMicrosoft.Winget.Source関連のパッケージが原因であれば、PowerShellを管理者権限で起動し、以下のようにコマンドを実行します。
# すべてのユーザーからMicrosoft.Winget.Sourceに関連するパッケージを削除
Get-AppxPackage -AllUsers *Microsoft.Winget.Source* | Remove-AppxPackage -AllUsersもしパッケージ名を特定したうえで削除したい場合には、Remove-AppxProvisionedPackageを使う方法もあります。
Remove-AppxProvisionedPackage -Online -PackageName "Microsoft.Winget.Source_1.4.11071.0_neutral_~_8wekyb3d8bbwe"上記のパッケージ名はあくまで例なので、自環境でGet-AppxPackage -AllUsersやGet-AppxProvisionedPackage -Onlineを実行し、正確な名称を確認してください。
アンインストール時の注意点
- 管理者権限のPowerShellまたはコマンドプロンプトを使用する。
- 対象パッケージが本当に不要かどうかを事前に確認する（システム動作に不可欠なアプリでないことをチェック）。
- アンインストール後は念のためOSを再起動し、
Get-AppxPackage -AllUsersを再度実行して確実に削除されたか確認する。
2. プロビジョニング状態の確認
どうしても対象アプリを残したい場合や、削除ではなく「すべてのユーザーにプロビジョニングしたい」ケースも存在します。たとえば企業や組織内で独自のツールをストアアプリとして配布している場合、単にアンインストールすると運用上のデメリットが生じる可能性があります。
その場合、以下のコマンドでAppxProvisionedPackageを確認してみましょう。
Get-AppxProvisionedPackage -Online | Select DisplayName, PackageName表示される一覧のなかに、問題となるパッケージが含まれていないのであれば、「特定ユーザーのみがインストールしている可能性がある」ということになります。そこで一度アンインストールし、改めて全ユーザー向けにインストール（プロビジョニング）することを検討します。
プロビジョニングを行う例
Add-AppxProvisionedPackage -Online -PackagePath "C:\AppPackages\MyApp.appx" -SkipLicense-PackagePathには、プロビジョニングしたいアプリパッケージのパスを指定- 組織内カタログからの配布やオフラインパッケージの利用時に活用
こうすることで、当該アプリが「すべてのユーザー」に対して提供されるようになり、Sysprep時にエラーを引き起こさなくなる可能性があります。
Microsoft公式ドキュメントと参照情報
Microsoftは公式ドキュメントとして以下のページを提供し、ストアアプリが原因でSysprepに失敗する場合の対策を案内しています。
公式ドキュメントでは、不要なアプリや更新によって問題を起こすアプリをアンインストールしたうえで、再度Sysprepを実行する手順が具体的に解説されています。特に大型アップデートや新しいビルドに移行した際は、ストアアプリの更新がOS内部で同時進行していることも多く、意図せずユーザー単位インストールとなる場合があります。そのため、Sysprepを実行する前に対象サーバーでストアアプリの状態を整理することが重要です。
具体的な手順例：問題アプリ検出からSysprep完了まで
ここでは、実際の運用を想定した例を挙げます。多くのシステム管理者が持つ疑問として、「どのアプリが原因か特定するのが難しい」「アンインストールすべきアプリを正確に見極められない」などがあります。そのため、以下の流れで対応することがおすすめです。
- ストアアプリの現状把握
# 全ユーザーに対するAppxパッケージ一覧
Get-AppxPackage -AllUsers | Select Name, PackageFullName, InstalledLocation
# プロビジョニング設定済みのAppxパッケージ一覧
Get-AppxProvisionedPackage -Online | Select DisplayName, PackageNameこれらのコマンドで、ユーザー単位か全ユーザーかを見比べ、怪しいパッケージを抽出します。
- エラー原因となりやすいアプリの削除（もしくは再プロビジョニング）
- エラー原因となるパッケージが不要な場合:
powershell Get-AppxPackage -AllUsers *パッケージ名の一部* | Remove-AppxPackage -AllUsers - アプリを残したい場合（ただし全ユーザーに適用したい場合）:
# 必要であればアンインストールしてから Remove-AppxPackage -AllUsers # その後、Add-AppxProvisionedPackageで全ユーザー向けにインストール Add-AppxProvisionedPackage -Online -PackagePath "C:\AppPackages\MyApp.appx" -SkipLicense
- OSの再起動と確認
- 必要に応じてWindows Serverを再起動し、変更が正しく適用されたかを確認。
- 再度
Get-AppxPackage -AllUsersを実行し、問題のアプリがユーザー単位インストールとして残っていないかチェック。
- Sysprepの実行
cd C:\Windows\System32\Sysprep
.\sysprep.exe /generalize /oobe /shutdown正しく不要アプリが排除または再プロビジョニングされた状態であれば、エラーなく完了するはずです。もし再度失敗した場合は、ログを詳細に確認し、ほかのパッケージが問題を引き起こしていないか再チェックします。
トラブルシューティングと運用上のヒント
定期的なストアアプリの棚卸し
Windowsサーバー運用においては、「サーバーでストアアプリを頻繁に使うことが少ない」というケースが多々あります。その分、いつの間にかインストールされているストアアプリに気づかず、いざSysprepを実行しようとしたときにエラーになることがしばしばあります。大規模運用や定期メンテナンスのサイクルを設計する際に、ストアアプリの棚卸し作業を含めるとスムーズです。
複数ユーザーアカウントを扱うテスト環境
本番環境を構築する前にテスト環境でイメージ作成を行う場合、複数のテストユーザーアカウントを用意してアプリインストールや更新を試してみると、問題の早期発見に役立ちます。特にサーバー運用では、管理者アカウントと一般ユーザーアカウントが異なる権限セットで動作しているため、どちらにのみインストールされているパッケージがあるかを見落としがちです。
アプリ更新が走っているタイミングに注意
Windowsのセットアップ中や起動直後、バックグラウンドでストアアプリの更新が走っている場合があります。完全に更新が完了する前にSysprepを実行すると、更新途中の状態が原因でエラーになることがあります。運用設計上、Sysprep実行前に一時的にネットワークを切断し、ストアアプリの更新を抑制したり、Windows Updateのタイミングをコントロールするなどの工夫をすることが望ましいです。
表で見るSysprepエラー防止の要点
以下の表に、Sysprepエラーを防ぐためにチェックしておくとよい事項をまとめます。
| チェック項目 | 内容 | 重要度 |
|---|---|---|
| ストアアプリの棚卸し | Get-AppxPackage -AllUsers で不要アプリがないか定期的に確認 | 高 |
| 全ユーザー向けプロビジョニングが正常か | Get-AppxProvisionedPackage -Online でアプリの有無を一覧チェック | 高 |
| OS起動直後の更新を待つか、更新を強制的に停止する | 起動直後にストアアプリやWindows Updateが動いていないか要確認 | 中 |
| テストユーザーアカウントを用いた動作検証 | 複数アカウントでログオンし、アプリのインストール状況を検証 | 中 |
| エラー時のログ確認 | C:\Windows\System32\Sysprep\Panther\setuperr.logなどをチェック | 高 |
このようにあらかじめチェックポイントを明文化し、実施することで、Sysprep実行時に想定外のエラーを回避しやすくなります。
Sysprepエラー解消後のベストプラクティス
Sysprepエラーを解消したあとも、以下のようなベストプラクティスを継続することで、安定したOS展開や運用を行うことができます。
- イメージ化手順のドキュメント化
いつ、どのような環境で、どのアプリを削除または再プロビジョニングしたかを記録し、再現性を高める。 - 定期的な検証
新しいビルドや累積アップデートが入ったとき、Sysprepが問題なく動作するかを定期的にテスト。 - グループポリシーとの連携
企業内ではグループポリシーを使ってストアアプリのダウンロードや自動更新を制御することで、不要なアプリが意図せずインストールされるリスクを下げる。 - 不要サービスの無効化
Windows Store自体が不要な場合、サーバー機として運用するならストア関連サービスや関連機能を無効化・削除しておく運用も検討。
まとめ：ストアアプリ対策が鍵
Windows Server 2025 (24H2)でSysprepエラーに遭遇する場合、その多くはユーザー単位インストールになっているストアアプリが原因であることが分かっています。特に「Microsoft.Winget.Source_～」などのパッケージは比較的新しい仕組みゆえ、知らず知らずのうちにインストールされていることが多く、Sysprep実行時にエラーを引き起こしがちです。
- 不要アプリはPowerShellでアンインストールし、全ユーザーに影響しない状態にする
- 必要があるアプリは全ユーザー向けに再プロビジョニングする
- Sysprep前にストアアプリの棚卸しを習慣化し、バックグラウンド更新の完了を待つ
これらのポイントを押さえるだけで、イメージ作成やサーバークローン時のエラー率が大幅に下がります。特に企業や組織内で複数人がサーバーにログオンする場合は、ユーザーごとの設定が複雑になりがちです。定期的なアプリ管理と検証体制の構築が、よりスムーズな運用を実現してくれるはずです。
コメント