Windows Event Forwarding（WEF）でドメインコントローラーのイベントを集約しようとすると、送信側で「Code (0x138C) / query returns no active channel」が出て転送が止まることがあります。本記事では権限不足が原因だったケースの直し方と、再起動を最小化する運用ポイントを整理します。
発生する症状：Code (0x138C) / query returns no active channel とは
WEF（Windows Event Forwarding）は、各サーバー（イベントソース）で発生したイベントを、イベントコレクター（サブスクリプションを持つサーバー）へ転送して集約する仕組みです。SIEM 連携や監査ログの集中管理でよく使われます。
ところが、ドメインコントローラー（DC）から転送しようとした際に、送信側で次のようなエラーが出て購読が進まないことがあります。
- Code (0x138C)：Windows Event Forward plugin can’t read any event … query returns no active channel
文面だけを見ると「購読クエリ（XPath）の指定ミス」「そのログ（チャネル）が存在しない」と誤解しやすいのですが、実際にはチャネル自体は存在するのに、転送主体が読み取れないために同じような状態として扱われるケースが少なくありません。
| 観測できる事象 | どこで確認するか | 読み取り権限不足が疑わしいサイン |
|---|---|---|
| Code (0x138C) / query returns no active channel | イベントソース（DC）のログ Microsoft-Windows-Eventlog-ForwardingPlugin/Operational | ログ名は正しいはずなのに特定チャネル追加で突然発生、または一部のDCだけで発生 |
| コレクター側でイベントが増えない | イベントコレクターの Forwarded Events / WEC の Operational | WinRM は疎通しているが、特定ログだけ欠ける（Security は来るのに SMBServer/Audit が来ない等） |
| 購読状態が「Active」にならない／遅延が極端 | イベント ビューアーの「サブスクリプション」画面 | 購読クエリの Path に含めたチャネルが追加されたタイミングで止まる |
このトラブルが起きやすい構成
- イベントソースがドメインコントローラー（台数が多く、OS 世代混在もしやすい）
- 転送したいログが Security ではなく、Microsoft-Windows-～ 配下の個別チャネル（例：SMBServer/Audit）
- サブスクリプションの QueryList に複数チャネルをまとめて書き、どれか1つが読めないと購読全体が止まる形になっている
結論：多くは「購読クエリ」ではなく「転送（読み取り）主体の権限不足」
この 0x138C は、購読クエリ自体が間違っている場合にも出ますが、現場で多いのは転送処理がログ（チャネル）を開けず、結果として「アクティブなチャネルが無い」扱いになるパターンです。
WEF の送信側処理は WinRM と密接に結びついており、環境によってはNetwork Service（S-1-5-20）の権限でイベントログを読み取ろうとします。対象チャネルの ACL（ChannelAccess）に Network Service が含まれていないと、管理者で手動参照できても、転送だけが失敗する状況が起こり得ます。
実際に解消した対処：対象チャネルの ACL に Network Service を追加
原因が権限不足だったケースでは、チャネル（ログ）の ACL（ChannelAccess）に Network Service を追加することで解消します。今回の例では、転送対象が Microsoft-Windows-SMBServer/Audit で、DC 全台に同じ設定を入れて復旧しました。
解決に使ったコマンド（例）
wevtutil set-log Microsoft-Windows-SMBServer/Audit /ca:O:BAG:SYD:(A;;0x5;;;BA)(A;;0x1;;;S-1-5-32-573)(A;;0x1;;;S-1-5-20)この 1 行は「ChannelAccess（チャネルアクセス制御）」を SDDL で上書きします。/ca は追記ではなく置換なので、既存のエントリを含めた形で指定するのが重要です（後述）。
SID の意味（最低限ここだけ押さえる）
| SID / 略号 | 意味 | この設定での役割 |
|---|---|---|
| BA | Built-in Administrators（管理者） | 管理者がログを参照・管理できる前提を維持 |
| S-1-5-32-573 | Event Log Readers（イベント ログ閲覧者） | 読み取り専用の一般的な権限枠 |
| S-1-5-20 | Network Service（ネットワーク サービス） | WEF/WinRM まわりがこの権限でログを読むケースをカバー |
SDDL（/ca）の見方をざっくり理解しておく
SDDL は一見難解ですが、「どこを触っているのか」を把握しておくと、事故が減ります。今回の文字列は大きく分けて Owner（所有者）/ Group（グループ）/ DACL（許可）で構成されています。
| 要素 | 例 | 意味 | 注意点 |
|---|---|---|---|
| Owner | O:BA | 所有者が Built-in Administrators | 不用意に変えると管理が面倒になる |
| Group | G:SY | 主グループが SYSTEM | 通常は既定のままでよい |
| DACL | D:(A;;...) | 許可（Allow）の ACE を並べる | /ca はここを含めて「全部置換」される |
| ACE | (A;;0x1;;;S-1-5-20) | 主体（SID）に権限（アクセス マスク）を付与 | 今回は 0x1（読み取り）だけを最小付与 |
なぜ Network Service を入れると「アクティブなチャネル」になるのか
WEF の転送処理が対象チャネルを開けない場合、転送プラグイン側は「そのクエリで返せるイベントが無い」ではなく、より根本の「チャネルが利用できない（＝アクティブではない）」扱いに寄ったエラーを返すことがあります。結果として、購読クエリの問題に見えてしまいます。
つまり、この症状は「チャンネル名が間違い」と「チャンネルはあるが読めない」で同じ見え方をしやすい、というのが落とし穴です。
購読クエリの例：Path は「表示名」ではなく「チャネル名」
念のため、購読クエリ側の書き方も押さえておきます。WEF で指定するのはイベント ビューアー上の表示名ではなく、チャネルの正式名（例：Microsoft-Windows-SMBServer/Audit）です。
複数チャネルをまとめる場合は、概ね次のような形になります（イベントIDなどは例です）。
<QueryList>
<Query Id="0">
<Select Path="Security">*</Select>
<Select Path="Microsoft-Windows-SMBServer/Audit">*</Select>
</Query>
</QueryList>このとき、2つ目のチャネルだけが存在しない／無効／読めない、という状態だと、全体が失敗して 0x138C に見えることがあります。原因の切り分けを簡単にするため、用途ごとにサブスクリプションを分割しておくのは有効な設計です（例：Security 用、SMB 監査用、AD 関連用など）。
作業前に必ずやる：存在確認・有効化・ACL バックアップ
/ca を扱う前に、次の 3 点を確認しておくと事故が減ります。特に DC 複数台に展開する場合は「DC 間の差分」が原因で再発しがちです。
チャネルが存在するか確認
wevtutil el | findstr /i SMBServerここで Microsoft-Windows-SMBServer/Audit が列挙されない DC がある場合、その DC にはチャネルが存在しない（OS バージョン差・機能差）可能性があります。その場合は「購読を OS 別に分ける」方が安全です（後述）。
チャネルが無効になっていないか確認（必要なら有効化）
wevtutil gl Microsoft-Windows-SMBServer/Audit出力の中に enabled: があり、false なら無効です。必要であれば次で有効化します。
wevtutil sl Microsoft-Windows-SMBServer/Audit /e:true現在の ChannelAccess（/ca）をバックアップ
/ca は置換なので、まず現状を控えます。環境によっては既定の SDDL が異なるため、いきなり固定文字列で上書きすると、想定外に権限を削ってしまうリスクがあります。
wevtutil gl Microsoft-Windows-SMBServer/Audit /f:xmlXML 出力の <channelAccess> 相当の値が ChannelAccess です。テキストファイルに保存しておき、変更後に戻せる状態にしてから進めます。
安全に適用する手順：既存 /ca に S-1-5-20 を足す考え方
実際の運用では、すでに何らかの SDDL が入っていることが多いです。基本方針は「既存の SDDL はなるべく保ち、必要な ACE だけ追加する」です。
手動でやる場合の流れ
- 対象チャネルの ChannelAccess を取得（バックアップ）
- 文字列の末尾（DACL 部分）に
(A;;0x1;;;S-1-5-20)を追加 wevtutil set-log ... /ca:で反映- 転送が再開するか確認
追加する ACE は「読み取り（0x1）」のみで、過剰な権限を与えない構成にしています。監査ログの扱いでは最小権限が基本です。
PowerShell で「入っていなければ追加」を自動化する例
DC が複数台ある場合、手作業よりもスクリプト化した方が抜け漏れが減ります。以下は一例です（実行前にテスト環境で確認してください）。
$log = 'Microsoft-Windows-SMBServer/Audit'
$xml = [xml](wevtutil gl $log /f:xml)
$ca = $xml.channel.channelAccess
if ($ca -notmatch 'S-1-5-20') {
$new = $ca + '(A;;0x1;;;S-1-5-20)'
wevtutil sl $log /ca:$new
"updated: $log"
} else {
"already contains Network Service: $log"
}ポイントは、既存の $ca を丸ごと維持したまま ACE だけ足す点です。最終的にどの SDDL になるかは wevtutil gl ... /f:xml で必ず再確認してください。
「再起動が必要に見える」問題への現実的なアプローチ
質問でよくあるのが「wevtutil set-log ... /ca:... を入れたのに、すぐには直らず、DC 再起動したら直った」というケースです。ここは少し割り切りが必要です。
なぜすぐ反映されないことがあるのか
- イベントログのチャネル情報やセキュリティ記述子が、内部でキャッシュされることがある
- 転送プラグインが次の読み取りタイミングまでエラー状態を保持することがある
- サブスクリプション側の再試行間隔やネットワーク状態で、復旧が遅れて「反映していない」ように見える
そして大前提として、Windows Event Log サービスは重要サービスで、停止・再起動は現実的ではありません。結果として「確実に全てを読み直させる手段」として OS 再起動が最も効きやすいのは事実です。
再起動せずに試すなら：影響が小さい順にここから
| 対象 | 目的 | 例（PowerShell） | 注意点 |
|---|---|---|---|
| イベントコレクター側：Windows Event Collector（Wecsvc） | 購読の受け口と再試行を促す | Restart-Service Wecsvc | 受信側の短時間停止。設計により影響範囲あり |
| 送信側（DC）：WinRM | WEF/WinRM 経由の転送処理をリフレッシュ | Restart-Service WinRM | WinRM を使う運用（構成管理等）がある場合は影響に注意 |
| 送信側（DC）：ポリシーの再適用 | サブスクリプション マネージャー設定の再取得 | gpupdate /force | ACL 反映とは別軸。設定が最新か確認する目的 |
上記を試した上で改善しない場合、短時間で確実にリロードさせる手段が限定されるため、計画メンテナンスで再起動する判断が現実的です。
ログやイベントIDを増やしたら再発する：典型パターンと対策
「別のログ（チャネル）を追加した途端に同じ 0x138C が出た」という相談は多いです。だいたい原因は次のどれかに収まります。
- 追加したチャネルが存在しない（OS バージョン差・役割差）
- 追加したチャネルが無効（未有効化）
- 追加したチャネルに同様の読み取り権限（/ca）が付いていない
| 原因 | 確認コマンド | 対策 | 運用のコツ |
|---|---|---|---|
| チャネルが無い | wevtutil el | findstr /i "チャネル名の一部" | そのチャネルを含む購読を OS 別に分割 | DC を混在させる場合は「最古 OS に合わせた購読」も検討 |
| チャネルが無効 | wevtutil gl チャネル名 の enabled | wevtutil sl チャネル名 /e:true | 分析/デバッグ用チャネルは既定で無効が多い |
| ACL 不足 | wevtutil gl チャネル名 /f:xml の channelAccess | 必要な主体（例：S-1-5-20）を追加 | 「テンプレ SDDL で上書き」ではなく「既存へ追記」が安全 |
特に DC は台数が多くなりやすく、OS 世代混在も起こりがちです。「全 DC に存在し、有効で、ACL 付与済み」を揃えることが再発防止の本質です。必要なら、サブスクリプションを OS 別に分けるのが一番トラブルが減ります。
WEF を安定運用するための実践ポイント
権限設計：追加するのは必要最小限に
- Network Service を追加するのは、転送に必要なチャネルだけに限定する
- 可能なら、どのチャネルに追加したかを台帳化し、変更管理の対象にする
- サブスクリプションの対象を増やす前に、まずは「転送が成立する最小セット」で安定化させる
設計面のコツ：1つの購読に詰め込みすぎない
WEF の購読（サブスクリプション）は、便利な反面「1つの QueryList の中に読めないチャネルが混ざると全体が失敗する」形になりがちです。次のように分けておくと、障害時の影響範囲を限定できます。
- Security（監査）用サブスクリプション
- SMB/ファイルアクセス監査用サブスクリプション（例：SMBServer/Audit）
- AD DS 関連ログ用サブスクリプション
「まず Security は安定して来ている」を土台に、追加ログを 1 つずつ増やすと、0x138C の原因特定も早くなります。
展開設計：DC 全台へ均一に適用する仕組みを用意
対処自体は単純でも、DC 1 台だけ漏れると「一部だけ転送されない」「時々欠ける」という厄介な状態になります。次のような展開方法が現実的です。
- GPO のスタートアップスクリプトで
wevtutilを実行（適用ログを残す） - 構成管理ツール（例：Desired State Configuration / Ansible 等）で差分検知
- 新規 DC 追加時のビルド手順に「対象チャネルの有効化＋ACL 付与」を組み込む
切り分けの鉄板手順：問題を「チャネル」「権限」「通信」へ分離する
0x138C が出たとき、最短で原因に辿り着くための順番は次の通りです。
- チャネル名が正しいか（
wevtutil elで存在確認） - チャネルが有効か（
wevtutil glで enabled 確認） - ChannelAccess に読み取り主体が含まれるか（
channelAccessを確認） - WinRM 疎通や WEF 設定（サブスクリプション マネージャー、HTTP/HTTPS、証明書など）を確認
「通信が悪いのでは？」に飛びつく前に、チャネルと ACL を先に疑うと時間を節約できます。今回のケースのように、通信自体は生きていても特定チャネルだけ読めない、という状況があるためです。
よくある質問
Q. Event Log Readers（S-1-5-32-573）だけでは足りないの？
A. チャネルによってはそれで足りることもありますが、WEF/WinRM の実行主体が Network Service になる環境では、Event Log Readers に権限があっても転送が読めないケースがあります。今回のように 0x138C が出るなら、まずは対象チャネルの ChannelAccess に S-1-5-20 が入っているかを確認するのが近道です。
Q. 全チャネルに Network Service を入れてしまって良い？
A. おすすめしません。監査ログは機密性が高い場合が多く、権限は必要最小限が基本です。0x138C が出ている「転送対象のチャネル」だけに限定して付与し、運用台帳に残す方が安全です。
Q. 変更してもすぐ直らないとき、まず何を確認すべき？
A. まずは wevtutil gl 対象チャネル /f:xml で channelAccess が意図した値になっているかを確認します。そのうえで、送信側の WinRM と受信側の Wecsvc を順に再起動し、Forwarded Events にイベントが到達するかを見ます。改善が見えない場合は、購読を分割して「どのチャネルが引っかかっているか」を特定すると前に進みます。
まとめ：0x138C は「チャネル名」だけでなく「チャネルを読む権限」を見る
- Code (0x138C) / query returns no active channel は、購読クエリのミスだけでなく読み取り権限不足でも起きる
Microsoft-Windows-SMBServer/Auditなど特定チャネルで止まる場合、ChannelAccess（/ca） に Network Service（S-1-5-20） を追加すると解消することがある- /ca は置換なので、既存 SDDL のバックアップと、追記方針が安全
- 反映が遅い場合は、まず WinRM / Wecsvc の再起動を試し、難しければ計画再起動を検討
- ログ追加で再発したら「存在・有効化・ACL」の 3 点セットを全 DC で揃える
コメント