Windows Server 2012 R2 Essentials から 2016 Essentials へインプレースアップグレード後、Windows Update で Windows Defender の更新（定義／エンジン／プラットフォーム）が検出されるタイミングでサーバーがハングしてしまう――この手のトラブルは「Defender を完全削除して入れ直す」より先に、OS 側（システムファイル／コンポーネントストア）の破損を修復し、ログで“固まる瞬間”の原因を切り分ける方が安全で早いことが多いです。
症状の整理：起きていることを“更新経路”で分けて考える
まず重要なのは、Defender の更新には大きく分けて複数の経路がある点です。今回のケースは「Defender 本体（または Defender のコマンド）からの定義更新は通るが、Windows Update 経由で Defender 更新が来ると固まる」というのがポイントになります。
| 観測される状況 | 意味する可能性 | 優先すべき切り分け |
|---|---|---|
| Server 2012 R2 Essentials → 2016 Essentials へインプレースアップグレード後から不安定 | アップグレード由来のコンポーネントストア破損／更新基盤の不整合が疑わしい | SFC/DISM で OS 側の整合性を回復 |
| Defender 機能を削除すると安定 | Defender 更新処理（TrustedInstaller や更新適用）と衝突している可能性 | 「削除しきり」よりも、更新適用時に壊れる箇所をログで特定 |
| Defender 本体から定義更新はできる | ネットワーク到達性だけが原因ではない（WU 由来の処理で問題が出る） | WU コンポーネント／CBS／セットアップログに焦点 |
| Windows Update が Defender 更新を検出すると最終的にハング | 更新メタデータ、コンポーネントストア、WMI、ドライバ、I/O 逼迫など幅広い可能性 | ハング前後のイベントログ＋CBS.log などの時系列確認 |
「Defender の痕跡を完全に消す」アプローチは、一見近道に見えます。しかしインプレースアップグレード直後の環境では、Defender そのものというよりも、Defender 更新を“適用する側”の OS 更新基盤（コンポーネントストアや更新サービス）が壊れているケースが多く、ここを直さない限り再発しがちです。
作業前の準備：サーバーが固まっても復旧できる状態で進める
今回のように「更新適用で固まる」事象は、作業中に再発しやすいです。復旧が遅れると業務影響が大きいので、事前準備を固めてから進めてください。
- フルバックアップ（可能ならシステム状態も）を取得する
- 仮想環境ならスナップショット、物理なら iLO/iDRAC 等のリモートコンソールを確保する
- ローカル管理者でのログオン手段を用意（ドメイン依存を避ける）
- 空き容量を確保（C: の空きが少ないと更新が破綻しやすい）
- 再起動が必要な保留状態がないか確認（保留があると更新が絡みやすい）
| チェック項目 | 目安 | 理由 |
|---|---|---|
| C ドライブ空き容量 | 最低でも 15〜20GB 程度（可能ならもっと） | コンポーネントストア展開やログ出力で急激に消費される |
| 保留中の再起動 | 作業前に一度再起動してから着手 | 中途半端な保留状態で DISM/WU を回すと泥沼化しやすい |
| メンテナンス時間 | 余裕のある枠 | SFC/DISM は環境によって長時間化する |
| サードパーティAV/EDR | 入っていない／完全に削除済みを確認 | 更新時のロックやサービス競合の原因になりやすい |
最優先：OS の整合性チェックと修復（SFC / DISM）
相談内容の結論に近い部分ですが、Defender の“削除しきり”を狙う前に、まずは OS 側の破損を疑って修復するのが第一手です。インプレースアップグレードは便利な反面、コンポーネントストア（WinSxS）や更新適用の履歴が“引き継がれる”ため、壊れ方も引き継ぎやすいからです。
以下は、管理者権限のコマンドプロンプトで実行します。
SFC と DISM の実行手順
sfc /scannow
dism /online /cleanup-image /scanhealth
dism /online /cleanup-image /restorehealth| コマンド | 目的 | 結果の見方 | 注意点 |
|---|---|---|---|
sfc /scannow | システムファイルの破損検出／自動修復 | 「破損ファイルを修復しました」なら再起動して次へ | 途中で止まって見えても待つ（ログは CBS.log に残る） |
dism /online /cleanup-image /scanhealth | コンポーネントストアの破損有無を検査 | 修復可能かどうかの判断材料になる | 検査なので直らない。次の restorehealth が本番 |
dism /online /cleanup-image /restorehealth | コンポーネントストア修復（更新基盤の土台を直す） | 完了後、再起動して Windows Update を再テスト | 更新元が必要。WU が壊れている場合は /source 指定が必要になることがある |
DISM が「ソースが見つからない」等で失敗する場合
Windows Update 自体が壊れている、または修復に必要なファイルがローカルに無い場合、/restorehealth が失敗することがあります。その場合は、Server 2016 のインストールメディア（同一エディション・同一ビルドに近いもの）を用意し、ソースを明示して修復するのが定石です。
例として流れだけ書くと、次のようになります（実際のドライブ文字や index は環境で変わります）。
dism /get-wiminfo /wimfile:D:\sources\install.wim
dism /online /cleanup-image /restorehealth /source:wim:D:\sources\install.wim:1 /limitaccess/limitaccessは Windows Update へ取りに行かない指定です（WSUS 運用や WU 破損時に有効な場合があります）。- install.wim の index は環境により異なるため、必ず
/get-wiminfoで確認してください。
追加で効くことがある：コンポーネントクリーンアップ
修復後も更新適用が不安定な場合、コンポーネントストアのクリーンアップで改善することがあります（ただし時間がかかることがあります）。
dism /online /cleanup-image /startcomponentcleanup固まるタイミングを“記録”する：イベントログと各種ログの確認
「ハングする」という現象は、ログが途切れやすく原因が見えづらいのが難点です。だからこそ、再起動後に“固まる直前までに何が起きていたか”を時系列で追います。Windows Update と Defender 更新は、裏側では TrustedInstaller、CBS（Component-Based Servicing）、WindowsUpdateClient など複数コンポーネントが連携します。どこで破綻しているかを絞り込むことが、再発防止にも直結します。
イベント ビューアーで見る場所
- イベント ビューアー → Windows ログ
- Application（アプリケーション）
- System（システム）
- Setup（セットアップ）
フィルターで絞るなら、例えば以下のソースやキーワードが手掛かりになります。
- WindowsUpdateClient（更新の検出／ダウンロード／インストールの段階が残る）
- Service Control Manager（サービスの停止／起動が失敗していないか）
- Microsoft-Windows-Windows Defender（Defender 側のエラー）
- Disk / storahci / iaStor / Ntfs など（I/O が詰まって“固まったように見える”ケースの確認）
追加で確認すべきログファイル
| ログ | パス | 主に分かること | 見るポイント |
|---|---|---|---|
| CBS ログ | C:\Windows\Logs\CBS\CBS.log | SFC/DISM/更新適用の内部処理 | エラーコード、パッケージ名、再試行、破損の痕跡 |
| CBS 永続ログ | C:\Windows\Logs\CBS\CbsPersist_*.log | 過去の CBS ログ（ローテーション分） | 直近の CBS.log に残っていない履歴の補完 |
| セットアップログ | %WINDIR%\Panther\setupact.log | セットアップ処理（アップグレード含む）の記録 | アップグレード後も残る不整合の痕跡がないか |
| セットアップエラーログ | %WINDIR%\Panther\setuperr.log | セットアップの明確なエラー | 致命的な失敗が記録されていないか |
| DISM ログ | C:\Windows\Logs\DISM\dism.log | DISM 実行時の詳細 | restorehealth がどの段階で失敗するか |
Windows Update のログ（WindowsUpdate.log）も用意する
Server 2016 世代では、従来の C:\Windows\WindowsUpdate.log が常に更新される方式ではありません。必要に応じて PowerShell で生成します（管理者で実行）。
Get-WindowsUpdateLog生成された WindowsUpdate.log を、固まった直前・直後の時刻で追うと「どの更新を処理していたか」「どのコンポーネントで詰まったか」が見えやすくなります。
ここまでで改善しない場合：Windows Update 側の破損を疑い“更新コンポーネント”をリセットする
SFC/DISM で OS の土台を整えても、Windows Update の検出・適用が不自然に重い／特定の更新だけで固まる場合は、Windows Update のキャッシュや暗号化カタログの破損が絡んでいることがあります。特にインプレースアップグレード後は、古い更新データベースを引きずりやすいのが落とし穴です。
代表的なリセット手順は次のとおりです（管理者権限のコマンドプロンプト）。
net stop wuauserv
net stop bits
net stop cryptsvc
net stop msiserver
ren C:\Windows\SoftwareDistribution SoftwareDistribution.old
ren C:\Windows\System32\catroot2 catroot2.old
net start msiserver
net start cryptsvc
net start bits
net start wuauserv| 項目 | 役割 | リセットが効くケース | 注意点 |
|---|---|---|---|
| SoftwareDistribution | 更新のダウンロードキャッシュ／履歴情報 | 検出が異常に遅い、ダウンロードがループする、同じ更新が何度も出る | 更新履歴の表示は消えるが、適用済み更新そのものは消えない |
| catroot2 | 署名検証に関わる暗号化カタログ | 署名関連のエラー、更新の検証段階で失敗する | サービス停止が必須。フォルダ削除ではなく rename が安全 |
| BITS / WUAUSERV | 更新の転送／更新エンジン | 更新が進まない、ダウンロードが始まらない | 業務時間中の実行は避け、メンテ枠で実施する |
リセット後は一度再起動し、Windows Update の「更新プログラムの確認」から再テストします。ここで Defender 更新が再度出てくるか、出てきたとして固まるか、挙動が変わるかを観察します。
「Defender 定義更新はできるのに、Windows Update 経由だと固まる」時の追加の見立て
Defender の更新は、単純な定義ファイルだけではなく、環境によってはエンジン／プラットフォーム更新が絡むことがあります。Defender 側からの更新が通っても、Windows Update が別の更新（プラットフォーム更新や関連コンポーネント）を検出して適用しようとして詰まる、という構図は珍しくありません。
Defender の状態を確認する（PowerShell）
まずは Defender の状態を把握して、更新適用の“前提条件”が満たされているか確認します（管理者 PowerShell）。
Get-MpComputerStatusここで確認したいのは、ざっくり次のような項目です。
- Defender が有効か（サービス停止状態になっていないか）
- リアルタイム保護の状態
- シグネチャ（定義）関連のバージョンが不自然に古い／更新が失敗していないか
定義の“掃除”をしてから再更新する（影響を最小にした切り分け）
「Defender を完全に消す」前に、まずは定義の削除→再取得で改善するか試す価値があります。Defender の定義が破損している／差分更新が噛み合っていないと、更新適用の局面で無駄に詰まりやすくなるためです。
"%ProgramFiles%\Windows Defender\MpCmdRun.exe" -RemoveDefinitions -All
"%ProgramFiles%\Windows Defender\MpCmdRun.exe" -SignatureUpdateこの手順の狙いは「Defender の状態を初期化に近づけ、更新の前提を整える」ことです。OS そのものの破損が強い場合は効果が限定的ですが、症状が軽くなる／固まるまでの時間が変わるなど、切り分け情報としても有効です。
更新適用中だけ一時的にリアルタイム保護を止めてみる（切り分け用）
更新適用中に I/O 競合が疑われる場合、切り分けとして一時的にリアルタイム保護を止めて挙動が変わるか確認します。これは恒久対策ではなく、原因の絞り込みに使います。
Set-MpPreference -DisableRealtimeMonitoring $true
# Windows Update を実行して挙動確認
Set-MpPreference -DisableRealtimeMonitoring $false- 適用テストはメンテナンス枠で実施し、確認後は必ず元に戻します。
- ネットワーク的に外部と遮断できる／影響が限定できるタイミングでのみ実施してください。
“削除しきり”は最終手段：機能としての Defender を削除→再追加する手順
SFC/DISM とログ確認、Windows Update コンポーネントのリセットまでやっても改善しない場合に限り、「Defender 機能の削除と再インストール」を検討します。ここで大事なのは、フォルダを手作業で消すような“痕跡削除”に寄せないことです。OS の保護対象に手を入れると、状況が悪化したり、将来の累積更新で破綻しやすくなります。
PowerShell で Defender 関連機能を確認する
機能名は環境によって表示が異なることがあるため、まずは “Defender を含む機能名” を一覧します（管理者 PowerShell）。
Get-WindowsFeature *Defender* | Format-Table DisplayName, Name, InstallState -Autoここで InstallState が Installed のものが対象です。表示された Name を使って削除します。
Defender 関連機能を削除する（例）
下記はあくまで例です。必ず前段の一覧で実際の名前を確認してから置き換えてください。
Uninstall-WindowsFeature -Name Windows-Defender-Features -Restart再起動後、同様に再インストールします。
Install-WindowsFeature -Name Windows-Defender-Features -RestartGUI で行う場合は、サーバーマネージャーの「役割と機能の追加」ウィザードで Windows Defender 機能 を外して再起動 → 再度追加、という流れになります。
再インストール後にやること
- まず Defender 側から定義更新が通るか確認
- 次に Windows Update の「更新プログラムの確認」を実行し、Defender 更新が検出されても固まらないか確認
- 同時にイベントログ（System/Setup）と CBS.log を確認し、エラーが出ていないかチェック
それでも固まる場合に疑うべき“周辺要因”
ここまでの対策をしてもなおハングする場合、「更新処理をきっかけに表面化する別要因」を疑います。特にサーバーが完全に無応答になり、マウスや RDP が効かなくなるレベルなら、単なる更新失敗ではなく、ストレージやドライバ、フィルタドライバ（セキュリティ系）絡みの可能性も出てきます。
| 疑うポイント | 典型的な兆候 | 確認先 | 打ち手の例 |
|---|---|---|---|
| ストレージ/I/O 詰まり | 更新時にディスク使用率が張り付き、操作不能になる | System ログ（Disk/Ntfs/stor*）、タスクマネージャー | ドライバ/ファーム更新、空き容量確保、別時間帯で再試行 |
| 保留中の更新／再起動待ち | 更新が同じ所で止まる、毎回同じ KB で不調 | Setup ログ、WindowsUpdate.log | 一度“保留を解消”してから適用順序を整える |
| WMI の破損 | 更新検出が異常に遅い／管理系ツールが不調 | Application/System ログ、WMI 関連イベント | WMI リポジトリの検証・修復（慎重に） |
| サードパーティ製セキュリティの残骸 | アンインストールしたはずでもフィルタが残る | プログラム一覧、サービス、ドライバ | ベンダーの削除ツール、残存コンポーネント除去 |
| インプレースアップグレード由来の整合性問題 | OS 全体が不安定、更新以外でも引っ掛かりがある | CBS.log / Panther / setuperr.log | 修復ソース指定 DISM、最終的にクリーン構築も検討 |
実務上の判断として、インプレースアップグレード環境で更新基盤が深く壊れている場合、復旧に費やす時間が長くなることがあります。ログで「修復不能」「同じパッケージで繰り返し失敗」などが見えてきたら、影響範囲と工数を見積もり、移行（新規構築→データ移行）まで含めて検討した方がトータルで安全なケースもあります。
現場で役立つ運用のコツ：再発を抑えるために
- アップグレード直後は、まず累積更新（最新の更新）まで持ち上げる：更新基盤の不具合が累積更新で改善していることがあるためです。
- 更新の適用は“まとめて一気に”ではなく段階的に：Defender 更新で固まる場合、先に OS 健全化 → WU リセット → 少数の更新適用と刻む方が原因が追いやすいです。
- ログ採取の習慣化：固まった時刻が分かるだけでも解析難度が下がります（「何時ごろ固まったか」をメモしてから再起動）。
- Defender を無効化したまま運用しない：一時対処として外すのはあり得ますが、恒久運用はリスクが高いので、根本原因の解消を優先します。
まとめ：Defender を“完全に消す”前にやるべきこと
Windows Server 2016 Essentials へインプレースアップグレード後に、Windows Update の Windows Defender 更新でサーバーが固まる場合、最初に狙うべきは Defender の痕跡削除ではなく、OS 側の整合性回復とログによる原因特定です。
- SFC/DISM でシステムファイルとコンポーネントストアを修復する
- イベントログ（Application/System/Setup）と CBS.log／Panther ログで“固まる直前”を追う
- 必要なら Windows Update コンポーネント（SoftwareDistribution/catroot2）をリセットする
- それでも改善しない場合のみ、機能として Defender を削除→再追加する
この順番で進めると、無用な“削除作業”で泥沼化するリスクを抑えつつ、再発しにくい状態へ持っていけます。
コメント