Azure Virtual Desktop の Windows Enterprise multi-session を Microsoft Intune で管理している、またはこれから管理したい管理者が最初に押さえるべき結論は、Intune 管理は実務利用できる段階にある一方で、通常の Windows 端末と同じ感覚でポリシーやアプリを割り当てると「未適用」「Not applicable」「登録失敗」が起きやすいという点です。
特に重要なのは、デバイス向け設定とユーザー向け設定の割り当て先を混同しないこと、設定カタログで Windows Enterprise multi-session 対応項目だけを選ぶこと、アプリは原則としてシステムコンテキストでデバイスに必須配布することです。Microsoft の公式情報では、Azure Virtual Desktop multi-session with Microsoft Intune は一般提供されており、Windows Enterprise multi-session のリモートデスクトップを Intune 管理センターから管理できます。(Microsoft Learn)
Azure Virtual Desktop multi-session with Microsoft Intune の更新ポイント
Azure Virtual Desktop multi-session with Microsoft Intune は、Azure Virtual Desktop 上の Windows Enterprise multi-session VM を Intune で管理するための機能です。従来の単一ユーザー向け Windows 端末管理とは異なり、1台のセッションホストに複数ユーザーが同時接続する前提で設計する必要があります。
今回確認すべきポイントは、単に「Intune で AVD を管理できる」という話ではありません。実務上は、次のような運用判断に影響します。
| 確認項目 | 管理者が見るべきポイント |
|---|---|
| 対象環境 | Azure Virtual Desktop の Windows Enterprise multi-session VM が対象 |
| 管理方法 | Intune 管理センターで構成プロファイル、コンプライアンスポリシー、アプリ、スクリプトなどを管理 |
| 割り当て単位 | デバイスベース構成はデバイスへ、ユーザーベース構成はユーザーへ割り当てる |
| 注意点 | 非対応テンプレートやユーザーコンテキストアプリは適用されない場合がある |
| 移行期限 | 公式情報上、この機能に伴う強制移行期限や廃止期限は明記されていない |
Microsoft の公式情報では、Windows Enterprise multi-session は Azure Virtual Desktop 専用の Remote Desktop Session Host とされ、複数の同時ユーザーセッション、通常の Windows に近い操作感、既存のユーザー単位 Microsoft 365 ライセンス活用といった利点が示されています。(Microsoft Learn)
影響範囲：対象になる環境と対象外になる環境
影響を受けるのは、Azure Virtual Desktop の pooled host pool で Windows Enterprise multi-session を利用し、Microsoft Intune による構成管理・セキュリティ管理・アプリ配布を行う組織です。
特に、次のような環境では確認が必要です。
- AVD セッションホストを Microsoft Entra joined または Microsoft Entra hybrid joined で運用している
- グループポリシーや Configuration Manager から Intune 管理へ段階的に寄せたい
- Windows 10 / Windows 11 Enterprise multi-session の構成を標準化したい
- AVD のセキュリティ基準、コンプライアンス、条件付きアクセスを強化したい
- ゴールデンイメージやセッションホスト再展開の運用を整備している
一方で、Citrix DaaS や VMware Horizon Cloud の multi-session 環境は、Intune による Azure Virtual Desktop multi-session 管理の対象として扱えません。Microsoft 公式情報でも、Citrix DaaS と VMware Horizon Cloud では Azure Virtual Desktop multi-session 向け Intune サポートは現在利用できないとされています。(Microsoft Learn)
前提条件：Intune 管理を始める前に確認すること
Azure Virtual Desktop multi-session を Intune で管理するには、対象 VM がいくつかの条件を満たしている必要があります。ここを確認せずにポリシーを作ると、設定が配布されない原因の切り分けに時間を取られます。
公式情報で示されている主な前提条件は、Azure Resource Manager 経由で展開された pooled host pool のリモートデスクトップであること、Intune と同じテナント配下にあること、Azure Virtual Desktop エージェントが 1.0.2944.1400 以降であること、Microsoft Entra hybrid joined または Microsoft Entra joined として Intune に登録されていることです。(Microsoft Learn)
| 前提条件 | 確認内容 | 実務上の注意 |
|---|---|---|
| ホストプール | pooled host pool として展開されているか | 個別に作成した VM を後から寄せるだけでは想定どおり管理できない場合がある |
| テナント | Intune と AVD が同じテナントか | クロステナント前提の設計は避ける |
| AVD エージェント | 1.0.2944.1400 以降か | 古いイメージを使い回している環境では要確認 |
| 参加状態 | Microsoft Entra joined または hybrid joined か | Microsoft Entra Domain Services 参加のセッションホストは Intune 管理できない |
| Intune 登録 | 自動登録や Azure portal の登録設定が正しいか | hybrid joined ではデバイス資格情報での登録が重要 |
| ライセンス | AVD と Intune の適切なライセンスがあるか | ユーザーまたはデバイスが Intune サービスの恩恵を受ける場合はライセンス確認が必要 |
Microsoft は、Azure Virtual Desktop セッションホストの OS 管理には Microsoft Intune の利用を推奨しており、Windows 10 / Windows 11 multi-session ホストではデバイスベース構成とユーザーベース構成の両方をサポートすると説明しています。(Microsoft Learn)
設定変更で最も重要なのは「スコープ」と「割り当て先」
Azure Virtual Desktop multi-session with Microsoft Intune で失敗しやすいのは、設定そのものよりも、スコープと割り当て先の不一致です。
公式情報では、デバイスベース構成をユーザーに割り当てたり、ユーザーベース構成をデバイスに割り当てたりすると、Error または Not applicable として報告されると説明されています。つまり、通常の Windows クライアント管理で使っていた既存ポリシーを、そのまま AVD multi-session に流用するのは危険です。(Microsoft Learn)
デバイス向けに割り当てるべきもの
デバイス向けに割り当てるべき代表例は、OS 設定、端末全体のセキュリティ設定、システムコンテキストで動くアプリ、デバイス証明書、品質更新の管理設定などです。
複数ユーザーが同じセッションホストに接続するため、端末全体に一貫して適用したい設定はデバイスグループへ割り当てます。たとえば、Defender 関連設定、ファイアウォール、更新のアクティブ時間、デバイス証明書などは、個々の利用者ではなくホスト単位で管理するほうが運用しやすくなります。
ユーザー向けに割り当てられるもの
ユーザー構成については、Settings catalog のユーザースコープポリシー、ユーザー証明書、ユーザーコンテキストで実行する PowerShell スクリプトをユーザーグループに割り当てられます。(Microsoft Learn)
ただし、ユーザー向けにできるからといって、すべての個人設定を Intune へ寄せるべきとは限りません。AVD では FSLogix などのプロファイル管理、アプリケーション側の設定、既存のグループポリシーとの役割分担も残ります。ユーザー体験に関わる設定は、「サインイン時に毎回必要な設定か」「プロファイルに保持すべき設定か」「セッションホスト全体で固定すべき設定か」を分けて設計することが大切です。
構成プロファイルは Settings catalog を中心に設計する
Azure Virtual Desktop multi-session の構成プロファイルでは、Settings catalog を使い、OS edition のフィルターで Enterprise multi-session を指定するのが基本です。Microsoft 公式手順でも、Intune 管理センターで Windows 10 and later を選び、Settings catalog を使って、OS edition が Enterprise multi-session の設定に絞り込む流れが示されています。(Microsoft Learn)
実務では、次の順番で作成すると失敗を減らせます。
| 手順 | 作業 | 確認ポイント |
|---|---|---|
| 1 | Intune 管理センターで Windows 構成ポリシーを作成 | Platform は Windows 10 and later |
| 2 | Profile type で Settings catalog を選択 | 既存テンプレートの流用を避ける |
| 3 | Settings picker で OS edition フィルターを追加 | Enterprise multi-session に絞り込む |
| 4 | 表示された対応設定だけを選択 | 非対応項目を無理に入れない |
| 5 | デバイスグループまたはユーザーグループへ割り当て | スコープと割り当て先を一致させる |
| 6 | レポートで Error / Not applicable を確認 | 未対応設定と割り当てミスを切り分ける |
対応していないテンプレートは multi-session デバイスに配信されず、レポートでは Not applicable と表示されます。公式情報では、証明書、SCEP、PKCS、VPN の一部テンプレートなど、サポートされるテンプレートが限定されていることも明記されています。(Microsoft Learn)
アプリ配布は「システムコンテキスト」「デバイス必須配布」が基本
Azure Virtual Desktop multi-session へのアプリ展開で最も避けたいのは、ユーザーコンテキストのアプリや Available 配布を前提に設計することです。
公式情報では、Windows アプリは Windows Enterprise multi-session に展開できますが、すべてのアプリはシステムまたはデバイスコンテキストでインストールするよう構成し、デバイスを対象にする必要があります。また、割り当ての意図は Required または Uninstall が必要で、Available apps は multi-session VM ではサポートされません。(Microsoft Learn)
たとえば、社内標準ブラウザ拡張、業務アプリ、セキュリティエージェント、印刷関連ツールなどは、ユーザーがポータルから任意導入するのではなく、セッションホストに対して必須配布する設計が向いています。
注意したいのは、Win32 アプリの依存関係です。システムコンテキストでインストールするアプリが、ユーザーコンテキストのアプリに依存している場合、multi-session VM ではインストールされません。既存の Intune アプリ定義を流用する場合は、依存関係と supersedence の設定を必ず見直してください。(Microsoft Learn)
コンプライアンスと条件付きアクセスの確認ポイント
Azure Virtual Desktop multi-session でも、Intune のコンプライアンスポリシーと Microsoft Entra の条件付きアクセスを組み合わせて、セッションホストの状態をアクセス制御に反映できます。
ただし、コンプライアンス設定は新規に作成し、multi-session VM を含むデバイスグループに割り当てる必要があります。公式情報では、ユーザーを対象にしたコンプライアンス構成はサポートされないと説明されています。(Microsoft Learn)
対応するコンプライアンスポリシーには、OS バージョン、パスワード関連、Microsoft Defender Antimalware、ファイアウォール、ウイルス対策、スパイウェア対策、リアルタイム保護、Defender ATP リスクスコアなどがあります。一方で、その他のポリシーは Not applicable として報告されます。(Microsoft Learn)
実務では、最初から厳しすぎる条件付きアクセスを本番適用するのではなく、レポート専用または限定グループで検証し、以下を確認してから展開するのが安全です。
- 対象セッションホストが Intune に正しく登録されているか
- コンプライアンス状態が期待どおり評価されるか
- Defender やファイアウォール状態が誤判定されないか
- 非準拠時にユーザーが業務停止しない代替手段があるか
- AVD のサインイン経路と条件付きアクセスの条件が矛盾しないか
Windows Update 管理は Update rings ではなく Settings catalog を確認する
Azure Virtual Desktop multi-session の更新管理では、通常の Windows 端末と同じ Update rings for Windows をそのまま使えるとは限りません。
公式情報では、Windows Enterprise multi-session VM の品質更新に関する Windows Update 設定は Settings catalog で管理でき、Enterprise multi-session のフィルターを設定したうえで Windows Update for Business カテゴリを確認すると説明されています。対象として、アクティブ時間、品質更新の延期日数、品質更新の期限、猶予期間などが挙げられています。(Microsoft Learn)
トラブルシューティング項目でも、Windows update rings policies は現在サポートされず、品質更新は Settings catalog の対応設定で管理するとされています。(Microsoft Learn)
AVD では、更新そのものよりも「再起動タイミング」がユーザー影響に直結します。稼働中のセッションを持つホストで強制再起動が発生すると、切断や作業損失につながります。更新ポリシーを作る際は、ホストプールのドレインモード、メンテナンス時間、スケールプラン、イメージ更新方式と合わせて設計しましょう。
リモートアクションとライフサイクル管理の注意点
Intune に登録された Windows 端末では、ワイプ、リモートロック、Autopilot reset などのリモートアクションを使う場面があります。しかし、Windows Enterprise multi-session VM では、すべてのリモートアクションが使えるわけではありません。
公式情報では、Windows Autopilot reset、BitLocker key rotation、Fresh Start、Remote lock、Reset password、Wipe は Windows Enterprise multi-session VM ではサポートされず、UI ではグレーアウトされ、Graph でも無効になるとされています。(Microsoft Learn)
また、Azure 側で VM を削除しても、Intune 管理センターに孤立したデバイスレコードが残る可能性があります。公式情報では、AVD マシンは 30 日後に自動削除され、60 日後に完全に削除されると説明されています。(Microsoft Learn)
そのため、AVD の再展開やスケールインを頻繁に行う環境では、Intune 側のデバイス一覧を定期的に確認し、不要なレコードが運用判断を妨げないようにする必要があります。
移行期限はあるのか：今すぐやるべきこと
今回の公式情報から読み取れる範囲では、Azure Virtual Desktop multi-session with Microsoft Intune に関して、特定日までに移行しなければならないという強制的な移行期限は示されていません。
ただし、移行期限がないから後回しでよい、という意味ではありません。AVD multi-session は複数ユーザーが共用する基盤であり、構成のばらつきやセキュリティ設定の抜けが、ユーザー単位ではなくホストプール全体の問題になります。
今すぐ着手すべきなのは、全面移行ではなく棚卸しです。既存の GPO、Configuration Manager、手作業設定、イメージ内設定、Intune ポリシーを並べ、どの管理面を Intune に寄せるかを決めることが現実的です。
| 項目 | すぐ確認すること | 判断基準 |
|---|---|---|
| 既存ポリシー | GPO と Intune の重複 | 同じ設定を複数経路で管理していないか |
| アプリ配布 | ユーザーコンテキストの有無 | AVD ではシステムコンテキスト配布へ寄せる |
| 登録方式 | hybrid joined / Entra joined の整合性 | デバイス資格情報や Azure portal 登録設定を確認 |
| 更新管理 | Update rings 依存 | Settings catalog の対応項目へ見直す |
| コンプライアンス | ユーザー対象になっていないか | multi-session VM のデバイスグループへ割り当てる |
| イメージ運用 | 登録済み VM のクローン有無 | Intune 登録済み状態を含むイメージ複製は避ける |
よくある失敗と回避策
登録済み VM をクローンしてしまう
Intune は、すでに登録済みのコンピューターをクローンしたイメージの使用をサポートしていません。物理デバイスだけでなく、Azure Virtual Desktop のような仮想デバイスも対象です。デバイス登録や ID トークンが複製されると、Intune の登録や同期に失敗します。(Microsoft Learn)
ゴールデンイメージを作る場合は、Intune 登録前の状態をベースにし、展開後に各セッションホストを個別に登録する設計にしましょう。
Microsoft Entra Domain Services 参加で Intune 管理しようとする
公式情報では、セッションホストを Microsoft Entra Domain Services に参加させている場合、Intune で管理できないとされています。(Microsoft Learn)
既存環境で Entra Domain Services を利用している場合は、Intune 管理を前提にした設計と矛盾しないか、事前に認証・参加方式を見直す必要があります。
非対応テンプレートを割り当てて Not applicable になる
構成プロファイルで対応していないテンプレートを使うと、ポリシーが適用されず Not applicable になります。特に、通常の Windows クライアント向けに作ったテンプレート型プロファイルを流用している環境では注意が必要です。
AVD multi-session 向けには、Settings catalog で Enterprise multi-session フィルターを使い、表示された対応設定を選ぶ運用に寄せるのが安全です。
Web アプリや Available 配布を前提にしてしまう
Web アプリは既定でユーザーコンテキストに適用されるため、multi-session VM には適用されません。また、Available apps deployment intent もサポートされません。(Microsoft Learn)
ユーザーが自分で必要なアプリを選んで入れる運用ではなく、ホストプール単位で必要なアプリを定義し、Required 配布で標準化する設計に切り替えましょう。
管理者が取るべき次のアクション
Azure Virtual Desktop multi-session with Microsoft Intune は、AVD の構成管理をクラウド側に集約する有力な選択肢です。ただし、成功の鍵は「Intune で何でも管理する」ことではなく、multi-session の制約を理解したうえで、対象・スコープ・割り当て先を正しく分けることです。
まずは、本番環境へ一括適用する前に、検証用ホストプールを用意し、次の順序で確認してください。
- 対象 VM が前提条件を満たしているか確認する
- Enterprise multi-session フィルターを使って Settings catalog の対応項目を洗い出す
- デバイス向け設定、ユーザー向け設定、アプリ配布を分けて設計する
- コンプライアンスポリシーは multi-session VM のデバイスグループへ割り当てる
- Windows Update は Settings catalog の対応設定で管理する
- Error / Not applicable のレポートを見て、非対応設定や割り当てミスを修正する
AVD multi-session は、通常の Windows 端末管理と似ているようで、運用上の前提が大きく異なります。既存の Intune ポリシーをそのまま流用するのではなく、ホストプール単位で標準化する設定、ユーザー単位で柔軟に変える設定、イメージに含める設定を分けることが、安定した運用への近道です。
コメント