Problemas conhecidos na versão do Azure Local 2408
Aplica-se a: Azure Local, versão 23H2
Este artigo identifica problemas conhecidos críticos e suas soluções alternativas na versão do Azure Local 2408.
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 sua instância local do Azure, 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 novos recursos nesta versão, consulte O que há de novo em 23H2.
Problemas conhecidos para a versão 2408
Esta versão de software corresponde à versão de software 2408.0.29.
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.
Nota
Para obter uma correção detalhada de problemas conhecidos comuns, consulte o repositório do GitHub do Suporte local do Azure.
Problemas corrigidos
Os seguintes problemas são corrigidos nesta versão:
Característica | Questão | Solução alternativa/comentários |
---|---|---|
Atualizações | Um problema de atualização relacionado ao campo ID do tipo de recurso ausente nas verificações de integridade foi corrigido. | |
Atualizações | Um problema de atualização relacionado a verificações de integridade diferentes com o mesmo nome foi corrigido. | |
Gerenciamento de VM do Arc | Em cenários de implantação em grande escala, como implantações extensas de pools de hosts do AVD ou provisionamento de VMs em larga escala, você pode encontrar questões de confiabilidade causadas por um problema em uma biblioteca externa de soquete Hyper-V. |
Problemas conhecidos nesta versão
A tabela a seguir lista os problemas conhecidos nesta versão:
Característica | Questão | Solução alternativa |
---|---|---|
Reparar o servidor | Depois de reparar um nó e executar o comando Set-AzureStackLCMUserPassword , você poderá 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. Importar 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 | O uso de um disco de SO da VM do Azure exportado como um VHD para criar uma imagem da galeria para provisionar uma VM Arc não é compatível. | Execute o comando restart-service mochostagent para reiniciar o serviço mochostagent. |
Gerenciamento de VM do Arc | Se você tentar habilitar o gerenciamento de convidados em uma VM migrada, a operação falhará com o seguinte erro: (InternalError) o webhook de admissão "createupdatevalidationwebhook.infrastructure.azstackhci.microsoft.com" negou a solicitação: OsProfile não pode ser alterado após a criação do recurso | |
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 Arc não conseguem instalar ou atualizar no nó em builds existentes, incluindo a versão 2408. No entanto, o nó permanece conectado ao Arc. | Siga estas etapas para atenuar o problema: 1. Defina os valores de ambiente em letras 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 letras 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 são desativadas, 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 de conectividade, use a antiga experiência para ver se ela é mostrada como "Conectado". |
Segurança | O recurso de segurança SideChannelMitigation pode não mostrar um estado habilitado mesmo que esteja habilitado. Isso acontece ao usar o Windows Admin Center (Modo de Exibição de Segurança do Cluster) ou quando esse cmdlet retorna False: Get-AzSSecurity -FeatureName SideChannelMitigation . |
Não há nenhuma solução alternativa nesta versão para corrigir a saída desses aplicativos. Para validar o valor esperado, execute o seguinte cmdlet: Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management' -name "FeatureSettingsOverride*" A saída esperada é: FeatureSettingsOverride: 83886152 FeatureSettingsOverrideMask: 3 Se a saída corresponder à saída esperada, você poderá ignorar com segurança a saída do Windows Admin Center e Get-AzSSecurity cmdlet. |
Gerenciamento de VM do Arc | O serviço Mochostagent pode parecer estar em execução, mas pode ficar travado sem atualizar os logs por mais de um mês. Você pode identificar esse problema verificando os logs de serviço no C:\programdata\mochostagent\logs para ver se os logs estão sendo atualizados. |
Execute o seguinte comando para reiniciar o serviço mochostagent: restart-service mochostagent . |
Upgrade | Ao atualizar o carimbo de 2311 ou builds anteriores para 2408 ou posteriores, as operações de adicionar nó e reparar nó poderão falhar. Por exemplo, você pode ver um erro: Type 'AddAsZHostToDomain' of Role 'BareMetal' raised an exception . |
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. |
Atualização | Ao instalar uma atualização do SBE para seu sistema local do Azure, algumas interfaces SBE não serão executadas em todos os computadores se o nome do host no cluster for um subconjunto de outro nome de host. Por exemplo, host-1 é um subconjunto de host-10. Isso pode resultar em falhas na verificação da CAU ou na execução da CAU. | A Microsoft recomenda usar pelo menos dois dígitos para a contagem de instâncias de nomes de host nas suas convenções de nomenclatura de hosts. Para obter mais informações, consulte Defina sua convenção de nomenclatura. |
Problemas conhecidos de versões anteriores
A tabela a seguir lista os problemas conhecidos das versões anteriores:
Característica | Questão | Solução alternativa | ||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Atualização | Ao exibir os resultados de verificação de preparação para uma instância local do Azure por meio do Gerenciador de Atualizações do Azure, 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 máquinas locais do Azure, esse erro pode ser visto nos logs de depuração: encontrado erro interno do servidor. 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 |
||||||||||||||||||
Atualização | Há um problema intermitente nesta versão quando o portal do Azure relata incorretamente o status da atualização como Falha na atualização ou Em andamento mesmo quando a atualização está concluída. | Conecte-se à sua instância local do Azure 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 cadeia de caracteres de versão pela versão que você está executando. Por exemplo, "10.2405.0.23". $Update.state Se 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 dentro de 24 horas. Para atualizar o status mais cedo, siga estas etapas em um dos nós do cluster. Reinicie o grupo de clusters de 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 moc de destino não ser encontrada no cache do catálogo. As atualizações de acompanhamento e tentativas de repetição mostram o MOC na versão alvo, sem que a atualização seja bem-sucedida e, como resultado, a atualização da ponte de recursos do Arc falha. Para validar esse problema, colete os logs de atualização usando Solucionar problemas de atualizações de solução para o Azure Local, versão 23H2. Os arquivos de log devem mostrar uma mensagem de erro semelhante (a versão atual pode diferir 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 localizar 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 localizar a versão moc da tabela abaixo que corresponde à versão do agente e defina $initialMocVersion para essa versão do MOC. Defina o $targetMocVersion encontrando o build local do Azure para o qual você está atualizando e obtenha a versão do MOC correspondente da 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, então $initialMocVersion = "1.0.24.10106" , e 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>" # Importar módulo MOC duas vezes import-module moc import-module moc $verbosePreference = "Continue" # Limpar o cache do catálogo do SFS Remove-Item (Get-MocConfig).manifestCache # Configurar a versão para a versão atual do MOC antes da atualização e definir o estado como atualização falhou Set-MocConfigValue -name "version" -value $initialMocVersion Set-MocConfigValue -name "installState" -value ([InstallState]::UpdateFailed) # Executar novamente a atualização do MOC para a versão desejada Update-Moc -version $targetMocVersion 4. Retome a atualização. |
||||||||||||||||||
AKS em 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 associado tem um sublinhado. |
Não há suporte para sublinhados em nomes de rede lógica. Certifique-se de não usar sublinhado nos nomes das redes lógicas implantadas na sua instância do Azure Local. | ||||||||||||||||||
Reparar o servidor | Em instâncias raras, 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 Suspend-ClusterNode -Drain PowerShell antes de iniciar o Repair-Server . Se o problema ocorrer, entre em contato com o Suporte da Microsoft para as próximas etapas. |
||||||||||||||||||
Reparar o servidor | Esse problema é visto quando uma instância local do Azure de nó único é atualizada 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 para o ADPrepTool. Siga as etapas em Preparar o Active Directory. Essa ação é rápida e adiciona as permissões necessárias à UO (Unidade Organizacional). 2. Mover o objeto de computador do segmento Computadores para a UO raiz. Execute o seguinte comando: 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 de validação que verifica 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 Prepare 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 local do Azure. 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 de cluster está ausente. Aplique a seguinte mitigação nos nós em que o registro DNS está ausente. Reinicie o serviço 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 computador, abra uma sessão do PowerShell e execute o seguinte comando:Restart-Service ECEAgent . |
||||||||||||||||||
Adicionar servidor | Nesta versão e nas versões anteriores, ao adicionar um computador ao cluster, não é possível atualizar a cadeia de caracteres da lista de bypass de proxy para incluir o novo computador. A atualização da lista de exceção de proxy das variáveis de ambiente nos hosts não atualizará a lista de exceção de proxy na ponte de recursos do Azure ou no AKS. | 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. | ||||||||||||||||||
Adicionar/reparar servidor | Nesta versão, ao adicionar ou reparar um computador, 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 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, tentar novamente 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 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 no Implantar o Azure Local, versão 23H2 por meio do modelo do Azure Resource Manager para garantir que todas as entradas sejam fornecidas no formato necessário e tente 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. Excluir C:\EceStore . 2. Excluir C:\CloudDeployment . 3. Excluir 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 Raiz Dinâmica de Medição (DRTM) habilitada por padrão. Se você tentar habilitar (DRTM) usando o cmdlet Enable-AzSSecurity, verá um erro de que a configuração drtm não tem suporte na versão atual. A Microsoft recomenda a defesa em profundidade, e o UEFI Secure Boot ainda protege os componentes na cadeia de inicialização da Raiz Estática de Confiança (SRT), garantindo que eles sejam carregados somente quando 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 padrão, a lista de bypass é diferente para winhttp e wininet, o que faz com que a 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. Configure novamente sua lista de exclusão de proxy. |
||||||||||||||||||
Gerenciamento de VMs 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, começa com um hífen. | Tente novamente a implantação/atualização. A tentativa novamente deve regenerar o segredo do SPN e é provável que a operação tenha sucesso. | ||||||||||||||||||
Gerenciamento de VM do 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 é acrescentado ao final do nome do recurso, de modo que essa propriedade corresponda ao nome da VM. Em seguida, reinicie a VM. |
||||||||||||||||||
Gerenciamento de VM do Arc | Quando um novo computador é adicionado a uma instância local do Azure, 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 Arc é concluída após aproximadamente 20 minutos, embora a própria VM reinicie 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 é exibido como Falha no portal do Azure. Isso ocorre quando você tenta excluir a rede lógica sem primeiro excluir recursos, 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 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, 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 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 instâncias raras, você pode encontrar esse erro ao atualizar sua instância local do 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] . |
Se você vir 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 de DNS: Uma WebException ocorreu ao enviar um RestRequest. WebException.Status: NameResolutionFailure. Como resultado do bug, o registro de DNS do segundo nó é excluído logo após ser criado, o que resulta em um erro de DNS. | Reinicie o computador. 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 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 uma interface de rede em uma VM 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 sem suporte, 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 | Implantações de recursos por meio do Azure Resource Manager expiram 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 instância local do Azure e vá para a entrada de novas Implantações. | ||||||||||||||||||
Azure Site Recovery | O Azure Site Recovery não pode ser instalado em uma instância local do Azure nesta versão. | Não há nenhuma solução alternativa conhecida nesta versão. | ||||||||||||||||||
Atualização | Ao atualizar a instância local do Azure por meio do Gerenciador de Atualizações do Azure, o progresso da atualização e os resultados 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" -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á totalmente o problema, pois os detalhes do progresso ainda 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 instâncias raras, se uma atualização com falha estiver presa em um Em andamento estado 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 alguns casos, os comandos SolutionUpdate podem falhar se forem executados após o comando Send-DiagnosticData . |
Feche a sessão do PowerShell usada para Send-DiagnosticData . Abra uma nova sessão do PowerShell e use-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. | Tente novamente a atualização. Se o problema persistir, entre em contato com 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 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 à 10.2402.3.11, o cmdlet Get-SolutionUpdate 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 o servidor. |
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, entre em contato com o Suporte da Microsoft. | ||||||||||||||||||
Atualização com suporte a cluster | A operação de nó de suspensão 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, entre em contato com o Suporte da Microsoft. |
Próximas etapas
- Leia a visão geral da Implantação.