Microsoft Defender for Endpointで旧バージョンのWindowsをオンボードする場合、結論は「OSごとに使う方式を分ける」ことです。Windows 7 SP1 Pro／EnterpriseとWindows Server 2008 R2 SP1はDefender展開ツール、Windows 8.1／8.1 ProはMicrosoft Monitoring Agent（MMA）を使う、という整理が実務上の出発点になります。公式ページはMicrosoft Defender for Endpoint Plan 1／Plan 2を対象としており、旧Windows端末からもセンサーデータを送信し、検出・調査・ハンティングに活用できるようにする内容です。(Microsoft Learn)
ただし、旧OSをオンボードできることと、最新Windowsと同じ機能を使えることは別です。ネットワーク保護、攻撃面縮小ルール、フォルダーアクセス制御など一部機能はWindows 7 SP1／Windows Server 2008 R2 SP1ではサポートされません。管理者は「導入できるか」だけでなく、「どの検知・防御・応答機能まで使えるか」「既存のMMAやSCEPをどう扱うか」「プロキシやSSLインスペクションで通信が止まらないか」まで確認する必要があります。(Microsoft Learn)
なお、Microsoft Learnの該当ページは確認時点で英語版が2026年6月3日、日本語版が2026年6月4日更新と表示されています。2026年5月末の更新情報として変更管理に残す場合も、社内チケットには参照URL、確認日、対象テナントの画面差分を記録しておくと安全です。(Microsoft Learn)
まず押さえるべき影響範囲
今回の「Onboard previous versions of Windows」で影響を受けるのは、主に次のような環境です。
| 対象 | 影響 | 最初に確認すること |
|---|---|---|
| Windows 7 SP1 Pro／Enterprise | Defender展開ツールでオンボードする対象 | x64環境、必要な更新プログラム、既存MMAの有無、Defender Antivirusをアクティブにするかパッシブにするか |
| Windows Server 2008 R2 SP1 | Defender展開ツールでオンボードする対象 | サーバー用途への影響、再起動可否、プロキシ設定、.NET要件、既存ウイルス対策製品との共存 |
| Windows 8.1／Windows 8.1 Pro | MMAとSCEPを使う対象 | MMAバージョン、SCEP更新、Workspace ID／Key、クラウド保護設定 |
| 既にMMAでオンボード済みの端末 | Defender展開ツールでアップグレード可能なケースがある | 既存ワークスペース、センサー送信状況、段階移行の対象グループ |
| SOC／運用監視チーム | タイムライン、Advanced Hunting、アラート調査に旧OSのデータが加わる | 端末名、デバイスグループ、タグ、アラートルール、除外設定 |
| 開発・展開自動化チーム | GPO、Configuration Manager、独自配布ツールへの組み込みが必要 | サイレント実行、終了コード、ログ収集、プロキシ引数、再実行時の扱い |
旧OSのオンボードは、セキュリティ運用上は「見えない端末を減らす」効果があります。一方で、旧OSの延命策として扱うのは危険です。Defender for Endpointで可視化できても、OS自体のサポート状態やアプリケーション互換性のリスクが消えるわけではありません。オンボード作業と並行して、OS更改計画も必ず別タスクとして管理しましょう。
変更点の要点：Defender展開ツール中心で考える
実務上の大きなポイントは、Windows 7 SP1とWindows Server 2008 R2 SP1では、Defender展開ツールを使った展開が中心になることです。公式情報では、Defender展開ツールが前提条件の処理、古いソリューションからの移行、オンボーディングスクリプトや個別ダウンロード、手動インストールの複雑さの軽減を担うと説明されています。(Microsoft Learn)
つまり、管理者がやるべきことは「オンボーディングスクリプトを端末に流せば完了」と考えることではありません。対象OS、既存エージェント、ネットワーク、再起動、プロキシ、既存ウイルス対策製品との共存を確認し、Defender展開ツールをどう配布・実行・監視するかを設計する必要があります。
Defender展開ツールは対話型の実行だけでなく、コマンドラインによる非対話実行にも対応しています。GPO、Microsoft Configuration Manager、組織内のソフトウェア配布基盤と組み合わせた大規模展開も想定されています。(Microsoft Learn)
OS別の推奨オンボード方式
旧Windowsのオンボードで最も間違えやすいのは、すべての古いWindowsに同じ方式を使おうとすることです。公式情報を基に、まずは次のように切り分けます。(Microsoft Learn)
| OS | 推奨方式 | 実務上の注意点 |
|---|---|---|
| Windows 7 SP1 Pro | Defender展開ツール | 必要更新プログラムとx64条件を確認。既存の非Microsoft製ウイルス対策がある場合はパッシブモードも検討 |
| Windows 7 SP1 Enterprise | Defender展開ツール | Advanced Huntingやセンサーイベントは活用できるが、最新Windowsと同じ防御機能ではない点に注意 |
| Windows Server 2008 R2 SP1 | Defender展開ツール | サーバー停止影響、再起動タイミング、既存AVとの共存、プロキシ経路を事前検証 |
| Windows 8.1 | MMAとSCEP | MMA 10.20.18029以降、.NET Framework 4.5.2以降、必要更新プログラムを確認 |
| Windows 8.1 Pro | MMAとSCEP | Workspace ID／Keyの管理、SCEPのクラウド保護設定、Defenderクラウドへの通信許可が必要 |
ここで重要なのは、Windows 8.1系だけはMMAとSCEPが残る点です。公式情報でも、MMAとSCEP経由のオンボードはWindows 8.1または8.1 Proの場合にのみ推奨され、それ以外のWindowsではDefender展開ツールを使う整理になっています。(Microsoft Learn)
Windows 7 SP1／Windows Server 2008 R2 SP1で使える機能と使えない機能
Windows 7 SP1やWindows Server 2008 R2 SP1でも、Microsoft Defender for Endpointのセンサーデータを使った調査や検出は可能です。ただし、機能差を把握せずに最新OSと同じ運用ルールを適用すると、ポリシーを配布したのに効いていない、SOCが期待した応答操作を実行できない、といった問題が起きます。
| 分類 | 利用できる主な内容 | 注意点 |
|---|---|---|
| Advanced Hunting | Kusto Query Languageでイベントを横断的に調査 | 旧OSのイベント粒度を前提にクエリを調整する |
| Defender Antivirus | リアルタイム動作監視、クラウド配信、定義ベースのブロックや修復、スケジュールスキャン | 既存AVがある場合はパッシブモード設計が必要 |
| カスタムファイルインジケーター | ハッシュや証明書情報に基づく許可、ブロック、検疫 | 誤検知対応として安易に許可を増やしすぎない |
| デバイス／ファイル応答 | デバイス分離、ファイルのブロック・取得、調査パッケージ収集、AVスキャン | その他の応答機能はサポート対象外 |
| 脆弱性評価 | Windowsとインストール済みソフトウェアの脆弱性情報を確認 | セキュリティ構成評価など一部機能は利用不可 |
| セキュリティ設定管理 | 利用可能なDefender Antivirus機能に対するポリシー適用 | 存在しない機能の設定は有効にならない |
特に注意したいのは、ネットワーク保護、攻撃面縮小ルール、フォルダーアクセス制御、IP／URLインジケーター関連機能がWindows 7 SP1／Windows Server 2008 R2 SP1ではサポートされない点です。また、セキュリティ構成評価、「保留中の再起動」エクスペリエンス、一部のプレミアム機能も利用できません。(Microsoft Learn)
管理画面上でポリシーを作成できることと、対象端末で実際に効くことは同じではありません。旧OS向けには「適用するポリシー」と「効果を期待するポリシー」を分けて設計し、展開後にAdvanced Huntingや端末ログで確認する運用にしましょう。
展開前に確認すべきチェックリスト
旧Windowsのオンボードは、最新Windows端末の展開よりも失敗要因が多くなります。以下のチェックを事前に済ませてから、本番展開に進めるのが安全です。
| 確認項目 | 確認内容 | 失敗しやすいポイント |
|---|---|---|
| OSとエディション | Windows 7 SP1 Pro／Enterprise、Windows Server 2008 R2 SP1、Windows 8.1／8.1 Proのどれか | 対象外OSを同じGPOに含めて終了コード50になる |
| アーキテクチャ | Windows 7 SP1／Server 2008 R2 SP1ではx64要件を確認 | 古い業務端末に32bit OSが残っている |
| 必要更新プログラム | Windows 7 SP1／Server 2008 R2 SP1ではSHA-2関連更新などを確認 | 更新不足で前提条件チェックに失敗する |
| 管理者権限 | ツール実行に必要な権限を確保 | ユーザー権限で実行し、インストールに失敗する |
| プロキシ | プロキシアドレス、認証、端末単位の接続経路を確認 | SYSTEMアカウント実行時のプロキシ設定がユーザー設定と異なる |
| SSLインスペクション | Defender for EndpointサービスURLへの直接接続を確認 | SSLインターセプトによりサービス通信が失敗する |
| 既存AV | 他社製品、SCEP、既存MMAの状態を棚卸し | 二重防御で性能劣化、またはDefenderが意図せずアクティブ化 |
| 再起動 | 業務時間、メンテナンス時間、再起動後の自動再開を設計 | 再起動後にサインインされず対話型処理が止まる |
| 検証方法 | ポータル反映、サービス状態、ログ、検出テストを決める | 「配布した」だけで完了扱いにしてしまう |
Defender展開ツールの一般的な前提条件には管理者権限が含まれます。また、ツールの取得や更新に関連する通信先、Defender for Endpointサービスへの接続要件も確認が必要です。公式情報では、definitionupdates.microsoft.comへのアクセスや、追加機能のためのDefender for Endpointサービス接続要件が説明されています。(Microsoft Learn)
Defender展開ツールでの基本的な展開手順
小規模な検証であれば、Defender展開ツールを対話形式で実行して挙動を確認できます。本番では、GPOやConfiguration Manager、既存のソフトウェア配布ツールを使い、非対話実行に切り替えるのが現実的です。公式情報でも、対話型と非対話型の両方が想定されています。(Microsoft Learn)
検証環境での進め方
最初は、代表的な端末を3〜5台選びます。業務アプリが多い端末、プロキシ配下の端末、既存AVが入っている端末、サーバー用途の端末を混ぜると、本番展開前に問題を見つけやすくなります。
| 手順 | 作業 | 確認ポイント |
|---|---|---|
| 事前棚卸し | 対象OS、既存AV、MMA、プロキシ、再起動可否を確認 | 対象外OSを除外する |
| パッケージ取得 | Microsoft DefenderポータルからWindows向けオンボードパッケージを取得 | プレビュー機能の有無で画面や取得方法が異なる可能性がある |
| 前提条件チェック | DefenderDT.exe -PreCheck -Verbose -Quietを実行 | 更新不足、権限不足、OS非対応を先に検出する |
| 少数展開 | 手動または限定GPOで実行 | サービス起動、ログ、ポータル反映を確認 |
| 検出テスト | 新規オンボード端末向けの検出テストを実行 | センサーが正しくサービスへ送信できているか確認 |
| 段階展開 | OUやデバイスグループ単位で広げる | 終了コード、失敗端末、通信エラーを集計 |
オンボード完了後、ポータルへの反映には時間がかかる場合があります。公式情報では、Windows 8.1のMMA手順でオンボードされたエンドポイントがポータルに1時間以内に表示されるとされています。反映が遅いだけなのか、通信に失敗しているのかを切り分けるため、端末側ログとサービス状態も合わせて確認しましょう。(Microsoft Learn)
よく使うコマンド例
Defender展開ツールは、コマンドラインでの非対話実行に対応しています。大規模展開では、終了コードを収集できるようにしておくと失敗端末の再処理がしやすくなります。(Microsoft Learn)
DefenderDT.exe -PreCheck -Verbose -Quiet前提条件だけを確認する例です。本番展開前に、OS非対応、更新不足、権限不足を洗い出す用途に向いています。
DefenderDT.exe -Quiet既定設定で非対話実行する例です。小規模な検証後、GPOや配布ツールから実行する場合の基本形になります。
DefenderDT.exe -Proxy:192.168.0.255:8080 -AllowReboot -Quietプロキシを指定し、必要に応じて再起動を許可する例です。サーバーや業務端末では、-AllowRebootを使う前に必ずメンテナンス時間と復旧手順を確認してください。
DefenderDT.exe -File:\\server\share\Defender.onboarding -Quietオンボーディングファイルをネットワーク共有に置いて実行する例です。GPOで配布する場合は、端末がSYSTEMアカウントで共有にアクセスできるか確認します。
GPOで配布する場合の注意点
GPOでDefender展開ツールを配布する場合は、スタートアップスクリプトよりもスケジュールタスクとしてSYSTEM権限で実行する構成が扱いやすいケースがあります。公式手順でも、GPOの「Immediate Task」を使い、NT AUTHORITY\SYSTEMで実行し、最高権限で実行する流れが示されています。(Microsoft Learn)
特に確認すべきなのは、UNCパスです。ツール本体、オンボーディングファイル、設定ファイルを共有フォルダーに置く場合、ユーザーがアクセスできてもSYSTEMアカウントがアクセスできないことがあります。検証時は、端末側のイベントログとDefender展開ツールのログを見て、ファイル未検出や権限エラーを確認してください。
GPO展開でありがちな失敗は、対象OUを広くしすぎることです。Windows 10やWindows 11、Windows Server 2019以降の端末まで同じ旧OS向けポリシーに含めると、意図しない再実行やログのノイズが増えます。最初は「Windows 7」「Server 2008 R2」「検証済み端末」などの条件で対象を絞る設計が安全です。
Windows 8.1でMMAを使う場合の確認ポイント
Windows 8.1／8.1 Proでは、MMAとSCEPを使ったオンボードが案内されています。この場合、Defender展開ツールの設計とは確認項目が変わります。公式情報では、2018年2月の月次更新ロールアップ、2019年3月12日以降のサービススタック更新、診断テレメトリ更新、.NET Framework 4.5.2以降、Azure Log Analyticsエージェントの要件が示されています。(Microsoft Learn)
また、MMAエージェントはSHA-1サポート廃止の影響により、バージョン10.20.18029以降が必要です。古いMMAが残っている環境では、オンボード前にバージョン確認を行い、必要に応じて更新してから作業を進めます。(Microsoft Learn)
MMA方式では、Microsoft DefenderポータルからWorkspace IDとWorkspace Keyを取得します。これらはオンボードに必要な情報ですが、スクリプトや共有フォルダーに平文で放置すると、意図しない接続や情報漏えいのリスクになります。配布後は不要なファイルを削除し、アクセス権を最小限にしてください。
既存MMA環境から移行する場合の考え方
既にMMAでオンボード済みのWindows 7 SP1やWindows Server 2008 R2 SP1がある場合、Defender展開ツールでアップグレードを実行できると公式情報で説明されています。(Microsoft Learn)
移行時に避けたいのは、先にMMAやSCEPを削除してから新しい展開を始めることです。順序を誤ると、一定期間センサーが停止し、SOCから端末が見えなくなる可能性があります。実務では次の順番で進めると安全です。
| フェーズ | 作業 | 判断基準 |
|---|---|---|
| 棚卸し | MMA導入済み端末、SCEP導入済み端末、他社AV導入端末を分類 | 端末名、OS、部署、業務影響でグルーピングする |
| 事前検証 | 代表端末で前提条件チェックと展開ツール実行 | サービス起動、ポータル反映、アラート発生有無を確認 |
| 並行監視 | 旧方式と新方式のログを比較 | センサー停止期間がないか確認 |
| 段階移行 | OUや拠点単位で展開 | 失敗端末は終了コードで分類し、再実行条件を決める |
| 後処理 | 不要になった旧設定やワークスペース構成を整理 | 削除前にオンボード状態を再確認する |
オフボードが必要な場合、MMAエージェントのアンインストール、またはDefender for Endpointワークスペース構成の削除という選択肢があります。オフボードすると端末はポータルへのセンサーデータ送信を停止しますが、端末データや過去アラートへの参照は最大6か月保持されると説明されています。(Microsoft Learn)
プロキシとSSLインスペクションは最優先で確認する
旧Windowsのオンボード失敗で多いのが、ネットワーク経路の問題です。とくにプロキシ環境では、管理者がブラウザーで通信できることを確認しても、SYSTEM権限で動くツールやサービスが同じ経路を使えるとは限りません。
公式情報では、プロキシやファイアウォールを使っている場合、Microsoft Defender for EndpointサービスURLへSSLインターセプトなしで直接アクセスできることを確認するよう案内されています。SSLインターセプトを使うと、Defender for Endpointサービスとの通信ができなくなる可能性があります。(Microsoft Learn)
本番前には、次の3点を確認してください。
| 確認対象 | 確認方法 | 見落としやすい点 |
|---|---|---|
| 端末のプロキシ設定 | WinHTTP、システムプロキシ、配布コマンドの-Proxy指定を確認 | ユーザーのブラウザー設定だけ見て判断する |
| ファイアウォール | Defender for Endpoint関連URLへの許可を確認 | IP固定前提で許可しようとする |
| SSLインスペクション | 対象URLを復号対象から除外 | 証明書エラーではなく、オンボード失敗として表面化する |
旧OSほどTLS、証明書、プロキシ認証、更新プログラムの状態に左右されやすくなります。ネットワークチームと連携し、検証端末の通信ログを先に取得しておくと、展開後の切り分けが速くなります。
展開後の確認方法
オンボード作業は、ツールの実行完了では終わりません。最低限、端末側、ポータル側、SOC側の3方向で確認します。
端末側で確認する
Defender展開ツールのログは、次のパスに出力されます。問題が起きた場合は、まずこのログを確認します。(Microsoft Learn)
C:\ProgramData\Microsoft\DefenderDeploymentTool\DefenderDeploymentTool-<COMPUTERNAME>.logサービスの稼働状況は、次のコマンドで確認できます。(Microsoft Learn)
Sc.exe query sense
Sc.exe query windefendSTATE : 4 RUNNINGになっていれば、サービスは起動しています。ただし、サービス起動だけではクラウド送信まで成功しているとは限りません。ポータル反映と検出テストも合わせて確認してください。
ポータル側で確認する
Microsoft Defenderポータルのデバイス一覧で、対象端末が表示されるかを確認します。端末名、OS、最終表示時刻、リスク状態、デバイスグループを見ます。表示されない場合は、オンボード未完了、通信失敗、反映待ち、重複デバイス、プロキシ問題の順に切り分けると効率的です。
オンボード後は、検出テストを実行してサービスに正しく接続されているか確認できます。公式情報でも、新しくオンボードされたDefender for Endpointエンドポイントで検出テストを実行することが案内されています。(Microsoft Learn)
SOC側で確認する
SOCやCSIRTでは、旧OSがAdvanced Huntingやデバイスタイムラインに現れるかを確認します。Windows 7 SP1／Server 2008 R2 SP1では、最新Windowsと取得できるイベントや有効な防御機能が異なるため、既存のハンティングクエリがそのまま期待通りに動くとは限りません。
たとえば「攻撃面縮小ルールの検出を前提にしたクエリ」は、旧OSでは対象外の可能性があります。一方で、プロセス実行、ファイル操作、検出センサー由来のイベントは調査に役立ちます。旧OS用のデバイスグループやタグを用意し、アラートの優先度や調査手順を分けると運用しやすくなります。
終了コードを使った失敗分類
大規模展開では、失敗端末を手作業で1台ずつ確認するのは現実的ではありません。Defender展開ツールの終了コードを配布基盤で収集し、原因ごとに再処理する設計にしておきます。公式情報では、代表的な終了コードが一覧化されています。(Microsoft Learn)
| 終了コード | 意味 | 管理者の対応 |
|---|---|---|
| 0 | 成功 | ポータル反映と検出テストへ進む |
| 2 | 既にオンボード済み | 重複展開ではないか確認し、成功扱いにするか判断 |
| 10 | 継続に再起動が必要 | メンテナンス時間に再起動し、再開状況を確認 |
| 40 | 管理者権限が必要 | GPOや配布ツールの実行権限を修正 |
| 50 | サポートされないOS | 対象グループから除外し、OS更改対象に入れる |
| 90 | 前提条件チェック失敗 | 必要更新プログラム、.NET、通信条件を確認 |
| 200 | オンボード失敗 | センサー初期化、オンボーディングファイル、ログを確認 |
| 400 | 必要コンポーネントのダウンロード失敗 | プロキシ、ファイアウォール、名前解決を確認 |
| 500 | 必要コンポーネントのインストール失敗 | 既存AV、権限、Windows Update状態を確認 |
| 710 | Defender Antivirus機能の有効化失敗 | Windows Server側の機能状態やサポート対応を確認 |
終了コード2は、運用上は失敗ではなく「再実行しても不要だった」と扱える場合があります。再実行に強い展開設計にしておくと、GPOや配布ツールで同じコマンドが複数回流れても大きな問題になりにくくなります。
開発者・自動化担当者が確認すべきポイント
この更新はセキュリティ管理者向けの内容に見えますが、社内ツールや配布スクリプトを管理する開発者にも影響します。特に、オンボーディングパッケージ、設定ファイル、ログ収集、プロキシ指定を自動化している場合は確認が必要です。
パッケージやキーを長期間放置しない
Defender展開ツールの関連情報では、展開パッケージに有効期限を設定できるプレビュー機能や、古いオンボーディングパッケージが悪用されるリスクを下げるため、有効期間をできるだけ短くする推奨が示されています。(Microsoft Learn)
社内のファイルサーバーに古いオンボーディングファイルやキーを残したままにすると、意図しない端末がオンボードされるリスクがあります。配布後は、共有フォルダーのアクセス権を見直し、不要なパッケージを削除する運用を入れてください。
設定ファイルで環境差分を管理する
繰り返し展開する場合、Defender展開ツールでは-MakeConfigで設定ファイルを生成し、プロキシ、再起動許可、パッシブモード、前提条件チェックなどのパラメーターをまとめて管理できます。(Microsoft Learn)
開発者が配布スクリプトを作る場合、環境ごとにコマンドを直書きするより、設定ファイルを分けたほうが変更履歴を追いやすくなります。
| 環境 | 設定例 | 管理ポイント |
|---|---|---|
| 本社LAN | プロキシなし、Quiet実行 | 通信許可URLと終了コード収集 |
| 拠点LAN | 拠点プロキシ指定 | SYSTEM権限でのプロキシ接続確認 |
| サーバー | 再起動なし、パッシブモード検討 | メンテナンス時間と既存AVの状態 |
| 検証端末 | Verbose、PreCheck有効 | ログ収集と失敗パターンの洗い出し |
既存アプリへの影響を検証する
Defender Antivirusのリアルタイム監視が有効になると、古い業務アプリ、自己解凍形式のインストーラー、独自署名の実行ファイル、ファイルを大量生成するバッチ処理に影響が出ることがあります。問題が起きた場合、安易に広い除外を入れるのではなく、検出名、ファイルハッシュ、署名、実行パス、発生条件を確認します。
公式情報では、カスタムファイルインジケーターによってハッシュや証明書情報に基づく許可、ブロック、検疫が可能とされています。(Microsoft Learn) ただし、許可設定は攻撃者にも悪用され得るため、期限、承認者、対象範囲を決めて運用してください。
移行・展開時によくある失敗
旧Windowsのオンボードで失敗しやすいポイントは、技術的には小さく見えても、本番では大きな手戻りになります。
| 失敗例 | 原因 | 対策 |
|---|---|---|
| ポリシーを配布したのに端末が表示されない | 通信失敗、プロキシ未設定、SSLインスペクション、反映待ち | 端末ログ、サービス状態、ネットワークログを順に確認 |
| 一部端末だけ失敗する | OS、更新プログラム、32bit／64bit、既存AVの差 | 失敗端末を属性別に分類し、共通点を探す |
| サーバーで性能劣化が起きる | 既存AVとの競合、リアルタイムスキャン対象の設計不足 | パッシブモードや除外設計を検証してから本番適用 |
| GPOで実行されない | SYSTEM権限で共有にアクセスできない | FQDNのUNCパス、共有権限、NTFS権限を確認 |
| 再起動後に処理が完了しない | 対話型実行でサインインが必要 | 本番では非対話実行を基本にし、再起動条件を制御 |
| ポリシーが効いていると思い込む | 旧OSで未サポートの機能を設定している | OS別のサポート機能表を作り、期待値を分ける |
特に危険なのは、「Microsoft Defender for Endpointに表示されたから防御も最新化された」と誤解することです。旧OSでは使えない機能があるため、オンボード後もリスクは残ります。セキュリティ運用上は、旧OS端末を専用デバイスグループに分け、リスク受容期間と更改期限を設定するのが現実的です。
管理者が取るべき次のアクション
まず、資産管理台帳やEDR未導入端末リストから、Windows 7 SP1、Windows Server 2008 R2 SP1、Windows 8.1／8.1 Proを抽出します。次に、OSごとにオンボード方式を分け、検証グループを作ります。
最初の1週間で行うべき作業は、次の5つです。
| 優先度 | 作業 | 成果物 |
|---|---|---|
| 高 | 対象OSと既存MMA／SCEP／AVの棚卸し | 対象端末一覧 |
| 高 | プロキシ、SSLインスペクション、サービスURL許可の確認 | ネットワーク確認結果 |
| 高 | 代表端末でDefender展開ツールのPreCheckを実行 | 失敗要因リスト |
| 中 | GPOまたは配布ツールでのサイレント展開を検証 | 展開手順書 |
| 中 | オンボード後の確認手順をSOCと合意 | 検出テスト、ログ確認、ポータル確認手順 |
Windows 7 SP1／Windows Server 2008 R2 SP1はDefender展開ツール、Windows 8.1／8.1 ProはMMAという切り分けを最初に固定すれば、展開設計の迷いはかなり減ります。そのうえで、未サポート機能、プロキシ、既存AV、終了コード、オフボード手順を確認しながら段階展開してください。
旧Windowsのオンボードは、古い端末を安全に使い続けるための万能策ではありません。目的は、見えていない端末をMicrosoft Defender for Endpointの監視対象に入れ、攻撃検出と調査の空白を減らすことです。オンボード完了をゴールにせず、可視化、検知、運用ルール、OS更改までを一つの計画として進めることが、管理者にとって最も実効性のある対応です。
コメント