Resolver problemas de Cache conectado da Microsoft para empresas e instituições de ensino

Este artigo contém instruções sobre como resolver problemas diferentes que possa encontrar ao utilizar a Cache Ligada. Estes problemas são categorizados pela tarefa na qual podem ser encontrados.

Problemas conhecidos

Esta secção descreve problemas conhecidos com a versão mais recente do Cache conectado da Microsoft para empresas e instituições de ensino. Consulte a página Notas de Versão para obter mais detalhes sobre as correções incluídas na versão mais recente.

O recurso Azure cache ligada está em falta na seleção de Âmbito no separador "Métricas"

Pode criar gráficos personalizados no portal do Azure cache ligada ao selecionar o separador Métricas na secção Monitorização do recurso Azure Cache Ligada. O recurso Azure cache ligada está corretamente selecionado como Âmbito por predefinição, mas se alterar o Âmbito selecionado, não poderá voltar a selecionar o recurso Azure Cache Ligada, impedindo a criação subsequente de gráficos personalizados.

Como solução temporária, pode navegar para fora do separador Métricas e, em seguida, regressar ao mesmo. O recurso Azure cache ligada está novamente selecionado corretamente como Âmbito.

limitações de importCert.ps1

O importCert.ps1 script é utilizado para importar certificados para o arquivo de certificados do Windows como parte do processo de configuração HTTPS para nós de cache alojados no Windows. A aplicação Windows de Cache Ligada v1.0.24.0 não suporta a execução deste script em nós de cache implementados no Windows Server 2022 ou Windows Server 2025 com uma conta de runtime da Cache Ligada gMSA. Utilize a aplicação v1.0.26.0 ou posterior para executar este script nesses ambientes.

Limitações de aplicações do instalador do Windows em Cache Ligada

A aplicação do instalador do Windows de Cache Ligada é um pacote MSIX que é utilizado para implementar a Cache Ligada em máquinas anfitriãs do Windows. Atualmente, a aplicação do instalador não suporta Windows Server Core.

Corrigido na versão mais recente

Versão ga: 23/07/2025

• A instalação da Cache Ligada falha quando o computador anfitrião do Windows está configurado com uma região não EN.
• Os nós da Cache Ligada alojada no Windows podem aumentar para além do tamanho da unidade de cache configurada.

Passos para obter um ID de subscrição Azure

1. Inicie sessão no portal do Azure.
2. Selecione Subscrições. Se não vir Subscrições, escreva Subscrições na barra de pesquisa. À medida que começa a escrever, a lista filtra com base na sua entrada.
3. Se já tiver uma Subscrição Azure, avance para o passo 5. Se não tiver uma Subscrição Azure, selecione + Adicionar no canto superior esquerdo.
4. Selecione a subscrição Pay As You Go . Ser-lhe-á pedido para introduzir informações de card de crédito, mas não lhe será cobrada a utilização do serviço Cache Ligada da Microsoft.
5. Na página Subscrições , encontrará detalhes sobre a sua subscrição atual. Selecione o nome da subscrição.
6. Depois de selecionar o nome da subscrição, encontrará o ID da subscrição no separador Descrição geral . Selecione o ícone Copiar para a área de transferência junto ao ID da Subscrição para copiar o valor.

Resolver problemas Azure criação de recursos

A criação de recursos Azure cache ligada pode ser iniciada através da interface de utilizador portal do Azure ou do conjunto de comandos da CLI Azure.

Se encontrar um erro durante a criação de recursos, marcar que tem as permissões necessárias para criar Azure recursos na sua subscrição e preencheu todos os campos necessários durante o processo de criação de recursos.

Resolução de problemas de configuração do nó de cache

A configuração do nó cache ligada pode ser feita com a interface de utilizador portal do Azure ou o conjunto de comandos da CLI Azure.

Se encontrar um erro de validação, marcar que preencheu todos os campos de configuração necessários.

Se a configuração não parecer estar a entrar em vigor, marcar que selecionou a opção Guardar na parte superior da página de configuração no portal do Azure interface de utilizador.

Se tiver alterado a configuração do proxy, terá de reimplementar o software de Cache Ligada no computador anfitrião para que a configuração do proxy entre em vigor.

Resolver problemas de implementação do nó de cache no computador anfitrião do Windows

Recolher registos de instalação alojados no Windows

A implementação de um nó de Cache Ligada num computador anfitrião do Windows envolve a execução de uma série de scripts do PowerShell contidos na aplicação Windows de Cache Ligada. Estes scripts tentam escrever ficheiros de registo no diretório de script da aplicação de Cache Ligada, especificado por deliveryoptimization-cli mcc-get-scripts-path.

Existem três tipos de ficheiros de registo de instalação:

1. WSL_Mcc_Install_Transcript: este ficheiro de registo regista as linhas impressas na janela do PowerShell ao executar o script de instalação
2. WSL_Mcc_Install_FromRegisteredTask_Status: este ficheiro de registo regista a status de alto nível que é escrita durante a instalação das tarefas registadas
3. WSL_Mcc_Install_FromRegisteredTask_Transcript: este ficheiro de registo regista os status detalhados escritos durante a instalação das tarefas registadas

A Transcrição de Tarefas Registadas é normalmente a mais útil para diagnosticar o problema de instalação.

Recolher outros registos alojados no Windows

Assim que o nó de cache tiver sido instalado com êxito no computador anfitrião do Windows, irá escrever periodicamente ficheiros de registo no diretório de instalação (C:\mccwsl01\ por predefinição).

Pode esperar ver os seguintes tipos de ficheiros de registo:

1. WSL_Mcc_Monitor_FromRegisteredTask_Transcript: este ficheiro de registo regista a saída da tarefa agendada "MCC_Monitor_Task" que é responsável por garantir que a Cache Ligada continua em execução.
2. WSL_Mcc_UserUninstall_Transcript: este ficheiro de registo regista a saída do script "uninstallmcconwsl.ps1" que o utilizador pode executar para desinstalar o software de Cache Ligada do computador anfitrião.
3. WSL_Mcc_Uninstall_FromRegisteredTask_Transcript: este ficheiro de registo regista a saída da tarefa agendada "MCC_Uninstall_Task" responsável pela desinstalação do software de Cache Ligada do computador anfitrião quando chamado pelo script "uninstallmcconwsl.ps1".

Iniciar um processo do PowerShell como a conta de runtime da Cache Ligada

Para resolver problemas com o software de Cache Ligada num computador anfitrião Windows, poderá ter de executar comandos como a conta de runtime da Cache Ligada. Pode fazê-lo ao iniciar um processo do PowerShell como a conta de runtime especificada durante a instalação da Cache Ligada.

• Se a conta de runtime for uma conta local, pode iniciar um processo do PowerShell como a conta de runtime ao executar o seguinte comando numa janela elevada do PowerShell:

  Start-Process powershell.exe -Credential (Get-Credential "<RuntimeAccountName>") -ArgumentList '-NoExit'
  

• Se a conta de runtime for um domínio ou conta de serviço, pode iniciar um processo do PowerShell como a conta de runtime ao executar o seguinte comando numa janela elevada do PowerShell:

  Start-Process powershell.exe -Credential (Get-Credential "<Domain>\<RuntimeAccountName>") -ArgumentList '-NoExit'
  

• Se a conta de runtime for uma Conta de Serviço Gerida de Grupo (gMSA), tem de utilizar o PsExec para iniciar um processo do PowerShell como a conta de runtime ao executar o seguinte comando numa janela elevada do PowerShell:

  psexec.exe -i -u <DOMAIN\GmsaAccountName$> -p ~ powershell.exe 
  

Verificar se o contentor da Cache Ligada está em execução

Depois de o software de Cache Ligada ter sido implementado com êxito no computador anfitrião do Windows, pode marcar se o nó de cache estiver a ser executado corretamente ao fazer o seguinte no computador anfitrião do Windows:

1. Iniciar um processo do PowerShell como a conta especificada como a conta de runtime durante a instalação da Cache Ligada
2. Execute wsl -d Ubuntu-24.04-Mcc para aceder à distribuição de Linux que aloja o contentor da Cache Ligada
3. Execute sudo iotedge list para mostrar que contentores estão em execução no runtime do IoT Edge

Se mostrar os contentores edgeAgent e edgeHub, mas não mostrar o MCC, pode ver a status do gestor de segurança do IoT Edge com sudo iotedge system logs -- -f.

Também pode reiniciar o runtime IoT Edge com sudo iotedge system restart. Veja IoT Edge documentação de resolução de problemas para obter mais detalhes sobre a resolução de problemas do runtime do IoT Edge.

A instalação da Cache Ligada falha durante o registo do nó de cache

Como parte do processo de instalação em máquinas anfitriãs do Windows, a Cache Ligada tentará registar-se no serviço de Otimização da Entrega ao chamar um ponto geomcc.prod.do.dsp.mp.microsoft.comfinal de registo. Esta chamada tem origem na distribuição WSL2 que aloja o contentor da Cache Ligada e tem de ter êxito para que o nó de cache seja instalado.

Para resolver problemas de ligação, pode tentar executar os seguintes comandos a partir de uma janela elevada do PowerShell como a conta de runtime da Cache Ligada.

Primeiro, aceda à distribuição WSL2 que aloja o contentor da Cache Ligada:

wsl -d Ubuntu-24.04-Mcc

Em seguida, execute o seguinte comando bash para marcar resolução de DNS do ponto final de registo:

nslookup geomcc.prod.do.dsp.mp.microsoft.com

Verifique a conectividade TCP (porta 443 para HTTPS) ao ponto final de registo:

nc -vz geomcc.prod.do.dsp.mp.microsoft.com 443

Verifique a resposta HTTPS a partir do ponto final de registo:

curl -v https://geomcc.prod.do.dsp.mp.microsoft.com

MCC_Install_Task tarefa agendada não é executada

A instalação da Cache Ligada em máquinas anfitriãs do Windows baseia-se na tarefa agendada "MCC_Install_Task" para efetuar ações de instalação como a conta de runtime de Cache Ligada designada. Se esta tarefa não for executada, poderá dever-se a um dos seguintes motivos.

Política de Grupo Objeto entra em conflito com o registo de Tarefa Agendada

Ativar o Objeto de Política de Grupo: acesso à rede: não permitir o armazenamento de palavras-passe e credenciais para autenticação de rede impedirá que o software da Cache Ligada registe as tarefas agendadas necessárias para o registo e a operação com êxito do nó de cache.

A conta de runtime do MCC não tem permissões para iniciar sessão como tarefa do Batch

Certifique-se de que concedeu à conta de runtime da Cache Ligada a permissão "Iniciar sessão como uma tarefa de lote". Esta permissão é necessária para que a conta de runtime da Cache Ligada execute tarefas agendadas.

A política de segurança empresarial impede a execução de scripts do PowerShell

Certifique-se de que a política de execução do PowerShell no computador anfitrião do Windows permite a execução de scripts. Pode marcar a política de execução atual ao executar o seguinte comando numa janela elevada do PowerShell:

Get-ExecutionPolicy

O registo da Tarefa Agendada do MCC falha com o erro de credencial gMSA

Se vir um erro de instalação a indicar que o nome de utilizador ou palavra-passe gMSA está incorreto ao tentar registar Tarefas Agendadas do MCC, o problema pode ser causado por um erro de correspondência no tipo de encriptação Kerberos entre o computador anfitrião MCC e o Controlador de Domínio. Para resolve isto, o tipo de encriptação na conta gMSA tem de ser atualizado para corresponder ao tipo de encriptação configurado no Controlador de Domínio.

Pode marcar e alinhar estas definições ao rever a Segurança de rede: Configurar tipos de encriptação permitidos para a política Kerberos no Controlador de Domínio e no atributo da msDS-SupportedEncryptionTypes conta gMSA. Contacte a equipa do Active Directory para atualizar o tipo de encriptação da conta gMSA para corresponder ao Controlador de Domínio.

Falha na instalação do WSL2 com a mensagem "Não existe uma sessão de início de sessão especificada"

Se estiver a encontrar esta mensagem de falha ao tentar executar o comando wsl.exe --install --no-distribution do PowerShell no seu computador anfitrião Windows, verifique se tem sessão iniciada como administrador local e execute o comando a partir de uma janela elevada do PowerShell.

Atualizar o kernel WSL2

Se a instalação da Cache Ligada estiver a falhar devido a problemas relacionados com o WSL, tente executar wsl.exe --update para obter a versão mais recente do kernel do WSL.

MCC_Monitor_Task tarefa agendada não é executada

Assim que o contentor da Cache Ligada estiver em execução, a MCC_Monitor_Task tarefa agendada é executada periodicamente na conta de runtime da Cache Ligada para impedir que o WSL pare a distribuição WSL da Cache Ligada. Se o nó de cache ficar offline sem qualquer ação do utilizador, tal poderá dever-se ao facto de a tarefa agendada "MCC_Monitor_Task" não estar a ser executada corretamente.

Pode utilizar o Programador de Tarefas no computador anfitrião para marcar a status desta tarefa agendada.

1. Abrir o Programador de Tarefas no computador anfitrião
2. Navegue para a secção Tarefas Ativas e faça duplo clique no MCC_Monitor_Task
3. Verifique as colunas Hora da Última Execução e Resultado da Última Execução para ver se a operação foi concluída com êxito.
4. Selecione o separador Acionadores e confirme que o Estado está Ativado
5. Selecione o separador Histórico e marcar para ver se existem erros ou avisos relacionados com a execução da tarefa.

Se o MCC_Monitor_Task não for executado com êxito, poderá dever-se a credenciais de conta de runtime da Cache Ligada expiradas. Neste caso, pode utilizar o updatetaskpasswords.ps1 script para atualizar as credenciais.

1. Abra um processo do PowerShell como Administrador.

2. Altere o diretório para o diretório de script e verifique a presença de updatetaskpasswords.ps1.

   • Se instalou a Cache Ligada com o pacote de implementação pré-visualização pública, o diretório de script está localizado na instalaçãoPasta especificada no comando de implementação original ("C:\mccwsl01\MccScripts" por predefinição).
   • Se instalou a Cache Ligada com a aplicação Windows de Cache Ligada, o diretório de script está localizado no diretório devolvido por deliveryoptimization-cli mcc-get-scripts-path.

3. Crie um Objeto PSCredential com o nome $myLocalAccountCredential que representa a conta de runtime da Cache Ligada com a nova palavra-passe.

4. Execute o updatetaskpasswords.ps1 script com o seguinte comando:

   .\updatetaskpasswords.ps1 -Credential $myLocalAccountCredential
   

Nó de cache implementado com êxito, mas não a servir pedidos

Se o nó de cache não estiver a responder a pedidos fora do localhost, poderá dever-se ao facto de as regras de reencaminhamento de portas do computador anfitrião não terem sido definidas corretamente durante a instalação da Cache Ligada. Uma vez que o WSL2 utiliza um adaptador ethernet virtualizado por predefinição, são necessárias regras de reencaminhamento de portas para permitir que o tráfego chegue à instância WSL2 a partir da sua LAN. Para obter mais informações, veja Accessing network applications with WSL (Aceder a aplicações de rede com WSL).

A Cache Ligada utiliza netsh portproxy para definir regras de reencaminhamento de portas que direcionam o tráfego do endereço IP do computador anfitrião para a distribuição WSL que executa o contentor MCC. O serviço Auxiliar de IP do Windows tem de estar ativado para que estas regras funcionem. Se o serviço Auxiliar de IP estiver desativado, as regras de reencaminhamento de portas definidas via netsh portproxy não entrarão em vigor e o contentor MCC não receberá nenhum pedido de cliente de localhost externo.

Get-Service -Name iphlpsvc | Select-Object Name, Status, StartType
Set-Service -Name iphlpsvc -StartupType Automatic
Start-Service -Name iphlpsvc

Para marcar as regras de reencaminhamento de portas do computador anfitrião, utilize o seguinte comando do PowerShell.

netsh interface portproxy show v4tov4

Se não vir nenhuma regra de reencaminhamento de portas para a porta 80 a 0.0.0.0, pode executar o seguinte comando a partir de uma instância elevada do PowerShell para definir o reencaminhamento adequado para o WSL.

netsh interface portproxy add v4tov4 listenport=80 listenaddress=0.0.0.0 connectport=80 connectaddress=<WSL IP Address>

Pode obter o Endereço IP do WSL a wslip.txt partir do ficheiro que deve estar presente no diretório de instalação da aplicação de Cache Ligada (C:\mccwsl01 por predefinição).

Regras de reencaminhamento de portas WSL em falta (443, 5000)

Para configurar com êxito os nós de cache alojada no Windows para suportar HTTPS, tem de criar uma regra de reencaminhamento de portas para reencaminhar o tráfego da porta 443 no computador anfitrião para a porta 443 na distribuição WSL2 que aloja o contentor de Cache Ligada.

Para aceder remotamente à página Resumo terse do nó de cache alojada no Windows, tem de criar uma regra de reencaminhamento de portas para reencaminhar o tráfego da porta 5000 no computador anfitrião para a porta 5000 na distribuição WSL2 que aloja o contentor de Cache Ligada.

Pode criar estas regras de reencaminhamento de portas ao executar os seguintes comandos numa janela elevada do PowerShell após concluir a implementação do nó de cache.

$ipFilePath = Join-Path ([System.Environment]::GetEnvironmentVariable("MCC_INSTALLATION_FOLDER", "Machine")) "wslIp.txt"

$ipAddress = (Get-Content $ipFilePath | Select-Object -First 1).Trim()

netsh interface portproxy add v4tov4 listenport=443 listenaddress=0.0.0.0 connectport=443 connectaddress=$ipAddress
netsh interface portproxy add v4tov4 listenport=5000 listenaddress=0.0.0.0 connectport=5000 connectaddress=$ipAddress

Também terá de garantir que a firewall do computador anfitrião permite o tráfego de entrada nas portas 443 e 5000. Pode fazê-lo ao executar os seguintes comandos numa janela elevada do PowerShell:

[void](New-NetFirewallRule -DisplayName "WSL2 Port Bridge (HTTPS)" -Direction Inbound -Action Allow -Protocol TCP -LocalPort "443")

[void](New-NetFirewallRule -DisplayName "WSL2 Port Bridge (HTTPS)" -Direction Outbound -Action Allow -Protocol TCP -LocalPort "443")

[void](New-NetFirewallRule -DisplayName "WSL2 Port Bridge (MCC SUMMARY)" -Direction Inbound -Action Allow -Protocol TCP -LocalPort "5000")

A implementação do nó de cache no Windows falha com "ERRO: não é possível verificar o certificado"

Se encontrar um erro durante a implementação do nó de cache que indica "ERRO: não é possível verificar o certificado", tal pode dever-se ao proxy de inspeção TLS da sua rede (por exemplo, ZScaler) que interceta a comunicação entre o software de Cache Ligada e o serviço de Otimização da Entrega. Esta intercepção interrompe a cadeia de certificados e impede a implementação com êxito da Cache Ligada.

Para resolve este problema, tem de configurar o ambiente de rede para permitir chamadas de e para "*.prod.do.dsp.mp.microsoft.com" para ignorar o proxy de inspeção de TLS.

Também tem de configurar as definições de proxy para o nó de cache e, em seguida, colocar o ficheiro de certificado de proxy (.pem) no caminho da pasta de instalação pretendido e adicionar -proxyTlsCertificatePemFileName "mycert.pem" ao comando de implementação. Por exemplo, coloque o ficheiro .pem no C:\mccwsl01\mycert.pem e adicione -proxyTlsCertificatePemFileName "mycert.pem" ao comando de implementação.

Resolver problemas de implementação de nós de cache para Linux computador anfitrião

A implementação de um nó de Cache Ligada num computador anfitrião Linux envolve a execução de uma série de scripts Bash contidos no pacote de implementação Linux.

Depois de o software de Cache Ligada ter sido implementado com êxito no computador anfitrião Linux, pode marcar se o nó de cache estiver a ser executado corretamente ao fazer o seguinte no computador anfitrião Linux:

1. Execute sudo iotedge list para mostrar que contentores estão em execução no runtime do IoT Edge

Se mostrar os contentores edgeAgent e edgeHub, mas não mostrar o MCC, pode ver a status do gestor de segurança do IoT Edge com sudo iotedge system logs -- -f.

Também pode reiniciar o runtime IoT Edge com sudo systemctl restart iotedge.

Falha na implementação do nó de cache no Linux com "ERRO: não é possível verificar o certificado"

Se encontrar um erro durante a implementação do nó de cache que indica "ERRO: não é possível verificar o certificado", tal pode dever-se ao proxy de inspeção TLS da sua rede (por exemplo, ZScaler) que interceta a comunicação entre o software de Cache Ligada e o serviço de Otimização da Entrega. Esta intercepção interrompe a cadeia de certificados e impede a implementação com êxito da Cache Ligada.

Para resolve este problema, tem de configurar o ambiente de rede para permitir chamadas de e para "*.prod.do.dsp.mp.microsoft.com" para ignorar o proxy de inspeção de TLS.

Também tem de configurar as definições de proxy para o nó de cache e, em seguida, colocar o ficheiro de certificado de proxy (.pem) no diretório do pacote de implementação extraído e adicionar proxytlscertificatepath="/path/to/pem/file" ao comando de implementação.

A gerar o pacote de suporte de diagnóstico do nó de cache

Pode gerar um pacote de suporte com informações de diagnóstico detalhadas ao executar o collectMccDiagnostics.sh script incluído no pacote de instalação.

Para máquinas anfitriãs do Windows , tem de fazer o seguinte:

1. Iniciar um processo do PowerShell como a conta especificada como a conta de runtime durante a instalação da Cache Ligada

2. Altere o diretório para o diretório "MccScripts" no diretório de instalação da aplicação de Cache Ligada (especificado no comando de implementação, a predefinição é C:\mccwsl01\MccScripts) e verifique a presença de collectmccdiagnostics.sh

3. Executar wsl bash collectmccdiagnostics.sh para gerar o pacote de suporte de diagnóstico

4. Assim que o script estiver concluído, tenha em atenção a saída da consola que descreve a localização do pacote de suporte de diagnóstico

   Por exemplo, "Pacote zipado com êxito, envie o ficheiro criado em /etc/mccdiagnostics/support_bundle_2024_12_03__11_05_39__AM.tar.gz"

5. Execute o wsl cp comando para copiar o pacote de suporte da localização na distribuição do Ubuntu para o SO anfitrião do Windows

   Por exemplo, wsl cp /etc/mccdiagnostics/support_bundle_2024_12_03__11_05_39__AM.tar.gz /mnt/c/mccwsl01/SupportBundles/

Para Linux computadores anfitriões, tem de fazer o seguinte:

1. Altere o diretório para o diretório "MccScripts" no pacote de implementação da Cache Ligada extraído e verifique a presença de collectmccdiagnostics.sh

2. Executar collectmccdiagnostics.sh para gerar o pacote de suporte de diagnóstico

3. Após a conclusão do script, tenha em atenção a saída da consola que descreve a localização do pacote de suporte de diagnóstico

   Por exemplo, "Pacote zipado com êxito, envie o ficheiro criado em /etc/mccdiagnostics/support_bundle_2024_12_03__11_05_39__AM.tar.gz"

Resolução de problemas de configuração de HTTPS

Se a Autoridade de Certificação (AC) só conseguir gerar certificados assinados em formatos .pem ou .cer, pode alterar a extensão de ficheiro do ficheiro de certificado para .crt se o ficheiro estiver na codificação Base64.

Resolução de problemas de monitorização de nós de cache

O status de nó de Cache Ligada e o desempenho podem ser monitorizados com a interface de utilizador portal do Azure.

Se os elementos visuais de monitorização básicos no separador Descrição geral estiverem a mostrar valores inesperados ou erróneos, atualize a janela do browser. Se o problema persistir, marcar que configurou os filtros do nó Período de Tempo e Cache conforme pretendido.

Tenha em atenção que a status "Em Bom Estado de Funcionamento" é determinada pela capacidade do contentor de Cache Ligada comunicar com êxito com o serviço De Otimização da Entrega. Se o nó de cache estiver a mostrar a status "Mau estado de funcionamento", marcar que o nó de cache tem conectividade de saída à Internet e pode aceder aos pontos finais do serviço De Otimização da Entrega.

A status "Em Bom Estado de Funcionamento" só reflete se o contentor da Cache Ligada consegue comunicar com o serviço de Otimização da Entrega. Não verifica se os dispositivos cliente DO na rede podem aceder ao nó de cache. Um nó "Em bom estado de funcionamento" ainda pode ser inacessível por parte dos clientes devido a regras de firewall, falhas de reencaminhamento de portas WSL2 ou segmentação de rede.

Resolver problemas de conectividade do cliente ao nó de cache

Para testar a acessibilidade do cliente, visite o seguinte URL a partir de um dispositivo cliente na mesma rede que o nó de cache, substituindo CacheNodeIPAddress pelo endereço IP do nó de cache:

http://[CacheNodeIPAddress]/filestreamingservice/files/7bc846e0-af9c-49be-a03d-bb04428c9bb5/Microsoft.png?cacheHostOrigin=dl.delivery.mp.microsoft.com

Veja o artigo Verificar nó de cache para obter instruções mais detalhadas.

Opção DHCP 235 não obtida devido à definição LocalPolicyMerge

Se estiver a utilizar a Opção DHCP 235 para anunciar o nó Cache Ligada aos clientes, a definição LocalPolicyMerge pode impedir que o cliente DHCP recupere a Opção 235. Este problema é especialmente comum em cenários de aprovisionamento do Windows Autopilot em que são aplicadas linhas de base de segurança.

Se os clientes não estiverem a detetar o nó de cache através de DHCP, marcar se a LocalPolicyMerge definição está configurada no seu ambiente. Se estiver, considere mudar da deteção da Opção DHCP 235 para configurar diretamente a política DOCacheHost com o nome de anfitrião ou endereço IP do nó de cache.

Diagnosticar falhas de acessibilidade do cliente

Se os clientes na rede ainda não conseguirem aceder ao nó de cache depois de concluir os passos de verificação acima, utilize os seguintes passos para diagnosticar o problema.

Passo 1: verificar se a tarefa agendada MCC_Monitor_Task foi executada

A MCC_Monitor_Task tarefa agendada é responsável por manter a distribuição WSL da Cache Ligada em execução nos computadores anfitriões do Windows. Se a tarefa não estiver em execução, o nó de cache pode estar offline, o que causa falhas de acessibilidade do cliente.

1. Abra o Programador de Tarefas no computador anfitrião do Windows.
2. Na secção Tarefas Ativas , localize MCC_Monitor_Task.
3. Verifique as colunas Hora da Última Execução e Resultado da Última Execução para confirmar que a tarefa foi executada com êxito.
4. Selecione o separador Acionadores e confirme que o Estado do acionador está Ativado.

Se MCC_Monitor_Task não for possível executar, veja a secção MCC_Monitor_Task tarefa agendada não é executada para obter os passos de resolução.

Passo 2: Rever WSL_Mcc_Monitor_FromRegisteredTask_Transcript.txt

O WSL_Mcc_Monitor_FromRegisteredTask_Transcript.txt ficheiro de registo regista a saída de cada MCC_Monitor_Task execução e é útil para identificar se a distribuição WSL da Cache Ligada ou o contentor encontrou um erro.

1. Navegue para o diretório de instalação da Cache Ligada no computador anfitrião do Windows.
   • O diretório de instalação predefinido é C:\mccwsl01\.
   • Pode confirmar o caminho exato ao executar deliveryoptimization-cli mcc-get-scripts-path numa janela elevada do PowerShell.
2. Abrir WSL_Mcc_Monitor_FromRegisteredTask_Transcript.txt num editor de texto.
3. Veja se existem erros no registo que indicam que a distribuição WSL não foi iniciada ou que o contentor da Cache Ligada parou inesperadamente.

Passo 3: Validar a resolução de DNS e a conectividade HTTP ao b1.download.windowsupdate.com

O nó Cache Ligada tem de conseguir aceder upstream pontos finais de entrega de conteúdos da Microsoft para servir pedidos aos clientes. Utilize os seguintes comandos para verificar se o anfitrião do nó de cache pode resolve e ligar a b1.download.windowsupdate.com.

Nós de cache alojados no Windows

1. Inicie um processo do PowerShell como a conta de runtime da Cache Ligada.

2. Aceda à distribuição WSL2:

   wsl -d Ubuntu-24.04-Mcc
   

3. Verifique a resolução de DNS:

   nslookup b1.download.windowsupdate.com
   

4. Verifique a conectividade HTTP:

   curl -v http://b1.download.windowsupdate.com
   

nós de cache alojada Linux

Execute os seguintes comandos diretamente no computador anfitrião Linux.

1. Verifique a resolução de DNS:

   nslookup b1.download.windowsupdate.com
   

2. Verifique a conectividade HTTP:

   curl -v http://b1.download.windowsupdate.com
   

Se a resolução de DNS falhar ou o pedido HTTP estiver bloqueado, avance para o Passo 4 para investigar os bloqueadores de camada de rede.

Passo 4: Verificar as definições de inspeção de firewall, proxy e TLS

Se as verificações de DNS ou HTTP do Passo 3 falharem, uma ou mais das seguintes configurações de camada de rede podem estar a bloquear upstream conectividade do anfitrião do nó de cache.

• Firewall: certifique-se de que o tráfego de saída nas portas 80 e 443 do computador anfitrião do nó de cache é permitido. Veja Pontos finais da Otimização da Entrega para obter a lista completa dos pontos finais necessários.
• Proxy: se o seu ambiente utilizar um proxy, verifique se as definições de proxy do nó de cache estão configuradas corretamente. Veja a documentação de configuração das definições de proxy .
• Inspeção TLS: se a rede utilizar um proxy de inspeção TLS (por exemplo, ZScaler), configure-o para ignorar o tráfego de *.do.dsp.mp.microsoft.com e para pontos finais. Veja Falha na implementação do nó de cache no Windows com "ERRO: não é possível verificar o certificado" ou A implementação do nó de cache no Linux falha com "ERRO: não é possível verificar o certificado" para obter os passos de resolução.
• Reencaminhamento de portas WSL (apenas nós alojados no Windows): confirme que as regras de reencaminhamento de portas para as portas 80 e 443 estão implementadas. Veja Regras de reencaminhamento de portas WSL em falta (443, 5000) para obter instruções.

Passo 5: Recolher diagnóstico

Se o problema persistir após concluir os passos anteriores, gere um pacote de suporte de diagnóstico para partilhar com o suporte da Microsoft. Veja Gerar o pacote de suporte de diagnóstico do nó de cache para obter instruções.

Atualizar o DNS do Docker para utilizar a sua própria resolução de DNS

Se o nó de cache alojada Linux estiver a ter problemas de conectividade de rede, atualizar a configuração DNS do Docker para utilizar a resolução de DNS da própria organização poderá resolve o problema.

1. Abra o ficheiro de configuração do daemon do Docker:

   nano /etc/docker/daemon.json
   

2. Atualize o conteúdo do ficheiro para incluir o endereço IP de resolução DNS da sua organização:

   "log-driver": "json-file", "log-opts": {"max-size": "10m","max-file": "3"},"dns":["<Your organization's DNS resolver IP address>"]
   

3. Guarde e feche o ficheiro com Ctrl+X e, em seguida, Y para confirmar.

4. Reinicie o Docker para que a alteração entre em vigor:

   systemctl restart docker
   

5. Execute novamente o comando IoT Edge marcar para validar a conectividade adequada:

   iotedge check --verbose
   

Diagnosticar e Resolver

Também pode utilizar a funcionalidade Diagnosticar e resolver problemas fornecida pela interface de portal do Azure. Este separador na Cache Ligada da Microsoft Azure recurso orienta-o através de alguns pedidos para ajudar a restringir a solução para o problema.