Microsoft IntuneでサードパーティのADMXを配布する

前回のADMXのしくみと読み方では、Active Directoryのグループポリシーで使われてきたADMXのしくみを紹介しました。 ADMXの設定は、Microsoft Intune（以下、Intune）のようなMDMからも配布できます。

今回は、IntuneでサードパーティのADMXの設定をWindowsデバイスに配布する方法を紹介します。 それぞれの方法でWindowsデバイスに何が届き、レジストリに値が書き込まれるまでに何が起きるのかを、実機で確かめた結果とともに説明します。

題材には、ADMXが公開されているZoom Workplaceのデスクトップアプリケーションを使います。

検証した環境は次のとおりです。

Windowsデバイスで何が起きるのか

IntuneでADMXの設定を配布する方法は、次の3つです。

1. 設定カタログ
2. ADMXのインポート
3. カスタムプロファイル（OMA-URI）

どの方法でも、Windowsデバイス側のしくみは同じです。 そこで、まずはWindowsデバイスで何が起きるのかを説明します。

MDMクライアントとPolicy CSP

IntuneからWindowsデバイスへの設定は、OMA-DMというプロトコルで届きます。 受け取るのは、Windowsに組み込まれているMDMクライアントです。 Mobile Device Management overviewにあるとおり、MDMで管理するためにクライアントを別にインストールする必要はありません。

MDMクライアントは、受け取った設定を構成サービスプロバイダ（CSP: Configuration Service Provider）に渡します。 CSPも、Windowsに組み込まれている、設定の種類ごとの受け口です。 ポリシーを扱うのはPolicy CSPで、ほかにもBitLockerやVPNなど、機能ごとのCSPがあります。

OMA-URIの読み方

OMA-DMで設定を送るときに、どのCSPのどの設定に渡すかを表すパスがOMA-URIです。 OMA-URIは、ファイルのパスのように/で区切った、設定の住所です。 Windowsの多くのCSPでは、次の形式になります。

/Vendor/MSFTは、CSPを提供するベンダー（MSFTはMicrosoft）を表します。 Windowsに組み込まれたCSPはMSFTの下にあるため、ここは常に/Vendor/MSFTと書きます。

先頭の{対象}は、設定をWindowsデバイス全体に効かせるか、ユーザーごとに効かせるかを表し、次の2つから選びます。

ADMXのポリシーでは、前回の記事で紹介したclass属性に合わせて選びます。 class="Machine"のポリシーはDevice、class="User"のポリシーはUserです。 class="Both"のポリシーは、どちらでも設定できます。

Policy CSPのドキュメントによると、Deviceの場合は./Deviceを省略して./Vendor/MSFT/Policy/...と書くこともできます。 この記事では、対象がわかるように./Deviceを省略せずに書きます。

たとえば、カメラの使用を許可するかどうかを設定する、Policy CSPのCamera/AllowCameraのOMA-URIは次のとおりです。

./Device/Vendor/MSFT/Policy/Config/Camera/AllowCamera

区切りごとに分けると、次のようになります。 図の区切りを、各行の左から右へ、上の行から順につなげると、元のOMA-URIになります。

左から順に読むと、次のことを表しています。

1. ./Device：Windowsデバイス全体に効かせる
2. /Vendor/MSFT：Microsoftが提供するCSPの中から選ぶ
3. /Policy：ポリシーを扱うPolicy CSPに渡す
4. /Config：Policy CSPの中の、ポリシーを設定する場所
5. /Camera：カメラに関するポリシーの分類
6. /AllowCamera：その分類の中の、カメラの使用を許可するかどうかの設定

値に0を指定するとカメラの使用が禁止され、1を指定すると許可されます。 CSPの中の設定に何を書けるかは、Policy CSP - Cameraのように、CSPごとのドキュメントで確認します。 サードパーティのADMXのポリシーも同じPolicy CSPを使いますが、CSPの中の設定は、後述するようにADMXの内容から組み立てます。

カスタムプロファイルでは、OMA-URIと値の組を自分で書きます。 設定カタログとADMXのインポートでは、IntuneがOMA-URIと値を生成して送ります。

ADMXの取り込みと値の設定

サードパーティ製アプリケーションのADMXは、Windowsに組み込まれていません。 そのため、Windowsデバイスは次の2段階で設定を受け取ります。

1. ADMXの取り込み：ADMXの全文をPolicy CSPに渡し、Windowsデバイスにポリシーの定義として登録する
2. 値の設定：取り込んだADMXのポリシーに、有効、無効や入力値を設定する

どちらの段階も、OMA-URIで宛先を指定します。 ここからは、ZoomのADMXを例に、それぞれのOMA-URIを説明します。

1. ADMXを取り込むOMA-URI

ADMXの取り込みには、次の形式のOMA-URIを使います。

./Device/Vendor/MSFT/Policy/ConfigOperations/ADMXInstall/{AppName}/Policy/{FileUid}

{AppName}はアプリケーションの名前、{FileUid}はADMXファイルの識別子で、どちらも取り込む側が決めます。 途中のPolicyは設定の種類で、PolicyかPreferenceを指定します。 ADMXのポリシーを取り込む場合はPolicyです。 ADMXの取り込みはWindowsデバイスへの操作のため、ユーザー向け（class="User"）のポリシーを含むADMXでも、対象はDeviceです。 たとえば、ZoomのADMXを、AppNameをZoomMeetings、FileUidをZoomMeetings_HKLM_7_2として取り込むOMA-URIは次のとおりです。

./Device/Vendor/MSFT/Policy/ConfigOperations/ADMXInstall/ZoomMeetings/Policy/ZoomMeetings_HKLM_7_2

区切りごとに分けると、次のようになります。

このOMA-URIの値には、ADMXの全文を指定します。

2. 取り込んだADMXのポリシーに値を設定するOMA-URI

取り込んだADMXのポリシーには、次の形式のOMA-URIで値を設定します。

./{対象}/Vendor/MSFT/Policy/Config/{AppName}~Policy~{カテゴリのパス}/{ポリシーの名前}

{AppName}には、取り込むときに決めたAppNameを使います。 対象は、前述のとおりポリシーのclass属性に合わせてDeviceかUserを選びます。 {カテゴリのパス}は、ポリシーが属するカテゴリからparentCategoryを親へたどり、親から順に~でつないだものです。 {ポリシーの名前}は、policy要素のname属性です。 どちらもエディタの表示名ではなく、ADMXのnameを使います。

ZoomのADMXで、クラウドレコーディングを無効にするポリシーは次のように定義されています。

<categories>
  <category name="ZoomUsCommunication" displayName="$(string.ZoomUsCommunication)" />
  <category name="zoommeetings" displayName="$(string.zoommeetings)">
    <parentCategory ref="ZoomUsCommunication" />
  </category>
</categories>
<policies>
  <policy name="DisableCloudRecording_Policy" class="Machine"
    key="Software\Policies\Zoom\Zoom Meetings\Meetings" valueName="DisableCloudRecording" ...>
    <parentCategory ref="zoommeetings" />
    <enabledValue>
      <decimal value="1" />
    </enabledValue>
    <disabledValue>
      <decimal value="0" />
    </disabledValue>
  </policy>
</policies>

DisableCloudRecording_Policyのカテゴリはzoommeetings、その親はZoomUsCommunicationです。 そのため、AppNameをZoomMeetingsとして取り込んだ場合、このポリシーに値を設定するOMA-URIは次のようになります。

./Device/Vendor/MSFT/Policy/Config/ZoomMeetings~Policy~ZoomUsCommunication~zoommeetings/DisableCloudRecording_Policy

区切りごとに分けると、次のようになります。

値は、<enabled/>や<disabled/>のようなXMLの断片で指定します。 入力欄がある場合は、elementsのidを使って<data id="..." value="..."/>を続けます。

<!-- 有効にする -->
<enabled/>
<!-- 無効にする -->
<disabled/>
<!-- 有効にして、数値の入力欄（id="SetUpdatingChannel_Part"）に1を入れる -->
<enabled/><data id="SetUpdatingChannel_Part" value="1"/>

Windowsデバイスで確認できる場所

取り込みと値の設定は、Windowsデバイスの次の場所で確認できます。

<登録ID>は、WindowsデバイスがIntuneに登録されたときのIDです。 <エリア名>は、OMA-URIの{AppName}~Policy~{カテゴリのパス}の部分で、イベントビューアでは「領域」と表示されます。 設定された値の状態のdeviceは、対象がDeviceのポリシーの場合です。 対象がUserのポリシーは、ユーザーごとのキーに記録されると考えられます。

処理の記録は、イベントビューアの「アプリケーションとサービス ログ > Microsoft > Windows > DeviceManagement-Enterprise-Diagnostics-Provider > Admin」で確認できます。

イベントログには、処理ごとにイベントIDの付いたイベントが記録されます。 今回の検証で、ADMXの取り込みと値の設定に関係して記録されたのは、次のイベントIDです。

イベントIDは、Intuneの設定ごとに決まるものではなく、Windows側で処理の種類ごとに決まっているようです。 そのため、Intune以外のMDMから配布しても、同じ処理なら同じイベントIDが記録されると考えられます。 一方で、値の種類が違えば別のイベントIDになります。 たとえば、ADMXのポリシーのように文字列で設定する値は、ポリシー文字列の設定イベント（814）として記録されます。 一方で、Windows Updateのポリシーなど整数で設定する値は、ポリシー整数の設定イベント（813）として記録されていました。 また、筆者が探した範囲では、Microsoftはこれらのイベントの一覧を公開していません。 Windowsのバージョンによって変わる可能性もあります。

次の画像は、イベントビューアでポリシー文字列の設定イベント（814）を表示したところです。 AppNameをZoomTfとして取り込んだときの記録です。 ポリシーの名前（DisableCloudRecording_Policy）、エリア名（ZoomTf~Policy~ZoomUsCommunication~zoommeetings）、設定した文字列（<enabled/>）が記録されています。 登録IDとコンピュータ名は伏せています。

IntuneでADMXの設定を配布する3つの方法

前述の3つの方法を、ADMXの用意のしかたと向いている場面で比べると、次のとおりです。

Microsoftのドキュメントからは、設定カタログを優先するよう読み取れます。

• Use ADMX templates on Windows devices in Microsoft Intuneの冒頭では、設定カタログの管理用テンプレートはIntuneに組み込まれており、ダウンロードやOMA-URIは不要と説明されています
• Add custom settings for Windows devices in Microsoft Intuneの冒頭の注記では、設定できる項目は設定カタログで確認するよう案内されています
• Import custom and third-party partner ADMX templates in Microsoft Intuneの冒頭のヒントでも、Google Chromeなどの設定が設定カタログに組み込まれていると案内されています

設定カタログにないアプリケーションでは、ADMXのインポートか、カスタムプロファイルを使います。

方法1：設定カタログ

設定カタログは、Intuneにあらかじめ組み込まれた設定から選んで配布する方法です。 Microsoft Edgeのように、ADMXで管理するアプリケーションの設定も含まれています。

Edgeの設定も、Windowsデバイスでは同じようにADMXを取り込んでから値が設定されていました。 次の画像は、Microsoft Edgeの「Hide the First-run experience and splash screen」（HideFirstRunExperience）を有効にしたプロファイルです。

このプロファイルを配布したところ、Windowsデバイスには次の2つのADMXが取り込まれました。

1つ目は、Edgeのmsedge.admxから、配布した設定だけを切り出したADMXでした。 Intuneは、Edgeの大きなADMXを丸ごと送らずに、配布する設定を小さなADMXに切り出して取り込ませていることがわかります。 値はHKLM\SOFTWARE\Policies\Microsoft\Edge\HideFirstRunExperienceに1として書き込まれました。

Intuneに組み込まれている設定であれば、ADMXの用意も取り込みの管理も不要です。

方法2：ADMXのインポート

ADMXのインポートは、IntuneにADMXとADMLをアップロードし、その設定を「インポートされた管理用テンプレート」のプロファイルで配布する方法です。 執筆時点では、まだプレビューの機能です。

制限事項

Import custom and third-party partner ADMX templates in Microsoft Intuneの「What you need to know」には、次の制限が書かれています。

• アップロードできるADMXは20個まで。1ファイル1 MBまで
• 1つのADMXにつき、ADMLは1つ。言語はen-USだけ
• 入力欄にcomboBoxを使うADMXはインポートできない
• 別のADMXの名前空間を参照している場合は、参照先のADMXを先にアップロードする

最後の制限は、ADMXのusing要素に関係します。 using要素で別のADMXの名前空間を宣言しているADMXは、その名前空間を持つADMXを先にアップロードしておく必要があります。 特にWindows.admxの名前空間（Microsoft.Policies.Windows）を宣言しているADMXでは、Windows.admxのアップロードが必要です。 Windows.admxは、Windows標準のカテゴリや対応バージョンをまとめたADMXで、サードパーティ製のADMXでも宣言されていることがあります。 将来は、Windows.admxは自動で含まれるようになり、アップロードが不要になる予定です³。

同じ「What you need to know」には、依存しているADMXはpolicyNamespacesのusing要素で確認できるとも書かれています。 たとえば、ZoomのADMXはWindows.admxの名前空間を宣言しています。

<policyNamespaces>
  <target prefix="fullarmor" namespace="ZoomMeetings_HKLM_7_2" />
  <using prefix="windows" namespace="Microsoft.Policies.Windows" />
</policyNamespaces>

しかし、ZoomのADMXはWindows.admxの定義を実際には使っていません。 宣言した名前空間の定義はwindows:SUPPORTED_Windows8のように接頭辞を付けて参照しますが、ZoomのADMXにはwindows:で始まる参照が1つもありません。 対応バージョン（SUPPORTED_WINXPSP2）とカテゴリは、どちらもZoomのADMXの中で定義されています。 7.2.0と6.6.5のZoomMeetings_HKLM.admx、ZoomMeetings_HKCU.admxは、どれもusing要素で宣言しているのにwindows:の参照がありませんでした。 using要素が残っているのは、旧形式のADMから変換ツールで作られたためだと考えられます。 ADMLにはADMXMigrator_NoSupportedOnという文字列があり、変換ツールのFullArmor ADMX Migratorが付けたものと思われます。

それでも、ZoomのADMXをアップロードするには、Windows.admxを先にアップロードする必要がありました。

ZoomのADMXをアップロードする

ZoomのADMXは、Zoomのサポート記事Mass-deploying with Group Policy Objectsから、バージョンごとのZIPファイルとしてダウンロードできます。 ZIPファイルの中のZoomMeetings_HKLM.admxとen-US\ZoomMeetings_HKLM.admlを使います。

最初にZoomMeetings_HKLM.admxをアップロードすると、次のエラーになりました。

ADMX file referenced not found NamespaceMissing:Microsoft.Policies.Windows. Please upload it first.

先にWindows.admxと英語のWindows.admlをアップロードします。 日本語版のWindowsのC:\Windows\PolicyDefinitionsには、英語のWindows.admlが含まれていない点に注意してください。

英語のWindows.admlは、Microsoftのダウンロードセンターで配布されているAdministrative Templates (.admx) for Windows 11 2025 Update (25H2)のMSIに含まれています。 今回は、次のように7-ZipでMSIを展開して取り出しました。 展開したファイルはstaging_で始まる名前になるため、アップロード用の名前に変えます。

# 7-ZipでMSIを展開する（Windowsでは7z.exe）
7zz x -y -oraw "Administrative Templates (admx) for Windows 11 Sep 2025 Update.msi"

# アップロード用の名前に変える
mkdir -p upload/en-US
cp raw/staging_Windows.admx upload/Windows.admx
cp raw/staging_en_US_Windows.adml upload/en-US/Windows.adml

アップロードは、Intune管理センターの「デバイス > Windows > 構成」を開き、「ADMX のインポート」のタブから行います。 Windows.admx、続いてZoomMeetings_HKLM.admxをアップロードし、どちらも状態が「Available」になれば完了です。

プロファイルを作成する

アップロードしたADMXの設定は、「Windows 10 以降」の「テンプレート > インポートされた管理用テンプレート (プレビュー)」のプロファイルで設定します。 今回は、次の2つの設定を有効にし、すべてのユーザーに割り当てました。

設定の一覧から設定を選ぶと、ADMLの説明と、有効、無効、入力欄が表示されます。 次の画像は、「Set the specified update channel when silent auto update is enabled」を有効にして、1を入力したところです。

Windowsデバイスでの動き

Windowsデバイスで同期すると、まずZoomのADMXが取り込まれました。 AppNameとFileUidは、どちらもfullarmorにGUIDを付けた名前でした。

C:\ProgramData\Microsoft\PolicyManager\ADMXIngestion\<登録ID>\fullarmor<GUID>\Policy\fullarmor<GUID>.admx

fullarmorは、ZoomのADMXのtarget要素のprefixです。 GUIDは、Graph APIで確認したアップロードのIDと一致しました。 取り込まれたファイルを元のADMXと比べると、prefixが同じfullarmor<GUID>に書き換えられ、XML宣言が削除されていました。 名前空間（ZoomMeetings_HKLM_7_2）は元のままです。

Windows.admxは取り込まれていませんでした。 Windowsに組み込まれているためだと考えられます。

値は、取り込みと同じ同期では届かず、次の同期で届きました。 イベントログには、ポリシー文字列の設定イベント（814）が、次の内容で記録されています。

レジストリには、次の値が書き込まれました。

インポートの機能は、OMA-URIのAppNameをfullarmor<GUID>に決めて、prefixを書き換えたADMXと値をOMA-URIで送っていることがわかります。

プロファイルを削除する

プロファイルを削除して同期すると、ポリシーの削除イベント（819）が記録され、2つの値が削除されました。 MeetingsとGeneralのキーごと削除され、値は残りませんでした。

同じ同期で、取り込んだADMXもWindowsデバイスから削除されました。 Intune側には、ADMXのアップロードを残したままです。

方法3：カスタムプロファイル（OMA-URI）

カスタムプロファイルでは、ADMXの取り込みと値の設定を、それぞれOMA-URIで書きます。 ADMXのインポートの制限にあたる場合や、AppNameなどを自分で決めたい場合に使います。

取り込みと値の設定は、別々のプロファイルに分けても、1つのプロファイルにまとめてもかまいません。 ここでは、まずプロファイルを分ける方法を説明し、最後にまとめる方法を紹介します。

ADMXを取り込む

「Windows 10 以降」の「テンプレート > カスタム」のプロファイルを作成し、OMA-URIの設定を追加します。 ADMXを取り込むために追加する設定は、次の1つです。 データ型は「文字列」です。 ADMXのインポートと違い、ZoomのADMXが参照しているWindows.admxを用意する必要はありません。

設定は、「行の編集」の画面で、名前、OMA-URI、データ型、値を入力して追加します。 次の画像は、「Zoom ADMX」を入力したところです。 値には、ADMXのファイルの中身をそのまま貼り付けます。

AppNameはZoomMeetings、FileUidはZoomMeetings_HKLM_7_2としました。 AppNameは値を設定するOMA-URIにも使うため、短くわかりやすい名前がよいと思います。

値の大きさには上限があります。 Microsoft LearnのApp Control for Businessのドキュメントには、カスタムのOMA-URIで配布する値は350,000バイトまでと書かれています。 App Controlのドキュメントですが、この制限はカスタムのOMA-URI全般に当てはまるものとして書かれています。

Graph APIでプロファイルを作成して試したところ、350,000文字の値は作成でき、それより長い値ではエラーになりました。 英数字だけの値で試したため、このときの文字数とバイト数は同じです。 データ型をXMLファイルにしてファイルでアップロードしても、上限は同じでした。 なお、このデータ型で選べるファイルの拡張子は.xmlか.txtだけです。

Zoom 7.2.0のZoomMeetings_HKLM.admxは330,066文字で、上限に近い大きさです。

同期すると、ADMXは指定したAppNameとFileUidで取り込まれました。 Windows.admxを用意していなくても、取り込みはエラーなく終わりました。 参照先のWindows.admxは、Windowsデバイスに組み込まれているものが使われると考えられます。 取り込まれたファイルは、文字コードがUTF-16に変わっていた以外は元のADMXのままで、ADMXのインポートのような書き換えはありませんでした。

値を設定する

値は、取り込みとは別のカスタムプロファイルに、次の2つのOMA-URIの設定を追加しました。 データ型はどちらも「文字列」です。

取り込みと同じように、1つずつ「行の編集」の画面で入力します。 次の画像は、「Disable cloud recording」を入力したところです。

2つの設定を追加すると、プロファイルの一覧は次のようになります。

同期すると、ADMXのインポートと同じ2つの値がレジストリに書き込まれました。

プロファイルを削除する

値のプロファイルを削除すると、ADMXのインポートと同じように、ポリシーの削除イベント（819）が記録され、値が削除されました。

一方で、取り込みのプロファイルを削除しても、取り込んだADMXはWindowsデバイスから削除されませんでした。 同期のたびに、コマンドのエラー状態イベント（454）が次の内容で記録されます。

0x86000011は、そのノードではコマンドが許可されていないことを表すエラーです。 Policy CSPのドキュメントでは、ADMXInstallはDeleteで削除できることになっています。 Intuneが送ったコマンドは確認していませんが、イベントには「Clear: first phase of Delete」と記録されています。 削除はClearから始まり、このノードではそのClearが拒否されています。 そのため、ドキュメントどおりには削除されないようです。

取り込んだADMXが残っても、値がなければレジストリには何も書き込まれません。 ただし、一度取り込んだAppNameとFileUidは、Windowsデバイスに残り続けると考えておく必要があります。

取り込みと値を1つのプロファイルにまとめる

ここまでは取り込みと値の設定を別々のプロファイルに分けましたが、1つのプロファイルにまとめることもできます。 取り込みの設定を先頭に置き、その後ろに値の設定を並べます。 この記事の例では、次の3つの設定を1つのプロファイルに入れました。 データ型はすべて「文字列」で、AppNameはZoomMeetingsAllとしました。

3つの設定を追加すると、プロファイルの一覧は次のようになります。

今回の検証では、最初の同期で取り込みと2つの値の設定が同じ秒に処理され、エラーもありませんでした。 ただし、プロファイルの中の行が上から順に処理されることは、ドキュメントでは保証されていません。 値の設定が取り込みより先に処理されると、その同期では値の設定がエラーになる可能性があります。 その場合は、次の同期で、取り込み済みのADMXのポリシーとして値が設定されると考えられます。

1つのプロファイルにまとめると、ADMXと値の組み合わせを1ヵ所で管理できます。 AppNameを変えたときも、値の行のOMA-URIを同じ画面で確認できるため、直し忘れに気付きやすくなります。 一方で、別々のプロファイルに分けると、同じADMXを取り込んだうえで、値の設定だけを部署ごとに変えて割り当てるような使い方も考えられます。

ADMXのインポートとOMA-URIを併用しない

ADMXのインポートでADMXを用意し、値だけをOMA-URIで設定することも考えられます。 インポートしたADMXは、WindowsデバイスではprefixにGUIDを付けたAppName（Zoomの場合はfullarmor<GUID>）で取り込まれます。 そのため、次のようなOMA-URIで値を設定できる可能性があります。

./Device/Vendor/MSFT/Policy/Config/fullarmor<GUID>~Policy~ZoomUsCommunication~zoommeetings/DisableCloudRecording_Policy

しかし、この併用は避けたほうがよいと考えています。 理由は次の3つです。

1. ADMXをアップロードしただけでは、Windowsデバイスに取り込まれないと考えられる。プロファイルを削除すると取り込みも消えたことから、取り込まれるのは、そのADMXを使う「インポートされた管理用テンプレート」のプロファイルが割り当てられたときだけと思われる
2. 取り込みが別のプロファイルに依存する。インポートの機能のプロファイルを外すと取り込みが削除され、OMA-URIで設定した値も効かなくなると考えられる
3. AppNameのGUIDはアップロードのIDのため、バージョンの更新などでADMXをアップロードし直すと変わる。そのたびにOMA-URIを書き直す必要があると考えられる

この使い方はドキュメントにもありません。 ADMXの用意と値の設定は、ADMXのインポートかOMA-URIのどちらか一方にそろえるのが安全だと思います。

どの方法を選ぶか

ここまでの結果を、観点ごとに比べると次のようになります。

バージョンの更新の手順と注意点は、次回の記事で詳しく紹介します。

配布したい設定が設定カタログにあれば、設定カタログを使います。 設定カタログにない場合は、画面で設定を選べるADMXのインポートが扱いやすいと思います。 OMA-URIは、ADMXのインポートの制限にあたる場合や、AppNameを固定してバージョンの更新を管理したい場合に向いています。

終わりに

今回は、IntuneでサードパーティのADMXを配布する3つの方法を紹介しました。

どの方法でも、Windowsデバイスでは、Policy CSPがADMXを取り込み、その定義に従って値をレジストリに書き込みます。 違いは、ADMXの用意のしかた、AppNameを決める主体、そしてプロファイルを削除したときに取り込みが残るかどうかです。 前回の記事のようにADMXを読めれば、どの方法でも、どのレジストリの値が変わるのかを確かめられます。

次回は、実際の運用を見据えて、Intuneでレジストリの設定を運用する方法を紹介する予定です。

参考資料

• Import custom and third-party partner ADMX templates in Microsoft Intune
• Add custom settings for Windows devices in Microsoft Intune
• Use the settings catalog to configure settings on Windows, iOS/iPadOS and macOS devices
• Win32 and Desktop Bridge app ADMX policy Ingestion
• Understanding ADMX policies
• Enable ADMX policies in MDM
• Mobile Device Management overview
• Policy CSP
• Deploy App Control policies using Microsoft Intune
• Mass-deploying with Group Policy Objects（Zoom）
• Administrative Templates (.admx) for Windows 11 2025 Update (25H2)