Exibir problemas conhecidos na versão 2405.2 do Azure Stack HCI
Aplica-se a: Azure Stack HCI, versão 23H2
Este artigo identifica os problemas críticos conhecidos e suas soluções alternativas na versão 2405.2 do Azure Stack HCI.
As notas sobre a versão são continuamente atualizadas e, à medida que são descobertos problemas críticos que exigem uma solução alternativa, elas são adicionadas. Antes de implantar o Azure Stack HCI, examine cuidadosamente as informações contidas nas notas de versão.
Importante
Para obter informações sobre os caminhos atualizados com suporte para esta versão, consulte Informações de versão.
Para obter mais informações sobre os novos recursos desta versão, consulte Novidades no 23H2.
Problemas para a versão 2405.2
Esta versão do software é mapeada para o número da versão do software 2405.2.7.
As notas de versão desta versão incluem os problemas corrigidos nesta versão, problemas conhecidos nesta versão e problemas observados de versão transferidos de versões anteriores.
Problemas corrigidos
Aqui estão os problemas corrigidos nesta versão:
| Recurso | Problema | Solução alternativa/comentários |
|---|---|---|
| Atualizações | Nesta versão, foi corrigido um problema de atualização relacionado ao campo ID do tipo de recurso ausente nas verificações de integridade. | |
| Atualizações | Nesta versão, foi corrigido um problema de atualização relacionado a diferentes verificações de integridade com o mesmo nome. | |
| Atualizações | Nesta versão, foi corrigido um problema em que as verificações de integridade da Atualização da Extensão do Construtor de Soluções estavam ausentes nas verificações de integridade diárias ou de pré-atualização. | |
| Atualizações | Nesta versão, foi corrigido um problema que causava a incapacidade de exibir ou iniciar novas atualizações devido ao travamento do serviço de atualização em servidores em mau estado. | |
| Atualizações | Nesta versão, o serviço de atualização foi aprimorado para evitar a inundação de ações no cluster. | |
| Atualizações | Nesta versão, uma verificação de integridade foi adicionada para evitar atualizações quando a adição ou remoção de servidores falhar. | |
| Gerenciamento de VM do Arc | Em versões anteriores, qualquer operação de alteração de estado de energia de uma VM, como iniciar, parar, salvar e pausar, inicialmente retornaria o estado da VM como em execução e, eventualmente, exibiria o estado correto após uma atualização 30+ segundos depois. Nesta versão, a operação de alteração do estado de energia só retorna depois que o estado da VM é alterado para o esperado. |
Problemas conhecidos nesta versão
A Microsoft não está ciente de nenhum problema conhecido nesta versão.
Problemas conhecidos de versões anteriores
Aqui estão os problemas conhecidos de versões anteriores:
| Recurso | Problema | Solução alternativa | ||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Atualizar | Ao exibir os resultados da verificação de preparação para um cluster do Azure Stack HCI por meio do Azure Update Manager, pode haver várias verificações de preparação com o mesmo nome. | Não há nenhuma solução alternativa conhecida nesta versão. Selecione Exibir detalhes para exibir informações específicas sobre a verificação de preparação. | ||||||||||||||||||
| Implantação | Em alguns casos, durante o registro de servidores do Azure Stack HCI, esse erro pode ser visto nos logs de depuração: Erro de servidor interno encontrado. Uma das extensões obrigatórias para implantação de dispositivo pode não estar instalada. | Siga estas etapas para atenuar o problema: $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 |
||||||||||||||||||
| Atualizar | Há um problema intermitente nesta versão quando o portal do Azure relata incorretamente o status da atualização como Falha ao atualizar ou Em andamento , embora a atualização esteja concluída. | Conecte-se ao Azure Stack HCI por meio de uma sessão remota do PowerShell. Para confirmar o status da atualização, execute os seguintes cmdlets do PowerShell: $Update = get-solutionupdate| ? version -eq "<version string>"Substitua a string de versão pela versão que você está executando. Por exemplo, "10.2405.0.23". $Update.stateSe o status da atualização for Instalado, nenhuma ação adicional será necessária de sua parte. O portal do Azure atualiza o status corretamente em 24 horas. Para atualizar o status mais cedo, siga estas etapas em um dos nós do cluster. Reinicie o grupo de clusters do Gerenciamento de Nuvem. Stop-ClusterGroup "Cloud Management"Start-ClusterGroup "Cloud Management" |
||||||||||||||||||
| Atualização | Durante uma atualização inicial do MOC, ocorre uma falha devido à versão do MOC de destino não ser encontrada no cache do catálogo. As atualizações e novas tentativas de acompanhamento mostram o MOC na versão de destino, sem que a atualização seja bem-sucedida e, como resultado, a atualização do Arc Resource Bridge falha. Para validar esse problema, colete os logs de atualização usando Solucionar problemas de atualizações de solução para o Azure Stack HCI, versão 23H2. Os arquivos de log devem mostrar uma mensagem de erro semelhante (a versão atual pode ser diferente na mensagem de erro): [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}" }] |
Siga estas etapas para atenuar o problema: 1. Para encontrar a versão do agente MOC, execute o seguinte comando: 'C:\Program Files\AksHci\wssdcloudagent.exe' version.2. Use a saída do comando para encontrar a versão do MOC na tabela abaixo que corresponde à versão do agente e defina $initialMocVersion como essa versão do MOC. Defina o $targetMocVersion localizando o build do Azure Stack HCI para o qual você está atualizando e obtenha a versão do MOC correspondente na tabela a seguir. Use esses valores no script de mitigação fornecido abaixo:
Por exemplo, se a versão do agente for v0.13.0-6-gf13a73f7, v0.11.0-alpha.38,01/06/2024, e $initialMocVersion = “1.0.24.10106” se você estiver atualizando para 2405.0.23, então $targetMocVersion = “1.3.0.10418”.3. Execute os seguintes comandos do PowerShell no primeiro nó: $initialMocVersion = "<initial version determined from step 2>"$targetMocVersion = "<target version determined from step 2>"# Importe o módulo MOC duas vezes import-module mocimport-module moc$verbosePreference = "Continue"# Limpe o cache do catálogo SFS Remove-Item (Get-MocConfig).manifestCache# Defina a versão para a versão atual do MOC antes da atualização e defina o estado como falha na atualização Set-MocConfigValue -name "version" -value $initialMocVersionSet-MocConfigValue -name "installState" -value ([InstallState]::UpdateFailed)# Execute novamente a atualização do MOC para a versão desejada Update-Moc -version $targetMocVersion4. Retome a atualização. |
||||||||||||||||||
| AKS em HCI | A criação do cluster do AKS falha com o Error: Invalid AKS network resource id. Esse problema pode ocorrer quando o nome da rede lógica associada tem um sublinhado. |
Não há suporte para sublinhados em nomes de rede lógicos. Certifique-se de não usar sublinhado nos nomes de redes lógicas implantadas em seu Azure Stack HCI. | ||||||||||||||||||
| Servidor de reparo | Em casos raros, a Repair-Server operação falha com o HealthServiceWaitForDriveFW erro. Nesses casos, as unidades antigas do nó reparado não são removidas e os novos discos ficam presos no modo de manutenção. |
Para evitar esse problema, certifique-se de NÃO drenar o nó por meio do Windows Admin Center ou usando o cmdlet do Suspend-ClusterNode -Drain PowerShell antes de iniciar Repair-Server. Se o problema ocorrer, entre em contato com o Suporte da Microsoft para obter as próximas etapas. |
||||||||||||||||||
| Servidor de reparo | Esse problema é visto quando o servidor único Azure Stack HCI é atualizado de 2311 para 2402 e, em seguida, é Repair-Server executado. A operação de reparo falha. |
Antes de reparar o nó único, siga estas etapas: 1. Execute a versão 2402 para o ADPrepTool. Siga as etapas em Preparar o Active Directory. Essa ação é rápida e adiciona as permissões necessárias à unidade organizacional (UO). 2. Mova o objeto de computador do segmento Computadores para a UO raiz. Execute o comando a seguir: Get-ADComputer <HOSTNAME> | Move-ADObject -TargetPath "<OU path>" |
||||||||||||||||||
| Implantação | Se você preparar o Active Directory por conta própria (não usando o script e o procedimento fornecidos pela Microsoft), a validação do Active Directory poderá falhar com permissão ausente Generic All . Isso ocorre devido a um problema na verificação de validação que verifica se há uma entrada de permissão dedicada para msFVE-RecoverInformationobjects – General – Permissions Full control, que é necessária para a recuperação do BitLocker. |
Use o método de script Preparar AD ou, se estiver usando seu próprio método, certifique-se de atribuir a permissão msFVE-RecoverInformationobjects – General – Permissions Full controlespecífica. |
||||||||||||||||||
| Implantação | Há um problema raro nesta versão em que o registro DNS é excluído durante a implantação do Azure Stack HCI. Quando isso ocorre, a seguinte exceção é vista: 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. |
Verifique o servidor DNS para ver se algum registro DNS dos nós do cluster está ausente. Aplique a mitigação a seguir nos nós em que seu registro DNS está ausente. Reinicie o serviço de cliente DNS. Abra uma sessão do PowerShell e execute o seguinte cmdlet no nó afetado: Taskkill /f /fi "SERVICES eq dnscache" |
||||||||||||||||||
| Implantação | Nesta versão, há uma falha de tarefa remota em uma implantação de vários nós que resulta na seguinte exceção:ECE RemoteTask orchestration failure with ASRR1N42R01U31 (node pingable - True): A WebException occurred while sending a RestRequest. WebException.Status: ConnectFailure on [https://<URL>](https://<URL>). |
A mitigação é reiniciar o agente ECE no nó afetado. No servidor, abra uma sessão do PowerShell e execute o seguinte comando:Restart-Service ECEAgent. |
||||||||||||||||||
| Adicionar servidor | Nesta versão e nas anteriores, ao adicionar um servidor ao cluster, não é possível atualizar a string da lista de bypass de proxy para incluir o novo servidor. A atualização da lista de bypass de proxy de variáveis de ambiente nos hosts não atualizará a lista de bypass de proxy no Azure Resource Bridge ou no AKS. | Não há solução alternativa nesta versão. Se você encontrar esse problema, entre em contato com o Suporte da Microsoft para determinar as próximas etapas. | ||||||||||||||||||
| Adicionar/reparar servidor | Nesta versão, ao adicionar ou reparar um servidor, uma falha é vista quando os certificados de VM do balanceador de carga de software ou do controlador de rede estão sendo copiados dos nós existentes. A falha ocorre porque esses certificados não foram gerados durante a implantação/atualização. | Não há solução alternativa nesta versão. Se você encontrar esse problema, entre em contato com o Suporte da Microsoft para determinar as próximas etapas. | ||||||||||||||||||
| Implantação | Nesta versão, há um problema transitório que resulta na falha de implantação com a seguinte exceção: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. |
Como esse é um problema transitório, repetir a implantação deve corrigir isso. Para obter mais informações, consulte como executar novamente a implantação. | ||||||||||||||||||
| Implantação | Nesta versão, há um problema com o campo URI/local de segredos. Esse é um campo obrigatório marcado como Não obrigatório e resulta em falhas de implantação de modelo do Azure Resource Manager. | Use o arquivo de parâmetros de exemplo no modelo Implantar o Azure Stack HCI, versão 23H2 por meio do Azure Resource Manager para garantir que todas as entradas sejam fornecidas no formato necessário e, em seguida, tente a implantação. Se houver uma implantação com falha, você também deverá limpar os seguintes recursos antes de executar novamente a implantação: 1. Exclua C:\EceStore. 2. Exclua C:\CloudDeployment. 3. Exclua C:\nugetstore. 4. Remove-Item HKLM:\Software\Microsoft\LCMAzureStackStampInformation. |
||||||||||||||||||
| Segurança | Para novas implantações, os dispositivos compatíveis com núcleo seguro não terão a DRTM (Raiz Dinâmica de Medição) habilitada por padrão. Se você tentar habilitar (DRTM) usando o cmdlet Enable-AzSSecurity, verá um erro informando que a configuração do DRTM não tem suporte na versão atual. A Microsoft recomenda a defesa em profundidade, e a Inicialização Segura UEFI ainda protege os componentes na cadeia de inicialização SRT (Raiz Estática de Confiança), garantindo que eles sejam carregados somente quando forem assinados e verificados. |
Não há suporte para DRTM nesta versão. | ||||||||||||||||||
| Rede | Uma verificação de ambiente falha quando um servidor proxy é usado. Por design, a lista de bypass é diferente para winhttp e wininet, o que faz com que a verificação de validação falhe. | Siga estas etapas alternativas: 1. Limpe a lista de bypass de proxy antes da verificação de integridade e antes de iniciar a implantação ou a atualização. 2. Depois de passar na verificação, aguarde a falha da implantação ou atualização. 3. Defina sua lista de bypass de proxy novamente. |
||||||||||||||||||
| Gerenciamento de VM do Arc | A implantação ou atualização do Arc Resource Bridge pode falhar quando o segredo SPN temporário gerado automaticamente durante essa operação é iniciado com um hífen. | Repita a implantação/atualização. A repetição deve regenerar o segredo do SPN e a operação provavelmente será bem-sucedida. | ||||||||||||||||||
| Gerenciamento de VM do Arc | As extensões do Arc em VMs do Arc permanecem no estado "Criando" indefinidamente. | Entre na VM, abra um prompt de comando e digite o seguinte: Janelas: notepad C:\ProgramData\AzureConnectedMachineAgent\Config\agentconfig.json Linux: sudo vi /var/opt/azcmagent/agentconfig.json Em seguida, encontre a resourcename propriedade. Exclua o GUID acrescentado ao final do nome do recurso, para que essa propriedade corresponda ao nome da VM. Em seguida, reinicie a VM. |
||||||||||||||||||
| Gerenciamento de VM do Arc | Quando um novo servidor é adicionado a um cluster do Azure Stack HCI, o caminho de armazenamento não é criado automaticamente para o volume recém-criado. | Você pode criar manualmente um caminho de armazenamento para novos volumes. Para obter mais informações, consulte Criar um caminho de armazenamento. | ||||||||||||||||||
| Gerenciamento de VM do Arc | A reinicialização da operação da VM do Arc é concluída após aproximadamente 20 minutos, embora a própria VM seja reiniciada em cerca de um minuto. | Não há nenhuma solução alternativa conhecida nesta versão. | ||||||||||||||||||
| Gerenciamento de VM do Arc | Em alguns casos, o status da rede lógica é mostrado como Falha no portal do Azure. Isso ocorre quando você tenta excluir a rede lógica sem primeiro excluir nenhum recurso, como interfaces de rede associadas a essa rede lógica. Você ainda deve ser capaz de criar recursos nessa rede lógica. O status é enganoso neste caso. |
Se o status dessa rede lógica for Bem-sucedido no momento em que essa rede foi provisionada, você poderá continuar a criar recursos nessa rede. | ||||||||||||||||||
| Gerenciamento de VM do Arc | Nesta versão, quando você atualiza uma VM com um disco de dados anexado a ela usando a CLI do Azure, a operação falha com a seguinte mensagem de erro: Não foi possível encontrar um disco rígido virtual com o nome. |
Use o portal do Azure para todas as operações de atualização de VM. Para obter mais informações, consulte Gerenciar VMs do Arc e Gerenciar recursos de VM do Arc. | ||||||||||||||||||
| Atualização | Em casos raros, você pode encontrar este erro ao atualizar o 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]. |
Se você encontrar esse problema, entre em contato com o Suporte da Microsoft para ajudá-lo com as próximas etapas. | ||||||||||||||||||
| Rede | Há um problema de cliente DNS pouco frequente nesta versão que faz com que a implantação falhe em um cluster de dois nós com um erro de resolução DNS: Ocorreu uma WebException ao enviar um RestRequest. WebException.Status: NameResolutionFailure. Como resultado do bug, o registro DNS do segundo nó é excluído logo após sua criação, resultando em um erro de DNS. | Reinicie o servidor. Essa operação registra o registro DNS, o que impede que ele seja excluído. | ||||||||||||||||||
| Portal do Azure | Em alguns casos, o portal do Azure pode demorar um pouco para ser atualizado e a exibição pode não estar atualizada. | Talvez seja necessário aguardar 30 minutos ou mais para ver a visualização atualizada. | ||||||||||||||||||
| Gerenciamento de VM do Arc | A exclusão de um adaptador de rede em uma VM do Arc do portal do Azure não funciona nesta versão. | Use a CLI do Azure para primeiro remover o adaptador de rede e, em seguida, excluí-lo. Para obter mais informações, consulte Remover o adaptador de rede e Excluir o adaptador de rede. | ||||||||||||||||||
| Implantação | Fornecer o nome da UO em uma sintaxe incorreta não é detectado no portal do Azure. A sintaxe incorreta inclui caracteres não suportados, como &,",',<,>. A sintaxe incorreta é detectada em uma etapa posterior durante a validação do cluster. |
Verifique se a sintaxe do caminho da UO está correta e não inclui caracteres sem suporte. | ||||||||||||||||||
| Implantação | As implantações por meio do Azure Resource Manager atingem o tempo limite após 2 horas. As implantações que excedem 2 horas aparecem como com falha no grupo de recursos, embora o cluster tenha sido criado com êxito. | Para monitorar a implantação no portal do Azure, acesse o recurso de cluster do Azure Stack HCI e, em seguida, vá para a nova entrada Implantações . | ||||||||||||||||||
| Azure Site Recovery | O Azure Site Recovery não pode ser instalado em um cluster do Azure Stack HCI nesta versão. | Não há nenhuma solução alternativa conhecida nesta versão. | ||||||||||||||||||
| Atualização | Ao atualizar o cluster do Azure Stack HCI por meio do Azure Update Manager, o progresso e os resultados da atualização podem não estar visíveis no portal do Azure. | Para contornar esse problema, em cada nó de cluster, adicione a seguinte chave do Registro (nenhum valor necessário):New-Item -Path "HKLM:\SYSTEM\CurrentControlSet\Services\HciCloudManagementSvc\Parameters" -forceEm seguida, em um dos nós do cluster, reinicie o grupo de clusters do Gerenciamento de Nuvem. Stop-ClusterGroup "Cloud Management"Start-ClusterGroup "Cloud Management"Isso não corrigirá totalmente o problema, pois os detalhes do progresso ainda podem não ser exibidos durante o processo de atualização. Para obter os detalhes da atualização mais recente, você pode recuperar o progresso da atualização com o PowerShell. |
||||||||||||||||||
| Atualização | Em casos raros, se uma atualização com falha estiver presa em um estado Em andamento no Azure Update Manager, o botão Tentar novamente será desabilitado. | Para retomar a atualização, execute o seguinte comando do PowerShell:Get-SolutionUpdate|Start-SolutionUpdate. |
||||||||||||||||||
| Atualizações | Em alguns casos, SolutionUpdate os comandos podem falhar se executados após o Send-DiagnosticData comando. |
Certifique-se de fechar a sessão do PowerShell usada para Send-DiagnosticData. Abra uma nova sessão do PowerShell e use-a para SolutionUpdate comandos. |
||||||||||||||||||
| Atualização | Em casos raros, ao aplicar uma atualização de 2311.0.24 para 2311.2.4, o status do cluster relata Em andamento em vez do esperado Falha ao atualizar. | Repita a atualização. Se o problema persistir, contate o Suporte da Microsoft. | ||||||||||||||||||
| Atualização | As tentativas de instalar atualizações de solução podem falhar no final das etapas da CAU com:There was a failure in a Common Information Model (CIM) operation, that is, an operation performed by software that Cluster-Aware Updating depends on. Esse problema raro ocorre se os recursos do or Cluster IP Address não forem iniciados Cluster Name após a reinicialização de um nó e é mais comum em clusters pequenos. |
Se você encontrar esse problema, entre em contato com o Suporte da Microsoft para obter as próximas etapas. Eles podem trabalhar com você para reiniciar manualmente os recursos do cluster e retomar a atualização conforme necessário. | ||||||||||||||||||
| Atualização | Ao aplicar uma atualização de cluster para 10.2402.3.11, o Get-SolutionUpdate cmdlet pode não responder e, eventualmente, falhar com um RequestTimeoutException após aproximadamente 10 minutos. É provável que isso ocorra após um cenário de adição ou reparo do servidor. |
Use os Start-ClusterGroup cmdlets e Stop-ClusterGroup para reiniciar o serviço de atualização. Get-ClusterGroup -Name "Azure Stack HCI Update Service Cluster Group" | Stop-ClusterGroup Get-ClusterGroup -Name "Azure Stack HCI Update Service Cluster Group" | Start-ClusterGroup Uma execução bem-sucedida desses cmdlets deve colocar o serviço de atualização online. |
||||||||||||||||||
| Atualização com reconhecimento de cluster | Falha ao retomar a operação do nó ao retomar o nó. | Este é um problema transitório e pode ser resolvido por conta própria. Aguarde alguns minutos e repita a operação. Se o problema persistir, contate o Suporte da Microsoft. | ||||||||||||||||||
| Atualização com reconhecimento de cluster | A operação de suspensão do nó ficou travada por mais de 90 minutos. | Este é um problema transitório e pode ser resolvido por conta própria. Aguarde alguns minutos e repita a operação. Se o problema persistir, contate o Suporte da Microsoft. |
Próximas etapas
- Leia a Visão geral da implantação.