Windows Server 2016の今後の“更新”が怖い：山市良のうぃんどうず日記（98）（1/2 ページ）

テスト環境として構築したWindows Server 2016の物理サーバと仮想マシン。その一部でWindows Updateやシャットダウンに異様に時間がかかるといった現象に遭遇しました。そんな中、Windows Serverの次期バージョンに関する新方針の発表もあって、いろいろな面で“更新”に対する不安が高まっています（筆者の個人的な感想）。

[山市良，テクニカルライター]

2017年6月の更新は95％で止まった（ように見えた）

　筆者がテスト環境用に構築した物理サーバ、Hyper-V仮想マシン、Azure仮想マシンでは、前回、前々回で取り上げたように、2017年5月のWindows Updateで異様に長い時間がかかるという現象に悩まされました。いずれも、Windows Server 2016の「デスクトップエクスペリエンス」がインストールされており、問題の原因になりそうな共通した条件は発見できていません。前回は「更新プログラムをダウンロードしています 21％」で止まったように見え、次の「22％」になるのに1時間20分という異様に長い時間がかかりました。

• Windows UpdateとIaaSクラウドは忍耐が試される？（本連載 第96回）
• 進まないWindows Update、やっぱり止まっていなかった（本連載 第97回）

　2017年6月の更新では、1台の物理サーバと1台のAzure仮想マシンで同様の問題に遭遇しました。今度は「更新プログラムをダウンロードしています 95％」で1時間以上（計測していません）止まったように見えました（画面1）。

画面1　Windows Server 2016の2017年6月のWindows Updateは、ダウンロード95％で止まったように見える現象に遭遇。一方で、すんなり更新できたサーバもある

　物理サーバの方は、更新に関係なく別の検証を行う予定でしたので、後日更新しようと思い「更新プログラムをダウンロードしています 95％」の状態でシャットダウンを開始しました。すると、「Windows の準備をしています コンピューターの電源を切らないでください」のまま一向にシャットダウンが進まない状態になりました。1時間以上経過しても、点々の丸いインジケーターも表示されないまま何も変化がありません（画面2）。

画面2　ダウンロード95％の状態でシャットダウンしたら、シャットダウンが進まない状態に遭遇。電源のリセットで対応し、その後の更新は一晩放置して完了

　仕方がないので、電源をリセットして再起動しました。別件の用事を済ませた後、Windows Updateを再実行しましたが、やはり異様に長い時間がかかります。一晩放置して、ようやく累積的な更新プログラム「KB4022715」（ビルド14393.1358への更新）のインストールが完了し、その後、累積的な更新プログラムと同時に検出されながら、更新のための再起動時にはインストールされなかった残りの更新プログラム、Windows Server 2016の重要な更新プログラム「KB4023834」と、.NET Framework 4.7への更新プログラム「KB3186568」がインストールされました。

　Azure仮想マシンの方は、2017年5月にAzure Marketplaceからデプロイしたばかりの比較的新しいインストールです。日本語言語パックと5月の更新をインストールしただけの状態で、「更新プログラムをダウンロードしています 95％」問題に遭遇しました。前回検証したように、そのまま待てばいつかは更新が完了するはずなのですが、更新のために実行時間が延び、クレジットが消費されるのは避けたかったので、「C:\Windows\SoftwareDistribution」をクリア（本連載 第96回で説明した「Windows Update正常化テク」のステップ3）する方法で半ば強引に問題を解消しました。

新しいWindows Updateには、何か根本的な問題があるのでは？

　更新に異様に長い時間がかかる、シャットダウンに異様に長い時間がかかるという現象は、特別な構成のサーバで発生しているわけではありません。共通の条件が見当たらないため、スペック的な問題とも思えません。Windows 10で刷新され、Windows Server 2016にも実装された新しいWindows Updateには、何か根本的な問題があるのではと疑いたくなります。

　シャットダウンに異様に長い時間がかかるという現象には、Windows Updateの実行中でなくても遭遇することが何度かありました。もしかすると、Windows Updateの処理がバックグラウンドで動いていたかもしれません。

　ここ最近、割り当て解除状態のAzure仮想マシンを開始すると、ログオン時に「シャットダウンイベントの追跡ツール」がポップアップすることが何度かありました（画面3）。

画面3　Windows Server 2016のAzure仮想マシンを割り当て解除状態から開始すると、「シャットダウンイベントの追跡ツール」が表示される。割り当て解除時のシャットダウンが正常に完了していなかったことを示している

　「シャットダウンイベントの追跡ツール」は、前回のシャットダウンが正常に行われなかった場合に表示されます。Azure仮想マシンを停止する場合、停止中の課金を避けるためには、仮想マシンのゲストOSからシャットダウンするのではなく、Azureポータルからシャットダウンを開始して、「停止（割り当て解除）」「Stopped（deallocated）」にするのですが、どうやらシャットダウンに時間がかかり、Azure側のタイムアウトで強制的にオフにされているようなのです。

　この現象は、Windows Server 2012 R2以前を実行するAzure仮想マシンでは遭遇したことはありません（筆者が経験した限り）。Windows Server 2016を実行するAzure仮想マシンで、ここ最近になって遭遇する機会が増えたような気がします。正常にシャットダウンされないとOSディスクが破損してしまうかもしれないので、今後はAzure仮想マシンのゲストOS側からシャットダウンを開始し、停止したことを確認してから、無駄な課金を避けるためにAzureポータルから「停止（割り当て解除）」するようにしようと考えています。