皆さんこんにちは、システムソリューション営業本部 高山です。

Windows Autopilot（以降、Autopilotと表記）の機能検証について、まだまだ書いていきます！
前回は、デバイスとユーザーのどちらに紐づけてもアプリがインストールされるのか、実際に設定してみました。

事前プロビジョニングはバーチャルマシン（以降、VMと表記）に対応していないため
VMではなく実際のWindos10 PCを使用して、事前プロビジョニングでキッティングをしていきます。

ユーザーグループとデバイスグループデバイスそれぞれに割り当てたアプリ・ポリシー適用のタイミングを確認しつつ、Autopilotの”デバイス”ページで「割り当てユーザーを指定していた場合」「割り当てユーザーを指定していない場合」の２パターンでAutopilotの実行画面でポリシーやアプリの配信など、どの様な違いが出るか確認したいと思います。

事前プロビジョニングとは

設定や事前準備について書く前に、そもそも「事前プロビジョニング」ってなんだろうと思って調べてみました。

元々は「White Glove」という名前で、Autopilotのデプロイ プロファイルで設定できる機能の1つです。
キッティング担当者が白い手袋をして作業する絵が浮かびますね！

PCの電源を入れてすぐの初期状態からのキーボードのレイアウト指定時に Windowsキーを5回入力することで
事前プロビジョニングのメニューを表示することができます。



事前プロビジョニングでできることは以下の２つです。

• デバイスに対して割り当てられたアプリケーション、証明書、セキュリティテンプレート、設定、ポリシーの適用
• ユーザーに対して割り当てられたアプリ(Win32アプリ等)のインストール

この時点では、”事前プロビジョニングしないでやったセルフキッティングと変わらないな？
事前プロビジョニングってやる必要あるの？”と思いました。

以前に書いた「セルフキッティング編」で、実際にAutopilotを設定・実施を行った際は、Intuneから配信するアプリの数・展開するプロファイルの数などにも影響されるかと思いますが、電源を入れてから全てのプロセスが完了するまで30分以上かかっていました。

事前プロビジョニングを使用した場合、IT管理者・情報システム担当者側での作業が入るものの、ユーザーの手元にデバイスが届いてセルフキッティングする際の待機時間がぐっと短くなります。

理由としては、時間のかかる処理(アプリケーションの配信など)を情報システム担当者側で事前に終わらせることが出来るからです。

言葉だと分かりにくいので、セルフキッティングの時に使った図を事前プロビジョニングをした場合の図にしてみました。



情報システム担当者側でデバイスに割り当てたものが設定した後、事前プロビジョニングの成功画面が
表示されて再起動がはいるのでシャットダウンしてユーザーの手元に送る。

PCが届いたらユーザーはアカウント情報を入力してユーザ認証を行い10分ほどで仕事が始められる、時間の面だけ見るとユーザーが業務開始までの時間はかなり短縮されます。

事前準備

事前プロビジョニングの設定・実施をしていく前に、以下5点の確認を行います。

今までより確認することが多いですが、これまで書いてきたブログの条件や事前準備と
同様の内容のものもあるのでおさらいだと思いながらやっていきます。

• 対象デバイスが実施条件に当てはまるか
• デプロイプロファイルで「事前プロビジョニングされたデプロイを許可する」が”はい”になっているか
• 対象のデバイスがAutopilotのデバイスとして登録されているか、デバイスグループのメンバーに入っているか
• 配信したいアプリや構成プロファイルが作成されているか
• アプリや構成プロファイルが作成されている場合、ユーザーグループやデバイスグループに割り当てられているか

◆対象デバイスが実施条件に当てはまっているか

前回まではWin10のVMでしたが、今回は物理端末であるノートPCでの実施のため、改めてAutopilotが可能なデバイスなのか確認を行います。
セルフキッティング編で対象デバイスの条件を記載しているので、よければ見てみてください！

◆デプロイプロファイルで事前プロビジョニングが許可されているか

OOBE編で設定したデプロイプロファイルの設定に「事前プロビジョニングされたデプロイを許可する」
という設定があります。

これが”はい”に設定していれば事前プロビジョニングの実施ができます。もし”はい”になっていなければ、
編集をクリックして変更してください。

詳しい設定方法については、プロファイル作成のブログの記事も書いたので、良ければご覧下さい。

◆対象のデバイスがAutopilotのデバイスとして登録されているか

キッティングを行うPCが、以前に誰かが使っていてIntune上に情報が残っている可能性もあるため、
Intune上でホスト名やシリアル番号で検索してデバイス登録されていないか確認をします。

前回のアプリ配信編で少し触れましたが、Autopilotのデバイス画面で「関連付けられている Intune デバイス」にデバイス名が入っていたり、
Azure AD上でユーザー名が紐づいていると事前プロビジョニングでのキッティングがうまくいかず再初期化が必要になるので、そのための確認になります。

※事前プロビジョニングを使用しない場合は、Intune上からデバイス情報の消去の必要はありません。

デバイス情報の削除

まずはPCの電源を入れたらすぐにShift＋F10キーでコマンドプロントを立ち上げ、「wmic bios get serialnumber」でシリアル番号を確認します。



Intuneのデバイスからシリアル番号で検索をかけ、デバイス情報が見つかったので削除していきます。



続いて、Autopilotのデバイスでもシリアル番号で検索、デバイス情報があったのでこちらも削除。
削除する前に、「関連付けられているAzure AD デバイス」に記載のあるデバイス名をコピーします。



今度はAzure portalサイトを開き、Acitive Directory（以降、Azure ADと表記）のデバイスからコピーしたデバイス名を検索。デバイス情報とユーザーの紐づけがあったので削除しました。



※Autopilotデバイスに登録されているとAzure ADからデバイス情報の削除ができないので、Intune→Autopilot→Azure ADの順番で削除をしてください。

デバイス情報の登録

Intune上とAzure AD上からデバイス情報を消したので、デバイスの登録状況としては何も登録されていない真っ新な状態になりました。
Autopilotのデバイスとして再度登録をするために、HWIDやデバイス情報が記載されたcsvファイルをIntuneにインポートする必要があります。
今回はPCからPowershellを使ってHWID登録用のcsvファイルを作成しました。
まずはPCの電源を入れて、ネットワーク接続をするところまで行います。



ネットワーク接続後、Shift＋F10でコマンドプロントを開き「Powershell」と入力して、Powershellを起動。

以下のコマンドを順々に打っていき、csvファイルを作成します。

※ネットワークに接続をしていないと、4行目でエラーが出てしまうので事前に接続しておきましょう。



上記コマンドを実行してcsvファイルがCドライブ直下に作成されたら、
コマンドプロンプトで「start msedge」と入力しインターネットブラウザを開きます。

URL欄に「https://endpoint.microsoft.com/#home」と入力し、Intuneに管理者アカウントでログイン。
「デバイス」→「Windows」→「Windows登録」→Windows AutoPilot Deployment プログラムの「デバイス」を選択。
インポートをクリックして、作成したcsvファイルを選択し「インポート」をクリック。
これでAutopilotのデバイスとして、新規登録されます。

Intune上にAutopilotのデバイスとして登録されたことの表記が確認できたらノートPCはいったんシャットダウンして閉じます。



インポートしてからAutopilotのプロファイルが再度割り当たるまで時間がかかるとなっていたので、その間に構成プロファイルが作成されているかの確認をして待ちました。（実際15分以上割り当てまでかかりました）

何度か更新をかけてプロファイルの状態が「割り当て済み」になれば、事前プロビジョニングでのキッティングが可能です。

デバイスグループ確認

アプリやポリシーを割り当てるデバイスグループにメンバーとして入っていなければ展開されないため、グループのメンバーとして入っているか確認を行います。
シリアル番号からデバイス検索し、グループメンバーシップでAutopilotのグループに入っていることを確認します。

◆配信したいアプリや構成プロファイルが作成されているか

前回アプリの配信設定を行ったので、ここでは構成プロファイルについて確認・作成方法を書いていきます。

もしアプリが作成されていない場合は前回のブログを参照してみてください！
Windows Autopilot を使ってみた　ーアプリ配信編ー

今回は、ユーザーグループ・デバイスグループ用で構成プロファイルを作成しました。

２つ一気に書いていきます！

デバイスグループ用の構成プロファイルの作成

Intuneからデバイス→構成プロファイル→プロファイルの作成をクリック。

プラットフォームを「WIndows10以降」、プロファイルの種類を「テンプレート」の「カスタム」を選んで「作成」。



名前を分かりやすい名前「Autopilot device test」とし、「次へ」

OMA-URI（構成設定のパス）の「追加」をクリックし、名前とパスを追加。
今回は大きいサイズのアプリケーションを配信することを想定して「配信の最適化」の「最大バックグラウンド ダウンロード帯域幅」設定を行いました。
OMA-URIのパスを入力しデータ型は整数、値は1000にして保存し、「次へ」



割り当てにデバイスグループを割り当てて保存すれば完了です。

◆アプリや構成プロファイルが作成されている場合、ユーザーグループやデバイスグループに割り当てられているか

念のためアプリや構成プロファイルの割り当てグループが間違っていないか確認です。
確認の方法は各アプリ・構成プロファイルのプロパティから割り当てからグループの確認ができます。

Intuneの事前プロビジョニング設定

事前準備でデバイスやAutopilotの設定確認が終わったら、事前プロビジョニングを行うために設定を行っていきます。

◆登録ステータスのページ作成

Intune上の”デバイス”より、”登録ステータスのページ”の作成を行います。
※事前プロビジョニングをしない場合でも、Autopilotでキッティングをする場合はこの設定が必要です。

デバイス→Windows→Windowsの登録→登録ステータスのページの順番で確認することができます。



「アプリとプロファイルの構成の進行状況を表示します」を「はい」に設定。
デバイスグループを割り当てて保存。（ユーザーグループも選択できますが、ユーザー認証してからでないと割り当たらないためここでは選択しません。）



試しに「いいえ」で事前プロビジョニングを行ったところエラーが起きました。

Intuneのサポートへ問い合わせを行ったところ、「アプリとプロファイルの構成の進行状況を表示します」を「はい」に設定しないと、事前プロビジョニングが失敗する可能性があるとのことでした。注意しましょう。

◆Autopilotのデプロイ プロファイルの割り当て確認

最後に念押しの確認です。

今までアプリや構成プロファイルを割り当ててきたデバイスグループとユーザーグループが、Autopilotのデプロイ プロファイルにも割り当たってるよね？と確認をします。
割り当たってることができたらようやく実際に事前プロビジョニングをやっていきます。

Autopilotデバイスへのユーザー割り当て

通常、デバイスのキッティングをしている時にユーザー認証する場面があり、そこでユーザーのアドレスとパスワードを入力してから、IntuneとAzure ADに同期されてデバイスにユーザーが紐づけられます。

Autopilotの”デバイス”から事前にユーザー割り当てができるみたいだったので、こちらも設定してユーザー認証にどう影響があるのか確認することにしました。

事前プロビジョニングではユーザーへの割り当ては実施されないはずなので、
事前にユーザー割り当てを行った場合、どうなるのか確認します。

割り当て方はAutopilotのデバイスで割り当てたいデバイスにチェックを入れ、「ユーザーの割り当て」をクリック。
割り当てたいユーザー名を検索し、選択したら保存します。



この設定で指定したユーザーが割り当たったのか、ユーザー認証後にユーザーが割り当たったのか分かりやすくするために、「ユーザーフレンドリ名」をアドレスに入っていない「TEST」に設定します。

ちなみに、このユーザー割り当ては、Autopilotでのキッティングが終わってる後でも設定することができます。

事前プロビジョニングの動作・配信タイミング確認

ようやく事前プロビジョニングを使ってのPCキッティングです。
1回目をAutopilot デバイスでユーザーを割り当てていない状態、2回目をユーザーを割り当てた状態で行ってみました。

事前プロビジョニングではユーザーに割り当てた設定は実施されないはずなので、
実際に実施されないのか確認を行います。

1回目：「ユーザーフレンドリ名」を割り当てていない場合

まずは電源をつけます。通常どおり、キーボードレイアウトまで設定をしていきます。
CSVでのインポートの際にネットワーク接続してるので、その工程は割愛しております。





２つめのキーボードレイアウト画面になったらWindowsキーを5回押します。



少しすると事前プロビジョニングの画面に移行しました。
真ん中の「Windows Autopilotのプロビジョニング」をクリックして「続行」します。



少しのロード画面後、Autopilotの構成画面が表示されました。
展開プロファイルに入っているプロファイル名があっているか割り当てられたユーザーに何も入っていないことを確認し「プロビジョニング」をクリック。



VMでキッティングした時と同様にESP画面が表示されます。
デバイスの準備、デバイスのセットアップと順々に完了していきました。



「デバイスのセットアップ」が完了後、グリーンスクリーンになりました。
この画面で、一旦デバイスグループに割り当てたアプリとポリシーが割り当たっていることを確認します。

アプリの確認

デバイスグループに割り当てたfirefoxがインストールされているか確認しました。
コマンドプロントをshift＋F10で出し、コマンドでコントロールパネルを出します。
プログラム→プログラムと機能から「firefox」があることを確認。



いつインストールされたかをイベントビューアーでも確認していきます。
コマンドプロンプトに戻りコマンドを「eventvwr」と入力、イベントビューアーを起動。

Windowsログ内のApplicationログの中から、ソースがMSInstallerのログを探します。
※ファイル形式がmsiのインストーラーを使用しているためです。
ログがあることを確認できたら続いてポリシーの確認です。

ポリシーの確認

デバイスグループに割り当てた構成プロファイルが割り当たっているかの確認をします。
firefoxのログ確認で開いたままのイベントビューアーで「アプリケーションとサービスログ」をクリック。
Microsoft→Windows→DeviceManaegment-Enterprise-Diafnostics-Providerを開き、「Admin」を選択。
検索から「Domax」でログ検索し、割り当てられていることを確認。



設定した内容の確認もしたいので、コマンドプロントに戻ります。
「start ms-settings:」と入力し、設定を開きます。
更新のセキュリティ→配信の最適化→詳細オプションから確認。
Intune上で1000KB/秒と設定していたので、Mbpsで計算しなおすと8Mbps。
設定されているのは7.8Mbpsなので、約8Mbpsと考えて大丈夫でしょう。
ということで無事、設定値も割り当たっていることを確認！



firefoxインストールとデバイスポリシーの確認ができたので、事前プロビジョニングの画面に戻ります。
「再シール」をクリックし、シャットダウンをさせてます。
ここからユーザーにPCが渡った時の想定として再度電源を入れます。
電源を入れるとすぐキーボードレイアウトの選択画面に遷移します。



２つ目のキーボードレイアウトの選択をスキップするとすぐにメールアドレス入力画面に遷移します。



パスワードを入力し、「次へ」をクリック。
Autopilotでのセルフキッティングだと、この後ESP画面が表示され長いロードが入りましたが…。



デバイスの準備、デバイスのセットアップを飛ばしすぐに「アカウントのセットアップ」になりました。



数秒でアカウントのセットアップが終わって顔認証画面へ。早い！



Windows Helloの設定画面になりました。ユーザーがやる作業箇所はあっという間です。



PINのセットアップ後、完了画面に。



キッティングが完了したので、ユーザーに割り当てたサクラエディタとユーザーポリシーの確認をします。

アプリの確認

再度コントロールパネルからプログラムと機能を開くと、今度はサクラエディタがインストールされていることが確認できました。

念のため、スタートボタンから検索をかけて表示されるか確認します。
こちらでも表示されていました。



Cドライブ直下のProgram Files(X86)にフォルダが生成されているか確認



作成の確認ができたので、
アプリをクリックして使えるかを確認。



※イベントビューアーを開いてログの検索・目視での確認をしましたが
 ひっかかりませんでした。
インストール時間がわからないため、どこにログが出るのか別途確認をします。

ユーザーポリシーの確認

イベントビューアーを開き、「アプリケーションとサービスのログ」を選択。
Microsoft→Windows→DeviceManaegment-Enterprise-Diafnostics-Provider→「Admin」を開きます。
「ErrorReport」で検索すると、今度は引っかかりました。



キッティング作業が終わってるので、MDM診断レポートも出してみます。
設定→アカウント→「職場または学校にアクセスする」を開きます
アカウントをクリックして「情報」をクリック。
画面の下にずっと行くと「レポートの作成」という項目があるのでクリック。
このレポートはCドライブ直下にあるユーザー→パブリックのドキュメントフォルダに
格納されます。
このレポートを開くと、適用されているポリシー一覧が見ることができます。



ユーザーのポリシーを検索、こちらも確認することができました。

２回目：「ユーザーフレンドリ名」を割り当てた場合

1回目と同じく、ネットワーク接続はしている状態でキーボードレイアウトまで設定をしていきます。





２つめのキーボードレイアウト画面になったらWindowsキーを5回押します。



変わらず、事前プロビジョニング画面になりました。
「Windows Autopilotのプロビジョニング」をクリックして「続行」します。



2回目も同様にロードが少しはいり、構成画面が表示。
「割り当てられたユーザー」に設定したユーザーが入っていました！



２回目もVMでキッティングした時と同様にESP画面が表示され、
デバイスの準備、デバイスのセットアップと順々に完了していきました。



２回目は、「割り当てられたユーザー」にユーザーが設定されているため、
ユーザーグループに割り当てたアプリやポリシーの確認もしていきます。

アプリの確認

一回目と同様、デバイスグループに割り当てたfirefoxがインストールされているか確認。

コマンドプロントをshift＋F10で出し、コマンドでコントロールパネルを出します。
プログラム→プログラムと機能から「firefox」があること、「sakura」が無いことを確認。



Intune側で指定したファイルパス、Cドライブ「Program Files」にfirefoxがいるか確認をします。



ユーザーグループに割り当てたアプリのサクラエディタ(Autopilot User test Sakura)のファイルは事前プロビジョニングの段階では生成されていませんでした。
やはり、ユーザーグループに割り当てたアプリはインストールされない様です。



１回目同様、イベントビューアーでログ確認をしていきます。
クリックして使えるかどうか確認、ブラウザ確認ができました。



firefoxはすぐ確認できたため、サクラエディタがインストールされているかを確認。
sakuraで検索しましたがみつかりませんでした。念のため目視でもさかのぼって
確認みましたが、インストールログは無し。

ファイル形式がexeのインストーラーだからなのか、自分のPCにもインストール
してみたところ同じくログは確認できませんでした。
とりあえずfirefoxのログ確認ができたので、ポリシー確認に移動します。

ポリシーの確認

１回目と同様、デバイスグループに割り当てた構成プロファイルが割り当たっているかの確認をします。
すぐに確認ができたので、つづいてユーザーポリシーであるWindowsエラー報告を
「ErrorReport」で検索。
こちらも割り当てたログはありませんでした。
念のため目視でも探しましたが、確認できませんでした。



１回目と同様に、デバイスポリシーに設定した配信の最適化として、”絶対帯域幅”に設定した値が割り当たっていることも確認。



Autopilotでのユーザー割り当ての意味はないのかもしれない、と「再シール」をクリック。
シャットダウン後に電源を入れて、ユーザーにPCが渡った想定でキッティングしていきます。
電源を入れるとすぐにキーボードレイアウト選択画面に。これも１回目と変わらず。



設定したユーザーフレンドリ名が表示され、メールアドレスではなくパスワード入力画面に！



すぐにESP画面に切り替わり「アカウントのセットアップ」も数秒で完了に。
１回目と同様にサクサク進んでいきます。





残りの流れは１回目と同じだったので、省略します。
２回目のユーザー割り当ても１回目と同じ10分かからないくらいで終わりました。

アカウント名の確認

ユーザーフレンドリ名を指定したので、アカウント名には影響があるのか確認をします。
残念なことに、フレンドリ名に指定した「TEST」ではなく、Azure ADのアカウント名でした。



念のためメールアカウントも確認。
こちらも変わりなしでした。



気を取り直して、ユーザーグループに割り当てた設定を確認していきます。
アカウントのセットアップでサクラエディタのインストールとユーザーポリシーのWindowsエラー報告が無効になっているはず。

アプリの確認

再度コントロールパネルからプログラムと機能を開きます。
今度もサクラエディタがインストールされていることを確認できました。



スタートボタンで検索をかけ、テキストドキュメントとして使えることも確認。
念のためイベントビューアーでログを確認しましたが、ログは見つかりませんでした。

ポリシーの確認

イベントビューアーを開き、「アプリケーションとサービスのログ」を選択。
Microsoft→Windows→"DeviceManagement-Enterprise-Diagnostics-Provider"を開き、「Admin」の中からログを探します。
「ErrorReport」で検索すると、２回目もログが見つかりました。



２回目も「職場または学校にアクセスする」から診断レポートをエクスポートして、ポリシーを確認していきます。
デバイスポリシーとユーザーポリシーを検索、あることが確認できました。

結果

デバイスに割り当てたFireFoxは事前プロビジョニングでインストールが行われていましたが、
ユーザーに割り当てたサクラエディタは事前プロビジョニングではインストールが行われませんでした。

事前プロビジョニングではユーザーに割り当てた設定は反映されないことが確認できました。

まとめ

今回やってみてわかったことは、エンドユーザーのセルフキッティング時間が短縮され、IT管理者側の作業も手動操作は数回のため、どちらに対しても負担はぐっと減るということです。
ただ、デバイスベンダーからそのままユーザーに届ける、といういわゆるIT管理者がPCにほぼノータッチ・ゼロタッチキッティングというAutopilotだからできるメリットが事前プロビジョニングだとなくなります。

アプリ配信とポリシーの適用タイミングについて併せて確認をしてきましたが、ESP画面で「デバイスのセットアップ」まで完了したらfirefoxも使えるし、設定画面で配信の最適化もされていること。
ユーザー認証後にユーザーに割り当てたサクラエディタのインストールとWindowsエラー報告の無効化が適用されることが確認できました。
デバイスにはデバイス用の、ユーザーにはユーザー用の、当たり前だけど正確に配信されていることがすごいなぁと思いました。

ユーザーフレンドリ名については、現状ほんのちょぴっと入力が楽になるくらいの設定でしたが、もしかしたら他になにか確認できることがあるかもしれません。これは個別で調べてみようと思います。

最後までお読みいただき、ありがとうございました。
次回は、WIndows11 PCを使用した場合の事前プロビジョニングについてお話しいたします。

※このブログで参照されている、Microsoft、Windows、Microsoft Azure、その他のマイクロソフト製品および
　サービスは、米国およびその他の国におけるマイクロソフトの商標または登録商標です。

本AutoPilotに関するブログはシリーズ化しております。
Windows Autopilot を使ってみた 1　ーセルフキッティング編ー
Windows Autopilot を使ってみた 2　ーAutopilot用のプロファイル作成・設定確認編ー
Windows Autopilot を使ってみた 3　ーアプリ配信編ー
Windows Autopilot を使ってみた 5　ーWindows11 PC 事前プロビジョニング編ー
Windows Autopilot を使ってみた 6　ーフィルターを使ったAutopilotプロファイルの確認ー
Windows Autopilot を使ってみた 7　ー既存PCのAutopilot登録・キッティング編ー