Microsoft Defender for Identity センサー v2.x の前提条件でまず押さえるべき結論は、v2.x はまだ必要な場面があるが、Windows Server 2019 以降のドメイン コントローラーでは v3.x への移行・新規展開を優先して検討するという点です。特に、AD FS、AD CS、Microsoft Entra Connect がドメイン コントローラーではない別サーバーで動いている環境では、v2.x センサーが引き続き重要になります。一方で、v3.x には Defender for Endpoint や 2026年3月以降の累積更新プログラムなど追加要件があるため、単純に「新しいから置き換える」ではなく、OS、サーバー役割、ネットワーク、監査設定を確認してから進める必要があります。(Microsoft Learn)
この記事では、2026年5月18日時点の公式情報を基に、Microsoft Defender for Identity センサー v2.x の前提条件、v3.x との使い分け、管理者が確認すべき影響範囲、移行・展開時に失敗しやすいポイントを実務目線で整理します。
Microsoft Defender for Identity センサー v2.x 前提条件の要点
Microsoft Defender for Identity は、Active Directory などの ID 基盤に対する不審な操作や攻撃兆候を検出するための Microsoft Defender 製品です。センサーはドメイン コントローラーや関連する ID サーバーに展開され、イベントログ、認証通信、ディレクトリ情報などを基に検出を行います。
v2.x センサーの前提条件で重要なのは、対象サーバーが次の範囲に整理されることです。
| 確認項目 | v2.x センサーでの扱い | 管理者が取るべき判断 |
|---|---|---|
| Windows Server 2016 のドメイン コントローラー | v2.x の展開対象 | v3.x の要件を満たさないため、v2.x を前提に計画する |
| Windows Server 2019 以降のドメイン コントローラー | v2.x も対象だが、v3.x 推奨 | 新規展開・更新時は v3.x の要件を満たせるか確認する |
| ドメイン コントローラーではない AD FS サーバー | v2.x の展開対象 | v3.x ではなく v2.x を使う |
| ドメイン コントローラーではない AD CS サーバー | v2.x の展開対象 | 証明機関ロール サービスがあるサーバーを対象にする |
| ドメイン コントローラーではない Microsoft Entra Connect サーバー | v2.x の展開対象 | アクティブ サーバーとステージング サーバーの両方を確認する |
| Windows Server 2025 の v2.x センサー環境 | v2.x の展開対象 | v3.x 移行制限の有無を必ず確認する |
公式ドキュメントでは、v2.x センサーは Windows Server 2016 以降のドメイン コントローラー、およびドメイン コントローラーではない AD FS、AD CS、Microsoft Entra Connect サーバーをサポートするとされています。また、Windows Server 2019 以降のドメイン コントローラーでは v3.x センサーの展開が推奨されています。(Microsoft Learn)
つまり今回の確認ポイントは、v2.x を廃止できるかどうかではありません。実務上は、サーバーごとに「v2.x を継続すべきか」「v3.x に移行できるか」「そもそもセンサーを入れるべきサーバーか」を切り分けることが重要です。
今回の公式情報で管理者が注目すべき変更点
今回の Microsoft Defender for Identity センサー v2.x 前提条件で注目したいのは、v2.x 単体の要件だけではなく、v3.x との役割分担がより明確になっている点です。
Windows Server 2019 以降のドメイン コントローラーは v3.x 推奨
Windows Server 2019 以降のドメイン コントローラーでは、v2.x ではなく v3.x センサーの展開が推奨されています。ただし、v3.x には追加要件があります。v3.x を有効化するサーバーには Defender for Endpoint の展開、Windows Server 2019 以降、2026年3月以降の累積更新プログラム、既存の v2.x センサーが展開されていないことなどが求められます。(Microsoft Learn)
そのため、既存の v2.x 環境では次のように判断します。
| 環境 | 推奨される考え方 |
|---|---|
| Windows Server 2016 のドメイン コントローラー | v2.x を継続し、OS 更新計画を別途検討する |
| Windows Server 2019 / 2022 のドメイン コントローラー | v3.x の要件を満たせるか確認し、移行候補にする |
| AD FS / AD CS / Entra Connect が同居していない純粋なドメイン コントローラー | ポータルからの v3.x 移行候補になりやすい |
| AD FS / AD CS / Entra Connect が動作する非ドメイン コントローラー | v2.x を使う |
| Windows Server 2025 の v2.x センサー環境 | v3.x 移行制限を確認し、安易に移行しない |
v3.x 移行はすべての v2.x センサーに適用できるわけではない
Microsoft Defender ポータルから v2.x から v3.x へ移行できる機能は用意されていますが、対象には条件があります。公式情報では、移行対象サーバーは追加の ID ロールを持たないドメイン コントローラー、v2.x センサー バージョン 2.254.19112.470 以降、Windows Server 2019 以降、Defender for Endpoint 展開済み、2026年3月以降の累積更新プログラム適用済みなどの条件を満たす必要があります。(Microsoft Learn)
特に注意したいのは、AD FS、AD CS、Microsoft Entra Connect を兼ねるサーバーです。新規の v3.x 前提条件では、ドメイン コントローラー上の一部 ID ロールをサポートする説明がありますが、ポータル移行の条件では「追加の ID ロールを持たないドメイン コントローラー」が要件として示されています。展開と移行では条件が異なるため、移行画面で「Ready for migration」と表示されない場合は、OS や更新プログラムだけでなくサーバー役割も確認してください。(Microsoft Learn)
Windows Server 2025 の v2.x から v3.x 移行には制限がある
2026年5月の Microsoft Defender for Identity の更新情報では、Windows Server 2025 のドメイン コントローラーで v2.x から v3.x へ移行することは現時点でサポートされておらず、サポートされるまでは v2.x センサーを継続する旨が示されています。(Microsoft Learn)
Windows Server 2025 を導入済みの組織では、「最新 OS だから v3.x にできる」と判断しないことが重要です。移行可否は OS の新しさだけでなく、Microsoft Defender for Identity 側の既知の制限にも左右されます。
大規模環境ではセンサー数の上限変更も確認する
2026年5月の更新では、Defender for Identity が 1 ワークスペースあたり最大 1,000 センサーをサポートするようになったことも示されています。従来の 350 から引き上げられたため、大規模な複数拠点・複数フォレスト環境では、ワークスペース設計や段階展開の計画を見直す価値があります。1,000 を超える追加が必要な場合はサポートへの連絡が必要です。(Microsoft Learn)
影響範囲：確認すべきサーバーと担当チーム
Microsoft Defender for Identity センサー v2.x の前提条件は、セキュリティ担当だけで完結しません。Active Directory 管理者、ネットワーク管理者、仮想基盤担当、Microsoft 365 管理者が連携する必要があります。
| 影響を受ける範囲 | 確認すべき内容 | 主な担当 |
|---|---|---|
| ドメイン コントローラー | OS、CPU、メモリ、ディスク、監査設定、時刻同期 | AD 管理者 |
| AD FS | センサー対象がフェデレーション サーバーのみか | ID 基盤担当 |
| AD CS | 証明機関ロール サービスがあるか、オフライン CA か | PKI 担当 |
| Microsoft Entra Connect | アクティブとステージングの両方に展開しているか | Entra ID / M365 管理者 |
| プロキシ・ファイアウォール | *.atp.azure.com、TCP 443、SSL 検査、サービス タグ | ネットワーク担当 |
| 仮想基盤 | 動的メモリ、メモリ予約、VMware LSO | 仮想基盤担当 |
| 運用監視 | センサー正常性、イベント監査、移行状態 | セキュリティ運用担当 |
特に見落とされやすいのは、Microsoft Entra Connect のステージング サーバーです。公式要件では、Microsoft Entra Connect サーバーについてアクティブ サーバーとステージング サーバーの両方にセンサーをインストールする必要があるとされています。(Microsoft Learn)
v2.x センサーのライセンスと権限要件
Defender for Identity を展開するには、対象ユーザーやテナントに適切な Microsoft 365 ライセンスが必要です。公式情報では、EMS E5/A5、Microsoft 365 E5/A5/G5、Microsoft 365 E5/A5/G5/F5 Security、Microsoft 365 F5 Security + Compliance、スタンドアロン Defender for Identity ライセンスなどが対象として示されています。F5 系ライセンスでは追加の前提ライセンスが必要になる場合があります。(Microsoft Learn)
権限面では、Defender for Identity ワークスペースを作成するために Microsoft Entra ID テナントが必要です。また、セキュリティ管理者ロールを持つユーザーが必要で、監視対象ドメイン内のすべてのオブジェクトに読み取りアクセスできる Directory Service アカウントを少なくとも 1 つ使用することが推奨されています。(Microsoft Learn)
実務では、次のように確認すると漏れを減らせます。
| 確認項目 | 確認方法の例 | 注意点 |
|---|---|---|
| ライセンス | Microsoft 365 管理センターで対象ライセンスを確認 | F5 系は追加条件を見落としやすい |
| 管理者ロール | Microsoft Entra 管理センターでロールを確認 | 作業者に過剰な永続権限を付けない |
| Directory Service アカウント | 監視対象ドメイン全体を読めるか確認 | 複数フォレストでは対象範囲を明確にする |
| 変更承認 | DC へのインストール作業として申請 | 再起動や .NET Framework 導入の可能性がある |
サーバー要件：スペックだけでなく運用設定まで確認する
v2.x センサーは、Windows Server 2016 以降のドメイン コントローラーにインストールでき、最小要件として 2 コア、6GB RAM、6GB のディスク領域が必要です。ディスク領域は 10GB が推奨され、Defender for Identity のバイナリとログ領域を含めて見積もる必要があります。RODC、つまり読み取り専用ドメイン コントローラーもサポートされています。(Microsoft Learn)
ただし、要件を「最小スペック」だけで見ると失敗します。実際の運用では、次の設定が検出品質や安定性に影響します。
| 項目 | 推奨・要件 | なぜ重要か |
|---|---|---|
| 電源オプション | 高パフォーマンス | DC 上でセンサーの処理が遅延しにくくなる |
| VMware の NIC | Large Send Offload を無効化 | 一部トラフィックが解析されない問題を避ける |
| メンテナンス期間 | 事前に確保 | .NET Framework 4.7 以降の導入や保留中の再起動で停止時間が発生し得る |
| 時刻同期 | センサー導入サーバーと DC 間で 5 分以内 | 認証イベントや検出の整合性に影響する |
| AD FS | フェデレーション サーバーのみ対象 | WAP サーバーには不要 |
| AD CS | 証明機関ロール サービスがあるサーバーのみ対象 | オフライン CA には不要 |
v2.x センサー導入時に .NET Framework 4.7 以降が見つからない場合はインストールされ、再起動が必要になる場合があります。ドメイン コントローラーへの作業であるため、平日日中に安易に実行せず、メンテナンス ウィンドウを確保してから進めるべきです。(Microsoft Learn)
OS 要件：Windows Server 2012 / 2012 R2 は移行計画が必要
v2.x センサーをインストールできる OS は、Windows Server 2016、Windows Server 2019、Windows Server 2022、Windows Server 2025 です。Windows Server 2019 では KB4487044 またはそれ以降の累積更新プログラムが必要で、古い ntdsai.dll が存在する場合、センサーが自動的に停止する可能性があります。(Microsoft Learn)
また、デスクトップ エクスペリエンスありのサーバーと Server Core はサポートされますが、Nano Server はサポートされません。ドメイン コントローラー、AD FS、AD CS、Entra Connect サーバーへのインストールが対象です。(Microsoft Learn)
Windows Server 2012 / 2012 R2 については、2023年10月10日に延長サポートが終了しています。これらの OS 上のセンサーは Defender for Identity への報告やセンサー更新を継続できるものの、OS 機能に依存する一部機能が利用できない可能性があるため、サーバーのアップグレードが推奨されています。(Microsoft Learn)
実務上は、Windows Server 2012 / 2012 R2 が残っている場合、Defender for Identity の設定変更だけでは根本対応になりません。OS 更改、DC 昇格・降格、FSMO ロール移動、レプリケーション確認まで含めた Active Directory 更改プロジェクトとして扱うべきです。
ネットワーク要件：TCP 443 だけでは不十分
Defender for Identity センサーは、Defender for Identity クラウド サービスと通信できる必要があります。通信経路としては、プロキシ、ExpressRoute、Defender for Identity Azure IP アドレスを使ったファイアウォール許可のいずれかを選択します。プロキシを利用する場合、センサー URL への通信許可や明示的な許可リスト設定が必要で、SSL 検査はサポートされません。(Microsoft Learn)
外向き通信では、ワークスペース センサー API URL への HTTPS 送信を許可します。形式は https://<your-workspace-name>sensorapi.atp.azure.com です。また、*.atp.azure.com への TCP 443 通信も前提になります。(Microsoft Learn)
内部通信では、DNS、RADIUS、ローカルホスト通信、ネットワーク名解決関連のポートを確認します。
| 用途 | プロトコル / ポート | 確認ポイント |
|---|---|---|
| クラウド通信 | TCP 443 | *.atp.azure.com およびワークスペース センサー API URL を許可 |
| DNS | TCP / UDP 53 | センサーから DNS サーバーへ名前解決できるか |
| RADIUS | UDP 1813 | RADIUS 連携を使う環境で確認 |
| センサー アップデーター | localhost TCP 444 | カスタム ファイアウォールで localhost 通信を遮断していないか |
| NNR | TCP 135、UDP 137、TCP 3389 | IP アドレスからコンピューター名を解決する用途 |
| 複数フォレスト | LDAP 389、LDAPS 636、GC 3268、LDAPS GC 3269 | フォレスト間の通信制御を確認 |
複数フォレスト環境では、センサーがインストールされているコンピューターからドメイン コントローラーへの LDAP / LDAPS / Global Catalog 通信も確認が必要です。既定では LDAP の 389 と 3268 が使われ、LDAPS の 636 と 3269 に切り替えるにはサポート ケースを開く必要があります。(Microsoft Learn)
仮想環境の注意点：動的メモリとメモリ予約を見落とさない
v2.x センサーを仮想マシン上で実行する場合は、メモリを常に仮想マシンに割り当てる必要があります。Hyper-V では動的メモリを有効にしないこと、VMware では構成メモリと予約済みメモリを同じにするか、すべてのゲスト メモリを予約する設定が求められます。(Microsoft Learn)
これは単なる推奨ではなく、安定運用に直結します。ドメイン コントローラーは認証基盤であり、センサーはその上で動作します。仮想基盤側でメモリが回収されると、センサーの遅延だけでなく、DC 自体のパフォーマンス低下につながる可能性があります。
VMware 環境では、NIC の Large Send Offload も重要です。公式の既知の問題では、VMware 上のセンサーで一部ネットワーク トラフィックが分析されない、またはネットワーク構成不一致の正常性アラートが出る場合があり、Guest OS 側で IPv4 TSO Offload を無効化する手順が示されています。(Microsoft Learn)
Windows イベント監査：検出精度を左右する必須設定
Defender for Identity の検出は、NTLM サインインやセキュリティ グループの変更など、特定の Windows イベントログに依存します。公式情報では、Defender ポータルまたは PowerShell を使って、ドメイン コントローラーで Windows イベント監査を構成する必要があるとされています。(Microsoft Learn)
ここで失敗しやすいのは、センサーのインストールだけで満足してしまうことです。センサーが「実行中」でも、監査ポリシーが不足していれば、検出や調査に必要なイベントが十分に取れません。
確認すべき観点は次のとおりです。
| 確認項目 | 実務での確認内容 |
|---|---|
| 監査ポリシー | 必要なイベントが有効化されているか |
| GPO の競合 | ドメイン ポリシーや OU 単位の GPO で上書きされていないか |
| イベントログ権限 | センサーが必要なイベントログを読み取れるか |
| ログ容量 | セキュリティログが短時間でローテーションしていないか |
| 変更管理 | 監査設定変更が他システムの監査要件と衝突しないか |
セキュリティ運用では、イベントログは「収集できているか」だけでなく、「攻撃調査に必要な粒度で残っているか」が重要です。導入後は、アラートの有無だけでなく、高度なハンティングや調査画面で想定どおりの ID イベントが確認できるかまで見てください。
v2.x を継続するか v3.x に移行するかの判断基準
v2.x と v3.x の判断は、サーバー単位で行うのが安全です。組織全体で一括して「v3.x へ移行」と決めると、非対応サーバーや制限に引っかかるサーバーを見落とす可能性があります。
| サーバーの状態 | 推奨判断 | 理由 |
|---|---|---|
| Windows Server 2016 の DC | v2.x 継続 | v3.x は Windows Server 2019 以降が前提 |
| Windows Server 2019 / 2022 の純粋な DC | v3.x 移行を検討 | ポータル移行の条件を満たしやすい |
| Windows Server 2025 の v2.x DC | v2.x 継続を基本に確認 | v2.x から v3.x への移行は現時点で制限あり |
| 非 DC の AD FS | v2.x | v3.x ではなく v2.x の対象 |
| 非 DC の AD CS | v2.x | 証明機関ロール サービスがあるサーバーが対象 |
| 非 DC の Entra Connect | v2.x | アクティブ・ステージング両方を確認 |
| VPN 統合や syslog 通知を利用 | v3.x 移行は慎重に判断 | v3.x では VPN 統合や syslog 通知に制限がある |
v3.x センサーは、VPN 統合や syslog 通知をサポートしないなどの制限があります。既存運用でこれらを利用している場合、移行後に監視・通知フローが変わる可能性があります。(Microsoft Learn)
v2.x から v3.x へ移行する場合の実務手順
v2.x から v3.x へ移行する場合は、単にインストーラーを置き換えるのではなく、Microsoft Defender ポータルの移行状態を確認しながら進めます。公式情報では、前提条件を満たすサーバーは Sensors ページで Ready for migration と表示され、移行中は v3.x センサーが準備できるまで v2.x センサーが動作し続けるため、通常はダウンタイムなしで保護を継続できると説明されています。移行には通常最大 20 分かかります。(Microsoft Learn)
移行前チェック
| チェック項目 | 確認内容 |
|---|---|
| サーバー役割 | 追加 ID ロールのないドメイン コントローラーか |
| v2.x バージョン | 2.254.19112.470 以降か |
| OS | Windows Server 2019 以降か |
| 更新プログラム | 2026年3月以降の累積更新プログラムがあるか |
| Defender for Endpoint | 展開済みでセンサーが正常か |
| Defender for Identity v2.x | サービスが実行中か |
| 移行状態 | Defender ポータルで Ready for migration か |
移行後に必要な設定
移行が成功しても、作業はそこで終わりではありません。v3.x 側では、RPC 監査、Windows イベント監査、ローカル システム ID への切り替えなどの構成確認が必要です。v3.x センサーはローカル システム ID を使うため、以前のバージョン向けに gMSA が構成されている場合は削除する必要があります。gMSA が残っていると、応答アクションが機能しない可能性があります。(Microsoft Learn)
移行後には、v2.x センサー サービスは無効化されますが、v2.x センサー ソフトウェア自体はサーバーに残ります。完全にクリーンアップするには、v2.x センサーのアンインストールと、v3.x では不要な Npcap の削除可否を確認します。Npcap を他アプリケーションが使っていない場合は削除を検討できます。(Microsoft Learn)
展開前に実行したい確認手順
Microsoft Defender for Identity センサー v2.x を新規展開または見直す場合は、次の順序で進めると失敗を減らせます。
| 手順 | 作業 | 完了条件 |
|---|---|---|
| 1 | 対象サーバーを棚卸しする | DC、AD FS、AD CS、Entra Connect、RODC、OS が一覧化されている |
| 2 | v2.x / v3.x の候補を分ける | サーバーごとに継続・移行・新規展開の方針が決まっている |
| 3 | ライセンスと管理者権限を確認する | 必要ライセンスとセキュリティ管理者ロールが確認済み |
| 4 | ネットワーク経路を確認する | TCP 443、プロキシ、SSL 検査、必要ポートが確認済み |
| 5 | 仮想基盤設定を確認する | 動的メモリ無効、メモリ予約、VMware LSO 設定が確認済み |
| 6 | 監査設定を確認する | Windows イベント監査が有効で、GPO 競合がない |
| 7 | メンテナンス期間を確保する | 再起動や .NET Framework 導入に備えた作業枠がある |
| 8 | Readiness チェックを実行する | Test-MdiReadiness.ps1 で前提条件を確認済み |
| 9 | 小規模に展開する | 代表的な DC で正常性とイベント取得を確認 |
| 10 | 段階展開する | 拠点・フォレスト単位で展開し、正常性アラートを監視する |
公式情報では、環境に必要な前提条件があるかを確認するために Test-MdiReadiness.ps1 スクリプトの実行が推奨されています。このスクリプトは Microsoft Defender XDR の [Identities] > [Tools] ページからも利用できるとされています。(Microsoft Learn)
よくある失敗と対策
プロキシや SSL 検査でクラウド通信に失敗する
v2.x センサーは Defender for Identity クラウド サービスと通信する必要があります。プロキシを使う場合、SSL 検査はサポートされません。セキュリティ製品やプロキシで TLS 通信を中間検査している環境では、センサー登録や通信が失敗する可能性があります。(Microsoft Learn)
対策として、Defender for Identity の通信先を明示的に許可し、センサーから対象 URL へ認証なしで到達できるかを確認します。プロキシ認証の問題がライセンス エラーのように見えるケースもあるため、エラー表示だけで判断せず、通信ログとプロキシログを併せて確認してください。(Microsoft Learn)
localhost の TCP 444 をブロックしている
センサー サービス アップデーターには localhost の TCP 444 通信が必要です。通常は許可されていますが、独自のファイアウォール ポリシーや強化テンプレートで localhost 通信まで制限していると、センサー関連サービスが正常に動作しない場合があります。(Microsoft Learn)
AD CS の対象を誤る
AD CS 環境では、証明機関ロール サービスがある AD CS サーバーのみが v2.x センサーの対象です。オフライン CA にセンサーをインストールする必要はありません。PKI 環境ではオンライン CA、オフライン ルート CA、中間 CA が混在しやすいため、事前に役割を棚卸ししてください。(Microsoft Learn)
Entra Connect のステージング サーバーを忘れる
Microsoft Entra Connect は、アクティブ サーバーだけでなくステージング サーバーにもセンサーが必要です。障害時にステージングを昇格する運用の場合、平常時にセンサーがないと可視性に差が出ます。(Microsoft Learn)
v3.x への移行後に gMSA を残してしまう
v3.x センサーではローカル システム ID を使用します。v2.x 時代の設定として gMSA を残したままにすると、応答アクションが機能しない可能性があります。v2.x と v3.x が混在する環境では、どのサーバーがどのセンサーで、どのアカウント設定を使っているかを一覧化して管理してください。(Microsoft Learn)
管理者・開発者が次に確認すべきチェックリスト
Microsoft Defender for Identity センサー v2.x の前提条件を確認したら、次は自社環境での実装状況に落とし込む必要があります。
| 立場 | 確認すべきこと | 次の行動 |
|---|---|---|
| AD 管理者 | DC の OS、役割、レプリケーション、時刻同期 | v2.x 継続対象と v3.x 候補を分ける |
| セキュリティ管理者 | Defender ポータルのセンサー正常性、アラート、監査設定 | 正常性アラートと検出イベントを確認する |
| M365 / Entra 管理者 | ライセンス、セキュリティ管理者ロール、Entra Connect | アクティブ・ステージング両方の展開状況を確認する |
| ネットワーク管理者 | プロキシ、SSL 検査、TCP 443、内部ポート | センサー用通信を許可リスト化する |
| 仮想基盤担当 | Hyper-V 動的メモリ、VMware メモリ予約、LSO | DC の VM 設定を標準化する |
| 開発者・自動化担当 | 展開手順、Readiness チェック、構成管理 | Test-MdiReadiness.ps1 を事前検証手順に組み込む |
開発者や自動化担当が関与する場合は、インストール手順だけでなく、前提条件チェック、ネットワーク到達性、監査設定確認、移行後のクリーンアップまでをスクリプトや運用Runbookに落とし込むと効果的です。特に大規模環境では、人手で 1 台ずつ確認すると抜け漏れが出るため、サーバー一覧、OS バージョン、センサー バージョン、移行状態を定期的に棚卸しできる形にしておくべきです。
まとめ：v2.x の前提条件確認は「v3.x 移行判断」とセットで行う
Microsoft Defender for Identity センサー v2.x の前提条件を確認する目的は、単にインストール可否を見ることではありません。現在の ID 基盤で、どのサーバーに v2.x を継続し、どのドメイン コントローラーを v3.x へ移行できるかを判断することが重要です。
まず実施すべきことは、ドメイン コントローラー、AD FS、AD CS、Microsoft Entra Connect サーバーを棚卸しし、OS、サーバー役割、センサー バージョン、ネットワーク経路、監査設定を一覧化することです。そのうえで、Windows Server 2019 以降の純粋なドメイン コントローラーは v3.x 移行候補として確認し、非ドメイン コントローラーの AD FS / AD CS / Entra Connect や Windows Server 2016 環境は v2.x 継続を前提に運用を固めます。
最後に、Test-MdiReadiness.ps1 による前提条件チェック、メンテナンス期間の確保、監査設定の確認、移行後の v2.x センサーと Npcap のクリーンアップまでを手順化してください。これにより、Microsoft Defender for Identity のセンサー更新を、単なるバージョン対応ではなく、ID 基盤全体の可視性と検出精度を高める改善作業として進められます。
コメント