Windows Server 2012 R2 を単一DC（AD DS兼DNS）で運用していると、KB4592484 適用後に再起動のたび DNS サービスが自動開始せず、イベント ID 4013 が記録されることがあります。本記事では原因の考え方と、レジストリを迂回せずに安定化させる現実的な回避策を具体的に解説します。
起きている現象を整理する
まずは、同じ「DNS が起動しない」に見えても状況が違うと対処が変わるため、現象を言語化しておきます。今回のケースは、単一のドメインコントローラー（AD DS）兼 DNSとして運用している Windows Server 2012 R2 に、更新プログラム KB4592484（2020年12月の月例ロールアップ）を適用した後から、再起動時に DNS が自動で立ち上がらない、というものです。
| 項目 | 内容（典型例） | ポイント |
|---|---|---|
| 役割 | AD DS + DNS（単一DC） | DNS ゾーンが AD 統合（Active Directory-integrated）になっていることが多い |
| 発生タイミング | サーバー再起動の直後 | 起動順序・初期化のタイミングの影響を受けやすい |
| 症状 | DNS サービスが「停止」のまま／自動開始しない | 手動で開始すると正常化することが多い |
| イベントログ | DNS イベント ID 4013 | 「AD DS の初期同期（initial synchronization）が完了するまで DNS を開始できない」という趣旨 |
単一DC環境では、DNS が止まると名前解決・認証・グループポリシー・共有アクセスまで連鎖して影響しやすく、体感的には「ネットワーク全体が止まった」ように見えます。原因究明は後回しでもよいので、まずは再起動しても DNS が確実に起動する状態を作るのが最優先です。
「本当に起動しない」の判定基準
4013 が出ていても、DNS が数分後に自動で起動するケースもあります。まずは「待てば動くのか／待っても動かないのか」を切り分けておくと、やるべき対処がブレません。
| 状態 | 見え方 | 優先度 | 考え方 |
|---|---|---|---|
| 起動直後に 4013 が出るが、数分後に DNS が自動で RUNNING になる | 一時的に名前解決が不安定 | 中 | タイミング問題の可能性が高い。遅延開始で再発を抑えやすい |
| 再起動後いつまで待っても DNS が停止のまま | 恒常的に名前解決できない | 高 | 起動順だけでなく、AD DS 側の不調や設定問題が隠れている可能性。まず復旧策（遅延開始/タスク）を入れてから原因調査 |
イベント ID 4013 の意味と、単一DCでも待たされる理由
イベント ID 4013 はざっくり言うと、「DNS サーバーが Active Directory の準備完了（初期同期完了）を待っている」という状態を示します。AD 統合ゾーンを使う DNS は、ゾーン情報や一部のレコードを Active Directory から読み込みます。もし起動直後に AD DS の状態が不安定だったり、ディレクトリデータベースがまだ開いていなかったりすると、DNS は「不完全な情報で応答してしまう」リスクを避けるために待機します。
ここでよく誤解されるのが、「単一DCならレプリケーション相手がいないのだから初期同期の概念がなく、待つ必要もないのでは？」という点です。実運用では、単一DCでも次のような理由で「初期同期完了」とみなされるまでに時間がかかる（あるいは条件が満たされない）ことがあります。
- AD DS 自体のサービス起動が遅い（更新適用直後、ディスク I/O、チェックディスク等）
- 起動直後のネットワーク初期化が遅い（NIC ドライバ、仮想環境、スイッチ側のリンクアップ遅延）
- Directory Service ログに出ている別の警告・エラーにより、AD DS の準備完了が遅れている
- 起動直後に内部 DNS が使えず、AD DS の自己参照の処理が遅れる（単一DCだと連鎖しやすい）
つまり単一DCであっても、DNS が「AD DS の準備完了を確認できない」状態が起動直後に起きれば、4013 が出る可能性があります。今回のケースは起動直後のタイミング問題として説明でき、手動で DNS を開始すると正常化するのも「その時点では AD DS の準備が整っている」ためです。
KB4592484 適用後から発生したように見える理由
「KB4592484 を入れてから突然起きた」と感じる場合でも、更新プログラムが DNS を直接壊したというより、起動直後の時間配分が変わったことで潜在していた条件が表面化するケースがあります。現場でよくある背景を挙げます。
- 更新適用後の初回再起動は、コンポーネントの構成処理が増えて起動が遅くなる
- ロールアップ適用によって、サービス起動順や初期化タイミングの揺らぎが出る
- 同時期にドライバ更新やセキュリティソフト更新が重なり、起動時の I/O が増える
このタイプの問題は「数回再起動したら最終的に自動で立ち上がるようになった」という経過も起こり得ます。だからこそ、まずはDNS の起動を遅らせて安定化させ、必要があれば後半の切り分けで根を潰す、という順番が効率的です。
結論としての最優先：DNS の起動を“遅らせて”安定化させる
DNS が早すぎるタイミングで立ち上がろうとして待たされるなら、発想はシンプルで、DNS の起動を少し遅らせるのが最も手堅い回避策です。レジストリで挙動を無理に変えるより、「待つべきときに待てる状態」を OS 標準の機能で作るほうが、後々のトラブルが少なくなります。
| 対処 | 狙い | 難易度 | 副作用リスク | おすすめ度 |
|---|---|---|---|---|
| DNS を「自動（遅延開始）」にする | AD DS の起動を先に進めてから DNS を開始 | 低 | 低 | 高 |
| スケジュールタスクで起動後に DNS を開始 | 遅延開始の代替／より柔軟に待ち時間を調整 | 中 | 低〜中 | 中 |
| レジストリで初期同期待ちを無効化 | DNS を待たせず起動させる | 中 | 中〜高 | 低 |
対処手順：DNS サービスを「自動（遅延開始）」に変更する
もっとも簡単で、かつ安全側に倒せるのがこの方法です。ポイントは、サービス名（表示名）と実体のサービス名が紛らわしい点で、表示上は DNS Server でも、コマンドではサービス名が DNS です。
GUI（services.msc）で設定する
- 「ファイル名を指定して実行」→ services.msc
- 一覧から DNS Server を開く
- 「スタートアップの種類」を 自動（遅延開始） に変更
- 適用して閉じる
コマンドで設定する（管理者権限）
sc config DNS start= delayed-auto変更後は、念のため現在の設定を確認します。
sc qc DNS設定後は再起動して、DNS が自動で「実行中」になるかを確認してください。再起動のたびに手動起動が必要だった環境でも、この設定だけで改善するケースが多いです。
代替案：スケジュールタスクで“起動後に少し待ってから”DNS を開始する
遅延開始で改善しない場合や、より確実に「○秒待つ」を入れたい場合は、スケジュールタスクを使った遅延起動も有効です。単一DCでは逃げ道が少ないため、保険として仕込んでおく運用も現場ではよく行われます。
| 設定項目 | 推奨値（例） | 意図 |
|---|---|---|
| トリガー | スタートアップ時 | OS 起動完了後に実行 |
| 遅延 | 30秒〜2分 | AD DS の初期化時間を稼ぐ |
| 実行ユーザー | SYSTEM（最上位の特権で実行） | 権限不足を回避 |
| 操作 | DNS サービス開始（sc start / net start） | DNS が停止していたら起動する |
GUI で作る場合の「アクション」例
- プログラム／スクリプト：cmd.exe
- 引数の追加：/c sc start DNS
コマンド（schtasks）で作る例
GUI で作成しても良いですが、手順を固定化するならコマンドが便利です。以下は例なので、タスク名や遅延時間は運用に合わせて調整してください。
schtasks /Create /TN "StartDNSAfterBoot" /SC ONSTART /DELAY 0000:30 /RU "SYSTEM" /RL HIGHEST /TR "cmd.exe /c sc start DNS"このタスクを入れておくと、DNS が自動開始に失敗しても起動後にタスクが拾ってくれるため、現場の「朝イチ障害」をかなり減らせます。
動作確認：DNS が起動し、名前解決できることを確認する
設定を入れたら「サービスが起動した」だけで終わらせず、名前解決まで確認します。単一DCでは DNS がそのまま AD の心臓部なので、確認が短いほど安全です。
- サービス状態：
sc query DNSで RUNNING を確認 - 簡易テスト：
nslookupで自ドメインの名前解決を確認
sc query DNS
nslookup localhost
nslookup _ldap._tcp.dc._msdcs.<あなたのドメイン名>最後の SRV レコードの問い合わせが成功するかを見ると、「DNS と AD の連携」が最低限機能しているかを把握しやすくなります。
レジストリの「Repl Perform Initial Synchronizations」を無効化する案が推奨されにくい理由
相談でよく出てくるのが、レジストリ値 Repl Perform Initial Synchronizations を 0 にして、DNS が AD DS の初期同期待ちをしないようにする案です。確かに理屈の上では「待たずに起動する」方向に寄せられます。しかし、これは DNS 側の安全装置を外す行為に近く、一般には次の理由で推奨されにくいです。
- 本来は「DNS データが揃っていない可能性」を避けるための仕組みで、無効化は迂回になる
- 単一DCでも、起動直後の AD DS が不安定な状態で DNS が動くと、別の不具合（名前解決の揺らぎ、サービス依存の不調）を呼びやすい
- 将来的に DC を増設したとき、設計が変わったときに副作用が表面化しやすい
- 根本原因（AD DS の起動が遅い、ネットワーク初期化が遅い等）を隠してしまい、別の問題が残る
運用者目線で言えば、レジストリ変更は「今だけ動けばOK」を作りやすい一方、“原因が見えないまま”安定しているように見せてしまうのが怖い点です。まずは遅延開始／遅延起動で正攻法に安定化させるのが無難です。
どうしても触るなら守るべき最低限
事情によりレジストリ変更を検討する場合でも、次の前提は守ってください（推奨はしませんが、運用事故を減らすための観点です）。
- 変更前にレジストリのエクスポート（バックアップ）を取る
- 必ずメンテナンス時間に実施し、再起動と動作確認までセットで行う
- 元に戻す手順（ロールバック）を先に用意する
- 将来の DC 増設・更改計画があるなら、そちらを優先してレジストリ変更は避ける
レジストリの場所（例）は次の通りです。
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNS\Parameters
DWORD: Repl Perform Initial Synchronizations値の意味は一般に、1 が「待つ（既定）」、0 が「待たない」です。単一DCだからといって機械的に 0 にするのではなく、まずは本記事の遅延開始／遅延起動を試し、それでも再現する場合に“最後の手段”として検討するのが安全です。
切り分け：AD DS とネットワークの健全性をチェックする
遅延開始で改善するケースが多い一方、起動の遅さの背景に別の問題が隠れていることもあります。単一DCでは「いつの間にか積み上がった小さな不調」が DNS 起動問題として表面化しやすいため、最低限の健全性チェックはおすすめです。
まず確認するイベントログ
- DNS Server：4013 の前後に、別のエラー（ゾーン読み込み失敗など）がないか
- Directory Service：起動直後にエラーが出ていないか（DB、SYSVOL 等）
- System：ネットワーク、ディスク、サービス起動失敗が出ていないか
代表的な確認コマンド
| 目的 | コマンド例 | 見方のポイント |
|---|---|---|
| DNS サービス状態確認 | sc query DNS | STATE が RUNNING になっているか |
| DNS 設定確認（起動方式） | sc qc DNS | START_TYPE が意図通りか（遅延開始になっているか） |
| AD DS 健全性（基本） | dcdiag /v | Failed が出ていないか。特に DNS 関連テストの結果 |
| レプリケーション状態 | repadmin /showrepl | 単一DCなら「隣接がない」表示になることがあるが、異常なエラーがないか |
| NIC・DNS 向き先確認 | ipconfig /all | DNS サーバーが自分自身を向いているか（単一DCなら重要） |
特に ipconfig /all で、NIC の DNS サーバー設定が外部 DNS を優先していたり、過去の DC の IP が残っていたりすると、起動直後の名前解決が揺らいで AD DS の準備完了が遅れることがあります。単一DCでは「自分自身（127.0.0.1 またはサーバーの固定IP）」を基本に、余計な設定がないか見直してください。
単一DCで見落としやすいチェックリスト
| チェック項目 | 確認ポイント | 理由 |
|---|---|---|
| DNS クライアント設定 | 優先 DNS が自分自身になっている | 単一DCだと外部DNS参照が起動時の遅延要因になりやすい |
| NIC が複数ある | 不要な NIC は無効化／DNS 登録設定を整理 | マルチホームは AD/DNS の混乱要因になりやすい |
| DNS ゾーン | 不要なゾーンや古い委任が残っていない | ゾーン読み込みが遅くなる・エラーが混ざる |
| 起動時間 | 更新適用後に極端に伸びていない | ディスクやドライバの問題が隠れていることがある |
運用の実務で効く小ワザ
現場で「再起動したら DNS が止まっていて朝から大騒ぎ」を避けるために、追加で効く対策も紹介します。遅延開始と組み合わせると、再発率をさらに下げられます。
サービスの回復オプションを見直す
DNS サービスが起動に失敗した場合に自動で再試行するよう、サービスの回復（Recovery）を設定しておくと安心です。
- services.msc → DNS Server → 「回復」タブ
- 初回の失敗：サービスの再起動
- 2回目の失敗：サービスの再起動
- 以降の失敗：サービスの再起動
- 再起動までの時間：1分など
起動直後だけ失敗するタイプの問題なら、この設定だけで「放置しても復帰する」状態になり、人的対応を減らせます。
監視・通知は「DNS 停止」と「4013 連発」をトリガーにする
監視がある環境なら、単純に DNS サービス停止を拾うだけでなく、DNS イベント ID 4013 が短時間に繰り返されていないかも見ておくと、根本原因（AD DS 側の起動遅延）が悪化したタイミングに気づきやすくなります。
それでも再発する場合に見るべきポイント
遅延開始を入れても再発する場合、タイミング問題だけでなく、AD DS 側の起動自体が不安定になっている可能性があります。単一DC環境では「DNS を動かす」よりも「AD DS が安定して起動する」ことが本質です。
- 更新適用直後の再起動で発生しやすいか（パッチ適用の影響が濃いか）
- 起動時間が普段より極端に長くないか（ディスク・CPU・メモリ逼迫）
- サードパーティ製セキュリティソフトやバックアップソフトの更新が直前に入っていないか
- System ログにディスクエラー、NTFS、ドライバ関連の警告が出ていないか
- Directory Service ログに DB 修復や再生処理の痕跡がないか
「数回再起動したら最終的に DNS が自動で立ち上がるようになった」という経過がある場合は、まさに起動順・初期化待ちの遅延が主因であることが多く、遅延開始を入れることで再発を抑えやすいパターンです。逆に、再起動のたびに必ず発生する・時間が経っても回復しない場合は、AD DS や OS 全体の健全性を優先して点検してください。
設計面の補足：単一DC運用は“復旧手段が少ない”
今回のような「起動順の問題」は、2台以上の DC があると、片方が不調でももう片方で名前解決や認証を継続でき、被害が限定されます。単一DCは構成がシンプルな反面、障害時の逃げ道がなく、トラブルのたびに運用負荷が跳ね上がります。
可能であれば、次のいずれかを中長期の改善として検討してください。
- DC を 2 台構成にして冗長化（DNS も両方で提供）
- サポート期間の観点も含め、後継の Windows Server へ更改して AD を移行
- バックアップ（システム状態、AD データ）と復旧手順の定期訓練
短期的には遅延開始／遅延起動で安定化させつつ、長期的には「単一障害点を減らす」方向へ寄せるのが、結果として最もコストが下がります。
まとめ：レジストリに頼らず、起動のタイミングを整えるのが最短ルート
KB4592484 適用後に DNS が自動開始しない問題は、イベント ID 4013 が示す通り「AD DS の準備が整う前に DNS が起動しようとして待たされる」タイミング問題で説明できることが多いです。単一DC環境でも起こり得るため、まずは DNS を 自動（遅延開始） に変更し、必要ならスケジュールタスクや回復設定で保険をかけるのが現実的です。
レジストリで初期同期待ちを無効化する方法は、短期的に効く場合があっても安全装置を外す方向のため、安易にはおすすめできません。焦って“仕組みを迂回”する前に、まずは正攻法で「DNS が起動する頃には AD DS が整っている」状態を作り、同時に AD DS と OS の健全性も点検していきましょう。
コメント