MENU

IntuneのADMXインポート失敗で削除できない時の対処法｜「Value cannot be null」エラー解説

Microsoft

Intune（Microsoft Endpoint Manager）の「管理テンプレート」でサードパーティ製 ADMX をインポートした際、依存関係エラーからの再インポートや削除に失敗し、「Value cannot be null」エラーで詰んでしまうケースは意外と多く発生します。本記事では、この状況から安全に復旧するための実務的な手順と再発防止策を、具体例を交えながら解説します。

目次

ADMX インポート失敗で削除できない問題の全体像

まず、本記事で扱う典型的なシナリオを整理しておきます。

  • Intune 管理センターで 「デバイス > 構成プロファイル > 管理テンプレート > ADMX のインポート」 を使用
  • サードパーティ製アプリ（Citrix、Chrome、Adobe など）の ADMX をアップロード
  • 一部の ADMX が他の ADMX に依存しており、依存関係エラー（NameSpaceMissing など）でインポートに失敗
  • 不足していた依存 ADMX を追加して再インポートすると成功するが、失敗していた古い ADMX を削除しようとするとエラー

実際に表示される代表的なエラーは次のようなものです。

メッセージ（英語 UI の例）状況
Removal Failed / Error Details: Value cannot be null. Parameter name: inputインポート済み ADMX を削除しようとした際に発生。
内部的なメタデータ不整合が原因と考えられる。
NameSpaceMissing: Microsoft.Policies.Windowsベンダー ADMX が Microsoft.Policies.Windows などの名前空間を参照しているが、
該当する基底 ADMX（例：Windows.admx）がインポートされていない。
The upload of this ADMX file has failed. … delete this upload … and try again.依存関係不足や内部エラーでアップロード失敗。
しかし指示どおり削除しようとしても削除に失敗する場合がある。

この現象は、公式に明確なドキュメントがある「仕様」ではなく、実質的には不具合に近い挙動として現場で認識されています。根本解決には Microsoft へのサポートケース起票が推奨されますが、日々の運用の中では、管理者側で取れるワークアラウンドを知っておくことも重要です。

なぜ「Value cannot be null」エラーが起きるのか

Intune の管理テンプレートに ADMX をアップロードすると、クラウド側には次のような情報が保存されます。

  • アップロードした ADMX / ADML ファイルの内容
  • 内部 ID（GUID やハッシュに近い識別子）
  • 名前空間（例：Microsoft.Policies.Windows、Citrix.Policies など）
  • 各ポリシー定義のメタデータ

依存関係が満たされない状態で一部の ADMX をアップロードすると、名前空間や参照元・参照先の関係が中途半端な形で Intune 上に登録されるケースがあります。その状態で、後から不足していた ADMX を追加したり、同名の ADMX を複数回アップロードしたりすると、

  • 同一の表示名だが内部 ID が異なる ADMX が複数存在する
  • 削除時に参照するべき情報が欠けており、内部処理で「null」が返る

といった状況になり、削除処理が Value cannot be null でコケてしまう、と考えられます。つまり、管理者の操作ミスというよりは、Intune 側のエラーハンドリング不足と捉えた方が実態に近いと言えるでしょう。

そのため、根本的には Microsoft 側の修正待ちとなりますが、現時点でも実務で使える再現性の高いワークアラウンドがいくつか知られています。

実務で使えるワークアラウンドの全体像

現場でよく効くアプローチを整理すると、次のようになります。

対策目的ポイント
依存チェーンの整理どの ADMX がどの名前空間に依存しているかを把握する<using namespace="..." /> を確認し、欠けている基底 ADMX を特定
インポート順に削除削除エラーを回避して古い ADMX をクリーンアップする依存の順ではなく、アップロードした順（古い → 新しい）で削除するのがポイント
Windows.admx を先に入れるMicrosoft.Policies.Windows などの基底名前空間を提供する多くのサードパーティ製 ADMX が Windows の基本ポリシーに依存
ベンダー ADMX を正しい順序で再インポート依存関係を満たした状態で再構築ベース → 上位（例：CitrixBase → Receiver）の順でインポート
待機（最終手段）バックエンド同期のタイミングで削除可能になることに賭ける数週間で直るケースもあるが、期待しすぎない。基本は他の対策を優先。

以下で、それぞれの手順をもう少し具体的に見ていきます。

ステップ 1：ADMX の依存チェーンを確認する

まず、問題となっている ADMX ファイルが、どの名前空間に依存しているかを確認します。ADMX ファイルをテキストエディタ（Visual Studio Code など）で開き、次のような定義を探します。

&lt;policyNamespaces&gt;
  &lt;target prefix="citrix" namespace="Citrix.Policies" /&gt;
  &lt;using prefix="windows" namespace="Microsoft.Policies.Windows" /&gt;
&lt;/policyNamespaces&gt;

この例の場合、Citrix のポリシーは Microsoft.Policies.Windows に依存しています。つまり、

  • Windows.admx（Microsoft.Policies.Windows を提供）
  • CitrixBase.admx（Citrix.Policies を定義）
  • 各種 Citrix アプリケーション用 ADMX（Receiver など）

の順に、依存関係が積み上がる構造になっていると理解できます。

同様に、他のベンダー（Google Chrome など）でも、

  • Windows / Microsoft の基底名前空間
  • ベンダー固有のベース ADMX
  • 製品別の上位 ADMX

という構造になっていることがほとんどです。まずはこの 「基底 → 依存」の関係を紙やメモアプリに書き出して整理しておきましょう。

ステップ 2：削除は「インポート順（古い → 新しい）」で行う

直感的には、

  • 依存しているもの（上位）を先に削除
  • その後に、基底となる ADMX を削除

という順番で削除したくなるところですが、今回の Intune の挙動に関しては、インポートした順番（古いものから順番に）で削除していく方が、削除エラーを回避できるケースが多く報告されています。

たとえば、次の順番でインポートしていたとします。

  1. Windows.admx
  2. CitrixBase.admx
  3. Receiver.admx（ここで依存エラーが発生し、一部失敗）

この場合、削除する際には次のような順番を試してみます。

  1. まず、最初にインポートした Windows.admx を削除
  2. 次に CitrixBase.admx を削除
  3. 最後に Receiver.admx（失敗したものも含めて）を削除

ここで重要なのは、Intune の内部では、アップロードした順に連番や内部 ID が付与されている可能性が高いという点です。削除処理も同じ順序前提で作られていると推測されるため、

  • 最新のものから削除しようとすると内部参照が追いつかず「null」扱いになる
  • 最初に入れたものから順番に消していくと、整合性が取れる

といった挙動になっていると考えられます。

実務的には、次の手順を推奨します。

  • Intune ポータルで当該ベンダーの ADMX をすべて一覧表示
  • 表示名だけでは順番が分かりにくい場合は、アップロード日時やバージョン情報をメモしておく
  • 最も古いもの（最初にアップロードしたもの）から順に削除を試す
  • エラーになったものは飛ばし、削除できたものを先に片付ける

この「地道な掃除」を行うだけで、最終的にすべての重複 ADMX が削除できた例も多くあります。

ステップ 3：Windows.admx を先にインポートする

依存関係のエラーで特に多いのが、次のようなメッセージです。

NameSpaceMissing: Microsoft.Policies.Windows

これは、対象の ADMX が Windows 標準のポリシー名前空間 Microsoft.Policies.Windows を使用しているにもかかわらず、Intune に Windows.admx がインポートされていない（または不完全な状態で登録されている）ことを意味します。

したがって、環境をクリーンアップした後は、必ず次の順番で再構築することをおすすめします。

  1. Windows.admx を先にインポートする
    • ソースは通常、管理端末の C:\Windows\PolicyDefinitions\Windows.admx
    • 言語ファイル（例：ja-JP\Windows.adml）も忘れずに
  2. その上で、各ベンダーの ADMX（Citrix、Chrome など）を順に投入

この手順を踏むことで、「NameSpaceMissing: Microsoft.Policies.Windows」系のエラーはかなりの割合で解消できます。

ステップ 4：ベンダー ADMX を正しい順で再インポートする

Windows.admx のインポートが完了したら、各ベンダーの ADMX を再インポートしていきます。このときも、「基底 → 依存」の順序を守ることが重要です。

Citrix の例：CitrixBase.admx → Receiver.admx

Citrix の場合、代表的な構成は次のようになります。

  1. CitrixBase.admx
    • Citrix 全体で共通する基本ポリシーを定義
    • 多くの製品用 ADMX から参照されるベース
  2. Receiver.admx（または Workspace など製品ごとの ADMX）
    • Receiver（現 Workspace アプリ）の UI や接続設定などを提供
    • コンボボックス定義など、一部の UI 要素が Intune 環境と相性問題を起こすことがある

特に Receiver 系 ADMX では、コンボボックスなどの UI 定義が Intune の管理テンプレートと噛み合わず、専用に調整された Intune 向けカスタム ADMX が必要になるケースもあります。ベンダーのドキュメントやコミュニティで、Intune での利用を想定した ADMX が提供されていないかを確認しておくと安心です。

同様の考え方は他ベンダーにも応用できます。

ベンダー例基底 ADMX上位 / 製品別 ADMXポイント
CitrixCitrixBase.admxReceiver.admx / Workspace.admx などまず Windows.admx → CitrixBase → 各製品の順で入れる
Googlechrome.admx管理テンプレート拡張用 ADMX（環境による）Chrome 向けは Intune 用サンプルが公開されていることも多い
AdobeAcrobatBase.admx 等製品別 ADMX（Reader / Acrobat）バージョン違いの混在に注意

ステップ 5：待機という最終手段について

実際の現場からの報告として、

  • 削除に失敗した ADMX が、数週間後に再度削除を試したら成功した
  • バックエンドのメンテナンスや内部同期が入るタイミングで解消したように見える

といったケースがあります。これは、Intune のバックエンドが非同期で動いており、時間経過とともに内部データの整合性が取れるためと推測されます。

ただし、

  • 待っても解消しなかった、という報告も多い
  • 業務上、長期間放置すべきでないケースも多い

という点を踏まえると、待機はあくまで「他の手段でどうにもならなかったときの最後の選択肢」と考える方がよいでしょう。

画面ベースでの具体的な操作手順（例）

ここでは、Citrix 関連 ADMX を例に、「削除できない状態から復旧する」流れを具体的にまとめます。

1. 現状の ADMX 一覧を確認する

  1. Intune 管理センターにサインイン
  2. 「デバイス」 > 「構成プロファイル」 > 「管理テンプレート」 > 「インポートされた ADMX」 を開く
  3. ベンダー名（Citrix など）でフィルタし、対象 ADMX をすべて一覧表示
  4. 表示名・バージョン・アップロード日などをメモし、インポート順のイメージをつかむ

2. インポート順（古い → 新しい）で削除を試す

  1. 最も古いと思われる ADMX を選択し、「削除」を実行
  2. 削除が成功したものは、そのままリストから消える
  3. 「Value cannot be null」エラーが出たものは、一旦スキップ
  4. 残りの ADMX についても、古いものから順に同様の操作を繰り返す
  5. 可能な限り全ての重複 ADMX を削除し、環境を「ほぼ空」の状態に近づける

3. Windows.admx をインポートする

  1. 管理端末上の C:\Windows\PolicyDefinitions から Windows.admx を用意
  2. 同じフォルダ配下の言語ディレクトリ（例：ja-JP\Windows.adml）も取得
  3. Intune 管理センターで「ADMX のインポート」から、Windows.admx（および ADML）をアップロード
  4. エラーが出ないことを確認する

4. CitrixBase.admx → Receiver.admx の順で再インポート

  1. ベンダー提供の最新 ADMX パッケージから、CitrixBase.admx とその ADML をアップロード
  2. その後に Receiver.admx をアップロード
  3. アップロード時に「NameSpaceMissing」などのエラーが出ないことを確認
  4. Receiver 用 ADMX が Intune 対応版として提供されている場合は、必ずそちらを使用

この一連の流れにより、多くの環境で「削除できない」「依存エラーで再インポートできない」という状態から復旧できます。

エラーメッセージ別の対処のヒント

よく見かけるエラーメッセージと、そのときに考えるべきポイントを一覧にしておきます。

エラーメッセージ原因のイメージ主な対応策
Value cannot be null. Parameter name: input削除処理が内部データ参照に失敗している。
重複や不完全な ADMX が混在している。		インポート順（古い → 新しい）で削除 同名の重複 ADMX を優先的に整理
NameSpaceMissing: Microsoft.Policies.WindowsMicrosoft.Policies.Windows を提供する ADMX（Windows.admx）が存在しないか不完全。Windows.admx を先にインポート 必要に応じて、関連する Windows 系 ADMX も追加
The upload of this ADMX file has failed. … delete this upload … and try again.依存関係不足や内部エラーでアップロード失敗。まず依存チェーンを整理 古い ADMX を順に削除して環境をクリーンに その後、基底 → 依存の順で再インポート

再発防止のための運用ベストプラクティス

一度環境がクリーンになったら、次同じ事象を起こさないように運用ルールを整えておくと安心です。ここでは、現場で実践しやすいポイントをまとめます。

1. ADMX ファイルの保管とバージョン管理

  • ベンダーからダウンロードした ADMX は、共有リポジトリ（SharePoint、OneDrive、Git など）で一元管理
  • フォルダ構成例
    • \ADMX\Microsoft\Windows\2024-01
    • \ADMX\Citrix\2024-03
  • 誰が、いつ、どのバージョンを Intune にインポートしたかを簡単に追跡できるようにする

2. 命名規約の統一（同名 ADMX の混在を避ける）

同じベンダー・同じ製品であっても、バージョン違いや調整版など複数の ADMX が存在する場合があります。次のようなルールを決めておくと、混乱を減らせます。

項目例ポイント
ファイル名CitrixBase_2024-03.admxダウンロード年月やバージョンを含めると識別しやすい
表示名Citrix Base Policies (2024-03)Intune 上でバージョンが分かるように工夫する
Intune へのインポート担当「ADMX 管理者」ロールを明確化誰が勝手にインポートしたのか分からない状況を防ぐ

3. テストテナントでの事前検証

  • 可能であれば、本番とは別に 検証用テナント を用意
  • 新しい ADMX は、必ず検証テナントでインポート手順を確認してから本番に適用
  • 依存関係や UI 上の挙動（ポリシーが正しく表示されるか）を事前にチェック

4. 変更管理とログの整備

  • 「いつ・誰が・どの ADMX を・どの順番で入れたか」を簡易なログでもよいので残す
  • 障害発生時に、インポート順を再現できる情報があると、今回紹介したワークアラウンドが実施しやすくなる

Citrix を例にした具体的な復旧ケース

最後に、実際に多く報告されている Citrix 関連 ADMX のケースを、流れとして整理しておきます。

発生していた問題

  • CitrixBase.admx と Receiver.admx を Intune にインポート
  • Receiver 側で依存関係エラー（NameSpaceMissing など）が発生し、一部ポリシーが表示されない
  • 古い Receiver.admx を削除しようとすると Value cannot be null エラーで削除できない
  • 同名の Receiver が複数リストに並び、どれが生きているものか分かりにくい

実際に行った対応手順

  1. Citrix 関連 ADMX（CitrixBase / Receiver 系）をすべて一覧にする
  2. アップロード日時が古いものから順番に、削除を実行
  3. 削除に成功したものはそのまま削除し、失敗するものは一旦保留
  4. 最終的に、CitrixBase と Receiver のすべてのエントリを削除できるまで繰り返す
  5. 次に、Windows.admx をインポート
  6. その後、CitrixBase.admx → Receiver.admx の順で再インポート
  7. Intune で Receiver のポリシーが正しく一覧表示されることを確認

この流れで、削除できなかった ADMX が正常にクリーンアップされ、Citrix のポリシーも意図通りに管理できるようになった、という報告が複数あります。

どうしても解決しない場合は Microsoft サポートへ

ここまで紹介したワークアラウンドを試しても、

  • 特定の ADMX だけがどうしても削除できない
  • 依存関係をすべて満たしているはずなのに、再インポートが失敗する

といった場合は、テナント固有の問題や、バックエンドの状態異常の可能性があります。その際は、次の情報を整理した上で、Microsoft サポートにケースを起票することをおすすめします。

  • 問題の発生しているテナント情報（テナント ID など）
  • 問題の発生している ADMX の一覧（ベンダー名、ファイル名、バージョン）
  • いつから問題が発生しているか（時系列）
  • これまでに試した操作（削除順序、再インポート、Windows.admx の導入など）
  • エラーメッセージのスクリーンショットやログ

サポート側で内部ログを確認し、テナント側のデータ修正や追加の回避策を案内してもらえる可能性があります。

まとめ：ポイントは「順番」と「依存関係」

Intune の管理テンプレートで ADMX を扱う際、「削除できない」「Value cannot be null」といったトラブルに遭遇すると、直感的には非常に分かりにくく、ポータル上の操作だけでは手詰まり感が出がちです。しかし、ポイントを押さえて整理してみると、次のようなシンプルな原則が見えてきます。

  • これは実質的に「既知の不具合に近い挙動」であり、管理者のミスだけが原因ではない
  • 削除は「依存関係の逆順」ではなく、あくまで「インポートした順（古い → 新しい）」で行うと成功しやすい
  • Windows.admx を最初にインポートし、Microsoft.Policies.Windows などの基底名前空間を満たす
  • ベンダー ADMX は、基底 → 上位（CitrixBase → Receiver など）の順で投入する
  • ADMX の命名規約・バージョン管理・事前検証の運用を整えておくことで、再発リスクを大きく下げられる
  • それでも解決しない場合は、遠慮なく Microsoft サポートにエスカレーションする

特に、「削除はアップロード順」と「Windows.admx を先に入れる」の 2 点は、現場での成功事例が非常に多いテクニックです。Intune でサードパーティ製 ADMX を扱う機会がある方は、ぜひ自社の運用標準に組み込んでおくと、将来的なトラブルシューティングがぐっと楽になります。

Microsoft
グループポリシー Intune Microsoft Endpoint Manager ADMX

この記事を書いた人

佐藤健司のアバター 佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

関連記事

コメント

コメントする

目次