Azure Local／Azure Stack HCI｜KB5063899 Readiness Check「Test RP registrations…」エラーの原因と解決（Microsoft.Attestation 登録必須化への対応）

Azure Local（Azure Stack HCI／Arc 統合環境）で 2025 年 8 月の累積更新（KB5063899）を適用しようとした際、Readiness Check にて Test RP registrations are present in the subscription が発生し更新が進まない事象が各所で見られます。本記事では原因の本質と、確実に通過させるための実運用手順・自動化スクリプト・ベストプラクティスをまとめます。

現象の概要

Azure Local（Azure Stack HCI クラスターを Azure Arc に登録して運用している構成）で、2025.08 累積更新プログラム（KB5063899）の適用前に実行される Readiness Check が失敗し、次のエラーが表示されます。

Test RP registrations are present in the subscription

2025.07 更新（例：Solution 11.2507.1001.9）までは同じ手順で問題なく通過していた環境でも、2025.08 以降は当該テストが強化され、必須のリソースプロバイダー（Resource Provider; RP）が 1 つでも未登録だと失敗する挙動になっています。特に Microsoft.Attestation が未登録のサブスクリプションで高確率に再現します。

なぜ失敗するのか（原因）

Microsoft.Attestation リソースプロバイダーが未登録である。
2025.08 更新以降、Azure Local/Arc 環境の 必須 RP の登録検証が厳格化され、Attestation を含む必要最小限の RP がすべて Registered でない場合に Readiness Check がエラー判定となる。

これにより、以前の更新で見逃されていた軽微な未整備（RP 未登録）が、2025.08 以降は明示的なブロッカーとして扱われるようになりました。

2025.08 時点の必須リソースプロバイダー一覧

Readiness Check が前提とする必須 RP（2025 年 8 月時点）は以下のとおりです。名称は Provider Namespace をそのまま記載しています。

Provider Namespace	主な役割／Azure Local との関係	備考
`Microsoft.Attestation`	ワークロードや構成状態のアテステーションに関与。準拠性チェックの基盤として参照される。	今回のエラーの主因となりやすい。
`Microsoft.GuestConfiguration`	Azure Policy の Guest Configuration 機能（OS 構成評価）を提供。	Arc 拡張との連携で利用。
`Microsoft.HybridCompute`	Arc 対応サーバー（Windows/Linux）を Azure リソースとして扱う基盤。	Azure Local の中核 RP。
`Microsoft.HybridConnectivity`	ハイブリッド接続のためのエンドポイント管理。	安全な制御プレーン接続に関与。
`Microsoft.ResourceConnector`	オンプレ資産を Azure に接続するためのコネクタ。	Azure Local 登録時に利用。
`Microsoft.Kubernetes`	Arc 対応 Kubernetes クラスタのリソース化。	クラスター管理・拡張配布で必要。
`Microsoft.KubernetesConfiguration`	GitOps 等のクラスター構成適用。	アプリ配布・構成適用で利用。
`Microsoft.ExtendedLocation`	Custom Location（Azure とオンプレの橋渡し）を提供。	Arc/HCI 連携の要点。
`Microsoft.HybridContainerService`	ハイブリッドなコンテナ基盤の管理。	Kubernetes 関連の一部シナリオで必要。
`Microsoft.AzureStackHCI`	Azure Stack HCI リソース管理のための RP。	Azure Local のコア RP。

上表は 2025.08 時点の要件に基づくもので、将来変更される可能性があります。運用ドキュメントや自動化スクリプトには、要件の更新に追随できる仕組み（例：配列の外部定義化）を取り入れると安全です。

すぐに解決するための手順（最短ルート）

1. 現在の登録状態を確認する

まずは Azure にサインインし、Attestation RP の登録状態を確認します。

Connect-AzAccount -SubscriptionId <SUBSCRIPTION_ID> -TenantId <TENANT_ID> -DeviceCode
Get-AzResourceProvider -ProviderNamespace Microsoft.Attestation

RegistrationState : NotRegistered と表示されたら未登録です。

2. 不足している RP を登録する

Owner もしくは Contributor ロールが必要です。Attestation のみ登録する場合：

Register-AzResourceProvider -ProviderNamespace Microsoft.Attestation

一括登録が必要なら以下の配列で登録します（2025.08 時点の必須セット）。

$mandatory = @(
  "Microsoft.Attestation",
  "Microsoft.GuestConfiguration",
  "Microsoft.HybridCompute",
  "Microsoft.HybridConnectivity",
  "Microsoft.ResourceConnector",
  "Microsoft.Kubernetes",
  "Microsoft.KubernetesConfiguration",
  "Microsoft.ExtendedLocation",
  "Microsoft.HybridContainerService",
  "Microsoft.AzureStackHCI"
)
foreach ($rp in $mandatory) {
    Register-AzResourceProvider -ProviderNamespace $rp
}

3. 登録完了を確認し、Readiness を再実行する

登録は非同期です。以下で Registered になるまで待機し、完了後に Readiness Check を再実行します。

Get-AzResourceProvider -ProviderNamespace Microsoft.Attestation
# 出力の RegistrationState が Registered であることを確認

Attestation を含む必須 RP がすべて Registered なら、Readiness Check は正常に通過し、KB5063899 の適用が可能になります。

運用で差がつく：堅牢なチェック＆自動化テンプレート

事前健全性チェックの自動化（PowerShell 完全版）

メンテ実施前に 未登録 RP を検出→登録→安定化待ち→結果サマリ までを自動で行うスクリプトの例です。CI/CD、Azure Automation、タスクスケジューラ等に組み込むことで、ヒューマンエラーを根絶できます。

# 事前条件:
# - Az.Accounts / Az.Resources モジュール
# - Owner または Contributor 権限
param(
  [Parameter(Mandatory=$true)][string]$SubscriptionId,
  [Parameter(Mandatory=$true)][string]$TenantId,
  [int]$TimeoutSec = 600,
  [int]$PollIntervalSec = 10
)

$mandatory = @(
"Microsoft.Attestation",
"Microsoft.GuestConfiguration",
"Microsoft.HybridCompute",
"Microsoft.HybridConnectivity",
"Microsoft.ResourceConnector",
"Microsoft.Kubernetes",
"Microsoft.KubernetesConfiguration",
"Microsoft.ExtendedLocation",
"Microsoft.HybridContainerService",
"Microsoft.AzureStackHCI"
)

Write-Host "Connecting to Azure..."
Connect-AzAccount -SubscriptionId $SubscriptionId -TenantId $TenantId -DeviceCode | Out-Null

$results = @()
foreach ($rp in $mandatory) {
$info = Get-AzResourceProvider -ProviderNamespace $rp -ErrorAction SilentlyContinue
$state = $info.RegistrationState
if (-not $state) { $state = "Unknown" }

if ($state -ne "Registered") {
Write-Host "Registering $rp (current: $state)"
Register-AzResourceProvider -ProviderNamespace $rp | Out-Null
} else {
Write-Host "$rp is already Registered"
}
}

# 安定化待ち

$deadline = (Get-Date).AddSeconds($TimeoutSec)
do {
Start-Sleep -Seconds $PollIntervalSec
$allOk = $true
$results = @()

foreach ($rp in $mandatory) {
$info = Get-AzResourceProvider -ProviderNamespace $rp -ErrorAction SilentlyContinue
$state = $info.RegistrationState
if (-not $state) { $state = "Unknown" }
$results += [pscustomobject]@{ Provider = $rp; RegistrationState = $state }
if ($state -ne "Registered") { $allOk = $false }

}

$now = Get-Date
Write-Host "[$($now.ToString('s'))] Registration progress:"
$results | Format-Table -AutoSize
} while (-not $allOk -and (Get-Date) -lt $deadline)

if (-not $allOk) {
Write-Error "Some providers did not reach 'Registered' within timeout."
exit 1
}

Write-Host "All mandatory providers are Registered."
$results | Format-Table -AutoSize

複数サブスクリプションを一括整備する場合

管理グループ配下の全サブスクリプションに対して適用する運用も一般的です。次の例では、ログイン済みコンテキストで列挙したすべてのサブスクリプションを対象に、一括登録を行います。

$mandatory = @(
  "Microsoft.Attestation",
  "Microsoft.GuestConfiguration",
  "Microsoft.HybridCompute",
  "Microsoft.HybridConnectivity",
  "Microsoft.ResourceConnector",
  "Microsoft.Kubernetes",
  "Microsoft.KubernetesConfiguration",
  "Microsoft.ExtendedLocation",
  "Microsoft.HybridContainerService",
  "Microsoft.AzureStackHCI"
)

$subs = Get-AzSubscription
foreach ($sub in $subs) {
Write-Host "Processing Subscription: $($sub.Name) [$($sub.Id)]"
Set-AzContext -SubscriptionId $sub.Id | Out-Null

foreach ($rp in $mandatory) {
$state = (Get-AzResourceProvider -ProviderNamespace $rp -ErrorAction SilentlyContinue).RegistrationState
if ($state -ne "Registered") {
Write-Host "  Registering $rp (current: $state)"
Register-AzResourceProvider -ProviderNamespace $rp | Out-Null
} else {
Write-Host "  $rp already Registered"
}
}
}

Azure CLI で実施したい場合

PowerShell に加え、Azure CLI でも同等の操作が可能です。自動化の都合で CLI を選ぶ現場も多いため、対となるコマンドを併記します。

# ログイン
az login --tenant <TENANT_ID>
az account set --subscription <SUBSCRIPTION_ID>

# 登録状態の確認

az provider show -n Microsoft.Attestation --query "registrationState" -o tsv

# 登録

az provider register -n Microsoft.Attestation

# 一括登録（Bash）

mandatory=(
Microsoft.Attestation
Microsoft.GuestConfiguration
Microsoft.HybridCompute
Microsoft.HybridConnectivity
Microsoft.ResourceConnector
Microsoft.Kubernetes
Microsoft.KubernetesConfiguration
Microsoft.ExtendedLocation
Microsoft.HybridContainerService
Microsoft.AzureStackHCI
)
for rp in "${mandatory[@]}"; do
az provider register -n "$rp"
done

# 登録完了の確認

for rp in "${mandatory[@]}"; do
echo -n "$rp: "
az provider show -n "$rp" --query "registrationState" -o tsv
done

ロールと権限（何の権限が必要か）

RP 登録（Microsoft.Resources/register/action）は、Owner および Contributor が既定で許可を持ちます。Reader では不可です。カスタムロールを使用している場合、当該アクションが含まれているかを確認してください。

操作	必要なアクション	既定で許可する代表的なロール
RP の登録	`Microsoft.Resources/register/action`	Owner, Contributor
登録状態の参照	`Microsoft.Resources/providers/read`	Reader 以上

ポリシー／ガバナンス上の注意点

Allowed Resource Providers ポリシーを使って許可 RP を制限している場合、Microsoft.Attestation を許可リストに含めていないと登録が Deny されます。運用前に必ず見直してください。
Blueprint やポリシーイニシアティブで RP の自動登録を阻害していないか確認します。Deny ルールがあると、Register-AzResourceProvider が AuthorizationFailed 相当のエラーで失敗します。

割り当て状況の確認例（参考）：

# サブスクリプション配下のポリシー割り当てを列挙
Get-AzPolicyAssignment -Scope "/subscriptions/<SUBSCRIPTION_ID>" | 
  Select-Object Name, PolicyDefinitionId, EnforcementMode

ネットワーク／プロキシに関する補足

Readiness Check に missing proxy server の警告が残る場合でも、Attestation RP を含む必須 RP が Registered であれば更新は進行できます。プロキシ警告のみを理由に中断する必要はありません。
ただし、Azure Resource Manager への到達性や認証エンドポイントへの接続要件は別途満たす必要があります。更新作業ウィンドウの前に通信要件を棚卸しし、監視で活性を追うのが無難です。

トラブルの見極めポイント（現場チェックリスト）

対象サブスクリプションが正しいか：Readiness を実行しているコンテキストの SubscriptionId が、HCI クラスターが登録されているサブスクリプションと一致しているか。
Attestation が Registered か：Get/az provider show の結果で Registered か。
他の必須 RP も Registered か：表の 10 個すべてを確認。
ポリシーで Deny されていないか：Allowed Resource Providers 等の制御を確認。
権限は十分か：Owner/Contributor で実行しているか。
登録反映の遅延を考慮：登録後すぐに Readiness を再実行して失敗する場合があるため、数分待機のうえ再試行。

ログ観点：失敗時に追うべき手がかり

現場での一次切り分けでは、次の情報が役立ちます。

Readiness 実行ログ（更新オーケストレーター／運用ツールの実行ログ）。
Azure Activity Log（サブスクリプション範囲）：Microsoft.Resources/register/action の成功／失敗履歴。
ポリシーの評価結果（Deny / Audit のヒット）。

「RP を登録済みなのに失敗する」ケースでは、Activity Log に register 成功が出ているか／出ていないかが分岐点です。成功しているのに Readiness が失敗するなら、登録直後で反映が及んでいない、または コンテキスト相違（別サブスクリプションで評価している） の可能性が高いです。

「それでも通らない」時の代替アプローチ

再評価の強制：運用ツール側に再評価・再スキャンがあれば明示的に実行します。
別クライアントで再試行：権限・ネットワークがよりシンプルなコンソール（例：運用用ジャンプボックス）で試すと周辺要因を除去できます。
クラウド環境の確認：Azure Government / China などソブリンクラウドでは Connect-AzAccount -Environment <CloudName> の指定忘れが典型ミスです。

更新作業の標準フロー（テンプレ化推奨）

事前ウィンドウ（T-7〜T-1 日）：自動化スクリプトで必須 RP を検査・補正。結果サマリを保存（変更管理台帳）。
当日開始前（T 時刻 60〜30 分前）：もう一度クイックヘルスチェック。Registered が揃っているか最終確認。
Readiness 実行：プロキシ警告のみであれば継続。ブロッカーがあれば直ちに解消。
KB5063899 適用：計画手順に沿って実行。適用後の状態確認を行い、クラスター健全性・Arc 接続・ワークロードを検証。
事後レビュー：Activity Log と実行ログを保存。次回以降の自動化にフィードバック。

FAQ（よくある質問）

Q. 登録済み表示だが Readiness が失敗する

A. 登録直後は内部キャッシュの関係で評価が反映されるまで数分かかる場合があります。数分待って再試行してください。評価コンテキスト（サブスクリプション／テナント）が期待どおりかも再確認を。

Q. どのロールを付与すれば良い？

A. 基本は Contributor（または Owner）。カスタムロールの場合は Microsoft.Resources/register/action が含まれるよう定義してください。

Q. 政府機関クラウド／中国クラウドでも同じ？

A. RP 名称や登録操作の基本は同じですが、サインイン先クラウド（-Environment）や到達先エンドポイントが異なります。該当クラウドを明示してサインインし、必要なネットワーク許可を満たしてください。

Q. Proxy の警告が残る

A. 本件のブロッカーは RP 未登録です。Proxy 警告だけが残っていても、必須 RP が Registered なら更新は継続可能です。

セキュリティとチェンジ管理の観点

最小権限の徹底：RP 登録だけを切り出した自動化で、必要最小の期間・範囲で権限を付与しましょう。
監査証跡の保存：Activity Log の register イベントと実行ログを証跡として保管します。
手順書の更新：2025.08 以降は Attestation RP の登録の必須化 を手順書に明記し、チェックを標準化します。

まとめ

2025.08 累積更新（KB5063899）で Readiness Check が Test RP registrations are present in the subscription により失敗する原因の大半は、Microsoft.Attestation を含む必須リソースプロバイダーの未登録です。Register-AzResourceProvider（または az provider register）で不足を解消し、Registered になるまで待機してから再評価すれば、更新は正常に進みます。更新のたびに迷わないために、事前健全性チェックの自動化・ポリシー／権限の整備・手順書への明記を標準化しましょう。

参考：本記事で使用したコマンド（再掲）

PowerShell

Connect-AzAccount -SubscriptionId <SUBSCRIPTION_ID> -TenantId <TENANT_ID> -DeviceCode
Get-AzResourceProvider -ProviderNamespace Microsoft.Attestation
Register-AzResourceProvider -ProviderNamespace Microsoft.Attestation

$mandatory = @(
"Microsoft.Attestation",
"Microsoft.GuestConfiguration",
"Microsoft.HybridCompute",
"Microsoft.HybridConnectivity",
"Microsoft.ResourceConnector",
"Microsoft.Kubernetes",
"Microsoft.KubernetesConfiguration",
"Microsoft.ExtendedLocation",
"Microsoft.HybridContainerService",
"Microsoft.AzureStackHCI"
)
foreach ($rp in $mandatory) {
Register-AzResourceProvider -ProviderNamespace $rp
}

Azure CLI

az login --tenant <TENANT_ID>
az account set --subscription <SUBSCRIPTION_ID>
az provider show -n Microsoft.Attestation --query "registrationState" -o tsv
az provider register -n Microsoft.Attestation

現場で使えるチェックサマリ（貼り出し用）

確認項目	期待値	確認コマンドの例
サブスクリプションの特定	HCI クラスター登録先と一致	`Get-AzContext` / `az account show`
Attestation 登録状態	Registered	`Get-AzResourceProvider -ProviderNamespace Microsoft.Attestation`
必須 RP の網羅	10/10 が Registered	表の配列で総当たり確認
ポリシー干渉	Deny なし	`Get-AzPolicyAssignment` で確認
権限	Owner/Contributor	ロール割り当て確認
Readiness のリトライ	登録反映後に再実行	数分待機のうえ再評価

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

Azure Local／Azure Stack HCI｜KB5063899 Readiness Check「Test RP registrations…」エラーの原因と解決（Microsoft.Attestation 登録必須化への対応）

現象の概要

なぜ失敗するのか（原因）

2025.08 時点の必須リソースプロバイダー一覧

すぐに解決するための手順（最短ルート）

1. 現在の登録状態を確認する

2. 不足している RP を登録する

3. 登録完了を確認し、Readiness を再実行する

運用で差がつく：堅牢なチェック＆自動化テンプレート

事前健全性チェックの自動化（PowerShell 完全版）

複数サブスクリプションを一括整備する場合

Azure CLI で実施したい場合

ロールと権限（何の権限が必要か）

ポリシー／ガバナンス上の注意点

ネットワーク／プロキシに関する補足

トラブルの見極めポイント（現場チェックリスト）

ログ観点：失敗時に追うべき手がかり

「それでも通らない」時の代替アプローチ

更新作業の標準フロー（テンプレ化推奨）

FAQ（よくある質問）

Q. 登録済み表示だが Readiness が失敗する

Q. どのロールを付与すれば良い？

Q. 政府機関クラウド／中国クラウドでも同じ？

Q. Proxy の警告が残る

セキュリティとチェンジ管理の観点

まとめ

参考：本記事で使用したコマンド（再掲）

PowerShell

Azure CLI

現場で使えるチェックサマリ（貼り出し用）

この記事を書いた人

コメント

コメントするコメントをキャンセル

Azure Local／Azure Stack HCI｜KB5063899 Readiness Check「Test RP registrations…」エラーの原因と解決（Microsoft.Attestation 登録必須化への対応）

現象の概要

なぜ失敗するのか（原因）

2025.08 時点の必須リソースプロバイダー一覧

すぐに解決するための手順（最短ルート）

1. 現在の登録状態を確認する

2. 不足している RP を登録する

3. 登録完了を確認し、Readiness を再実行する

運用で差がつく：堅牢なチェック＆自動化テンプレート

事前健全性チェックの自動化（PowerShell 完全版）

複数サブスクリプションを一括整備する場合

Azure CLI で実施したい場合

ロールと権限（何の権限が必要か）

ポリシー／ガバナンス上の注意点

ネットワーク／プロキシに関する補足

トラブルの見極めポイント（現場チェックリスト）

ログ観点：失敗時に追うべき手がかり

「それでも通らない」時の代替アプローチ

更新作業の標準フロー（テンプレ化推奨）

FAQ（よくある質問）

Q. 登録済み表示だが Readiness が失敗する

Q. どのロールを付与すれば良い？

Q. 政府機関クラウド／中国クラウドでも同じ？

Q. Proxy の警告が残る

セキュリティとチェンジ管理の観点

まとめ

参考：本記事で使用したコマンド（再掲）

PowerShell

Azure CLI

現場で使えるチェックサマリ（貼り出し用）

この記事を書いた人

関連記事

コメント

コメントする コメントをキャンセル

コメントするコメントをキャンセル