Windows Server 2019をインターネット未接続の閉域網で運用しているのに、DeviceSetupManagerのイベント（Event ID 202）で「Network List Manager reports no connectivity to the internet」が出続けることがあります。本記事ではNLM/NCSIの仕組み、止まった対処（Device Setup Manager無効化）と注意点、代替策を整理します。
起きている現象：DeviceSetupManager / Event ID 202 とは
閉域網のWindows Server 2019で、イベントビューアーに次のようなイベントが繰り返し記録されることがあります。
- ログ：アプリケーションとサービス ログ → Microsoft → Windows → DeviceSetupManager → Admin
- ソース：DeviceSetupManager
- イベントID：202
- 内容の傾向：Network List Manager（NLM）が「インターネット接続なし」と報告したため、オンライン取得を伴う処理が行えないという警告
閉域網では外部へ出られないため、ログの主旨自体は「想定どおり」です。しかし、監視や運用では次のような“実害”が出やすく、結果として対策が必要になります。
| 困りごと | 現場で起きがちな影響 | ありがちな対応 |
|---|---|---|
| 警告ログが増え続ける | ログ監視がノイズ化し、本当に重要なアラートが埋もれる | OS側で発生源を止める／監視側で除外する |
| セキュリティ監査で指摘される | 「なぜインターネットへ出ようとしているのか？」の説明が必要 | NCSIの仕組みを説明し、閉域網設計と矛盾しない運用ルールを整備 |
| 一部の自動化が失敗扱いになる | ログをトリガーにしているジョブが誤検知する | イベントIDやソース単位での例外ルールを設計 |
Network List Manager（NLM）とは何か
Network List Manager（NLM）は、Windowsがネットワークを「識別・分類」し、その状態（プロファイル／接続性）をアプリやOS内部へ提供する仕組み（API/機能群）です。サーバーでも“ネットワークの状態把握”は必要なため、閉域網でも動作します。
混同されやすい用語を整理すると、全体像が見えます。
| 名称 | 役割（ざっくり） | 代表的なサービス名 |
|---|---|---|
| Network List Manager（NLM） | ネットワーク一覧・接続状態をアプリへ提供する窓口（COM/API） | （機能として提供。内部的に下記サービスに依存） |
| Network Location Awareness（NLA） | ネットワークの場所（ドメイン/プライベート等）の判定材料を集める | NlaSvc |
| Network List Service | ネットワークのプロファイル管理（NLA結果の保持など） | netprofm |
| NCSI（到達性判定） | 「インターネットへ到達できるか」を判定する仕組み | NlaSvcの一部として動くことが多い |
つまり、イベント本文に出てくる「Network List Manager」は単体の“アプリ”ではなく、OSがネットワーク状態を判定・通知する仕組みの一部です。
なぜ“インターネット接続確認”が走るのか：NCSIの動作
WindowsにはNCSI（Network Connectivity Status Indicator）という到達性判定があり、ネットワーク変化（起動、NICのリンク変化、IP/DNS変更、VPN接続、仮想NIC追加など）を契機に、アクティブテスト（実際にDNS/HTTP/HTTPSで外部到達を試す）を行うことがあります。
閉域網では外部の名前解決やHTTP(S)が遮断されているため、アクティブテストが失敗して「インターネットなし」と判定されます。これ自体は正常ですが、判定結果を参照するコンポーネントが“警告ログ”として残すと、今回のように目立つ形になります。
アクティブテストで何をしているのか（代表例）
Windowsのバージョンや更新状況で細部は変わり得ますが、一般的には次のようなチェックが行われます。
| チェックの種類 | 目的 | 閉域網での結果 |
|---|---|---|
| DNSの到達性 | 外部の特定レコードが引けるか、DNSが正しく動くか | 外部DNSへ出ない設計なら失敗しやすい |
| HTTP/HTTPSの到達性 | 既知のURLへアクセスできるか（キャプティブポータル検知を含む） | 出口遮断なら失敗（「インターネットなし」判定） |
| パッシブ情報 | ゲートウェイ/ルーティング/リンク状態などの観測情報 | “ネットワークはある”と見えるが、外部到達は不明のまま |
重要なのは、ここでいう“インターネット接続確認”はユーザーがブラウズするための通信ではなく、OSが接続状態を判定するための短い確認通信だという点です。閉域網でも判定処理は走り得ます。
なぜ DeviceSetupManager が Event ID 202 を記録するのか
Device Setup Managerは、PnPデバイスの追加・構成に関わるコンポーネントです。環境によっては、次のような“オンライン取得”の要素が絡みます。
- デバイスのメタデータ（表示名、アイコン、追加情報など）の取得
- ドライバーが足りない/古い場合の探索（Windows Update側のドライバー配布を参照する設計の影響）
- デバイス初期構成に必要な補助情報の取得
このとき、前提条件として参照されるのが「ネットワークの接続状態（NLM/NCSI）」です。閉域網では「インターネットなし」判定が返るため、DeviceSetupManager側が“オンライン取得できない”という警告を残す流れになり、結果としてEvent ID 202が蓄積します。
サーバー用途では周辺機器の抜き差しが少なく、標準ドライバーや事前配布ドライバーで十分なことも多いので、実害がないのにログだけが増える、という構図が起きやすいのが特徴です。
解決策：Device Setup Manager サービスを無効化（停止）して止める
今回の結論として、Device Setup Manager サービスを無効化（停止）することで、該当のEvent ID 202が止まった、という実績がある対処です。閉域網のサーバーで「新規デバイス追加をほとんどしない」「ドライバーは運用手順で手動適用する」なら、現実的な選択肢になります。
GUIでの手順（services.msc）
- 「ファイル名を指定して実行」から services.msc を起動
- 一覧から Device Setup Manager を開く
- 「スタートアップの種類」を 無効 に変更
- 「サービスの状態」が実行中なら 停止 を押す
- 必要に応じてサーバーを再起動し、イベントが止まるか確認
PowerShellでの設定例（台数が多い運用向け）
サービス名（Name）は表示名（DisplayName）と異なることがあるため、まず確認してから無効化するのが安全です。
# まず“表示名”で候補を確認
Get-Service | Where-Object { $_.DisplayName -like "*Device Setup*" } |
Format-Table Name, Status, StartType, DisplayName
# 代表例：サービス名が DsmSvc の場合
Stop-Service -Name DsmSvc -Force
Set-Service -Name DsmSvc -StartupType Disabled
# 状態確認
Get-Service -Name DsmSvc | Format-List Status, StartType, Name, DisplayNameイベントが止まったか確認する（運用で詰まらないコツ）
「止まった/止まっていない」を曖昧にしないため、確認手順を固定化すると運用が楽になります。
- イベントビューアーで該当ログを開き、現在のログのフィルターで イベントID=202 を指定
- 対策前後のタイムスタンプで、一定期間（例：起動後24時間）発生しないことを確認
- NIC再起動やIP変更など、ネットワーク変化を意図的に起こしても再発しないかを見る
| 確認項目 | 確認方法 | 期待する状態 |
|---|---|---|
| サービスが無効化されている | services.msc / Get-Service | StartTypeがDisabled |
| Event ID 202の新規発生 | ログフィルター／時刻確認 | 発生しない（または大幅に減る） |
| デバイス追加時の影響 | （必要なら）テストでUSB/仮想NICを追加 | 業務に必要な動作が維持される |
補足：無効化の注意点と“やってはいけない判断”
Device Setup Managerの無効化は、ログ対策として有効な反面、デバイス追加・ドライバー自動取得の挙動に影響する可能性があります。閉域網サーバーで典型的なシーン別に、判断の目安をまとめます。
| 運用シーン | リスク感 | おすすめ |
|---|---|---|
| 固定構成の物理サーバー（機器追加ほぼ無し） | 低 | 無効化でログノイズを止める判断がしやすい |
| 仮想基盤上のVM（vNIC追加や仮想デバイスの変更があり得る） | 中 | 無効化するなら、変更手順（増設・統合サービス更新）で検証を入れる |
| USB機器、HBA、特殊NICなどを追加する可能性がある | 高 | 無効化より、別の根本策（NCSI制御や運用ルール）を優先 |
戻す必要が出た場合に備え、ロールバック手順も一緒に残しておくと安心です。
# 例：元に戻す（Manual / Automatic は要件で選択）
Set-Service -Name DsmSvc -StartupType Manual
Start-Service -Name DsmSvc根本的に止めたい場合：NCSIのアクティブテストを無効化する
「Device Setup Managerは止めたくないが、インターネット到達性確認（アクティブテスト）を止めたい」場合は、NCSIのアクティブテスト無効化を検討できます。
ただし、これはOSの接続状態判定そのものに影響します。閉域網では“インターネットなし”が正しいため、困ることは少ないこともありますが、NCSIの結果に依存するアプリやエージェントがある環境では、挙動が変わる可能性があります。
グループポリシー（ドメイン一括適用向け）
- コンピューターの構成
- 管理用テンプレート
- システム
- インターネット通信の管理
- インターネット通信設定
- 「Windows ネットワーク接続状態インジケーターのアクティブ テストをオフにする」を有効
レジストリ（単体サーバー／Server Core向け）
代表的な制御は次のとおりです。
パス：HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NlaSvc\Parameters\Internet
値 ：EnableActiveProbing（DWORD）
内容：0 = 無効、1 = 有効（既定）変更後は再起動が確実です。サービス再起動で済ませる場合でも、業務影響のない時間帯に計画的に行うのがおすすめです。
副作用として知っておくべきこと
- 接続状態の判定が変わり、OSやアプリが“オフライン前提”の振る舞いになることがある
- NCSI結果を参照する監視・エージェントがある場合、要件どおりに動くか検証が必要
- 「インターネットなし」状態が“正しい”閉域網では、正しさは変わらないが、判定方法だけが変わる
“社内だけ”で到達性確認を成功させる（必要な場合のみ）
閉域網でも「インターネットは無いが、社内サービスには到達できる」ことをOSに認識させたいケースがあります。たとえば、あるエージェントがNCSIの結果で通信処理を抑制してしまい、社内の更新サーバーや管理サーバーへ接続できなくなる、といったパターンです。
その場合は、NCSIの参照先を社内エンドポイントへ置き換える設計が選択肢になります。ただし、構成によっては「インターネットあり」と誤認させる形になり得るため、閉域網の設計思想（出口遮断）や監査要件と矛盾しないか、必ず確認してください。
閉域網＋WSUS運用でのおすすめの考え方
閉域網でWSUSを使っている場合、外部インターネットへ出ないことが要件であることがほとんどです。したがってEvent ID 202は“異常”というより“運用設計の課題”として扱うのが現実的です。
次のように考えると判断しやすくなります。
| 優先したいこと | おすすめ | 理由 |
|---|---|---|
| ログを確実に減らしたい（固定構成） | Device Setup Manager無効化 | 効果が分かりやすく、運用負担が減る |
| デバイス追加の柔軟性を残したい | NCSIアクティブテスト無効化 | 到達性確認を抑えつつ、デバイス側の機能を残しやすい |
| OS設定を変えたくない | 監視側で除外 | 副作用を最小にし、ログの意味を運用ルールで整理できる |
トラブルシューティング：止まらない／別ログが増えるとき
サービスの対象を取り違えていないか
表示名が似ているサービスがあるため、無効化したサービスが本当に「Device Setup Manager」か確認します。
# “Device Setup” を含むサービスを列挙
Get-Service | Where-Object { $_.DisplayName -match "Device Setup" } |
Format-Table Name, Status, StartType, DisplayNameEvent ID 202以外のログが原因になっていないか
今回止めたいのが「202というイベント」なのか、「到達性確認そのもの」なのかで対策は変わります。到達性確認が残る限り、別のソース（NLA関連ログなど）で似た趣旨のイベントが出ることもあります。監視ルールを組む場合は、ソース＋ログ名＋イベントIDで対象を明確にするのがコツです。
PowerShellでログを横断的に確認する
イベントビューアー操作が難しい場合は、PowerShellで該当イベントだけ抽出すると切り分けが速いです。
# 直近のEvent ID 202を10件確認（ログ名は環境に合わせて調整）
Get-WinEvent -LogName "Microsoft-Windows-DeviceSetupManager/Admin" |
Where-Object { $_.Id -eq 202 } |
Select-Object -First 10 TimeCreated, Id, LevelDisplayName, Messageまとめ
Windows Server 2019の閉域網運用でも、OSはネットワーク状態を判定するためにNLM/NCSIを動かします。その結果、DeviceSetupManagerが参照する接続性が「インターネットなし」となり、Event ID 202として警告が残ることがあります。
ログノイズとして困る場合、実際に止まった対処としてDevice Setup Managerサービスの無効化（停止）が有力です。ただしデバイス追加やドライバー取得の挙動に影響し得るため、サーバーの用途（固定構成か／変更があるか）に合わせて選んでください。根本的に到達性確認を制御したいなら、NCSIのアクティブテスト無効化などの設定も検討できます。
コメント