Windows Server 2019 Essentials が毎週火曜朝に勝手に再起動／シャットダウンし、イベントログに silsvc.exe（Licensing Compliance Service）が記録される場合、故障よりも「Essentials のライセンス準拠チェック」が原因であることが多いです。原因の特定手順と、再発しない現実的な対処をまとめます。
現象：silsvc.exe（Licensing Compliance Service）がシャットダウンを開始する
この症状は「突然落ちる」ように見えますが、ログを読むとシステム自らが“意図して”シャットダウンを実行していることが分かります。典型的には以下の流れです。
- Windows のSystem ログに「C:\Windows\System32\silsvc.exe がシャットダウンを開始した」旨が出る
- 同時刻付近に Server Infrastructure Licensing のOperational ログで、User Count Check 等のチェックが “out of compliance” と判定
- 「○日以内に是正しないと自動シャットダウンする」という猶予メッセージが出て、期限到来で落ちる
| 確認ポイント | どこを見る | よく出る兆候 | 意味 |
|---|---|---|---|
| シャットダウンの“実行者” | イベント ビューアー > Windows ログ > System | silsvc.exe が NT AUTHORITY\SYSTEM としてシャットダウンを開始 | 更新・電源断ではなく「ライセンス準拠サービスが落としている」可能性が高い |
| 本当の原因（どのチェックがNGか） | アプリケーションとサービス ログ > Microsoft > Windows > Server Infrastructure Licensing > Operational | User Count Check / Non-domain Member Check などのエラー・警告 | ここに“何が非準拠か”が書かれる（対処はチェック種別で変わる） |
| 「火曜だから Windows Update？」の切り分け | System / WindowsUpdateClient / TaskScheduler など | 更新再起動なら WindowsUpdateClient や RebootRequired が前後に出やすい | silsvc.exe が主語なら、まずは更新よりライセンス側を疑う |
結論：故障ではなく「Essentials のライセンス準拠チェック」に引っかかっている
Windows Server Essentials 系列には、ライセンス条項に合っているかを定期的に確認する仕組み（Server Infrastructure Licensing / Licensing Compliance）が組み込まれており、非準拠が解消されないと警告 → 猶予 → 自動シャットダウンに進みます。Microsoft Q&A でも、silsvc.exe が落とした後に「Server Infrastructure Licensing の Operational ログを見て」と案内され、User Count Check が原因だった事例が複数報告されています。
ここで重要なのは、“silsvc.exe を止める”ことが根本解決にならない点です。落ちている理由は「サービスの誤動作」ではなく、その環境が Essentials の使用条件に合っていないという判定だからです。対処は必ず非準拠の原因を特定して是正する方向になります。
Windows Server 2019 Essentials の前提：2019 は「機能」より「ライセンス条件」が本体
Windows Server 2019 Essentials は、以前の Essentials と同様に “小規模向け” の位置づけですが、2019 ではEssentials Experience ロール（ダッシュボード等）が削除され、管理は従来の Windows Server と同じく手動で行う形になっています。その一方で、ライセンス上限（ユーザー数など）や、AD 構成に関する制約は残るため、構成が噛み合わないと今回のような自動シャットダウンに直結します。
「端末は 10 台くらいだから大丈夫」と思っていても、Essentials が見ているのは端末台数ではなく“条件”です。とくに以下が原因になりやすいです。
引っかかりポイント：どこで非準拠になりやすいか
User Count Check：端末台数ではなく「ユーザーアカウント数」上限が刺さる
User Count Check は文字通り、環境内のユーザーアカウント数が上限を超えていないかを見ます。Windows Server 2019 Essentials は、Microsoft の製品条項で最大 25 ユーザーアカウントという制限が明記されています。
ここでの落とし穴は次の通りです。
- 「接続している PC が 10 台」でも、ユーザーが 26 を超えたらアウト
- ワークグループ運用の場合はローカルユーザーが増えて上限を超えることがある
- ドメイン運用の場合はAD のユーザーが増えて上限を超えることがある
- アプリや機能が自動で複数アカウントを作るケースがあり、気づきにくい（例：SQL Server 関連で SQLEXPRESS 系アカウントが増えて上限超過になった報告）
| 状況 | カウント対象のイメージ | まず確認する場所 | やりがちな勘違い |
|---|---|---|---|
| ワークグループ（ドメインなし） | ローカルユーザー（SAM） | コンピューターの管理 > ローカル ユーザーとグループ、または PowerShell | 「ユーザーを作ってないのに超える？」→ ソフトが作っていることがある |
| ドメイン コントローラー（DC） | Active Directory のユーザー | Active Directory ユーザーとコンピューター、または PowerShell | 「端末 10 台だからOK」→ 端末数は関係ない |
ワークグループ運用での確認（例）：
# ローカルユーザー一覧
Get-LocalUser | Select-Object Name, Enabled, LastLogon
# ローカルユーザー数
(Get-LocalUser).Countドメイン（DC）運用での確認（例）：
# ADユーザー数（概算）
Get-ADUser -Filter * | Measure-Object上限を超えていたら、まずは不要なユーザーの整理が必要です。ただし、いきなり削除するとサービスが停止することがあるため、次のような順番が安全です。
- “見覚えのないユーザー” を名前で洗い出す（プレフィックスが揃っている、同日に大量作成など）
- そのユーザーが紐づくサービス／タスク／アプリを特定する（サービスのログオンアカウント、インストールした機能）
- 不要と判断できるものから無効化 → 影響確認 → 削除
SQL Server Express などで「いつの間にかユーザーが増えていた」報告は現実にあり、インストールした機能（分析・機械学習系、補助サービス等）によって複数アカウントが作られることがあります。該当する場合は、不要な機能を外す／構成を見直すのが再発防止として有効です。
Non-domain Member Check：ドメイン参加の「メンバーサーバー」が許されないケース
Essentials のチェックには、ドメインに参加している“メンバーサーバー状態”を非準拠と判定するものがあります。Microsoft Q&A では「このサーバーはワークグループかドメインコントローラーのどちらかである必要がある」という趣旨のメッセージ（Non-domain Member Check）が出て自動シャットダウンした事例が報告されています。
つまり、方針は二択になりがちです。
- Essentials を続けたい：ワークグループ運用に戻す、もしくは DC として要件を満たす
- ドメインに参加したメンバーサーバーとして運用したい：Essentials ではなく Standard/Datacenter を選ぶ（CAL 含め再設計）
とくに Hyper-V 構成で「ホストに Essentials を入れてドメイン参加させた」ようなパターンは、このチェックに引っかかりやすいので要注意です。ホスト OS をドメイン参加させたい要件があるなら、最初から Standard/Datacenter を検討したほうが事故が減ります。
DC として運用する場合の AD 要件：単独 DC／FSMO 全保持／trust なし など
Windows Server 2019 Essentials は、Microsoft 公式ブログでも「DC として構成する場合は単独 DC で、FSMO をすべて保持し、他ドメインとの双方向 trust を持てない」という制約が明示されています。製品条項でも、同様に FSMO・フォレスト ルート・trust なし等の条件が書かれています。
DC として運用する方針なら、以下のような点をチェックして是正します。
| チェック項目 | 確認コマンド例 | 期待される状態 | 非準拠になりやすい例 |
|---|---|---|---|
| FSMO 役割 | netdom query fsmo | Essentials サーバーが全 FSMO を保持 | 別 DC に FSMO が残っている／移行途中で止まっている |
| ドメイン コントローラー数 | Get-ADDomainController -Filter * | DC が Essentials の 1 台のみ | 冗長化のために 2 台目 DC を立てた |
| trust（信頼関係） | Get-ADTrust -Filter * | 他ドメインとの trust がない | 別ドメイン・別フォレストと連携した |
「DC にしたくない」という方針がある場合、この要件を満たすために無理に DC 化するより、Standard/Datacenter へ移行したほうが運用の自由度が高く、長期的には安全です。
原因特定の最短ルート：Operational ログで“どのチェックが落ちたか”を見る
やることはシンプルです。“どのチェック”が非準拠かを先に確定させると、対応が迷子になりません。
- イベント ビューアーで、落ちた時刻付近の System ログを確認（silsvc.exe が主語かどうか）
- 次に、Server Infrastructure Licensing > Operational を同時刻付近で確認
- User Count Check / Non-domain Member Check / Forest Trust Check など、チェック名をメモ
- チェック名ごとの対処を実施し、警告イベントが消えることを確認
PowerShell で横断的に探す場合は、ログ名が環境で見え方が違うことがあるので、まず「該当ログ名を一覧から探す」方法が確実です。
# “ServerInfrastructureLicensing” を含むログ名を探す（まずはこれが安全）
Get-WinEvent -ListLog * |
Where-Object { $_.LogName -like "*ServerInfrastructureLicensing*" } |
Select-Object LogName
# 見つかった LogName を使って直近の警告/エラーを表示（例）
$log = "Microsoft-Windows-ServerInfrastructureLicensing/Operational"
Get-WinEvent -FilterHashtable @{LogName=$log; StartTime=(Get-Date).AddDays(-14)} |
Where-Object { $_.LevelDisplayName -in @("Warning","Error") } |
Select-Object TimeCreated, Id, LevelDisplayName, Message |
Format-Table -Autoやってはいけない回避策：silsvc.exe の無効化・改変は“止まらない上に危険”
「silsvc.exe を停止すれば動き続けるのでは？」と考えがちですが、これはおすすめできません。
- この挙動は “障害” ではなく “ライセンス準拠の仕組み” が動いている可能性が高い
- OS の保護機構（更新、整合性チェック等）で元に戻る／別経路で処理されることがある
- ライセンス条項に抵触するリスクがあり、監査・サポート面でも不利
- 結果的に「原因が見えなくなる」「別の不具合を誘発する」ことが多い
停止を試しても止まらないケースがあるのは、まさにこの“仕組み側”が本体だからです。遠回りせず、Operational ログで原因を特定して是正するのが最短です。
現実的な解決策：Essentials を守って直すか、Standard/Datacenter に移行するか
ここが最重要です。Essentials の制約とやりたい運用が噛み合わないと、今回のような自動シャットダウンは再発します。判断材料を表にまとめます。
| やりたいこと | Essentials で現実的？ | おすすめの方向 | 理由 |
|---|---|---|---|
| 小規模（最大 25 ユーザー）で、単独サーバー中心 | はい（要件内なら） | Essentials 継続 | 制約に合えばコスト・運用がシンプル |
| 「DC にしたくない」かつ「ドメインに参加してファイルサーバーにしたい」 | 難しい | Standard/Datacenter | Essentials のチェックに触れやすい（メンバーサーバー運用と相性が悪い） |
| 複数 DC / trust / Azure AD 連携など拡張したい | 難しい | Standard/Datacenter | DC 要件・trust 制約がボトルネックになる |
| ユーザーが 25 を超える見込み | いいえ | Standard/Datacenter | User Count Check が根本的に回避不能 |
Standard/Datacenter は、一般にアクセス用の CAL（ユーザー CAL / デバイス CAL）が必要です。Essentials のような“上限付き・CAL不要”の枠から出る代わりに、構成の自由度が上がります。
また、Essentials からフル版（Standard 等）への切替は、Microsoft Learn のドキュメントでも「Essentials ならプロダクトキーを入れて変換できる」旨が案内されています。正規ライセンスを用意した上で、バックアップ・停止時間・DC かどうかなどを踏まえて計画的に実施してください。
再発防止：次の“火曜朝”を迎える前にやっておくこと
原因を潰したつもりでも、別のチェックで再度 “out of compliance” になることがあります。運用面では以下が効きます。
- 警告イベントを見逃さない：Operational ログの Warning/Error が出たら通知（タスクスケジューラでイベントトリガー、監視ツールで収集など）
- ユーザー数の棚卸しを定期化：月次でローカル/AD のユーザー数を確認し、増えていたら理由を記録
- 新規ソフト導入時に“ユーザーが増えるか”を確認：特にサーバー上で DB/分析系を入れる場合は注意
- 方針の明文化：「このサーバーは workgroup でいく」「DC にする」「将来 Standard にする」などを決め、場当たり対応を減らす
「毎週同じ曜日・同じ時間帯に落ちる」系は、ハード故障よりも“仕組みが定期的に動いている”可能性が高いです。silsvc.exe が絡んだら、最初に見るべきは更新ではなくServer Infrastructure Licensing の Operational ログです。
参考リンク（公式情報・事例）
- 毎週火曜に再起動する（User Count Check）事例（Microsoft Q&A）
- SQL 関連アカウント増加で上限超過になった事例（Microsoft Q&A）
- Non-domain Member Check / Forest Trust Check の事例（Microsoft Q&A）
- Windows Server 2019 Essentials update（Microsoft 公式ブログ）
- What’s New in Windows Server 2019 Essentials（Essentials Experience ロール削除）（Microsoft Learn）
- Windows Server 2019 Essentials の追加条項（Product Terms）
- Windows Server ライセンス概要（Standard/Datacenter と CAL）（Microsoft）
- Windows Server のアップグレード／変換（Essentials の変換含む）（Microsoft Learn）
コメント