Exibir problemas conhecidos na versão do Azure Stack HCI 2402.4
Aplica-se a: Azure Local 2311.2 e posterior
Este artigo identifica os problemas conhecidos críticos e suas soluções alternativas na versão do Azure Stack HCI 2402.4.
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 seu dispositivo Azure Stack HCI, reveja cuidadosamente as informações contidas nas notas sobre a versão.
Observação
Para entender os caminhos de atualização compatíveis com esta versão, consulte Azure Stack HCI, versão 23H2.
Para obter mais informações sobre os novos recursos nesta versão, consulte Novidades na 23H2.
Problemas da versão 2402.4
Esta versão de software corresponde ao número da versão de software 2402.4.4.
As notas de versão desta versão incluem os problemas corrigidos nesta versão, problemas conhecidos nesta versão e problemas de anotação de versão carregados de versões anteriores.
Problemas corrigidos
A Microsoft não tem conhecimento de nenhum problema corrigido nesta versão.
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 das versões anteriores:
Recurso | Problema | Solução alternativa |
---|---|---|
AKS no HCI | A criação de cluster do AKS falha com o Error: Invalid AKS network resource id . Esse problema pode ocorrer quando o nome da rede lógica associada está sublinhado. |
Não há suporte para sublinhados em nomes de rede lógica. Certifique-se de não usar sublinhado nos nomes para redes lógicas implantadas no Azure Stack HCI. |
Reparar servidor | Em raras instâncias, a operação Repair-Server falha com o erro HealthServiceWaitForDriveFW . Nesses casos, as unidades antigas do nó reparado não são removidas e novos discos ficam presos no modo de manutenção. |
Para evitar esse problema, certifique-se de NÃO desativar o nó por meio do Windows Admin Center ou usando o cmdlet do PowerShell Suspend-ClusterNode -Drain antes de iniciar o Repair-Server . Se o problema ocorrer, entre em contato com o Suporte da Microsoft para obter as próximas etapas. |
Reparar servidor | Esse problema é visto quando o servidor único Azure Stack HCI é atualizado de 2311 para 2402 e, em seguida, o Repair-Server é executado. A operação de reparo falha. |
Antes de reparar o nó individual, siga estas etapas: 1. Execute a versão 2402 do 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. Mover 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), sua validação do Active Directory poderá falhar com a permissão de Generic All ausente. Isso ocorre devido a um problema na verificação da validação, que confere se há uma entrada de permissão dedicada para msFVE-RecoverInformationobjects – General – Permissions Full control , o que é necessário para a recuperação do BitLocker. |
Use o método de script Preparar o AD ou, se estiver usando seu próprio método, atribua a permissão específica msFVE-RecoverInformationobjects – General – Permissions Full control . |
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á faltando. Nos nós em que o registro DNS estiver ausente, aplique a mitigação a seguir. Reinicie o serviço do 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/reparar servidor | Nesta versão, ao adicionar ou reparar um servidor, uma falha é vista quando o balanceador de carga de software ou os certificados de VM 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á nenhuma 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 em 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 problema é transitório, isso pode ser corrigido repetindo a implantação. Para obter mais informações, consulte como Executar novamente a implantação. |
Implantação | Nesta versão, há um problema com o campo URI de Segredos/local. 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 em Implantar Azure Stack HCI, versão 23H2 por meio do modelo do Azure Resource Manager, para garantir que todas as entradas sejam fornecidas no formato necessário, e depois tente fazer a implantação. Se houver uma implantação com falha, você também deverá limpar os seguintes recursos antes de reexecutar a implantação: 1. Exclua C:\EceStore . 2. Exclua C:\CloudDeployment . 3. Exclua C:\nugetstore . 4. Remove-Item HKLM:\Software\Microsoft\LCMAzureStackStampInformation . |
Segurança | Nas novas implantações, os dispositivos compatíveis com núcleo protegido não terão a Raiz Dinâmica de Medida (DRTM) habilitada por padrão. Se você tentar habilitar (DRTM) usando o cmdlet Enable-AzSSecurity, verá um erro de incompatibilidade da configuração de DRTM com a versão atual. A Microsoft recomenda a defesa em profundidade, e o Boot Seguro UEFI ainda protege os componentes na cadeia de inicialização SRT (Raiz Estática de Confiança), garantindo que eles sejam carregados somente quando assinados e verificados. |
O DRTM não é compatível com esta versão. |
Rede | Quando um servidor proxy é usado, a verificação de ambiente falha. 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 soluções 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, espere até que a implantação ou a atualização falhe. 3. Defina sua lista de bypass de proxy novamente. |
Gerenciamento de VM Arc | A implantação ou atualização de Ponte de recursos do Arc pode falhar quando o segredo SPN temporário, gerado automaticamente durante essa operação, começa com um hífen. | Tente executar a implantação/atualização novamente. A repetição deve gerar novamente o segredo do SPN e a operação provavelmente terá êxito. |
Gerenciamento de VM Arc | As Extensões do Arc em Máquinas Virtuais Arc permanecem no estado "Criando" indefinidamente. | Entre na VM, abra um prompt de comando e digite o seguinte: Windows: notepad C:\ProgramData\AzureConnectedMachineAgent\Config\agentconfig.json Linux: sudo vi /var/opt/azcmagent/agentconfig.json Em seguida, localize a propriedade resourcename . Exclua o GUID que é anexado ao final do nome do recurso, de modo que essa propriedade corresponda ao nome da VM. Em seguida, reinicie a VM. |
Gerenciamento de VM 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. | O caminho de armazenamento para novos volumes pode ser criado manualmente. Para obter mais informações, consulte Criar um caminho de armazenamento. |
Gerenciamento de VM Arc | A reinicialização da operação de VM 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 Arc | Em certas instâncias, o status da rede lógica é exibido como Falhou no portal do Azure. Isso ocorre quando você tenta excluir a rede lógica sem primeiro excluir recursos, tais como adaptadores de rede associados a aquela rede lógica. Mas ainda deve ser possível criar recursos nessa rede lógica. O status é enganoso nesta instância. |
Se o status dessa rede lógica tenha foi Bem-sucedido no momento em que foi provisionada, você pode continuar a criar recursos nessa rede. |
Gerenciamento de VM Arc | Nesta versão, ao atualizar 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 localizar um disco rígido virtual com o nome. |
Use o portal do Azure para todas as operações de atualização da VM. Para obter mais informações, consulte Gerenciar VMs Arc e Gerenciar recursos de VM Arc. |
Atualização | Em casos raros, você pode encontrar esse erro ao atualizar o Azure Stack HCI: o tipo 'UpdateArbAndExtensions' da função 'MocArb' gerou uma exceção: exceção ao atualizar a ARB e a extensão na etapa [UpgradeArbAndExtensions :Get-ArcHciConfig] UpgradeArb: Invalid applianceyaml = [C:\AksHci\hci-appliance.yaml]. | Se você vir esse problema, entre em contato com o Suporte da Microsoft para ajudar você com as próximas etapas. |
Rede | Há um problema pouco frequente no cliente DNS nesta versão que faz com que o processo de implantação falhe em um cluster de dois nós com um erro de resolução de DNS: ocorreu um WebException ao enviar um RestRequest. WebException.Status: NameResolutionFailure. Como resultado do bug, o registro DNS do segundo nó é deletado logo após ser criado, causando um erro de DNS. | Reinicie o servidor. Essa operação documenta o registro DNS, o que impede que ele seja excluído. |
Portal do Azure | Em certas instâncias, o portal do Azure pode demorar um pouco para ser atualizado e a exibição pode não ser atual. | Talvez seja necessário aguardar 30 minutos ou mais para ver o modo de exibição atualizado. |
Gerenciamento de VM do Arc | Excluir 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 a interface de rede e consulte Excluir a interface de rede. |
Implantação | A apresentação do nome da UO em uma sintaxe incorreta não é identificada no portal do Azure. A sintaxe incorreta inclui caracteres incompatíveis, tais 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 não suportados. |
Implantação | As implantações por meio do Azure Resource Manager atingem o tempo limite após 2 horas. Implantações que excedam 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 do cluster do Azure Stack HCI e vá para a entrada de novas 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 Gerenciador de Atualizações do Azure, o progresso e os resultados da atualização podem não estar visíveis no portal do Azure. | Para contornar esse problema adicione, em cada nó de cluster, a seguinte chave do registro (não é necessário nenhum valor):New-Item -Path "HKLM:\SYSTEM\CurrentControlSet\Services\HciCloudManagementSvc\Parameters" -force Em seguida, em um dos nós de cluster, reinicie o grupo de clusters de Gerenciamento de Nuvem. Stop-ClusterGroup "Cloud Management" Start-ClusterGroup "Cloud Management" Isso não corrigirá o problema totalmente, porque os detalhes do progresso podem não ser exibidos durante o processo de atualização. Para obter os detalhes mais recentes da atualização, você pode Recuperar o progresso da atualização com o PowerShell. |
Atualização | Em raras instâncias, se uma atualização com falha ficar travada em um estado de Em andamento no Gerenciador de Atualizações do Azure, 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 certos casos, os comandos SolutionUpdate podem falhar se forem executados após o comando Send-DiagnosticData . |
Feche a sessão do PowerShell utilizada para Send-DiagnosticData . Abra uma nova sessão do PowerShell e utilize-a para comandos SolutionUpdate . |
Atualização | Em instâncias raras, ao aplicar uma atualização de 2311.0.24 para 2311.2.4, os relatórios de status do cluster mostram 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 do 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 Cluster Name ou Cluster IP Address não forem iniciados após uma reinicialização de nó, sendo mais típico 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 os recursos do cluster manualmente e retomar a atualização conforme necessário. |
Atualização | Ao aplicar uma atualização do cluster à 10.2402.4.11, o Get-SolutionUpdate cmdlet pode não responder e, eventualmente, falhar com uma RequestTimeoutException após aproximadamente 10 minutos. É provável que isso ocorra após um cenário de adicionar ou reparar servidores. |
Use os cmdlets Start-ClusterGroup 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 ativar o serviço de atualização. |
Atualização com suporte a cluster | Falha ao retomar a operação do nó. | Esse é 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 suporte a cluster | A operação Suspender nó ficou paralisada por mais de 90 minutos. | Esse é 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.