Azure Local 2411 リリースの既知の問題
適用対象: Azure Local バージョン 23H2
この記事では、Azure Local 2411 リリースの重大な既知の問題とその回避策について説明します。
これらのリリース ノートは継続的に更新され、回避策を必要とする重大な問題が検出されると、追加されます。 Azure ローカル インスタンスをデプロイする前に、ここに含まれている情報を慎重に確認してください。
重要
このリリースでサポートされている更新プログラムのパスについては、「 リリース情報を参照してください。
このリリースの新機能の詳細については、 23H2 の新機能を参照してください。
バージョン 2411 の既知の問題
このソフトウェア リリースは、ソフトウェア バージョン番号 2411.0.22 にマップされます。
このバージョンのリリース ノートには、このリリースで修正された問題、このリリースの既知の問題、以前のバージョンから引き継がれたリリース ノートの問題が含まれます。
Note
一般的な既知の問題の詳細な修復については、 Azure Local Supportability GitHub リポジトリを参照してください。
修正された問題
このリリースでは、次の問題が修正されています。
| 機能 | 問題 | 回避策/コメント |
|---|---|---|
| Arc VM の管理 | 移行された VM でゲスト管理を有効にしようとすると、操作は次のエラーで失敗します。 (InternalError) 受付 Webhook "createupdatevalidationwebhook.infrastructure.azstackhci.microsoft.com" は要求を拒否しました。リソースの作成後に OsProfile を変更することはできません |
このリリースの既知の問題
次の表に、このリリースの既知の問題を示します。
| 機能 | 問題点 | 回避策 |
|---|---|---|
| セキュリティの脆弱性 | Microsoft は、Azure Local での Arc VM の作成時に使用されるローカル管理者資格情報を、VM 上およびホスト上の管理者以外のユーザーに公開する可能性があるセキュリティの脆弱性を特定しました。 Azure Local 2411 リリースより前のリリースで実行されている Arc VM は脆弱です。 |
この変更を必要とする Arc VM を特定し、アカウント パスワードを変更するには、「 Azure Local での Arc VM のセキュリティの監視」の詳細な手順を参照してください。 |
| デプロイ | Azure Local をデプロイする前にタイムゾーンが UTC に設定されていない場合、検証中に ArcOperationTimeOut エラーが発生します。 次のエラー メッセージが表示されます: OperationTimeOut、操作のためにデバイスから更新プログラムを受信しません。 | シナリオに応じて、この問題に対して次のいずれかの回避策を選択します。 シナリオ 1. デプロイを開始する前に、タイムゾーンが UTC に設定されていることを確認します。 各 Azure ローカル ノードに接続し、タイムゾーンを UTC に変更します。 コマンド Set-TimeZone -Id "UTC" を実行します。 シナリオ 2. UTC タイムゾーンを設定せずにデプロイを開始し、検証フェーズで説明したエラーを受け取った場合は、次の手順に従います。 1. 各 Azure ローカル ノードに接続します。 Set-TimeZone -Id "UTC"でタイム ゾーンを UTC に変更します。 ノードを再起動します。2. ノードが再起動したら、Azure portal の Azure ローカル リソースに移動します。 もう一度検証を開始して問題を解決し、デプロイを続行します。 |
| を更新する | 2411 リリースでは、ソリューションとソリューション ビルダー拡張機能の更新プログラムは、1 回の更新実行では結合されません。 | ソリューション ビルダー拡張機能パッケージを適用するには、別の更新プログラムを実行する必要があります。 |
| を更新する | このリリースでソリューション更新プログラムを適用すると、更新が失敗する可能性があります。 エラーの原因となる問題により、次のいずれかのエラー メッセージが表示される可能性があります。 エラー 1 - ステップ "ARB と拡張機能の更新" エラー "Clear-AzContext failed with 0 and Exception calling "Initialize" with "1" argument(s): "Object reference not set to an instance of an object." at "Clear-AzPowerShellCache". エラー 2 - ステップ "EvalTVMFlow" エラー "CloudEngine.Actions.InterfaceInvocationFailedException: ロール 'ArcIntegration' の型 'EvalTVMFlow' で例外が発生しました:このモジュールでは、バージョン 3.0.5 Az.Accounts 必要です。 以前のバージョンの Az.Accounts は、現在の PowerShell セッションにインポートされます。 このモジュールをインポートする前に、新しいセッションを開いてください。 このエラーは、互換性のない複数のバージョンの Azure PowerShell コマンドレットがシステム上にインストールされていることを示している可能性があります。 トラブルシューティング情報については、 https://aka.ms/azps-version-error を参照してください。PowerShell モジュールのバージョンによっては、上記のエラーがバージョン 3.0.4 と 3.0.5 の両方で報告される可能性があります。 |
この問題を軽減する方法の詳細な手順については、「 https://aka.ms/azloc-update-30221399」を参照してください。 |
以前のリリースの既知の問題
次の表に、以前のリリースの既知の問題を示します。
| 機能 | 問題点 | 回避策 | ||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| サーバーの修復 | ノードを修復してコマンド Set-AzureStackLCMUserPasswordを実行すると、次のエラーが発生する可能性があります。 CloudEngine.Actions.InterfaceInvocationFailedException: Type 'ValidateCredentials' of Role 'SecretRotation' raised an exception: Cannot load encryption certificate. The certificate setting 'CN=DscEncryptionCert' does not represent a valid base-64 encoded certificate, nor does it represent a valid certificate by file, directory, thumbprint, or subject name. at Validate-Credentials |
問題を軽減するには、次の手順に従います。$NewPassword = <Provide new password as secure string> $OldPassword = <Provide the old/current password as secure string> $Identity = <LCM username> $credential = New-Object -TypeName PSCredential -ArgumentList $Identity, $NewPassword 1. 必要なモジュールをインポートします。 Import-Module "C:\Program Files\WindowsPowerShell\Modules\Microsoft.AS.Infra.Security.SecretRotation\PasswordUtilities.psm1" -DisableNameChecking 2. ECE クラスター グループの状態を確認します。 $eceClusterGroup = Get-ClusterGroup | Where-Object {$_.Name -eq "Azure Stack HCI Orchestrator Service Cluster Group"} if ($eceClusterGroup.State -ne "Online") {Write-AzsSecurityError -Message "ECE cluster group is not in an Online state. Cannot continue with password rotation." -ErrRecord $_} 3. 新しいパスワードで ECE を更新します。 Write-AzsSecurityVerbose -Message "Updating password in ECE" -Verbose $eceContainersToUpdate = @("DomainAdmin", "DeploymentDomainAdmin", "SecondaryDomainAdmin", "TemporaryDomainAdmin", "BareMetalAdmin", "FabricAdmin", "SecondaryFabric", "CloudAdmin") <br><br> foreach ($containerName in $eceContainersToUpdate) {Set-ECEServiceSecret -ContainerName $containerName -Credential $credential 3>$null 4>$null} <br><br> Write-AzsSecurityVerbose -Message "Finished updating credentials in ECE." -Verbose 4. Active Directory のパスワードを更新します。 Set-ADAccountPassword -Identity $Identity -OldPassword $OldPassword -NewPassword $NewPassword |
||||||||||||||||||
| Arc VM の管理 | エクスポートした Azure VM OS ディスクを VHD として使用して、Arc VM をプロビジョニングするためのギャラリー イメージを作成することはサポートされていません。 | コマンド restart-service mochostagent を実行して、mochostagent サービスを再起動します。 |
||||||||||||||||||
| ネットワーク | HTTPS://10.100.000.00:8080など、アドレスに大文字が含まれるプロキシ サーバーでノードが構成されている場合、Arc 拡張機能は、バージョン 2408.1 を含む既存のビルドのノードにインストールまたは更新できません。 ただし、ノードは Arc 接続されたままです。 | 問題を軽減するには、次の手順に従います。 1. 環境の値を小文字で設定します。 [System.Environment]::SetEnvironmentVariable("HTTPS_PROXY", "https://10.100.000.00:8080", "Machine"). 2. 値が設定されたことを検証します。 [System.Environment]::GetEnvironmentVariable("HTTPS_PROXY", "Machine"). 3. Arc サービスを再起動します。 Restart-Service himds Restart-Service ExtensionService Restart-Service GCArcService 4. AzcmaAgent に小文字のプロキシ情報を通知します。 & 'C:\Program Files\AzureConnectedMachineAgent\azcmagent.exe' config set proxy.url https://10.100.000.00:8080 & 'C:\Program Files\AzureConnectedMachineAgent\azcmagent.exe' config list |
||||||||||||||||||
| ネットワーク | Arc マシンがダウンすると、新しいポータル エクスペリエンスの [すべてのクラスター] ページに 、"PartiallyConnected" または "接続されていない最近 状態が表示されます。 Arc マシンが正常になった場合でも、"Connected" 状態が表示されないことがあります。 | この問題の既知の回避策はありません。 接続状態を確認するには、以前のエクスペリエンスを使用して、"Connected" と表示されているかどうかを確認します。 | ||||||||||||||||||
| セキュリティ | SideChannelMitigation セキュリティ機能が有効になっている場合でも、有効な状態が表示されない場合があります。 | このリリースには回避策はありません。 この問題が発生した場合は、Microsoft サポートに連絡して次の手順を確認してください。 | ||||||||||||||||||
| Arc VM の管理 | Mochostagent サービスは実行中のように見えますが、ログを更新せずに 1 か月以上停止する可能性があります。 この問題を特定するには、 C:\programdata\mochostagent\logs のサービス ログを確認して、ログが更新されているかどうかを確認します。 |
mochostagent サービスを再起動するには、次のコマンドを実行します: restart-service mochostagent。 |
||||||||||||||||||
| アップグレード | スタンプを 2311 以前のビルドから 2408 以降にアップグレードすると、ノードの追加とノードの修復操作が失敗する可能性があります。 たとえば、 Type 'AddAsZHostToDomain' of Role 'BareMetal' raised an exceptionというエラーが表示される場合があります。 |
このリリースには回避策はありません。 この問題が発生した場合は、Microsoft サポートに連絡して次の手順を確認してください。 | ||||||||||||||||||
| 更新する | Azure Update Manager を使用して Azure ローカル インスタンスの準備チェックの結果を表示する場合、同じ名前の準備チェックが複数存在する可能性があります。 | このリリースには既知の回避策はありません。 表示の詳細を選択して、準備チェックに関する特定の情報を表示します。 | ||||||||||||||||||
| デプロイ | 場合によっては、Azure ローカル マシンの登録中に、デバッグ ログに次のエラーが表示されることがあります: 内部サーバー エラー。 デバイスの展開に必須の拡張機能の 1 つがインストールされていない可能性があります。 | 問題を軽減するには、次の手順に従います。$Settings = @{ "CloudName" = $Cloud; "RegionName" = $Region; "DeviceType" = "AzureEdge" } New-AzConnectedMachineExtension -Name "AzureEdgeTelemetryAndDiagnostics" -ResourceGroupName $ResourceGroup -MachineName $env:COMPUTERNAME -Location $Region -Publisher "Microsoft.AzureStack.Observability" -Settings $Settings -ExtensionType "TelemetryAndDiagnostics" -EnableAutomaticUpgrade New-AzConnectedMachineExtension -Name "AzureEdgeDeviceManagement" -ResourceGroupName $ResourceGroup -MachineName $env:COMPUTERNAME -Location $Region -Publisher "Microsoft.Edge" -ExtensionType "DeviceManagementExtension"New-AzConnectedMachineExtension -Name "AzureEdgeLifecycleManager" -ResourceGroupName $ResourceGroup -MachineName $env:COMPUTERNAME -Location $Region -Publisher "Microsoft.AzureStack.Orchestration" -ExtensionType "LcmController" New-AzConnectedMachineExtension -Name "AzureEdgeRemoteSupport" -ResourceGroupName $ResourceGroup -MachineName $env:COMPUTERNAME -Location $Region -Publisher "Microsoft.AzureStack.Observability" -ExtensionType "EdgeRemoteSupport" -EnableAutomaticUpgrade |
||||||||||||||||||
| 更新する | このリリースでは、更新が完了しても、Azure portal によって更新状態が正しく報告されない 更新 または In progress が間違って報告される場合に、断続的な問題が発生します。 | リモート PowerShell セッションを使用して Azure ローカル インスタンスに接続します。 更新の状態を確認するには、次の PowerShell コマンドレットを実行します。$Update = get-solutionupdate| ? version -eq "<version string>"バージョン文字列を実行しているバージョンに置き換えます。 たとえば、"10.2405.0.23" などです。 $Update.state更新の状態が Installed の場合、追加の操作は必要ありません。 Azure portal では、24 時間以内に状態が正しく更新されます。 状態をより早く更新するには、いずれかのノードで次の手順を実行します。 Cloud Management クラスター グループを再起動します。 Stop-ClusterGroup "Cloud Management"Start-ClusterGroup "Cloud Management" |
||||||||||||||||||
| を更新する | MOC の初期更新中に、ターゲット MOC バージョンがカタログ キャッシュに見つからないため、エラーが発生します。 フォローアップの更新と再試行では、ターゲット バージョンで MOC が表示され、更新が成功せず、その結果、Arc Resource Bridge の更新が失敗します。 この問題を検証するには、 Azure Local バージョン 23H2 のソリューション更新プログラムを使用して更新ログを収集します。 ログ ファイルに同様のエラー メッセージが表示されます (現在のバージョンは、エラー メッセージで異なる場合があります)。 [ERROR: { "errorCode": "InvalidEntityError", "errorResponse": "{\n\"message\": \"the cloud fabric (MOC) is currently at version v0.13.1. A minimum version of 0.15.0 is required for compatibility\"\n}" }] |
問題を軽減するには、次の手順に従います。 1. MOC エージェントのバージョンを見つけるには、次のコマンドを実行します: 'C:\Program Files\AksHci\wssdcloudagent.exe' version。2. コマンドの出力を使用して、エージェントのバージョンと一致する MOC バージョンを次の表から見つけ、 $initialMocVersion その MOC バージョンに設定します。 更新先の Azure Local ビルドを見つけて、次の表から一致する MOC バージョンを取得して、 $targetMocVersion を設定します。 以下に示す軽減スクリプトでこれらの値を使用します。
たとえば、エージェントのバージョンが v0.13.0-6-gf13a73f7、v0.11.0-alpha.38,01/06/2024 の場合、 $initialMocVersion = "1.0.24.10106" し、2405.0.23 に更新する場合は、 $targetMocVersion = "1.3.0.10418"。3. 最初のノードで次の PowerShell コマンドを実行します。 $initialMocVersion = "<initial version determined from step 2>"$targetMocVersion = "<target version determined from step 2>"# MOC モジュールを 2 回インポートする import-module mocimport-module moc$verbosePreference = "Continue"# SFS カタログ キャッシュをクリアする Remove-Item (Get-MocConfig).manifestCache# 更新前にバージョンを現在の MOC バージョンに設定し、状態を更新に失敗として設定する Set-MocConfigValue -name "version" -value $initialMocVersionSet-MocConfigValue -name "installState" -value ([InstallState]::UpdateFailed)# MOC の更新を目的のバージョンに再実行する Update-Moc -version $targetMocVersion4. 更新プログラムを再開します。 |
||||||||||||||||||
| Azure ローカルでの AKS | AKS クラスターの作成は、 Error: Invalid AKS network resource idで失敗します。 この問題は、関連付けられている論理ネットワーク名にアンダースコアがある場合に発生する可能性があります。 |
論理ネットワーク名ではアンダースコアはサポートされていません。 Azure Local インスタンスにデプロイされている論理ネットワークの名前にアンダースコアを使用しないようにしてください。 | ||||||||||||||||||
| 更新する | Azure Update Manager を使用して Azure Local の準備状況チェックの結果を表示する場合、同じ名前の準備チェックが複数存在する可能性があります。 | このリリースには既知の回避策はありません。 表示の詳細を選択して、準備チェックに関する特定の情報を表示します。 | ||||||||||||||||||
| デプロイ | 場合によっては、Azure ローカル マシンの登録中に、デバッグ ログに次のエラーが表示されることがあります: 内部サーバー エラー。 デバイスの展開に必須の拡張機能の 1 つがインストールされていない可能性があります。 | 問題を軽減するには、次の手順に従います。$Settings = @{ "CloudName" = $Cloud; "RegionName" = $Region; "DeviceType" = "AzureEdge" } New-AzConnectedMachineExtension -Name "AzureEdgeTelemetryAndDiagnostics" -ResourceGroupName $ResourceGroup -MachineName $env:COMPUTERNAME -Location $Region -Publisher "Microsoft.AzureStack.Observability" -Settings $Settings -ExtensionType "TelemetryAndDiagnostics" -EnableAutomaticUpgrade New-AzConnectedMachineExtension -Name "AzureEdgeDeviceManagement" -ResourceGroupName $ResourceGroup -MachineName $env:COMPUTERNAME -Location $Region -Publisher "Microsoft.Edge" -ExtensionType "DeviceManagementExtension"New-AzConnectedMachineExtension -Name "AzureEdgeLifecycleManager" -ResourceGroupName $ResourceGroup -MachineName $env:COMPUTERNAME -Location $Region -Publisher "Microsoft.AzureStack.Orchestration" -ExtensionType "LcmController" New-AzConnectedMachineExtension -Name "AzureEdgeRemoteSupport" -ResourceGroupName $ResourceGroup -MachineName $env:COMPUTERNAME -Location $Region -Publisher "Microsoft.AzureStack.Observability" -ExtensionType "EdgeRemoteSupport" -EnableAutomaticUpgrade |
||||||||||||||||||
| 更新する | このリリースでは、更新が完了しても、Azure portal によって更新状態が正しく報告されない 更新 または In progress が間違って報告される場合に、断続的な問題が発生します。 | リモート PowerShell セッションを使用して Azure Local に接続します。 更新の状態を確認するには、次の PowerShell コマンドレットを実行します。$Update = get-solutionupdate | ? version -eq "<version string>"バージョン文字列を実行しているバージョンに置き換えます。 たとえば、"10.2405.0.23" などです。 $Update.state更新の状態が Installed の場合、追加の操作は必要ありません。 Azure portal では、24 時間以内に状態が正しく更新されます。 状態をより早く更新するには、いずれかのノードで次の手順を実行します。 Cloud Management クラスター グループを再起動します。 Stop-ClusterGroup "Cloud Management"Start-ClusterGroup "Cloud Management" |
||||||||||||||||||
| を更新する | MOC の初期更新中に、ターゲット MOC バージョンがカタログ キャッシュに見つからないため、エラーが発生します。 フォローアップの更新と再試行では、ターゲット バージョンで MOC が表示され、更新が成功せず、その結果、Arc Resource Bridge の更新が失敗します。 この問題を検証するには、 Azure Local バージョン 23H2 のソリューション更新プログラムを使用して更新ログを収集します。 ログ ファイルに同様のエラー メッセージが表示されます (現在のバージョンは、エラー メッセージで異なる場合があります)。 [ERROR: { "errorCode": "InvalidEntityError", "errorResponse": "{\n\"message\": \"the cloud fabric (MOC) is currently at version v0.13.1. A minimum version of 0.15.0 is required for compatibility\"\n}" }] |
問題を軽減するには、次の手順に従います。 1. MOC エージェントのバージョンを見つけるには、次のコマンドを実行します: 'C:\Program Files\AksHci\wssdcloudagent.exe' version。2. コマンドの出力を使用して、エージェントのバージョンと一致する MOC バージョンを次の表から見つけ、 $initialMocVersion その MOC バージョンに設定します。 更新先の Azure Local ビルドを見つけて、次の表から一致する MOC バージョンを取得して、 $targetMocVersion を設定します。 以下に示す軽減スクリプトでこれらの値を使用します。
たとえば、エージェントのバージョンが v0.13.0-6-gf13a73f7、v0.11.0-alpha.38,01/06/2024 の場合、 $initialMocVersion = "1.0.24.10106" し、2405.0.23 に更新する場合は、 $targetMocVersion = "1.3.0.10418"。3. 最初のノードで次の PowerShell コマンドを実行します。 $initialMocVersion = "<initial version determined from step 2>"$targetMocVersion = "<target version determined from step 2>"# MOC モジュールを 2 回インポートする import-module mocimport-module moc$verbosePreference = "Continue"# SFS カタログ キャッシュをクリアする Remove-Item (Get-MocConfig).manifestCache# 更新前にバージョンを現在の MOC バージョンに設定し、状態を更新に失敗として設定する Set-MocConfigValue -name "version" -value $initialMocVersionSet-MocConfigValue -name "installState" -value ([InstallState]::UpdateFailed)# MOC の更新を目的のバージョンに再実行する Update-Moc -version $targetMocVersion4. 更新プログラムを再開します。 |
||||||||||||||||||
| Azure ローカルでの AKS | AKS クラスターの作成は、 Error: Invalid AKS network resource idで失敗します。 この問題は、関連付けられている論理ネットワーク名にアンダースコアがある場合に発生する可能性があります。 |
論理ネットワーク名ではアンダースコアはサポートされていません。 Azure Local にデプロイされている論理ネットワークの名前にアンダースコアを使用しないようにしてください。 | ||||||||||||||||||
| サーバーの修復 | まれに、 Repair-Server 操作は HealthServiceWaitForDriveFW エラーで失敗します。 このような場合、修復されたノードの古いドライブは削除されず、新しいディスクはメンテナンス モードで停止します。 |
この問題を回避するには、Repair-Serverを開始する前に、Windows Admin Center または Suspend-ClusterNode -Drain PowerShell コマンドレットを使用してノードをドレインしないようにしてください。 問題が発生した場合は、次の手順についてMicrosoft サポートにお問い合わせください。 |
||||||||||||||||||
| サーバーの修復 | この問題は、単一ノードの Azure Local インスタンスが 2311 から 2402 に更新された後、 Repair-Server が実行されるときに発生します。 修復操作が失敗します。 |
単一ノードを修復する前に、次の手順に従います。 1. ADPrepTool のバージョン 2402 を実行します。 Prepare Active Directory の手順に従います。 この操作は簡単で、必要なアクセス許可を組織単位 (OU) に追加します。 2. コンピューター オブジェクトを Computers セグメントからルート OU に移動します。 次のコマンドを実行します。 Get-ADComputer <HOSTNAME> | Move-ADObject -TargetPath "<OU path>" |
||||||||||||||||||
| デプロイ | (Microsoft が提供するスクリプトと手順を使用しない) Active Directory を自分で準備した場合、Active Directory の検証が失敗し、 Generic All アクセス許可が不足している可能性があります。 これは、BitLocker 回復に必要な、 msFVE-RecoverInformationobjects – General – Permissions Full control専用のアクセス許可エントリをチェックする検証チェックの問題が原因です。 |
Prepare AD スクリプト メソッドを使用するか独自のメソッドを使用する場合は、特定のアクセス許可msFVE-RecoverInformationobjects – General – Permissions Full control割り当てるようにしてください。 |
||||||||||||||||||
| デプロイ | このリリースでは、Azure ローカル デプロイ中に DNS レコードが削除されるというまれな問題があります。 その場合、次の例外が発生します。Type 'PropagatePublicRootCertificate' of Role 'ASCA' raised an exception:<br>The operation on computer 'ASB88RQ22U09' failed: WinRM cannot process the request. The following error occurred while using Kerberos authentication: Cannot find the computer ASB88RQ22U09.local. Verify that the computer exists on the network and that the name provided is spelled correctly at PropagatePublicRootCertificate, C:\NugetStore\Microsoft.AzureStack, at Orchestration.Roles.CertificateAuthority.10.2402.0.14\content\Classes\ASCA\ASCA.psm1: line 38, at C:\CloudDeployment\ECEngine\InvokeInterfaceInternal.psm1: line 127,at Invoke-EceInterfaceInternal, C:\CloudDeployment\ECEngine\InvokeInterfaceInternal.psm1: line 123. |
DNS サーバーを調べて、ノードの DNS レコードがないかどうかを確認します。 DNS レコードがないノードに次の軽減策を適用します。 DNS クライアント サービスを再起動します。 PowerShell セッションを開き、影響を受けるノードで次のコマンドレットを実行します。 Taskkill /f /fi "SERVICES eq dnscache" |
||||||||||||||||||
| デプロイ | このリリースでは、マルチノードデプロイでリモート タスクエラーが発生し、次の例外が発生します。ECE RemoteTask orchestration failure with ASRR1N42R01U31 (node pingable - True): A WebException occurred while sending a RestRequest. WebException.Status: ConnectFailure on [https://<URL>](https://<URL>). |
軽減策は、影響を受けるノードで ECE エージェントを再起動することです。 コンピューターで PowerShell セッションを開き、次のコマンドを実行します。Restart-Service ECEAgent. |
||||||||||||||||||
| サーバーの追加 | このリリースおよび以前のリリースでは、コンピューターをシステムに追加するときに、プロキシ バイパス リスト文字列を更新して新しいマシンを含めすることはできません。 ホストで環境変数プロキシ バイパス リストを更新すると、Azure Resource Bridge または AKS のプロキシ バイパス リストは更新されません。 | このリリースには回避策はありません。 この問題が発生した場合は、Microsoft サポートに連絡して次の手順を確認してください。 | ||||||||||||||||||
| サーバーの追加/修復 | このリリースでは、マシンを追加または修復するときに、ソフトウェア ロード バランサーまたはネットワーク コントローラー VM 証明書が既存のノードからコピーされるときにエラーが発生します。 このエラーは、デプロイ/更新中にこれらの証明書が生成されなかったためです。 | このリリースには回避策はありません。 この問題が発生した場合は、Microsoft サポートに連絡して次の手順を確認してください。 | ||||||||||||||||||
| デプロイ | このリリースでは、一時的な問題が発生し、デプロイエラーが発生し、次の例外が発生します。Type 'SyncDiagnosticLevel' of Role 'ObservabilityConfig' raised an exception:*<br>*Syncing Diagnostic Level failed with error: The Diagnostic Level does not match. Portal was not set to Enhanced, instead is Basic. |
これは一時的な問題であるため、デプロイを再試行すると、これを修正する必要があります。 詳細については、 デプロイを実行する方法を参照してください。 | ||||||||||||||||||
| デプロイ | このリリースでは、シークレット URI/場所フィールドに問題があります。 これは必須フィールドであり、 必須 とマークされ、Azure Resource Manager テンプレートのデプロイエラーが発生します。 | Azure Resource Manager テンプレートを使用して Azure Local バージョン 23H2 をデプロイするのサンプル パラメーター ファイルを使用して、すべての入力が必要な形式で提供されていることを確認してから、デプロイを試します。 デプロイに失敗した場合は、デプロイを 実行する前に、次のリソースもクリーンアップする必要があります。 1. C:\EceStoreを削除します。 2. C:\CloudDeploymentを削除します。 3. C:\nugetstoreを削除します。 4. Remove-Item HKLM:\Software\Microsoft\LCMAzureStackStampInformation。 |
||||||||||||||||||
| セキュリティ | 新しいデプロイでは、セキュリティで保護されたコア対応デバイスでは、既定では動的な測定ルート (DRTM) は有効になりません。 Enable-AzSSecurity コマンドレットを使用して (DRTM) を有効にしようとすると、現在のリリースでは DRTM 設定がサポートされていないというエラーが表示されます。 Microsoft では多層防御をお勧めします。UEFI セキュア ブートでは、署名されて検証されたときにのみ読み込まれるようにすることで、静的信頼ルート (SRT) ブート チェーン内のコンポーネントが保護されます。 |
DRTM は、このリリースではサポートされていません。 | ||||||||||||||||||
| ネットワーク | プロキシ サーバーを使用すると、環境チェックが失敗します。 設計上、winhttp と wininet ではバイパス リストが異なり、検証チェックが失敗します。 | 次の回避策の手順に従います。 1. 正常性チェックの前と、デプロイまたは更新を開始する前に、プロキシ バイパス リストをクリアします。 2. チェックに合格した後、デプロイまたは更新が失敗するまで待ちます。 3. プロキシ バイパス リストをもう一度設定します。 |
||||||||||||||||||
| Arc VM の管理 | Arc Resource Bridge のデプロイまたは更新は、この操作中に自動的に生成された一時的な SPN シークレットがハイフンで始まるときに失敗する可能性があります。 | デプロイ/更新を再試行します。 再試行によって SPN シークレットが再生成され、操作が成功する可能性があります。 | ||||||||||||||||||
| Arc VM の管理 | Arc VM 上の Arc 拡張機能は、無期限に "作成中" 状態のままになります。 | VM にサインインし、コマンド プロンプトを開き、次のように入力します。 Windows: notepad C:\ProgramData\AzureConnectedMachineAgent\Config\agentconfig.json Linux: sudo vi /var/opt/azcmagent/agentconfig.json 次に、 resourcename プロパティを見つけます。 リソース名の末尾に追加された GUID を削除して、このプロパティが VM の名前と一致するようにします。 次に、VM を再起動します。 |
||||||||||||||||||
| Arc VM の管理 | 新しいマシンが Azure ローカル インスタンスに追加されると、新しく作成されたボリュームのストレージ パスは自動的に作成されません。 | 新しいボリュームのストレージ パスを手動で作成できます。 詳細については、「 ストレージ パスの作成」を参照してください。 | ||||||||||||||||||
| Arc VM の管理 | Arc VM の再起動操作は約 20 分後に完了しますが、VM 自体は約 1 分で再起動します。 | このリリースには既知の回避策はありません。 | ||||||||||||||||||
| Arc VM の管理 | 場合によっては、Azure portal で論理ネットワークの状態が [失敗] と表示される場合があります。 これは、論理ネットワークに関連付けられているネットワーク インターフェイスなどのリソースを最初に削除せずに論理ネットワークを削除しようとすると発生します。 この論理ネットワーク上にリソースを作成することはできます。 この場合、状態は誤解を招きます。 |
この論理ネットワークの状態が Succeededed このネットワークがプロビジョニングされた時点で、このネットワーク上にリソースを作成し続けることができます。 | ||||||||||||||||||
| Arc VM の管理 | このリリースでは、Azure CLI を使用して VM に接続されているデータ ディスクを使用して VM を更新すると、次のエラー メッセージで操作が失敗します。 名前が付いた仮想ハード ディスクが見つかりませんでした。 |
すべての VM 更新操作に Azure portal を使用します。 詳細については、「 Arc VM の管理と Arc VM リソースの管理を参照してください。 | ||||||||||||||||||
| を更新する | まれに、Azure ローカル インスタンスの更新中にこのエラーが発生する場合があります: Type 'UpdateArbAndExtensions' of Role 'MocArb' raised an exception: Exception Upgrading ARB and Extension in step [UpgradeArbAndExtensions :Get-ArcHciConfig] UpgradeArb: Invalid applianceyaml = [C:\AksHci\hci-appliance.yaml]。 |
この問題が発生した場合は、Microsoft サポートにお問い合わせください。 | ||||||||||||||||||
| ネットワーク | このリリースでは、DNS 解決エラーが発生した 2 ノード システムでデプロイが失敗する原因となる、あまり発生しない DNS クライアントの問題があります: RestRequest の送信中に WebException が発生しました。WebException.Status: NameResolutionFailure. バグの結果、2 番目のノードの DNS レコードは作成後すぐに削除され、DNS エラーが発生します。 | マシンを再起動します。 この操作により DNS レコードが登録され、削除されなくなります。 | ||||||||||||||||||
| Azure Portal | 場合によっては、Azure portal の更新に時間がかかる場合があり、ビューが最新ではない可能性があります。 | 更新されたビューを表示するには、30 分以上待つ必要がある場合があります。 | ||||||||||||||||||
| Arc VM の管理 | このリリースでは、Azure portal から Arc VM 上のネットワーク インターフェイスを削除することはできません。 | Azure CLI を使用して、最初にネットワーク インターフェイスを削除してから削除します。 詳細については、「 ネットワーク インターフェイスの削除 ネットワーク インターフェイスの削除 を参照してください。 | ||||||||||||||||||
| 展開 | 正しくない構文で OU 名を指定することは、Azure portal では検出されません。 正しくない構文には、 &,",',<,>などのサポートされていない文字が含まれています。 不適切な構文は、後の手順でシステム検証中に検出されます。 |
OU パスの構文が正しく、サポートされていない文字が含まれていないことを確認します。 | ||||||||||||||||||
| 展開 | Azure Resource Manager 経由のデプロイは、2 時間後にタイムアウトになります。 2 時間を超えるデプロイは、システムが正常に作成されたにもかかわらず、リソース グループに失敗として表示されます。 | Azure portal でデプロイを監視するには、Azure ローカル インスタンス リソースに移動し、新しい Deployments エントリに移動します。 | ||||||||||||||||||
| Azure Site Recovery | このリリースでは、Azure Site Recovery を Azure ローカル インスタンスにインストールできません。 | このリリースには既知の回避策はありません。 | ||||||||||||||||||
| 更新する | Azure Update Manager を使用して Azure ローカル インスタンスを更新すると、更新の進行状況と結果が Azure portal に表示されないことがあります。 | この問題を回避するには、各ノードで次のレジストリ キーを追加します (値は必要ありません)。New-Item -Path "HKLM:\SYSTEM\CurrentControlSet\Services\HciCloudManagementSvc\Parameters" -force次に、いずれかのノードで、Cloud Management クラスター グループを再起動します。 Stop-ClusterGroup "Cloud Management"Start-ClusterGroup "Cloud Management"更新プロセスの期間中、進行状況の詳細が表示されない可能性があるため、この問題は完全には修復されません。 最新の更新プログラムの詳細を取得するには、 PowerShell を使用して更新の進行状況を確認。 |
||||||||||||||||||
| を更新する | まれに、失敗した更新が Azure Update Manager の In progress 状態でスタックした場合、 再試行 ボタンは無効になります。 | 更新を再開するには、次の PowerShell コマンドを実行します。Get-SolutionUpdate|Start-SolutionUpdate. |
||||||||||||||||||
| を更新する | 場合によっては、Send-DiagnosticData コマンドの後で実行すると、SolutionUpdateコマンドが失敗することがあります。 |
Send-DiagnosticDataに使用されている PowerShell セッションを閉じてください。 新しい PowerShell セッションを開き、 SolutionUpdate コマンドに使用します。 |
||||||||||||||||||
| を更新する | まれに、2311.0.24 から 2311.2.4 に更新プログラムを適用すると、システムの状態は、予想される更新ではなく、In Progress を報告します。 | 更新を再試行してください。 引き続き問題が発生する場合は、 Microsoft サポートにお問い合わせください。 | ||||||||||||||||||
| を更新する | ソリューションの更新プログラムのインストールの試行は、CAU の手順の最後に失敗する可能性があります。There was a failure in a Common Information Model (CIM) operation, that is, an operation performed by software that Cluster-Aware Updating depends on. このまれな問題は、ノードの再起動後に Cluster Name または Cluster IP Address リソースの起動に失敗し、小規模なデプロイで最も一般的な場合に発生します。 |
この問題が発生した場合は、次の手順Microsoft サポートにお問い合わせください。 Azure ローカル リソースを手動で再起動し、必要に応じて更新プログラムを再開することができます。 | ||||||||||||||||||
| を更新する | システム更新プログラムを 10.2402.3.11 に適用すると、 Get-SolutionUpdate コマンドレットが応答せず、最終的に約 10 分後に RequestTimeoutException で失敗する可能性があります。 これは、サーバーの追加または修復シナリオの後に発生する可能性があります。 |
Start-ClusterGroupコマンドレットとStop-ClusterGroup コマンドレットを使用して、更新サービスを再起動します。 Get-ClusterGroup -Name "Azure Stack HCI Update Service Cluster Group" | Stop-ClusterGroup Get-ClusterGroup -Name "Azure Stack HCI Update Service Cluster Group" | Start-ClusterGroup これらのコマンドレットを正常に実行すると、更新サービスがオンラインになります。 |
||||||||||||||||||
| クラスター対応の更新 | ノードの再開操作がノードの再開に失敗しました。 | これは一時的な問題であり、単独で解決される可能性があります。 数分待ってから、操作を再試行してください。 引き続き問題が発生する場合は、 Microsoft サポートにお問い合わせください。 | ||||||||||||||||||
| クラスター対応の更新 | ノードの中断操作が 90 分を超える間停止しました。 | これは一時的な問題であり、単独で解決される可能性があります。 数分待ってから、操作を再試行してください。 引き続き問題が発生する場合は、 Microsoft サポートにお問い合わせください。 |
次のステップ
- 展開の概要を参照してください。