WSL／WSL 2開発担当者は「Server Core」が眼中にないらしい――WSLの正しいインストール手順は存在するのか？：山市良のうぃんどうず日記（260）

以前取り上げたように、それまでWindows 10／11でのみ利用可能だった「WSL 2」が、2022年6月の累積更新プログラム（Bリリース）でWindows Server 2022でもサポートされるようになりました。ただし、それは「デスクトップエクスペリエンス」という限定付きでした。その後の状況を再確認してみました。

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

山市良のうぃんどうず日記

Windows Server 2022へのWSL 2のインストールがもっと簡単になっていました

　本連載第234回では「Windows Server 2022」向けの「2022年6月の累積更新プログラム（Bリリース）」で、本物のLinuxカーネルで動く「Windows Subsystem for Linux 2（WSL2）」がサポートされたことを取り上げました。Windows Server 2022では、それ以前は従来のエミュレーション環境「WSL 1」（または単に「WSL」）のみを利用できました。

• 【朗報】ついにWindows Server 2022で「WSL 2」が動くようになったよ！――インストール方法を詳細解説（本連載 第234回）

　Windows Server 2022でWSL 2が利用できるようになったばかりの当時は、公式ドキュメントが整備されておらず、筆者が試行錯誤して独自のインストール手順を紹介しました。現在はドキュメントも出そろいました（ただし、後述するように以前のWindows Server向けの記述は不正確な部分があります）。

• Windows Server インストール ガイド（Microsoft Learn）

　Windows Server 2022では、WSL 2対応の「Windows 10」や「Windows 11」と同様に、「wsl.exe」コマンドによる簡単インストール機能を利用できます。また、以前は既定がWSL 1だったのに対して、現在はWSL 2が既定に変更されています。そのため、Windows Server 2022へのWSL 2のインストールはさらに簡単になっています。

　手動によるWSLの機能有効化は不要であり、例えば、Linuxディストリビューションとして既定の「Ubuntu」を利用する場合は、PowerShellまたはコマンドプロンプトで以下の1行のコマンドラインを実行するだけでインストールを開始できます。インストール後の再起動と、再起動後のLinuxディストリビューションのインストール時にユーザー名とパスワードを設定すれば、それだけで利用可能になります。

wsl --install

　また、Windows 11からWSL 2のLinux環境で利用可能になったGUIアプリの対応機能「WSLg」の最小要件が以前は「ビルド22000」でしたが、現在は「ビルド19044」以降となり、Windows 10 バージョン21H2（ビルド19044）／バージョン22H2（ビルド19045）やWindows Server 2022、Windows 10 バージョン21H2（ビルド20348）でも利用可能になっています（画面1）。

画面1　Windows Server 2022上のWSL 2で動いている「Kali Linux」のシェルと、LinuxのGUIアプリ（xeyes、xclock）

　上記画面1の環境までを新規構築する場合は、Windows Server 2022の「デスクトップエクスペリエンス」をインストールし、Windows Updateを実行して、最新の更新プログラムを全てインストールしたら（注：Windows Server 2022の初期のセットアップメディアは、WSL 2非対応のビルドです）、コマンドプロンプトまたはPowerShellウィンドウで次のコマンドラインを順番に実行するだけで終わります（画面2）。

wsl --install -d kali-linux
shutdown /r /t 0

　再起動後は、Linuxディストリビューションのダウンロードとインストールが自動的に再開し、UNIXユーザー名とパスワードを設定してインストールが完了します。その後、お好みのGUIアプリ（x11-appsなど）をインストールして実行します。

sudo apt update
sudo apt install x11-apps -y
xclock &
xeye &

画面2　「Kali Linux」をWSL 2のLinuxディストリビューションとしてインストールする

最新Server Core環境ではWSL 1もWSL 2も動かない

　Windows Server 2022のWSL 2でLinuxのGUIアプリが実行できることが分かり、「Server Core」インストール環境で同様にGUIアプリが動くと面白いなぁと思い、以前はできなかったWindows Server 2022 Server Core環境へのWSL 2のインストールに再挑戦してみました。

　話は少しそれますが、実は、Server Core環境でWSL 2が動いたとしても、GUIアプリには対応できないと予想していました。WSLgは、技術的には、実行中のLinuxカーネル上の「X11」と「Wayland」のローカルコンソールへのリモートデスクトップ接続（Hyper-VのLinux仮想マシンへの「拡張セッション」接続と似ています）であり、クライアントになる「msrdc.exe」（C:\Program Files\WindowsApps\MicrosoftCorporationII.WindowsSubsystemForLinux……）はユニバーサルWindowsプラットフォーム（UWP）アプリ、つまりストアアプリなのでServer Core環境ではクライアント（msrdc.exe）を利用できない（存在しない）と簡単に想像できます。

　さて、最新ビルドに更新したServer Core環境で、wslコマンドを実行してみると、何も起きません。ヘルプさえ見えません。イベントログを確認すると（「Windows Admin Center」を使用）、「wsl.exe」で障害が発生していることが記録されています（画面3）。

画面3　Windows Server 2022 Server Coreの最新ビルド（2023年5月Bリリース）環境では、wsl.exeを実行してもクラッシュを繰り返すだけで、インストールも何もできない

　実は、2022年6月のWSL 2対応以前のビルドまでは、Server Core環境でWSL 1上でLinuxディストリビューションを実行できました（デスクトップエクスペリエンスも同様）。

　「wsl --install」コマンドによるWSLのインストールは可能で、既定のLinuxディストリビューションであるUbuntuのダウンロードとインストールはエラーで失敗しますが、後述する「Windows Server 2019」のWSL 1上へのLinuxディストリビューションのインストール方法（Add-AppxPackageを使用しない方法）を使えば、筆者が確認した限り、Ubuntu 16.04とUbuntu 18.04をインストールして動かすことができました（画面4、画面5）。

　このWSL 1でLinuxディストリビューションが動いている環境を、最新ビルドに更新するとどうなるでしょうか。新規にインストールしようとした場合と同様に、起動しようとしても「wsl.exe」がクラッシュするようになり、WSLはバージョンに関係なく、利用できなくなりました。

画面4　Windows Server 2019のRTMビルド（20348.169）では、Linuxディストリビューションのインストールはエラーで失敗するものの、「wsl --install」は機能していた

画面5　Add-AppxPackageを使用しない方法を使えば、Ubuntu 16.04やUbuntu 18.04を動かすことができた

　本連載第234回でも指摘しましたが、WSL 2がWindows 10 バージョン2004（ビルド19041）に初めて実装されたとき、当時は存在した「Windows Server半期チャネル（SAC）」のバージョン2004（Server Coreインストールのみ）でもWSL 2が同時に利用可能になりました。それが、Windows Server 2022のServer Coreでは、RTM直後はWSL 1のみを利用できるように、そして現在は、とうとうWSLを全く利用できない状況になってしまいました。

Windows Server 2019でWSL 1をインストールして動かす正しい手順

　このおかしな状況は、WSL 2という同じ機能を、ライフサイクルの短いWindows 10やWindows 11と、今はもう「長期サービスチャネル（LTSC）」のみとなったWindows Serverの両方に対応させようとしことで生じた意図しない（考えていなかった）状況のようにも見えます。

　Windows Server 2019は、WSL 2には対応していませんが、従来のWSL 1には対応しています。しかし、公式ドキュメントの「Windows Serverへのインストール」の「以前のバージョンのWindows ServerにWSLをインストールする」（Microsoft Learn）の手順には、ダウンロードしたパッケージファイル「app_name.appx」の拡張子を「.zip」にリネームし、その後、もうないはずの「app_name.appx」を「Add-AppxPaackage」コマンドレットでインストールするという不可能ごとが書いてあります（画面6）。オリジナルの英語ドキュメントにもそう書いてあります。

画面6　「app_name.appx」を「app_name.zip」にリネームしたので、もう「app_name.appx」は存在しない

　Windows Server 2019デスクトップエクスペリエンスのPowerShellウィンドウで次のコマンドラインを実行すると、Ubuntu 18.04をインストールすることができます。

Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux
shutdown /r /t 0
curl.exe -L -o wsl-ubuntu-1804.appx https://aka.ms/wsl-ubuntu-1804
Add-AppxPackage .\wsl-ubuntu-1804.appx

　Add-AppxPackageコマンドレットの実行が完了すると、スタートメニューに「Ubuntu 18.04 LTS」のアイコンが追加されるので、それをクリックするとLinuxディストリビューションのインストールが始まります（画面7）。

画面7　Windows Server 2019には、ダウンロードしたパッケージ（.appx、.appxBoundle、.msixBoundle）をAdd-AppxPackageコマンドレットでインストールする

　他のLinuxディストリビューションのパッケージ（拡張子「.appx」または「.appxBoundle」または「.msixbundle」、ダウンロードリンクはhttps://learn.microsoft.com/ja-jp/windows/wsl/install-manual#downloading-distributions）も同じ方法でインストールできるはずです。なお、PowerShellウィンドウで「curl」を使用する際には、必ず「curl.exe」と完全なファイル名で入力してください。「curl」と入力すると、Invoke-WebRequestのエイリアスとして認識されてしまいます。

　Windows Server 2019のServer Core環境は、この方法ではインストールに失敗すると思います。Server Core環境の場合は、Add-AppxPackageコマンドレットを使用せずにインストールする方法を利用します。

　それには、以下のように「.appx」の拡張子を「.zip」にリネームし、Expand-Archiveコマンドレットで展開したら、そのディレクトリに移動し、ランチャーである実行可能ファイル（.exe）を実行します（画面8）。ランチャーは初回実行時にインストールを開始し、その後、Linuxシェルが開きます。次回実行時はランチャーを実行することで、Linuxシェルを開始できます。

Rename-Item .\wsl-ubuntu-1804.appx .\wsl-ubuntu-1804.zip
Expand-Archive .\wsl-ubuntu-1804.zip
cd wsl-ubuntu-1804
dir *.exe
.\ubuntu1804.exe

画面8　拡張子「.appx」のパッケージのみ、「.zip」にリネームして展開し、ランチャー（.exe）を実行することでインストールを開始できる

　この方法でインストールできるのは、ダウンロードファイルの拡張子が「.appx」だけのようです。具体的には、Ubuntu 16.04／Ubuntu 18.04と「SUSE Linux」の各バージョン、「openSUSE」の各バージョン、「Oracle Linux」の各バージョンです。Ubuntuの他のバージョン、「Debian GNU/Linux」「Kali Linux」（いずれも拡張子「.appxBoundle」）、「Fedora Linux」（拡張子「.msixbundle」）は、ランチャーとなる実行可能ファイルを含まないため、この方法ではインストールできません。

　Server Core環境でのWSL 1およびLinuxディストリビューションのインストール方法は、WSL 1が登場した初期のドキュメントにはちゃんと書いてあったと記憶しています。現在の公式ドキュメントの誤った記述は、デスクトップエクスペリエンスとServer Core環境へのインストール手順が中途半端に混在し、あり得ない手順（リネームして存在しないはずのファイル名の指定）になってしまっているのだと思います。

筆者紹介

山市 良（やまいち りょう）

岩手県花巻市在住。Microsoft MVP 2008 to 2023（Cloud and Datacenter Management）。SIer、IT出版社、中堅企業のシステム管理者を経て、フリーのテクニカルライターに。Microsoft製品、テクノロジーを中心に、IT雑誌、Webサイトへの記事の寄稿、ドキュメント作成、事例取材などを手掛ける。個人ブログは『山市良のえぬなんとかわーるど』。近著は『Windows版Docker＆Windowsコンテナーテクノロジ入門』（日経BP社）、『ITプロフェッショナル向けWindowsトラブル解決 コマンド＆テクニック集』（日経BP社）。