Microsoft Intuneのassignment filtersとは?作成・更新・削除と運用上の注意点

Intuneの割り当てフィルターで使うoperatingSystemVersionは、サービスリリース2608で一般提供になりました。旧osVersionは非推奨で、新しいフィルターには使えません。ただし、既存のosVersionフィルターは引き続き動作するため、一括削除や即時の作り直しは必要ありません。

移行では、旧ルールが表す対象を確認し、新しいバージョン比較条件を作って小規模な割り当てで評価します。プロパティ名だけを置き換えると、文字列の部分一致とOSバージョンの大小比較を混同するおそれがあります。この記事では新旧の扱いと、Include/Exclude、作成・評価・変更時の確認を整理します。

目次

osVersionとoperatingSystemVersionの現在の違い

Intune 2608の新機能では、管理対象デバイスと管理対象アプリの両方でoperatingSystemVersionの一般提供が案内され、既存の割り当ては変更なしで動作すると説明されています。新旧の構文はプロパティと演算子の公式リファレンスで確認できます。

次の表の「新」はoperatingSystemVersion、「旧」はosVersionを指します。

項目新旧の違い
現在の位置付け新:一般提供。新規ルールで使う。
旧:非推奨。新規フィルターで使用不可。既存は継続動作。
値の扱い新:OSバージョン値を比較する。
旧:引用符付き文字列の完全一致・部分一致など。
移行の注意新:必要な範囲の上下限と境界を確認する。
旧:文字列条件が何を対象にしていたか棚卸しする。

主な演算子にも違いがあります。

  • 新(operatingSystemVersion):-eq、-ne、-gt、-ge、-lt、-le。
  • 旧(osVersion):-eq、-ne、-in、-notIn、-startsWith、-containsなど。

たとえば「ある文字で始まるOSバージョン」という旧条件と、「あるビルドより大きい」という新条件は、同じ対象になるとは限りません。既存ルールの目的、含めたい版、除外したい版を先に文章で書き出してください。

OSバージョン条件の構文例

次の2つはMicrosoftの構文例です。古い例示ビルドを運用上の推奨OSや全端末向けの基準として扱わず、必要な製品・ポリシーの条件に置き換えて検証してください。

指定したバージョンより大きいもの

(device.operatingSystemVersion -gt 10.0.22000.1000)

指定したバージョン以下のもの

(device.operatingSystemVersion -le 10.0.22631.3235)

-gtは境界値を含まず、-geは境界値を含みます。-ltと-leも同様です。管理対象アプリのルールではapp.operatingSystemVersionを使います。Managed devicesのdevice.を、Managed appsへそのまま転記しないでください。

割り当てフィルターはグループの対象をさらに絞る

assignment filtersは、Intuneのアプリやポリシーをグループへ割り当てる際に、端末やアプリのプロパティで対象を絞る機能です。グループ自体のメンバーを作り直すものではありません。所有形態、メーカー、モデル、カテゴリ、登録プロファイルなどを、対応するプラットフォームの範囲で利用できます。

Intuneの配布だけに使う単純な端末条件ならフィルターを検討できます。一方、条件付きアクセス、ライセンス、Autopilotなどでも同じ対象グループを使う場合は、その用途に必要なグループを維持します。動的グループをまとめて削除する置換ではありません。割り当てフィルターの公式概要にも使い分けがあります。

フィルターの種類使う場面
Managed devicesIntune登録済み端末向けの、対応するアプリ・コンプライアンス・構成などの割り当て。
Managed apps管理アプリのアプリ保護ポリシー・アプリ構成ポリシー。端末登録を伴わないMAMの場面も含む。

OSが対応していても、すべてのアプリ種別・ポリシーで使えるわけではありません。たとえばWindowsのFeature updates、PowerShellスクリプト、ポリシーセット、Linuxのワークロードは対応対象ではありません。WindowsのWin32アプリやMicrosoft 365 appsなど、現在の対応ワークロード表で対象を確認してください。

Android Enterpriseの個人所有ワークプロファイルでAvailableアプリ割り当てにフィルターを使うと、Include/Excludeは無視されるという制約もあります。管理方式・アプリの配布目的まで確認する必要があります。

IncludeとExcludeは一致した端末の扱いが逆になる

次の表は、対象グループに対する1つの割り当てでのフィルター判定です。他の割り当てとの競合やアプリの配布目的もあるため、この表だけでアプリの最終インストール状態を保証するものではありません。

モードフィルターの判定この割り当ての対象
IncludeMatch(一致)含める
IncludeNo match(不一致)含めない
ExcludeMatch(一致)除外する
ExcludeNo match(不一致)除外しない

「新しいOSの端末だけに試験配布する」ならその端末に一致する条件をIncludeにし、「未更新の端末を対象から外す」なら除外したい端末に一致する条件をExcludeにします。新旧ルールの比較では、条件だけでなくモードも記録してください。

既存osVersionを棚卸しし、新しい条件を検証する

  1. [Tenant administration]→[Assignment filters]で既存のosVersionルールを探します。フィルター名、プラットフォーム、全文を記録します。
  2. [Associated Assignments]で利用しているアプリ・ポリシー、対象グループ、Include/Excludeを確認します。
  3. 旧ルールの文字列条件が意図するOS範囲を整理し、新しいバージョン比較の条件を決めます。
  4. 元のフィルターを残したまま検証用フィルターを作り、対応する場合は[Preview devices]で候補を確認します。
  5. 限定したグループに割り当て、境界値の前後、対象に入る端末、除外される端末で評価結果を確認します。
  6. 結果と実際のアプリ・ポリシー適用が意図に合うことを確認してから、利用先ごとに切り替えます。

同じフィルターを複数の割り当てが参照している場合、既存ルールを直接編集するとすべてに影響します。旧条件と旧割り当ての記録を残し、必要な場合に戻せるようにしてから変更してください。

新しい割り当てフィルターを作成する手順

  1. Intune管理センターの[Tenant administration]→[Assignment filters]→[Create]を開きます。
  2. [Managed devices]または[Managed apps]を選び、名前・説明・プラットフォームを設定します。
  3. [Rules]のルールビルダーまたは構文エディターで、対応する条件を作成します。
  4. 構文エラーを確認し、利用できる場合は[Preview devices]で一致する登録端末を確認します。
  5. 管理範囲に応じて[Scope tags]を設定し、[Review + create]で作成します。
  6. 対象アプリ・ポリシーの[Assignments]を編集し、対象グループの[Edit filter]でInclude/Excludeと作成したフィルターを選び、保存します。

名前には種類・OS・用途を入れると、後から利用先を確認しやすくなります。例はMDM-Windows-OS-Pilotです。フィルターはテナントあたり最大200個、1フィルター最大3,072文字なので、似た条件を増やす前に既存の用途を確認します。

operatingSystemVersion自体は一般提供済みです。一方、別のプレビュープロパティをルールに含む場合など、Preview devicesを使えない条件はあります。プレビューできることだけで本番適用の正しさを判断せず、小規模な割り当て後の評価も確認してください。

適用されない場合はFilter evaluationを確認する

管理対象デバイスでは[Devices]→[All Devices]→対象デバイス→[Filter evaluation]を開きます。評価された時刻、Match/No match、Include/Exclude、評価に使われたプロパティを確認してください。結果が管理センターに出るまで、評価時点から最大30分かかる場合があります。

表示されるフィルター名・説明・ルールは現在の設定です。過去の評価時点のルールをそのまま保存した表示ではないため、[Evaluation time]と[Last modified]、変更前に残したルールを照合します。詳細はフィルター評価レポートとトラブルシューティングにあります。

確認場面注意点
アプリのDevice install statusAvailable配布のアプリは同レポートに出ない。端末側のFilter evaluationを確認する。
Availableの評価を確認する利用者がCompany Portalアプリ/Webのアプリ一覧を開くことで評価結果が生成される。
Android/AOSP/iOSのAvailableで新OS版条件を使うoperatingSystemVersionの評価が不確定になる既知の注意が公式資料に残る。一般提供と区別して確認する。
条件付きアクセスの結果を調べるFilter evaluationの対象外。Entraのサインインログを確認する。

管理対象アプリはアプリ保護・アプリ構成の状態レポートも確認します。フィルターが選択肢に出ないときは、Managed devices/Managed apps、Platform、対応ワークロードが一致しているかを先に見直してください。

OS以外の既存条件と削除の注意

メーカー・所有形態などの既存条件は、新しいOSバージョン条件とは別に評価値を確認します。たとえばapp.appVersionでアプリの版を絞る運用では、実際の配信版と条件が一致しているか、アプリ担当者と確認してください。

Managed appsのdeviceManagementTypeには、従来のManagedやAndroid Enterpriseから細分化した管理タイプへの対応付けもあります。OS版の一般提供とは別の変更なので、同じ置換として処理せず、プロパティリファレンスの値・Entra登録などの条件を確認します。

古いフィルターは、使用中の割り当てから外すまで削除できません。ただし、Includeフィルターを外すと対象が広がる場合があります。先に代替の割り当てを検証し、不要になった参照を整理してから削除してください。

移行前後のチェックリスト

  • 既存osVersionのルール、利用先、グループ、Include/Excludeを記録した。
  • 文字列の部分一致をバージョン値の大小比較と同一視していない。
  • 例示ビルドを採用基準にせず、自組織の対象OSと境界を決めた。
  • 種類・プラットフォーム・ワークロードが対応している。
  • Preview devicesと小規模割り当ての評価を確認した。
  • 対象外にすべき端末と、対象にすべき端末の両方を確認した。
  • 切り替え後の適用状態と、戻すための旧条件・割り当てを確認した。

よくある質問

一般提供になったので、既存osVersionはすぐ停止しますか?

既存フィルターは引き続き動作します。新規作成に使えないことと、既存が停止することを分けて考え、利用先を把握して段階的に移行してください。

osVersionをoperatingSystemVersionへ文字列置換すれば移行できますか?

できるとは限りません。旧条件の部分一致、新条件のバージョン比較、モードを確認し、対象端末が意図どおりになるか評価する必要があります。

この記事を書いた人

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

コメント

コメントする

目次