最後に Azure Virtual Desktop （旧称: Windows Virtual Desktop)の記事を書いたのは2021年の6月。9か月振りに記事を書く。 この間に呼び名も Azure Virtual Desktop に変わり、また、Windows 365 なども登場。 ブログを書く習慣がすっかり抜けきってしまっているが少しづつ書く習慣、アウトプットする習慣を取り戻したい。
9か月も記事を書いていないと何を書いたら良いか困ってしまうのですが、とりあえず思いつくままに既存のWindows 10 のセッションホストを Windows 11へアップグレードしてみることにします。 事前に Microsoft Docs などは確認せずトラブルが起きること前提（トラブル起きた方が自分のためにも世のためにもなる）で進めてみます。
まずは リモートデスクトップクライアントを起動します。 バージョンは最新の 1.2.2927.0。 セッションホストにサインインします。
セッションホストのサインインが完了。 Windows のバージョンは 21H1 です。 これを Windows 11 にアップグレードしていきます。
Windows 11 へのアップグレードですが、やり方を調べていません。 とりあえず Microsoft Update の画面を調べてみることにします。
最後に修正プログラムを適用したのは2か月前の1月中旬です。修正プログラムがたまっています。 Windows 11 にアップグレードする前にまずは 21H1 として最新化することにします。
2vCPUかつバーストタイプの Virtual Machine ですが、CPUリソースを使いきっています。 Windows の修正プログラム適用は常にこんなものですが。
待っていても暇なのでリソースの状況を見る。CPUは御覧の通り 100% に近い状況。
ディスクではキューに着目し、IOの待ちは無さげな状況。 となると単純に修正プログラムの処理はCPUがほとんどということがわかります。 ちなみにStandard SSD なのでそこまで性能が高いディスクではありません。
と書いているうちにディスクのキューは1~5になっています。 物理ディスクとRAIDカードの時は物理ディスクの本数も考慮してキューに待ちがあるのかないのか計算したのですが、Azure の仮想ディスクではどう考えればよいのだろうか。 Storage を1つとみなして1以上は待ちがあると捉えてよいのか。 まあ、待ちがあるかどうかよりも Latency が見れればそこで20msを常時超えてくるようであればディスクの性能不足と判断したりもしますがその情報が確認できず。
タスクマネージャのパフォーマンスにディスクカテゴリがあってそこにスループットやLatencyが表示されるはずなのですが出てこない。 21H1 の仕様なのか。
そんなこんなしている間にOSの再起動を求められたので再起動する。
Windows の修正プログラムを適用する中での再起動やシャットダウンは通常よりも時間がかかることがよくあります。5分や10分など。 いつまでたっても接続出来ず心配になった時は Azure Portal からブート診断を確認します。
以下のように”Windows の準備をしています。コンピュータの電源を切らないでください”と修正プログラムの適用に関する処理の途中であることを確認できます。
あとはメトリックから CPU の使用率なんかで稼働状況を確認するのもありです。
結局再起動に30分かかりました。 修正プログラムの適用でこの調子では Windows 10 から 11へは何時間かかるかわかりません。 仮想マシンをスペックアップすることにします。
もともと 2 vCPU、 8 GB メモリでしたが 8 vCPU 、32 GB メモリにスペックアップ。 これで修正プログラム適用も Windows 11 へのバージョンアップも捗るはずです。
スペックアップ後の初めてサインインです。 8 vCPU、32 GB になっていることも確認できます。 Teams 起動中ということもありますが 50% 近くのCPUリソースを消費しています。 Teams 重すぎですよね。
まあ、Teams の起動が終われば以下のとおり CPU リソースの使用率は落ち着きます。
修正プログラムの適用を再開します。 最新の状態であることが確認できます。
しかし、 Windows 11 へのアップグレードを行うためのボタンなどはありません。
何も調査無くバージョンアップは難しそうです。 Microsoft のドキュメントなど確認することにします。
マイクロソフトのWebサイト (新しい Windows 11 OS へのアップグレード | Microsoft)を見ていると互換性チェックのアプリが配布されているようです。 とりあえずこれを落として実行します。
インストールを進めようとすると失敗します。 “システム管理者によって、ポリシーはこのインストールを実行できないように設定されています”とのこと。
管理者権限を明示的に指定することでインストールすることが出来ました。 WindowsPCHealthCheckSetup.msi を右クリックして管理者として実行を行おうとするとそのメニューが表示されなかったのでコマンドプロンプトを管理者として起動し、その中でWindowsPCHealthCheckSetup.msiを起動しています。
セッションホスト上で PC 正常性チェックツールを起動し、”今すぐチェックを実行します”。 この辺で、そういえば Windows 11 はTPM が必須だったはずだが Azure Virtual Machine もモノによっては NG じゃないかなと思いつつクリックします。
予感は的中し、TPM で仕様を満たしていません。 また、プロセッサも未対応とのこと。
このバーストタイプの CPU は Xeon E5-2673 v4 です。 Broadwell という骨董品でした。バーストタイプなので仕方ないですが。 Windows 11 は CPU を選ぶのです。
Windows 11 に対応する CPU のリストは以下のマイクロソフトのサイトを参照。
Windows 11 にするためにどの仮想マシンにするべきなのか再度ドキュメントを探すことにします。
もともとセキュアブートは Azure Virtual Machine の第2世代の機能であることは知っていたのでそのドキュメントを探します。 Microsoft Docs にみつかります。URL
下の方に行くと セキュアブートと vTPM は第2世代 VM でサポートされることがわかります。
そして今利用している Virtual Machine の世代はV1ということで第1世代です。 CPUも変更しつつ世代も第2世代に変更する必要があることがわかってきます。
そして Microsoft Docs では”仮想マシンを作成した後にその世代を変更することは出来ないため”と明記されています。 仮想マシンから作り直す必要があるようです。
セッションホストのカスタムイメージを作り、それを再度 Host Pool から展開することで第2世代に変更出来ないかチャレンジすることにします。
しかし、イメージ作成の際にVM 世代数はグレーアウトされており Gen 1から Gen 2へ変更することが出来ません。
すでに利用しているセッションホストの VM 世代が第1世代だと Windows 11 へのアップグレードは難しいようです。 早々にあきらめて新しく Host Pool から展開することにしました。
基本情報を設定し（検証環境をはい）
仮想マシンメニューの中でセキュリティの種類という設定があります。この中でトラステッド起動の仮想マシンを選ぶことで vTPM やセキュアブートが利用可能となります。
ただ、セキュリティの種類にStandardを選んだままでイメージとして Windows 11 は選択可能。
Microsoft Docs では第2世代の対応OSとして Windows 11 はリストされている。
今回はセキュリティの種類には”トラステッド起動の仮想マシン”を選択し、イメージは”Windows 11 Enterprise multi-session + Microsoft 365 Apps”を使用する。
新しい Windows 11 のセッションホストの展開まで終わりました。
リモートデスクトップクライアントからサインインします。
Edition は Windows 11 Enterprise multi-session 、Version は 21H2です。
CPU は AMD EPYC 7V12 で 8 vCPU、メモリは 28GB です。 この仮想マシンは AMD のGPU搭載タイプなのですがドライバがインストールされておらず認識されていません。 Windows 10 のイメージではドライバは自動インストールされたのですが Windows 11 は未対応です。手動でインストールする必要があります。
今日分かったことは第1世代の Virtual Machine の Windows 10 を Windows 11 へアップグレードは難しいということ。 調べ方は浅いので出来る方法はあるかもですが TPM とセキュアブートは第2世代の機能となり、世代の変更は展開後は出来ないと Microsoft Docs に明記されていたので早々にあきらめました。
以上
