Windowsイベント転送を使えば、複数の端末で発生したログを一元管理できてとても便利です。しかしソース開始方式で構成したとき、WinRMのエラーやイベントが転送されないといったトラブルに悩まされるケースが少なくありません。本記事では、具体的な対処方法を分かりやすく解説します。
Windowsイベント転送(ソース開始方式)の概要
Windowsイベント転送(Windows Event Forwarding: WEF)には「コントロール側(Collector)から発信する方式(Collector-initiated)」と「送信側(Forwarder)から発信する方式(Source-initiated)」の2種類があります。ソース開始方式では、イベントログを転送したい側(Forwarder)が能動的にCollectorへ送信を行います。これによりCollector側のサブスクリプション設定とForwarder側のポリシー設定が正しくかみ合わない場合に、エラーが起きやすくなる点が特徴です。
ソース開始方式のメリットとデメリット
ソース開始方式の主なメリットは、Collectorが複数台のForwarderを一括管理しやすい点です。逆にデメリットとしては、ForwarderからCollectorへ通信の許可や、イベント転送先のURL設定など、構成が若干複雑になるという点が挙げられます。
メリット
- Collector側で多数のForwarderを一括管理できる
- Forwarderがオフラインになっても再度オンライン時にイベントをまとめて転送できる
デメリット
- CollectorとForwarder間でのWinRM(WS-Management)通信が必要になる
- ForwarderがCollectorに接続しにいくため、ネットワーク設定やポリシー構成がやや複雑
エラーが発生する典型的な状況
ソース開始方式でWindowsイベント転送を構成した際、特に次のようなエラーが発生するとイベントログがCollectorに送られないことがあります。
The WinRM client sent a request to an HTTP server and got a response saying the requested HTTP URL was not available. This is usually returned by a HTTP server that does not support the WS-Management protocol.
またイベントビューアー上では、EVENT ID 105が記録されるケースが多いです。このエラーは「HTTPサーバーがWS-Managementプロトコルをサポートしていない(または正しく応答できていない)」という趣旨を示します。つまり、WinRM通信に必要な設定やバインディング、ファイアウォールなど、何らかの要素が阻害している可能性が考えられます。
原因として考えられるポイント
Windowsイベント転送のエラーが発生するときに、まず疑うべき代表的な要因をまとめました。
1. IISの既定サイトのHTTPバインディング設定不備
Windows Server側(Forwarder)にIIS(Internet Information Services)がインストールされている場合、IISの設定がWinRM(WS-Management)プロトコルのHTTP通信と競合を引き起こす可能性があります。特にデフォルトWebサイトのバインディング(ポート80)にホスト名が設定されていたり、そもそもHTTPバインディングが無効になっていると、WS-Management側の通信が正常に動作しないことがあります。
2. プロキシ設定の影響
職場などプロキシを利用するネットワーク環境では、netsh winhttp show proxyコマンドで確認できるプロキシ設定がWinRM通信に干渉している場合があります。必要のないプロキシ設定が残っていると、Collectorとの通信が正常に行われず、エラーが起きやすくなります。
3. ポート(5985/5986)やファイアウォールの設定
ソース開始方式では、ForwarderからCollectorへWinRM(ポート5985/TCP for HTTP, 5986/TCP for HTTPS)で通信します。双方向の疎通が必要な場合もあり、Windows Defenderファイアウォールや他のセキュリティソフトウェアでこれらポートがブロックされていないかを再確認することが重要です。
4. WinRM設定そのものの誤り
Collector側の購読(Subscription)設定やForwarder側のWinRMリスナー設定に、URLや認証方式の不整合があることがあります。特にサブスクリプション設定で指定するCollectorのURLが誤っていると、Forwarderが「存在しないURLを要求している」状態となり、エラーにつながります。
5. ネットワークレベルでの問題
ドメイン環境において、グループポリシー(GPO)が競合している、DNSでCollectorの名前解決がうまくいっていないといったネットワーク・インフラ上の問題も見過ごせません。特に複数サイトを跨ぐ環境だと、サイト間のルーティングやファイアウォールルールが原因となるケースもあります。
具体的な解決策
ここからは実際にトラブルシューティングを行う際に役立つ、いくつかの具体的な手法を紹介します。
IISのバインディングを見直す
IISが導入されている環境であれば、まずは既定のWebサイト「Default Web Site」を見直しましょう。以下の手順がポイントです。
- IIS Managerを起動し、「Default Web Site」を右クリックして「Edit Bindings」を選択
- HTTPのバインディングが存在しない場合は、新規追加でポート80を追加(ホスト名は空欄、IPアドレスは“All Unassigned”)
- すでにHTTPバインディングがある場合は、ホスト名が空欄であることを確認(もしホスト名が指定されていたら削除)
- 設定変更後はIISを再起動
| 項目 | 設定例 |
|---|---|
| Type | http |
| IP address | All Unassigned |
| Port | 80 |
| Host name | (空欄) |
IISの設定がWinRMのHTTPリスナーと競合していないかを確認することが大切です。もしポート80を使用しているアプリケーションが他にもある場合、ポートの重複が起きないよう調整が必要になります。
プロキシ設定の確認とリセット
- 管理者権限でコマンドプロンプトまたはPowerShellを起動する
netsh winhttp show proxyで現在のプロキシ設定を確認- 不要なプロキシが設定されている場合は
netsh winhttp reset proxyを実行し、プロキシ設定をリセット
その後、gpupdate /forceなどでグループポリシーを即時適用して、環境が更新されているかを再度チェックしてください。特にプロキシの手動設定や自動検出が有効になっている場合、WS-Managementの通信を阻害しているかもしれません。
ポートやファイアウォール、ネットワークを再点検する
ソース開始方式ではForwarderからCollectorへの通信が要となります。具体的には以下のポートが重要です。
| プロトコル | ポート番号 | 役割 |
|---|---|---|
| HTTP (WinRM) | 5985/TCP | WinRMによるHTTP通信 |
| HTTPS (WinRM) | 5986/TCP | WinRMによるHTTPS通信 |
ファイアウォール設定で、これらポートの受信・送信規則が許可されていないと、当然ながらForwarderはCollectorに到達できません。また、物理的なネットワーク境界でもこれらのポートが遮断されていないか注意してみましょう。
名前解決(DNS)の確認
ForwarderがCollectorのホスト名を正しく解決できていない場合は、pingやnslookupコマンドで名前解決の状態をチェックしてください。ドメイン環境であれば、DNSサーバーにCollectorホスト名が正しく登録されているかを確認します。
WinRM設定を再度見直す
WinRMそのものの設定が不完全である可能性も見逃せません。以下のコマンドで手早く状況を確認しましょう。
winrm quickconfig
このコマンドをForwarderおよびCollectorの両方で実行すると、WinRMが無効になっている場合に有効化を促すプロンプトが表示されます。また、すでに有効化されている場合は現状の設定を確認できます。加えて下記の点もチェックしましょう。
- Collector側の「購読(Subscription)」設定で、ForwarderがアクセスするURL(例:
http://CollectorFQDN:5985/wsman/SubscriptionManager/WEC)が正しいか - セキュリティログを取得するために、Event Log ReadersグループなどにForwarderの送信アカウントが含まれているか
- ドメインポリシーで設定しているWinRMのポリシー(例: 「Allow remote server management through WinRM」など)が正しく構成されているか
SubscriptionManagerURLの設定例
Forwarderのグループポリシーやコマンドで設定する場合、次のような形でURLを指定するケースが多いです。
wecutil qc
winrm set winrm/config/service @{AllowUnencrypted="true"}
winrm set winrm/config/service/auth @{Basic="true"}
winrm create winrm/config/Listener?Address=*+Transport=HTTP
@{Port="5985";Hostname=""}
winrm set winrm/config/client/auth @{Basic="true"}
winrm set winrm/config/client @{TrustedHosts="CollectorFQDN"}
winrm set winrm/config/client @{AllowUnencrypted="true"}
winrm set winrm/config/service @{AllowUnencrypted="true"}
上記は一例ですが、実際にはご利用のセキュリティポリシーや環境要件に合わせて設定する必要があります。HTTPSを利用した暗号化通信を行う場合は、5986ポートや証明書設定が必要となりますのでご注意ください。
追加のトラブルシューティング
もし上記の対策を行ってもエラーが解消しない場合、より詳細なトラブルシューティングが求められます。
パケットキャプチャによる調査
Wiresharkなどのパケットキャプチャツールを使用して、ForwarderからCollectorへの通信が実際にどのようになっているかを解析すると、問題の切り分けが早まる場合があります。特定の途中ルーターやプロキシサーバーがリクエストをブロックしているケースも珍しくありません。
イベントログのより詳細な分析
WinRM関連のログは「Windows ログ」→「アプリケーションとサービス ログ」→「Microsoft」→「Windows」→「WinRM」配下などで詳細を確認できる場合があります。また、Forwarding関連のログは「Microsoft」→「Windows」→「EventCollector」や「EventLog-ForwardingPlugin」などでエラー内容を詳しくチェックできます。
Collector側のIIS設定との競合確認
稀ではありますが、Collector側にWebサービスが導入されており、WinRMポートと競合を起こしているときに問題が生じるケースもあります。Collector自体をWindows Serverとして運用しており、IISや他のWebサービスを起動している場合はポート競合を注意深く確認してみてください。
まとめ
ソース開始方式でWindowsイベント転送を構成する際に、EVENT ID 105や「The WinRM client sent a request to an HTTP server and got a response saying the requested HTTP URL was not available.」といったエラーメッセージが出力される場合、多くはWinRMポート、IISバインディング、プロキシ設定のいずれかが原因となっています。設定をすべて見直し、特に下記を要チェックとしてください。
- IISの「Default Web Site」でホスト名を設定していないか、HTTPバインディングが不完全ではないか
- Proxy設定が不要な環境で残っていないか
- 5985/5986ポートが双方向通信可能な状態か
- WinRM設定(購読URL、認証方式、グループポリシー)に誤りがないか
Windowsイベント転送を正しく構成できれば、監査ログやセキュリティログなどを一元的に把握することができ、運用効率が大幅に向上します。一度正常に動作するようにしておけば、拠点が増えてもForwarderを追加してCollectorに登録するだけでログ管理を拡充できるのが大きな利点です。ぜひ本記事で紹介したポイントを参考に、快適なログ収集環境を実現してください。
コメント