Azure Local 23H2をPowerShellで更新する方法｜2026年4月更新ポイントと実務手順

Azure Local 23H2 系の更新を PowerShell で実行する場合、まず押さえるべき結論は「いきなり Start-SolutionUpdate を実行しない」ことです。2026年4月22日に更新された Microsoft Learn の手順では、現在のバージョンとヘルス状態を確認し、適用可能な更新を検出し、可能であれば -PrepareOnly で事前ダウンロードと準備チェックを済ませてから、メンテナンス時間帯にインストールする流れが推奨されています。対象は Azure Local のハイパーコンバージド展開で、PowerShell から OS、サービス、Solution Builder Extension などの更新を管理したい developers、DevOps engineers、platform teams にとって実務上重要な内容です。(Microsoft Learn)

Azure Local の2026年4月更新で押さえるべきポイント

2026年4月時点の Azure Local は、単なる OS 更新ではなく、Azure Stack HCI OS、コアエージェント、サービス、ハードウェアベンダー由来の Solution Builder Extension などを、Lifecycle Manager のオーケストレーションでまとめて扱う考え方が中心です。Microsoft は Azure Local の更新機能について、複数コンポーネントの更新ワークフローを一つの体験に統合し、事前・実行中のヘルスチェックによってワークロードへの影響を抑える設計だと説明しています。(Microsoft Learn)

特に 2026年4月リリースでは、Azure Local のハイパーコンバージド展開のバージョンは 12.2604.1003.209、OS バージョンは 26100.32690 と案内されています。リリース内容は「信頼性向上とバグ修正」が中心で、新規・既存の展開はいずれもこの OS バージョンで動作するとされています。(Microsoft Learn)

ただし、この記事で扱う Microsoft Learn の「Update Azure Local by using PowerShell」は、特定の1つのパッチ番号だけを説明するページではありません。Azure Local version 23H2 系の環境で、PowerShell を使ってソリューション更新を適用するための運用手順を示すドキュメントです。したがって実務では、「2026年4月版の更新内容を確認する」だけでなく、「自社クラスターでどの更新が Ready なのか」「SBE の追加コンテンツが必要か」「事前チェックで止まる項目があるか」を確認することが重要です。

何が変わったのか：更新作業は“PowerShellで実行、状態はポータル併用”が現実的

今回のドキュメントで実務上目立つポイントは、PowerShell 手順がかなり明確に整理されていることです。更新前の状態確認、更新の検出、必要に応じたインポート、事前ダウンロード、開始、進捗確認、失敗時の再開、インストール後検証まで、運用担当者がそのままランブック化しやすい順序になっています。(Microsoft Learn)

一方で、進捗監視は PowerShell だけにこだわらない方が安全です。Microsoft は、PowerShell から更新を開始した場合でも、更新開始後のクラスタ進捗確認には Azure portal が有用だと説明しています。理由は、更新中にマシンが再起動し、リモート PowerShell セッションが切断される可能性があるためです。(Microsoft Learn)

実務では次のように役割分担すると運用しやすくなります。

作業	推奨される使い方	実務上の理由
更新前の確認	PowerShell	Get-SolutionUpdateEnvironment でバージョンとヘルス状態を確認しやすい
適用候補の確認	PowerShell	Get-SolutionUpdate で Ready や AdditionalContentRequired を判断できる
事前準備	PowerShell	Start-SolutionUpdate -PrepareOnly で事前ダウンロードと準備チェックを実行できる
本番適用	PowerShell	ランブック化しやすく、対象更新を明示しやすい
進捗監視	Azure portal 併用	再起動による PowerShell セッション切断の影響を受けにくい
失敗時調査	PowerShell と Azure portal	UpdateRun やヘルスチェック結果を両方から確認できる

対象環境：Lifecycle Manager が入っている Azure Local が前提

PowerShell 更新手順は、Azure Local の最新バージョンで Lifecycle Manager、つまり orchestrator がインストールされている単一ノードまたは複数ノード環境に適用されます。Azure Local として新規展開したシステムでは、orchestrator は展開時に自動的にインストールされます。(Microsoft Learn)

更新前の前提条件として、Microsoft Learn では次の点が示されています。

確認項目	判断基準
Azure Local のバージョン	version 2311 以上であること
Azure 登録	Azure に登録済みであること
接続元クライアント	Azure Local に接続できるクライアントを用意すること
更新へのアクセス	ネットワーク経由でソリューション更新にアクセスできること

ここで注意したいのは、「Windows Update のように個別コンポーネントだけを任意更新する」発想を持ち込まないことです。Azure Local の更新は、検証済みの組み合わせを保つためのソリューション更新として扱うのが基本です。Microsoft は Azure Local の更新について、Azure CLI、PowerShell、拡張機能を含む個別コンポーネントの out-of-band 更新はサポートしないと説明しています。(Microsoft Learn)

PowerShell 更新の基本フロー

Azure Local PowerShell 更新の実務フローは、次の順番で組むと安全です。

| 順番 | 作業 | 主なコマンド |
| -: | —————— | ———————————————- |
| 1 | リモート PowerShell 接続 | Enter-PSSession |
| 2 | 現在のバージョンとヘルス確認 | Get-SolutionUpdateEnvironment |
| 3 | 適用可能な更新の検出 | Get-SolutionUpdate |
| 4 | 必要に応じて更新ファイルをインポート | Add-SolutionUpdate |
| 5 | 事前ダウンロードと準備チェック | Start-SolutionUpdate -PrepareOnly |
| 6 | 更新開始 | Start-SolutionUpdate |
| 7 | 進捗確認 | Get-SolutionUpdate / Azure portal |
| 8 | インストール後検証 | Get-SolutionUpdateEnvironment / cmd /c ver |
| 9 | 必要に応じてハードウェア更新 | SBE、Windows Admin Center、ベンダー手順 |

リモート PowerShell で Azure Local に接続する

まず、接続元クライアントで PowerShell を管理者として起動し、Azure Local のいずれかのマシンにリモート PowerShell セッションを開きます。

$cred = Get-Credential
Enter-PSSession -ComputerName "<Computer IP>" -Credential $cred

資格情報には、Azure Local の展開時に使用した deployment user account を使います。通常の個人アカウントや、権限が不足した管理アカウントで実行すると、途中でコマンドが通らず作業が止まる原因になります。

現在のバージョンとヘルス状態を確認する

更新前に必ず実行したいのが Get-SolutionUpdateEnvironment です。

Get-SolutionUpdateEnvironment

確認すべき項目は主に CurrentVersion、CurrentSbeVersion、State、HealthState です。Microsoft Learn では、HealthState が Failure、Error、Warning の場合は先に readiness check のトラブルシューティングを確認するよう案内されています。(Microsoft Learn)

実務では、更新前レビュー用に次のように絞り込むと見やすくなります。

Get-SolutionUpdateEnvironment |
  Format-List CurrentVersion, CurrentSbeVersion, State, HealthState, HealthCheckDate

HealthState が Success ではない場合、メンテナンス時間帯を確保していても更新を開始しない方が無難です。特にクラスター、ストレージ、ネットワーク、SBE 関連の警告は、更新中の再起動やノード切り替えに影響する可能性があります。

適用可能な更新を検出する

更新候補は Get-SolutionUpdate で確認します。Microsoft Learn では、Ready または AdditionalContentRequired の更新を抽出する例が示されています。(Microsoft Learn)

Get-SolutionUpdate |
  Where-Object {$_.State -like "Ready*" -or $_.State -like "Additional*"} |
  Format-List DisplayName, Description, ResourceId, State, PackageType

ここで重要なのは ResourceId です。更新開始時に対象を明示するため、作業メモや変更申請書に必ず記録しておきます。

$Update = Get-SolutionUpdate -Id <ResourceId>
$Update
$Update.ComponentVersions

PackageType が Solution の場合、OS やサービスを含むソリューション更新です。SBE が表示される場合は、ハードウェアベンダー由来の Solution Builder Extension 更新が関係します。

AdditionalContentRequired が出た場合の判断

AdditionalContentRequired は、更新に追加コンテンツが必要な状態です。Microsoft Learn では、SBE 更新や Solution + SBE の組み合わせで、ハードウェアベンダーのコンテンツが必要な場合に発生すると説明されています。(Microsoft Learn)

この状態を見たら、次のように判断します。

状態	意味	取るべき対応
Ready	更新を準備・インストールできる	事前準備へ進む
AdditionalContentRequired	追加コンテンツが必要	ベンダー提供ファイルや SBE 関連手順を確認する
期待する更新が表示されない	フィルター外の状態の可能性	フィルターなしで Get-SolutionUpdate を実行する
HealthCheckFailed	準備チェックで失敗	Remediation を確認し、解消してから再実行する

追加コンテンツを手動インポートする場合は、インフラストラクチャボリューム配下に import フォルダーを作成し、更新ファイルを配置してから Add-SolutionUpdate を実行します。

New-Item C:\ClusterStorage\Infrastructure_1\Shares\SU1_Infrastructure_1\import -ItemType Directory

Add-SolutionUpdate -SourceFolder C:\ClusterStorage\Infrastructure_1\Shares\SU1_Infrastructure_1\import

インポート対象のファイル名は更新内容によって異なります。Solution Builder Extension が含まれる場合は、SBE の XML、ZIP、Discovery XML などが必要になるため、ハードウェアベンダーの Azure Local 向けドキュメントを必ず確認してください。

本番前に -PrepareOnly を使うべき理由

Azure Local の更新で失敗しやすいのは、インストール中よりも「準備段階で予想外の問題が見つかる」ケースです。Start-SolutionUpdate -PrepareOnly を使うと、更新をインストールせずにダウンロード、検証、ヘルスチェックを実行できます。Microsoft Learn でも、更新を開始せずにクラスターの更新準備状況を確認できる手順として案内されています。(Microsoft Learn)

Get-SolutionUpdate -Id <ResourceId> | Start-SolutionUpdate -PrepareOnly

準備状況は次のコマンドで確認します。

Get-SolutionUpdate -Id <ResourceId> |
  Format-Table Version, State, UpdateStateProperties, HealthState

ReadyToInstall になれば、インストールを開始できる状態です。HealthCheckFailed の場合は、そのまま本番適用に進まず、失敗したチェックの内容を確認します。

重要な注意点があります。-PrepareOnly で準備を実行した場合、その後の更新開始も PowerShell から行う必要があります。Microsoft は、-PrepareOnly 実行後に Azure portal へ移動して更新を開始することはサポートされず、予期しない問題につながる可能性があると説明しています。(Microsoft Learn)

更新を開始する

準備が終わったら、対象の ResourceId を指定して更新を開始します。

$InstanceId = Get-SolutionUpdate -Id <ResourceId> | Start-SolutionUpdate

事前準備をスキップした場合でも、Start-SolutionUpdate はダウンロードと readiness check を実行してからインストールに進みます。ただし、業務システムを載せた Azure Local では、メンテナンス時間帯に初めて準備チェックを走らせるのはリスクが高い運用です。できる限り事前に -PrepareOnly を使い、ブロッカーを潰しておくべきです。

なお、インストール中はシステム内のマシンが再起動する可能性があります。単一ノード構成では Azure Local にダウンタイムが発生すると Microsoft Learn でも明記されています。(Microsoft Learn)

進捗確認で見るべき状態

更新中は、次のような状態遷移を確認します。

Get-SolutionUpdate -Id <ResourceId> |
  Format-Table Version, State, UpdateStateProperties, HealthState

State	意味	対応
Downloading	更新パッケージをダウンロード中	ネットワーク帯域と失敗有無を確認
Preparing	ファイル検証・展開などの準備中	しばらく待機
HealthChecking	更新前ヘルスチェック中	失敗した場合は内容を確認
ReadyToInstall	インストール可能	メンテナンス時間帯に本番適用
Installing	インストール中	Azure portal でも進捗確認
Installed	インストール完了	バージョン検証へ進む
InstallationFailed	インストール失敗	UpdateRun とエラー詳細を確認

より詳細な準備・インストールの進捗は Get-SolutionUpdateRun からも確認できます。Microsoft は、Azure Local 更新を「Preparation」と「Installation」の2フェーズとして説明しており、各フェーズでは UpdateRun リソースが進捗、タイミング、エラーを記録します。(Microsoft Learn)

Get-SolutionUpdate -Id <ResourceId> |
  Get-SolutionUpdateRun |
  ForEach-Object Progress |
  ForEach-Object Steps

失敗時は IgnoreWarnings を安易に使わない

更新が失敗した場合、単純に再実行する前に失敗理由を確認します。Microsoft のトラブルシューティングでは、readiness check は Critical、Warning、Informational に分類され、Critical は更新をブロックし、Warning も既定では更新をブロックしますが、Start-SolutionUpdate -IgnoreWarnings で上書きできると説明されています。(Microsoft Learn)

$result = Get-SolutionUpdateEnvironment

$result.HealthCheckResult |
  Where-Object {$_.Status -ne "SUCCESS"} |
  Format-List Title, Status, Severity, Description, Remediation

失敗した更新を再開する基本形は次の通りです。

Get-SolutionUpdate -Id <ResourceId> | Start-SolutionUpdate

Warning を無視して再開する場合は次のコマンドです。

Get-SolutionUpdate -Id <ResourceId> | Start-SolutionUpdate -IgnoreWarnings

ただし、-IgnoreWarnings は「警告だから安全」という意味ではありません。たとえば冗長電源、ファームウェア、ストレージ、クラスターヘルスに関する警告は、更新中の再起動やフェールオーバーに影響する可能性があります。グローバル拠点で複数クラスターを運用している場合は、Warning の内容、対象ノード、Remediation、ベンダー推奨事項を変更管理プロセスに残してから判断すべきです。

インストール後に確認すること

更新が Installed になったら、Azure Local のソリューションバージョンと OS バージョンを確認します。

Get-SolutionUpdateEnvironment | Format-Table State, CurrentVersion

OS バージョンは次のコマンドで確認できます。

cmd /c ver

この確認を省略すると、監視上は完了しているように見えても、運用台帳や CMDB、セキュリティ監査で必要なバージョン情報が更新されません。特に複数リージョン、複数拠点、複数ハードウェアベンダーの Azure Local を運用している platform team は、更新後の CurrentVersion、CurrentSbeVersion、OS build、実施日時、対象ノード、発生した警告をセットで記録すると後続の障害解析が楽になります。

Solution Builder Extension とハードウェア更新の扱い

Azure Local の更新で見落としやすいのが、ドライバーやファームウェアなどのハードウェア更新です。Solution Builder Extension は、ハードウェアベンダーから提供されるドライバー、ファームウェア、ハードウェア監視、診断ツールなどの更新を Azure Local に適用するための仕組みです。Microsoft は、SBE パッケージ更新を Azure Local のソリューション更新プロセスに統合できると説明しています。(Microsoft Learn)

ただし、すべてのハードウェアで同じ体験になるとは限りません。SBE に対応しているシステムでは、Azure Local Feature update に適切な SBE 更新が含まれる場合があります。一方、SBE をサポートしないハードウェアでは、Windows Admin Center またはハードウェアベンダーの推奨手順でファームウェアやドライバーを別途更新する必要があります。(Microsoft Learn)

実務では、次の観点で事前に仕分けしておきましょう。

確認項目	見るポイント
SBE がインストールされているか	Get-SolutionUpdateEnvironment の SbeFamily、HardwareModel、CurrentSbeVersion
SBE 更新が Ready か	Get-SolutionUpdate の PackageType と State
追加コンテンツが必要か	AdditionalContentRequired の有無
ベンダー手順が必要か	ハードウェアベンダーの Azure Local ドキュメント
メンテナンス時間が十分か	ノード数、更新内容、再起動回数、SBE 有無

サポート観点：23H2 OS の期限にも注意

2026年4月更新を扱ううえで重要なのが、23H2 OS のサポート期限です。Microsoft Learn のリリース情報では、Azure Stack HCI version 23H2 OS、つまり OS version 25398.xxxx は 2026年4月にサポート終了に到達するとされています。また、2025年10月の 11.2510 が最終 23H2 リリースで、2026年4月以降は 23H2 向けの月例セキュリティおよび品質更新を受け取れないと説明されています。(Microsoft Learn)

そのため、23H2 系の Azure Local を運用している組織は、単発の PowerShell 更新だけでなく、24H2 系への移行計画、ドライバー互換性、SBE 対応状況、メンテナンスウィンドウを合わせて確認する必要があります。グローバル拠点で運用している場合は、地域ごとの保守時間、ネットワーク帯域、現地チームの対応可否も計画に含めるべきです。

運用ランブックに入れておきたいチェックリスト

Azure Local PowerShell 更新を安定して回すには、コマンド手順だけでなく、判断基準をランブックに入れることが重要です。

タイミング	チェック内容	合格基準
更新計画時	対象クラスターと現在バージョン	CurrentVersion と OS build が記録済み
更新前	ヘルス状態	HealthState が原則 Success
更新前	SBE 状態	SBE の有無、追加コンテンツ要否を確認済み
更新前	事前準備	-PrepareOnly 後に ReadyToInstall
更新中	進捗	Installing から Installed へ遷移
失敗時	エラー詳細	HealthCheckResult または UpdateRun を確認
更新後	バージョン確認	CurrentVersion と cmd /c ver を記録
更新後	ハードウェア更新	SBE、WAC、ベンダー手順の完了を確認

まとめ：2026年4月の Azure Local 更新は「事前準備」と「状態確認」が要点

Azure Local の2026年4月更新ポイントは、PowerShell で更新を開始できること自体ではなく、Lifecycle Manager を前提に、OS、サービス、Solution Builder Extension を含むソリューション全体を安全に更新する運用へ寄せることです。

実務でまず行うべきことは、対象環境で次の3つを確認することです。

• Get-SolutionUpdateEnvironment で現在のバージョンと HealthState を確認する
• Get-SolutionUpdate で Ready または AdditionalContentRequired の更新を確認する
• 本番適用前に Start-SolutionUpdate -PrepareOnly で事前ダウンロードと readiness check を済ませる

PowerShell 更新は自動化しやすい一方、Azure Local ではハードウェア、SBE、クラスター状態、サポート期限が密接に関係します。コマンドをコピーして実行するだけでなく、ResourceId、State、HealthState、CurrentVersion、OS build を記録し、失敗時に戻れる運用ランブックとして整備しておくことが、DevOps engineers や platform teams にとって最も実用的な対策です。