Windows Server 2016の製品ライフサイクルとサポート終了日（End of LifeCycle《EOL》、End of Support《EOS》）である2027年1月12日までまだ1年以上ありますが、対策に着手するには遅すぎるくらいです。前回は、Windows Server 2016のHyper-Vホストから最新のHyper-Vホストに仮想マシン（VM）を移行（移動）する方法での仮想環境の移行について説明しました。仮想TPM（vTPM）が有効な第2世代仮想マシンでは、移行後に起動できなくなることがあります。その理由と解消方法を解説します。

TPM搭載が推奨される現在のコンピューティング環境

　TPM（トラステッドプラットフォームモジュール）は、資格情報や暗号化キーなどの機密データを格納して保護するハードウェアチップです。例えば、UEFIセキュアブートはTPMを活用して、信頼されたOSやドライバーのみを読み込み、OSのブートの早い段階からマルウェアなどによるシステムの改ざんを防止します。

　セキュアブートやTPM 2.0は、Windows 10以降のセキュアコアPC（Secured Core PC）認定およびWindows Server 2022以降のセキュアコアサーバー（Secureｄ Core Server）認定の要件の一部です。そして、Windows 11では、これらが必須要件になりました。Windows Serverでは必須要件ではありませんが、UEFIセキュアブートやTPM 2.0を備えていることが推奨されます。TPMを備えることで、セキュアブートが強化され（Measure BootやSecure Launch^*1などのSystem Guard）、資格情報ガード（Credential Guard）、デバイスガード（Devicce Guard、コードの整合性）、BitLockerドライブ暗号化、Windows Hello/Windows Hello for Businessでの資格情報の保護、証明書ストアの保護、TPM仮想スマートカード（TPM Virtual Smart Card）^*2 など、高度なセキュリティ機能を利用できるようになります。
^{*1　Secure Launch（セキュア起動）はVMには提供されない物理ハードウェアの機能（Intel TXT、AMD DRTM）に依存するため、ＶＭでは利用できません。
*2}　TPM仮想スマートカードについては、古い記事ですが、こちらを参照してください。

^{Windows 8 Developer Preview > TPM Virtual Smart Card を試した。できた。｜山市良のえぬなんとかわーるど（アーカイブ）}

第2世代VMのTPM 2.0サポート

　Hyper-Vでは、第2世代VMにおいてTPM 2.0互換のTPMデバイス（仮想TPM、vTPM）をサポートしています。この機能は、仮想化ベースのセキュリティ（Virtualization-Based Security《VBS》）が提供する機能であり、Hyper-Vホストの物理的なTPMには依存しません。つまり、Hyper-VホストにTPMが搭載されていなくても、Hyper-Vホスト上のVMではvTPMを利用できます。vTPMを利用できることで、TPM 2.0が必須なWindows 11をVMのゲストOSとしてインストールして、使用できます。また、vTPMを有効にすることで、BitLockerドライブ暗号化をはじめとする、前述の高度なセキュリティ機能をVMのゲストOSで利用することができます（画面1）。

画面1　第2世代VMのvTPMにより、TPM 2.0必須のWindows 11をVMのゲストOSとして実行できる

別のHyper-Vホストに移行したVMが起動に失敗（原因はvTPM）

　Hyper-Vホストから、別のHyper-VホストやホストクラスターにVMをエクスポート/インポートした場合、インポートしたVMを新しいHyper-Vホストで起動しようとしても、起動中にエラー（キーの保護機能をラップ解除できませんでした）が発生して起動できないことがあります（画面2）。同じ原因で、Hyper-Vホスト間やHyper-Vホストクラスターのノード間でライブマイグレーションを実行しようとしたとき、Hyper-VレプリカでセカンダリサーバーにVMをフェールオーバーしようとしたとき、エラー（仮想マシンのハードウェア要件の不一致、キーの保護機能のラップ解除失敗）が発生し、移行に失敗することがあります（画面3）。これまでvTPMを使用していなかった場合は、このエラーに遭遇することはありませんでしたが、Windows 11 VMなど、vTPMが有効になっているVMが存在するようになって、その移行/移動時にはじめて顕在化する問題です。

画面2　別のHyper-VホストからインポートしたVMの起動時エラー

画面3　ハードウェア要件の不一致を理由にブロックされた（シェアードナッシング）ライブマイグレーション。Hyper-Vホストクラスター環境でも発生することがある

　これらのエラーは、移行した（する）VMにvTPMが存在（vTPMが有効）することが原因で発生します。VMのvTPMをクリア（無効化/有効化）しても、この問題は解消できません。vTPMを無効化すれば、VMを起動することはできます。Hyper-Vホストでは、vTPMを提供するのにローカル証明書ストアの証明書に依存しています。そのため、vTPM用の証明書が存在しない移行先のHyper-VホストではvTPMの保護を解除できずに、起動に失敗するのです。

　Hyper-VホストのvTPM用証明書は、ローカルコンピューターの証明書ストア（certlm.msc）の「シールドVMのローカル証明書（￥証明書）」（cert:￥localmachine￥Shielded VM Local Certificates）にある以下の2つの自己署名証明書（有効期限10年）です。なお、“コンピューター名”は、最初にvTPMが有効化されたときのもので、後でコンピューター名が変更されたとしても、証明書が再生成されることはありません。引き続き、旧“コンピューター名”を含む証明書が利用されます。これらの証明書はVMのvTPMの有効化時にキー保護（キープロテクター）の暗号化と署名に使用され、次回以降のVM起動時の保護の解除に使用されます。

　VMの起動エラーを解消するには、VMの移行元のHyper-Vホストから、上記の証明書を、秘密キーとともに「Personal Information Exchange - PKCS #12(.PFX）」形式でファイルにエクスポート（パスワードで保護）し、移行先のHyper-Vホストの証明書ストアの同じ場所、つまり「シールドVMのローカル証明書」（cert:￥localmachine￥Shielded VM Local Certificates）にインポートします（画面4、画面5）。なお、別のHyper-Vホストからインポート/ライブマイグレーションしたVMの場合でも、過去のvTPMが有効化されたことがない場合、移行先のHyper-Vホスト上でのVMのvTPMの有効化には、移行先のHyper-Vホストの自己署名証明書（存在しなければ自動生成）が使用されるため、移行元のHyper-Vホストの自己署名証明書の移行は不要です。

画面4　移行元のHyper-Vホストから、「Shielded VM」で始まる2つの証明書をファイル（.pfx）にエクスポートする

　インポート先のHyper-Vホストに証明書ストア「シールドVMのローカル証明書」が存在しない場合は、PowerShellで以下のコマンドラインを実行することで作成できます。

　移行先のHyper-VホストにダミーのVM（第2世代VM）を作成してvTPMを有効にすることでも作成できます（その後ダミーのVMは削除できます）。この場合、このHyper-Vホストで新規作成されるVMのvTPM用の自己署名証明書が生成されます。PowerSHellで以下のコマンドラインを実行することで、vTPM用の自己署名証明書を生成することもできます（名前はUntrustedGuardian以外でも問題ありませんでした）。

画面5　移行元Hyper-Vホストからエクスポートした証明書（.pfx）を、移行先のHyper-Vホストの証明書ストアの同じパスにインポートする

　移行元の証明書を移行先のHyper-Vホストにインポートすると、それらの証明書に依存するvTPMが有効なVMが正常に起動できるようになります（画面6）。ライブマイグレーションで移行する場合は、移行前に事前に証明書を移行先にインポートしておきます（画面7）。

画面6　vTPM用証明書インポート後、起動に失敗したvTPMが有効なVMの起動に成功

画面7　移行元のvTPM用証明書を事前に移行先にインポートしておけば、ライブマイグレーション時のエラーもなくなる

　vTPMが有効なVMがHyper-Vホストのローカルの証明書に依存するという制約は、Hyper-VホストクラスターやAzure Local（旧称、Azure Atack HCI）クラスター上のVMでも同じです（画面8）。Hyper-Vホストクラスターの場合は、すべてのノードの証明書ストア「シールドVMのローカル証明書」に必要な証明書をインポートして、同一になるようにしてください（最大で、各ノードのペアの証明書がノード数分だけ必要です）。

画面8　vTPMが有効なVMは、Hyper-Vホストクラスター上の高可用性が構成されたVMでも同じ理由でライブマイグレーションに失敗することがある

　vTPMが有効なVMのライブマイグレーションがこの問題の影響を受けない例外が1つあります。Windows Server 2016以降のHost Guardianサービス（HGS）とともに展開されたHyper-Vホストクラスターでは、vTPMはローカルホストの自己署名証明書を使用する「UntrustedGuardian」ではなく、信頼されたGuardianを所有者としたキー保護（KeyProtector）が使用されるため、ライブマイグレーションでこの問題の影響は受けません。Host Guardianサービスは、クラウドサービスプロバイダーやプライベートクラウド向けの、セキュリティが強化されたシールドされたVM（Shielded VM）環境を実現する機能です。証明書の名前から想像できる人もいると思いますが、実は、スタンドアロンのHyper-VホストやHyper-VホストクラスターのVMのvTPMの機能は、このHGSやシールドされたVMのために実装された機能を利用しています。

保護されたファブリックとシールドされた VM｜Windows Server（Microsoft Learn）

　次回は、vTPM用自己署名証明書の10年という有効期限に注目します。

Windows Server 2016 EOSまであとX日（1）｜...｜（11）｜（12）｜（13）｜（14）