以前から社内の Windows Server 2012R2の Windows Update が、やってもやっても最新状態にならずもうかれこれ数ヶ月、さすがになんとかしようと調べてみました。症状と対策はサーバOSに限らず、 Windows 10などのクライアントOSでも当てはまる事例のはずです。対象のサーバの概要は次の通り、ごく普通の仮想サーバです。
- Windows Server 2012R2
- VMware ESXi上の仮想マシン
- ADのセカンダリDC （プライマリも同症状）
早速Windows Updateを開いてみると、既にいくつかの更新が適用を控えています。
図01.Windows Update
もちろん普段はアップデートを見つけると適用し、夜間再起動をスケジューリングしてメンテを終えています。しかし翌日の確認を怠っていた為に、実は更新が全く適用されずにPendingのまま過ぎていたのです。ここで手動で何十回と再起動やシャットダウンによるコールドスタートも試すも、最新状態になることはありません。更新履歴を見ると案の定、Pendingの山でした。
図02.Update History Pending Restart Entries
同じ更新が何度も再起動待ちになっていて、画像にはその日の分しか写っていませんが、 実はこれが何ヶ月分もつづいています。
1. dism.exeとsfc.exeを使った試み【失敗】
まずはこちらの記事に沿って、dism.exeを使った解決を試みます。このツール、以前にも使ったことがあるのですが、あまり覚えていないので、当時も解決出来なかったんだと思います。
次のコマンドでパッケージ情報を取得しますが、全てInstalledでした。
|
1 |
dism /online /get-packages |
続いて、いくつかチェックのためのオプションを試してみますが、/restorehealthのエラーは解消せず。sfc.exeでも回復不能エラーを検出して手詰まり。
図03.dism.exe実行の様子
図04.sfc.exe実行の様子
正直、今回に限らずこれらのツールで何か解決出来たことが今まで無いので、本方法についてはここまでとしました。
2. Reset Windows Update Toolを使った試み【やや改善】
次に、Windows Updateのコンポーネントをリセットする、と言うアプローチで解決を試みようと思います。こちらのMicrosoft謹製ページにその方法が詳しく解説されているのですが、ステップが多いのでツール化されているのを有り難く使わせていただきます、Great Tnx!!
ダウンロード、解凍の後ResetWUEng.cmdを実行すると、約款同意の後、次のようなメニュー画面になります。
図05.Reset Windows Update Tool メニュー画面
メニュー中の「2. Reset the Windows Update Components」を実行し、小一時間放置しておくと無事に完走していました。
図06. Reset the Windows Update Components実行完了
他にもこのツールでは、dism.exeやsfc.exeを使ったチェックやクリーニング、さらに踏み込んでWinsockのリセットなども出来、今回は2, 4, 7, 8, 9, 10番まで実行させてみました。尚、dism.exeを使う項目のうち、7番はスキャンのみなのに対し、9番はスキャンに加えて必要であれば修復を試みる仕様になっているので、7番は不要かもしれません。
ここで気付いたのですが、2を実行させると%windir%\SoftwareDistributionフォルダを綺麗にする際に、既存フォルダが.bak付きで残されます。最終的に問題無ければ消してしまった方が良いでしょう。
図07.残された既存SoftwareDIstributionフォルダ
リセットさせたことで、Windows Updateの履歴もこの通り空っぽです。
図08.Update History Empty
Check for updatesしてみると、未適用な直近の更新が検出されるので適用、再起動と進めますが、ここでまたPending Restartが出現。これは何度か再起動させても解消されませんでした。
このツールを使ってリセットすることで、残る問題が顕在化されましたが、これを解決するには至りませんでした。
3. Windows Module Installerサービスの起動やセーフモードの試み【有効】
こちらの記事によると、セーフモードで一度起動させることで、Pending Restartから抜け出し、更新が適用されるのだそうです。
クライアントOS同様、サーバOSでも以前と異なり起動時にセーフモードを選んだりするブートメニューが表示されなくなりました。表示させる方法はいくつかあるのですが、設定を変えずに実現するには、SettingsでPowerやその次のUpdate and restart（もしくは単にRestart）をShiftキー押しながらクリックします。
図09.Settings – Powerクリック
続いて表示される青い設定画面では、下図の要領で進めて次回起動時の設定を有効にします。
図10.Startup Settings遷移
すると再起動となり、見慣れたブートオプション選択画面が現れます。Safe Modeで起動しましょう。
図11.Advanced Boot Optionsメニュー
セーフモードでは特に何もすることはありません。「セーフモードで起動した」という事実を作ることで、Pending Restartのループから抜け出すのが狙いです。起動完了したのを見計らって、今度は通常モードで再起動させます。
さて、先の記事にセーフモード起動と併記して、Windows Modules Installerサービスを起動させると言う方策も挙げられています。
デフォルトでは手動起動で普段は停止ているこのサービスをあえて、自動起動且つ開始させてから再起動させると、その過程でPengingされていた項目が適用されると言うものです。
図12.Windows Modules Installer サービス
早速これも設定して再起動させてみると、再起動中明らかに時間が掛かっていて、いかにも「パッチ適用しています！」を感じさせてくれます。再起動が済み、Windows Updateを開いてみると、遂に最新状態であることが確認されました。
図13.No Updates are Available
更新履歴も全て成功していて清々しい思いです。
図14.Update History Succeeded
4. 再起動時にWindows Module Installerサービスを有効かつ開始しておく【結論】
Windows Updateのトラブルは解消したわけですが、上の項目に於けるセーフモードとWindows Modules Installerサービスのどちらが果たして有意であったのか、それを検証してみたいと思います。
幸いもう一台、プライマリDCを司っている仮想マシンも全く同じ症状なことから、ここからはこの仮想マシン上で作業を進めます。
まずWindows Modules Installerサービスを自動起動にするのみで再起動したところ、当該サービスがバックグラウンドで高負荷で動き続け、Windows Updateのウィンドウすら開かない状態になってしまいました。
図15.WMI High CPU Load
そのまま放置していると勝手に再起動となり、長い更新作業の後、Windows Updateの更新履歴を確認すると、過去のエントリは全てSuccessかFailとなり、Pending Restartは解消しました。
図16.Update History Succeeded & Failed Only
その後、残る今月分の更新も問題無く適用されることを確認出来たので、このサービスが有意であることが判りました。
今後の対応として、Windows Module Installerを自動起動かつ開始してから再起動するスケジュールタスクを作り、必要な時にワンタイムで使えるようにします。コマンドラインでこのサービスを扱うためのサービス名を以下のコマンドから割り出します。
|
1 |
sc.exe queryex type=service state=all | find /i "SERVICE_NAME:" |
サービスの自動起動と開始は次のコマンドです。尚、sc.exeコマンドのオプション表記は、イコール後方の半角スペースが必須であることに注意します。
|
1 2 |
sc.exe config TrustedInstaller start= auto net.exe start TrustedInstaller |
実際にこのようにタスク登録しておきました。
図17.WMIサービス有効化してから再起動するタスクを作成
参考とGreat Tnx!）
