Proxmoxバージョンアップ手順 (8.4→9.1)

Proxmoxのサポートポリシーは、メジャーバージョンのリリース後、おおよそ3年となる。

• Frequently Asked Questions

Proxmoxは現在バージョン8と9がサポート期間となっているが、バージョン8については、2026年8月がEOLとなっており、バージョンアップ対応が必要となる。

本記事では、Proxmoxをバージョン8からバージョン9にバージョンアップする手順を記載する。

環境

Proxmoxのバージョンは以下の通り。バージョンアップ作業では再起動が必要であるため、仮想マシンは事前に停止させておくこと。

• バージョンアップ前Proxmox: 8.4.14
• バージョンアップ後Proxmox: 9.1.4

バージョンアップ手順

1. 最新までアップデートを実施

まずは、現在のProxmoxを最新化しておく。

apt update
apt dist-upgrade

2. チェックスクリプトpve8to9実行

バージョンアップの各種チェックを行うスクリプトとしてpve8to9が用意されているのでこちらを実行する。

最後にサマリーが表示されるが、通常はいくつかのWARNINGSとFAILURESが出力される。必ずしもすべて解消しなければならないものではないので、以降の手順で私が遭遇したエラーに対する対応を記載する。

# pve8to9

～(中略)～

= SUMMARY =

TOTAL:    58
PASSED:   38
SKIPPED:  13
WARNINGS: 4
FAILURES: 1

3. (必要な場合) GRUBの設定修正

以下エラーは、「EFI の「リムーバブルメディア用ブートローダー」が存在するが、今後 GRUB の更新対象にならない可能性がある」ことに対する警告となる。

WARN: Removable bootloader found at '/boot/efi/EFI/BOOT/BOOTX64.efi', but GRUB packages not set up to update it!
Run the following command:
echo 'grub-efi-amd64 grub2/force_efi_extra_removable boolean true' | debconf-set-selections -v -u
Then reinstall GRUB with 'apt install --reinstall grub-efi-amd64'

対処としては、メッセージに記載の通りのコマンドを実行して修正するだけでよい。

echo 'grub-efi-amd64 grub2/force_efi_extra_removable boolean true' | debconf-set-selections -v -u
apt install --reinstall grub-efi-amd64

4. (必要な場合) systemd-bootパッケージの削除

以下エラーは、「Proxmox の想定ブートローダー（GRUB）とは別系統の systemd-boot が同居しており、 今後のブートローダー更新や OS アップグレードで問題を起こす構成になっている」ことに対する警告となる。

FAIL: systemd-boot meta-package installed. This will cause problems on upgrades of other boot-related packages. 
Remove 'systemd-boot' See https://pve.proxmox.com/wiki/Upgrade_from_8_to_9#sd-boot-warning for more information.

対処としては、systemd-bootパッケージをアンインストールする。

apt remove systemd-boot

5. リポジトリの修正

Debian 12 (Bookworm)からDebian 13 (Trixie)へリポジトリの変更を行う。

sed -i 's/bookworm/trixie/g' /etc/apt/sources.list
sed -i 's/bookworm/trixie/g' /etc/apt/sources.list.d/pve-enterprise.list

また、Debian 13 (Trixie)用のpve-no-subscriptionリポジトリの追加を行う。

cat > /etc/apt/sources.list.d/proxmox.sources << EOF
Types: deb
URIs: http://download.proxmox.com/debian/pve
Suites: trixie
Components: pve-no-subscription
Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg
EOF

6. チェックスクリプトpve8to9再実行

バージョンアップの直前に再度チェックスクリプトを実行しておく。私の場合は1件WARNINGSを残しているが、バージョンアップ作業には影響がなさそうなので無視して進めることにする。

# pve8to9

～(中略)～

= SUMMARY =

TOTAL:    57
PASSED:   43
SKIPPED:  9
WARNINGS: 1
FAILURES: 0

7. バージョンアップ

バージョンアップを実行する。多数のパッケージダウンロードとインストールが発生するため、完了までは15分程度要した。

apt update
apt dist-upgrade

途中、入力を求められる場面があるため、以下の通り進める。

Configuration file '/etc/issue'

Configuration file '/etc/issue'
 ==> Modified (by you or by a script) since installation.
 ==> Package distributor has shipped an updated version.
   What would you like to do about it ?  Your options are:
    Y or I  : install the package maintainer's version
    N or O  : keep your currently-installed version
      D     : show the differences between the versions
      Z     : start a shell to examine the situation
 The default action is to keep your current version.
*** issue (Y/I/N/O/D/Z) [default=N] ?　★そのままエンター。

Configuring libc6:amd64

There are services installed on your system which need to be restarted 
when certain libraries, such as libpam, libc, and libssl, are upgraded. 
Since these restarts may cause interruptions of service for the system, 
you will normally be prompted on each upgrade for the list of services you wish to restart.  
You can choose this option to avoid being prompted; instead, 
all necessary restarts will be done for you automatically so you can avoid being asked questions on each library upgrade.                                                               
                                                                                                                                            
Restart services during package upgrades without asking?                                                                                    
                                                                                                                                            
<Yes>    <No>
↑★「Yes」を選択。

/usr/share/chrony/chrony.conf

lqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqu Modified configuration file tqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqk
x A new version (/usr/share/chrony/chrony.conf) of configuration file /etc/chrony/chrony.conf is available, but the version installed   x
x currently has been locally modified.                                                                                                  x
x                                                                                                                                       x
x What do you want to do about modified configuration file chrony.conf?                                                                 x
x                                                                                                                                       x
x                                         install the package maintainer's version                                                      x
x                                         keep the local version currently installed                                                    x
x                                         show the differences between the versions                                                     x
x                                         show a side-by-side difference between the versions                                           x
x                                         show a 3-way difference between available versions                                            x
x                                         do a 3-way merge between available versions                                                   x
x                                         start a new shell to examine the situation                                                    x
x                                                                                                                                       x
x                                                                                                                                       x
x                                                                <Ok>                                                                   x
x                                                                                                                                       x
mqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqj

↑★「keep the local version currently installed」を選んでエンター。

Configuration file '/etc/lvm/lvm.conf'

 ==> Modified (by you or by a script) since installation.
 ==> Package distributor has shipped an updated version.
   What would you like to do about it ?  Your options are:
    Y or I  : install the package maintainer's version
    N or O  : keep your currently-installed version
      D     : show the differences between the versions
      Z     : start a shell to examine the situation
 The default action is to keep your current version.
*** lvm.conf (Y/I/N/O/D/Z) [default=N] ? Y　★「Y」を入力しエンター。

8. 再起動

Proxmoxを再起動する。

reboot

9. aptリポジトリのフォーマット最新化

最後にaptのリポジトリ設定を新しいフォーマットに変換するコマンドを実行しておく。

apt modernize-sources

参考

• Upgrade from 8 to 9 - Proxmox VE

Entra JoinしたWindows 11デバイスにEntra IDでリモートデスクトップ接続する手順

Entra Joinで管理しているWindows 11のデバイスは、ローカルアカウントを使えば今まで通りリモートデスクトップ接続することが可能だが、Entra IDでログインする場合は、少し工夫が必要となる。

本記事では、Entra JoinしたWindows 11デバイスにEntra IDでリモートデスクトップ接続する手順を記載する。なお、接続手順は2パターンある。

環境

本環境を構築した際のOSバージョンは以下の通り。Windows 11は仮想マシンで構築している。

• デバイス : Windows 11 24H2　※仮想マシン

手順①：「Webアカウントを使用して、リモートコンピューターにサインインする」のオプションを使う

1. Entra IDのユーザーを「Remote Desktop Users」または「Administrators」グループに所属させる

Entra IDのユーザーはGUIからはローカルのグループに所属させることはできない。したがって、以下のようにnet localgroupコマンドで追加を行う。コマンド実行には管理者権限が必要となる。

PS C:\Users\test> net localgroup "Remote Desktop Users" /add "AzureAD\tuser001@test.com"
コマンドは正常に終了しました。

追加後、念のためGUIでも確認しておこう。「コンピューターの管理 > ローカルユーザーとグループ」を開いてみると、「Entraのドメイン名\ユーザー名」でグループにEntra IDのユーザーが追加されているはずだ。

2. リモートデスクトップ接続の設定を変更

「リモートデスクトップ接続」の「詳細設定」タブにある「Webアカウントを使用して、リモートコンピューターにサインインする」を有効にする。

3. リモートデスクトップ接続実施

Webアカウントによるリモートデスクトップ接続を行い場合は、IPアドレスの接続は許可されずホスト名によるログインが必要となる。

なお、IPアドレスで接続しようとすると、以下のようなエラーで接続に失敗する。

4. ユーザー・パスワード入力

通常のリモートデスクトップ接続とは異なり、よくあるEntra IDでログインする際のユーザー・パスワードの入力画面が表示される。

入力内容に問題なければ、リモートデスクトップ接続に成功し、接続先デバイスのOS画面が表示される。

手順②：CredSSPを無効化する

1. Entra IDのユーザーを「Remote Desktop Users」または「Administrators」グループに所属させる

これは手順①と同じなので割愛する。

2. 接続先デバイスでネットワークレベル認証 (NLA) を無効化

接続先となるWindows 11のデバイスで、「設定 > システム > リモートデスクトップ」より、「デバイスが接続にネットワークレベル認証を使用することを要求する (推奨)」のチェックを外す。これによりネットワークレベル認証 (NLA) を無効化する。

3. リモートデスクトップ接続設定

リモートデスクトップ接続を開き、接続先のコンピューター名 (IPアドレスでも可) とEntra IDのアカウントを入力する。Entra IDのアカウントは「ユーザー名@ドメイン名」の形で入力すること。入力後、「名前を付けて保存」にて*.rdpファイルを保存する。

保存したファイル (*.rdp) のファイルをメモ帳などで開き、enablecredsspsupport:i:0の行を最下行に追記する。

この設定は、「クライアントが認証に資格情報セキュリティ サポート プロバイダー (CredSSP) を使用するかどうかを指定する」設定となり、0を指定することで無効化する。

screen mode id:i:1
use multimon:i:0

～(中略)～

username:s:AzureAD\tuser001@test.com
enablecredsspsupport:i:0　←★追記

4. リモートデスクトップ接続実施

保存したファイル (*.rdp) をダブルクリックし、リモートデスクトップ接続をすると、通常はリモートデスクトップ接続クライアントで聞かれる認証画面ではなく、通常のWindows 11のログイン画面が表示され、ユーザー・パスワード入力ができるようになる。

5. ユーザー・パスワード入力

ユーザー名にはEntra IDのユーザー名を入力するが、「azuread\ユーザー名@ドメイン名」の名前で入力する。「azuread」と入力することでサインイン先がEntra IDとなる。

なお、*.rdpのファイル内で事前に「azuread\ユーザー名@ドメイン名」を入れたユーザー名で設定したとしても、必ず手入力で「azuread」の入力が必要となるので注意すること。

以上で、Entra JoinしたWindows 11デバイスにEntra IDでリモートデスクトップ接続する手順は完了となる。

参考

• Microsoft Entra 参加済みデバイスのローカル管理者グループを管理する方法
• サポートされている RDP プロパティ

Entra JoinしたWindows 11端末をEntra KerberosでファイルサーバーにSSOさせる

Entra Kerberosを設定すると、Entra Joinしている端末からもオンプレADのドメイン上のファイルサーバーにSSOし、ファイルアクセスができるようになる。

本記事では、Entra JoinしたWindows 11端末をEntra KerberosでファイルサーバーにSSOさせる手順を記載する。

環境

本環境を構築した際のOSバージョンは以下の通り。Windows 11は仮想マシンで構築している。

• デバイス : Windows 11 24H2　※仮想マシン

1. Entra Kerberosを構成する

SSOさせるための前提条件として、「①Entra ConnectによるオンプレユーザーをEntra IDへ同期」させ、「②Entra Kerberosを構成」する必要がある。Entra IDで認証した際に、オンプレADの認証に必要な「部分的なTGT」を受け取ることで、オンプレADの認証を処理させるためだ。

Entra Connectの設定手順は、以下URLを参照すること。

• Entra Connectを用いてWindows 11端末をハイブリッド参加させる手順

Entra Kerberosの設定手順は、以下URLの「クラウド信頼とEntra Kerberosについて」を参照すること。

• Windows Hello for Business (WHfB) をクラウド信頼で認証するよう構成する手順

Entra Join手順

1. 設定画面へ遷移

[設定] > [アカウント] > [職場または学校にアクセスする]を選択する。

[職場または学校のアカウントを追加」を選択する。

2. Entra Joinに必要な認証情報の入力

「職場または学校アカウントのセットアップ」では、中央の「電子メールアドレス」のテキストボックスに入力して進めたくなるが、画面下部の[このデバイスをMicrosoft Entra IDに参加させる]のリンクを選んで登録する点に注意しよう。

Microsoftアカウントの認証画面に遷移するので、Entra IDのユーザー・パスワードを入力する。

「これがあなたのネットワークであることを確認してください」では「参加する」を選択する。

完了すると、「<テナント名>のEntra IDに接続しました」と表示される。

Entra管理センターでも、デバイスが「Microsoft Entra joined」と表示される。

以上で、Entra Joinは完了となる。

ファイルサーバーへのSSOでのアクセス確認

オンプレADにドメイン参加したWindows 11に共有フォルダを作成し、これをファイルサーバー相当としてSSOによる接続確認を行う。使用するユーザーと共有フォルダの設定は以下の通り。なお、使用するユーザーは、オンプレAD上に存在するユーザーをEntra Connectで同期しておく必要がある。

• 使用するユーザー : tuser002
• 共有タブ : tuser002のみフルコントロール
• セキュリティタブ : tuser002のみフルコントロール

まず、ローカルアカウントでデバイスにログインしたのち、共有フォルダにアクセスする。当然「アクセスできません」のエラーとなる。

次に、フルコントロールを許可している「tuser002」のアカウントにてログインし、共有フォルダにアクセスする。今度は、エラーとならず共有フォルダにアクセスに成功できた。

以上で、Entra JoinしたWindows 11端末をEntra KerberosでファイルサーバーにSSOさせることの設定手順と確認は完了となる。