MENU

AVD Windows 11 マルチセッションをIntune管理するベストプラクティス｜重複デバイスを出さない設計と運用

Azure

Azure Virtual Desktop（AVD）の Windows 11 Enterprise マルチセッションを Intune で管理しようとすると、「マスターを Intune 登録していいの？」「再展開で重複デバイスが量産されない？」といった不安がつきまといます。本記事では、物理 PC を ConfigMgr＋Intune で共同管理している環境を前提に、AVD マルチセッション（プール）を“重複デバイスなし＆初回からポリシー適用済み”で運用するための実践的なベストプラクティスをまとめます。

目次

シナリオの整理：どんな環境を想定しているか

前提として、以下のような環境を想定します。

  • 既存の物理 Windows 11 PC は ConfigMgr（SCCM）＋Intune の共同管理（Co-management）。
  • これに追加で、Azure Virtual Desktop の Windows 11 Enterprise マルチセッション（プール型）を展開したい。
  • マスターイメージは Azure Compute Gallery（ACG）で管理。
  • AVD セッションホストは Intune 管理下に置き、初回サインイン前からセキュリティ ポリシーを適用したい。

ここで悩ましいのが次のポイントです。

  • マスターイメージは Intune 登録してよいのか？
  • 新規セッションホストはどう Intune に登録させるのが正解か？
  • イメージ更新によるホスト入れ替え時に、ホスト名を再利用して良いのか？
  • Intune／Entra ID（旧 Azure AD）側の古いデバイス オブジェクトはどう掃除するか？
  • Windows 11 Enterprise マルチセッション特有の制限と、物理端末用ポリシーの流用可否。

結論から言えば、「マスターは絶対に Intune 登録しない」「ホストは展開時に個別 Intune 登録」「クリーンアップを自動化」という 3 本柱を徹底すれば、重複デバイスのない健全な運用が実現できます。

全体アーキテクチャと基本方針

まずは、AVD マルチセッション × Intune の全体イメージを整理します。

  • マスターイメージ層：Windows 11 Enterprise multi-session のゴールデンイメージ（ACG）。ここは Intune 非登録が大前提。
  • セッションホスト層：ホストプールにぶら下がる VM 群。展開時に Entra Join／ハイブリッド Join ＋ Intune 登録を行う。
  • 管理層：Intune（＋必要なら ConfigMgr）と GPO による構成管理。
  • アクセス制御層：Azure AD 条件付きアクセス（CA）で「接続元クライアントが準拠デバイスであること」を必須にする。

Windows Enterprise multi-session は、通常の Windows Enterprise とは別の OS エディションとして扱われ、ProductType=3（サーバー系と同じ）として報告されます。 そのため、Intune の適用可能なポリシーやテンプレートに制限がある点を前提に設計する必要があります。

項目物理 Windows 11 PCAVD W11 Enterprise multi-session
ユーザー数1 台 1 ユーザー（想定）1 台 複数ユーザー同時利用
OS エディションWindows 11 EnterpriseWindows 11 Enterprise multi-session
Intune 登録方法Autopilot / Co-management / 手動などAVD 展開時の Entra Join / Hybrid Join ＋ MDM 自動登録
ポリシー適用デバイス／ユーザー両方フルサポート設定カタログ＋一部テンプレートのみ。
ユーザー設定は一部サポートだが制限あり
Autopilot / ESP利用可非対応（OOBE 登録不可）
Azure AD DS 参加特殊ケースAzure AD DS に参加したセッションホストは
Intune では管理不可

マスターイメージ（ゴールデン）のベストプラクティス

なぜ「マスターを Intune 登録してはいけない」のか

Microsoft の公式ドキュメントでは、Intune にすでに登録された PC／VM をクローンしたイメージの利用はサポートされず、登録・同期エラーや重複デバイスの原因になると明記されています。

AVD セッションホストはイメージから大量展開されるため、マスターを Intune 登録したままキャプチャすると、以下の問題がほぼ確実に発生します。

  • 同一 Intune デバイス ID／証明書が複製され、登録が失敗もしくは上書きされる。
  • Entra ID と Intune の両方で「どれが本物か分からない」状態のオブジェクトが乱立する。
  • Defender for Endpoint、証明書、SCEP なども不整合を起こす可能性。

したがって、マスターイメージは絶対に Intune に登録しない、というのが唯一の正解です。これは Microsoft Q&A でも MVP から繰り返し強調されています。

マスターイメージ作成手順（推奨フロー）

典型的なゴールデンイメージの作成フローは次のとおりです。

  1. Azure 上に Windows 11 Enterprise multi-session VM を作成。
  2. 必要な共通アプリ（Office/Teams 最適化、FSLogix、監視エージェントなど）をインストール。
  3. 構成が完了したら、Entra 参加・Intune 登録・ConfigMgr クライアントをすべて解除。
    • コマンド例： dsregcmd /leave
    • 「設定 > アカウント > 職場または学校にアクセスする」からアカウント解除。
    • レジストリ／タスクスケジューラなどの MDM 痕跡を削除（後述）。
  4. BitLocker を無効化（Sysprep 推奨設定）。
  5. Sysprep /generalize /oobe /shutdown を実行。
  6. Azure ポータルから VM をキャプチャし、Azure Compute Gallery（ACG）にイメージとして保存。
  7. 元の VM は削除（または検証環境に移動）し、本番展開には使用しない。

MDM 痕跡のクリーンアップ例

マスターイメージ上の Intune 痕跡は、スクリプト化して確実に削除しておくと安全です。例えば次のような PowerShell スクリプトを “最終クリーンアップ” として使うイメージです（例示であり、環境に合わせてテスト必須）。

# Entra / Intune からの離脱
dsregcmd /leave

# MDM Enrollment レジストリの削除例
Remove-Item 'HKLM:\SOFTWARE\Microsoft\Enrollments' -Recurse -Force -ErrorAction SilentlyContinue
Remove-Item 'HKLM:\SOFTWARE\Microsoft\EnrollmentsEx' -Recurse -Force -ErrorAction SilentlyContinue

# スケジュールタスクの無効化例（Intune MDM 関連）
Get-ScheduledTask | Where-Object {$_.TaskName -like '*MDM*'} |
  Disable-ScheduledTask -ErrorAction SilentlyContinue

ポイントは、「このイメージから起動した VM が、Intune 登録されている痕跡を一切持たない」状態にすることです。

やってはいけない例正しいやり方
マスターを Entra Join＋Intune 登録したまま Sysprepdsregcmd /leave／MDM 痕跡削除後に Sysprep & キャプチャ
ConfigMgr クライアントをインストールしたままキャプチャ基本はインストールせず、必要なら展開後に構成
マスター VM をそのまま本番ホストとして使い続けるマスターは検証専用。ホストは常に ACG から新規デプロイ

セッションホストの Intune 登録パターン

AVD セッションホストを Intune に登録する方法は大きく分けて 2 パターンです。

  • Entra Join（Azure AD Join）＋ Intune 登録
  • ハイブリッド Join（AD 参加＋Entra Hybrid）＋ Intune 自動登録 GPO

パターン1：Entra Join ＋「Intune に VM を登録」を有効化

Azure ポータルから AVD ホストプールに VM を追加する際、「Microsoft Entra 参加」と同時に 「Intune に VM を登録（Enroll VM with Intune）」オプションを有効化できます。

このチェックを有効にすると、AVD ホストは次の流れで自動的に Intune 登録されます。

  1. VM 展開後、AVD エージェントが起動。
  2. Microsoft Entra Join が実行され、デバイス オブジェクトが Entra ID に作成される。
  3. 同じ流れで MDM 自動登録（Intune）が実行される。
  4. デバイスが指定された Entra グループに動的に追加され、Intune ポリシー／アプリが配布される。

この方式のメリットは、AVD 展開と Intune 登録が 100% 自動化される点です。ホスト作成直後から Defender、ファイアウォール、FSLogix 設定などを即座に適用できます。

観点Entra Join ＋ Intune 登録
オンプレ AD 必要性不要（クラウド専用構成に最適）
Intune 登録AVD 展開時に自動登録（ポータル設定のみ）
ConfigMgr との Co-management通常は利用しない（完全クラウド管理）
構成のシンプルさ最もシンプル。新規環境では一押し

パターン2：ハイブリッド Join＋MDM 自動登録 GPO

既存の物理 PC 同様、オンプレ AD＋Entra Hybrid Join＋Intune の構成を AVD ホストにも適用したい場合は、次の構成を取ります。

  1. AVD セッションホスト VM を オンプレ AD ドメインに参加させる（もしくは Azure 上の AD DS）。
  2. AAD Connect により Hybrid Join を有効にしておく。
  3. セッションホストを格納する 専用 OU を作成。
  4. その OU に対して以下の GPO をリンク。
    • コンピューターの構成 > 管理用テンプレート > Windows コンポーネント > MDM > 既定の Azure AD 資格情報を使用した自動 MDM 登録を有効にする
    • 「利用する資格情報の種類」＝デバイス／コンピューター資格情報（ユーザー資格情報では不可）
  5. 必要に応じて ConfigMgr クライアントをインストールし、Co-management を構成。

注意点は、自動登録 GPO がユーザー資格情報になっていると、マルチセッション VM の Intune 登録が失敗する点です。公式ドキュメントでも「Windows Enterprise multi-session VM はデバイス資格情報で登録する必要がある」と明記されています。

観点ハイブリッド Join＋MDM 自動登録
オンプレ AD 必要性必須
登録方式Hybrid Join ＋ MDM 自動登録 GPO／Co-management
物理 PC との整合ConfigMgr／GPO を共通利用できる
構成の複雑さやや複雑だが、既存オンプレ主導の組織には適合

Intune ポリシーとアプリ配布の設計ポイント

設定カタログ＋OS エディション フィルターを必ず使う

Windows Enterprise multi-session は、Intune 上で 専用の OS エディションとして扱われます。そのため、構成プロファイルは 設定カタログ＋「OS エディション＝Enterprise multi-session」フィルターで作成するのが推奨です。

  1. Intune 管理センターで デバイス > Windows > 構成プロファイル > 新規作成。
  2. プラットフォーム：Windows 10 以降、プロファイルの種類：設定カタログ を選択。
  3. 設定の追加で「フィルターを追加」をクリック。
  4. フィルター条件を以下のように設定：
    • キー：OS エディション
    • 演算子：==
    • 値：Enterprise multi-session
  5. 必要なカテゴリ（Defender、Windows Update for Business、FSLogix 関連など）を選択して設定を構成。
  6. 割り当ては デバイス グループ（AVD ホスト用グループ）を指定。

テンプレートベースのプロファイルは、証明書（Trusted/SCEP/PKCS）と VPN（デバイス トンネル）のみが multi-session でサポートされ、それ以外のテンプレートは「不適用」となります。

デバイススコープ中心で設計する理由

最新のドキュメントでは、Windows Enterprise multi-session に対してもユーザー スコープの設定カタログやユーザーコンテキスト PowerShell スクリプトが サポートされることが明示されています。

とはいえ、プール型マルチセッション環境では「1 台に多数ユーザー」「ユーザーが複数ホストをまたいで利用」という特性から、次の観点で デバイス スコープを主役にする方が運用が安定します。

  • どのホストに接続しても 同じセキュリティ設定・アプリを保証する必要がある。
  • ユーザーターゲットのポリシーは、トラブルシュート時に「どのホストで適用されたか」を追いづらい。
  • ユーザーコンテキストのアプリ／スクリプトは FSLogix のプロファイル ローミングと絡むと複雑化しやすい。

そのため、本記事では以下のスタンスを推奨します。

  • 基盤ポリシー（Defender、ファイアウォール、WUfB、FSLogix、RDP 設定など）はデバイス スコープのみで構成。
  • ユーザー スコープは、どうしても必要な 最小限（例：ユーザー証明書、特定アプリのユーザー設定など）に留める。

アプリ配布の制約とベストプラクティス

アプリ配布に関するマルチセッション特有の制約は非常に重要です。

  • すべてのアプリは「システム／デバイス コンテキスト」でインストールする必要がある。
  • ターゲットは デバイス グループ。ユーザー グループ対象のアプリは適用されない。
  • Assignment Intent は Required（必須） または Uninstall のみ。Available（ユーザーからインストール）」は非サポート。
  • Web アプリは既定でユーザー コンテキストのため、multi-session VM には適用されない。
  • システムコンテキスト アプリがユーザーコンテキスト アプリに依存している場合、そのアプリはインストールされない。
アプリ種別サポート状況注意点
Win32 アプリ（.intunewin）サポートシステムコンテキスト＋Required／Uninstall のみ
ストア アプリ（MSI 変換含む）限定的にサポート同じくシステムコンテキスト＆デバイス割り当て必須
Web アプリ非サポートユーザーコンテキスト前提のため multi-session VM には適用されない
Azure Virtual Desktop RemoteApp / MSIX app attachIntune 経由では 非サポートAVD 側の機能として別途構成

AVD マルチセッション向けに必須となるアプリの例：

  • Defender for Endpoint センサー
  • ログ／監視エージェント（Log Analytics、サードパーティ監視など）
  • バックアップ／DR エージェント
  • AVD 最適化ツール（Teams 最適化、マルチメディアリダイレクト等）

FSLogix とトークンローミングの注意点

FSLogix のプロファイル コンテナを利用する場合、Intune の登録トークンや認証トークンをユーザープロファイルと一緒にローミングさせないことが重要です。Intune 側は「トークンローミングはサポートしない」と明言しており、トークンが複数ホストに複製されると登録やポリシー適用が不安定になります。

FSLogix の RoamIdentity 設定を確認し、トークンがローミングしない構成になっているかをチェックしておきましょう。

コンプライアンスと条件付きアクセス（CA）の設計

マルチセッション VM に対するコンプライアンス ポリシー

Windows Enterprise multi-session では、コンプライアンス ポリシーも一部の設定に限定されています。代表的な対応項目は以下です。

  • OS バージョン（最小／最大／有効なビルド）
  • パスワード（有無、長さ、複雑さ、有効期限など）
  • Microsoft Defender 関連
    • リアルタイム保護、有効／無効
    • アンチウイルス／アンチスパイウェア／ファイアウォール
    • Defender ATP リスクレベルなど

重要なのは、マルチセッション用に別のコンプライアンス ポリシーを作成し、AVD ホストのデバイス グループに割り当てることです。ユーザー対象のコンプライアンス構成は multi-session VM ではサポートされません。

条件付きアクセス：評価されるのは「接続元クライアント」

AVD へのアクセス制御は、Azure AD 条件付きアクセス ポリシーで「Azure Virtual Desktop」クラウド アプリを対象に構成します。

ここで重要なポイント：

  • CA が「準拠デバイス必須」などの条件を評価するとき、評価対象は AVD セッションホストではなく、接続元のクライアント端末です。
  • セッションホスト側のコンプライアンス（Intune 管理）は、AVD 内部のセキュリティ制御（ポリシー／アプリ／スクリプト）に活用します。

典型的な CA ポリシー例：

  • 対象クラウドアプリ：Azure Virtual Desktop
  • ユーザー／グループ：AVD 利用を許可したいユーザー／グループ
  • 条件：
    • クライアントアプリ：モダン認証クライアント（Azure Virtual Desktop クライアント）
    • デバイプラットフォーム：Windows／macOS／iOS など必要に応じて
  • アクセス制御：
    • 準拠デバイスを要求
    • 必要に応じて MFA を要求

この構成により、「会社管理の準拠端末からのみ AVD に接続可能」というゼロトラスト的な要件を満たせます。

再展開（イメージ更新）時の重複デバイス対策

なぜ重複が発生するのか

AVD では、イメージ更新のたびに「既存ホストを削除して新ホストをデプロイ」という運用になるため、正しくクリーンアップしないと次のような重複が生じます。

  • 同じホスト名の Intune デバイス オブジェクトが複数存在。
  • Entra ID 側にも同名のデバイス オブジェクトが残存。
  • Defender for Endpoint、資産管理、CMDB 等にも古いレコードが残る。

さらに、Intune は「すでに登録済みの PC のクローン」をサポートしないため、マスターを誤って登録したままキャプチャすると、そもそも新ホストの登録が安定しません。

推奨するクリーンアップ フロー

イメージ更新に伴うホスト入れ替え（スケールイン／再デプロイ）時には、次の手順を標準化しておくと安全です。

  1. AVD 側でセッションホストを Drain モードにし、ユーザー接続を停止。
  2. そのホストに対応する Intune の管理デバイス オブジェクトを削除。
    • Intune 管理センター（GUI）から手動削除、または Graph API で自動化。
  3. Entra ID のデバイス オブジェクトも削除。
  4. 必要なら ConfigMgr／他の資産管理ツールからも削除。
  5. 最後に Azure VM を削除。

Graph API 例（イメージ）：

# Intune managedDevices から対象ホストを削除する REST 呼び出し例
DELETE https://graph.microsoft.com/beta/deviceManagement/managedDevices/{managedDeviceId}

# Entra ID デバイスオブジェクト削除
DELETE https://graph.microsoft.com/v1.0/devices/{deviceId}

これらを Azure Automation Runbook／Logic Apps／DevOps パイプラインに組み込んで、「削除ワークフローに必ず Intune／Entra の掃除を含める」のが理想です。

Intune デバイス クリーンアップ ルールは「安全網」として

Intune には「一定期間チェックインしていないデバイスを自動削除する」クリーンアップ ルールがあり、AVD マシンについては 30 日後に非アクティブ化、60 日後に完全削除される旨がドキュメントに記載されています。

しかし、これはあくまで 安全網（セーフティネット）として考えるべきで、再展開運用の主役にしてはいけません。

  • 短いサイクルでイメージ更新を行うと、クリーンアップが追いつかない。
  • ConfigMgr／Defender／CMDB など他システムのレコードは自動では消えない。

したがってベストプラクティスは：

  • 削除ワークフローでの「Intune＋Entra デバイス削除」を必須ステップにする。
  • クリーンアップ ルールは 30～60 日程度で有効化し、「漏れがあった場合の最後の砦」として活用。

ホスト名は再利用すべきか？

ホスト名の扱いは好みが分かれるポイントですが、次のルールを押さえておくとシンプルです。

  • 旧ホストの Intune／Entra オブジェクトを事前に削除できる運用なら、同じホスト名を再利用して問題なし。
  • 削除漏れが起きがちな運用（属人ワークフロー）なら、世代を示すサフィックス付きの新しい名前を付ける。
    • 例：AVD-W11-POOL-01-G01 → 再展開時 AVD-W11-POOL-01-G02

どちらを選ぶにせよ、「マスターを Intune 登録しない」「削除時に Intune／Entra のオブジェクトを先に消す」という 2 点さえ守れば、重複デバイスの多発は避けられます。

物理端末向けポリシーはどこまで流用できるか

よくある質問が「物理 PC 用に作った Intune ポリシーやアプリを、そのまま AVD マルチセッションに使い回せるか？」です。

基本スタンス：流用「できる」がおすすめは分離

多くのセキュリティ ポリシーは、物理端末／AVD 双方に共通化できます。

  • Defender Antivirus／EDR／ファイアウォール
  • ブラウザ／Edge のセキュリティ設定
  • Windows Update for Business（品質更新のリング）
  • ASR（攻撃面の削減）ポリシー、Exploit Protection 等

一方で、マルチセッション特有の制限や挙動を考慮すると、以下のいずれかのパターンを取るのが現実的です。

パターン概要メリットデメリット
1. 共通ポリシー＋OS フィルター同一プロファイルを、
OS エディション フィルターで
物理／AVD に振り分け		ポリシー数を抑えられる設定の中身が複雑になりやすい
2. 物理用と AVD 用を完全分離AVD 専用のプロファイル／アプリ／コンプライアンス／セキュリティ セットを用意影響範囲を明確にしやすく、
トラブルシュートも容易		ポリシー数は増える

実務的には、重要な基盤ポリシーは AVD 用に専用プロファイルを作成し、細かなセキュリティ設定などは OS フィルターで共通化、というハイブリッドが扱いやすい印象です。

そのまま流用してはいけないもの

特に注意が必要なものを挙げておきます。

  • Autopilot／ESP 関連のポリシーやプロファイル
    • マルチセッション VM は OOBE 登録非対応のため、Autopilot／ESP は利用できません。
  • ユーザー割り当て前提のアプリ・設定
    • ユーザーコンテキストの Web アプリ、ユーザー対象の一部 MDM 設定は multi-session では適用されないか、予期せぬ動作になります。
  • リモート操作系（Wipe／Fresh Start／Autopilot Reset 等）
    • multi-session VM では、これらのリモート操作は Intune 上でグレーアウトされ利用できません。
  • Azure AD DS 参加を前提にしたポリシー
    • Entra Domain Services 参加のセッションホストは Intune で管理できないため、そもそもシナリオとして NG です。

よくある NG パターンとその回避策

NG1：マスターイメージを Intune 登録したままキャプチャ

もっとも多いトラブルの原因がこれです。

  • 症状：新しいセッションホストが Intune に登録されない／一部だけ登録される／デバイスが上書きされる。
  • 原因：クローンされた Intune 登録情報（証明書／トークン）が複数 VM で競合。
  • 対策：本記事で述べた dsregcmd /leave＋MDM 痕跡削除＋Sysprep を徹底する。

NG2：自動 MDM 登録 GPO でユーザー資格情報を使用

Hybrid Join 構成でありがちなのが、MDM 自動登録 GPO を既存 PC と同じ「ユーザー資格情報」で使い回すパターンです。

  • 症状：AVD セッションホストだけ Intune 登録に失敗する。
  • 原因：multi-session VM は デバイス資格情報での登録が必須。
  • 対策：専用 OU を切り、デバイス資格情報を指定した GPO を適用。

NG3：Azure AD DS に参加させたセッションホストを Intune 管理しようとする

Entra Domain Services（旧 Azure AD DS）に参加した VM は、Intune のサポート対象外です。公式ドキュメントにも「Entra Domain Services にリンクしたセッションホストは Intune 管理できない」と明記されています。

  • 症状：どう設定しても Intune 登録されない。
  • 対策：AVD セッションホストは オンプレ AD 参加（Hybrid） または Entra Join を利用する。

NG4：FSLogix でトークンローミングを有効にしたまま

FSLogix でユーザープロファイルをローミングさせる際、認証トークンや MDM トークンが一緒にローミングされると、複数ホスト間でトークンが競合し、Intune／認証まわりが不安定になります。

  • 対策：RoamIdentity を無効にするなど、トークンがローミングされない構成を採用。

最低限守りたいチェックリスト

チェック項目ポイント
マスターイメージは Intune 非登録かdsregcmd /status で Entra Join 状態を確認し、/leave 済みか確認。
MDM 痕跡を削除してから Sysprep しているかEnrollment レジストリ／タスク等をクリーンアップしてから ACG にキャプチャ。
AVD 展開時に Intune 登録を有効化しているか（Entra Join）Azure ポータルの「Intune に VM を登録」オプションを ON。
Hybrid Join の場合、MDM 自動登録 GPO はデバイス資格情報になっているかユーザー資格情報のままだと multi-session は登録失敗。
ポリシーは設定カタログ＋OS エディション フィルターで構成しているか「Enterprise multi-session」フィルターで multi-session 対応のみに絞り込み。
アプリはシステムコンテキスト＋デバイス割り当てになっているかWeb アプリや Available 配布は multi-session VM には適用不可。
AVD へのアクセス制御で「準拠デバイス必須」を CA で要求しているか対象アプリ：Azure Virtual Desktop。接続元端末の準拠性でゼロトラストを実現。
ホスト削除時に Intune／Entra デバイスを先に削除しているかGraph API／自動化で “台帳の掃除” をワークフローに組み込み。
Intune デバイス クリーンアップ ルールを 30～60 日で設定しているか削除漏れの安全網として有効化。

まとめ：AVD マルチセッションを“キレイな台帳”で運用するために

AVD Windows 11 Enterprise マルチセッションの Intune 管理は、ポイントさえ押さえれば「物理 PC と同じレベルのセキュリティと可視性」を実現できます。

  • マスターイメージは絶対に Intune 登録しない（dsregcmd /leave＋MDM 痕跡削除＋Sysprep＋ACG キャプチャ）。
  • セッションホストは展開時に個別 Intune 登録（Entra Join＋「Intune に VM を登録」、または Hybrid Join＋MDM 自動登録 GPO）。
  • ポリシーは設定カタログ＋Enterprise multi-session フィルターでデバイススコープ中心に設計し、ユーザー スコープは最小限にとどめる。
  • アプリはシステムコンテキスト＋Required でデバイス割り当てとし、Web アプリ／Available 配布に頼らない。
  • 削除ワークフローに Intune／Entra デバイス オブジェクト削除を組み込み、Intune のクリーンアップ ルールは安全網として利用。
  • AVD への入口は条件付きアクセスで「準拠デバイス＋MFA」を要求し、接続元クライアントをしっかり守る。

この設計をベースに運用すれば、イメージ更新やホスト入れ替えを繰り返しても、Intune／Entra ID 上のデバイス台帳が肥大化することなく、「初回からポリシー適用済み」「重複のないクリーンな管理状態」を長期的に維持できます。

Azure
Windows 11 Intune Entra ID Azure Virtual Desktop

この記事を書いた人

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

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

関連記事

コメント

コメントする

目次