SE の雑記

当ブログでは Azure Stack HCI 22H2 を 23H2 にアップグレードする際の日本語環境の制限について として情報を記載していましたが、自分の中での整理を兼ねて新しい投稿を。

Azure Local バージョン 22H2 OS サポート終了について / Upgrade to Azure Local, version 23H2 OS でもアナウンスが行われていますが、Azure Local (Azure Stack HCI) の 22H2 のサポートが 2025/5/31 に終了します。

英語版のメディアでインストールした環境であれば Azure ローカル アップグレードについて の一連のドキュメントを参考にアップグレードを計画することができます。

しかし、22H2 までは日本語版のインストールメディアが提供されており (23H2 では英語版のみになりました)、日本語版のインストールメディアでインストールされた環境では、「ソリューションアップグレードの適用」がサポートされていません。

これは 修復 5: 言語が英語であることを確認する にも記載されています。

英語を使用してインストールされたシステムのみが、ソリューションのアップグレードを適用できます。 システムが英語を使用してインストールされていることを確認します。

そのため、ドキュメントで公開されている 22H2 のアップグレード手順とは異なる方式を検討する必要があります。

日本語メディアで構築された Azure Locak 22H2 を 23H2 にアップグレードする場合のアップグレード方式として、考えられるものをまとめておこうかと思います。

アップグレードについての公式ドキュメント

22H2 から 23H2 へのアップグレードについては、次のドキュメントツリーが公式ドキュメントとなりますので、最初にこのドキュメントを一読しておきます。

• Azure ローカル アップグレードについて
• Upgrade

アップグレードではありませんが、高添さんが公開されている 23H2 の展開方法のドキュメントも参考となります。

• AzureStackHCI_23H2 展開方法

仮想環境での PoC の実施

実際の運用環境で 22H2 から 23H2 のアップグレードを実施する前に、PoC として他の環境でアップグレードの実施を行うことになるかと思いますが、その際には仮想環境で実施するのが一般的ではないでしょうか。

仮想環境上で構築する場合、23H2 のドキュメントとなりますが、22H2 でも次のドキュメントが参考となります。

• Deploy a virtual Azure Local system
• Use CreateVmsUsingScript To Deploy A Nested Virtualization Environment To Test Azure Stack HCI 23H2

ハードウェアサポート状況の確認

Azure Local は統合システム上で稼働していることが多いのではないでしょうか。

統合システム上で稼働している場合、https://azurelocalsolutions.azure.microsoft.com/#/catalog から、ハードウェアを確認することができますが「Platform lifecycle」が「Limited Support」「Out of Support」となっているハードウェアの場合、23H2 の実行がサポートされていない可能性がありますので、アップグレードしようとしているハードウェアが 23H2 をサポートしているかを意識しておく必要があります。

また、アップグレードの公式のドキュメントは Azure ローカル アップグレードについて となりますが、各ベンダーでアップグレードの情報を公開しているものもありますので、これらの情報も一度確認しておくとよいのではないでしょうか。

DELL

• Azure ローカル バージョン 22H2 を Azure ローカル バージョン 23H2 にアップグレードする
• Support Matrix
• 参考情
  • デル・テクノロジーズが提供するMicrosoft HCIソリューション：スイッチレス ネットワーキングを使用したエンドツーエンドの導入および運用ガイド Deployment Guide
    • スイッチレスでストレージ用のネットワークを構築した場合の、ストレージネットワークの ATC の設定方法が記載されています。
  • デル・テクノロジーズのHCI Solutions for Microsoft Windows Server：スイッチレス ネットワーキングを使用したエンドツーエンドの導入および運用ガイド(Windows) 導入ガイド
    • iDRAC の USB NIC のクラスター検証の除外方法について記載されています。
    • 除外については、「Get-NetAdapter -InterfaceDescription "Remote NDIS Compatible Device" | Disable-NetAdapter」 を実行して無効にすることを検討してもよいかと。
• Lenovo
  • Upgrading ThinkAgile MX Servers from Azure Local version 22H2 to 23H2

Azure Local の統合システムを提供しているベンダーの情報としては、 HP / Lenovo / Dell / Huawei / Cisco / Fujitsu 辺りの情報を確認してみるとよいかもしれませんね。(DefaultOemUpdateRings.xml に記載されているベンダー)

日本語版メディアで構築された Auzre Local 22H2 のアップグレード方式

日本語メディアで構築された Azure Local 22H2 のアップグレード方式としては次の 3 つの方法が考えられるのではないでしょうか。

1. ソリューションアップグレードを展開せずに 23H2 を使用する
2. 22H2 の段階でクラスターのノードを全て英語版の 23H2 に置き換えてからアップグレードを行う
3. 23H2 にアップグレードした後に、クラスターのノードを全て英語版の 23H2 に置き換えてからアップグレードを行う

ソリューションアップグレードを展開せずに 23H2 を使用する

この方法が 23H2 にアップグレードするのに最も容易な方法ですが、ソリューションアップグレード (リソースブリッジ) を展開しないため、アップグレード後に Azure Local の全機能を使用することはできません。

Azure Local 23H2 で英語版のメディアで構築された環境が必須となるのは「ソリューションアップグレード」を展開するタイミングとなり、日本語版のメディアで構築していた環境でも「22H2 → 23H2 へのインプレースアップグレード」については実施することができます。

ソリューションアップグレードを展開しない場合、Azure Local のすべての機能を使用することはできませんが「Hyper-V の実行基盤」としてであれば、この方法で OS をインプレースアップグレードすることで延命できる可能性があります。

23H2 へのアップグレード機能が提供された直後に検証して確認した内容では、ソリューションアップグレードを展開せずに 23H2 にアップグレードした環境も 23H2 のサポートライフサイクルの間はサポートされるということでした。(今後、新しいバージョンが提供された際にはそのバージョンではサポートされない可能性が高いです)

しかし、この状態ではリソースブリッジを展開していないため、Azure Portal からの更新プログラムの適用は実行できません。

更新プログラムの適用は、最新のドキュメントでは 更新プログラムのサポートされていないインターフェイス となっている更新方法に頼らざるを得ないかと思います。

ひとまず、サポートされるバージョンにアップグレードするということでは一番手軽な方法ではあるのですが、現在公開されている情報内ではどこまでサポートされるのかが正直不安ではあります….。

2025/5/31 の 22H2 のサポート終了に対しては、ひとまずこれを実施しておくことで、サポート終了に対しての対応は実施することができます。

22H2 の段階でクラスターのノードを全て英語版の 23H2 に置き換えてからアップグレードを行う

Azure Local はノードの追加 / 削除がサポートされており、このようなノードの操作方法は Add or remove servers for an Azure Stack HCI cluster としてドキュメントが公開されています。

ノードの削除 → OS のディスクを初期化し英語版メディアで 22H2 をインストール → 必要な設定 / 機能のインストールが完了したら WSFC のノードに追加

このような作業を全ノードで繰り返すことで、クラスター内の全ノードを英語版に切り替えていきます。

このような対応を実施し、22H2 の全ノードを英語版メディアでインストールされた環境に切り替えます。

切り替えが完了してから、Azure ローカル アップグレードについて の作業を順次実行することで、23H2 へのアップグレードを実施します。この方法では英語環境でインストールしたノードに切り替えを行っていますので、ソリューションアップグレードの展開も実施することができます。

Nested Hyper-V 上に構築した環境での検証となりますが、この方法で実際に 23H2 のアップグレード / ソリューションアップグレードの展開まで実施することができています。

22H2 の段階で、ソリューションアップグレードの展開に必要な対応を一通り実行してから 23H2 にアップグレードする方法となります。

実施している作業は 22H2 でのノードの入れ替えとなり、入れ替え後は Azure ローカル アップグレードについて のドキュメントの流れで対応ができますので、ドキュメントのとおりに作業ができる手順としてはこの手順が一番シンプルかと思います。

23H2 にアップグレードした後に、クラスターのノードを全て英語版の 23H2 に置き換えてからアップグレードを行う

前項では、22H2 の段階で英語版の環境に入れ替えましたが、この方法は 23H2 にアップグレードした後に英語版の環境に入れ替える方法となります。

「ソリューションアップグレードを展開せずに 23H2 を使用する」として記載したように、23H2 へのインプレースアップグレードまでは日本語版のメディアでインストールした環境でも実行することができます。

インプレースアップグレードを実施して、23H2 の環境となった後に 22H2 で実施した作業と、Azure Local でノードを修復する を参考にしながら、23H2 の英語版のメディアを使用してインストールされたノードに置き換えていきます。

この方法でアップグレードしていたところ、一時的にではありますが後述の「Count of ARC machines used during Validation [x] is different from that used during deployment [x]」のエラーが発生しました。

エラーを解消したところ、この方法でもアップグレードを最後まで実行することができました。

一時的に発生していた問題

23H2 にアップグレードした後に、英語版のノードへの入れ替えを実施し、その後ソリューションアップグレードの展開を行う方法を検証していた際に発生した問題となります。

私が検証をしていた際にはこの方法で入れ替えをしようとするとソリューションアップグレードの展開時に「Count of ARC machines used during Validation [x] is different from that used during deployment [x]」のエラーが発生し、展開時の検証を完了させることができませんでした。

この環境を展開した際には 3 ノード構成としており、1 ノードずつ入れ替えながらアップグレードをしていのですが、Azure 上で認識されている構成と、実際の構成で差が出てしまったタイミングがったのか、このエラーが発生してしまいソリューションアップグレードを展開することができませんでした。

後日、以下の作業を実施したところ、上記のエラーは解消しました。

• 全ノードをシャットダウンした状態で 1 日程度放置
• 全ノードを起動後、Sync-AzureStackHCI を実行
• User deleted the App IDs by mistake に記載されている 「Register-AzStackHCI -RepairRegistration」を実行
  • この作業がエラーの解決の主な要因だったような気がしています。

1 ノードずつ入れ替えを実施しているため、タイミングによっては 2 ノードの構成となっている状態があるのですが、この状態の情報が Azure 上に連携されたことで、実環境と差が出てしまったのかと思います。

ソリューションアップグレードの展開 (アップグレード) を行うことができるかの事前確認

OS のインプレースアップグレードはどのサブスクリプションでも実施できるはずです。

しかし、私が 22H2 からのアップグレードの検証を実施していた際には、ソリューションアップグレードを展開するための Azure Portal 上のリンクの表示は、ホワイトリストによる許可制となっており、アップグレードが許可されたサブスクリプションでないと、「アップグレードのリンクが表示されない」という制御が行われていました。

私の環境 (サブスクリプション) では、既にソリューションアップグレードの展開ができるように対応してもらえているのですが、投稿時点では、Install solution upgrade on Azure Local には次の記載が残った状態です。

While the OS upgrade is generally available, the solution upgrade will have a phased rollout.

22H2 からのアップグレードを検討しており、OS アップグレード後にリンクが表示されない場合、SR を起票し状況を確認して、ホワイトリストへの登録を依頼する必要があります。

22H2 からのアップグレードを予定しているサブスクリプションで、アップグレードのリンクが表示されるかは事前に検証環境を構築して確認をしておいたほうが良いかと思います。

ノード入れ替え時に実施した作業

メモですが、ノード入れ替え時に実施した作業としては次の内容となります。

ノードの入れ替えの基本作業

基本的には、Add or remove servers for an Azure Stack HCI cluster (22H2) / Azure Local でノードを修復する (23H2) の作業を実施していけばよいという認識です。

22H2 で AKS を使用していた場合は、MOC (Microsoft Online Cloud) をアンインストールする必要がありますので、Remediation 10: Check the MOC install state の手順で削除を行います。

ノード入れ替えの基本的な手順としては次の作業内容となります。

1. Azure Portal から入れ替えるノードの Azure Arc リソースを削除する。
2. WSFC のノードから入れ替えるノードを削除する。
3. 入れ替えるノードの OS ディスクを初期化し、英語版のインストールメディアで再インストールする。
   • データディスクについては WSFC にノードを追加した際に、自動的に修復が行われるため、操作は行わずに残しておきます。
4. 必要となる機能をインストールする。
   • 22H2 のノード追加時: Windows PowerShell を使用して Azure Stack HCI クラスターを作成する
   • 23H2 のノード追加時: Remediation 1: Install required and optional Windows features
5. ドメインに参加する。
6. WSFC にノードを追加する。
   • このタイミングで S2D の修復が行われるため 操作の進行状況を監視する で修復状況を確認し、入れ替えたノードで S2D の修復が完了することを確認
7. 必要に応じて、Arc の管理の修復を行う。
   • Azure Local バージョン 22H2 の拡張管理を有効にする
   • マシンを登録し、Azure Local バージョン 23H2 デプロイのアクセス許可を割り当てる

この作業をクラスターを構成する全ノードに対して、実施していきます。

クラスターリソース名を英語名に変更する

アップグレードは英語版の環境を使用していることが前提となっているため、ドキュメントには記載されていませんが、クラスターグループ / リソースで日本語名が使用されているものを英語名に変更しておく必要があります。

この変更をしていないとソリューションアップグレードの準備の実行やそれ以外のステップでエラーとなる箇所があります。

次のようなコマンドを実行して英語版のグループ名 / リソース名に設定を変更します。(環境によって作成されているリソースに差がありますので、「Get-ClusterResource」で確認をして、日本語が含まれるものは英語に変更を行います、)

Get-ClusterGroup -Name "クラスター グループ" | %{$_.Name = "Cluster Group"}
Get-ClusterGroup -Name "SDDC グループ" | %{$_.Name = "SDDC Group"}
Get-ClusterGroup -Name "使用可能記憶域" | %{$_.Name = "Available Storage"}
Get-ClusterGroup -Name "ユーザー マネージャー グループ" | %{$_.Name = "User Manager Group"}

Get-ClusterResource -Name "SDDC の管理" | %{$_.Name = "SDDC Management"}
Get-ClusterResource -Name "クラスター IP アドレス" | %{$_.Name = "Cluster IP Address"}
Get-ClusterResource -Name "クラスター プール 1" | %{$_.Name = "Cluster Pool 1"}
Get-ClusterResource -Name "クラスター仮想ディスク (ClusterPerformanceHistory)" | %{$_.Name = "Cluster Virtual Disk (ClusterPerformanceHistory)"}
Get-ClusterResource -Name "クラスター名" | %{$_.Name = "Cluster Name"}
Get-ClusterResource -Name "ヘルス" | %{$_.Name = "Health"}
Get-ClusterResource -Name "ユーザー マネージャー" | %{$_.Name = "User Manage"}
Get-ClusterResource -Name "記憶域 Qos リソース" | %{$_.Name = "Storage Qos Resource"}
Get-ClusterResource -Name "Azure Stack HCI クラスター エージェント" | %{$_.Name = "Azure Stack HCI Cluster Agent"}

ネットワーク ATC の設定

21H2 からアップグレードをしている環境や 22H2 で ATC を使用しなかった場合、Network ATC が設定されていない状態となっています。23H2 は ATC を使用したネットワーク構成が前提となっているため ATC の設定をどこかのタイミングで実施する必要があります。

Azure Local バージョン 22H2 に Network ATC をインストールして有効にする には次の記載があるため、23H2 にアップグレードした後に、ネットワーク ATC を設定するのが良いのではないでしょうか。

オペレーティング システムをバージョン 22H2 からバージョン 23H2 にアップグレードした後で、Network ATC を設定することをお勧めします。

ATC を事前に設定しておけば、ネットワークアダプター名を適切な名称に設定しておくことで WSFC のノード追加時に ATC により自動的にネットワークが構成されます。

Network ATC の設定が想定通り反映されていないというような場合は、自動修復を検証する の方法でリトライ実施 / Microsoft-Windows-Networking-NetworkAtc のイベントログを確認して、対応を行います。

スイッチレスでストレージのネットワークを構築している場合は、前述のとおり デル・テクノロジーズが提供するMicrosoft HCIソリューション：スイッチレス ネットワーキングを使用したエンドツーエンドの導入および運用ガイド Deployment Guide  のドキュメントを確認しておくとよいのではないでしょうか。

PowerShell モジュールの CloudCommon ディレクトリのコピー

22H2 / 23H2 のどのタイミングでノードを入れ替えたパターンでも発生したことがあり、発生しなかったこともあるので、確実に必要となる作業ではないのですが、エラーが発生した場合は対応する必要があります。

[確認と作成] タブ でアップグレードプロセスを開始した後に次のエラーが発生することがありました。

WARNING: Task: Invocation of interface ‘CleanUpDeploymentPackageAndNugetStoreOnNonSeedNodes’ of role ‘BareMetal’ failed:

Type ‘CleanUpDeploymentPackageAndNugetStoreOnNonSeedNodes’ of Role ‘BareMetal’ raised an exception:

The specified module ‘CloudCommon’ was not loaded because no valid module file was found in any module directory.

at CleanUpDeploymentPackageAndNugetStoreOnNonSeedNodes, C:\CloudDeployment\Classes\BareMetal\BareMetal.psm1: line 557

at <ScriptBlock>, C:\CloudDeployment\ECEngine\InvokeInterfaceInternal.psm1: line 139

at Invoke-EceInterfaceInternal, C:\CloudDeployment\ECEngine\InvokeInterfaceInternal.psm1: line 134

at <ScriptBlock>, <No file>: line 33 – 4/13/2025 2:55:16 AM

WARNING: Task: Retrying interface ‘CleanUpDeploymentPackageAndNugetStoreOnNonSeedNodes’ of role ‘BareMetal’… – 4/13/2025 2:55:16 AM

これは、「C:\Program Files\WindowsPowerShell\Modules」に「CloudCommon」が存在しないノードがあることで発生しているようでした。

Issues for version 2311.2 で修正されている問題に近い内容に見えますが、23H2 へのアップグレードでも、この事象が発生する可能性があるように見えました。

私が遭遇したケースでは、クラスター内のいずれかのノードには CloudCommon が存在していましたので、次の対応を実施することでエラーを解決できました。

1. C:\Program Files\WindowsPowerShell\Modules\CloudCommon が存在しないノードにファイルをコピー
2. コピーしたファイルに ZoneId が設定されている場合は次のコマンドで ZoneId を削除
   • ZoneId を削除していないと「AuthorizationManager check failed.」のエラーが発生してしまうため。

cd "C:\Program Files\WindowsPowerShell\modules"
Get-ChildItem -Recurse -File | Unblock-File

このような方法でノードを入れ替えていくことができるかと。

実際に上述の方法で、「22H2 の段階でクラスターのノードを全て英語版の 23H2 に置き換えてからアップグレードを行う」「23H2 にアップグレードした後に、クラスターのノードを全て英語版の 23H2 に置き換えてからアップグレードを行う」のどちらの方法でもソリューションアップグレードの展開が完了できることを確認しています。