Azure Local（Azure Stack HCI）クラスターのデプロイ中にポータル上でノードが「Not Validated」と表示され、検証タスクで謎のエラーが出続ける――という状況は、要因が複数絡みやすく、原因特定に時間がかかりがちです。本記事では、実際に発生しやすい「ValidateArcIntegration」「ValidateOSImageRecipe」失敗パターンを題材に、再現性のある切り分け手順と、現場でそのまま使えるチェックリスト形式で解説します。
Azure Local（Azure Stack HCI）デプロイ時に「Not Validated」になる典型パターン
Azure ポータルから Azure Local（Azure Stack HCI）クラスターのデプロイを開始すると、ウィザードの途中で各ノードのステータスが表示されます。このとき、一部またはすべてのノードが 「Not Validated」 のままになり、次のステップに進めないケースがあります。
さらに、ARM テンプレート（Bicep/JSON）で同じクラスターをデプロイしてみると、内部で実行されている検証タスクのうち、例えば次のようなタスクが失敗していることが分かります。
- ValidateArcIntegration
例：The provided account <identity> does not have access to subscription ID “<sub-id>”… - ValidateOSImageRecipe
例：特定の Windows 更新プログラム（KB5053599）が未適用、または Azure CLI が見つからない／想定パスと異なる、など。
このように、ポータル上は「Not Validated」という一行の表示ですが、実際には複数の検証タスクが同時進行しており、どれか一つでも失敗するとノードの検証が完了しません。そのため、どのタスクが失敗しているかを特定することが最初の一歩になります。
事象の整理：ポータル表示と ARM テンプレートの関係
まず、ポータルと ARM テンプレート（または Bicep）で見えている情報を整理しておきます。
| 視点 | どこで見るか | 見える情報 | 役割 |
|---|---|---|---|
| ポータル ウィザード | Azure ポータル > Azure Local | ノードごとの「Validated / Not Validated」などの概要 | ユーザーフレンドリーな結果要約 |
| ARM テンプレート / Bicep | テンプレートデプロイの履歴・出力 | 各検証タスク（ValidateArcIntegration など）の詳細エラー | 原因特定の決定版 |
| サーバーログ | C:\CloudDeployment\… など | スクリプト単位のログ、スタックトレース | どうしても原因が分からない場合の最終手段 |
運用上のコツとしては、次の順番で原因を追っていくと効率的です。
- ポータルで「Not Validated」を確認（事象の入口）
- 同じ構成を ARM テンプレート／Bicep でデプロイしてみて、どの検証タスクが失敗しているか を特定
- 該当タスクに応じて、Arc 接続・RBAC・OS レシピ・Azure CLI のどこを疑うかを決める
まずはここから：Arc 接続と権限・前提条件の切り分け
Azure Arc 接続状態の確認
Azure Local（Azure Stack HCI）は、Azure Arc を通じて Azure と連携します。そのため、Arc 接続が不完全だと、そもそも検証タスクが正常に動作しません。
Azure ポータル上で次の順に確認します。
- Azure ポータル > Azure Arc > Host Environments > Azure Local
- 対象サーバー（各ノード）を開き、次を確認
- Status が Connected になっている
- Agent Version がサポートされている最新バージョンである
ここで「Disconnected」や古いバージョンが表示されている場合、Arc の接続やエージェント更新を先に是正してからクラスター検証をやり直すのが鉄則です。
主なエラーと原因カテゴリの対応表
ARM テンプレートの結果から分かる主な検証タスクと、疑うべき原因カテゴリを表にまとめます。
| 検証タスク名 | 代表的なエラーメッセージ | 主な原因カテゴリ | 最初に確認すべきポイント |
|---|---|---|---|
| ValidateArcIntegration | The provided account <identity> does not have access to subscription ID… | RBAC / リソース プロバイダー / サブスクリプション コンテキスト | 権限ロール、RP 登録、az/PowerShell のコンテキスト |
| ValidateOSImageRecipe | Required KB KB5053599 is missing… | OS 更新プログラム / イメージレシピ | 要求 KB が全ノードに適用済みか |
| ValidateOSImageRecipe | Azure CLI is not installed or path mismatch… | ツール類（Azure CLI）のバージョン／パス | CLI のインストール状況とパス統一 |
以下では、特に遭遇しやすい ValidateArcIntegration と ValidateOSImageRecipe のエラーに絞って、より具体的な対処方法を解説します。
ValidateArcIntegration 失敗：サブスクリプション権限／コンテキスト不一致
よくある原因
ValidateArcIntegration は、Azure Arc と Azure Local クラスターが正しく統合されているかを確認するタスクです。ここで多いのは次のパターンです。
- デプロイに使用しているユーザー／サービスプリンシパル／マネージド ID に、必要な RBAC ロールが付与されていない
- 適切なサブスクリプションではなく、別サブスクリプションのコンテキストでコマンドを実行している
- 必要なリソース プロバイダー（RP）がサブスクリプションに登録されていない
- Azure Policy が一部リソースや拡張機能の作成をブロックしている
必要な RBAC ロールの整理
環境によって細かい差は出ますが、概ね次のようなロールが必要になります（最低限の目安）。
| ロール名（例） | 付与スコープの目安 | 主な用途 |
|---|---|---|
| Azure Stack HCI Device Management Role | サブスクリプションまたは対象リソース グループ | Azure Local（Azure Stack HCI）リソースの作成・管理 |
| Azure Connected Machine Resource Administrator （または Onboarding 系ロール） | サブスクリプションまたはリソース グループ | Arc 対応マシン（ハイブリッドサーバー）の登録・管理 |
| Reader | 少なくともサブスクリプション単位で付与しておくと便利 | 関連リソース／設定の参照に必要 |
注意点として、スレッドやメモの中に「Azure Connected Machine Resource Manager」のような表記が出てくる場合がありますが、ポータルの「ロールの割り当て」画面で実際に存在する組み込みロール名を選択するようにしてください。表記ゆれがあると、意図しないロールを付けてしまうことがあります。
リソース プロバイダー（RP）の登録
サブスクリプションに必要なリソース プロバイダーが登録されていないと、検証タスクがバックエンドで関連リソースを作成できず、失敗する場合があります。代表的な RP は次の通りです。
Microsoft.AzureStackHCIMicrosoft.HybridComputeMicrosoft.GuestConfiguration- （環境により）
Microsoft.PolicyInsightsなど
登録状況は Azure ポータルの「サブスクリプション > リソース プロバイダー」から確認できますが、スクリプトで一括確認・登録しておくと楽です。
# PowerShell（Az モジュール）例
Connect-AzAccount
Set-AzContext -Subscription "<sub-id>"
$providers = @(
"Microsoft.AzureStackHCI",
"Microsoft.HybridCompute",
"Microsoft.GuestConfiguration"
)
foreach ($p in $providers) {
Register-AzResourceProvider -ProviderNamespace $p
}
Azure Policy によるブロックを疑うポイント
Azure Policy は「必ずしも検証タスクの直接のエラー原因とは限らない」が、結果としてリソースが作成できず、検証が失敗するケースがあります。例えば次のようなポリシーです。
- 許可されるリージョンを制限するポリシー
- 特定のリソース種類の作成を禁止するポリシー
- VM 拡張機能のインストールを制限するポリシー
Azure Policy のステータスで「非準拠」と出ていても、すぐに検証が失敗するとは限りませんが、本番前に是正しておくべきものです。特にセキュリティ系の強いポリシーを全社スコープで適用している場合は、Azure Local 用のリソース グループだけ一時的に除外するなど、運用ルールを事前に決めておくとトラブルを避けやすくなります。
サブスクリプション コンテキストの確認（PowerShell / Azure CLI）
うっかりやりがちなミスが、別サブスクリプションのコンテキストでコマンドを実行しているケースです。必ず次のように確認しましょう。
PowerShell（Az モジュール）
Connect-AzAccount
# 利用可能なサブスクリプション一覧
Get-AzSubscription | Format-Table Name, Id
# 対象サブスクリプションにコンテキストを切り替え
Set-AzContext -Subscription "<sub-id>"
# 現在のコンテキストが想定通りか確認
Get-AzContext
# 参考：Az モジュールの設定状況（プロキシや既定値など）
Get-AzConfig
Azure CLI
az login
# サブスクリプション一覧を確認
az account list -o table
# 対象サブスクリプションを選択
az account set --subscription "<sub-id>"
# 現在のコンテキスト確認
az account show -o table
上記を実施してもなお ValidateArcIntegration が失敗する場合は、ロールのスコープが狭すぎないか（サブスクリプションではなく一部のリソース グループにしか付いていないなど）も再確認してください。
ValidateOSImageRecipe 失敗：OS 要件（特定 KB 未適用）
典型的な症状：KB5053599 が未適用
ValidateOSImageRecipe は、Azure Local クラスター構成に必要な OS イメージ要件を満たしているかをチェックするタスクです。ここで多いのが、特定の累積更新（LCU）が入っていない、あるいは違う KB は入っているものの、レシピが要求するものと番号が一致していないため失敗するパターンです。
例：
- NODE-04 のみ要求される KB5053599 が未適用
- 別の新しい累積更新は入っているが、レシピが 「KB5053599 が入っていること」 を条件にしているため NG
ポイントは、「最新の更新だから大丈夫」ではなく「レシピが指定した KB 番号が入っていること」が合格条件になっている点です。
KB の適用手順（実務向け）
要求された KB を適用する標準手順は次の通りです。
- Microsoft Update Catalog で該当 KB（例：KB5053599）を検索する
- 対象 OS のバージョン、アーキテクチャ（x64 など）に合ったパッケージを選択し、.msu をダウンロード
- 各ノードにパッケージを配布し、ローカルでインストール
- インストール完了後、必ず再起動を実施
- 再度、クラスター検証（ValidateOSImageRecipe） を実行
インストール状況は、PowerShell で次のように確認できます。
Get-HotFix | Where-Object { $_.HotFixID -eq "KB5053599" }
必要な KB がすべてのノードに適用されているかどうかは、クラスター全体で揃っていることが重要です。1 台だけ古いままだと、そのノードだけ検証で落ちて「Not Validated」になります。
「より新しい更新が入っているのに NG」な理由
現場でよくある誤解が、
- 「KB5053599 より新しい累積更新が入っているから、当然 OK のはず」
という考え方です。しかし、ValidateOSImageRecipe は、内部で決められた条件（特定 KB の存在）をそのままチェックしているだけであり、「新しいから OK」というロジックにはなっていません。結果として、
- 実質的には OS のビルドは要件を満たしているのに、指定 KB 番号が見つからないため不合格
という「もったいない」失敗が発生します。これを避けるには、クラスター構成ガイドや Azure Local のバージョンに対応する公式ドキュメントで、「必須 KB 番号」を事前に洗い出し、イメージ作成時点で組み込んでおくのが理想的です。
Azure CLI が見つからない／パス不一致によるエラー
症状：Azure CLI の未インストールまたは想定パスと不一致
ValidateOSImageRecipe や関連タスクの中には、Azure CLI の存在を前提としているものがあります。このとき、次のようなエラーがログに記録されることがあります。
- Could not find file ‘C:\Users\Administrator\Documents\AzureCLI.net’
- Azure CLI が PATH に存在しない、またはバージョンが古い
環境によっては、スクリプトが特定パス（例：C:\Program Files (x86)\Microsoft SDKs\Azure\CLI2\wbin\az.cmd など）を前提にしていることもあり、インストールパスが揃っていないと検証に失敗します。
Azure CLI のインストールとバージョン統一
対処の基本は次の 3 点です。
- 全ノードに Azure CLI をインストールする
- バージョンを揃える（できれば同一バージョン）
- インストールパスを揃える（特定パス前提のスクリプトがある場合）
インストール後は、各ノードで次のコマンドを実行して確認します。
az version
where az <# Windows の場合 #>
もし既存のデプロイスクリプトが 特定のパス を前提にしている場合は、
- そのパスに合わせて Azure CLI をインストールし直す
- またはスクリプト側で参照パスを修正する
といったいずれかの対応が必要になります。クラスターのノード台数が多いほど、この「パスのばらつき」が地味に効いてくるので、標準 OS イメージの段階で Azure CLI のバージョンとパスを決めておくと運用が楽になります。
ARM テンプレート / Bicep で検証タスクを可視化する
ポータルより ARM テンプレートを推奨する理由
Azure ポータルのウィザードは便利ですが、「Not Validated」の理由までは深掘りしてくれません。一方、ARM テンプレートや Bicep を使ったデプロイでは、
- 検証タスクごとの結果がデプロイ履歴に詳細に残る
- エラーになったタスク名（ValidateArcIntegration など）がはっきり分かる
- 再実行が容易（パラメータを変えて何度でも試せる）
といったメリットがあります。そのため、本番構成に近いテンプレートを一つ用意しておき、検証時は必ずそれを使うという運用スタイルをおすすめします。
デプロイ結果からエラーを読むポイント
テンプレートデプロイが失敗した場合、Azure ポータルの「デプロイメント」画面から該当のデプロイを開き、「出力」や「操作の詳細」を確認します。「失敗した操作」を辿っていくと、どの検証タスクで止まっているかが見えてきます。
また、サーバー側には次のようなパスに詳細ログが残っていることが多いです。
C:\CloudDeployment\ECEngine\...C:\NugetStore\AzStackHci.EnvironmentChecker...
どの検証クラスで落ちているのか、どのコマンドが失敗しているのかを追うことで、ポータルでは見えない「本当の原因」に近づけます。
実務で使えるチェックリスト
ここまでの内容を、「実際に現場で使えるチェックリスト」に落とし込んでみます。クラスターごとに 1 回、この表を埋めるイメージで確認すると早期に問題を洗い出せます。
| 項目 | チェック内容 | 確認方法 / コマンド例 |
|---|---|---|
| Arc 接続 | 全ノードが Azure Arc で Connected／Agent 最新 | Azure ポータル > Azure Arc > Azure Local > 対象サーバー |
| RBAC ロール | デプロイ主体に必要ロール（Azure Stack HCI Device Management, Azure Connected Machine 系, Reader 等）が適切スコープで付与 | ポータルの「アクセス制御 (IAM)」で確認 |
| リソース プロバイダー | Microsoft.AzureStackHCI / Microsoft.HybridCompute / Microsoft.GuestConfiguration などが登録済み | サブスクリプション > リソース プロバイダー または PowerShell / Azure CLI |
| Azure Policy | 拡張機能のインストールやリージョン制限など、デプロイを妨げるポリシーがない | ポリシーのコンプライアンス ステータスを確認 |
| OS 更新（KB） | 要求 KB（例：KB5053599）が全ノードに適用済みで、再起動も完了 | Get-HotFix で KB の有無を確認 |
| Azure CLI | 全ノードに Azure CLI がインストールされ、バージョンとインストールパスが統一 | az version / where az で確認 |
| サブスクリプション コンテキスト | PowerShell / Azure CLI のコンテキストが対象サブスクリプションになっている | Get-AzContext / az account show |
| 検証タスク結果 | ARM テンプレート デプロイで全検証タスクが成功 | テンプレートデプロイの「出力」「操作の詳細」 |
運用のコツと設計時に意識したいポイント
「ポータルで Not Validated → ARM で詳細」をテンプレ化する
問題発生時、ポータルだけで悩み続けると時間を浪費します。チーム内の運用ルールとして、次のフローをあらかじめ決めておくとトラブルシュートがスムーズになります。
- ポータルで「Not Validated」を確認したら、深追いせず「原因調査モード」に切り替える
- 同じ構成を ARM テンプレート／Bicep でデプロイし、エラーになった検証タスク名を特定
- タスク名ごとに「Arc / RBAC」「OS レシピ」「CLI / ツール」など担当チームを割り振る
ロール名・表記ゆれに注意する
Azure のロール名は、テナントの言語設定やドキュメントの世代によって微妙に表記が異なることがあります。そのため、
- メモや記事のロール名をそのまま鵜呑みにしない
- 実際にポータルの「ロールの割り当て」画面で検索し、存在する組み込みロール名を選択する
といった運用を徹底することで、「名前が似ている別ロールを付けてしまった」という事故を防げます。
標準 OS イメージに「必須 KB」と「CLI」を組み込んでおく
毎回ノードごとに KB の適用や Azure CLI のインストールを行っていると、どうしても漏れやバージョン違いが発生します。特に Azure Local（Azure Stack HCI）のように、
- ノード数が多く、
- 検証要件が細かく決まっている
環境では、標準 OS イメージの段階で「必須 KB」や「Azure CLI」を組み込んでおくのが得策です。これにより、
- 新規ノード追加時にも同じ条件で検証に臨める
- 検証失敗時の原因がハードウェアやネットワークに絞りやすくなる
といったメリットが得られます。
再検証〜再デプロイまでのおすすめフロー
最後に、実際にトラブルが発生してから解消するまでの流れを、ひとまとめにしておきます。
- Arc 接続の健全性確認
- 全ノードの Status=Connected / Agent 最新を確認
- ARM テンプレートで検証タスクを実行
- ポータルではなくテンプレートデプロイを使い、失敗タスク名（ValidateArcIntegration / ValidateOSImageRecipe など）を特定
- ValidateArcIntegration 対応
- 必要ロールの付与（Azure Stack HCI Device Management、Azure Connected Machine 系、Reader）
- リソース プロバイダー登録（Microsoft.AzureStackHCI / Microsoft.HybridCompute など）
- Azure Policy の影響を確認し、必要に応じて一時的に除外
- PowerShell / Azure CLI のサブスクリプション コンテキストを確認・修正
- ValidateOSImageRecipe 対応（KB / CLI）
- 必須 KB（例：KB5053599）を全ノードに適用し、再起動
- Azure CLI を全ノードにインストールし、バージョン・パスを統一
- 再検証
- ARM テンプレートで再度検証タスクを実行し、すべて成功することを確認
- ポータルからの再デプロイ
- ポータルのウィザードでノードが「Validated」と表示され、クラスター作成が完了することを確認
まとめ：4 つの落とし穴を押さえておく
Azure Local（Azure Stack HCI）クラスターのデプロイ時に、ポータルで「Not Validated」と表示される裏側には、複数の検証タスクが動いています。特に実務でトラブルの原因になりやすいのは、次の 4 点です。
- Azure Arc 接続の健全性（Connected / Agent 最新）
- RBAC とリソース プロバイダー登録（ValidateArcIntegration の主因）
- OS レシピ準拠（特定 KB の適用）（ValidateOSImageRecipe の主因）
- Azure CLI の存在とパス統一（ValidateOSImageRecipe でのパス不一致エラー）
ポータルだけを眺めていても原因が見えにくいため、まずは ARM テンプレートで 失敗タスク名を確定し、上記のチェックリストに沿って是正していく――という運用スタイルに切り替えることで、問題切り分けのスピードと再現性が大きく向上します。
本記事の内容を、自組織の標準手順書や Runbook に落とし込むことで、将来のトラブル時にも「誰が見ても同じ手順で原因を特定できる」状態にしておくと、Azure Local（Azure Stack HCI）基盤の安定運用につながります。
コメント