查看 Azure Stack HCI 2405.2 版本中的已知问题
适用于：Azure 本地版本 23H2
本文介绍 Azure Stack HCI 2405.2 版本中的关键已知问题和解决方法。
发行说明会持续进行更新，并且会陆续将所发现的需要解决的重要问题添加到说明中。 在部署 Azure Stack HCI 之前，请仔细查看发行说明中包含的信息。
重要
有关此版本支持的更新路径的信息，请参阅 发布信息。
有关此版本中的新功能的详细信息，请参阅 23H2 中的新增功能。
版本 2405.2 的问题
此软件版本映射到软件版本号 2405.2.7。
此版本的发行说明包括此版本中已修复的问题、此版本中的已知问题，以及从早期版本传递的发行说明问题。
修复的问题
下面是此版本中的已修复问题：
| 功能 | 问题 | 变通方法/注释 |
|---|---|---|
| 更新 | 在此版本中，修复了与运行状况检查中缺少资源类型 ID 字段相关的更新问题。 | |
| 更新 | 在此版本中，修复了与具有相同名称的不同运行状况检查相关的更新问题。 | |
| 更新 | 在此版本中，修复了预更新或每日运行状况检查中缺少解决方案生成器扩展更新运行状况检查的问题。 | |
| 更新 | 在此版本中，修复了由于更新服务在处于错误状态的服务器上崩溃而导致无法查看或启动新更新的问题。 | |
| 更新 | 在此版本中，更新服务已得到改进，以防止群集上的操作泛滥。 | |
| 更新 | 在此版本中，添加了运行状况检查以防止添加或删除服务器时更新失败。 | |
| Arc VM 管理 | 在早期版本中，VM 的任何电源状态更改操作（如启动停止、保存和暂停）最初都将返回 VM 的状态，在刷新 30 秒后最终显示正确的状态。 在此版本中，电源状态更改操作仅在 VM 状态更改为预期状态后返回。 |
本版本中的已知问题
| 功能 | 问题 | 解决方法 |
|---|---|---|
| 更新 | 由于 SDN 基础结构 VM 中的 bug，在主机完成机密轮换和更新后，SDN 将停止工作。 | 此版本中没有此问题的解决方法。 如果出现问题，请联系Microsoft 支持部门以了解后续步骤。 |
| 更新 | 由于环境准备情况检查器中的 bug，物理磁盘环境就绪情况检查错误失败并阻止更新。 | 等待几分钟，然后重试更新。 |
| 部署 | 在此版本中，可能会收到以下错误： 调用 Cloud Deploy Failed With - Value 不能为 null。 | 此版本中没有此问题的解决方法。 如果出现问题，请联系Microsoft 支持部门以了解后续步骤。 |
| 更新 | 在此版本中，环境检查失败并出现以下错误： 更新处于“失败”状态：HealthCheckFailed。ECE 中的摘要 XML 不存在。 | 此版本中没有此问题的解决方法。 如果出现问题，请联系Microsoft 支持部门以了解后续步骤。 |
以前版本中的已知问题
下面是以前版本中的已知问题：
| 功能 | 问题 | 解决方法 | ||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 更新 | 通过 Azure 更新管理器查看 Azure Stack HCI 群集的就绪情况检查结果时，可能有多个具有相同名称的就绪情况检查。 | 此版本中没有已知的解决方法。 选择“查看详细信息”以查看有关就绪情况检查的特定信息。 | ||||||||||||||||||
| Arc VM 管理 | 在大型部署方案中（例如广泛的 AVD 主机池部署或大规模 VM 预配），可能会遇到由 Hyper-V 套接字外部库问题引起的可靠性问题。 | 按照以下步骤缓解此问题： 1.运行命令 Get-service mochostagent (\) get-process (\) kill。 检查命令的输出，并验证句柄计数是否在数千个中。 2.运行命令 Get-service mochostagent (\) get-process 以终止进程。 3.运行命令 restart-service mochostagent 以重启 mochostagent 服务。 |
||||||||||||||||||
| 部署 | 通过 Azure 门户 部署 Azure Stack HCI 版本 23H2 时，可能会遇到以下部署验证失败：Could not complete the operation. 400: Resource creation validation failed. Details: [{"Code":"AnswerFileValidationFailed","Message":"Errors in Value Validation:\r\nPhysicalNodesValidator found error at deploymentdata.physicalnodes[0].ipv4address: The specified for \u0027deploymentdata.physicalnodes[0].ipv4address\u0027 is not a valid IPv4 address. Example: 192.168.0.1 or 192.168.0.1","Target":null,"Details":null}]. 如果转到Azure 门户部署中的“网络”选项卡，在“网络意向”配置中，可能会看到以下错误：所选物理网络适配器未绑定到管理虚拟交换机。 |
按照Azure 门户中的部署验证失败故障排除中的过程操作。 | ||||||||||||||||||
| 部署 | 通过Azure 门户部署失败，并出现此错误：无法从密钥保管库提取机密 LocalAdminCredential。 | 此版本中没有此问题的解决方法。 如果出现问题，请联系Microsoft 支持部门以了解后续步骤。 | ||||||||||||||||||
| 部署 | 在某些情况下，在注册 Azure Stack HCI 服务器期间，可能会在调试日志中看到此错误： 遇到内部服务器错误。 可能未安装设备部署的必需扩展之一。 | 按照以下步骤缓解此问题：$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 门户错误地报告更新状态失败或正在进行更新时，此版本中存在间歇性问题。 | 通过远程 PowerShell 会话连接到 Azure 本地 。 若要确认更新状态，请运行以下 PowerShell cmdlet：$Update = get-solutionupdate| ? version -eq "<version string>"将版本字符串替换为正在运行的版本。 例如，“10.2405.0.23”。 $Update.state如果更新状态为 “已安装”，则部件无需执行进一步操作。 Azure 门户 24 小时内正确刷新状态。 若要更快地刷新状态，请在其中一个群集节点上执行以下步骤。 重启云管理群集组。 Stop-ClusterGroup "Cloud Management"Start-ClusterGroup "Cloud Management" |
||||||||||||||||||
| 更新 | 在初始 MOC 更新期间，由于未在目录缓存中找到目标 MOC 版本，导致失败。 后续更新和重试在目标版本中显示 MOC，而不成功更新，因此 Arc 资源桥更新失败。 若要验证此问题，请使用 Azure Stack HCI 版本 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' version2. 使用命令的输出从下表中找到与代理版本匹配的 MOC 版本，并设置为 $initialMocVersion 该 MOC 版本。 $targetMocVersion通过查找要更新的 Azure Stack HCI 版本并从下表获取匹配的 MOC 版本来设置该版本。 在下面提供的缓解脚本中使用这些值：
例如，如果代理版本为 v0.13.0-6-gf13a73f7，v0.11.0-alpha.38,01/06/2024，则如果要更新到 2405.0.23，则 $initialMocVersion = “1.0.24.10106” 为 $targetMocVersion = “1.3.0.10418”2405.0.23。3.在第一个节点上运行以下 PowerShell 命令： $initialMocVersion = "<initial version determined from step 2>"$targetMocVersion = "<target version determined from step 2>"# 导入 MOC 模块两次 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.恢复更新。 |
||||||||||||||||||
| HCI 上的 AKS | AKS 群集创建失败，并出现 Error: Invalid AKS network resource id. 当关联的逻辑网络名称具有下划线时，可能会出现此问题。 |
逻辑网络名称不支持下划线。 请确保不要在 Azure Stack HCI 上部署的逻辑网络的名称中使用下划线。 | ||||||||||||||||||
| 修复服务器 | 在极少数情况下，操作 Repair-Server 失败并 HealthServiceWaitForDriveFW 出现错误。 在这些情况下，不会删除已修复节点中的旧驱动器，并且新磁盘停滞在维护模式下。 |
若要防止此问题，请确保在启动Repair-Server之前不要通过 Windows Admin Center 或使用 Suspend-ClusterNode -Drain PowerShell cmdlet 清空节点。 如果出现问题，请联系Microsoft 支持部门以了解后续步骤。 |
||||||||||||||||||
| 修复服务器 | 当单服务器 Azure Stack HCI 从 2311 更新到 2402，然后 Repair-Server 执行时，会出现此问题。 修复操作失败。 |
在修复单个节点之前，请执行以下步骤： 1.运行 ADPrepTool 版本 2402。 按照准备 Active Directory 中的步骤操作。 此操作很快，并将所需的权限添加到组织单位（OU）。 2.将计算机对象从 计算机 段移动到根 OU。 运行下面的命令： Get-ADComputer <HOSTNAME> | Move-ADObject -TargetPath "<OU path>" |
||||||||||||||||||
| 部署 | 如果你自行准备 Active Directory（不使用Microsoft提供的脚本和过程），Active Directory 验证可能会失败，但权限缺失 Generic All 。 这是因为验证检查中存在一个问题，用于检查专用权限条目 msFVE-RecoverInformationobjects – General – Permissions Full control，这是 BitLocker 恢复所必需的。 |
使用 Prepare AD 脚本方法或使用自己的方法，请确保分配特定权限msFVE-RecoverInformationobjects – General – Permissions Full control。 |
||||||||||||||||||
| 部署 | 此版本中很少出现以下问题：在 Azure Stack HCI 部署期间删除 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 会话并在受影响的节点上运行以下 cmdlet： 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 资源桥或 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 资源管理器模板部署失败。 | 使用部署 Azure Stack HCI 版本 23H2 中的示例参数文件（通过 Azure 资源管理器 模板）确保以所需格式提供所有输入，然后尝试部署。 如果部署失败，则还必须在重新运行部署之前清理以下资源： 1. 删除 C:\EceStore。 2. 删除 C:\CloudDeployment。 3. 删除 C:\nugetstore。 4. Remove-Item HKLM:\Software\Microsoft\LCMAzureStackStampInformation. |
||||||||||||||||||
| 安全 | 对于新部署，默认情况下，支持安全核心的设备不会启用动态度量根（DRTM）。 如果尝试使用 Enable-AzSSecurity cmdlet 启用 （DRTM），则会看到当前版本中不支持 DRTM 设置的错误。 Microsoft建议深度防御，UEFI 安全启动仍通过确保仅在签名和验证组件时才加载信任根（SRT）启动链中的组件。 |
此版本中不支持 DRTM。 | ||||||||||||||||||
| 网络连接 | 使用代理服务器时，环境检查会失败。 根据设计，winhttp 和 wininet 的绕过列表不同，这会导致验证检查失败。 | 请按照以下解决方法步骤操作： 1.在运行状况检查之前以及开始部署或更新之前，清除代理绕过列表。 2. 通过检查后，等待部署或更新失败。 3.再次设置代理绕过列表。 |
||||||||||||||||||
| Arc VM 管理 | 当此操作期间自动生成的临时 SPN 机密以连字符开头时，Arc 资源桥的部署或更新可能会失败。 | 重试部署/更新。 重试应重新生成 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 Stack HCI 群集时，不会为新创建的卷自动创建存储路径。 | 可以为任何新卷手动创建存储路径。 有关详细信息，请参阅 “创建存储路径”。 | ||||||||||||||||||
| Arc VM 管理 | 大约 20 分钟后，Arc VM 操作的重启完成，尽管 VM 本身大约在一分钟内重启。 | 此版本中没有已知的解决方法。 | ||||||||||||||||||
| Arc VM 管理 | 在某些情况下，逻辑网络的状态显示为Azure 门户失败。 尝试删除逻辑网络时，不会首先删除任何资源，例如与该逻辑网络关联的网络接口。 仍应该能够在此逻辑网络上创建资源。 此实例中的状态具有误导性。 |
如果此逻辑网络的状态在预配此网络 时成功 ，则可以继续在此网络上创建资源。 | ||||||||||||||||||
| Arc VM 管理 | 在此版本中，在使用 Azure CLI 附加的数据磁盘更新 VM 时，操作会失败并显示以下错误消息： 找不到具有名称的虚拟硬盘。 |
对所有 VM 更新操作使用Azure 门户。 有关详细信息，请参阅 管理 Arc VM 和管理 Arc VM 资源。 | ||||||||||||||||||
| 更新 | 在极少数情况下，更新 Azure Stack HCI 时可能会遇到此错误： 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 客户端问题，导致部署在两节点群集上失败，并出现 DNS 解析错误： 发送 RestRequest 时发生 WebException。WebException.Status：NameResolutionFailure。 由于 bug，第二个节点的 DNS 记录在创建后不久将被删除，从而导致 DNS 错误。 | 重新启动服务器。 此操作会注册 DNS 记录，以防止其被删除。 | ||||||||||||||||||
| Azure 门户 | 在某些情况下，Azure 门户可能需要一段时间才能更新，并且视图可能不是最新的。 | 可能需要等待 30 分钟或更多时间才能查看更新后的视图。 | ||||||||||||||||||
| Arc VM 管理 | 从 Azure 门户 中删除 Arc VM 上的网络接口在此版本中不起作用。 | 使用 Azure CLI 先删除网络接口，然后将其删除。 有关详细信息，请参阅 “删除网络接口 ”和“ 删除网络接口”。 | ||||||||||||||||||
| 部署 | 在Azure 门户中未检测到以不正确的语法提供 OU 名称。 错误的语法包括不支持的字符，例如 &,",',<,>。 在群集验证过程中的后续步骤中检测到错误的语法。 |
确保 OU 路径语法正确且不包含不受支持的字符。 | ||||||||||||||||||
| 部署 | 通过 Azure 部署资源管理器 2 小时后超时。 如果成功创建群集，超过 2 小时的部署在资源组中显示为失败。 | 若要监视Azure 门户中的部署，请转到 Azure Stack HCI 群集资源，然后转到新的部署条目。 | ||||||||||||||||||
| Azure Site Recovery | 在此版本中，无法在 Azure Stack HCI 群集上安装 Azure Site Recovery。 | 此版本中没有已知的解决方法。 | ||||||||||||||||||
| 更新 | 通过 Azure 更新管理器更新 Azure Stack HCI 群集时，更新进度和结果在Azure 门户中可能不可见。 | 若要解决此问题，请在每个群集节点上添加以下注册表项（无需值）：New-Item -Path "HKLM:\SYSTEM\CurrentControlSet\Services\HciCloudManagementSvc\Parameters" -force然后在其中一个群集节点上重启云管理群集组。 Stop-ClusterGroup "Cloud Management"Start-ClusterGroup "Cloud Management"这不会完全修正问题，因为进度详细信息在更新过程期间可能仍未显示。 若要获取最新的更新详细信息，可以使用 PowerShell 检索更新进度。 |
||||||||||||||||||
| 更新 | 在极少数情况下，如果失败的更新停滞在 Azure 更新管理器中的“正在进行 ”状态，则会 禁用“重试 ”按钮。 | 若要恢复更新，请运行以下 PowerShell 命令：Get-SolutionUpdate|Start-SolutionUpdate。 |
||||||||||||||||||
| 更新 | 在某些情况下， SolutionUpdate 如果在命令后 Send-DiagnosticData 运行，命令可能会失败。 |
请确保关闭用于 Send-DiagnosticData的 PowerShell 会话。 打开新的 PowerShell 会话并将其用于 SolutionUpdate 命令。 |
||||||||||||||||||
| 更新 | 在极少数情况下，在将更新从 2311.0.24 应用到 2311.2.4 时，群集状态报告 正在进行 中，而不是预期 无法更新。 | 重试更新。 如果该问题仍然存在，请联系 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 支持部门以了解后续步骤。 他们可以与你一起手动重启群集资源，并根据需要恢复更新。 | ||||||||||||||||||
| 更新 | 将群集更新应用到 10.2402.3.11 时， Get-SolutionUpdate cmdlet 可能无法响应，最终在大约 10 分钟后失败并失败。 在添加或修复服务器方案后，可能会发生这种情况。 |
Start-ClusterGroup使用 cmdlet 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 成功运行这些 cmdlet 应使更新服务联机。 |
||||||||||||||||||
| 群集感知更新 | 恢复节点操作无法恢复节点。 | 这是暂时性问题，可以自行解决。 等待几分钟，然后重试该操作。 如果该问题仍然存在，请联系 Microsoft 支持部门。 | ||||||||||||||||||
| 群集感知更新 | 暂停节点操作停滞了 90 分钟以上。 | 这是暂时性问题，可以自行解决。 等待几分钟，然后重试该操作。 如果该问题仍然存在，请联系 Microsoft 支持部门。 |