本記事は大半を 7月～8月に作成しました。
(内容が古い場合は、見つけ次第、後日更新します。)
Intune 担当同志のみなさま、今日もポリシー設計お疲れ様です。
Intune の設計要素には、テナント構成や管理含め様々な観点・項目がありますが、その中でも、ポリシー設計はあらゆるフェーズの Intune プロジェクトでまんべんなく対応が必要になる要素ですよね。
| # | プロジェクト フェーズ例 | ポリシー検討観点例 |
|---|---|---|
| 1 | Intune 新規導入 | Intune の導入を契機に、新規採択 または これまでお客様の既存システムで実装してきた端末制御を再現する方向で実装方法の検討が必要になります。 |
| 2 | Windows Autopilot 導入 | Autopilot の導入を契機に、これまでイメージクローニング や バッチ処理など、キッティング工程にて実施してきた設定を自動化する方向で実装方法の検討が必要になります。 |
| 3 | デバイス管理エコシステム見直し | MDM 移行・統合や、Entra hybrid join から Entra join への移行 (GPO 離脱)、共同管理卒業などを契機に、既存システムで実装してきた端末制御を再現する方向で実装方法の検討が必要になります。 |
特に Windows はお客様にて管理されてきた歴史が長いことが多く、既存システム上の設定の再現検討という観点でのポリシー設計もよく発生します。
本記事では、お客様の Windows デバイス ポリシー要件を Intune 上に実装するにあたり、どの機能を使うか方針を検討する過程を一例としてまとめます！
具体的なポリシー再現方法を例示しつつ、細かく複雑なポリシー再現の実態を少しでも表現できれば... と思いながら書きました。
長めの記事になってしまいました。飛ばし読み推奨です。
Intune 実装方法 - 検討フロー
よくプロジェクトでは、概ね以下のフローで実装方法を検討しています：
新規に端末制御を実装する場合
新規の場合も、GPO 条件分岐をスキップして同様のフローで検討しています。
| # | 検討プロセス | 補足 | ゴール |
|---|---|---|---|
| 1 | 対象の棚卸し | Intune 環境にてデバイス上に実装したい制御と、実装不要な制御を仕分けします。 | この段階では未定 |
| 2 | GPOか？ | 既存設定再現が必要かつ、その既存設定が GPO の場合はまずグループポリシー分析を利用します。GPO でない場合は、「5-1. 構成プロファイル」「5-2. レジストリ」「5-3. コマンド・スクリプト」「6. その他」のいずれかに振り分けられるよう調査検証します。 | この段階では未定 |
| 3 | GP Analytics | GPO を XML ファイルとしてエクスポートし、グループポリシー分析を実行します。 | この段階では未定 |
| 4 | 「移行」可能か？ | グループポリシー分析実行の結果、「移行」が可能と診断された項目については設定カタログに「移行」します。「移行」不可と診断された項目については、「5-1. 構成プロファイル」「5-2. レジストリ」「5-3. コマンド・スクリプト」「6. その他」のいずれかに振り分けられるよう調査検証します。 | 構成プロファイル (設定カタログ) |
| 5-1 | 構成プロファイルがあるか？ | 調査検証し、該当項目が構成プロファイルに存在する場合は構成プロファイルとして実装します。構成プロファイルに存在しない場合は、レジストリやコマンドが特定可能かという視点で引き続き調査検証を実施します。 | 構成プロファイル |
| 5-2 | レジストリか？ | 既存システムにてレジストリ展開で対応されている項目や、構成プロファイル特定が困難でレジストリ実装の方が容易な項目は、レジストリ実装を検討します。ただし、将来的運用負荷を考慮して他機能実装検討を先に実施し、レジストリ実装確定は後の工程にまわします。 | この段階では未定 |
| 5-2-1 | 製品設定か？ | レジストリ実装検討対象のうち、Microsoft Edge や旧 Office、Google Chrome をはじめとした 3rd party 製品などソフトウェアに対する制御は、「5-2-1-1. 設定カタログ」「5-2-1-2. ADMX」「5-2-1-3. Office」に振り分けられることがあります。 | この段階では未定 |
| 5-2-1-1 | 設定カタログ | Microsoft Edge や Google Chrome など、一部の製品は構成プロファイルの設定カタログにて構成がサポートされています。設定カタログの一覧を検索し、該当項目が存在する場合は構成プロファイルとして実装します。 | 構成プロファイル (設定カタログ) |
| 5-2-1-2 | ADMX | 設定カタログでサポートされていない製品や設定項目について、ADMX backed policy の場合は ADMX テンプレートをインポートして構成プロファイルを作成することができます。検証し意図した状態になる場合は、当方法で構成プロファイルとして実装します。 | 構成プロファイル |
| 5-2-1-3 | Office | 旧Office に対する制御を、今後は Microsoft 365 Apps for enterprise に対する制御として再現実装したい場合、クラウドポリシーとして実装します。 | クラウドポリシー |
| 5-2-2 | HKLM か？ | レジストリ以外の方法で実装目途が付かないものは、HKLM キーのものは求める最終動作に応じてスクリプトまたはアプリとして実装します。 | スクリプト または アプリ |
| 5-3 | コマンド、スクリプトがあるか？ | コマンドやスクリプトがあるものは、求める最終動作に応じてスクリプトまたはアプリとして実装します。 | スクリプト または アプリ |
| 6 | その他 | これまでの工程でキャッチできなかったものは、個別に検討を実施します。例えば、HKU キーや HKCU キーなど HKLM 以外のキーの場合は、ユーザー権限やプロビジョニングフローを鑑みて実装できる場合とできない場合があります。こうした実現可否についても最終判断を実施します。 | 個別に検討が必要 |
みなさんはどういったフローで検討されてますでしょうか。もしよければコメントで教えてください。
なお「フロー」と記載したものの、実際には上から下にウォーターフォール型に対応できるケースばかりではなく、むしろアジャイル チックに対応することが多いです。
また、「5-1. 構成プロファイル」「5-2. レジストリ」「5-3. コマンド・スクリプト」「6. その他」は並行して検討することが多いです。
これ以降のセクションにて、それぞれの工程についてもう少し詳しく記載します。
1. 対象の棚卸し
| これは必要な設定？ | Next Step |
|---|---|
| YES: 必要である | 「2. GPO か？」へ進み、対応を検討する |
| NO: 不要 | 再現不要な設定については対応不要 |
まずはじめに、Intune 実装検討対象の設定と、対象外の設定 (検討不要な設定) を仕分けします。
特にお客様環境で長く使われている設定の中には、新しいデバイス利用環境で引継ぎ不要な設定がまぎれていることが多いです。
- 現在では利用されていないソフトウェアの設定
- オンプレミス環境特有の製品の設定
- おまじない設定、etc...
個人的には、昨今セキュリティは多層防御が主流となっていると感じており、Windows OS レイヤーでガチガチにセキュリティを固めようとするアプローチよりも多層で防御を固めるアプローチの方が好きです。
(多層防御の方が昨今の製品デザイン的にも、ハイブリッドワーク時代の利用形態的にもに合うのではと思っています。)
既存の設定をすべて移行する必要があるのか？ (いやない) ―― Intune 設計を契機に改めて検討できるのが理想です。
... が、現実はなかなか理想通りにはいかないですね。
実際のプロジェクトでは、なかなか一発で棚卸しを完了することも難しく、何回かリレーしてリストをブラッシュアップしつつ、並行して実装方針検討を進めることが多いです。
2. GPO か？
| この設定は GPO がもとになっているのか？ | Next Step |
|---|---|
| YES: GPO がもとである | 「3. GP Analytics」へ進み、対応を検討する |
| NO: GPO ではない | 「5-1. 構成プロファイルがあるか？」「5-2. レジストリか？」「5-3. コマンド、スクリプトがあるか？」へ進み、対応を検討する |
Intune 実装検討の対象となる設定が、現行環境にて AD のグループポリシーとして実装されている場合、Intune のグループポリシー分析機能が利用可能です。
まずは個別に調査検証する設定項目の母数を減らすためにも、まずはグループポリシー分析を使うのが方針決定への早道です。
ただし、既存設定の実装方法が GPO でなかったり、GPO だが XML をベンダーに連携することができないというお客様もいらっしゃいます。
この場合は、設定項目毎に「構成プロファイルがあるか？」「レジストリか？」「コマンド、スクリプトがあるか？」に応じて実装方法を検討することになります。
3. GP Analytics (GPA)
| この場合に実施 | Next Step |
|---|---|
| 既存環境にて GPO で設定が実装されている場合、かつ XML 連携を受けられる場合 | 「4. 「移行」可能か？」へ進み、対応を検討する |
GPO を XML ファイルとしてエクスポートし、グループポリシー分析 を実施します。
グループポリシー分析では、大きく以下 2つの機能が提供されています：
- 診断：Intune 構成プロファイルの設定カタログで構成可能な設定については「移行可能」と診断する
- 移行：「移行可能」な設定項目を対象に、診断結果画面から「移行」ボタンをクリックし設定カタログを作成する
診断を実施し、結果に応じてワンタッチで実装 または さらなる検討へ進みます。
GPO 移行の現状と課題
AD も Intune も Microsoft 製品ですが、現状は横流しでの設定移行が困難であるという課題があります。
-
構成プロファイルと GPO の項目数乖離
従来から、Intune 構成プロファイルのテンプレートでサポートされる設定項目とグループポリシーでサポートされる設定項目には大きな乖離があり、後者の母数が圧倒的に大きく Intune にて再現できない設定があることが既知の課題でした。現在でもまだこれは継続して課題であるものの、Intune 開発チームが精力的に設定カタログに項目を追加しており、以前よりは比較的実装できる項目が増えてきています。
-
移行ツールの GA
グループポリシー分析 機能は長らくパブリックプレビュー扱いでしたが 2308 リリースで「移行」機能とともに GA されました。これにより、GPO の再現はここ数年でグッと現実的に対応できる範囲になってきたという印象です。
ただし、グループポリシー分析 がサポートするのは一部の CSP に限られるため、まだまだ すべての GPO を横流しで移行することはできません。
4. 「移行」可能か？
| この設定は「移行」可能か？ | Next Step |
|---|---|
| YES: 移行可能である | 構成プロファイルとして実装する |
| NO: 移行可能と表示されない | 「5-1. 構成プロファイルがあるか？」「5-2. レジストリか？」「5-3. コマンド、スクリプトがあるか？」へ進み、対応を検討する |
先述のように、グループポリシー分析 では設定カタログで構成可能な設定については「移行可能」と診断してくれます。
厳密には、現在 グループポリシー分析 では以下の CSPs がサポートされており、これら CSP の範囲内で設定カタログにて構成可能な項目が「移行可能」として診断されます。
(参考：Import and analyze your on-premises GPOs using Group Policy analytics in Microsoft Intune)
- Policy CSP
- PassportForWork CSP
- BitLocker CSP
- Firewall CSP
- AppLocker CSP
- Group Policy Preferences
グループポリシー分析がサポートする CSP について
パブリックプレビューの時からこの機能を 2, 3年ウォッチしていますが、サポート対象の CSP は増えていないです。
移行可能な場合、そのまま「移行」ボタンをクリックして構成プロファイル (設定カタログ) として実装が可能です。(詳細は公開情報ご参照)
移行可能と表示されない場合も、グループポリシー分析 がサポートしていない CSP にて実装が可能で合ったり、レジストリやコマンド/スクリプトとして実装できたりする場合があります。
設定項目毎に調査検証し、実装方法を検討することになります。
5-1. 構成プロファイルがあるか？
| この設定は構成プロファイル上に項目が存在するか？ | Next Step |
|---|---|
| YES: 構成プロファイルに存在する | 構成プロファイルとして実装する |
| NO: 構成プロファイルに見当たらない | 「5-2. レジストリか？」「5-3. コマンド、スクリプトがあるか？」観点でも並行して対応を検討する |
グループポリシー分析が使えない場合や、グループポリシー分析でサポートされる範囲外の設定である場合、本セクション以降で実装方法を検討します。
現場では、「構成プロファイルがあるか？」「レジストリか？」「コマンド、スクリプトがあるか？」という観点で並行して地道に調査検証を実施しています。
意外かもしれませんが、現状は地道な方法が王道で、それ以外に対応する方法は無いかと思います。
対応事例がある設定の場合は、事例を参考にして実装方式を提示することができます。
事例ベースの構成プロファイル設計における注意点
事例ベースの構成プロファイル設計は、2024年 7月現在すこし注意が必要です。
前々から予告されていた構成プロファイルの "unified settings platform" 移行に伴い、一部のプロファイル テンプレートが廃止・統合されることになりました。(対象は今後追加される可能性があります。)
- 廃止・統合されるテンプレートの例：
- ID保護 (Identity protection)：構成プロファイルテンプレートは廃止、エンドポイントセキュリティプロファイルに統合
- デバイス制限 (Device Restrictions)：構成プロファイルテンプレート廃止、当該項目は今後設定カタログにて実装可能
- 管理用テンプレート (Administrative Template)：同上
- カスタム (Custom OMA-URI)：設定カタログに存在する OMA-URI を使ったカスタムプロファイルの新規作成ブロック
廃止・統合予定のテンプレートは今後新規に作成できなくなるため、過去プロジェクトなどで実績があっても新プロジェクトでそのまま流用することができません。
初見の設定の場合は、ファーストアクションは Microsoft Intune サポートへの SR 起票 & 並行してインターネット検索になります。(ネットではおもに Microsoft MVP のブログを探します。)
最近は、設定カタログ一覧上のキーワード検索という手も増えました。これもなかなか使えます。
新規の構成プロファイル設計における希望
今後 Copilot を使うと、ポリシー・プロファイル設計が楽になる可能性があります。
Early Access Program 段階の Copilot は open prompt を受け付けており、ユース ケースとしてポリシーの drafting もありました。
ただし、どうやら open prompt だと hallucination リスクが高いそうで、パブリックプレビュー段階の現在は open prompt ではなく promptbook 形式で Copilot が提供されています。
なおユース ケースは、主に各プロファイル上の項目の詳細な説明や、既存ポリシーやデバイス情報の要約などです。
将来的には open prompt 形式にも対応する予定 (時期未定) らしく、そうなると Copilot を持つものと持たざる者でスタートダッシュに大きく差がつく可能性がありそうです。
5-2. レジストリか？
| この設定はレジストリが特定できるか？ | Next Step |
|---|---|
| YES: 対応するレジストリが分かる | 「5-2-1. 製品設定か？」に進み、レジストリそのものとして以外の方法で実装可能か検討する |
| NO: 対応するレジストリが分からない | 「5-1. 構成プロファイルがあるか？」「5-3. コマンド、スクリプトがあるか？」観点でも並行して対応を検討する |
「構成プロファイルがあるか？」「レジストリか？」「コマンド、スクリプトがあるか？」という観点は、並行して検討することがおすすめです。
スクリプトやアプリは運用難易度が上がる傾向にあるため、理想は可能な限り構成プロファイルに設計を寄せることです。
現実には、うまく構成プロファイル形式に訳せない設定や、スクリプト・アプリの動作仕様の方が要件に合う設定もあり、これらは最終的にスクリプトやアプリとして実装します。
運用におけるスクリプト・アプリの課題
現状、Intune ではスクリプトやアプリパッケージのライフサイクルマネジメントに課題があります。
Intune 管理センター上に一度アップロードすると以後中身を確認・編集したりエクスポートしたりすることができないため、構成が簡単にブラックボックス化してしまいます。
パラメータシートにスクリプトを掲載したり、GitHub や Azure DevOps などを活用したり、管理センターの外で工夫する必要があるのが現状です。
なお、GPO ではネイティブにレジストリを展開できるため、GPO 再現を検討する際はお客様からレジストリ形式で項目を連携されることも多いです。
この場合も、他の設定と同じく要/不要を棚卸ししたうえで、改めて実装方法を検討するのが理想です。
レジストリ展開について
意外に思われることが多いですが、Intune にはレジストリ展開をネイティブにサポートするポリシープロファイルが存在していません。
このため、レジストリを展開したい場合はスクリプトなどの実行ファイル形式にして対応します。
(参考：レジストリ設定展開用 Intune Win32 アプリを、PowerShell スクリプトで簡単に実装したい)
Intune 上ではスクリプトまたはアプリとして実装するため、例にもれず管理センター上ではブラックボックス化してしまいます。文書管理文化が無い組織カルチャーの場合は要注意です。
5-2-1. 製品設定か？
| 製品の設定か？ | Next Step |
|---|---|
| YES: 何らかのソフトウェアの設定である | 「5-2-1-1. 設定カタログ」「5-2-1-2. ADMX」「5-2-1-3. Office」の方法で実装可能か検討する |
| NO: 特にソフトウェアとは関係ない設定である | 「5-2-2. HKLM か？」に応じて実装検討、または「5-1. 構成プロファイルがあるか？」「5-3. コマンド、スクリプトがあるか？」観点でも並行して対応を検討する |
お客様既存システムでレジストリとして展開されている設定も、Intune 実装にあたっては先述の運用観点から可能な限り構成プロファイル (またはその類似機能) に寄せる利があります。
Microsoft Edge や旧Office (Microsoft 365 Apps)、Google Chrome をはじめとした 3rd party 製品などソフトウェアに関連する制御は、「5-2-1-1. 設定カタログ」「5-2-1-2. ADMX」「5-2-1-3. Office」の例に挙げられるように、レジストリ以外の方法で実装できる場合があります。
5-2-1-1. 設定カタログ
- 参考：
ひと昔前は Google Chrome もカスタム テンプレートで ADMX ingestion をして構成していましたが、いまは設定カタログから構成できるようになりました！
まずは設定カタログの「設定ピッカー」上でキーワード検索するのがおすすめです。
設定カタログ推奨の動き
構成プロファイルセクションで先述のように、現在 "unified settings platform" 移行に伴い一部テンプレートの廃止や統合が進んでいます。
- 管理用テンプレート (Administrative Template)：構成プロファイルテンプレート廃止、当該項目は今後設定カタログにて実装可能
- カスタム (Custom OMA-URI)：設定カタログに存在する OMA-URI を使ったカスタムプロファイルの新規作成ブロック
従来 Microsoft Edge は管理用テンプレートで、Google Chrome は ADMX ingestion を使ったカスタム テンプレートで実装されることが多かったですが、今後は使えなくなります。
これらに関しても設定カタログをファースト チョイスにするのが吉と思います。
5-2-1-2. ADMX
GPO など既存のシステムでは製品ベンダーから提供された ADMX をインポートしポリシーを構成することがありますが、Intune でも同様のことが実施できるようになりました！
3rd party 製品の ADMX ファイルを Intune 管理センター上にインポートする機能が現在パブリック プレビューで提供されており、私もプロジェクトにてこの機能にお世話になっています。
例えば、Mozilla Support が Group Policy 向けに公開している ADMX テンプレートを Intune でも利用できます。
(参考：Firefox for Enterprise - グループポリシーを使用して Firefox をカスタマイズする)
なお、現在対応している ADML ファイルは en-us のみのため、Intune 管理センターの言語設定を英語にして構築・テストする必要があります。
また、ADMX ファイルに依存関係がある場合は、前提となるファイルからインポートするなど構築順に配慮が必要です。
(こうした Tips や、ADMX ファイルインポート～ポリシー作成までの step by step の手順は公開情報上に記載があります。)
5-2-1-3. Office
Office あらため、Microsoft 365 Apps for enterprise (以降、M365Apps) に関連するポリシーは、「クラウドポリシー」を使って展開することができます。
よく Intune 導入と同時期に Office 16 などから M365Apps へ Office 更改を実施されることがありますが、「Office 16 時代に使っていたポリシーと同等の制御を M365Apps でも使いたい」といった場合にクラウドポリシーが非常に便利です。
Office のポリシーはユーザーベースという仕様があり、Windows 上のレジストリでいうと HKCU キーにマッピングされます。
| 製品 | レジストリキー |
|---|---|
| Office 16 | HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\11.0\ |
| Microsoft Apps for enterprise | HKEY_CURRENT_USER\Software\Policies\Microsoft\Cloud\Office\16.0\ |
一般に、HKCU キーのレジストリを Intune から展開する場合、以下の難点があります。
-
実装の難点：作りこみが必要
- レジストリ設定を実行可能ファイルにする
- スクリプト、またはアプリとして展開する
- アプリ展開の場合：実行可能ファイルを Intune から展開可能な形式 (.intunewin) にラッピングする
- 管理の難点：Intune 上に配置されたスクリプト/アプリの実行ファイル中身を参照できない (ブラックボックス化)
さらに、HKCU キーを触るにはユーザーコンテキスト (ユーザー権限) 実行が必要ですが、レジストリ操作に端末管理者権限が必要なことから、エンドユーザーのアカウントがローカル管理者権限を持つ必要があります。
以上、かなり環境を選ぶ実装方法になってしまいます。
この点、クラウドポリシーは Intune ではなく M365Apps の機能で、Office 関連のポリシーを GUI ベースで作成、展開することができます。
エンドユーザーの端末権限に依らず適用できるという利点もあります。
クラウドポリシーは Microsoft 365 Apps admin center、または Intune 管理センター上に同居している「Office アプリのポリシー」ペインから作成・編集・管理することができます。
-
Microsoft 365 Apps admin center > Customization > Policy Management
-
Microsoft Intune 管理センター > アプリ > Office アプリのポリシー
Microsoft 365 Apps for Business のサポート
Microsoft 365 Business Premium など、"Business" 系のライセンス形態だと同梱の Office 製品は Microsoft 365 Apps for Business になります。
Microsoft 365 Apps for Business に対しては、クラウドポリシーのサポートが限定的になります。
具体的には、プライバシー関連の制御項目のみサポートされています。
5-2-2. HKLM か？
| そのレジストリ設定は HKLM キーか？ | Next Step |
|---|---|
| YES: HKLM キーである | スクリプト または アプリとして実装する |
| NO: HKLM キーではない | 「6. その他」へ |
レジストリやコマンドは、Intune では標準で展開する機能が無い (管理センターの GUI に打ち込んで展開することができない) ので、PowerShell スクリプトやアプリといった何かしら Intune が展開できる形式に落とし込んで実装します。
スクリプトで実装するか？ アプリで実装するか？
レジストリやコマンド含め、一般に Windows における開発物は以下のいずれかの Intune 機能を使って実装します。
- プラットフォームごとのスクリプト (旧称: スクリプト)
- Win32 アプリ
- 修復 (旧称: プロアクティブな修復)
各機能の概要については以前記事で触れたことがあるので、ご興味のある方はこちらもどうぞ！
前項「5-2-1-3. Office」に HKCU レジストリキー展開の注意点 (難点) を記載しましたが、HKLM キーの場合には先述の難点は当てはまらず、ある程度汎用性のある対応ができます。
レジストリ (HKLM) 設定展開の実装例
以前記事にしましたので、もしよければご参考ください！
(タイトルがややこしいですが、アプリとして実装する例です。)
5-3. コマンド、スクリプトがあるか？
| 求める設定に対応するコマンドがあるか？ | Next Step |
|---|---|
| YES: コマンドが存在する | スクリプトまたはアプリとして実装する |
| NO: コマンドが存在しない | 「5-1. 構成プロファイルがあるか？」「5-3. コマンド、スクリプトがあるか？」観点でも並行して対応を検討する |
構成プロファイルも無い、レジストリも不明または対応していない、となると最後の砦はスクリプトになります。
スクリプトが用意できたら、それを実装する Intune 側機能としてはざっと 3通りあります。(レジストリ実装時の選択肢と同じです。)
【再掲】スクリプトで実装するか？ アプリで実装するか？
レジストリやコマンド含め、一般に Windows における開発物は以下のいずれかの Intune 機能を使って実装します。
- プラットフォームごとのスクリプト (旧称: スクリプト)
- Win32 アプリ
- 修復 (旧称: プロアクティブな修復)
各機能の概要については以前記事で触れたことがあるので、ご興味のある方はこちらもどうぞ！
なお、スクリプティングでタスクシークエンスを実現するのは、Intune では非推奨という扱いになっています。
理由は、処理が複雑になりトラブルシュートが困難になるから、とのことです。
(参考：Windows Autopilot: notes from the field)
あまりひとつのスクリプトに処理を詰め込まず、ある程度の論理的固まりの単位でまとめておきたいところです。
6. その他
最後に、これまでの工程でキャッチできなかったものは、個別に検討を実施します。
例えば、HKU キーや HKCU キーなど HKLM 以外のキーの場合は、ユーザー権限やプロビジョニングフローを鑑みて実装できる場合とできない場合があります。
こうした実現可否についても最終判断を実施します。
残念ながら、Intune の製品デザイン上どうしても実装できない設定であるという結論になるものもあります。
そういった場合は、まず項目自体が今後必要なのかに立ち返り、必要な場合は別のシステム・サービス・製品での実装を検討することになります。
備考：構成プロファイル、レジストリ、コマンド... どれを選ぶ？
「構成プロファイルがあるか？」「レジストリか？」「コマンド、スクリプトがあるか？」という点、現場では並行して back and forth で検討する旨先述しましたが、何を決め手にどれにすればいいのでしょうか。
経験則ベースの話ですが、組織が策定するデバイスポリシーは一般に以下の 2つのタイプに分けられることが多いです。
(タイプ名は恣意的に付けました。私は頭の中でいつもこう呼んでいます。)
| # | タイプ | 説明 | ユーザーによる設定変更 |
|---|---|---|---|
| 1 | Persistent setting | デバイスの定常設定。デバイス利用環境に合わせてアプリやOSのあるべき状態を考慮して策定される。セキュリティ目的であることが多い。多少生産性に影響があっても保持されるべき設定。 | 許可しない |
| 2 | Default setting | デバイスの初期設定。利便性を考慮して策定される。ユーザーの好みに合わせて変更されてもいい設定。 | 許可する |
タイプ 1 (Persistent Setting) の動作を求めるのであれば、構成プロファイルが適しています。
| 設定 | タイプ 1 | タイプ 2 |
|---|---|---|
| 構成プロファイル | ◎ | × |
| アプリ、修復 | 〇 | 〇 |
| プラットフォームごとのスクリプト | × | ◎ |
(凡例 ◎: 最適！、○: できる、△: 難易度上がるがまぁできる、×: 仕様上不可)
割合でいうと、肌感覚ですが Autopilot プロジェクトでもない限り基本 Intune に求められるのはタイプ1 の persistency です。
構成プロファイルとレジストリは容易にタイプ 1の実装が可能です。
(レジストリを修復または Win32 アプリとして実装し、しっかり検出する場合。)
コマンドやスクリプトになっている設定でタイプ 1を実現するには、一工夫が必要です。
(具体的には、修復または Win32 アプリとして実装し、かつ検出規則には戻り値設計した検出スクリプトを使う必要があります。)
あまり作りこみの観点を語ろうと欲張りすぎると、この記事がいつまでも公開できない記事になってしまうので、本記事ではこの程度で....
拙過去記事でも開発について少し触れたことがあるので、ご興味ある方はこちらもどうぞ！
さいごに
「GPO Intune 移行」でネット検索すると、グループポリシー分析 ぐらいしかヒットしないことが長らく気になっていました。(私の環境だけかもしれないですが)
もちろんグループポリシー分析の登場は革命的です。
ただ、Intune 担当をやっていると、この機能だけで完結するワンタッチ移行は、あくまで理想の世界のことだと思うようになりました。
実際のプロジェクトでエンカウントする現実では、GPO 以外の方法で実装されている設定の再現検討が必要だったり、GPO であってもグループポリシー分析がサポートするよりも広い範囲で設定の取捨選択が必要だったりします。
ポリシー再現検討は一筋縄ではいかない... a long and wining road だし there's really no royal road と思っているのは、私だけではないと思います。
一方で、なかなかその複雑な実態について、お客様のみならずプロジェクトチーム内でも認識にバラつきがある、ということが結構あるとも感じます。
本記事が少しでもそのギャップを埋める一助になればいいなと思います。
なお、本記事のように実装方法を仕分けしたとして、その次はさらにパラメータレベルの検証と設計 fix が必要です ―― 道のりは長いですね。
また、場合によっては一足飛びに Intune ネイティブな管理を目指すのではなく、Entra hybrid join で GPO 併用期間を設けたり、共同管理で Configuration Manager 併用期間を設けることも視野にロードマップの検討が必要です。
みなさまの cloud journey に幸ありますように。