Microsoft Intuneでフロントライン端末をゼロタッチで交換・再プロビジョニングするには、初回登録の自動化だけでは不十分です。交換端末の電源を入れてから、ネットワーク接続、自動登録、ポリシー適用、証明書配布、業務アプリの起動、ユーザー認証までを、一つの復旧経路として設計する必要があります。
特に、店舗、工場、倉庫、医療・介護、運輸などの現場では、端末の故障や紛失がシフト中に発生します。現地にIT担当者がいない状況でも、予備端末へ交換するだけで業務へ戻れる状態が理想です。
Microsoftが示すフロントライン端末の登録設計でも、端末を誰がどのように使うかだけでなく、障害時の復旧、再割り当て、現場の操作負担まで含めて登録方式を選ぶことが重要になります。(TECHCOMMUNITY.MICROSOFT.COM)
この記事では、Microsoft Intuneのフロントライン端末をゼロタッチ交換できるようにするための、利用モデルの選び方、ネットワークと証明書の配布順序、プラットフォーム別の構成、ワイプ後の復旧フロー、本番前のテスト項目まで具体的に解説します。
Microsoft Intuneのゼロタッチ交換は「登録」ではなく「復旧経路」の設計
ここでいうゼロタッチとは、IT担当者が端末を1台ずつ開封し、手作業でアプリや設定を投入しなくても、用意された端末が自動的に組織の管理下へ入り、業務に必要な状態へ収束することです。
プラットフォームや登録方式によっては、利用者による次のような操作が残ります。
- 電源を入れる
- 言語や地域を選ぶ
- 初期接続用Wi-Fiを選ぶ
- Microsoft Entra IDでサインインする
- 登録用QRコードを読み取る
- Microsoft Authenticatorを一度開く
したがって、ゼロタッチを「利用者が一切触らないこと」と定義すると、現場では実現しにくくなります。IT部門による個別設定を不要にし、現場作業を数個の定型操作に限定することを目標にするのが現実的です。
| 観点 | 初回登録だけの設計 | 交換・再プロビジョニングまで含む設計 |
|---|---|---|
| 端末登録 | 新品がIntuneに登録できる | 新品、ワイプ済み端末、修理返却端末が同じ経路で登録できる |
| ネットワーク | 社内Wi-Fi接続後を想定 | 証明書がない状態でも接続できる初期ネットワークを用意する |
| ポリシー | 登録後に順次配布する | 業務開始前に必要なものと、後から配布するものを分ける |
| 証明書 | 既存端末への配布だけを確認する | 信頼済みルート、端末証明書、Wi-Fiの配布順序を確認する |
| ユーザー認証 | 通常のサインインだけを確認する | 認証端末の紛失やMFA再登録まで想定する |
| 再割り当て | 管理者が都度初期化する | 標準のワイプ・リセット手順で次の利用者へ渡せる |
| 現場支援 | IT担当者への問い合わせを前提にする | 予備端末と短い手順書だけで交換できる |
最終的な成功条件は「Intuneに登録済みと表示されたこと」ではありません。交換開始から、実際の業務処理が1件成功するまでを復旧時間として計測することが重要です。
最初にフロントライン端末の利用モデルを決める
登録方式を選ぶ前に、端末と利用者の関係を整理します。同じスマートフォンやタブレットでも、「1人1台」と「シフト共有」では適切な登録方式が異なります。
| 利用モデル | 想定例 | 主な登録方式 | 設計上の重点 |
|---|---|---|---|
| 1人1台の割り当て端末 | 店長、現場責任者、配送員 | Windows Autopilotユーザー主導、Android Enterpriseフルマネージド、Apple ADEのユーザーアフィニティあり | ユーザー認証、MFA復旧、個人データの消去 |
| シフト共有端末 | 倉庫ハンディ、病棟端末、店舗タブレット | Android Enterprise専用端末とMicrosoft Entra Shared Device Mode、iOS/iPadOSのADEとShared Device Mode | サインアウト時のデータ消去、対応アプリの確認 |
| キオスク・専用端末 | POS補助、受付、在庫照会、デジタルサイネージ | Android Enterprise専用端末、Windows Autopilot自己展開モード、Apple ADEのユーザーアフィニティなし | 端末単位の認証、アプリ固定、無人復旧 |
| BYOD | 個人スマートフォンでの業務利用 | Android仕事用プロファイル、アプリ保護ポリシーなど | 会社所有端末とは別の運用として設計する |
Windows Autopilotのユーザー主導モードは主に1人の利用者へ割り当てる端末に向き、自己展開モードはユーザーを割り当てない共有端末やキオスクに向きます。Android Enterprise専用端末は、ユーザーに関連付けない単一用途端末として登録でき、Microsoft Entra Shared Device Modeを組み合わせることも可能です。Appleでは、Apple Business ManagerとAutomated Device Enrollmentを使って共有端末を自動登録できます。(Microsoft Learn)
Shared Device Modeを使う前に業務アプリを確認する
Microsoft Entra Shared Device Modeでは、対応アプリの一つでサインインすると、ほかの対応アプリでもシングルサインオンを利用できます。シフト終了時には、対応アプリからまとめてサインアウトできます。
ただし、Shared Device Modeに対応していないアプリには、シングルサインオンや一括サインアウトが適用されません。端末を共有できるかどうかは、OSやIntuneの設定だけではなく、実際に利用する業務アプリの実装に左右されます。(Microsoft Learn)
導入前に、すべての業務アプリについて次を確認してください。
- Shared Device Modeに対応しているか
- サインアウト後にキャッシュや一時ファイルが残らないか
- 前の利用者の氏名、履歴、添付ファイルが表示されないか
- WebViewや外部ブラウザのセッションも終了するか
- オフラインデータが利用者間で引き継がれないか
なお、Microsoft Entra Shared Device ModeとAppleのShared iPadは別の仕組みです。Shared Device Modeは対応アプリ間のサインインとサインアウトを連携する仕組みで、Shared iPadはManaged Apple IDや一時セッションを使うAppleのマルチユーザー機能です。目的と利用アプリに応じて選び分けます。(Microsoft Learn)
ゼロタッチ再プロビジョニングを成立させる7つの設計
調達時点で自動登録の台帳へ載せる
ゼロタッチ交換の成否は、Intuneの設定を始める前の調達段階で決まります。
主な仕組みは次のとおりです。
- Apple：Apple Business ManagerからIntuneのADEトークンへ端末を割り当てる
- Android：Google zero-touch enrollmentまたはKnox Mobile Enrollmentへ登録する
- Windows：Windows Autopilotへ端末を登録する
交換用の予備端末も、本番端末と同じ自動登録経路へあらかじめ登録しておきます。故障後にシリアル番号やハードウェア情報を登録する運用では、現場交換のたびにIT部門の作業が発生してしまいます。
Apple端末は、Intuneからワイプする方法、またはIntuneで廃止した後に工場出荷状態へ戻す方法で再登録できます。再起動後にSetup Assistantを進めると、割り当てられたリモート管理プロファイルを再取得します。(Microsoft Learn)
上流の自動登録台帳から端末を外す操作は、原則として廃棄や売却時に限定します。修理、再割り当て、予備機への戻しでは、組織への割り当てを維持してください。
初回起動専用のブートストラップネットワークを用意する
未登録端末がIntuneから社内Wi-Fi設定や証明書を受け取るには、その前にインターネットへ到達できなければなりません。
証明書認証の社内Wi-Fiだけを用意すると、次の循環が発生します。
- 社内Wi-Fiへ接続するには端末証明書が必要
- 端末証明書を受け取るにはIntuneへの接続が必要
- Intuneへ接続するにはWi-Fiが必要
この問題を避けるため、初期登録専用のブートストラップ経路を用意します。
候補は次のとおりです。
- インターネット接続だけを許可した初期登録用SSID
- 有線LAN接続
- モバイル回線またはeSIM
- 管理されたモバイルルーター
- 拠点担当者だけが知る一時的なPSK方式のWi-Fi
初期登録用ネットワークでは、ファイアウォール、VPN、プロキシを通して、Intuneが必要とするFQDN、IP範囲、ポートへ接続できるようにします。(Microsoft Learn)
キャプティブポータル、Web認証、TLSインスペクション、認証プロキシは、OOBEやSetup Assistantで正しく動作しない場合があります。設計資料上の許可だけで判断せず、製品版と同じ端末、OS、拠点ネットワークで登録テストを行ってください。
登録直後のグループ所属を確定させる
ゼロタッチ登録に成功しても、端末が動的グループへ追加されるまで待たされると、アプリやポリシーがすぐに届きません。
利用可能な登録方式では、IntuneのEnrollment Time Groupingを使い、登録中に静的なMicrosoft Entraデバイスグループへ参加させます。Microsoftによると、この設定を使わず、インベントリ情報や動的グループ判定に依存した場合、すべてのアプリやポリシーが届くまで最大8時間かかる可能性があります。Enrollment Time Groupingは新規登録に対して動作し、既に登録済みの端末には遡って適用されません。(Microsoft Learn)
次のように、登録プロファイル、グループ、フィルターの対応関係を明確にします。
登録プロファイル：FL-ANDROID-SHARED-01
登録時グループ：GRP-ETG-FL-ANDROID-SHARED
割り当てフィルター：FLT-ENROLLMENTPROFILE-FL-ANDROID-SHARED
端末名規則：TOK-ST01-シリアル番号AppleやAndroidでは、enrollmentProfileNameを使った割り当てフィルターも有効です。特定の登録プロファイルを通過した端末だけに、Shared Device Mode、キオスク、証明書、Wi-Fiなどの設定を絞り込めます。AppleのShared Device Mode構成でも、登録プロファイル名を使った動的グループと割り当てフィルターが案内されています。(Microsoft Learn)
業務開始前に必要な「最小構成」を定義する
すべてのアプリや設定が届くまで端末をロックすると、重要度の低いアプリが1つ失敗しただけで、現場が業務を開始できなくなります。
設定項目を次の2種類に分けます。
| 区分 | 代表例 |
|---|---|
| 業務開始前に必須 | 管理プロファイル、セキュリティ基準、Microsoft Authenticator、キオスクまたはランチャー、主要業務アプリ、信頼済みルート証明書、Wi-Fi・VPN設定 |
| 業務開始後でもよい | マニュアル、補助アプリ、利用頻度の低いツール、追加ブックマーク、壁紙、任意アプリ |
Windowsの従来型Windows Autopilotでは、Enrollment Status Pageを使い、必要なポリシーやアプリがインストールされるまで端末利用をブロックできます。エラー時の連絡先、タイムアウト、診断画面も設定できます。(Microsoft Learn)
一方、Windows Autopilot device preparationはEnrollment Status Pageを使用しません。device preparationポリシーで選択したアプリやPowerShellスクリプトの展開状況を、専用のレポートで確認します。両者を同じ仕組みとして設計しないよう注意してください。(Microsoft Learn)
Apple ADEの「Await final configuration」を有効にすると、Setup Assistantの終了前に重要なデバイス構成ポリシーの適用を待たせられます。ただし、この待機対象にアプリは含まれません。ホーム画面が表示された時点で業務アプリが利用可能とは限らないため、アプリ起動確認を別に設ける必要があります。(Microsoft Learn)
Android Enterprise専用端末では、割り当て方法が「必須」のアプリだけをインストールできます。業務アプリ、Microsoft Authenticator、ランチャーなどの割り当て漏れがないか確認してください。(Microsoft Learn)
証明書の配布順序を固定する
Intuneでは、証明書を使ってWi-Fi、VPN、メール、業務リソースへの認証を行えます。(Microsoft Learn)
証明書認証を利用する場合は、次の順序で配布します。
| 段階 | 端末の状態 | 配布・確認するもの |
|---|---|---|
| 0 | 未登録 | ブートストラップネットワークへ接続 |
| 1 | 登録中 | Intune登録、端末管理プロファイル |
| 2 | 管理開始 | 信頼済みルートCA証明書 |
| 3 | 証明書要求 | SCEPまたはPKCS証明書 |
| 4 | 本番接続 | 証明書認証の社内Wi-Fi、VPN |
| 5 | 業務準備完了 | 本番ネットワークでの業務アプリ疎通 |
| 6 | 初期経路終了 | 必要に応じてブートストラップSSIDを削除または利用制限 |
共有端末やユーザーがサインインする前に接続する端末では、一般に端末証明書とデバイス認証を中心に設計します。1人1台端末で、アクセス権を個人単位に制御したい場合は、ユーザー証明書も選択肢になります。実際の方式は、RADIUS、NAC、VPN、対象OSの対応状況と合わせて決めてください。
オンプレミスのActive Directory Certificate ServicesとSCEPを組み合わせる場合は、Certificate Connector for Microsoft Intuneが必要です。信頼済みルート証明書を先に配布し、SCEPプロファイルから参照させます。Microsoft Cloud PKIを利用すれば、オンプレミスのAD CSやNDES、証明書コネクターを使わない構成も可能ですが、利用条件やライセンスを事前に確認してください。(Microsoft Learn)
証明書基盤は、初回配布だけでなく次も監視対象にします。
- 証明書の有効期限と更新状況
- 失効処理の動作
- SCEPまたはPKCSの発行失敗
- 証明書コネクターの停止
- CA証明書の更新
- 古い証明書が端末に残っていないか
- ワイプ後に同じ証明書主体名が重複しないか
認証手段を失った利用者の復旧経路を作る
交換端末が正常でも、故障した旧端末がMicrosoft Authenticatorとして使われていた場合、利用者がMFAを通過できず、業務へ戻れないことがあります。
端末交換の手順には、次の認証復旧を含めます。
- 本人確認を行う窓口
- 古い認証方法を無効化する基準
- Microsoft Authenticatorの再登録
- FIDO2セキュリティキーなどの代替手段
- Temporary Access Passの発行権限と手順
- 夜間や休日に認証管理者が不在の場合の対応
Temporary Access Passは、有効時間を限定した一時コードとして発行でき、認証方法を紛失した利用者の復旧や、パスワードレス認証の登録に利用できます。単回利用または複数回利用を設定できますが、発行者の権限、本人確認、伝達方法、利用後の削除まで手順化してください。(Microsoft Learn)
現場では「設定」ではなく「交換」だけを行わせる
現場担当者へIntuneの操作や管理者資格情報を渡すのではなく、予備端末への交換だけを依頼できる形にします。
現場向け手順書は、次の程度に絞ります。
- 故障端末の資産番号を記録する
- 予備端末を充電器から外す
- 電源を入れる
- 指定された初期接続用Wi-Fiを選ぶ
- 画面の指示に従ってサインインする
- 業務アプリを開いて確認処理を行う
- 故障端末を回収袋または保管庫へ入れる
- 交換完了を連絡する
端末本体や保管箱には、次の情報を表示すると問い合わせを減らせます。
- 資産番号
- 利用拠点
- 交換手順へのQRコード
- 問い合わせ先
- エラー報告時に伝える項目
- 故障端末の返送先
予備台数は一律の割合ではなく、拠点の重要度、修理日数、同時故障数、営業時間から決めます。最低限、次の考え方で見積もると実務的です。
最低予備台数
＝ 想定する同時故障台数
＋ 修理中となる最大台数
＋ 登録・検証用端末プラットフォーム別の推奨再プロビジョニング構成
Android Enterpriseの共有端末
倉庫、店舗、製造現場などで複数の従業員が交代利用する場合は、Android Enterprise専用端末とMicrosoft Entra Shared Device Modeの組み合わせが有力です。
推奨フローは次のとおりです。
- 対応端末をGoogle zero-touch enrollmentまたはKnox Mobile Enrollmentへ登録する
- IntuneでShared Device Mode用の専用端末登録プロファイルを作る
- 登録時グループを指定する
- Managed Google Playから業務アプリを「必須」で割り当てる
- Microsoft AuthenticatorとIntuneアプリを自動展開する
- キオスクまたはManaged Home Screenを構成する
- 端末証明書、Wi-Fi、VPNを配布する
- 利用者のサインインとグローバルサインアウトを確認する
Android Enterpriseでは、Google zero-touch、Knox Mobile Enrollment、QRコード、NFC、トークン入力など複数の登録手段を選択できます。QRコードは現場での読み取りが必要ですが、自動登録サービスに未対応の端末を復旧するための予備経路として利用できます。(Microsoft Learn)
Androidの初期化方法を統一する
Androidでは、Intuneからのワイプ、設定画面からの初期化、リカバリーやブートローダーからの初期化で、Factory Reset Protectionの動作が異なる場合があります。
特に、Android 15を搭載した会社所有の仕事用プロファイル端末では、設定画面からリセットした後に、構成へ関連付けられたGoogleアカウントを求められる場合があります。現場担当者が独自に初期化しないよう、再プロビジョニング時に使用するリセット経路を1つに決めることが重要です。(Microsoft Learn)
iPhone・iPadの共有端末
Apple端末では、Apple Business ManagerとIntuneのAutomated Device Enrollmentを連携させます。
Microsoft Entra Shared Device Modeを利用する場合の基本構成は次のとおりです。
- ADE登録プロファイルでMicrosoft Entra ID shared modeを選ぶ
- Locked enrollmentを有効にする
- Setup Assistantの不要な画面を非表示にする
enrollmentProfileNameで対象端末を絞り込む- Microsoft Enterprise SSOプラグインを構成する
- VPP版Microsoft Authenticatorを必須配布する
- 必要に応じてAwait final configurationを有効にする
端末を受け取った利用者には、Microsoft Authenticatorを一度開き、Shared Device Modeになっていることを確認してもらいます。(Microsoft Learn)
再利用する場合は、Intuneからワイプするか、Intuneで廃止した後に工場出荷状態へ戻します。その後、Setup Assistantを進めれば、ADEに割り当てられた管理プロファイルを再取得できます。(Microsoft Learn)
Windowsの共有PC・キオスク端末
1人1台のWindows PCでは、Windows Autopilotのユーザー主導モードまたはWindows Autopilot device preparationを検討します。
共有PCやキオスクでは、Windows Autopilot自己展開モードが候補です。自己展開モードはMicrosoft Entra参加のみをサポートし、ユーザーを割り当てない端末向けです。また、TPMアテステーションに対応した端末が必要です。(Microsoft Learn)
安定して動作しているMicrosoft Entra参加済み端末を別の利用者へ渡す場合は、Windows Autopilot Resetを利用できます。Autopilot Resetでは、個人ファイル、アプリ、設定を削除しながら、Microsoft Entra IDへの参加情報とIntuneの管理接続を維持できます。Wi-Fi情報やSCEP証明書も保持対象です。(Microsoft Learn)
ただし、Windows Autopilot Reset後は、必須アプリがEnrollment Status Pageで追跡されず、デスクトップ表示後にインストールされる既知の動作があります。そのため、デスクトップが表示されたことだけで交換完了とせず、主要アプリのインストールと起動を確認してください。(Microsoft Learn)
OSが破損している場合や、ストレージ交換後に再インストールが必要な場合は、Autopilot Resetではなく、Windows Autopilot for existing devicesやOS再展開を含む別の復旧経路を用意します。
交換・ワイプ・修理・再割り当ての標準フロー
端末交換では、予備機の払い出しと旧端末の処理を別々に管理します。旧端末の修理を待ってから交換すると、業務停止時間が長くなるためです。
| 段階 | 実施内容 | 完了条件 |
|---|---|---|
| 障害受付 | 利用者、資産番号、症状、紛失有無を記録 | 交換対象とセキュリティ対応の要否が決まる |
| アクセス保護 | 必要に応じてセッション、認証方法、端末アクセスを制御 | 旧端末からの不正利用を抑止できる |
| 予備機払い出し | 同じ用途の登録プロファイルへ割り当て済みの端末を渡す | 電源、SIM、バッテリー、付属品が揃っている |
| 初期接続 | ブートストラップネットワークへ接続 | Intuneと各プラットフォームの登録サービスへ到達できる |
| 自動登録 | ADE、zero-touch、KME、Autopilotなどを実行 | Intuneに正しい所有区分とプロファイルで表示される |
| 構成適用 | ポリシー、アプリ、証明書、Wi-Fiを受信 | 必須構成が成功している |
| 業務確認 | サインイン、アプリ起動、実データ処理を行う | 業務トランザクションが1件成功する |
| 旧端末処理 | ワイプ、修理、廃棄のいずれかへ振り分ける | 前利用者のデータが残らない |
| 在庫復帰 | 修理端末を再プロビジョニングして予備機へ戻す | 同じ交換テストに合格する |
紛失端末では、ワイプ命令の送信だけをセキュリティ対応の完了条件にしないでください。端末が通信できない状況も想定し、ユーザーセッション、認証方法、証明書、業務システム側のアクセスを含めて判断します。
再プロビジョニングで失敗しやすいポイント
| 失敗例 | 起きる問題 | 対策 |
|---|---|---|
| 初回登録だけをテストしている | ワイプ後や修理後にプロファイルが再取得されない | 新品、ワイプ、修理返却の3経路を試す |
| 社内Wi-Fiが証明書認証だけ | 未登録端末がIntuneへ接続できない | 初期登録用ネットワークを用意する |
| 動的グループだけに依存する | アプリやポリシーの配布開始が遅れる | Enrollment Time Groupingや割り当てフィルターを使う |
| すべてのアプリをブロッカーにする | 補助アプリの失敗で端末全体が利用できない | 業務開始に必要なアプリだけを指定する |
| Shared Device Mode非対応アプリを使う | 一括サインアウトしてもセッションが残る | 全業務アプリで利用者切り替え試験を行う |
| AppleのAwait final configurationを過信する | ホーム画面表示後もアプリが未導入 | 業務アプリの起動確認を別に行う |
| Windows Autopilot Reset完了を即利用可能と判断する | 必須アプリのインストール前に利用を始める | デスクトップ表示後のアプリ確認を行う |
| Androidを任意の方法で初期化する | Factory Reset Protectionで再登録できない | Intuneワイプなど承認済みの経路へ統一する |
| 証明書基盤を単一障害点にする | 新規端末だけ社内Wi-Fiへ接続できない | コネクター、CA、証明書発行を監視する |
| MFA復旧を用意していない | 予備端末は正常でも利用者がサインインできない | Temporary Access Passなどの復旧手順を用意する |
| 予備機を未登録のまま保管する | 交換時にIT部門の登録作業が必要になる | 本番と同じ自動登録台帳へ事前登録する |
| 予備機の充電やSIMを確認していない | 設計は正しくても現場で起動できない | 定期的な在庫点検を行う |
本番前に行う再プロビジョニング試験
本番導入前には、正常系だけでなく、端末が業務へ戻れない条件を意図的に作って確認します。
| テストシナリオ | 確認する内容 |
|---|---|
| 新品の予備端末を開封する | 自動登録サービスから正しいプロファイルを取得できるか |
| 使用中端末をIntuneからワイプする | 同じ登録プロファイルで再登録できるか |
| 修理返却端末を再利用する | シリアル番号やハードウェア情報の変更に対応できるか |
| 初期登録用Wi-Fiを停止する | 有線、モバイル回線などの代替経路が使えるか |
| 証明書発行を停止する | どの画面で止まり、現場が何を報告すべきか |
| 業務アプリの配布を失敗させる | タイムアウト、再試行、問い合わせ先が表示されるか |
| 旧認証端末を紛失した状態にする | MFAやAuthenticatorを復旧できるか |
| 共有端末で利用者を交代する | 前利用者のデータやセッションが残らないか |
| Androidを承認済み経路で初期化する | Factory Reset Protectionに阻害されないか |
| Windows Autopilot Resetを実行する | デスクトップ表示後に必須アプリが導入されるか |
各テストでは、次の状態をすべて満たした時点を「業務準備完了」とします。
- Intuneへ正しい登録方式で登録されている
- 想定したグループとフィルターが適用されている
- 管理対象、会社所有、コンプライアンス状態が正しい
- 信頼済みルート証明書と端末証明書が配布されている
- 本番Wi-FiまたはVPNへ接続できる
- 必須アプリがインストールされ、起動できる
- 利用者が認証できる
- 前利用者の情報が残っていない
- 実際の業務処理を完了できる
- エラー時の問い合わせ先を端末上で確認できる
復旧時間の目標値は、「ホーム画面が表示されるまで」ではなく、交換開始から業務処理が成功するまでで設定します。拠点、回線速度、利用アプリ数ごとに実測し、遅延の大半が登録、グループ判定、アプリ配布、証明書発行、ユーザー認証のどこで発生しているかを記録してください。
シフト中に交換できるIntune端末へ移行する手順
最初から全端末を作り直す必要はありません。故障時の影響が大きく、利用方法が単純な1つの業務から始めると進めやすくなります。
まず、対象端末を「1人1台」「シフト共有」「キオスク」のいずれかに分類します。次に、Apple ADE、Android zero-touchまたはKME、Windows Autopilotなどの自動登録経路へ予備機を含めて登録します。
そのうえで、初期接続用ネットワーク、登録時グループ、必須アプリ、証明書、社内Wi-Fi、認証復旧、現場手順書を一つの設計としてつなげます。
最後に、新品端末の登録だけでなく、ワイプ後、修理返却後、認証手段紛失時の試験を行います。端末を消してから業務へ戻るまでの手順を繰り返し成功させられれば、Microsoft Intuneによるフロントライン端末のゼロタッチ交換と再プロビジョニングは、実運用に耐えられる状態です。
コメント