Problemas conhecidos na versão do Azure Local 2411
Aplica-se a: Azure Local 2311.2 e posterior
Este artigo identifica problemas conhecidos críticos e suas soluções alternativas na versão do Azure Local 2411.
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 suportados para esta versão, consulte Informações sobre a versão.
Para obter mais informações sobre os novos recursos desta versão, consulte O que há de novo no 23H2.
Problemas conhecidos da versão 2411
Esta versão do software corresponde à versão do software 2411.0.24.
Importante
As novas implantações deste software usarão a compilação 2411.0.22, enquanto que se você atualizar a partir da 2408.2, obterá a compilação 2411.0.24. Nenhuma ação será necessária se você já tiver atualizado de 2408.2 para 2411.0.22.
As notas de versão para esta 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 Azure Local Supportability GitHub.
Problemas corrigidos
Os seguintes problemas foram corrigidos nesta versão:
| Funcionalidade | Questão | Solução alternativa/Comentários |
|---|---|---|
| Gerenciamento de Arc VM | Se tentar ativar a gestão de convidados numa VM migrada, a operação falhará com o seguinte erro: (InternalError) webhook de aprovação "createupdatevalidationwebhook.infrastructure.azstackhci.microsoft.com" negou o pedido: OsProfile não pode ser alterado após a criação do recurso |
Problemas conhecidos nesta versão
A tabela a seguir lista os problemas conhecidos nesta versão:
| Funcionalidade | Questão | Solução alternativa |
|---|---|---|
| Vulnerabilidade de segurança | A Microsoft identificou uma vulnerabilidade de segurança que pode expor as credenciais de administrador local usadas durante a criação de Arc VMs no Azure Local para usuários não administradores na VM e nos hosts. As VMs do Arc em execução em versões anteriores à versão do Azure Local 2411 são vulneráveis. |
Para identificar as VMs Arc que exigem essa alteração e alterar as senhas de conta, consulte instruções detalhadas em: Vulnerabilidade de segurança para VMs Arc no Azure Local. |
| Implantação Atualizar |
Se o fuso horário não estiver definido como UTC antes de implantar o Azure Local, ocorrerá um erro ArcOperationTimeOut durante a validação. A seguinte mensagem de erro é exibida: OperationTimeOut, Nenhuma atualização recebida do dispositivo para operação. | Dependendo do cenário, escolha uma das seguintes soluções alternativas para esse problema: Cenário 1. Antes de iniciar a implantação, verifique se o fuso horário está definido como UTC. Conecte-se a cada um dos nós locais do Azure e altere o fuso horário para UTC. Execute o seguinte comando: Set-TimeZone -Id "UTC". Cenário 2. Se você iniciou a implantação sem definir o fuso horário UTC e recebeu o erro mencionado na fase de validação, siga estas etapas: 1. Conecte-se a cada nó local do Azure. Altere o fuso horário para UTC com Set-TimeZone -Id "UTC". Reinicialize os nós.2. Depois que os nós forem reiniciados, vá para o recurso local do Azure no portal do Azure. Inicie a validação novamente para resolver o problema e continuar com a implantação ou atualização. Para obter etapas detalhadas de correção, consulte o guia de solução de problemas no repositório Azure Local Supportability GitHub. |
| Atualização | Ao atualizar da versão 2408.2.7 para 2411.0.24, o processo de atualização pode falhar com a seguinte mensagem de erro: Type 'CauPreRequisites' of Role 'CAU' raised an exception: Could not finish cau prerequisites due to error 'Cannot remove item C:\UpdateDistribution\<any_file_name>: Access to the path is denied.' |
Para obter etapas detalhadas sobre como mitigar esse problema, consulte Guia de Solução de Problemas Local do Azure para Atualização. |
| Atualização | Com a versão 2411, a solução e a atualização da Extensão do Construtor de Soluções não são combinadas em uma única execução de atualização. | Para aplicar um pacote de extensão do Solution Builder, você precisa de uma execução de atualização separada. |
| Atualização | Ao aplicar a atualização de solução nesta versão, a atualização pode falhar. Isso ocorrerá somente se a atualização tiver sido iniciada antes de 26 de novembro. O problema que causa a falha pode resultar em uma das seguintes mensagens de erro: Erro 1 - A etapa "atualizar ARB e extensão" falhou com erroClear-AzContext 0 e exceção ao chamar "Initialize" com "1" argumento(s): "Object reference not set to an instance of an object." em "Clear-AzPowerShellCache". Erro 2 - A etapa "EvalTVMFlow" erro "CloudEngine.Actions.InterfaceInvocationFailedException: Tipo 'EvalTVMFlow' da função 'ArcIntegration' levantou uma exceção: Este módulo requer Az.Accounts versão 3.0.5. Uma versão anterior do Az.Accounts é importada na sessão atual do PowerShell. Abra uma nova sessão antes de importar este módulo. Esse erro pode indicar que várias versões incompatíveis dos cmdlets do Azure PowerShell estão instaladas em seu sistema. Consulte https://aka.ms/azps-version-error para obter informações sobre solução de problemas." Dependendo da versão dos módulos do PowerShell, o erro acima pode ser relatado para ambas as versões 3.0.4 e 3.0.5. |
Para obter etapas detalhadas sobre como mitigar esse problema, acesse: https://aka.ms/azloc-update-30221399. |
Problemas conhecidos de versões anteriores
A tabela a seguir lista os problemas conhecidos de versões anteriores:
| Funcionalidade | Questão | Solução alternativa | ||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Reparar o servidor | 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 mitigar 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 estado 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 Ative Directory: Set-ADAccountPassword -Identity $Identity -OldPassword $OldPassword -NewPassword $NewPassword |
||||||||||||||||||
| Gerenciamento de VM do Arc | Não é suportado usar um disco do sistema operativo exportado de uma VM do Azure como 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. |
||||||||||||||||||
| Redes | Quando um nó é configurado com um servidor proxy que tem letras maiúsculas no seu endereço, como HTTPS://10.100.000.00:8080, as extensões 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 mitigar 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 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 |
||||||||||||||||||
| Redes | Quando as máquinas Arc ficam fora de serviço, a página "All Clusters" na nova experiência no portal mostra um estado "PartiallyConnected" ou "Not Connected Recently. Mesmo quando as máquinas Arc se tornam saudáveis, elas podem não mostrar um status "Connected". | Não há nenhuma solução conhecida para esse problema. Para verificar o status da conectividade, use a experiência antiga para ver se ela aparece como "Connected". | ||||||||||||||||||
| 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, contate 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 ficar bloqueado 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. |
||||||||||||||||||
| Atualizar | Ao atualizar da versão 2311 ou compilações anteriores para a 2408 ou posterior, as operações de adição e reparo de nós 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, contate o Suporte da Microsoft para determinar as próximas etapas. | ||||||||||||||||||
| Atualizar | Ao exibir os resultados da verificação de preparação para uma instância Local do Azure 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 máquinas locais do Azure, esse erro pode ser visto nos logs de depuração: Encontrou erro interno do servidor. Uma das extensões obrigatórias para implantação de dispositivos pode não estar instalada. | Siga estas etapas para mitigar 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, em que o portal do Azure indica incorretamente o estado da atualização como Falha ao atualizar ou Em andamento, mesmo que a atualização já esteja concluída. |
Conecte-se à sua instância local do Azure através 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.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. Reinicie o grupo de clusters de Gestão 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 tentativas de repetição mostram o MOC na versão de destino, sem sucesso na atualização, e, como resultado, a atualização do Arc Resource Bridge falha. Para validar esse problema, recolha os logs de atualização usando Resolver problemas de atualizações da 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 mitigar o problema: 1. Para encontrar a versão do agente MOC, execute o seguinte comando: 'C:\Program Files\AksHci\wssdcloudagent.exe' version.2. Use o resultado do comando para encontrar a versão do MOC na tabela abaixo que corresponde à versão do agente e defina $initialMocVersion para essa versão do MOC. Defina o $targetMocVersion localizando a compilação Local do Azure para a 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, então $initialMocVersion = "1.0.24.10106" e se estiver a atualizar 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 mocimport-module moc$verbosePreference = "Continue"# Limpar o cache do catálogo SFS Remove-Item (Get-MocConfig).manifestCache# Configure a versão para a versão atual do MOC antes da atualização e defina o estado como atualização falhada 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 Azure Local | A criação do cluster AKS falha com o Error: Invalid AKS network resource id. Esse problema pode ocorrer quando o nome de rede lógica associado tem um sublinhado. |
Os sublinhados não são suportados em nomes de rede lógicos. Certifique-se de não usar sublinhado nos nomes de redes lógicas implantadas em seu Azure Local. | ||||||||||||||||||
| Reparar o servidor | Em casos raros, a operação Repair-Server falha com o erro HealthServiceWaitForDriveFW. 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 Suspend-ClusterNode -Drain PowerShell antes de iniciar Repair-Server. Se o problema ocorrer, contacte o Suporte da Microsoft para obter os próximos passos. |
||||||||||||||||||
| Reparar o servidor | Este problema ocorre quando a instância local do Azure de nó único é atualizada de 2311 para 2402 e depois é efetuada a Repair-Server. A operação de reparo falha. |
Antes de reparar o nó único, siga estes passos: 1. Execute a versão 2402 para o ADPrepTool. Siga as etapas em Preparar Active Directory. Esta 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 seguinte comando: Get-ADComputer <HOSTNAME> | Move-ADObject -TargetPath "<OU path>" |
||||||||||||||||||
| Implantação | Se você preparar o Ative Directory por conta própria (não usando o script e o procedimento fornecidos pela Microsoft), sua validação do Ative Directory poderá falhar com a falta de permissão 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 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 Local. Quando isso ocorre, observa-se a seguinte exceção: 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 está faltando. Aplique a atenuação a seguir nos nós onde 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 atenuação é reiniciar o agente ECE no nó afetado. Em sua máquina, abra uma sessão do PowerShell e execute o seguinte comando:Restart-Service ECEAgent. |
||||||||||||||||||
| Adicionar servidor | Nesta versão e em versões anteriores, ao adicionar uma máquina ao sistema, não é possível atualizar a cadeia de caracteres da lista de bypass de proxy para incluir a nova máquina. A atualização da lista de bypass de proxy das 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, contate o Suporte da Microsoft para determinar as próximas etapas. | ||||||||||||||||||
| Adicionar/Reparar servidor | Nesta versão, ao adicionar ou reparar uma máquina, 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á solução alternativa nesta versão. Se você encontrar esse problema, contate 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/local de segredos. Este é um campo obrigatório marcado como Não obrigatório que resulta em falhas na implantação de modelos 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, em seguida, tente a implantação. Se houver uma falha na implantação, você também deverá limpar os seguintes recursos antes de executar novamente a implantação: 1. Suprimir C:\EceStore. 2. Suprimir C:\CloudDeployment. 3. Suprimir C:\nugetstore. 4. Remove-Item HKLM:\Software\Microsoft\LCMAzureStackStampInformation. |
||||||||||||||||||
| Segurança | Para novas implantações, os dispositivos compatíveis com Secured-core 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 informando que a configuração DRTM não é suportada na versão atual. A Microsoft recomenda uma defesa aprofundada e a Inicialização Segura UEFI ainda protege os componentes na cadeia de inicialização SRT (Static Root of Trust), garantindo que eles sejam carregados somente quando assinados e verificados. |
DRTM não é suportado nesta versão. | ||||||||||||||||||
| Redes | 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 de solução alternativa: 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 até que a implantação ou atualização falhe. 3. Defina novamente a sua lista de exclusão de proxy. |
||||||||||||||||||
| Gerenciamento de Arc VM | A implantação ou atualização do Arc Resource Bridge pode falhar quando o segredo SPN temporário gerado automaticamente durante esta operação começar com um hífen. | Tente novamente a implantação/atualização. A nova tentativa deve regenerar o segredo do SPN e a operação provavelmente terá sucesso. | ||||||||||||||||||
| Gerenciamento de VM do Arc | As Extensões Arc em VMs 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, encontre a propriedade resourcename. Exclua o GUID que é anexado ao final do nome do recurso, para que essa propriedade corresponda ao nome da VM. Em seguida, reinicie a VM. |
||||||||||||||||||
| Gerenciamento de Arc VM | Quando uma nova máquina é adicionada 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 quaisquer novos volumes. Para obter mais informações, consulte Criar um caminho de armazenamento. | ||||||||||||||||||
| Gerenciamento de VM do Arc | A reinicialização da operação do Arc VM é 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 Arc VM | 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 quaisquer recursos, como interfaces de rede associadas a essa rede lógica. Você ainda deve ser capaz de criar recursos nesta rede lógica. Neste caso, o estatuto é enganador. |
Se o status desta rede lógica foi Bem-sucedido no momento em que esta rede foi provisionada, pode continuar a criar recursos nesta rede. | ||||||||||||||||||
| Gerenciamento de Arc VM | 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 Gerir VMs Arc e Gerir recursos de VMs Arc. | ||||||||||||||||||
| Atualização | Em casos raros, 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 vir este problema, contacte o Suporte da Microsoft para o ajudar com os próximos passos. | ||||||||||||||||||
| Redes | Há um problema pouco frequente do cliente DNS nesta versão que faz com que a implantação falhe em um sistema 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 ser criado, resultando em um erro de DNS. | Reinicie o computador. Essa operação registra o registro DNS, o que impede que ele seja excluído. | ||||||||||||||||||
| do portal do Azure | Em alguns casos, o portal do Azure pode demorar um pouco a atualizar e a visualização pode não ser atual. | Talvez seja necessário aguardar 30 minutos ou mais para ver a exibição atualizada. | ||||||||||||||||||
| Gerenciamento de VM do Arc | A exclusão de 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 a interface de rede e, em seguida, excluí-la. Para obter mais informações, consulte Remover a interface de rede e consulte Excluir a interface de rede. | ||||||||||||||||||
| Implantação | Fornecer o nome da UO em uma sintaxe incorreta não é detetado no portal do Azure. A sintaxe incorreta inclui caracteres sem suporte, como &,",',<,>. A sintaxe incorreta é detetada em uma etapa posterior durante a validação do sistema. |
Certifique-se de que 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 expiram após 2 horas. As implantações que excedem 2 horas aparecem como falha no grupo de recursos, embora o sistema tenha sido criado com êxito. | Para monitorizar a implementação no portal do Azure, vá para o recurso de instância Local do Azure e, em seguida, vá para a nova entrada de 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. | ||||||||||||||||||
| Atualizar | Ao atualizar a instância Local do Azure 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 este problema, em cada nó, adicione a seguinte chave do registo (nenhum valor necessário):New-Item -Path "HKLM:\SYSTEM\CurrentControlSet\Services\HciCloudManagementSvc\Parameters" -forceEm seguida, em um dos nós, 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 de progresso ainda podem não ser exibidos durante o processo de atualização. Para obter os detalhes de atualização mais recentes, pode recuperar o progresso da atualização com o PowerShell. |
||||||||||||||||||
| Atualização | Em casos raros, se uma atualização de falha estiver presa num estado Em progresso no Azure Update Manager, o botão Tentar novamente está desativado. | Para retomar a atualização, execute o seguinte comando do PowerShell:Get-SolutionUpdate
|
Start-SolutionUpdate. |
||||||||||||||||||
| Atualização | Em alguns casos, SolutionUpdate comandos podem falhar se executados após o comando Send-DiagnosticData. |
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, os relatórios de estado do sistema indicam Em andamento em vez do esperado Falha ao atualizar. | Tente atualizar novamente. Se o problema persistir, contacte o Suporte da Microsoft. | ||||||||||||||||||
| Atualização | As tentativas de instalar atualizações da 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 de Cluster Name ou Cluster IP Address falharem ao iniciar após a reinicialização de um nó e é mais comum em implantações pequenas. |
Se você encontrar esse problema, contate o suporte da Microsoft para as próximas etapas. Eles podem trabalhar com você para reiniciar manualmente os recursos locais do Azure e retomar a atualização conforme necessário. | ||||||||||||||||||
| Atualização | Ao aplicar uma atualização do sistema a 10.2402.3.11, o cmdlet Get-SolutionUpdate 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 de 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 destes "cmdlets" deve ativar o serviço de atualização. |
||||||||||||||||||
| Atualização com reconhecimento de cluster | Falha ao retomar a operação do nó. | Esta é uma questão transitória e poderia ser resolvida por si só. Aguarde alguns minutos e tente novamente a operação. Se o problema persistir, contacte o Suporte da Microsoft. | ||||||||||||||||||
| Atualização com reconhecimento de cluster | A operação do nó de suspensão ficou bloqueada por mais de 90 minutos. | Esta é uma questão transitória e poderia ser resolvida por si só. Aguarde alguns minutos e tente novamente a operação. Se o problema persistir, contacte o Suporte da Microsoft. |