Windows Autopilot と ESP を組み合わせたアプリ配布のコツ

こんにちは。皆さんは、Windows Autopilot によるゼロタッチキッティングは思うように運用できていますか。

弊社では、Microsoft Intune を利用し多くのお客様の Windows MDM (Mobile Device Management) 環境の構築および運用支援を日々行っておりますが、その中でも以下のようなお悩みをよく聞きます。

「割り当てを必須にしているのに、いつまでもインストールされないアプリがある」
「このアプリは必ず最初に配りたいのに、インストールされる前にユーザーが使いだしてしまう」
「インストール後に再起動が必要な必須アプリがあり、勝手に再起動されてしまう」

このようなアプリ配布の悩みにつきまして、本記事では『依存関係』と『登録状態ページ』を活用したアプローチをご紹介いたします。

『依存関係』を活用し、アプリの配布順をコントロールしよう
『登録状態ページ (ESP)』を活用し、デスクトップが出る前に設定してみよう
ESPを乗りこなすには、『ユーザー』と『デバイス』のスコープを意識しよう

『依存関係』の設定

皆さんは、アプリ配布の際に『依存関係』は利用していますか？

アプリの種類が『Windows アプリ (Win32)』の時に使用できる機能ですが、アプリ自体の仕様による直接的な依存関係（例えばランタイムを入れてからアプリを入れる、本体を入れてから設定を配るなど）に活用されている方が多いかと思います。

（本記事では詳しくは触れませんが、『基幹業務アプリ』と『Windows アプリ (Win32)』は配布処理が競合してエラーになる仕様のため、混在しての配布は非推奨となり、MSIパッケージも『Windows アプリ (Win32)』として配布することが推奨されています）

そのような機能的制約だけでなく、業務上またはセキュリティ上の要件から、以下のような設定も行うことができます。

セキュリティソフトのエージェントを最初にインストールしてから、他のソフトを配布したい
Google Chrome をまず先に入れたい
VPN や SASE を早めに入れておきたい

設定する場合は、以下の手順で進めていきましょう。

Intune 管理センターで Windows アプリの一覧を開きます
　アプリ＞プラットフォーム＞ Windows
後からインストールしたいアプリ（Windows アプリ (Win32)）をクリックして開きます
[管理] > [プロパティ] > [依存関係] > [編集] をクリックして開きます
『依存関係』タブで [+追加] をクリックします
右のポップアップで、先にインストールしたいアプリを選択し（複数選択可）、下部の [選択] ボタンで決定します
選択したアプリが一覧に表示されるので、自動インストールで [いいえ] を選択し、下部の [レビューと保存] ボタンをクリックします
『置き換え』タブでは何もせず、下部の [レビューと保存] ボタンをクリックします
『レビューと保存』タブで内容を確認したら、下部の [保存] ボタンで確定します

これで『依存関係』の設定は完了です。

各アプリごとに設定していく必要があるのと、あまり複雑に組むとあとで管理が大変になります。そのため、極力シンプルな構成にするか、依存関係を作図してドキュメントに残しておくといいでしょう。

（後述のESP設定にも影響するので、その際に見直す可能性があることも考慮した方がよいです）

『登録状態ページ (ESP)』の概要

まずは、ESPの概要を押さえていきましょう。

『ESP (Enrollment Status Page、登録状態ページ)』とは、OOBE（Out of Box Experience、デスクトップが表示されるまでの初期設定画面のこと）において、登録および設定の状況を可視化する画面を挿入する機能になります。

ESPを設定しない場合、最低限の初期登録のみが行われた状態でデスクトップ画面に遷移し、そのあとに設定が進む仕様となっております。

これは Windows Autopilot の場合も同様で、ESPを設定しない場合はデスクトップが表示されてから設定されるのを待つ必要があります。また、再起動が必要な設定（アプリだけでなく、BitLocker設定後のポリシー準拠判定なども含みます）を完了させるには、その後で（自動または手動で）再起動させることが必要になってきます。

ESPは、以下の三段階のプロセスで進行します。

デバイスの初期登録
『デバイス』に対する初期設定、アプリインストール
『ユーザー』に対する初期設定、アプリインストール

ここまで完了すると、Windows Hello for Business の設定を挟み、デスクトップ画面が表示されます。

また、2つ目以降のユーザープロファイルを作成するタイミングでは OOBE を挟みませんが、ESPのユーザーに対する設定機能 (上記の3.) のみ利用することが可能です（対象のオプションを有効化する必要があります）。

ここで、「それなら、必要なアプリは全部ESPで入れちゃえばいいじゃん！」となると思います。

しかし、色々と検証を進めていくと、そうはいかないことがわかってきます。

そこでいくつか、利用する上でのポイントをまとめていきましょう。

ESPを活用するためのポイント

ESP中に配布できるアプリは、多くても5個くらいまで
『ユーザー権限』でインストールするアプリは必ず『ユーザー』に割り当てて配ろう
Microsoft Store アプリも『ユーザー』に割り当てて配ろう
DeviceLockポリシーも『ユーザー』に割り当てて配ろう
『依存関係』との矛盾に気を付けよう
インストール後に再起動をするアプリは1つまで
判定可能な『デバイス』の割り当ては限定的

1. ESP中に配布できるアプリは、多くても5個くらいまで

「ESP中に全部配れば、デスクトップが出た瞬間終わるし最高じゃん！！」と皆さん思うと思います。

ところがどっこい、以下のような理由があり色々とそうもいかないのです。

ESP中に発生したアプリ配信エラーを解析するのはかなり大変
ESP中は、デスクトップ表示後と挙動が異なるインストーラーや環境変数があり、それを問題なく動作させるインストールスクリプトや検出ルールを作成するのが大変
仕様上ESP中には配布すること自体できないアプリというものが存在する
インストール後に再起動を要するアプリによって、ESP中に再起動を複数回繰り返すことができない

細かい解説は本稿では省きますが、「対象は『ESP中に配布可能』かつ『どうしても利用前に必須』なものに絞り込み、5個以内には収めましょう」と覚えておいてください。

また、『Microsoft 365 Apps (Officeアプリ)』については、当方の環境ではインストールがスキップされたり、ESPが異常終了に陥るなどの不安定な動作が見受けられたため、ESP中の配布対象にはせずにデスクトップ表示後の配布とすることをオススメしています。こちらですが、もし回避方法をご存知の方がいましたら是非お知らせください。

2.『ユーザー権限』でインストールするアプリは必ず『ユーザー』に割り当てて配ろう

こちらもインストールに関する仕様上の制約になります。
『システム権限』でインストールするアプリは、『デバイス』への割り当てで問題ありません。

3. Microsoft Store アプリも『ユーザー』に割り当てて配ろう

様々なパターンで検証しましたが、『デバイス』への割り当てではうまくインストールされないので、原則として割り当てを『ユーザーグループ』に必須で配布する設定としてください。

4. DeviceLockポリシーも『ユーザー』に割り当てて配ろう

無操作時の画面ロック/電源制御を制御するプロファイルを設定したい場合、『デバイス』への割り当ても可能ではあるのですが、『ユーザー』セットアップの開始時にパスワード入力が求められてしまう点には注意が必要です。

対象のスコープ上、どうしても『デバイス』割り当てで実施する必要性がある場合を除き、手ぶらでラクチンな Autopilot を実現するためにも『ユーザー』に割り当てを行いましょう。

5.『依存関係』との矛盾に気を付けよう

こちらは、以下の順番で処理されるので、矛盾しないように整理する必要があります。

ESPで入れるアプリのうち、『デバイス』に割り当てたもの
ESPで入れるアプリのうち、『ユーザー』に割り当てたもの
デスクトップが表示されてから入れるアプリ

上記ルールを超えて『依存関係』を設定した場合、当然破綻します。

ESP内でルール違反となった場合、その場でエラーとなり、ESPが完了しません。

あくまで、「ESPを通っても通らなくても、同じ順序でアプリが入るように」という意識で『依存関係』を設計する必要がある、というわけですね。

6. インストール後に再起動をするアプリは1つまで

これも検証の結果ですが、ESP中に複数回の再起動はできないようでした。

ただ、1回であれば再起動は可能なようなので、『依存関係』を活用し、後からインストールするアプリで1度だけ再起動をかける、という設計は可能かもしれません。

ただし、Autopilot ではない端末では動作がおかしくなると思いますので、その場合インストーラーは共用しない整理とした方がいいかと思います。

また、ESP中に再起動をかけた場合、（ESP開始前に一度認証していますが）再度ログイン認証が求められる点は注意が必要です。

「ESP開始したし、あとは待つだけだ」とはならない、ということですね。

「ログイン認証画面が出てるし、もうデスクトップ出てロック掛かってるのかな？」と思ったらまだESPの途中でした…ということになり落胆しないよう、流れをきちんと押さえておきましょう。

7. 判定可能な『デバイス』の割り当ては限定的

検証の結果、以下のような制限があることがわかっています。

判定可能
- すべてのユーザー、すべてのデバイス
- Autopilot かどうか
- ユーザーグループ
判定不可能
- デバイスグループ
- Autopilot のグループタグ
  - 新規端末は原則不可（一度 Microsoft Entra 参加済の端末の Entra/Intune 側の情報を削除せずに端末を初期化し、再度 OOBE から Autopilot に入った場合に限り判定可能）

結論として、「『Autopilot かどうかを判定するデバイスグループ』以外のデバイスグループは、ESPでは利用できない」という前提で整理してESPを含めた全体設計をしましょう。

実際にESPの設定を行ってみましょう

まずは ESP の設定に必要な項目を確認してから、実際の設定を行いましょう。

【ESPの設定前の確認】

ESP の対象とするグループが決まっていること
- 『すべてのユーザー』『すべてのデバイス』も設定可能ですが、非推奨です
- デバイスグループ：通常、以下のクエリのAutopilotグループのみが利用可能です
  ※Autopilotのサービスタグや、その他のデバイスプロパティはOOBE中に判定ができないため、ESPの対象にすることができません
  - 1(device.devicePhysicalIDs -any (_ -contains "[ZTDID]"))
- ユーザーグループ：特に制限はありません
ESP で配布対象となる設定の確認
- 『すべてのユーザー』および『すべてのデバイス』に配布される設定およびアプリ
  - 構成プロファイル、コンプライアンスポリシー、Windowsアプリ　など
- ESP の対象とする『ユーザーグループ』または『デバイスグループ』に配布される設定およびアプリ
ESP で配布対象となるアプリの確認
- 依存関係が配布順序（デバイス → ユーザー → ESP対象外）と矛盾しないこと
- その他、前述のポイントの通りにアプリの設定および割り当てがされていること

【ESPの設定手順】

Intune 管理センターで、デバイス＞デバイスのオンボーディング＞登録を開きます
Windows タブ＞ Windows Autopilot ＞登録状態ページを開きます
一覧上部の [+作成] をクリックします

※規定値で『すべてのユーザーおよびデバイス』が表示されていますが、こちらはそのままにしましょう。未設定端末の設定を変更してエラーでハマるとリカバリが大変です
『名前』『説明』を入力し、[次へ] をクリックします
『設定』タブで、下図のとおり入力し、[+ アプリの選択] をクリックします
ESP中で配布したいアプリを選択します（※前述のポイントを参考に5個以内程度）
アプリが表示されたら、[次へ] をクリックして進めます
『割り当て』タブで [グループの追加] をクリックし、対象のグループを選択したら [次へ]
『スコープタグ』タブは必要に応じ設定し、[次へ]をクリックします（※規定値のままで問題なし）
『確認および作成』タブで内容を確認し、問題なければ [作成] ボタンをクリックします
一覧に戻り、作成したものが『規定値』よりも高い優先度で表示されていることを確認します

以上で初期設定は完了です。
この後は、テストをしながらチューニングを進めていきましょう。

【OOBEから初期設定を行う場合の動作確認】

OOBEでの初期設定時を想定した、通常のESPをテストします。
初期化した状態でスタートし、OOBEからデスクトップまでたどり着けるか、または止まった時/終わった時の状態を確認していきます。

テスト対象のESPの設定が、『エンドユーザーのログ収集と診断ページを有効にする：はい』であることを確認します
初期化した状態のPC（またはVM）を用意します（なお、Autopilot設定の有無は検証スコープによりますので、必須ではないです）
OOBEから初期設定を進めてサインインし、ESPが始まることを確認します
ESP中にエラーが出て止まった場合、エラー原因を確認します
1. ログ収集と診断ページからログを取得する場合、USBメモリなどの外部媒体が必要です。対象PCのローカルには保存できません
2. セットアップをやり直す場合、『再試行』はエラーとなり実行できない場合が多いです。その場合は、[Ctrl] + [Shift] + [F3] で監査モードに入ろうとすると再起動が掛かるので、再起動中の UEFI 起動メッセージ中のコマンド入力でリカバリモードに入りましょう
ESP中にエラーが無く、そのままデスクトップが表示された際に未完了の項目がある場合、割り当てやスコープの抜け漏れを確認します
エラーや想定外の項目があった場合、ESPの対象やアプリの設定/割り当てなどを見直してから再試行します
ESP中のエラーおよびデスクトップ表示後の想定外が解消されれば、テスト完了です

【追加ユーザーをセットアップする場合の動作確認】

ESPで『OOBEでプロビジョニングされたデバイスにのみページを表示する：[いいえ]』の場合です。
『すべてのユーザー』および『ユーザーグループ』で指定されている設定・アプリのみがESP中に配布され、デバイスが対象となるものはデスクトップ表示後に配布されます。

ローカルユーザーまたは ESPでテストを行うユーザー以外のユーザーでPCにログインします
Windowsのユーザーセッションからサインアウトします
ESP対象のユーザーで新規にサインインし、プロファイル作成画面がESPに切り替わることを確認します
ESPの結果を見届け、エラーが発生した場合はエラー個所を確認します

まとめ

『依存関係』や『登録状態ページ』は使いこなせると、ゼロタッチデプロイの体験向上に繋がります。
まずは導入が比較的容易な『依存関係』を試してみて、次のステップとしてESPをスモールスタートからはじめていきましょう。

ZUNDA は、Microsoft 365 の導入支援・運用サポートに豊富な経験を持つ、Microsoft ソリューションパートナーです。Microsoft Entra を使ったデバイス管理や Intune の導入を検討されているお客様、または既存の IdP/MDM 環境の改善・再構築をお考えのお客様は、ぜひ当社までご相談ください。要件を詳しくヒアリングし、おすすめのプランをご提案します。

情報セキュリティ対策は、企業の信頼を守るための重要な投資です。Intune を活用して、安心で安全な情報活用環境を構築しましょう。

まずはお気軽にお問い合わせください。お客様のセキュリティ強化を全力でサポートいたします。

ミーティングを予約する