Windows Server 2019 のドメインコントローラーが、sconfig で Windows Update を手動にしているのに勝手に再起動する——。イベントログに Event ID 1074（User32）と Reason Code 0x80020010 が出る場合、原因は“更新に伴う計画済み再起動”であることが多いです。ここでは 0x80020010 の正体、再起動を防ぐためのGPO設計、ログでの切り分け手順をまとめます。
症状：Windows Update 起因で勝手に再起動する（Event ID 1074 / 0x80020010）
「勝手に再起動した」と感じるケースでも、Windows は“誰が”“何が”再起動を開始したのかをイベントログに残しています。今回のパターンは次のような内容が典型です。
| 項目 | よく出る値 | 読み取りポイント |
|---|---|---|
| イベント ソース | User32 | OS のシャットダウン/再起動要求が発行されたことを示します（クラッシュではありません）。 |
| Event ID | 1074 | プロセスがシャットダウン/再起動を開始したときに記録されます。 |
| プロセス | C:\Windows\System32\svchost.exe | Windows Update を含む多くのサービスは svchost.exe でホストされるため、“更新系の処理”が疑われます。 |
| ユーザー | NT AUTHORITY\SYSTEM | 管理者が手動で押したのではなく、システム サービスが開始した再起動である可能性が高いです。 |
| Reason | Operating System: Service pack (Planned) | 「計画済み（Planned）」＋「OS 更新（Service Pack 相当）」という意味合いです。 |
| Reason Code | 0x80020010 | ファイルエラーではなく、Windows の「シャットダウン理由コード」です。 |
重要なのは、Event ID 1074 は「電源断やブルースクリーン」ではなく、OS が正常系の手続きで再起動したことを示す点です。もし同時刻に Event ID 41（Kernel-Power）や 6008（予期しないシャットダウン）が出ている場合は、別原因（クラッシュ・電源・ハード）も並行して疑う必要がありますが、今回の Reason（Service pack / Planned）とセットで出ているなら Windows Update 由来の線が濃くなります。
Reason Code 0x80020010 の意味：SHTDN_REASON_* の合算値
0x80020010 は「ディレクトリが削除できない」といったファイル操作のエラーコードではありません。Windows のシャットダウン理由コード（Reason.h）で定義されている “再起動の理由を表すフラグの合算値”です。Microsoft Learn の「システム シャットダウン理由コード」にも、Planned / Major / Minor のビット構成が整理されています。
| ビット（16進） | 区分 | 意味 |
|---|---|---|
| 0x80000000 | Planned | 計画済み（管理/更新など、意図された手順としての再起動） |
| 0x00020000 | Major | Operating System（OS に関する大分類） |
| 0x00000010 | Minor | Service Pack（サービスパック相当の更新処理） |
| 0x80020010 | 合算 | OS 更新（サービスパック相当）に伴う“計画済み”再起動 |
Windows Server 2019 自体は「サービスパック」を提供していませんが、理由コードの “Service Pack” は歴史的な分類名として残っており、実際には累積更新（LCU）やサービススタック系の更新などでもこの表現で記録されることがあります。イベント ビューアー上の「Operating System: Service pack (Planned)」は、上記の合算を人間向けに説明したものです。
また、Microsoft のトラブルシュート記事でも Event ID 1074 の例として同様の文言が挙げられており、Windows Update の再起動で見かけやすいパターンだと分かります。
sconfig で「手動」にしているのに再起動する理由
Server Core の運用では sconfig.cmd を使って Windows Update を「手動」に寄せることが多いですが、ドメイン環境（特にドメインコントローラー）では sconfig の設定だけで挙動が固定されないことがあります。代表的な理由は次のとおりです。
- GPO（ドメインのグループ ポリシー）が上書きしている
ローカルで手動にしても、OU にリンクされた GPO で「自動ダウンロード＋スケジュール インストール」などが設定されていると、定期更新でドメイン設定が優先されます。 - “更新のインストール”と“再起動の扱い”は別物
「インストールは手動」でも、何らかの手段で更新が入った後に“再起動が必要”な状態になれば、ポリシーによっては自動再起動が走ります。 - 誰もログオンしていないサーバーは再起動されやすい
「ログオン ユーザーがいるときは自動再起動しない」系のポリシーは、サインイン ユーザー（RDP セッションなど）が存在する場合にのみ効きます。DC のように普段ログオンしていない運用では、ここに期待しても防ぎ切れません。 - 更新の適用主体が Windows Update とは限らない
WSUS、MECM/SCCM、サードパーティ製パッチ管理、運用スクリプトなどが更新を入れていると、見た目は「Windows Update が勝手に…」でも実態は別プロセス、ということがあります。
結論として、自動再起動を止めたいなら「sconfig で手動」ではなく、GPO（またはローカル ポリシー）で Windows Update の動作を明示的に固定するのが本筋です。
最優先の対策：GPO で「自動インストール＆自動再起動」にならないよう固定する
狙いはシンプルで、Windows Update の挙動を「通知中心（管理者がインストールと再起動を決める）」に寄せます。Microsoft Learn の WSUS 手順でも、GPO で「Configure Automatic Updates」を設定する流れが示されています。
Configure Automatic Updates で何を選ぶべきか
ドメインコントローラーのように“勝手な再起動が困る”サーバーでは、次のいずれかに寄せるのが実務的です。
| 設定値 | 挙動のイメージ | DC 運用での向き不向き |
|---|---|---|
| Disabled（無効） | 自動更新の動作を抑え、手動操作寄りにする | 再起動事故を避けたい場合に分かりやすい。運用でパッチ適用手順を必ず回す前提。 |
| Option 2（Notify for download and notify for install） | ダウンロードもインストールも通知 → 管理者判断で進める | 「自動で入れたくない」派に向く。通知を取りこぼすと未適用が溜まりやすい。 |
| Option 7（Notify to install / Notify to reboot） | インストールも再起動も通知ベースに寄せる | “再起動まで勝手に進めたくない”意図に合いやすい。環境によって表示や動作差があるため検証推奨。 |
| Option 4（Auto download and schedule the install） | ダウンロード＆スケジュール インストール（放置すると進む） | 自動再起動の温床になりやすい。メンテ時間帯が厳密に管理できる場合のみ。 |
「勝手に再起動を止めたい」という目的だけなら、Option 4 のような“スケジュール自動インストール”は避けるのが無難です。特に DC はログオンユーザーが常にいるわけではないため、再起動抑止が働かず夜間に再起動される、といった事故につながります。
GPO の設定場所（Server Core でも管理可能）
設定場所は以下です。
- コンピューターの構成
- 管理用テンプレート
- Windows コンポーネント
- Windows Update
- （Manage end user experience）
- Configure Automatic Updates
Server Core 上で GUI を開けない場合でも、管理端末から「グループ ポリシー管理（GPMC）」で DC の OU にリンクすれば同じ効果が得られます。DC は通常「Domain Controllers」OU 配下にいるため、そこへリンクする GPO の優先度（リンク順、強制、継承ブロック）も合わせて確認してください。
見落としがちな関連ポリシー：再起動を“後押し”する設定を潰す
Configure Automatic Updates だけで止まることも多い一方、環境によっては “再起動を促進するポリシー” が有効になっていて、結果的に自動再起動が発生します。次の項目は特にチェックしてください。
| ポリシー名（代表例） | 狙い/作用 | DC での注意点 |
|---|---|---|
| No auto-restart with logged on users for scheduled automatic updates installations | ログオン ユーザーがいる場合、スケジュール更新で自動再起動しない | ログオンが無いと効かないため、DC の“無人運用”では防ぎ切れません。 |
| Always automatically restart at the scheduled time | スケジュール インストール後の再起動を強制しやすくする | 有効だと事故が増えます。自動再起動を避けたいなら無効方向で検討します。 |
| Specify deadline before auto-restart for update installation | 期限（デッドライン）到達で強制再起動する考え方 | 期限設定が入っていると、たとえ通知中心でも最終的に強制再起動される場合があります。 |
| Re-prompt for restart with scheduled installations | 再起動通知の再表示間隔を制御 | 通知頻度を上げるだけで根本解決ではありません。運用設計とセットで。 |
ここで大事なのは、「ログオン ユーザーがいるときは再起動しない」を“最後の砦”にしないことです。Microsoft Learn の再起動管理の解説でも、ログオン状態の影響が前提になっています。DC は通常ログオンしないため、再起動を止めるには そもそも自動インストール（＝勝手に再起動まで進む流れ）を作らないことが重要です。
適用状況の確認：GPO が効いているかを短時間で判定する
「設定したつもり」でも、別 GPO が勝っていたり、想定外の OU に DC が入っていたりすると挙動は変わりません。まずは“結果”を確認します。
gpresult で結果セットを確認する
Server Core でも次のコマンドで確認できます。
gpresult /r
gpresult /h C:\Temp\gpresult.htmlHTML 出力は管理端末にコピーして確認すると、どの GPO が Windows Update 周りを設定しているか見えやすくなります。
レジストリで Windows Update ポリシー値を確認する
GPO が有効になると、一般に次の場所にポリシー値が反映されます（環境により差分あり）。
HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AUPowerShell で確認する例です。
Get-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU" | Format-Listここに NoAutoUpdate や AUOptions などが設定されていれば、少なくともポリシーが配布されている手がかりになります（値の意味はポリシーの選択肢と対応します）。
svchost.exe の“中身”を特定して、更新系かどうかを裏取りする
Event ID 1074 の詳細情報には、プロセス名だけでなく プロセス ID（PID） が含まれることがあります。PID が分かれば、その svchost.exe がどのサービスをホストしていたかを追えます。
| やりたいこと | コマンド例 | ポイント |
|---|---|---|
| svchost の一覧をサービス名付きで表示 | tasklist /svc /fi "imagename eq svchost.exe" | wuauserv（Windows Update）や UsoSvc（Update Orchestrator Service）などが見つかります。 |
| PID を指定してどのサービスか特定 | tasklist /svc /fi "PID eq 1234" | 1074 の PID と突き合わせると“どのサービスが再起動要求に近いか”のヒントになります。 |
ただし、再起動後は PID が変わるため、「再起動が発生した直前の情報」を拾うことが重要です。監視製品でプロセス一覧を採取している場合は、そのログも有効です。
「本当に Windows Update が引き金か」をログで確定する
勝手に再起動したとき、対策を急ぐほど原因の特定が曖昧になりがちです。Event ID 1074 を起点に、前後のログを突合すると「Windows Update → 再起動要求」の流れを固めやすくなります。Microsoft も複数イベントの相関で原因を絞る方法を推奨しています。
見るべきログと観点
| ログ | 場所 | 確認したいこと |
|---|---|---|
| System（システム） | イベント ビューアー / wevtutil | 1074 の直前・直後に何が出ているか（更新、サービス停止/開始、シャットダウン開始/完了）。 |
| WindowsUpdateClient/Operational | アプリケーションとサービス ログ | 更新のインストール成功・失敗、再起動要求（restart required 系）の記録。 |
| UpdateOrchestrator/Operational | アプリケーションとサービス ログ | 再起動のスケジュール、再起動タスク実行の痕跡（環境によって有効/無効）。 |
| Setup | イベント ビューアー | 累積更新やサービススタック更新の適用履歴の補助情報。 |
| Task Scheduler | \Microsoft\Windows\UpdateOrchestrator など | 再起動関連タスク（Reboot など）の最終実行時刻。 |
Server Core で前後のイベントを素早く抽出する例
GUI が無くても、wevtutil や PowerShell で必要部分だけ抜き出せます。
System ログから 1074 を抽出
wevtutil qe System /q:"*[System[(EventID=1074)]]" /f:text /c:5WindowsUpdateClient の運用ログを確認
wevtutil el | findstr /i WindowsUpdate
wevtutil qe "Microsoft-Windows-WindowsUpdateClient/Operational" /f:text /c:50PowerShell で時刻範囲を絞って確認（例：直近24時間）
$start = (Get-Date).AddHours(-24)
Get-WinEvent -FilterHashtable @{LogName='System'; Id=1074; StartTime=$start} | Select-Object TimeCreated, Message | Format-List1074 の直前に「更新のインストール成功」「再起動が必要」などが並んでいれば、更新起因である確度が上がります。
それでも再起動が止まらないときの追加チェック
GPO を見直しても改善しない場合、次の“上流”を疑うと原因に近づきます。
ドメイン全体で配布しているセキュリティ ベースライン
Microsoft Security Baseline や組織の標準 GPO が、更新の自動化（期限、強制再起動）を有効にしていることがあります。DC 用に例外を作るべきかは組織ポリシー次第ですが、少なくとも「どの GPO がその値を設定しているか」は把握しておくとトラブル対応が速くなります。
WSUS / MECM（SCCM）/ サードパーティ製パッチ管理
WSUS や MECM を使っている場合、クライアントの Windows Update 設定は“管理製品の方針”に引っ張られます。特に MECM は再起動制御（リブート コーディネーション）を持つため、Windows 側のポリシーを変えても再起動が発生することがあります。運用チーム間で「更新の適用主体」を必ず確認してください。
再起動関連タスクの存在（Update Orchestrator）
Windows Update は「更新が必要」「再起動が必要」と判断すると、Update Orchestrator 系の仕組みで再起動を調整します。タスクの存在自体は正常ですが、挙動確認として“最終実行時刻”を把握しておくと、1074 と時刻が一致するかを見られます。
Get-ScheduledTask -TaskPath "\Microsoft\Windows\UpdateOrchestrator\" | Select-Object TaskName, Stateタスクを無効化して強引に止める方法も情報としては存在しますが、更新適用そのものに支障が出たり、意図せぬ未適用状態を作りやすいので、まずは GPO と更新管理の設計で“勝手に再起動しない流れ”に戻すことを優先してください。
「再起動保留（Pending reboot）」の検出
更新を入れた直後に再起動せず放置すると、次のメンテ以外のタイミングで“再起動が必要”と判断され、ポリシーにより再起動が走ることがあります。目安として、再起動保留状態の確認は有効です。
# 代表的な再起動保留の手がかり（簡易チェック）
Test-Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\RebootPending"
Test-Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update\RebootRequired"もちろん、これらが存在しても「必ず自動再起動する」わけではありません。ただし「いつ再起動してもおかしくない状態」であることは分かるため、DC では早めに計画再起動へ寄せた方が安全です。
緊急回避：再起動カウントダウンが出たときの最小手当
更新やサービスが再起動を要求した直後、コンソールに「このシステムはシャットダウンされます」といったカウントダウンが表示されることがあります。その瞬間だけ止めたい場合、次のコマンドで中止できるケースがあります。
shutdown /aただし、恒久対策ではありません。根本的には GPO と更新運用を整え、「勝手に再起動が走る条件」を作らないことが最重要です。
ドメインコントローラーで安全に更新する運用例
自動再起動を止めるだけだと「更新が当たらないサーバー」が出来上がってしまいます。DC はセキュリティ更新の優先度が高い一方で、再起動のタイミングも厳密に管理したい役割です。そこで、通知中心に寄せたうえで、次のように“人が回す手順”を用意しておくと事故が減ります。
ローリング更新（2台以上の DC がある前提）
- 事前ヘルスチェック
repadmin /replsummary、DNS 状態、時刻同期、イベントログ（Directory Service / DNS Server）を確認。 - 片系 DC から更新を適用
運用時間帯に Windows Update（または WSUS/MECM）で更新を適用し、完了後に管理者が明示的に再起動。 - 再起動後の確認
AD DS、DNS、SYSVOL、レプリケーション、ログオン試験を実施。 - もう一方の DC に展開
同様に更新→手動再起動→確認。
運用で押さえたいポイント
- 「更新を入れたらその場で再起動」までをセットにして、再起動保留を残さない。
- 再起動前後のイベント（1074、WindowsUpdateClient）をテンプレ化して記録する。
- 夜間の自動再起動を避けたい場合は、自動インストールを採用しない（または厳密なメンテ時間帯に限定する）。
- 2台構成でも、片系が落ちる前提で DNS/GC/サイト構成を見直し、サービス継続性を担保する。
まとめ：0x80020010 は“計画済みの OS 更新再起動”。止めるなら GPO で挙動を固定する
- Reason Code 0x80020010 は、Windows のシャットダウン理由コードで「OS 更新（Service Pack 相当）に伴う計画済み再起動」を示します。
- sconfig の手動設定だけでは、GPO や更新管理製品の方針で上書きされることがあります。
- 自動再起動を防ぐ本筋は、GPO（またはローカル ポリシー）で Configure Automatic Updates を見直し、通知中心（手動でインストール/再起動）へ寄せることです。
- 原因を固めるには、1074 の前後で WindowsUpdateClient/Operational などを突合して“更新→再起動要求”の流れを確認します。
コメント