Microsoft Defender for EndpointにWindows Serverをローカルスクリプトでオンボードする方法は、少数のサーバーを手動で登録するための手段です。結論から言うと、検証環境・DMZ内の単体サーバー・一時的な個別対応には有効ですが、本番環境で多数のWindows Serverへ展開する場合は、Intune、グループポリシー、Microsoft Configuration Manager、Defender for Cloud連携などの展開方法を優先すべきです。Microsoft公式ドキュメントでも、ローカルスクリプトは手動オンボーディング向けで、対象は10台以下に限定することが推奨されています。(Microsoft Learn)
2026年5月末の公式情報では、Microsoft Defender for Endpointのローカルスクリプト手順について、オンボーディングパッケージ名の表記修正やオフボーディング手順の誤記修正が確認できます。機能そのものが大きく変わったというより、管理者が手順書・自動化スクリプト・社内Runbookで参照しているファイル名や画面名を見直すべき更新です。(GitHub)
Microsoft Defender for Endpointのローカルスクリプトオンボードとは
Microsoft Defender for Endpointのオンボードとは、Windows ServerやWindowsクライアントをDefender for Endpointサービスに登録し、センサー情報やセキュリティ状態をMicrosoft Defenderポータルへ報告できるようにする作業です。オンボードが完了すると、デバイスはDefender for Endpointの管理対象となり、アラート、調査、EDR、脅威検出などの対象になります。(Microsoft Learn)
ローカルスクリプト方式では、Microsoft Defenderポータルからオンボーディングパッケージをダウンロードし、対象サーバー上で管理者権限のコマンドプロンプトから.cmdファイルを実行します。公式手順では、Defenderポータルの「System > Settings > Endpoints > Device management > Onboarding」からパッケージを取得し、展開後にWindowsDefenderATPLocalOnboardingScript.cmdを実行する流れになっています。(Microsoft Learn)
ただし、この方式は「便利だから全社展開に使う」ものではありません。台数が増えるほど実行漏れ、権限不足、ネットワーク疎通ミス、ログ確認漏れが起きやすくなります。10台を超える本番展開では、最初から自動展開・構成管理・監査証跡を前提に設計することが重要です。
2026年5月末更新で管理者が見るべき変更点
今回の更新で特に確認したいのは、オンボーディングの概念変更ではなく、手順書や自動化処理が古い表記に依存していないかです。GitHub上の公式ドキュメント履歴では、2026年5月29日のコミットで「Corrected typo.」として4行の変更が行われています。主な差分は、日付メタデータの更新、オンボーディングパッケージ名の修正、オフボーディング画面名の修正です。(GitHub)
| 確認項目 | 更新後の内容 | 実務上の影響 |
|---|---|---|
| ドキュメント日付 | ms.date: 05/28/2026 | 社内手順書の参照日を更新する |
| オンボーディングZIP名 | GatewayWindowsDefenderATPOnboardingPackage.zip | ZIP名を固定で探す自動化スクリプトは要修正 |
| 展開後の実行ファイル | WindowsDefenderATPLocalOnboardingScript.cmd | 実行する.cmd名は引き続き確認が必要 |
| オフボーディング画面名 | 「Onboarding」ではなく「Offboarding」 | 手順書の画面説明ミスを修正する |
| 機能面の大幅変更 | 明示的な機能追加ではなく表記修正中心 | 展開方式の再設計までは不要だが、Runbook確認は必要 |
とくに注意したいのは、ZIPファイル名です。過去の社内手順やPowerShellで、WindowsDefenderATPOnboardingPackage.zipのような古い名前を前提にファイル存在チェックをしている場合、パッケージ取得後の処理に失敗する可能性があります。手動作業だけであれば大きな問題になりにくいものの、踏み台サーバーや展開用共有フォルダーでファイル名を条件分岐に使っている環境では、更新後の名称に合わせて確認してください。(GitHub)
影響範囲はWindows Server管理者、SOC、ネットワーク担当に及ぶ
この更新の影響は、Microsoft Defenderポータルを操作するセキュリティ管理者だけに限られません。Windows Serverの構成管理、プロキシ・ファイアウォール設定、EDRアラート運用、オフボーディング運用にも関係します。
| 立場 | 確認すべきこと | 見落とすと起きやすい問題 |
|---|---|---|
| Windows Server管理者 | 対象OS、更新プログラム、管理者権限、SENSEサービス | スクリプト実行後もデバイスが登録されない |
| SOC・セキュリティ運用 | 検出テスト、アラート通知、デバイスインベントリ反映 | 登録済みと思っていたサーバーが監視対象外になる |
| ネットワーク担当 | Standard / Streamlined接続、プロキシ、TLS検査 | クラウドサービスへ接続できずセンサーが報告しない |
| 開発・DevOps担当 | ビルドサーバー、CI/CDエージェント、検証VMの扱い | 一時サーバーやDMZサーバーがEDR管理から漏れる |
| IT資産管理担当 | サーバー台帳とDefenderデバイス一覧の突合 | ライセンス数や管理対象台数が実態とずれる |
Windows ServerをDefender for Endpointへオンボードするには、サーバー向けライセンスも確認が必要です。公式ドキュメントでは、Defender for Servers Plan 1またはPlan 2、Microsoft Defender for Endpoint for servers、Microsoft Defender for Business serversなどが選択肢として示されています。(Microsoft Learn)
ローカルスクリプトを使うべきケース、使わないほうがよいケース
ローカルスクリプト方式は、悪い方法ではありません。問題は、用途を間違えることです。最初の検証や例外的な単体サーバーには向いていますが、継続運用や大規模展開には向きません。
| 利用シーン | ローカルスクリプトの適性 | 推奨判断 |
|---|---|---|
| 検証用Windows Serverを1〜3台だけ登録する | 高い | ローカルスクリプトで十分 |
| DMZ内の単体サーバーを個別に登録する | 中〜高 | 疎通確認とログ確認を前提に利用 |
| 10台以下の小規模環境で一時的に試す | 中 | 実行結果の記録を残す |
| 50台以上の本番サーバーへ展開する | 低い | Group Policy、Configuration Manager、Defender for Cloudを検討 |
| IntuneやConfigMgrで管理済みの端末群 | 低い | 既存の管理基盤で展開 |
| 非永続VDIやゴールデンイメージ | 低い | VDI向け手順を確認 |
| Windows Server 2012 R2 / 2016の移行対象 | 注意が必要 | 統合エージェントや前提更新を先に確認 |
Microsoftの展開方式選定ガイドでも、ローカルスクリプトは「最大10台」の選択肢として整理され、Windows Serverではサーバープランが必要とされています。環境に応じて、Defender for Cloud連携、Configuration Manager、グループポリシー、Defender deployment toolなどを使い分けるのが現実的です。(Microsoft Learn)
Windows Serverでオンボード前に確認すべき前提条件
ローカルスクリプトを実行する前に、少なくとも次の項目を確認してください。ここを省くと、スクリプト自体は実行できてもMicrosoft Defenderポータルにデバイスが表示されない、SENSEサービスが起動しない、プロキシで通信が止まるといったトラブルにつながります。
対象OSとサーバー世代を確認する
Windows Serverのオンボーディングでは、Windows Server 2012 R2以降、Windows Server version 1803、Azure Stack HCI OS version 23H2以降などが対象として整理されています。Windows Server 2019、2022、2025ではDefender for Endpoint関連コンポーネントが組み込まれている一方、Windows Server 2012 R2や2016では前提条件や統合ソリューションの状態確認が重要です。(Microsoft Learn)
Windows Server 2012 R2および2016では、最新のServicing Stack Update、累積更新プログラム、Microsoft Defender Antivirus機能、最新プラットフォームバージョンなどの確認が求められます。特にWindows Server 2016では、Microsoft Defender Antivirusが機能としてインストールされ、更新済みであることを確認してから作業する必要があります。(Microsoft Learn)
既存ウイルス対策製品との共存を確認する
サードパーティ製のウイルス対策・マルウェア対策を使っているサーバーでは、Microsoft Defender Antivirusをパッシブモードで動作させる設計が必要になる場合があります。公式ドキュメントでも、Microsoft以外のアンチマルウェア製品を使う場合は、インストールおよびオンボーディング時にパッシブモードを設定するよう案内されています。(Microsoft Learn)
この確認を飛ばすと、既存製品とDefender Antivirusの役割が曖昧になり、検出の重複、性能劣化、除外設定の不整合が起きやすくなります。とくにファイルサーバー、DBサーバー、バックアップサーバーでは、除外設定やスキャンタイミングを運用チームと調整しておきましょう。
Standard接続かStreamlined接続かを決める
オンボーディングパッケージ取得時には、接続方式としてStandardまたはStreamlinedを選択します。Standardは従来のDefender for EndpointサービスURL群を使う方式で、Streamlinedは接続先URLや静的IP範囲の管理を簡素化する方式です。(Microsoft Learn)
Streamlined接続は、機能やエンドユーザー体験を変えるものではなく、主にサービス接続に使うURLやIPの構成を変えるものです。既存の標準URLが廃止される予定はないとされているため、既存環境を急いで置き換えるというより、新規展開やネットワーク設計見直しのタイミングで検討するのが安全です。(Microsoft Learn)
ただし、Streamlined接続には前提条件があります。Windows Server 2012 R2や2016でMMAエージェントのまま運用している環境はStreamlined接続の対象外で、統合エージェントへの移行が必要です。TLS検査はサポートされず、ユーザー認証を強制するプロキシも接続を壊す可能性があるため、ネットワーク担当との事前確認が欠かせません。(Microsoft Learn)
ローカルスクリプトでオンボードする基本手順
実作業では、サーバーごとに「取得」「展開」「管理者権限で実行」「ポータル確認」「検出テスト」の順で進めます。作業ログを残すため、対象サーバー名、実行者、実行日時、パッケージ取得日時、接続方式、検証結果を記録しておくと、後日の監査やトラブル対応が楽になります。
| 手順 | 作業内容 | 確認ポイント |
|---|---|---|
| 事前確認 | ライセンス、権限、OS、ネットワーク疎通を確認 | 少なくともSecurity Administrator相当の権限を確認 |
| パッケージ取得 | DefenderポータルのOnboardingからZIPを取得 | 接続方式とDeployment methodを確認 |
| ファイル展開 | ZIPを対象サーバー上の分かりやすい場所へ展開 | 展開後の.cmdファイル名を確認 |
| 管理者実行 | 管理者権限のコマンドプロンプトで実行 | 通常ユーザー権限で実行しない |
| ポータル確認 | Assets > Devicesで対象サーバーを確認 | 反映まで時間がかかる場合がある |
| 検出テスト | テストアラートでオンボード状態を確認 | SOCへ事前連絡して誤検知扱いを避ける |
公式手順では、ダウンロードするZIPファイルはGatewayWindowsDefenderATPOnboardingPackage.zip、展開後のスクリプトはWindowsDefenderATPLocalOnboardingScript.cmdとして案内されています。実行は管理者権限のコマンドプロンプトで行います。(Microsoft Learn)
実行コマンド自体はシンプルです。
WindowsDefenderATPLocalOnboardingScript.cmdただし、シンプルだからこそ実行後の確認が重要です。「コマンドが最後まで進んだ」だけでは、Defender for Endpointに正しく報告できているとは限りません。必ずMicrosoft Defenderポータルのデバイス一覧と、必要に応じてSENSEサービスの状態を確認してください。
sc.exe query senseサーバー向けのオンボーディング検証では、Defender for EndpointセンサーであるSENSEが実行状態であることを確認する流れが示されています。問題がある場合は、オンボーディングのトラブルシューティング手順を参照し、イベントログやエラーIDを確認します。(Microsoft Learn)
サンプル収集設定はプライバシーと調査効率のバランスで決める
ローカルスクリプト手順では、サンプル収集設定も重要です。Defender XDRから詳細分析のためにファイル提出が要求された場合、端末側のレジストリ設定AllowSampleCollectionによって、サンプル共有を許可するかどうかを制御できます。値が0ならサンプル共有を許可せず、1ならすべてのファイルタイプの共有を許可します。レジストリキーが存在しない場合、既定値は1とされています。(Microsoft Learn)
機密性の高いサーバーでは、既定値のままにせず、データ分類とインシデント対応方針に合わせて設定を決めるべきです。たとえば、研究開発サーバー、個人情報を扱う業務サーバー、法務関連ファイルを保管するサーバーでは、サンプル提出の許可範囲をセキュリティ部門と法務・コンプライアンス部門で確認しておくと安全です。
サンプル共有を無効化する例は次のとおりです。
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows Advanced Threat Protection]
"AllowSampleCollection"=dword:00000000ここで大切なのは、「セキュリティを強くするために常に共有する」「機密情報があるから常に共有しない」と単純化しないことです。サンプル共有を止めれば情報漏えいリスクを抑えやすくなる一方、深いマルウェア分析や自動調査の精度に影響する可能性があります。サーバーの用途ごとに、標準設定を決めておきましょう。
オフボーディング手順も同時に見直す
オンボードだけでなく、オフボーディングの手順も確認が必要です。公式ドキュメントでは、ローカルスクリプトによるオフボーディングパッケージはダウンロード日から7日で期限切れになり、期限切れのパッケージは拒否されると説明されています。また、同じデバイスにオンボーディングポリシーとオフボーディングポリシーを同時に展開しないよう注意されています。(Microsoft Learn)
オフボードすると、そのデバイスはポータルへセンサーデータを送信しなくなります。ただし、デバイスのデータやアラートへの参照は最大6か月保持されるとされています。サーバー廃止、環境移行、M&A、テナント統合などの場面では、オフボード後のデータ保持と調査履歴の扱いも運用手順に入れておくべきです。(Microsoft Learn)
よくある失敗と対策
ローカルスクリプト方式で多い失敗は、スクリプトそのものよりも周辺準備にあります。とくに、権限、ネットワーク、ファイル名、確認手順の4つは事前に潰しておきましょう。
| 失敗しやすいポイント | 原因 | 対策 |
|---|---|---|
| DefenderポータルにEndpointsが表示されない | 環境初期化待ち、権限不足、ライセンス不足 | 数分待つ、他のDefender XDR機能を開く、Security Administrator権限とライセンスを確認 |
| スクリプト実行後にデバイスが出ない | 通信不可、SENSE未起動、実行エラー | 1時間程度の反映待ち後、イベントログとsc.exe query senseを確認 |
| ZIPファイルが見つからない | 古いファイル名を前提にした手順・自動化 | GatewayWindowsDefenderATPOnboardingPackage.zipを前提に修正 |
| プロキシ環境で失敗する | TLS検査、ユーザー認証プロキシ、URL許可不足 | Defender for Endpoint通信を事前検証 |
| 2012 R2 / 2016で失敗する | 前提更新不足、統合エージェント未対応 | SSU、LCU、Defender Antivirus、統合ソリューションを確認 |
| オフボードできない | オフボーディングパッケージ期限切れ | 作業直前に新しいパッケージを取得 |
| SOCに不要なアラートが上がる | 検出テストの事前連絡不足 | テスト日時、対象サーバー、想定アラートを共有 |
オンボーディング後にデバイス一覧へ表示されない場合、公式トラブルシューティングでは、スクリプト実行結果をイベントビューアーのApplicationログで確認し、WDATPOnboardingイベントソースやエラーIDを確認する流れが示されています。エラーIDには、レジストリ書き込み失敗、SENSEサービス起動失敗、管理者権限不足などが含まれます。(Microsoft Learn)
本番展開ではローカルスクリプトから卒業する判断基準を持つ
最初の数台をローカルスクリプトで検証するのは自然です。しかし、検証が成功した後も同じ方法で増やし続けると、運用負荷と抜け漏れが急に増えます。次のいずれかに当てはまる場合は、ローカルスクリプトではなく、管理基盤を使った展開に切り替えましょう。
- 対象サーバーが10台を超える
- 今後も継続的にサーバーが増減する
- 展開結果を監査証跡として残す必要がある
- 複数拠点やDMZをまたいで展開する
- プロキシやファイアウォールの例外管理が複雑
- Windows Server 2012 R2 / 2016の移行が絡む
- SOCがデバイス登録状況を継続的に監視する必要がある
Microsoftの展開方式選定では、クラウドネイティブ環境ならIntune、オンプレミス資産を活用する環境ならConfiguration ManagerやActive Directory Domain Services、評価や小規模環境ならローカルオンボーディングという考え方が示されています。つまり、ローカルスクリプトは「最初の一歩」には向いていても、「標準展開方式」にするには慎重な判断が必要です。(Microsoft Learn)
管理者が今すぐ確認すべきチェックリスト
今回のMicrosoft Defender for Endpointローカルスクリプト更新を受けて、管理者は次の順に確認すると効率的です。
| 優先度 | 確認内容 | 対応の目安 |
|---|---|---|
| 高 | 社内手順書のZIPファイル名 | 古いWindowsDefenderATPOnboardingPackage.zip表記があれば修正 |
| 高 | ローカルスクリプトの利用台数 | 10台超なら別展開方式を検討 |
| 高 | Windows Server 2012 R2 / 2016の前提条件 | 更新プログラム、Defender Antivirus、統合エージェントを確認 |
| 高 | Standard / Streamlined接続の選択 | プロキシ、TLS検査、URL許可ルールを確認 |
| 中 | サンプル収集設定 | 機密サーバーの既定値を確認 |
| 中 | オフボーディング手順 | 7日期限と画面名を手順書へ反映 |
| 中 | 検出テストの運用 | SOC通知、アラート確認、証跡保存を標準化 |
| 低 | 一時サーバー・検証VM | 資産台帳とDefenderデバイス一覧を突合 |
まずは、社内Runbookと展開スクリプトが更新後のファイル名に対応しているかを確認してください。そのうえで、現在ローカルスクリプトで運用している対象台数を棚卸しし、10台を超える場合はグループポリシー、Configuration Manager、Defender for Cloud連携などへ移行する計画を立てるのが現実的です。
Microsoft Defender for Endpointのローカルスクリプトオンボードは、少数のWindows Serverをすばやく登録するには便利です。一方で、運用で本当に重要なのは「登録したつもり」で終わらせないことです。ファイル名、権限、接続方式、SENSEサービス、デバイス一覧、検出テストまでを一連のチェックとして標準化し、検証環境から本番展開へ進む段階で、管理基盤を使った展開方式へ切り替えましょう。
コメント