Windows Server 2012 をクローンした環境で Sysprep を実行すると、「a fatal error occurs while trying to sysprep the machine」で止まることがあります。まずは不要レジストリキー削除を試し、改善しない場合は Setuperr.log で原因を確定し、Rearm 回数制限なら参照イメージの再構築が近道です。
現象：クローン後の Sysprep が「fatal error」で完了しない
仮想マシン（Hyper-V / VMware など）や物理サーバーのディスクをクローンして環境を複製したあと、Sysprep（システム準備ツール）を実行すると途中で停止し、次のようなメッセージが表示されることがあります。
a fatal error occurs while trying to sysprep the machineネット上では「SysprepStatus のレジストリ値を変更する」「Panther フォルダを消す」といった対処が紹介されがちですが、症状だけが一時的に変わっても根本原因が残ると再発します。特に Windows Server 2012 は運用年数が長い環境も多く、参照イメージ（テンプレート）の作り方とログの読み方が勝敗を分けます。
Sysprep がクローンで重要になる理由
Sysprep（/generalize）は、複製した OS を「別マシンとして起動できる状態」に整えるために、マシン固有情報のリセットや初回起動処理（OOBE）の準備を行います。クローン運用では必須級の工程ですが、その分、OS の状態が少しでも「一般化に不向き」だと失敗しやすいのも事実です。
| 用語 | ざっくり意味 | 今回のポイント |
|---|---|---|
| クローン | ディスク/VM を丸ごと複製して同一状態の環境を作る | 同じ参照イメージを繰り返し触るほど、Sysprep が失敗しやすくなる |
| Sysprep /generalize | OS を一般化して別マシン配布できる形にする | 一般化の回数制限（Rearm など）に引っかかると「fatal error」になりやすい |
| Panther ログ | Sysprep の処理ログ | 「なぜ fatal error なのか」はログ末尾に出ることが多い |
最初に試す対処：レジストリの不要キー削除
「とにかく早く復旧したい」「まずは低リスクの手を打ちたい」という場合、最初に試しやすいのが SysPrepExternal\Cleanup の不要キー削除です。クローンや中断を挟んだ環境では、外部クリーンアップ情報が不整合を起こしているケースがあります。
対象キー（存在する場合のみ）
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Setup\SysPrepExternal\Cleanup手順（安全に進めるコツ込み）
- （可能なら）仮想環境はスナップショット、物理はバックアップを取得します。
- 管理者権限で regedit を起動します。
- 該当キーを右クリックし、エクスポートで .reg を保存（復旧用）。
- キー
...\SysPrepExternal\Cleanupを削除します。 - Sysprep を再実行します（後述の「ログ確認」もセットで行うのがおすすめです）。
ポイント：この対処で直るなら「状態ファイルのゴミ」が原因だった可能性が高いです。一方、ここで改善しない場合はレジストリをさらに深掘りするより、ログから原因を確定した方が早く、再発も減ります。
確実な切り分け：Setuperr.log / Setupact.log を必ず確認する
Sysprep の「fatal error」は表示メッセージだけでは原因が分かりません。確実に前へ進めるには、Panther ログの末尾を見て「どのフェーズで失敗したか」「何を例外として扱ったか」を掴む必要があります。
まず見るログ（最重要）
- Setuperr.log：エラー要点がまとまる（短いので最初に見る）
- Setupact.log：動作ログ（長いが手掛かりが増える）
保存場所
C:\Windows\System32\Sysprep\Panther\Setuperr.log
C:\Windows\System32\Sysprep\Panther\Setupact.log最短でログ末尾を見る方法
GUI なら Notepad で開いて末尾へ移動します。CLI で素早く見るなら次のように実行します。
notepad C:\Windows\System32\Sysprep\Panther\Setuperr.log
type C:\Windows\System32\Sysprep\Panther\Setuperr.logSetupact.log は巨大になりがちなので、「SYSPRP」などで絞ると読みやすくなります。
findstr /i SYSPRP C:\Windows\System32\Sysprep\Panther\Setupact.logログの読み方：よく出るキーワードと次の一手
| ログ末尾で見つかりやすい語 | 示唆する原因 | 次にやること |
|---|---|---|
| rearm / Rearm / SPP / Software Protection | ライセンス再アーム回数制限・ライセンス関連の一般化失敗 | Rearm 残回数の確認 → 0 なら参照イメージ再構築が現実的 |
| Pending / reboot required / reboot pending | 再起動待ち（更新・ロール追加・ドライバ）が残っている | 再起動 → 更新完了 → もう一度 Sysprep |
| Access is denied / 0x5 | 権限不足、セキュリティソフトや保護機能の干渉 | 管理者で実行、保護ソフト一時停止、サービス状態確認 |
| Unattend / parse / invalid | unattend.xml の構文・値不正 | unattend を最小化し、まず Sysprep 単体で通るか検証 |
| CleanupState / GeneralizationState | 中断した Sysprep の「状態」だけが残っている可能性 | 状態の修正より、まず Setuperr の直前行で根本原因を探す |
コツ：ログの「最後の 20〜50 行」に、失敗直前の処理と例外が並びます。ネット情報を片っ端から試すより、ここを見て原因クラスを決める方が最短ルートです。
根本原因の筆頭：Rearm 回数制限（同一イメージで 3 回超え）
Windows Server 2012 の Sysprep 失敗で特に多いのが、Software Licensing Rearm（ライセンス再アーム）の回数制限に起因するものです。クローン運用で同じ参照イメージを長く使い、検証のたびに Sysprep（/generalize）を繰り返すと、ある日突然「fatal error」で止まります。
Rearm とは何か（Sysprep とどう関係するか）
Rearm は、ライセンス認証や評価期間などの内部状態をリセットする仕組みに関係します。Sysprep の一般化（/generalize）はこの仕組みと連動しており、同一インストールに対して実行できる回数に上限があります。上限に達した状態で一般化を実行すると、Sysprep は途中で失敗しやすくなります。
Rearm 制限を疑うべき典型パターン
- 長年使っているテンプレート VM を「起動→調整→Sysprep→配布」を繰り返している
- 検証のたびに Sysprep を何度も回している（戻す運用がなく、同じ OS を延命している）
- クローン元が「一度 Sysprep 済み」なのに、クローン後に再度 Sysprep を回そうとしている
確認方法：Rearm 残回数の目安を見る
環境により表示項目は異なりますが、コマンドでライセンス状態を確認すると、Rearm の残回数が判断材料になります。
cscript //nologo %windir%\system32\slmgr.vbs /dlv出力の中に Remaining Windows rearm count（残り再アーム回数）に相当する情報が出ることがあります。残回数が 0 に近い、あるいはログに rearm 関連の失敗が出ている場合は、レジストリ小細工より再構築が結果的に早いケースが大半です。
重要：Rearm 制限に達している場合、一般化に失敗するのは「Sysprep の不具合」ではなく、OS 側の仕様・状態に近いです。そのため、無理に通そうとするより、クリーンな状態から参照イメージを作り直す方がトラブルが激減します。
| 状況 | おすすめの判断 | 理由 |
|---|---|---|
| Setuperr.log に rearm / licensing 関連が明確に出ている | 参照イメージ再構築を優先 | 原因が設計レベルで、対処しても再発しやすい |
| 残回数が少ない（または不明だがテンプレ運用が長い） | スナップショット復帰運用へ切り替え | 同じ OS を触り続ける運用が失敗の温床 |
| テンプレを作ってから Sysprep は初回 | ログから別要因を疑う | Rearm 以外（更新待ち等）の可能性が高い |
「レジストリをいじっても直らない」時に陥りやすい落とし穴
Sysprep の fatal error を検索すると、SysprepStatus（CleanupState / GeneralizationState）の値を変更する方法が出てきます。これで動くこともありますが、クローン環境では次の罠があります。
- 状態だけ直しても原因が残る：次回の Sysprep でまた失敗する
- ログがさらに読みにくくなる：本当の失敗ポイントが見えにくくなる
- 運用が破綻する：「直し方」が人依存になり、再現性が落ちる
どうしても状態修正を試すなら、必ずスナップショット/バックアップの上で行い、成功したとしても「なぜ通ったのか」を Setuperr.log で確認してください。原因が Rearm 制限だった場合は、たまたま通ったとしても将来また詰まります。
クローン環境で Sysprep を通すための事前チェック
Rearm 以外にも、Sysprep の一般化を邪魔する要素はいくつかあります。ここでは Windows Server 2012 で実務的に効くチェック項目をまとめます。まずは「再起動すれば消えるもの」「設定で回避できるもの」から潰すのがコツです。
| チェック項目 | なぜ失敗につながるか | 確認方法（例） | 対処の方向性 |
|---|---|---|---|
| 再起動待ち（更新/ロール/ドライバ） | 一般化中のコンポーネント処理が完了せず停止しやすい | 更新適用直後か、最近ロール追加したかを確認 | 必ず再起動 → 更新が残っていない状態で Sysprep |
| セキュリティソフト/エージェント | Sysprep が触るファイル・レジストリをロックすることがある | Setuperr に Access denied 系が出る | 参照イメージでは最小構成にし、配布後に導入する |
| ドメイン参加済み | ドメイン関連のポリシーや証明書が一般化の邪魔になる場合がある | クローン元がドメイン参加していないか | 参照イメージはワークグループで作成し、配布後に参加 |
| 独自の unattend.xml | 値不正・設定矛盾で Sysprep 自体が止まる | unattend を外して Sysprep 単体で通るか | 一度最小化し、段階的に項目を戻す |
| 中途半端なクローン（スナップショット復元直後など） | Sysprep の前提となる「クリーンな状態」から外れる | 最近の運用履歴を洗う | 参照イメージの作り方を固定し、作業ログを残す |
最低限の「再現性ある」検証手順
個別要因を疑う前に、同じ条件で再現するかを押さえると切り分けが速くなります。
- クローン直後の VM を一度も余計に触らず、Sysprep を実行して失敗するか確認する
- 失敗したら、Setuperr.log の末尾を保存（後から比較できるように）
- 対処を 1 つだけ適用 → 再実行 → ログ差分を確認（同時に複数手を入れない）
この「1変更→1回検証」を守ると、ネット情報より早く原因に到達できます。
Rearm 制限が原因だった場合：参照イメージを再構築するのが最短
Rearm 制限に達している、またはログがライセンス関連の失敗を示している場合、根本解決は参照イメージ（ゴールデンイメージ）の作り直しです。遠回りに見えても、後工程の不具合（ライセンス、更新、エージェント）をまとめて消せるため、結果的に工数が減ります。
参照イメージ再構築のおすすめ手順
- 新規 VM（または新規インストール）で Windows Server 2012 をクリーンセットアップ
- 必要な更新（Windows Update）を適用し、再起動を繰り返して「更新待ちゼロ」にする
- 共通で必要なアプリ/ドライバのみ導入（参照イメージは「最小構成」が基本）
- サーバー固有になる設定（固定 IP、ホスト名、ドメイン参加、監視設定など）は入れない
- Sysprep を /generalize で実行し、完了後はシャットダウン
- シャットダウンした状態をテンプレ化（VHD コピー、テンプレート登録、イメージキャプチャ）
Sysprep 実行例（実行オプションは環境に合わせて調整）
%windir%\System32\Sysprep\sysprep.exe /generalize /oobe /shutdown運用のコツ：参照イメージの調整が必要になったら、Sysprep 前のスナップショットに戻って作業し、同じ OS インスタンスに対して Sysprep を何度も回さない運用に切り替えます。これだけで「突然 Sysprep が通らない」事故は大きく減ります。
再発防止：Sysprep を繰り返さない運用設計
クローン配布が安定するかどうかは、Sysprep の手順そのものよりも「参照イメージをどう育てるか」に依存します。場当たりでテンプレ VM を更新すると、Rearm 制限だけでなく、更新の積み残しやエージェントの状態不整合で Sysprep が壊れやすくなります。
おすすめの運用モデル（よくある失敗を避ける）
| 工程 | やること | やらないこと |
|---|---|---|
| 参照イメージ作成 | OS + 更新 + 最小限の共通ソフトのみ | ドメイン参加、固定 IP、個別監視設定 |
| 配布後（初回起動） | PowerShell 等でホスト名/IP/ロールを自動設定 | 参照イメージを「個別用途ごと」に分岐させすぎる |
| 参照イメージ更新 | スナップショット復帰→更新適用→テスト→Sysprep→テンプレ更新 | 同一 VM を延命して Sysprep を繰り返す |
| 障害対応 | ログ保全（Setuperr/Setupact）と変更履歴の記録 | 原因不明のまま「レジストリの呪文」を積み上げる |
ログを資産にする（次回のトラブルが早くなる）
Sysprep は失敗してもログが残ります。次の 2 つだけでもテンプレ運用が安定します。
- Sysprep を回すたびに Setuperr.log / Setupact.log を別フォルダへコピーして保管する
- 「いつ、何を変更して Sysprep したか」を簡単でいいのでメモする
これにより、「更新を入れたら失敗した」「エージェントを入れたら失敗した」といった因果関係が追いやすくなります。
よくある質問
Sysprep を実行する順番は「クローン→Sysprep」と「Sysprep→クローン」どちらが正しい？
配布の基本は「Sysprep 済みの参照イメージをクローンして配布」です。クローンしてから Sysprep を回す運用は、各クローン先で個別にエラー要因が混ざるため、切り分けが難しくなります。参照イメージ側で Sysprep を通し、シャットダウンした状態をテンプレ化する方が再現性が高くなります。
Setuperr.log がほとんど空に見える／情報が少ない
Setuperr.log は「エラーの要点」だけが出ることがあり、十分な手掛かりがない場合があります。そのときは Setupact.log を SYSPRP で絞り込むか、ログ末尾の直前直後を広め（数百行）に見てください。エラーは 1 行だけでも、直前の処理が原因を語っていることが多いです。
紹介されているレジストリキーが存在しない
...\SysPrepExternal\Cleanup は環境によって存在しないことがあります。存在しない場合は無理に作る必要はありません。削除手順は「ある場合に限り」有効な対処で、根本原因が別にある可能性が高いのでログ確認へ進むのが安全です。
CleanupState / GeneralizationState を変更しても直らなかった
その場合、状態値の修正は「当たり」ではありません。多くは Rearm 制限や更新待ち、権限・ロックなどの根本要因が別にあります。Setuperr.log の末尾で「どのコンポーネントで止まったか」を確認し、対処を 1 つずつ適用してください。
Rearm 制限が原因なら、回避する裏技はない？
運用上は「裏技」より参照イメージ再構築とスナップショット復帰運用が安定し、トータル工数が下がります。テンプレート運用は、回避策を積み重ねるほど次の担当者が詰まりやすくなるため、再現性のある作り方に寄せるのが結果的に安全です。
まとめ：最短で解決するための優先順位
Windows Server 2012 のクローン環境で Sysprep が「a fatal error occurs while trying to sysprep the machine」で失敗する場合、次の順で進めると迷いにくくなります。
- まずは SysPrepExternal\Cleanup の不要キー削除を試す（低リスク）
- 改善しないなら Setuperr.log / Setupact.log を最優先で確認し、原因クラスを特定する
- ログが Rearm 制限を示すなら、参照イメージ再構築とSysprep を繰り返さない運用へ切り替える
「とりあえずレジストリをいじる」から卒業して、ログ起点で切り分けるだけで、同じ fatal error の再発率は大きく下がります。
コメント