現在、Windows Autopilotの事前プロビジョニング用シナリオ、Entraハイブリッド参加による新規デバイスの導入手順を試しています。前回までに展開の準備を完了しました。いよいよ新規デバイスをWindows Autopilotにより展開してみます。今回は事前プロビジョニング（技術者フローのフェーズ）の部分です。先に言っておくと、今回クライアントデバイスとして使用したHyper-V VMでは、事前プロビジョニングを完了させることはできませんでした。
前回まで...
今回は、以下に示す一連の手順の手順 10から。
Windows Autopilot 事前プロビジョニング用、Entraハイブリッド参加の手順済 vol.221）手順 1: Windows の自動Intune登録を設定する（Microsoft Learnドキュメント） 済 vol.224) ＋手順: Microsoft 365アプリのインストールのカスタマイズとデバイスへの割り当て |
手順 10: テクニシャン（技術者）フロー
Hyper-V VMに作成しておいた疑似OEMプレインストールデバイス（Windows 11 Proの一般化イメージ）を使用して、事前プロビジョニング用シナリオの技術者フローを体験してみます。
有線ネットワークに接続した状態でデバイスの電源をオンにし、「更新プログラムをチェックしています」に続き「職場または学校向けに設定しましょう」というMicrosoft Entra IDのサインインページが表示されるまで待ちます。有線ネットワークに接続されている場合、通常のデバイス起動時のOOBE画面（国または地域、キーボードレイアウトの選択...）は一切表示されず、すぐに「職場または学校向けに設定しましょう」のページが表示されました（画面1）。
画面1 デバイスの電源オン後、対話することなくEntra IDのサインイン画面が表示された。サインインに使用するIDは入力済み（手順 9でユーザーを割り当てた場合）
Windows Autopilotでは、デバイスの電源オン直後、OOBEセットアップの開始直後にIntuneにハードウェアIDを問い合わせてデバイスの登録先となるテナントを識別し、デプロイプロファイルやユーザーアカウント（割り当てられている場合）を取得しているからだと想像します。この最初のエクスペリエンスは、新しいWindows Autopilotデバイスの準備（Autopilot v2）と大きく違うはずです。Windows Autopilotデバイスの準備（Autopilot v2）については、今後の検証をお待ちください。
| ※無線ネットワーク（Wi-Fi）への接続が必要な場合など、デバイスの電源オン時にインターネット接続ができない場合、「ネットワークに接続しましょう」の画面が表示されるまで、通常のOOBEセットアップの初期プロセス（国または地域はこれでよろしいでしょうか?: はい、これは正しいキーボード レイアウトまたは入力方式ですか?： はい、2つめのキーボード レイアウトを追加しますか?: いいえ）と対話して、ネットワークに接続する必要があります。 |
「職場または学校向けに設定しましょう」ではサインインせずに、キーボードの「Win（Windows）」キーをすばやく5回押します。今回はHyper-V VMの環境であるため、ローカルキーボードが使えません。Hyper-Vホストで「スクリーンキーボード」（osk.exe）を起動し、サインイン画面をクリックしてから「Win」キーを押しました（画面1）。
画面2 Microsoft Entra IDのサインインページが表示されたら「Win」キーを5回押す
「何を行いますか」のページが表示されるので、「Windows Autopilotによる事前プロビジョニング」を選択して、「次へ」をクリックします（画面3）。
画面3 「Windows Autopilotによる事前プロビジョニング」を選択して進む
「Windows Autopilotによる事前プロビジョニング」のページで「次へ」をクリックします（画面4）。これにより、事前プロビジョニング（技術者フローとしてデバイスESP部分のセットアップ）が始まります。なお、この画面に表示されているQRコードは、スマートフォンのカメラは認識しません。このQRコードは、以前、Microsoftが開発者向けにGitHubで公開していたWindows Autopilot Companionアプリ（現在はアーカイブ）に対応したもので、Microsoft Storeなどで入手できるアプリではありません。
画面4 「次へ」をクリックして、事前プロビジョニングを開始する
残念ながら、VMで体験できるのはここまで
事前プロビジョニング開始後、しばらくすると、「問題が発生しました 問題が発生し、TPM 構成証明がタイムアウトしました」と表示されました。「再試行」や「リセット」を試してみましたが状況は変わりません。
画面5 Hyper-V VMでは事前プロビジョニングがTPM 構成証明のタイムアウトエラーで失敗
Windows Autopilotの既知の問題を確認すると、事前プロビジョニングの場合、特定のハードウェアモデル（ST Micro、Nuvotonなど）でTPM構成証明がタイムアウトになったり、エラーになったりすることがわかりました。インターネットを検索してみても、Hyper-V VMでは事前プロビジョンングが失敗するという事例やその理由の考察（Windows AutopilotがTPM構成証明のために要求する製造元のEndorsement Key《EK》証明書がHyper-V VMのvTPMに存在しない*1）がいくつか見つかりました。そして、そもそもWindows Autopilotの既知の問題の中に、“事前プロビジョニングは、VM ではサポートされていません。” と記載されています。Windows Autopilotシナリオの長所と短所のドキュメントにも、事前プロビジョニングおよび自己展開モードで必要なTPM構成証明は、“仮想 TPM を使用しても VM では機能しません” と記載されています。
*1 TPMに焼き付けられたEKは、Get-TpmEndorsementKeyInfoコマンドレットのManufacturerCertificatesで確認できます。Hyper-V VMのvTPMのManufacturerCertificatesは空でした。 参考: Autopilot Error 0x80280009: TPM Attestation. What is going on?（call4cloud.nl）
Windows Autopilot - 既知の問題｜Windows（Microsoft Learn）
“事前プロビジョニングは、VM ではサポートされていません。”
Windows Autopilot シナリオ > シナリオの長所と短所｜Windows（Microsoft Learn）
“TPM 構成証明 が必要なので、サポートされている TPM を持つ物理デバイスでのみ動作します (仮想 TPM を使用しても VM では機能しません)。”（事前プロビジョニングおよび自己展開モードの欠点）
TPM キーの構成証明 > TPM キーの構成証明の動作方法｜Windows（Microsoft Learn）
“すべての TPM は、製造元によって焼き付けられた、"保証キー" (EK) と呼ばれる一意の非対称キーと共に出荷されます。 ...”
本来の手順では、事前プロビジョニングで「デバイスの準備」と「デバイスのセットアップ」（技術者フローのフェーズ）が実行され、完了すると、「デバイスのセットアップが完了しました」と表示されるので、「再シール」ボタン（左のサンプル画面）をクリックしてデバイスを停止します。
実際の現場ではこの後、再シールしたデバイスをユーザーに送付/配布して、エンドユーザーによるデバイスの電源オンから始まる「デバイスのセットアップ」（再シール後に追加/変更されたアプリやポリシーのセットアップ）と、Microsoft Entra IDサインインに続く「手順 11: ユーザーフロー」に進みます。ユーザーフローでは、アカウントのセットアップ（ユーザーESP）部分が行われ、セットアップ完了、利用開始となるはずです。Hyper-V VMでは事前プロビジョニングの完了以降を体験することはできませんでしたが、事前プロビジョニングのため設定の手順は確認できたと思います。
次回は、事前プロビジョニング用シナリオをユーザー駆動モードに切り替えてデバイスのデプロイを行いたいと思います。物理デバイスでもTPM構成証明で失敗する場合は、同じようにユーザー駆動に切り替えることで問題を解消できるはずです。事前プロビジョニングのデバイスESPやユーザーESPの部分の画面遷移については、ユーザー駆動モードで改めて確認できます。
次回（手順 4再び、そしてデバイスの展開）へ...
