Windows 10の機能更新プログラム、またはインストールメディアによる新バージョンへのアップグレードで、「バージョンのロールバック」による解決が必要な問題が立て続けに明らかになりました。それらの問題は、実はWindows Serverにも影響します。しかし、ほとんど問題になることはないでしょう。なぜなら……。
この記事は会員限定です。会員登録(無料)すると全てご覧いただけます。
「Windows 10 バージョン20H2(October 2020 Update)」が正式にリリースされてから1カ月もたたないうちに、Windows 10の新バージョンへのアップグレードに関して、複数の問題が明らかになり、一部の問題についてはセーフガードホールドの対象としてWindows Updateによる自動配布が一時停止される措置が講じられました(注:「ダウンロードしてインストール」による手動更新はブロックされないようです)。詳しくは、筆者の別連載で解説しています。
Windows 10の新バージョンがリリースされると、同じタイミングでそのバージョンと同じコードベースのWindows Serverもリリースされます。それは、Windows 10と同じ「半期チャネル(Semi-Annual Channel、SAC)」のWindows Serverのことです。
このServer Coreベース(「デスクトップエクスペリエンス」は含みません)のサーバOSは、有効なソフトウェアアシュアランス(SA)付きのボリュームライセンス契約を通じて提供されるものです。
そして、Windows 10に存在する既知の問題の多くは、同じOSビルドのWindows Serverにも影響します。最近、Windows 10 バージョン2004とバージョン20H2で明らかになった新バージョンへのアップグレードに関する以下の2つの問題は、Windows Server SACのバージョン2004とバージョン20H2にも影響すると説明されています。
「Windows Server, version 2004」をインストールした仮想マシンで影響を受ける環境を構築して、ISOイメージから「Windows Server, version 20H2」にアップグレードしたところ、Windows 10と同じ問題が再現しました。
1つ目の問題はビルトインアカウントの名前を変更していると、アップグレード後に「ローカルユーザーとグループ」スナップイン(lusrmgr.msc)などの使用でエラーが発生し、1分以内に自動的に再起動してしまうというものです(画面1)。
Server CoreベースのWindows Server SACはGUI(グラフィカルユーザーインタフェース)を搭載していませんが、「Server Core アプリ互換性オンデマンド機能」をインストールすることで、「ローカルユーザーとグループ」スナップイン(lusrmgr.msc)を含む一部のGUIツールが利用可能になります。
Windows 10とは異なり、サーバOSではビルトインAdministratorアカウントは“既定で有効”であり、セキュリティ対策として想像しにくい名前に変更するということは決して珍しいことではありません。この問題の影響を受けてしまった場合、ビルトインアカウントの名前を元に戻すこともできなくなります。
2つ目の問題は、アップグレード時にセットアップ関連の最新の更新プログラムを利用できない場合、または今後提供予定の2020年10月の累積更新プログラムが統合された更新されたインストールメディアを使用しない場合、Windows 10 バージョン1809とWindows Server, version 1809以降で、2020年9月以降の累積更新プログラムがインストールされている環境を、新しいバージョンのインストールメディアを使用してアップグレードすると、「ローカルコンピューター」や「ユーザーの証明書」が失われてしまうというものです。
問題が再現する要件は複雑ですが、サーバが提供するアプリやサービス、セキュリティ、管理機能の多くは証明書に依存します。この問題の影響を受けた場合、被害は甚大になる可能性があります。
再現テストでは、Windows Server, version 2004を実行する仮想マシンに「インターネットインフォメーションサービス(IIS)」の「Webサーバー」と「管理サービス」をインストールして構成し、外部の「IISマネージャー」からのリモート管理を有効化して「Default Web Site」へのHTTPSのバインドを行いました。
この仮想マシンをネットワークから切断し、ISOイメージを使用してWindows Server, version 20H2にアップグレードしたところ、「ローカルコンピューター(LocalMachine)」の「個人(My)」ストアにあった自己署名証明書は失われ、それを使用する管理サービスとWebサイトのHTTPSバインドは機能しなくなりました(画面2)。
1つ目の問題については現在、Windows 10 バージョン2004とバージョン20H2の機能更新プログラムを対象に、セーフガードホールドの措置が講じられており、問題が解決されるまで、影響を受けるPC(ビルトインアカウントの名前を変更しているPC)にはWindows Updateを通じて自動配布されることはありません(注:「ダウンロードしてインストール」のクリックによる手動更新はブロックされません)。
Windows Server SACには、Windows 10のように機能更新プログラムが提供されることはありません。つまり、Windows Updateを通じて新バージョンが提供されることはありません。しかしながら、Windows Updateにアクセス可能な状態でインストールメディア(ISOイメージなど)からアップグレードインストールを試みると、セーフガードホールドの対象であると判断されると、アップグレードをブロックしてくれます。
以下の画面3は、ローカルAdministratorアカウントの名前を「MyAdmin」に変更してから、アップグレードを試みたところです。「詳細情報」をクリックして表示されるサイトリンクは、この問題について説明する以下のサポート情報を示しています。
2つ目の証明書消失問題は、セーフガードホールドの対象ではありません。現在はアップグレードの実行時、セットアップ関連の最新の更新プログラムがダウンロードされることで問題は回避されます。また、今後、提供される更新されたインストールメディア(2020年10月の累積更新プログラム以降が統合されたインストールメディア)を使用することでも問題は回避されます。
“アップグレード開始時にWindows Updateにアクセス可能な状態であること”が、問題の回避に重要なわけですが、残念なことに、サーバが稼働するネットワーク環境がそれを許さないクローズドな環境の場合があるということです。Windows Updateにアクセスできない環境でアップグレードを実行すると、セーフガードホールドにブロックされることなく、アップグレードを続行できてしまいます(画面4)。
Windows 10ではこれらの問題の影響を受けた場合、10日以内に「設定」アプリの「更新とセキュリティ」にある「回復」から「前のバージョンのWindows 10に戻す」を実行して、簡単に(時間はかかりますが)バージョンをロールバックできます。
しかし、もう一つ残念なことに、Windows Serverはそのようなロールバック機能を備えていません。アップグレード前にサーバのシステムイメージのバックアップを取得してあれば、バックアップから復旧できますが、バックアップがない場合は、最悪、システムを再構築しなければならないかもしれません。
証明書消失問題は、証明書の再発行と再設定で何とかなるかもしれませんが、ビルトインアカウントの名前変更に起因する問題を解決するにはバックアップから復元するか、システムの再構築しかなさそうです。Microsoftが示す回避策は現状、影響を受ける可能性がある場合はアップグレードしないこと、アップグレードして影響を受けた場合はロールバックすることしかありません。
幸いなのは、半期チャネル(SAC)のWindows Serverにも影響するこの問題が、企業のIT環境の現場で大きな問題にはならないだろうということです。半年ごとに新バージョンがリリースされ、18カ月以内に新バージョンにアップグレードする必要がある(18カ月のサポート終了後、セキュリティ更新プログラムが提供されなくなるため)サーバOSを企業のインフラストラクチャサーバとして採用しているところは果たして存在するでしょうか。
長期稼働や安定性が求められるWindowsベースのインフラストラクチャサーバのOSとしては、「長期サービスチャネル(Long Term Servicing Channel、LTSC)」で10年の長期サポートが提供される「Windows Server 2016」や「Windows Server 2019」を採用するのが、まず間違いのない選択です。
Windows Server SACの価値、あるいは存在意義は、使い捨てアプリケーションのプラットフォームとしての利用にあると思います。つまり、仮想マシンやコンテナ(Windowsコンテナ)の技術を利用して、素早くアプリケーション実行環境を展開する際の、部品としてのOSレイヤーを提供するためのものです。使い捨てとは、展開済みの実行環境に対してOSの更新やアップグレードは行わず、その都度、新たに作り直して入れ替えるという、クラウド的な利用方法です。OSの更新やアップグレードを行わないなら、更新やアップグレードに付随する問題からも解放されるでしょう。
しかし現実問題として、多くの企業ユーザーはWindows Server LTSCを採用しています。特に、日本市場では、Windows Server SACを利用しているユーザーは皆無に近いのではないでしょうか(あくまで筆者の感想です)。実は、Windows Server, version 1903以降、最新のWindows Server, version 20H2まで、「Microsoft IME」による日本語の入力変換が全く機能しないという問題があるのですが、Server Core環境での日本語入力にニーズがあるかどうかは別として、それを問題視している声を全く聞かないからです。
Microsoftは「Microsoft Azure」のサービスと機能を、オンプレミスで利用可能にする「Azure Stack」というハイブリッドクラウドプラットフォーム製品を開発中です。その中核的なサーバOSとなる「Azure Stack HCI」は、プレビュー版をインストールしての印象としては、Windows Server SACと同様のServer Coreベースのものでした。この製品が一般提供となれば、Windows Server SACの存在意義がまた違ってくるかもしれません(画面5)。
自動化された方法で、インフラストラクチャを構成するクラスタノードを、ダウンタイムなしで最新状態に維持できるようになれば、18カ月という短いライフサイクルが問題になることはなくなり、常に最新のインフラストラクチャを利用可能になるだろうからです。
岩手県花巻市在住。Microsoft MVP:Cloud and Datacenter Management(2020-2021)。SIer、IT出版社、中堅企業のシステム管理者を経て、フリーのテクニカルライターに。Microsoft製品、テクノロジーを中心に、IT雑誌、Webサイトへの記事の寄稿、ドキュメント作成、事例取材などを手掛ける。個人ブログは『山市良のえぬなんとかわーるど』。近著は『Windows版Docker&Windowsコンテナーテクノロジ入門』(日経BP社)、『ITプロフェッショナル向けWindowsトラブル解決 コマンド&テクニック集』(日経BP社)。
Copyright © ITmedia, Inc. All Rights Reserved.