MENU

Windows Server 2022 CoreでWindows Push Notifications User Serviceエラーが大量発生する原因と対処法

Windows Server

Windows Server 2022 Core に App Compatibility FOD を入れた途端、「Windows Push Notifications User Service_xxxx」のエラーがイベントログを埋め尽くす――本番導入後にこれに遭遇すると、不具合なのか仕様なのか判断に迷います。本記事では、この現象の正体と実害の有無、そして運用現場で現実的な三つの対処パターン（無視・FoD 削除・サービス無効化）を、具体的なコマンドやレジストリ設定例とともに整理します。

目次

現象の整理：どんなエラーが出るのか

問題となる構成は、おおむね次のようなものです。

  • OS：Windows Server 2022 Core（Desktop Experience なし）
  • App Compatibility Feature on Demand（App Compatibility FoD / ServerCore.AppCompatibility）を追加済み
  • ログオンのたびに System ログに同じパターンのイベントが多数記録される

代表的なイベントパターンは次の通りです。内容は日本語に要約しています。

イベント IDレベル概要
7036情報サービス Windows Push Notifications User Service_XXXX が開始／停止状態に入ったことを示す状態遷移ログ。
7023エラー同サービスがエラー終了。「CoInitialize が呼び出されていない」（0x800401F0）という COM 初期化エラーが理由として記録される。
7031エラーサービスが予期せず終了し、再起動ポリシーに基づいて数秒後に自動再起動されることを示す。

Microsoft Q&A にも同様の事例が投稿されており、「Server 2022 Core はクライアント OS のような通知機能を持たないはずなのに、なぜ WPN 関連のサービスが動くのか？」という疑問とともに共有されています。

原因：per-user service と App Compatibility FoD の組み合わせ

WpnUserService とは何か

Windows Push Notifications User Service（WpnUserService） は、Windows の通知プラットフォーム（タイル、トースト、プッシュ通知など）をホストするサービスです。通常は自動起動で動作し、ローカル通知とクラウド由来のプッシュ通知の双方を扱います。

Windows 10/11 のクライアントでは、トースト通知やアクションセンターに深く関わるサービスであり、無効化すると通知 UI や一部の設定画面が動作しなくなる報告もあります。

per-user service（ユーザー別サービス）の仕組み

WpnUserService が少しややこしいのは、「通常のサービス」ではなくper-user service（ユーザー別サービス）である点です。

  • ユーザーがサインインすると、そのユーザー専用のサービス インスタンスが作成される。
  • サービス名は WpnUserService_2fb4a のように、元のサービス名 + 「_LUID（ローカル一意 ID）」という形式になる。
  • サインアウト時にインスタンスは停止・削除される。
  • インスタンスの「ひな型（テンプレート）」はレジストリの HKLM\SYSTEM\CurrentControlSet\Services\WpnUserService に定義されている。

つまり、サービス マネージャー（services.msc）から WpnUserService_2fb4a のようなインスタンスを止めても、「テンプレート」が有効である限り、次回ログオン時に別の ID で再生成されてしまうわけです。

なぜ Server Core で per-user service が動き始めるのか

Microsoft の per-user service 解説では、本来 per-user services は Windows クライアントや Desktop Experience 環境で利用されるものと説明されています。 一方で、Server Core に App Compatibility FOD（ServerCore.AppCompatibility~~~~0.0.1.0） を追加すると、GUI アプリやシェル関連コンポーネントが追加され、結果として WpnUserService を含むいくつかの per-user services が有効化されるパターンが観測されています。

App Compatibility FoD は、Windows Server Core に次のような GUI 管理ツールを追加する役割を持ちます。

ツール例用途
eventvwr.mscイベント ビューアー
taskschd.mscタスク スケジューラ
mmc.exeMicrosoft Management Console（各種スナップイン）
explorer.exeファイル エクスプローラー
devmgmt.msc / diskmgmt.mscデバイス マネージャー／ディスク管理

これら GUI コンポーネントの一部が「通知プラットフォーム」と結び付いているため、Server Core でも WpnUserService の per-user インスタンスが起動するようになり、その過程で COM 初期化周りの不整合から 7023/7031 が発生している、と考えられます。

これはバグなのか？

前述の Microsoft Q&A では、Microsoft 側の回答として「これらのエラーは実害のないものであり、無視して構わない」「気になるならログを抑止するか、FOD を削除する」といったスタンスが示されています。 少なくとも現時点で「修正パッチ」や「公式既知の不具合」として整理されている様子はなく、「Windows Server 2022 Core + App Compatibility FOD」という組み合わせ固有の“お行儀の悪いログ”と捉えるのが妥当そうです。

本当に対処が必要かを判断するポイント

いきなりサービスを無効化する前に、次の観点で「放置してよいか」を検討すると、過剰な対処を避けられます。

  • 通知・トースト・アクションセンター機能を使っているか？
    Server Core ではそもそも通知 UI が限定的で、WpnUserService の停止がユーザー体験に影響するケースは少ないと考えられます。
  • イベントログのノイズが監視設計に影響するか？
    7023/7031 を「重要な障害」として収集・アラートしている環境だと、誤検知の嵐になります。この場合は何らかの対処が必要です。
  • 将来的に Desktop Experience への移行や RDS 用途に転用する可能性
    クライアントライクな使い方を想定している場合、通知機構の完全停止はリスクになることもあります。

一般的なサーバー（AD DS、ファイルサーバー、アプリケーションサーバー等）で、トースト通知を業務で使っていないのであれば、「ログ抑止だけで様子を見る」という選択肢が最も保守的かつ安全です。

対処パターンの比較

代表的な対処パターンを整理すると、次のように整理できます。

対処方法概要メリットデメリット／注意点向いている環境
① ログ抑止のみイベントビューアーや SIEM 側で WpnUserService_* の 7023/7031/7036 をフィルタリングする。機能へ影響なし。ロールバックも容易。根本的にはサービスは動いたまま。ノイズを「見ない」だけ。通知不要で、ログのノイズだけ問題なケース。
② App Compatibility FOD を削除ServerCore.AppCompatibility をアンインストールして GUI コンポーネントを取り除く。原因となるコンポーネント自体を排除。ログも止まりやすい。ローカルのイベントビューアーやタスクスケジューラ等が使えなくなる。GUI 管理をほぼ使わず、RSAT や WAC で十分なサーバー。
③ WpnUserService テンプレートを無効化レジストリで WpnUserService のテンプレート（Start / UserServiceFlags）を変更し、per-user インスタンス生成を止める。FoD は残したまま、該当エラーを実質的に停められる。通知関連機能が動かなくなる可能性。レジストリ編集のリスク。GUI ツールは使いたいが、通知機能は不要なサーバー。

以下では、それぞれの具体的な手順を詳しく解説します。

方法 1：イベントログ・監視側でノイズを抑止する

実害がないと判断できるなら、もっとも安全なのは「ログだけ見ないようにする」アプローチです。Microsoft Q&A でも、まずはログフィルタリングを推奨する回答が採用されています。

イベント ビューアーでのフィルタリング例

ローカルでログを確認するときにノイズを消したい場合は、ユーザー定義ビューを作成してフィルタリングするのが簡単です。

  1. イベント ビューアー（eventvwr.msc） を開く。
  2. 左ペインで「ユーザー定義ビュー」を右クリックし、「ビューの作成」を選択。
  3. 「ログ：System」「ソース：Service Control Manager」を選択。
  4. 「イベント ID」に 7023,7031,7036 を入力（後から除外条件を追加するため）。
  5. 「XML」タブで「クエリを手動編集する」にチェックを入れ、次のような XML クエリに差し替える。
<QueryList>
  <Query Id="0" Path="System">
    <Select Path="System">
      *[System[
          Provider[@Name='Service Control Manager'] and
          (EventID=7023 or EventID=7031 or EventID=7036)
        ]
        and not(EventData[Data and starts-with(., 'Windows Push Notifications User Service_')])
      ]
    </Select>
  </Query>
</QueryList>

このクエリは、Service Control Manager が出力する 7023/7031/7036 のうち、サービス名が Windows Push Notifications User Service_ で始まるものを除外します。自分用の「サーバー監視ビュー」として保存しておけば、普段の運用で余計なエラーに惑わされずに済みます。

監視基盤（SIEM / ログ収集）の除外ルール例

Zabbix、Splunk、Azure Monitor などの監視基盤に System ログを転送している場合は、同様の条件でアラートや収集対象から除外するルールを定義するとよいでしょう。

  • ログソース：System
  • イベントソース：Service Control Manager
  • イベント ID：7023 / 7031 / 7036
  • メッセージまたはパラメータに Windows Push Notifications User Service_ を含む場合は除外

この方法であれば、OS 側には一切手を加えずにノイズだけを取り除けます。障害解析の観点からも、もっとも保守的なアプローチと言えます。

方法 2：App Compatibility FoD をアンインストールする

もし App Compatibility FOD を「試しに入れてみただけ」で、今後も使う予定がなければ、そもそもの原因である FoD を削除してしまうのも一つの手です。

インストール済みの FoD 名称を確認する

まずは、サーバーにどの FoD が入っているかを PowerShell で確認します。

Get-WindowsCapability -Online |
  Where-Object Name -like "*AppCompatibility*" |
  Select-Object Name, State

Windows Server 2022 の App Compatibility FOD は通常 ServerCore.AppCompatibility~~~~0.0.1.0 という名前で表示されますが、Microsoft Q&A などでは App.Support.Tools~~~~0.0.1.0 のような表記例も見られます。 そのため、必ず実機で Name を確認してから削除してください。

FoD のアンインストール手順

削除する能力名が ServerCore.AppCompatibility~~~~0.0.1.0 だった場合の例を示します。

Remove-WindowsCapability -Online `
  -Name "ServerCore.AppCompatibility~~~~0.0.1.0"

Restart-Computer

再起動後、System ログに WpnUserService_xxxx 由来の 7023/7031/7036 が記録されないことを確認します。

FoD を外すことのデメリットと代替手段

App Compatibility FOD を削除すると、Server Core 上で次のような GUI ツールが使えなくなります。

FoD に含まれる主な GUI ツール代替手段の例
イベントビューアー（eventvwr.msc）管理用端末からのリモート MMC、または Windows Admin Center
タスクスケジューラ（taskschd.msc）PowerShell の ScheduledTasks モジュール、リモート MMC
ファイル エクスプローラー（explorer.exe）管理端末からの UNC アクセス（\\server\c$ など）
デバイスマネージャー／ディスク管理Hyper-V 管理ツール、Storage 管理用 MMC を別サーバーから実行

「Core なのに GUI を足して楽をしたい」という動機で FoD を入れている場合、削除すると確かに不便になります。逆に「もともと RSAT / Windows Admin Center で全てリモート管理する方針だった」という環境では、FoD を無効にしてしまった方がシンプルで安全な構成になるでしょう。

方法 3：WpnUserService のテンプレートを無効化する

「FoD に含まれる GUI ツールは使いたいが、WpnUserService 関連のログだけはどうにか止めたい」という場合には、per-user service テンプレートとしての WpnUserService を無効化する方法が有効です。

公式ドキュメントに基づく無効化の考え方

per-user services に関する Microsoft ドキュメントでは、ユーザー別サービスを制御する方法として次の 2 点が示されています。

  • テンプレートの Start を 4（Disabled） にすると、作成されるインスタンスは停止・無効状態になる。
  • UserServiceFlags を 0 にすると、そもそも per-user service のインスタンスが作成されなくなる。

WpnUserService も per-user services の一覧に載っており、テンプレートを直接レジストリから制御することが想定されています。

レジストリで WpnUserService テンプレートを無効化する手順

以下は、管理者権限のコマンドプロンプトで WpnUserService のテンプレートを無効化する例です。本番適用前に必ず検証環境でテストしてください。

:: WpnUserService の per-user インスタンス生成を抑止
reg.exe ADD HKLM\System\CurrentControlSet\Services\WpnUserService ^
  /v UserServiceFlags /t REG_DWORD /d 0 /f

:: テンプレート自体を「無効」に設定（Start=4）
reg.exe ADD HKLM\System\CurrentControlSet\Services\WpnUserService ^
  /v Start /t REG_DWORD /d 4 /f

設定後にサーバーを再起動し、再度ログオンして System ログを確認します。WpnUserService_xxxx のサービス インスタンスが作成されなくなり、7023/7031/7036 の連発も発生しなくなるはずです。

ロールバック方法（元に戻す）

環境によって既定値が異なる可能性があるため、厳密には事前に Start と UserServiceFlags の元の値を控えておくのがベストですが、一般的には次のような値になっていることが多いです。

  • Start：2（自動）または 3（手動）
  • UserServiceFlags：1 以上（有効）

仮に「自動起動が既定」と仮定して元に戻す例を示します。

reg.exe ADD HKLM\System\CurrentControlSet\Services\WpnUserService ^
  /v Start /t REG_DWORD /d 2 /f

reg.exe ADD HKLM\System\CurrentControlSet\Services\WpnUserService ^
  /v UserServiceFlags /t REG_DWORD /d 1 /f

こちらも再起動後に動作を確認してください。

副作用の可能性

WpnUserService は通知プラットフォームを担っているため、無効化すると次のような影響が出る可能性があります。

  • トースト通知が表示されなくなる。
  • アクションセンター（通知センター）の表示・履歴が機能しなくなる。
  • 一部の「設定」画面や UWP アプリが通知機構を前提としている場合、その挙動に影響する可能性。

Server Core では GUI の機能自体が非常に限定されているため、実際には影響が表面化しないケースも多いと思われますが、RDS セッションホストとして利用するなど、ユーザーが GUI を多用するサーバーで適用する場合は、事前検証を入念に行ってください。

WpnService（システムサービス）まで無効化してよいのか？

WpnUserService とは別に、WpnService（Windows Push Notifications System Service） というシステムサービスも存在します。セキュリティベンチマークやプライバシー向上ツールの中には、WpnService / WpnUserService をまとめて無効化するスクリプトも存在します。

しかし、クライアント OS では WpnService を無効にするとアクションセンターやネットワーク設定 UI が動かなくなるといった不具合報告もあり、影響範囲が広いことが示唆されています。

本記事で対象としているのはあくまで「Server 2022 Core + App Compatibility FOD」による WpnUserService_xxxx エラーですので、特別な理由がない限り WpnService 側まで手を入れるのは避け、まずは

  • ログ抑止（方法 1）
  • FoD 削除（方法 2）
  • WpnUserService テンプレートだけを無効化（方法 3）

のいずれかで解決することをおすすめします。

App Compatibility FOD の価値と「入れるか・外すか」の判断軸

最後に、今回の問題のきっかけとなっている App Compatibility FoD 自体について、もう少し整理しておきます。

FoD は、Server Core の利点（フットプリントの小ささ・セキュリティ面）を保ちつつ、「最低限の GUI 管理ツールだけ使えるようにする」ための妥協案として設計されています。具体的には、次のようなメリットがあります。

  • 障害時にローカル コンソールからイベントログやタスクスケジューラを直接確認できる。
  • デバイスマネージャーやディスク管理を GUI で操作できるため、トラブルシューティングが容易。
  • MMC ベースの管理ツールを一部ローカルで使える。

一方で、今回のような WpnUserService のログノイズ以外にも、バージョンによっては RDP との相性問題など、細かい不具合が報告されることもあります。

したがって、FoD の導入有無は次のような軸で判断するとよいでしょう。

観点FoD を「入れる」べきケースFoD を「外す」または最初から入れない方がよいケース
運用スタイル現地コンソールからの GUI トラブルシュートが多い。基本は RSAT / Windows Admin Center / PowerShell でリモート管理。
セキュリティポリシーGUI 追加による攻撃面の拡大が許容される。最小限構成を徹底したい、不要なバイナリを減らしたい。
障害対応スキルGUI ベースでの解析の方がチームにとって効率的。CLI / PowerShell での解析に慣れている。

「FoD がほぼ必須な場面」なのか、「なくても困らないが、あると少し楽」というレベルなのかを整理しておくと、今回のような副作用に出会ったときに意思決定がしやすくなります。

実務でのおすすめフロー

ここまでの内容を踏まえ、実務的には次のようなステップで対応するのが現実的です。

  1. 影響の有無を確認する
    対象サーバーでトースト通知やアクションセンターを業務利用していないか、アプリ側で WNS 連携をしていないかを確認します。多くの Server Core 環境では「使っていない」がほとんどでしょう。
  2. まずはログ抑止だけを試す（方法 1）
    イベントビューアーのユーザー定義ビューと SIEM 側の除外ルールで、WpnUserService_xxxx の 7023/7031/7036 をノイズとして扱います。これで運用上の問題が解消されるかを確認します。
  3. FoD の必要性を棚卸しする
    「FoD を外しても困らない」ことが分かれば、方法 2 のアンインストールが最もシンプルです。特に、全管理を Windows Admin Center や PowerShell で行っている場合は、FoD を削除してしまった方が長期的にすっきりします。
  4. FoD は残したい場合のみ、テンプレート無効化（方法 3）を検証
    検証環境で WpnUserService の Start / UserServiceFlags を変更し、想定外の副作用が出ないことを十分確認した上で、本番環境へ段階的に展開します。

いずれの方法を取るにしても、適用後は必ずサーバーを再起動し、再ログオン時に System ログと、通知・アプリ動作の双方を確認してから本番運用に戻すようにしましょう。

まとめ：Server 2022 Core での WpnUserService エラーとの付き合い方

  • App Compatibility FoD を導入した Windows Server 2022 Core で、Windows Push Notifications User Service_xxxx の 7023/7031/7036 が大量発生するのは、多くの事例から見て「仕様と FoD の組み合わせが生むログノイズ」と考えるのが妥当です。
  • Microsoft Q&A でも「harmless（無害）」とされており、機能障害が確認されない限りは、まずログ抑止だけで様子を見るのが安全です。
  • GUI ツールが不要なら、App Compatibility FoD をアンインストールしてしまうのが根本的かつシンプルな解決策です。
  • FoD は残したいがログノイズを止めたい場合は、per-user service の公式ドキュメントに従って WpnUserService テンプレートをレジストリから無効化することで、インスタンス生成を抑止できます。
  • WpnService/WpnUserService の無効化は、クライアント OS では通知や UI に影響する例も知られているため、Server Core であっても必ず検証環境での確認と段階的な展開を行うべきです。

「本当に直さなければいけない不具合」なのか、「運用上のノイズをどう扱うか」という問題なのかを切り分けた上で、自分たちの環境・運用スタイルに合った落としどころを選ぶことが、Windows Server 2022 Core を安定運用するうえでのポイントになります。

Windows Server
イベントログ Windows Server 2022 App Compatibility FOD Server Core WpnUserService

この記事を書いた人

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

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

関連記事

コメント

コメントする

目次