2024年 6月 3日に、Windows Autopilot デバイスの準備 (Windows Autopilot device preparation) が GA されました！
以前から「Autopilot v2」の仮称で界隈では噂されており、楽しみにされていた方が多い印象です。
結局どうなん？ と思ったので調査検証してみました。
本記事は、アツいトピックについてとにかく語りたかった Autopilot ウォッチャーによる萌え語り記事です。
「Windows Autopilot デバイスの準備」の現在地と、開発予定情報をレポします！
なお、Autopilot そのものの説明は割愛しています。
(すでに Windows Autopilot をご存知/やったことある方向けの記事となっております。)
本記事の内容は、AS-IS です。
検証時の 2024年 6月末~7月頭 時点のテナント状態、端末動作 および Microsoft 社公開情報や公式ブログをベースにしています。
Contents
- Windows Autopilot デバイスの準備とは
- 今後はすべての Autopilot が「デバイスの準備」になるのか？ (いやならない)
- ソリューション比較：Windows Autopilot or デバイスの準備
- 既知の事象
- やってみた (GIF付き)
- さいごに
本記事では、「デバイスの準備」の Autopilot における位置づけや、既存の Windows Autopilot とどこが一緒でどこが違うのか (共通点と相違点) について語らせてください。
もちろん、一度も検証せずに記事を書くのは nonsense ですので、軽くですが検証もしてみました。
感想を最後に書いてまとめとします。
ソリューション1名の表記について
-
Windows Autopilot
本記事では、Microsoft社の公式ブログ・公開情報に倣い、既存の Windows Autopilot を「Windows Autopilot」と表記します。
(文脈により分かりづらい部分は極力「既存の Windows Autopilot」と記載します。) -
「デバイスの準備」
「Windows Autopilot デバイスの準備」は名称が長いため「デバイスの準備」と略記させていただきます。
(文脈により分かりづらい部分は極力「Windows Autopilot デバイスの準備」と記載します。) -
Autopilot
「Autopilot」と単体で記載している場合は、Windows Autopilot と「デバイスの準備」を含む総称の意で使用しています。
Windows Autopilot デバイスの準備とは
「Windows Autopilot デバイスの準備」は、Entra join する Windows 端末をユーザー駆動型でプロビジョニングするあたらしいデバイス プロビジョニング ソリューション1です。
既存の Windows Autopilot では Goverment クラウドでの利用がサポートされておらず、サポート範囲を広げるにあたって Government クラウドユーザーのニーズである「早く、正確なプロビジョニング」をかなえるため、「Windows Autopilot デバイスの準備」がいちから開発されました。(commercial テナントでも利用可能。)
(参考：AMA: Windows Autopilot)
ユーザー目線ではプロビジョニング経過が % 表示されるほか、管理者目線ではほぼリアルタイムで以前よりも詳細なレポートが表示されるようになるという、目に見える違いがあります。
(▲レポート画面写真出典：Announcing new Windows Autopilot onboarding experience for government and commercial customers)
現状 Government Community Cloud High (GCCH) と Department of Defense (DoD) テナントの場合はこの Windows Autopilot デバイスの準備が、唯一サポートの受けられる Autopilot 展開ソリューション1になります。
(参考：Overview of Windows Autopilot device preparation)
commercial テナントの場合は、既存の Windows Autopilot (以後 Windows Autopilot) を使うか、Windows Autopilot デバイスの準備 (以後「デバイスの準備」) を使うか、要件に合わせて選択することができます。
-
選択肢2：
-
Windows Autopilot
- ユーザー駆動モード (User diven mode)
- 事前プロビジョニングモード (Preprovisioning mode, 旧称 White Glove)
- 自己展開モード (Self-deploying mode, SDM)
-
Windows Autopilot デバイスの準備 (device preparation) ←NEW!
- ユーザー駆動モード (User diven mode)
-
Windows Autopilot
今後はすべての Autopilot が「デバイスの準備」になるのか？ (いやならない)
「デバイスの準備」は、界隈では半年ほど「Autopilot v2」の仮称で楽しみにされてきました。
「v2」というと version 2 なので、古いものに代わる新しいものというイメージがありますが、以下の理由から、「デバイスの準備」の現状は Windows Autopilot にとってかわるものではないと思いました。
-
機能範囲：
「デバイスの準備」には Windows Autopilot と比較して機能制限があり、これまで Autopilot で設計・実現されてきたすべてのシナリオにはまだ対応していません。
(機能範囲については次セクションにて深堀します。) -
開発状況：
「デバイスの準備」と Windows Autopilot は現在並行して開発が行われており、将来的に「デバイスの準備」の機能拡充や「デバイスの準備」用に開発された機能の Windows Autopilot へのリバース更新が積極検討されています。 -
移行不要ステイトメント：
すでに Windows Autopilot を利用テナントでも新しい「デバイスの準備」方式への移行は必要ないとされています。
以上から、今後も「デバイスの準備」ではなく Windows Autopilot が利用されるシナリオは残りそうです。
(参考：Announcing new Windows Autopilot onboarding experience for government and commercial customers)
余談ですが、「デバイスの準備」登場前後で公開情報に更新が入り、シナリオの整理まわりの情報が格段に読みやすく見つけやすくなりました！
シナリオ比較が必要な際、今後は自作せずとも公開情報を流用することでほぼ用に足ると思います。
(参考：Windows Autopilot scenarios、Compare Windows Autopilot device preparation and Windows Autopilot)
ソリューション1比較：Windows Autopilot or デバイスの準備
現状、Windows Autopilot と「デバイスの準備」 は、双方プロビジョニングの結果として以下を達成することができます。
-
共通点：
- Entra join
- Intune 登録
- ユーザー駆動型のデバイスプロビジョニング
- 設定の展開
ただし、「デバイスの準備」は "re-architecture" されたとのことで、上記を達成する裏の仕組みが異なるそうです。
これが設計する上でも目に見える相違点として表れています。
-
相違点：
- サポートする Windows バージョン
- デバイスとテナントの紐づけ
- グループ
- デプロイ プロファイル
- ESP (Enrollment Status Page)
- 展開可能な設定
なお、公開情報にもすでに網羅性の高い比較記事があるため、一覧としてご確認されたいかたは MS Learn を参照ください！
(参考：Compare Windows Autopilot device preparation and Windows Autopilot)
本セクションでは、細かい項目の羅列はせずに (これは公開情報に任せて) 恣意的にカテゴライズしたうえで、私が個人的に特に着目している点をシェアします！
共通点
まず、Windows Autopilot と共通する点というカットで「デバイスの準備」を見ていきます。
- Entra join
- Intune 登録
- ユーザー駆動型のデバイスプロビジョニング
- 設定の展開
1. Entra join
| ▼ソリューション / 参加方式▶ | Entra register | Entra join | Entra hybrid join |
|---|---|---|---|
| Windows Autopilot | × | 〇 | 〇 |
| デバイスの準備 | × | 〇 | × |
どちらのソリューションもデバイス参加方式として Entra join が利用可能です。
なお、Windows Autopilot では Hybrid join も可能ですが、現状「デバイスの準備」では Hybrid join ができず、Entra join のみ対応となっています。
Tips
Windows Autopilot では Hybrid join が可能ですが、構成が複雑になり障害ポイントが増えることから、Entra join の利用が推奨されています。
開発情報！
Windows Autopilot デバイスの準備では、現状 Hybrid join にサポート範囲を広げる予定は無いそうです。
既存の Windows Autopilot における Hybrid join シナリオも機能追加など開発は現状行っていないとのことです。
残念ですが、Ignite で "the fure is cloud" と強調されていたように Microsoft のクラウドネイティブ路線は近年明らかです。個人的には、今後 Autopilot における Hybrid 対応の進化は望み薄だと思っています。
2. Intune 登録
| ▼ソリューション / MDM▶ | Intune | 3rd party 製 MDM |
|---|---|---|
| Windows Autopilot | 〇 | 〇 |
| デバイスの準備 | 〇 | × |
Windows Autopilot と「デバイスの準備」どちらも Intune へのデバイス登録が可能です。
ただし、Windows Autopilot の場合、Intune 以外の 3rd party 製 MDM にもデバイス登録が可能です3。
この点、現状「デバイスの準備」は 3rd party MDM へのデバイス登録はできず Intune のみ対応となっています。
開発情報！
Windows Autopilot デバイスの準備でも、将来的に 3rd party MDM へサポート範囲を広げる予定があるそうです。
3. ユーザー駆動型のデバイスプロビジョニング
| ▼ソリューション / 展開モード▶ | ユーザー駆動 | 事前プロビジョニング | 自己展開 |
|---|---|---|---|
| Windows Autopilot | 〇 | 〇 | 〇 |
| デバイスの準備 | 〇 | × | × |
ユーザー駆動型とは、デバイスの OOBE (out-of-box experience) 画面上で、ユーザー自身が 組織の Entra ID ユーザーアカウントとパスワードを入力することでスタートする、デバイスのプロビジョニング方法です。
現状、「デバイスの準備」ではユーザー駆動のみサポートされており、事前プロビジョニングや自己展開モードは使えません。
開発情報！
Windows Autopilot デバイスの準備でも、将来的に事前プロビジョニングや自己展開モードにも対応範囲を広げる予定があるそうです。
4. 設定の展開
| ▼ソリューション / 設定▶ | ポリシー類 | スクリプト | アプリ |
|---|---|---|---|
| Windows Autopilot | 〇 | 〇 (数上限無し) | 〇 (数上限無し) |
| デバイスの準備 | 〇 | 〇 (10個まで) | 〇 (10個まで) |
デバイスの OOBE (out-of-box experience) 過程で、Intune から端末構成設定を展開することができます。
Autopilot のだいご味である設定の展開が可能という点はやはり両ソリューション共通です。
ただし、細かい設定種類や個数、パラメータについては差異があります。
差異については「相違点」セクションの「6. 展開可能な設定」に記載しますが、パッと見て異なるのは「デバイスの準備」では OOBE 中に展開可能なスクリプトとアプリに個数制限がある点です。
なお 10個を超える場合、あぶれた分は OOBE 後にユーザーがデスクトップ到達後に展開されます。
「デバイスの準備」では、OOBE 中に展開したいスクリプトとアプリはデプロイプロファイル (デバイス準備ポリシー) 上で指定する必要があり、それぞれ 10個を上限として指定が可能となっています。
Windows Autopilot にて ESP (Enrollment Status Page) プロファイル上で指定するのと似た感覚です。
10個という数ですが、個人的には十分だと感じました。
以前プロジェクトで Windows Autopilot を設計した際も一部開発はあったもののスクリプトとアプリそれぞれで 10個もいきませんでした。
正直 10個以上もスクリプトとアプリを展開するとなると、それなりに検証期間が必要なうえ実行コンテキストや割り当てにおいてバリエーションが生まれるなどそれなりに設計も複雑になることが予想されるため、現状だと Windows Autopilot の方が適応度が高いということになります。
コンテキストや割り当てについては「相違点」セクションの「6. 展開可能な設定」にて後述します。
なお余談ですが、元来 Windows Autopilot では PowerShell スクリプトは仕様上展開できるものの公開情報に展開できると明記されていないという捻じれがありました。
アプリについては OOBE 中に展開可能なのは ESP プロファイルの設定からも自明ですが、PowerShell についてどうかというと、以前 Microsoft Intune サポートに聞いた際、「公開情報に明確な記載は無いが Intune Management Extension の仕様上 PowerShell スクリプト実行後にアプリが実行されるため、ひとつでもアプリを OOBE 中に展開するよう構成していればそれが楔になり PowerShell も OOBE 中に展開が可能」という主旨の回答を受けたことがあります。
言い換えれば、アプリを展開せずに PowerShell のみを OOBE 中に展開することは不可能でした。
この点、「デバイスの準備」ではアプリと PowerShell スクリプトそれぞれで "OOBE 中に展開したいものリスト" の作成が可能なため、理論上は PowerShell スクリプト単体で (アプリ展開無しでも) OOBE 中に展開できるように見えます。
(アプリを展開しない Autopilot はかなり珍しいとは思いますが。)
相違点
遠目では共通点が多いような両ソリューションですが、視点をミクロにすると相違点が見えてきました。
特にパラメータレベルでは相違点を考慮した設計が必要になります。
- サポートする Windows バージョン
- デバイスとテナントの紐づけ
- グループ
- デプロイ プロファイル
- ESP (Enrollment Status Page)
- 展開可能な設定
1. サポートする Windows バージョン
| ▼ソリューション / サポート OS▶ | Windows 10 | Windows 11 | HoloLens |
|---|---|---|---|
| Windows Autopilot | 〇 | 〇 | 〇 (HoloLens 2) |
| デバイスの準備 | × | 〇 ('24/4 更新以降) | × |
Windows Autopilot ではサポートされるバージョンの Windows 10, Windows 11 に対応しており、HoloLens も HoloLens 2 に対応しています。
(参考：Windows Autopilot requirements - Software)
この点、「デバイスの準備」では 2024年 4月更新以降の Windows 11 に対応が限定されています。
(参考：Windows Autopilot device preparation requirements - Software)
- Windows 11, version 23H2 with KB5035942 or later
(2024年 4月以降リリースの Windows 11 インストールメディアに含まれる) - Windows 11, version 22H2 with KB5035942 or later
(2024年 4月以降リリースの Windows 11 インストールメディアに含まれる)
現場の感覚としては、お客様企業でも特に新規端末から Windows 11 の導入が進んでいることが最近多くなってきましたが、2024年 4月リリースの更新以降の OS イメージが必要という点は 「デバイスの準備」版 Autopilot 導入のハードルになり得るのではと思いました。
現状 Autopilot ではデバイスプロビジョニング中に Windows OS を更新することができず、Autopilot 以前の OS インストール段階で Windows が Autopilot にてサポートされるバージョンなっている必要があります。
← 特定のバージョンに揃えるには、現状 Intune 単体では対応できず OEM サービスを利用する必要があります。
開発情報！
Autopilot によるデバイスプロビジョニング中の Windows OS 更新については、開発中 (ただしリリース時期は未定) だそうです！ 楽しみですね！
2. デバイスとテナントの紐づけ
| ▼ソリューション / 紐づけ方法▶ | ハードウェア ハッシュ | 業務用デバイスの識別子 |
|---|---|---|
| Windows Autopilot | 〇 | × |
| デバイスの準備 | × | 〇 (Coming Soon!) |
Windows Autopilot では端末のハードウェアハッシュを Windows Autopilot deployment service に登録して企業端末を識別しますが、「デバイスの準備」では業務用デバイスの識別子を使って企業端末を識別します。
(参考：New Windows corporate device identifier feature with Microsoft Intune: Everything you need to know)
2024年 6月 5日に Windows Autopilot デバイスの準備がリリースされた直後、業務用デバイスの識別子の Windows サポートが不具合により一時期ストップしましたが、6月最終週~7月頭にサポートが復活しました！
なお、Windows で業務用デバイスの識別子を利用できるのは Windows 11 22H2 KB5035942 以降のデバイスです。
なお、ハードウェアハッシュを登録したデバイス (Autopilot deployment service に登録されたデバイス) は Windows Autopilot のプロビジョニング対象とみなされ、OOBE (out-of-box experience) では Windows Autopilot のデプロイプロファイルが適用されます。
「デバイスの準備」を使いたい場合はハッシュ登録無しで OOBE 画面にて組織の Entra ID ユーザーアカウントでサインインする必要があります。
(参考：Windows Autopilot device preparation user-driven Microsoft Entra join: Create a Windows Autopilot device preparation policy)
また、「デバイスの準備」ではデバイスのテナントの紐づけは必須ではありません。必要に合わせて利用が可能、という位置づけです。
(参考：Windows Autopilot device preparation user-driven Microsoft Entra join: Add Windows corporate identifier to device (optional))
「デバイス プラットフォームの制限」ポリシーにて Windows の個人所有端末をブロックしている場合は、「デバイスの準備」によるプロビジョニング中のデバイス登録を許可するために業務用デバイスの識別子の登録が必要になります。
3. グループ
| ▼ソリューション / グループ▶ | デバイスグループ | ユーザーグループ |
|---|---|---|
| Windows Autopilot | 〇 (動的, 静的どちらでも) | 〇 (任意構成) |
| デバイスの準備 | 〇 (静的だがサービスにより動的にメンバー追加される) | 〇 (必須) |
Windows Autopilot では、ハードウェアハッシュ登録した端末が、Entra・Intune 登録前のゴースト状態で Entra 管理センターで見える状態になるため、ZTDId や Group tag を利用 (動的グループの場合) して通称「Autopilot デバイスグループ」を作成します。
(動的/静的どちらでもOKですが、production 環境では運用負荷を軽減できる動的が圧倒的人気です。)
Autopilot デバイスグループはデプロイプロファイルや ESP など、Intune 登録前に適用が必要なポリシーの割り当てに使うほか、普通のデバイスグループと同様にポリシープロファイル類を割り当てて利用します。
Windows Autopilot におけるグループ、ポリシー割り当て、プロビジョニングフローの関係はざっと以下の通りです。
-
Windows Autopilot におけるグループ、ポリシー、フローの関係 (略図)
では、ハードウェアハッシュを使わない「デバイスの準備」ではどうなるか？ が面白いところで、なんと静的デバイスグループをメンバー空状態で作成することになります。
静的デバイスグループ作成時に、所有者としてサービスプリンシパル (Intune Provisioning Client4) を設定し、これが「デバイス準備ポリシー」が適用されたデバイスを順次自動的にデバイスグループメンバーに追加してくれるという仕組みになっています。
(「デバイスの準備」におけるデプロイプロファイルにあたる「デバイス準備ポリシー」はユーザーグループに割り当てます。)
「デバイスの準備」におけるグループ、ポリシー割り当て、プロビジョニングフローの関係はざっと以下の通りです。
-
Windows Autopilot device preparation におけるグループ、ポリシー、フローの関係 (略図)
Windows Autopilot デバイスの準備のユーザーグループ
「デバイス準備ポリシー」の割り当て先としてユーザーグループの作成が必須です。
このユーザーグループにコンプライアンスポリシーや構成プロファイルなど他のポリシープロファイル類を割り当てることも可能ですが、Windows Autopilot と異なり「デバイスの準備」ではユーザー割り当ての設定を OOBE (out-of-box experience) 中に展開することはできません。
なお、先述の「デバイスの準備」にて OOBE 中に展開が可能なスクリプト、アプリ (それぞれ 10個まで) はデバイスグループに割り当てることが必須となっています。
フロー (上図) を参照いただくと分かりやすいかと思いますが、「デバイスの準備」ではいわば「ユーザーのセットアップ」フェーズがありません。
Windows Autopilot で Hybrid join を構成する際、マネージド環境では ESP の「ユーザーのセットアップ」をスキップすることが推奨されている5ので、すでにこの感覚に慣れている/むしろデフォルトであるという組織もあるかもしれないですね。
これから Autopilot を導入する場合は、必要な設定を設計していくうえで処理の仕様上ユーザーコンテキストで実行が必要になったり、実行タイミングを調整するためユーザーグループ割り当てが必要になったりする可能性もあります。
Autopilot ソリューション選定およびパラメータ設計において、両ソリューションのグループとフロー仕様の差異は考慮する必要があると思いました。
4. デプロイ プロファイル
| ▼ソリューション / 実装可能な構成▶ | 展開モード選択 | Entra ID 参加方式選択 | OOBE 表示カスタマイズ | デバイス名テンプレート |
|---|---|---|---|---|
| Windows Autopilot | 〇 | 〇 | 〇 | 〇 |
| デバイスの準備 | 〇 | 〇 | × | × |
Windows Autopilot と「デバイスの準備」では、Autopilot プロビジョニングの契機となる、いわゆる「デプロイ プロファイル」が異なります。
一応名は体を表すというか、「デバイスの準備」では意外にもデプロイ プロファイルという名称が使われておらず、「デバイス準備ポリシー」という名称になっています。
「デバイス準備ポリシー」は、Entra 参加方式や展開モード (現在はユーザードリブンのみ可能) を指定する点で Windows Autopilot のデプロイプロファイル に相当しますが、OOBE (out-of-box experience) 中に展開するスクリプトやアプリの選択も含む点、Enrollment Status Page (ESP) 的役割も包含します。
ただし構成可能な項目という観点において、デバイス準備ポリシー ≠ デプロイプロファイル + ESP です。
具体的には、以下の OOBE 中のユーザーエクスペリエンスを事前構成できない他、デバイス名テンプレートが利用できません。
デバイス名は、別途スクリプトなどで構成しない限り Windows 既定の DESKTOP~ になります。
-
OOBE 中のユーザーエクスペリエンス
(「デバイスの準備ポリシー」では構成不可)- 国と地域
- キーボード
- ライセンス同意
- プライバシー設定
この点は実際にプロファイルを比較してみると、設定項目に差異があることから違いが一目瞭然です。
-
Windows Autopilot デプロイプロファイル (構成例)
-
Windows Autopilot ESP プロファイル (構成例)
-
Windows Autopilot device preparation 「デバイス準備ポリシー」(構成例)
開発情報！
デバイス名テンプレートについては、Windows Autopilot デバイスの準備でも対応することがロードマップにあるらしいです。
5. ESP (Enrollment Status Page)
| ▼ソリューション / 実装可能な構成▶ | ESP プロファイル |
|---|---|
| Windows Autopilot | 使う |
| デバイスの準備 | 使わない |
Windows Autopilot は Enrollment Status Page (ESP) によりポリシー適用完了までのステイタスを表示し、かつ 適用完了までデスクトップ画面の利用を待機させることが可能です。
この点、「4. デプロイ プロファイル (上のセクション)」にて先述・写真掲載の通り、「デバイスの準備」ではデバイス準備ポリシーが ESP にて構成可能な項目を包含しており、ESP プロファイル無しでステイタス表示およびポリシー適用完了までのホールドを行ってくれます。
6. 展開可能な設定
「デバイスの準備」を使ったプロビジョニング中に展開可能な設定には、まず以下の三原則があります。
- システムコンテキスト
- デバイスグループ割り当て
- 10個まで
先述の通りいわゆる「ユーザーのセットアップ」にあたるフェーズが「デバイスの準備」には無いため、ユーザーコンテキストやユーザーグループ割り当ての構成は展開しきることができません。
なお、あくまで「プロビジョニング中に展開可能か」という観点の話のため、この条件に当てはまらない構成については OOBE (out-of-box experience) 後 (プロビジョニング以降) に順次展開されます。
改めてまとめると、スクリプト、アプリそれぞれ以下の特徴があります。
スクリプト
| ▼ソリューション / 展開可能な構成▶ | 実行コンテキスト | 割り当てグループ | 数 |
|---|---|---|---|
| Windows Autopilot | システム、ユーザー (どちらでも) | デバイス、ユーザー (どちらでも) | 上限なし |
| デバイスの準備 | システムのみ | デバイスのみ | 10個まで |
スクリプトの形式は Windows Autopilot も「デバイスの準備」も双方 PowerShell です。
Tips
.bat や .vbs などの PowerShell 以外の形式の実行ファイルを展開したい場合は、intunewin 形式でパッケージングして Win32 アプリとして展開することになります。
アプリ
| ▼ソリューション / 展開可能な構成▶ | 実行コンテキスト | 割り当てグループ | 数 | LOB アプリ | Win32 アプリ | ストアアプリ | M365アプリ |
|---|---|---|---|---|---|---|---|
| Windows Autopilot | システム、ユーザー (どちらでも) | デバイス、ユーザー (どちらでも) | 上限なし | 〇 (Win32と併用不可) | 〇 (LOBと併用不可) | 〇 | 〇 |
| デバイスの準備 | システムのみ | デバイスのみ | 10個まで | 〇 | 〇 | 〇 | 〇 |
Windows Autopilot では 1つのデプロイメントで LOB アプリと Win32 アプリを含めてはいけない鉄則がありました (LOB と Win32 どちらも含めた場合 Intune Management Extension が処理できずエラーになる)。
その点、「デバイスの準備」ではこれらの併用が可能です。
個人的には、もう Win32 アプリ寄せに設計する慣れがあるので、今の時点ではまだ併用解禁のメリットはそこまで感じていません。
構成プロファイル
「デバイスの準備」の公開情報には構成プロファイルについて展開完了までホールドしてくれるのか？ 観点の明確な記載が現状無いように見えますが、検証ではプロビジョニング中にデバイスグループ割り当ての構成プロファイルが適用完了する動作となっていました。
ちなみに構成プロファイルのなかでも DFCI (Device Firmware Configuration Interface、デバイスのファームウェア構成インターフェイス) は明確に「デバイスの準備」では利用不可とのことです。
(参考：Compare Windows Autopilot device preparation and Windows Autopilot)
既知の事象
Windows Autopilot に既知の事象があるように、「デバイスの準備」にも既知の事象があります。
「デバイスの準備」はリリースから日が浅いことから、バグ的な事象もあり、一部は今後解消される予定だそうです。
この記事公開後も数か月 (if not weeks) くらいでアップデートがありそうな予感が個人的にはしており、特に案件で Autopilot のソリューションを検討する場合は今後もこまめに既知の事象は確認が必要だろうと思いました。
2024年 6月 5日に Windows Autopilot デバイスの準備がリリースされた直後、業務用デバイスの識別子の Windows サポートが不具合により一時期ストップしましたが、6月最終週~7月頭にサポートが復活しました！
直近で私が検証した際は、Entra ID のデバイスの設定と「デバイス準備ポリシー」の競合により「デバイスの準備」によるプロビジョニングがスキップされる事象に遭遇しました。
こちらも現在既知の事象としてリストされています。
(参考：Conflict between Microsoft Entra ID and Windows Autopilot device preparation local administrator setting)
やってみた (GIF付き)
なにも検証せずに記事を書くのはまずいだろうと思い、簡単な構成で基本的動作を確認しました。
Step by step の構成方法についてはすでに網羅性の高い公開情報 (↑ 上記参考リンク) があるため、本記事での記載は割愛します。
展開した設定は構成プロファイルとアプリ、タイムアウトは 30分にしました。
【GIF】プロビジョニング画面
業務用デバイスの識別子サポート復活情報が出る前のタイミングだったため、業務用デバイスの識別子を使わずに動作確認しています。
ペラペラの仮想マシンだったためアプリ展開に時間がかかってしまい、幸か不幸かエラーページを見ることに成功 (?) しました。
ただ、エラーを出して気づいたことは、デバイス側ではあくまで 30分のタイムアウトまでの間の処理を時間で等分したパーセンテージが表示されるということです。
今回だとアプリの 1/2 を展開した段階で総処理時間が 30分のタイムアウトに達したためエラーになっているので、実際のプロビジョニング進捗としては 90% 程度の段階でエラーが発生していることになります。
(構成プロファイル 8個＋アプリ 2個 = 10 を 100% とし、単純に個数で割り算した場合)
ただし、あくまでデバイス上の表示は 30分になった時点で進捗 99% と表示され、そのあとエラー画面に推移しました。
(あと 1% 惜しくも...! という状態に見えますが、実際の進捗はそこまで惜しい状態ではないです。)
こうなると、あくまで管理者目線では Windows Autopilot の各フェーズの Y/X が見えた ESP の方が嬉しかったかなと思ったりもしました。
レポート
個人的に一番感動したのは、やはり "near-realtime" の新しいレポートです。
Windows Autopilot のレポートはデプロイ後に結果が表示され、必要に応じてデバイスの診断アクションを実行するいわば事後の状況把握用レポートという側面が強いですが、新しい「Windows Autopilot デバイス準備の展開」レポートはプロビジョニング中から進行状況をほぼリアルタイムで追うことができます。
検証時は、デバイス側のプロビジョニング進捗が 20% 程になったタイミングでレポート画面上にレコードが出現し、デバイスの進捗が見れるようになりました！
どのアプリ / スクリプトが成功 / 失敗しているか、Intune Management Extension Log を開かずともほぼリアルタイムで管理センター上で把握することができます。
これがあることを踏まえると、デバイス側の進捗表示は多少ガバくてもいっか♪ という気持ちになりました。
デバイス プロパティ
プロビジョニング完了後に、デバイスのプロパティを管理センターにて確認しました。
あくまで 2024年 6月 27日時点の検証結果ですが、現状 「登録プロファイル (enrollmentProfileName)」は空値 となりました。
Windows Autopilot では、適用されたデプロイプロファイルの名前を「登録プロファイル (enrollmentProfileName)」の値としてデバイスが持つので、フィルターなどでこのプロパティを掴むと Autopilot 前と後、対象と対象外を区別することができます。
この点、「デバイスの準備」では利用できなさそうです。
ただし、プロパティが変更になる例も (別機能の例ですが) あるので、この点は将来的に変更される可能性もゼロではないと思います。
(現状は情報無し)
さいごに
デバイス管理を設計するうえで、デバイスのライフサイクル検討は避けては通れない考慮点です。
Intune を使う際に Autopilot を導入すると、デバイスの利用開始から再利用まで輪を完成させることができます。Autopilot はライフサイクル管理における重要なピースで、出発点であり終着点だと思います。
昨今コロナ禍や働き方改革を経てハイブリッドワークが注目されるなか、キッティングも場所に縛られないかつ運用負荷を軽減するロータッチ設計が求められており、Autopilot の注目度も上がっていると感じます。
そんななか、Government クラウドのサポート拡充を契機にまったく新しい Autopilot ソリューションとして「Windows Autopilot デバイスの準備」が登場しました。
本当に胸アツですし、既存の Windows Autopilot 含めまだまだ活発に開発予定があり、今後にも期待しかありません！！
ただし選択肢が増えたというのは設計の考慮点も増えたのと同義でもあります。
これからの Autopilot 設計は一考の必要がありますが、その中でもスピードを落とさずプロジェクトを進めるには、個人的にはとりあえずシナリオ検討から先にするのがよいかと思いました。
具体的には、Entra 参加方式や展開シナリオ (展開モード) を検討し、そこでソリューションが決まるのであれば決めます。
ソリューション検討は要件定義後基本設計期間中に最終判断でも遅くないです。
ただし、パラメータレベルでは設計要素が異なるため、詳細設計時点では決まっている必要があります。
並行して、スクリプトやアプリは早めに検証を開始し、処理の仕様上コンテキストやグループで考慮が必要か洗い出し必要に応じてソリューション選定にフィードバックできるのがベストだと思います。
なお設計の現場としては、現状は Entra hybrid join のニーズも根強く、事前プロビジョニングも人気高く感じます。私はまだ Windows Autopilot or Windows Autopilot デバイスの準備 という岐路に立ったことはありません。。 (後者はリリース後やっと 1か月なのでまあそんなものなのか)
ただし、今後の潮流としてはクラウドファースト、ゼロタッチキッティングですので、比較する機会も増えてくるのではと思います！
So let's buckle up and hope we'll all have a safe flight Autopilot-ing!
現場からは以上です！
-
Autopilot 用語：TechCommunity ブログや公開情報上、「Windows Autopilot デバイスの準備」は「ソリューション」と位置付けられています。Autopilot のソリューションは現状、既存の Windows Autopilot と、新しい「Windows Autopilot デバイスの準備」の 2つあるという位置づけです (参考：Announcing new Windows Autopilot onboarding experience for government and commercial customers、Compare Windows Autopilot device preparation and Windows Autopilot)。ソリューションの下にさらに「展開シナリオ (展開モード)」という概念があり、① ユーザー駆動、② 事前プロビジョニング、③ 自己展開、④ Existing Devices、⑤ Autopilot reset がこれに該当します (参考：Windows Autopilot scenarios)。また、Entra 参加方式 (参加オプション) が別概念としてあり、Autopilot 全体としては ① Entra join または ② Entra hybrid join いずれかが可能で、各ソリューションと展開シナリオによりサポート状況が異なります。 ↩ ↩2 ↩3 ↩4
-
選択肢：上の「Autopilot 用語」注釈に Autopilot における各機能の区分け概念を記載しましたが、新規端末の provisioning における選択肢として、本記事ではソリューションと展開シナリオを横断してよくある選択肢を恣意的にピックアップしました。 ↩
-
Windows Autopilot で利用可能な 3rd party MDM：Autopilot をサポートしており (各ベンダードキュメント参照) かつ Entra ID に MDM アプリとして登録している場合は、Autopilot によるデバイスプロビジョニング過程でその MDM への登録が可能です。なお、Entra ID と紐づけてサポート可能な MDM は 1つまでのため、3rd party MDM を使う場合 Intune は使えなくなります。逆もまた然りです。 ↩
-
Intune Provisioning Client：Entra ID 上のエンタープライズ アプリです。アプリ ID は「f1346770-5b25-470b-88bd-d5744ab7952c」で、環境によっては別の名 (Intune Autopilot ConfidentialClient) で表示されることがあるそうです。テナント上に存在していない場合は、先にアプリを作成してからデバイスグループを作成する順で構築します。(参考：Windows Autopilot device preparation user-driven Microsoft Entra join: Create a device group) ↩
-
Hybrid join 構成時はユーザーのセットアップ (UserStatusPage) スキップが推奨：元 Microsoft 社社員で Windows Autopilot 開発に多大な貢献をされた Michael Niehaus氏のブログです - Troubleshooting Windows Autopilot Hybrid Azure AD Join ↩