Windows Server 2019でSysprepを行おうとした際、なぜか致命的なエラーが出て作業が進まない――。クローンした仮想マシン環境で遭遇するトラブルとして比較的よく見られます。この記事では、Sysprep失敗のよくある原因や対策を詳しく解説していきます。クローン先で設定変更が必要なケースも多々あり、そのままではSysprepに失敗してしまうこともしばしば。この記事では、初心者から上級者まで役立つよう丁寧に解説します。
Sysprepの基本とWindows Server 2019での注意点
SysprepはWindows OSの初期化を行い、重複SIDなどの問題を解消してクローン環境を量産できる便利なツールです。しかし、Windows Server 2019の仮想マシンにおいては、特にイベントログやレジストリの設定が独自に変更されている場合に、エラーが発生しやすい傾向があります。実稼働環境ではセキュリティや監査要件のためにイベントログの格納先を変更していたり、サービス設定を最適化していたりすることが多いですが、こうした変更がSysprepに影響を与える場合があります。
仮想マシンをクローンすることで作業効率は大きく向上しますが、一方で「Sysprepしないままクローンした環境を増やしてしまう」というリスクを抱えることにもなります。同一のSIDを持つ複数サーバーが存在すると、ドメイン参加などで問題を引き起こすケースがあり、その対策としてSysprepはほぼ必須です。そこで、Windows Server 2019上でSysprepを確実に成功させるために知っておきたいポイントを、具体的な事例とともにご紹介します。
Sysprepとは
Sysprep (System Preparation Tool) はMicrosoftが提供するシステム準備ツールであり、新規イメージ作成やクローン環境の作成時に重複ID（SID）の重複やライセンス認証まわりなどの問題を回避するために使用されます。一般的には以下のような機能が知られています。
- OSの一般化（Generalize）
- SIDのリセット
- OOBE（Out-of-Box Experience）の再実行
- デバイスドライバやライセンス情報の再設定
Windowsを複数台展開する場合には欠かせないツールであり、Windows Serverを仮想マシンで運用する場面では特に重要です。しかし、実際にSysprepを実行するときには多くの注意点があります。ひとつの小さな設定ミスが「Fatal Error（致命的エラー）」という結果を招き、深夜のデプロイ作業を止めてしまう可能性もあります。
仮想マシンでのSysprepが重要な理由
物理サーバーが主流だった時代は、構築するサーバー台数も限られており、一台ごとにインストールと設定を行うのが一般的でした。しかし、仮想化技術が普及した現在では、テンプレート（マスターイメージ）を作り、それを元にクローンを作成してサーバーを量産する方法が広く使われています。
このとき、1台のベースイメージから複数の仮想マシンを作る際に必ず問題となるのがSIDの重複です。ドメインコントローラやActive Directory、ファイルサーバーなどを構築するときにSIDが重複すると、セキュリティ設定やACLなどが混乱するリスクがあります。Windows上ではSIDを基にさまざまなアクセス管理が行われるため、事前に重複SIDを回避することは非常に重要です。
さらに、Windows Server 2019特有のアップデートやイベントログの強化もあり、標準設定が変わっている部分があるので、以前のバージョンのWindows Serverと同じ手順で進めようとすると思わぬエラーに遭遇することがあります。そのため、Windows Server 2019をベースにクローンを作る際は、Sysprepの前後で環境設定を厳密にチェックすることが求められます。
Sysprep失敗の原因を特定する方法
Sysprepが失敗した場合、多くの場合は「Fatal Error」という一般的なエラーが表示され、具体的にどの設定が問題になっているのかが分かりにくいです。こうした原因を特定するためには、ログファイルをチェックすることが最も確実です。特にWindowsでは %WINDIR%\System32\Sysprep\Panther フォルダや %WINDIR%\Panther フォルダ内にある setupact.log が重要になります。
setupact.logを詳細に確認すると、多くの場合はエラーコードや「どのコンポーネントで失敗したか」が記載されているので、まずはそこを手がかりに原因を探っていきます。今回取り上げるのは「Microsoft-Windows-EventLog」まわりの失敗例ですが、他にも「BitLocker」「Microsoft-Windows-Security-SPP」「Officeライセンス」などが原因になるケースもあります。
setupact.logの読み方
setupact.logはテキストファイルのため、メモ帳やテキストエディタで開いて内容を確認できます。ログの最後の行付近に最も新しいエラー情報があることが多いので、末尾からさかのぼって読むのがポイントです。以下は例として、Sysprepの失敗に関するログ行がある場合の一部抜粋です。
[0x0f0082] SYSPRP EventLog component found error [...]
[0x0f00a8] SYSPRP WinMain: Hit failure while processing sysprep cleanup providers.
このような記載があった場合、「EventLog」コンポーネントのクリーニング処理が正常に行われなかったことを示唆しています。特にWindows Server 2019ではイベントログ関連の設定を変更していると、この部分でエラーとなることが珍しくありません。
イベントログに関連するエラーの特徴
Windows Server 2019のイベントログは、セキュリティ強化や監査ログの細分化などの面で以前のバージョンより進化しています。一方で、イベントログの保存先をデフォルト以外に変更していると、Sysprepがその設定を正しくクリアできずに失敗する事例があります。また、レジストリ上のイベントログサービス設定が通常の名前と異なる、あるいはサービス自体が無効化されている場合にエラーが出ることもあります。
現場ではCドライブの容量不足などの理由で「ログだけ別ドライブ（Dドライブなど）に移動する」運用をしているケースが多々あります。こうしたリダイレクト設定自体は正しい運用上の工夫ですが、Sysprep実行前に元に戻しておかないと問題を引き起こす可能性が高いです。
具体的な対処方法
ここからは、Sysprepでイベントログ関連のエラーが起きた場合の具体的な対処方法をご紹介します。作業の前には、必ずシステムのバックアップやスナップショットを取得し、万が一に備えるようにしてください。レジストリの編集も含まれるため、誤操作に注意が必要です。
1. レジストリのCleanupState修正
レジストリの場所と変更手順
最初のアプローチとしては、以下のレジストリキーを確認し、値を変更してみる方法があります。
HKEY_LOCAL_MACHINE\SYSTEM\Setup\Status\SysprepStatus
ここにある「CleanupState」の値が 2 になっている場合は、これを 7 に変更することで、Sysprepのクリーンアップが再度実行されるようになります。変更後はサーバーを再起動し、改めてSysprepを試みてください。以下は例として、レジストリを変更する際の手順を書いたテーブルです。
| 手順 | 操作内容 |
|---|---|
| 1 | Windows + Rキーを押し、「regedit」と入力してレジストリエディタを起動 |
| 2 | HKEY_LOCAL_MACHINE\SYSTEM\Setup\Status\SysprepStatusを開く |
| 3 | CleanupStateの値を確認（既定値が2になっていないかをチェック） |
| 4 | CleanupStateの値を7に変更 |
| 5 | レジストリエディタを閉じ、サーバーを再起動 |
ただし、このレジストリ変更のみで解決しない場合も多いです。実際にエラーを引き起こしている根本原因がイベントログやその他のコンポーネントの場合は、次の手順を検討してください。
2. イベントログサービスの無効化
サービスの名前に注意
一部の環境では、イベントログサービス（EventLogまたはWindows Event Log）を無効にしないとSysprepが正常に動作しないケースがあります。しかし、Windows Server 2019のサービス一覧を確認しても「EventLog」のような名前が見つからないことがあります。それはサービス名と表示名が異なるためです。
実際には「Windows Event Log」という表示名になっていたり、あるいは一部のセキュリティソフトによってサービス名が変更されている場合もあります。そのため、レジストリから直接無効化する必要があることがあります。
以下のレジストリキーを確認し、イベントログサービスがEnabled（=2）になっている場合は一時的に4（=Disabled）に変更してからSysprepを実行してみる手があります。
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EventLog
ただし、イベントログサービスを無効にするとシステムログの記録が行われなくなるため、いったんSysprepを成功させた後は必ず元に戻すようにしてください。稼働環境でイベントログが無効のまま運用すると、障害原因の解析が困難になってしまいます。
3. イベントログの保存先リダイレクトを標準に戻す
GPOやローカルレジストリの設定をチェック
最も多くの現場で効果がある方法は、イベントログの保存先をシステム標準のパスに戻すことです。もし運用上の都合でDドライブやEドライブなどにログを保存するようにしている場合、Sysprep実行前に以下のように設定を元に戻してください。
- グループポリシー（GPO）でイベントログのパスを指定している場合、それを
%SystemRoot%\System32\winevt\Logsなどの既定値に戻す - ローカルレジストリ（
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EventLog下）でログのファイルパスを変更している場合、同様に既定値に戻す
設定を変更したらサーバーを再起動し、再度Sysprepを実行します。イベントログのリダイレクト先が標準パスに戻っていれば、イベントログ関連のエラーが大幅に減り、通常どおりSysprepが完了する可能性が高いです。
イベントログリダイレクトの落とし穴
ビジネス要件によっては、Cドライブの容量節約や監査要件からイベントログを別ドライブに移す必要があることもあります。ただし、その場合でもSysprep前には必ずリダイレクト設定を外すか、テンプレート作成の段階でリダイレクトしない構成を取るようにするとトラブルを避けやすいです。以下は例として、イベントログを別ドライブに配置している場合の標準化手順です。
1. システム稼働開始後に、グループポリシーもしくはスクリプトでイベントログをDドライブに移動
2. Sysprepを実行する際は再度元の場所へ戻すか、移動前のスナップショットを使用
3. クローン後のマシンが起動したら、必要に応じて再リダイレクト
このように、「デプロイ時のテンプレート構成」と「実稼働構成」を分けて考えるのがポイントです。デプロイ後に運用設定を追加する手間は増えますが、Sysprep失敗による大きな手戻りを防ぎ、結果的に作業全体の効率化につながります。
最終的な解決策と運用上の注意
ここまで紹介した対処法の中でも、レジストリのCleanupState修正やイベントログサービスの無効化を試して解決しない場合、イベントログの保存先を標準に戻す手段がほぼ確実な方法となります。実際の現場でも、別ドライブへのリダイレクト設定が原因でSysprepに失敗していたケースが非常に多く報告されています。
SysprepはWindows環境の大規模展開において重要な役割を担う反面、少しの設定変更が「Fatal Error」を招きやすいデリケートなツールです。特にイベントログ周りの設定は監査要件などから変更されることが多いため、以下のポイントを意識して運用することをおすすめします。
- テンプレートイメージを作る段階では、できるだけ標準設定に近い形を維持する
- デプロイ後に変更が必要な設定（ログのリダイレクトなど）は、スクリプトやGPOで自動反映させる
- レジストリ編集などリスクのある作業は必ずバックアップやスナップショット取得後に行う
- イベントログサービスを無効化した場合は、Sysprep完了後に必ず有効に戻す
また、クローン作成のフェーズごとにチェックリストを作っておくと便利です。以下は簡単な例です。
| チェック項目 | 説明 | 備考 |
|---|---|---|
| レジストリCleanupState | 値が2のままではないか確認し、必要に応じて7に変更 | Sysprep実行前に確認 |
| イベントログ保存先 | デフォルトパスに設定されているか | GPOおよびローカルレジストリ両方 |
| イベントログサービスの状態 | 無効化していないか、一時的に無効化している場合はSysprep完了後に戻す | 常時無効は厳禁 |
| アンチウイルス/BitLocker | システムに組み込まれていないか、あるいは一時停止が必要か | 環境による |
このように、事前に作業手順とチェック項目を明確化しておけば、急に「Sysprepが失敗した…」というトラブルが発生しても迅速に原因を切り分けできます。特に数十台、数百台といったサーバーのクローンを一度に行う場合は、ちょっとした設定漏れが大きなインパクトを与えかねないため、計画的な準備が重要です。
まとめ
Windows Server 2019の仮想マシンでSysprepが失敗し、「Microsoft-Windows-EventLog」に起因するエラーが疑われる場合、まずはレジストリのCleanupState修正やイベントログサービスの無効化を検討します。しかし、最も効果的で安定した解決策は、イベントログの保存先をデフォルトに戻すことです。特にドライブ分割や容量管理のためにログを別ドライブにリダイレクトしているケースでは、Sysprep実行前に元の設定に戻すだけで問題が解決する可能性が高いです。
併せて、スナップショットの取得やバックアップなどの事前対策を徹底し、トラブルが発生した場合にすぐロールバックできるようにしておくことも大切です。イベントログ自体は運用に必要不可欠な情報源であり、セキュリティインシデントや障害解析に大きく貢献するため、Sysprepのためだけに無効化したり削除したりするのではなく、適切な時期・方法で設定を戻しておくように心がけましょう。
いずれにしても、Windows Server環境のクローン作成ではSysprepの失敗リスクはつきものです。エラーの原因が多岐にわたるため、問題が発生したらまずはログを詳しくチェックし、今回ご紹介したような「レジストリ編集」「イベントログ設定の確認」「サービス状態の確認」などを段階的に試すのがよいでしょう。そうすることで、安定したクローンイメージの展開と運用を実現できます。
コメント