Windows Server 2012 R2 だけ PRTG や PerfMon（パフォーマンス モニター）からリモートのパフォーマンスカウンターが取得できず、Windows Server 2019 は問題なく取れる——同一ドメインでも起こり得る厄介な現象です。切り分けポイントを押さえつつ、最終的に最短で安定させるための「PRTG リモートプローブ」方式への切り替え手順と注意点をまとめます。
症状を正確に言語化する
今回の状況は、監視の世界でよくある「WMI は通るのに、パフォーマンスカウンターだけが取れない」パターンです。ポイントはPRTG の不具合ではなく、Windows の“リモート パフォーマンスカウンター取得経路”そのものが成立していないことにあります。
| 役割 | OS / 製品 | 結果 | 補足 |
|---|---|---|---|
| 監視サーバー | Windows Server 2016（PRTG） | — | 同一ドメイン内で監視 |
| 監視対象A | Windows Server 2019 | 取得できる | PerfMon のリモート接続もOK |
| 監視対象B | Windows Server 2012 R2 | 取得できない | PRTG だけでなく PerfMon からも接続不可。一方で WMI は取得可能 |
ここで大事なのは、「同じドメイン」「ドメイン管理者」「ファイアウォール確認済み」でも、PerfMon 系だけが失敗することがあるという現実です。原因を 1 つに特定できるケースもありますが、現場では複数要因が絡むことも多く、調査が長期化しがちです。
WMI とリモート パフォーマンスカウンターは“別ルート”
「WMI が取れるなら大丈夫」と思いがちですが、PerfMon（パフォーマンス モニター）のリモート取得は別の要求を持ちます。PRTG のセンサーも同様で、WMI 系センサーが動くのに、Windows Performance Counter 系センサーだけが失敗する典型パターンになります。
| 観点 | WMI | PerfMon / パフォーマンスカウンター |
|---|---|---|
| 取得の仕組み | WMI プロバイダー経由で情報を取得 | パフォーマンスカウンター API / Perflib で取得 |
| 依存しやすい要素 | WMI サービス、WMI リポジトリ、名前解決、権限 | RPC/DCOM、Remote Registry、カウンターの公開状態、カウンター破損/無効化など |
| 失敗時の特徴 | センサー全体が遅い／タイムアウト／認証失敗 | 特定 OS だけ NG、特定カウンターだけ NG、PerfMon からも繋がらない |
| 運用上の意味 | 「取れる項目を増やす」方向で回避しやすい | 「経路を成立させる」か「方式変更（プローブ配置）」が効く |
つまり、2012 R2 のみ取得できない場合は、PRTG 側で“何かを直す”よりも、2012 R2 側の PerfCounter リモート経路を成立させる（＝OS 側の要件を満たす）必要があります。
Windows Server 2012 R2 で詰まりやすい代表パターン
Windows Server 2012 R2 は、現役の環境でも「長年の運用で積み重なった設定差」「過去のハードニング」「役割追加・削除の履歴」「更新の当たり方の差」などが発生しやすい世代です。その結果、2019 では問題にならないのに 2012 R2 では PerfMon が詰まる、ということが起こります。
- Remote Registry サービスが停止（無効化や手動起動のまま）
- RPC/DCOM の到達性が不十分（セグメント/FW/ポリシー/IPS の影響で “WMI は通るが PerfMon は落ちる”）
- UAC のリモート制限やローカルアカウント使用時のトークン問題
- カウンター自体の破損・欠落（Perflib/レジストリの不整合。イベントログに Perflib/LoadPerf が出る）
- 「特定のカウンターだけ」無効化（レジストリ設定やサードパーティ製品で無効化される）
- セキュリティ製品・運用ツールによるブロック（RPC/DCOM を広く使う通信が抑止される）
ここまでくると、原因を 1 つずつ潰すのは可能でも、監視を早く安定させたい運用ではコストが重くなりやすいです。
切り分けの最短ルート（中央サーバーから直接取得したい場合）
「それでも中央（監視サーバー）から直接取りたい」場合に、無駄な遠回りを避けるための切り分け順を整理します。最初にPerfMon 相当の取得が PowerShell でできるかを見て、失敗するなら“PRTG ではなく OS の問題”であることを明確にします。
Get-Counter でリモート取得できるか確認する
監視サーバー（Windows Server 2016）側で、対象 2012 R2 に対してテストします。
Get-Counter -ComputerName WS2012R2HOST -Counter '\Processor(_Total)\% Processor Time'ここでエラーが出る場合、PRTG のセンサー設定変更では解決しません。PerfCounter のリモート経路が成立していないためです。逆に成功するなら、PRTG 側の資格情報・センサー種類・タイムアウトの問題に寄せて考えられます。
よくあるエラーメッセージの読み替え
表示される文言は環境で揺れますが、意味合いをざっくり掴むだけでも調査が速くなります。
| 見えがちなエラー例 | 示唆 | 次に見るべき場所 |
|---|---|---|
| アクセスが拒否されました／権限がありません | 資格情報・グループ・UAC リモート制限 | 対象側のローカルグループ、GPO、PRTG の認証情報 |
| RPC サーバーを利用できません／ネットワーク パスが見つかりません | 名前解決、FW、RPC/DCOM 到達性 | DNS、FW ルール、経路、セキュリティ製品 |
| 指定されたオブジェクトが見つかりません／カウンターが存在しません | カウンター破損、無効化、カテゴリ欠落 | ローカル perfmon、イベントログ（Perflib/LoadPerf） |
Remote Registry の状態確認
リモート パフォーマンスカウンター取得では、カウンター名の解決などで Remote Registry が関与することが多く、まず疑う価値があります。
sc \\WS2012R2HOST query RemoteRegistry停止している場合は起動し、自動起動にするかはセキュリティ方針と相談します。監視要件が強いなら、監視に必要な範囲だけ有効化する設計に寄せます。
権限の最小要件を再確認する
「ローカル管理者だから大丈夫」の前提でも、運用では“最小権限”での監視が求められることが増えています。PerfMon で必要になりやすいのは次のグループです。
- Performance Monitor Users（閲覧系）
- Performance Log Users（ログ作成/収集系）
PRTG の実行アカウントやセンサーに設定する認証情報を、必要十分なグループに入れて試すと、権限問題の切り分けが進みます。
通信要件を“WMI と分けて”考える
WMI は許可されているのに PerfMon が落ちる場合、ネットワーク的には「RPC/DCOM の扱い」が差分になりやすいです。Windows の設定だけでなく、セグメント間 FW、UTM、IPS/IDS、EDR の通信制御も含めて、“PerfMon に必要な範囲の RPC/DCOM を通す”視点が必要です。
カウンターの破損・欠落を疑う
対象 2012 R2 自身で PerfMon を開いたときに、カウンターが表示されない・カテゴリが欠ける・追加時にエラーになる場合は、カウンター破損の可能性があります。代表的な復旧の試みとして、次のようなコマンドが検討対象になります（実行前にバックアップと手順検証を推奨します）。
lodctr /R
winmgmt /resyncperfただし、運用上は「復旧作業の影響」「作業時間」「再発リスク」も含めて評価が必要です。監視は止めたくない、という前提なら、次に紹介する方式変更が現実的です。
結論：PRTG のリモートプローブで“計測地点”を寄せると安定する
今回の解決は、PRTG の「リモートプローブ（Remote Probe）」を導入し、監視対象側（または同一セグメント内）で計測して PRTG 本体へ報告する方式に切り替えることでした。
中央サーバー（Windows Server 2016）から 2012 R2 の PerfMon を無理に取りに行くのではなく、計測地点を 2012 R2 の近くに置くことで、RPC/DCOM や FW の“越境要件”を大幅に減らせます。結果として、特定サーバーだけ取得できない、といったブレが消え、監視が安定します。
リモートプローブ導入のメリット・デメリット
| 観点 | メリット | デメリット / 注意点 |
|---|---|---|
| 安定性 | PerfMon の“リモート越境”を避けられ、取得失敗が減る | プローブ障害時に配下の監視が止まる |
| ネットワーク | FW 設計が「プローブ→PRTG 本体」中心に単純化 | プローブから PRTG 本体への到達性（経路/ポート/名前解決）が必須 |
| セキュリティ | 越境で広い RPC/DCOM を開けずに済む場合がある | プローブホストの権限管理・パッチ適用を運用に組み込む必要 |
| 工数 | 原因究明より早く“止血”できることが多い | プローブ用の Windows ホスト確保（物理/VM）が必要になる |
リモートプローブ配置の考え方
| 配置 | おすすめの状況 | メリット | 注意点 |
|---|---|---|---|
| 監視対象（2012 R2）に同居 | 最短で直したい／対象が少ない | 通信経路が最短。PerfCounter は実質ローカル取得になりやすい | 対象サーバーのリソース消費、変更管理の対象が増える |
| 同一セグメントの小型 VM に設置 | 対象が複数台／監視専用ホストを置ける | 対象に触れずに改善。センサーをまとめて担当できる | VM の保守、パッチ、バックアップなど運用が必要 |
| 拠点・ネットワーク境界の内側に設置 | 拠点間越境・DMZ・FW が複雑 | 越境通信を最小化し、FW 設計がシンプルになる | プローブから PRTG 本体へ到達するためのルール設計が必要 |
導入手順（実務で迷わないレベル）
- 配置場所を決める
2012 R2 自体に入れるか、同一セグメントの監視用 VM に入れるかを決めます。まずは“最短で止血”なら同居が速いです。 - PRTG 本体（Core Server）へ到達できることを確認
リモートプローブは PRTG 本体へ接続してデータを送ります。名前解決（DNS）と通信（FW/経路）を先に固めます。FW ルールは「広い RPC/DCOM を開ける」よりも、「プローブ→本体の必要最小限を許可」の方がレビューが通りやすいことが多いです。 - リモートプローブをインストール
PRTG のインストーラーで「Remote Probe」を選び、ウィザードに従って登録します。インストール後、PRTG の画面に新しいプローブが追加されていることを確認します。 - 監視対象（2012 R2）を“そのプローブ配下”に追加
同じデバイスでも、どのプローブが計測するかで結果が変わります。2012 R2 をリモートプローブ配下に置く（またはセンサーを移す）ことで、PerfCounter の取得経路が変わります。 - 問題のセンサーを移行・再作成して確認
PerfMon 系（Windows Performance Counter 系）のセンサーを中心に、値が取れるかを確認します。取得できるようになったら監視間隔やしきい値を再調整します。
センサー移行で失敗しないコツ
- まずは「同じカウンターを 1 本だけ」で成功体験を作る（CPU など）
- 取得できたら対象カウンターを増やす（ディスク、メモリ、プロセスなど）
- しきい値は移行直後に厳しくしすぎない（まずはデータ欠損をなくす）
- 「WMI で代替できる項目」は WMI に寄せ、PerfCounter は必要箇所に絞る
リモートプローブ運用で意識したいポイント
導入して終わりではなく、運用で詰まらないための勘所も押さえておくと安心です。
認証情報は「監視専用アカウント」を基本にする
ドメイン管理者で何でも取れてしまう状態は、監査やセキュリティの観点で避けたいところです。可能であれば、監視用のドメインアカウントを作り、対象サーバー側では次のいずれかで権限付与します。
- Performance Monitor Users を付与（原則）
- 取得できないカウンターがある場合のみ、最小範囲で追加権限
プローブ障害時の影響範囲を見える化する
プローブは“計測の要”になるため、落ちるとその配下の監視がまとめて止まります。次のように影響範囲を小さくする設計が現実的です。
- 拠点/セグメント単位でプローブを分ける（1 台に集約しすぎない）
- プローブサーバーのパッチ適用・再起動の手順を運用化する
- PRTG 側でプローブの死活監視（ハートビート）を必ず有効化する
「プローブを入れたのに取れない」場合の見方
プローブを監視対象と同居させても取れない場合は、ネットワークではなくカウンター自体の問題が濃厚です。次の観点で確認します。
| 確認 | 見る場所 | 典型的な示唆 |
|---|---|---|
| ローカル PerfMon で同じカウンターが見えるか | 2012 R2 上の perfmon.exe | ローカルでも無理なら、カウンター破損/無効化の可能性 |
| イベントログに Perflib / LoadPerf が出ていないか | イベント ビューアー | カウンター再構築（lodctr）検討 |
| PRTG の資格情報で権限不足になっていないか | PRTG のセンサーエラー | 最小権限で不足していれば権限付与を見直す |
それでも中央から直接取りたいときの落としどころ
組織の方針で「監視ソフトは対象に入れない」「プローブを増やせない」となることもあります。その場合は、“完全解決”よりも運用品質を落とさない落としどころを選ぶのがおすすめです。
PRTG は WMI センサー主体に寄せる
今回のケースでは WMI は取得できているため、代替できる項目は WMI センサーで取るのが最短です。WMI は遅い・重いと言われることもありますが、監視頻度を調整し、対象を絞れば十分運用できます。
必要な指標だけを「ローカル取得→ログ化→回収」にする
どうしてもパフォーマンスカウンターでしか取れない指標がある場合、対象側で定期取得してログに落とし、中央で回収する（ファイル共有や転送）という設計もあります。リアルタイム性は落ちますが、監視要件によっては十分です。
2012 R2 を“監視しやすい状態”に寄せる
最終的に長期運用を見据えるなら、2012 R2 の役割を整理し、更新・設定・セキュリティ基準を 2019/2022 と揃える方向が本筋です。監視トラブルは、将来の更改や統合のサインでもあります。
まとめ
Windows Server 2012 R2 だけリモートのパフォーマンスカウンター（PerfMon / PRTG）が取得できない場合、WMI が取れることがむしろ混乱を招きます。WMI と PerfCounter は別ルートであり、OS 世代や設定差で詰まりやすいからです。
現場で最短・最安定を狙うなら、PRTG のリモートプローブを監視対象側（または同一セグメント）に置き、計測地点を寄せるのが強力な解決策になります。原因究明に時間を使い切る前に、監視を止めないための“方式変更”という選択肢を、ぜひ運用の武器として持っておくと楽になります。
コメント