Problemas conhecidos na versão 2408.1 do Azure Stack HCI
Aplica-se a: Azure Stack HCI, versão 23H2
Este artigo identifica problemas críticos conhecidos e suas soluções alternativas na versão 2408.1 do Azure Stack HCI.
Essas notas de versão são atualizadas continuamente e, à medida que problemas críticos que exigem uma solução alternativa são descobertos, elas são adicionadas. Antes de implantar o Azure Stack HCI, examine cuidadosamente as informações contidas aqui.
Importante
Para obter informações sobre os caminhos de atualização com suporte para esta versão, consulte Informações sobre a versão.
Para obter mais informações sobre os novos recursos desta versão, consulte Novidades no 23H2.
Problemas conhecidos da versão 2408.1
Esta versão do software é mapeada para o número da versão do software 2408.1.9.
As notas de versão desta versão incluem os problemas corrigidos nesta versão, problemas conhecidos nesta versão e problemas de nota de versão transferidos de versões anteriores.
Observação
Para obter uma correção detalhada para problemas comuns conhecidos, consulte o repositório GitHub de capacidade de suporte do Azure Stack HCI.
Problemas corrigidos
Os seguintes problemas foram corrigidos nesta versão:
| Recurso | Problema | Solução alternativa/comentários |
|---|---|---|
| Gerenciamento de VM do Arc | O endereço MAC do adaptador de rede da VM não apareceria se o cliente não passasse o endereço mac no momento da criação. | |
| Atualização | O agente de nó MOC ficaria preso em um estágio pendente de reinicialização durante a etapa de atualização do MOC. | |
| Atualização | As permissões necessárias não foram concedidas durante a atualização, o que fez com que a atualização falhasse posteriormente. | |
| Melhoramento | Adicionada validação para verificar se há um endereço IPv6. | |
| Atualizar | As interfaces SBE não seriam executadas em todos os servidores se o nome do host no cluster fosse um subconjunto de outro nome de host. |
Problemas conhecidos nesta versão
A Microsoft não está ciente de nenhum problema conhecido nesta versão.
Problemas conhecidos de versões anteriores
A tabela a seguir lista os problemas conhecidos de versões anteriores:
| Recurso | Problema | Solução alternativa | ||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Servidor de reparo | Depois de reparar um nó e executar o comando Set-AzureStackLCMUserPassword, você pode encontrar o seguinte erro: 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 |
Siga estas etapas para atenuar o problema: $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. Importe o módulo necessário: Import-Module "C:\Program Files\WindowsPowerShell\Modules\Microsoft.AS.Infra.Security.SecretRotation\PasswordUtilities.psm1" -DisableNameChecking 2. Verifique o status do grupo de clusters 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. Atualize o ECE com a nova senha: 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. Atualize a senha no Active Directory: Set-ADAccountPassword -Identity $Identity -OldPassword $OldPassword -NewPassword $NewPassword |
||||||||||||||||||
| Gerenciamento de VM do Arc | Não há suporte para o uso de um disco exportado do sistema operacional da VM do Azure como um VHD para criar uma imagem de galeria para provisionar uma VM do Arc. | Execute o comando restart-service mochostagent para reiniciar o serviço mochostagent. |
||||||||||||||||||
| Rede | Quando um nó é configurado com um servidor proxy que tem letras maiúsculas em seu endereço, como HTTPS://10.100.000.00:8080, as extensões do Arc não são instaladas ou atualizadas no nó em compilações existentes, incluindo a versão 2408.1. No entanto, o nó permanece conectado ao Arc. | Siga estas etapas para atenuar o problema: 1. Defina os valores do ambiente em minúsculas. [System.Environment]::SetEnvironmentVariable("HTTPS_PROXY", "https://10.100.000.00:8080", "Machine"). 2. Valide se os valores foram definidos. [System.Environment]::GetEnvironmentVariable("HTTPS_PROXY", "Machine"). 3. Reinicie os serviços do Arc. Restart-Service himds Restart-Service ExtensionService Restart-Service GCArcService 4. Sinalize o AzcmaAgent com as informações de proxy em minúsculas. & 'C:\Program Files\AzureConnectedMachineAgent\azcmagent.exe' config set proxy.url https://10.100.000.00:8080 & 'C:\Program Files\AzureConnectedMachineAgent\azcmagent.exe' config list |
||||||||||||||||||
| Rede | Quando as máquinas Arc ficam inativas, a página "Todos os Clusters", na nova experiência do portal, mostra um status "Parcialmente Conectado" ou "Não Conectado Recentemente . Mesmo quando as máquinas Arc se tornam íntegras, elas podem não mostrar um status "Conectado". | Não há nenhuma solução alternativa conhecida para esse problema. Para verificar o status da conectividade, use a experiência antiga para ver se ela é exibida como "Conectado". | ||||||||||||||||||
| Segurança | O recurso de segurança SideChannelMitigation pode não mostrar um estado habilitado, mesmo que esteja habilitado. | 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. | ||||||||||||||||||
| Gerenciamento de VM do Arc | O serviço Mochostagent pode parecer estar em execução, mas pode travar sem atualizar os logs por mais de um mês. Você pode identificar esse problema verificando os logs C:\programdata\mochostagent\logs de serviço para ver se os logs estão sendo atualizados. |
Execute o seguinte comando para reiniciar o serviço mochostagent: restart-service mochostagent. |
||||||||||||||||||
| Melhoramento | Ao atualizar o carimbo de 2311 ou compilações anteriores para 2408 ou posterior, as operações de adição de nó e nó de reparo podem falhar. Por exemplo, você pode ver um erro: Type 'AddAsZHostToDomain' of Role 'BareMetal' raised an exception. |
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. | ||||||||||||||||||
| 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 no 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. | ||||||||||||||||||
| Atualizar | 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ção | 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.