MENU

Hyper‑V 固有イベントがWECに転送されない原因と解決策｜チャネルACL（SDDL）・WinRM・サブスクリプション徹底ガイド

Hyper-V

Windows Event Collector（WEC）で「セキュリティ／システム／アプリケーション」は届くのに、Hyper‑V 固有チャネルだけが転送されない――Source‑initiated（送信元主導）型で頻発する現象です。本記事は、その根本原因（チャネル ACL・収集アカウント権限・WinRM／サブスクリプション不整合）を分解し、再現コマンド、修正手順、検証ポイント、運用設計までを一気通貫で解説します。

目次

事象の概要（前提）

  • WEC で Source‑initiated サブスクリプションを構成済み。
  • Security / System / Application 等の標準ログは収集できている。
  • Applications and Services Logs → Microsoft → Windows → Hyper‑V‑* に属する各種 Hyper‑V ログのみが Collector 側に現れない。
  • サブスクリプションの XPath（XML フィルター）には Hyper‑V チャネルを列挙済み。

この症状は、Hyper‑V 系チャネルのアクセス制御（SDDL）が標準ログと異なること、そして WEF/WinRM が読み取りに使うアカウントに正しく権限が付与されていないことに起因するケースが大半です。

仕組みの整理：なぜ Hyper‑V ログだけ届かないのか

WEC/WEF の経路と権限の要点

  • Source‑initiated では、送信元（Forwarder）が WinRM（TCP 5985/5986）経由で Collector へイベントをプッシュします。
  • 送信元がローカルでイベントを読み出す際の実効権限は、Windows Event Log サービス＋WinRM サービスが動作するアカウント（多くの環境では NETWORK SERVICE）と、そのアカウントが所属する Event Log Readers グループに依存します。
  • Applications and Services Logs 配下の一部チャネル（とりわけ Hyper‑V 系の Operational）は、既定の channelAccess（SDDL）に Event Log Readers の読み取りが含まれていないことがあります。
<h3>チャネルの種類と既定 ACL の違い</h3>
<ul>
  <li><strong>Admin / Operational</strong>：運用で用いる一般的なチャネル。<br>標準ログと違い、各チャネルごとに固有の SDDL を持ち、<strong>Event&nbsp;Log&nbsp;Readers への権限委譲がない</strong>場合がある。</li>
  <li><strong>Analytic / Debug</strong>：高頻度・技術者向け。既定では無効。<br>必要性を精査せず有効化すると、Forwarder 側の負荷・遅延・未収集の温床になる。</li>
</ul>

<h3>フィルター XML の落とし穴</h3>
<p><code>&lt;Select Path="..."&gt;</code> の <strong>Path はワイルドカード非対応</strong>です。<code>Hyper‑V‑*</code> とは書けません。必ずチャネルを列挙する必要があります。列挙済みにもかかわらず届かないときは、<strong>ACL とアカウント権限</strong>を疑うのが近道です。</p>

主な原因（実務で多い順）

  1. チャネルのアクセス権不足
    Hyper‑V の Operational 系チャネルの一部は、既定 SDDL に Event Log Readers の読み取りが含まれていません。結果、Forwarder がログを読み出せず転送されません。
  2. 収集に用いられるアカウントのロール不足
    送信元ホストでログを読む実行主体（例：NETWORK SERVICE、ドメインのマネージドサービスアカウント等）に対象チャネルへのアクセス権がない。
  3. WinRM/サブスクリプション設定の不一致
    WinRM が停止／ポート遮断／HTTPS 証明書不整合、あるいは Source‑initiated なのに Collector 側のフィルター更新が Forwarder 群へ反映されていない、など。

解決までの実行手順（コマンドつき）

<table>
  <thead>
    <tr>
      <th>手順</th>
      <th>目的</th>
      <th>コマンド例 / GUI 操作</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>1</td>
      <td><strong>チャネル ACL（SDDL）を確認</strong></td>
      <td>
        <pre><code>wevtutil gl "Microsoft-Windows-Hyper-V-VMMS/Operational"</code></pre>
        <p>出力の <code>channelAccess:</code> を控え、<code>Event Log Readers</code>（SID: <code>S-1-5-32-573</code>）や <code>NETWORK SERVICE</code>（短縮 SID: <code>NS</code>）が読み取り権限（0x1）を持つか確認します。</p>
      </td>
    </tr>
    <tr>
      <td>2</td>
      <td><strong>不足していれば読み取り権を付与</strong></td>
      <td>
        <p>例：既存 SDDL に <code>NETWORK SERVICE</code> と <code>Event Log Readers</code> の Read(0x1) を追加</p>
        <pre><code># 既存 SDDL を取得

$log = “Microsoft-Windows-Hyper-V-VMMS/Operational” $sddl = (wevtutil gl $log | Select-String -Pattern ‘^channelAccess:’ ).ToString().Split(‘:’)[-1].Trim() # 追記（重複防止の簡易判定） $evrSid = (New-Object System.Security.Principal.NTAccount(“Event Log Readers”)).Translate([System.Security.Principal.SecurityIdentifier]).Value $add = @(“(A;;0x1;;;NS)”,”(A;;0x1;;;$evrSid)”) foreach($ace in $add){ if($sddl -notmatch [regex]::Escape($ace)){ $sddl += $ace } } # 反映 wevtutil sl $log /ca:”$sddl”

PowerShell が使えない環境でも、以下のように直接指定可能です（既存 SDDL に追記すること）。

wevtutil sl "Microsoft-Windows-Hyper-V-VMMS/Operational" /ca:"O:BAG:SYD:(A;;0x1;;;NS)(A;;0x1;;;S-1-5-32-573)"

※本番適用前に wevtutil gl の出力をバックアップしてください。 3 Event Log Readers に収集主体を追加

送信元 Hyper‑V ホストのローカル グループに、必要なアカウント（例：NETWORK SERVICE／Forwarder が用いるサービス アカウント）を追加。

  • GUI：コンピューターの管理 → ローカル ユーザーとグループ → Event Log Readers → 追加
  • PowerShell：net localgroup "Event Log Readers" "NT AUTHORITY\NETWORK SERVICE" /add

4 WinRM を健全化

winrm quickconfig
Test-NetConnection  -Port 5985

# HTTPS を使う場合は 5986 も確認

winrm enumerate winrm/config/Listener

ファイアウォールで TCP 5985/5986 を開放。証明書使用時はサブジェクト名や SPN の一致に注意。 5 サブスクリプションの再同期／再読み込み

wecutil ss <サブスク名> /resync
Restart-Service Wecsvc

フィルター XML を更新した場合、Wecsvc の再起動まで行うと確実です。 6 チャネルが有効か確認

Get-WinEvent -ListLog "Microsoft-Windows-Hyper-V-Worker/Operational" | Select-Object LogName, IsEnabled

GUI：イベント ビューアー → 該当チャネル → 右クリック「ログの有効化」。

<h3>大量チャネルを一括で権限整備（安全に・再実行可能に）</h3>
<p>Hyper‑V 系の主要チャネル（Admin/Operational）に対し、<strong>Event&nbsp;Log&nbsp;Readers</strong> と <strong>NETWORK SERVICE</strong> の Read(0x1) を付与するサンプルです。既存 SDDL を保持しつつ不足分のみ追記します。</p>
<pre><code class="language-powershell"># 管理者 PowerShell（送信元 Hyper‑V ホストで実行）

$targets = Get-WinEvent -ListLog ‘Microsoft-Windows-Hyper-V-*’ | Where-Object { $_.LogType -in @(‘Admin’,’Operational’) } | Select-Object -ExpandProperty LogName $evrSid = (New-Object System.Security.Principal.NTAccount(“Event Log Readers”)).Translate([System.Security.Principal.SecurityIdentifier]).Value $aces = @(“(A;;0x1;;;NS)”,”(A;;0x1;;;$evrSid)”) $backup = Join-Path $env:ProgramData “HyperV-ChannelACL-Backup-$(Get-Date -Format yyyyMMddHHmmss).csv” “Channel,OriginalSDDL,NewSDDL,Changed” | Out-File -FilePath $backup -Encoding UTF8 foreach($ch in $targets){ try{ $line = (wevtutil gl “$ch” | Select-String ‘^channelAccess:’ ).ToString() if(-not $line){ Write-Warning “channelAccess を取得できません: $ch”; continue } $sddl = $line.Split(‘:’)[-1].Trim() $new = $sddl foreach($a in $aces){ if($new -notmatch [regex]::Escape($a)){ $new += $a } } $changed = $new -ne $sddl if($changed){ wevtutil sl “$ch” /ca:”$new” } “$ch,””$sddl””,””$new””,$changed” | Out-File -Append -FilePath $backup -Encoding UTF8 Write-Host (“[{0}] {1}” -f ($(if($changed){“UPDATED”}else{“OK”}), $ch)) }catch{ Write-Warning “処理失敗: $ch – $($_.Exception.Message)” } } Write-Host “バックアップ: $backup”

<p><strong>ポイント：</strong>あくまで「読み取り（0x1）」のみを追加します。既存 ACE を壊さないこと、重複を作らないことが重要です。必ずバックアップ（CSV）を残しましょう。</p>

フィルター XML の実例（Source‑initiated サブスクリプション）

Path のワイルドカードは不可のため、必要なチャネルを列挙します。まずは運用で有用なチャネルに絞り、正常動作を確認してから拡張するのが安全です。

<QueryList>
  <Query Id="1" Path="Microsoft-Windows-Hyper-V-VMMS/Operational">
    <Select Path="Microsoft-Windows-Hyper-V-VMMS/Operational">*</Select>
  </Query>
  <Query Id="2" Path="Microsoft-Windows-Hyper-V-VMMS/Admin">
    <Select Path="Microsoft-Windows-Hyper-V-VMMS/Admin">*</Select>
  </Query>
  <Query Id="3" Path="Microsoft-Windows-Hyper-V-Worker/Operational">
    <Select Path="Microsoft-Windows-Hyper-V-Worker/Operational">*</Select>
  </Query>
  <Query Id="4" Path="Microsoft-Windows-Hyper-V-Worker/Admin">
    <Select Path="Microsoft-Windows-Hyper-V-Worker/Admin">*</Select>
  </Query>
  <Query Id="5" Path="Microsoft-Windows-Hyper-V-VmSwitch/Operational">
    <Select Path="Microsoft-Windows-Hyper-V-VmSwitch/Operational">*</Select>
  </Query>
  <Query Id="6" Path="Microsoft-Windows-Hyper-V-Hypervisor/Operational">
    <Select Path="Microsoft-Windows-Hyper-V-Hypervisor/Operational">*</Select>
  </Query>
  <!-- 必要に応じて他の Hyper‑V チャネルを追加 -->
</QueryList>

対象チャネルの一覧は、送信元で次のコマンドで把握できます。

Get-WinEvent -ListLog 'Microsoft-Windows-Hyper-V-*' | Select-Object LogName, LogType, IsEnabled | Sort-Object LogName

GPO で一括展開する（Windows Event Log サービス：追加のチャネル アクセス）

多数のホストに適用する場合、グループポリシーの「Windows Event Log サービス: 追加のチャネル アクセス」を用いると展開が容易です。以下は考え方の例です。

  1. 適用対象 OU に GPO をリンクし、該当ポリシーで Hyper‑V チャネル名ごとに channelAccess の SDDL を指定。
  2. ACE は過剰に付けず、読み取り (0x1) のみを NETWORK SERVICE と Event Log Readers に付与。
  3. テスト用 OU で 1 台ずつ段階適用し、ForwardedEvents に到達しているかを確認。

SDDL 例（ACE 部分）

(A;;0x1;;;NS)(A;;0x1;;;S-1-5-32-573)

※ポリシーの適用後は gpupdate /force、必要に応じて wecutil ss <サブスク名> /resync と Restart-Service Wecsvc を伴わせます。

検証方法（届く／届かないを即断する）

送信元で最新 1 件を確認

wevtutil qe "Microsoft-Windows-Hyper-V-VMMS/Admin" /c:1 /f:text

Collector 側で ForwardedEvents を確認

Get-WinEvent -LogName ForwardedEvents -MaxEvents 50 |
  Where-Object { $_.ProviderName -like "Microsoft-Windows-Hyper-V*" } |
  Select-Object TimeCreated, ProviderName, Id, MachineName, LevelDisplayName

ここで ProviderName が Hyper‑V 系に一致し、MachineName が該当ホストであれば転送成功です。出てこない場合は、送信元のチャネル ACL → Forwarder アカウント権限 → WinRM 経路の順で切り分けます。

よくある落とし穴と対処

症状原因対処
標準ログは届くが Hyper‑V だけ届かないHyper‑V チャネルに Event Log Readers/NS の ACE がない本記事の ACL 追記を実施（0x1 のみ）。GPO で横展開
一部ホストだけ届かないForwarder のローカル ポリシー不一致、または WinRM/Firewall 差分winrm quickconfig、Test-NetConnection、GPO 適用状況を比較
更新しても反映されない／遅いSource‑initiated の再同期待ち・間隔が長いwecutil ss <サブスク名> /resync、必要に応じて Delivery を「最小遅延」に
Analytic/Debug を入れたが届かないチャネルが無効、または高負荷でロスまず Admin/Operational に限定。Analytic/Debug は真に必要な範囲だけ有効化
ForwardedEvents がすぐ満杯になるCollector 側のログサイズ不足wevtutil sl ForwardedEvents /ms:<バイト> で拡張し、アーカイブ運用を検討
HTTPS でだけ失敗する証明書の CN/SAN 不一致、信頼チェーン欠落サーバー証明書を再発行／正しいテンプレート使用、クライアント信頼を配布

サブスクリプション健全性のチェック コマンド集

# Collector 側：サブスクリプションの設定確認
wecutil gs "<サブスク名>"

# 配信最適化（例：最小遅延）に変更

wecutil ss "<サブスク名>" /delivery:MinLatency

# 対象コンピューターの到達性テスト（Collector → Forwarder）

Test-NetConnection  -Port 5985

# Forwarder 側：SubscriptionManager の登録確認（GPO で配布する値）

Get-ItemProperty 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\EventLog\EventForwarding\SubscriptionManager'

# Forwarder 側：プラグインの動作ログ

Get-WinEvent -LogName 'Microsoft-Windows-Eventlog-ForwardingPlugin/Operational' -MaxEvents 50 |
Select TimeCreated, Id, LevelDisplayName, Message

Forwarder 側の Eventlog‑ForwardingPlugin/Operational は、サブスクリプションの状態を判断するうえで非常に有用です。エラー時刻と ForwardedEvents の欠落タイムラインを突き合わせると、ネットワーク・権限・キャパシティのどこで詰まっているか当たりを付けられます。

セキュリティと運用のベストプラクティス

  • 最小権限：読み取り（0x1）のみを付与。不要な書き込み／消去は絶対に加えない。
  • 対象チャネルの限定：まず Admin/Operational の最小集合から。Analytic/Debug は十分に検討のうえ段階的に。
  • 通信保護：信頼済み境界をまたぐ場合は WinRM over HTTPS を検討。証明書と SPN 整合を運用設計に組み込む。
  • 可観測性：Collector の ForwardedEvents 容量・アーカイブ設計／Forwarder のバックログ監視を行う。
  • 変更管理：チャネル SDDL 変更は必ず記録・バックアップ。ロールバック手順（wevtutil sl /ca:<旧SDDL>）を残す。

チェックリスト（現地対応用の短冊）

  • □ Hyper‑V 対象チャネルの channelAccess に NS と S-1-5-32-573 の Read(0x1) がある
  • □ Forwarder 側の Event Log Readers に必要なアカウントが所属
  • □ winrm quickconfig が正常／TCP 5985（必要なら 5986）到達
  • □ サブスクリプション再同期（wecutil ss /resync）と Wecsvc 再起動を実施
  • □ チャネルが 有効化され、イベントが実際に発生している
  • □ Collector 側の ForwardedEvents 容量が十分で、ローテーション設計がある
  • □ 重複・競合するサブスクリプションがない（フィルター被り／Delivery 設定衝突なし）

付録：Hyper‑V チャネル列挙とフィルター XML 自動生成

運用対象ホストで実行し、現在存在する Hyper‑V チャネル（Admin/Operational）を抽出して XML スニペットを生成します。

$logs = Get-WinEvent -ListLog 'Microsoft-Windows-Hyper-V-*' |
  Where-Object { $_.LogType -in @('Admin','Operational') } |
  Sort-Object LogName

""
$i = 1
foreach($l in $logs){
$p = [System.Security.SecurityElement]::Escape($l.LogName)
"  "
"    *"
"  "
$i++
}
""

付録：トラブル復旧のためのロールバック

誤った SDDL を設定してしまった場合、バックアップした値をそのまま戻せます。

# 例：CSV バックアップから 1 行ずつ復旧
Import-Csv "C:\Temp\HyperV-ChannelACL-Backup.csv" | ForEach-Object {
  wevtutil sl $_.Channel /ca:$($_.OriginalSDDL)
}

WEC/Wecsvc 再起動後に再テスト（送信元 1 件 → Collector 反映）を繰り返し、正常化を確認します。

まとめ

Hyper‑V 固有チャネルが WEC に届かないときは、ほぼ必ず チャネル ACL と収集アカウント権限に原因があります。まずは送信元で wevtutil gl により SDDL を確認し、Event Log Readers（S-1-5-32-573） と NETWORK SERVICE（NS） の読み取り（0x1）を付与。次に WinRM の健全性（5985/5986、リスナー、証明書）を検証し、最後に サブスクリプションの再同期とチャネルの有効化を行います。ここまでを揃えれば、Hyper‑V 系ログも標準ログ同様に安定して収集されるはずです。運用では GPO による横展開、ForwardedEvents 容量設計、Forwarder/Collector 側の健全性監視を組み合わせ、「権限」「経路」「容量」の 3 点が常に揃っている状態を維持しましょう。

Hyper-V
PowerShell Hyper-V WinRM WEF Windows Event Collector SDDL

この記事を書いた人

佐藤健司のアバター 佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

関連記事

コメント

コメントする

目次