Solucionar problemas do Cache conectado da Microsoft' para empresas e instituições de ensino

Este artigo contém instruções sobre como solucionar diferentes problemas que você pode encontrar ao usar o Cache Conectado. Esses problemas são categorizados pela tarefa em que podem ser encontrados.

Problemas conhecidos

Esta seção descreve problemas conhecidos com a versão mais recente do Cache Conectado da Microsoft para Empresas e 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 do Azure de cache conectado está ausente da seleção de escopo na guia "Métricas"

Você pode criar gráficos personalizados no portal do Azure de Cache Conectado selecionando a guia Métricas na seção Monitoramento do recurso do Azure de Cache Conectado. O recurso de Cache Conectado do Azure está corretamente selecionado como o Escopo por padrão, mas se você alterar o Escopo selecionado, não poderá selecionar novamente o recurso de Cache Conectado do Azure, impedindo a criação subsequente de gráficos personalizados.

Como solução temporária, você pode sair da guia Métricas e retornar a ela. O recurso de Cache Conectado do Azure é novamente selecionado corretamente como o Escopo.

importCert.ps1 limitações

O importCert.ps1 script é usado para importar certificados para o repositório de certificados do Windows como parte do processo de configuração HTTPS para nós de cache hospedados no Windows. O aplicativo Windows v1.0.24.0 Cache Conectado não dá suporte à execução deste script em nós de cache implantados no Windows Server 2022 ou no Windows Server 2025 com uma conta de tempo de execução de Cache Conectado gMSA. Use o aplicativo v1.0.26.0 ou posterior para executar esse script nesses ambientes.

Cache conectado Limitações do aplicativo instalador do Windows

O aplicativo instalador do Windows de Cache Conectado é um pacote MSIX usado para implantar o Cache Conectado em computadores host Windows. No momento, o aplicativo instalador não dá suporte ao Windows Server Core.

Corrigido na versão mais recente

Versão GA: 23/07/2025

• A instalação do Cache conectado falha quando o computador host Windows é configurado com uma localidade não EN.
• Os nós de Cache Conectado hospedados no Windows podem crescer além do tamanho da unidade de cache configurada.

Etapas para obter uma ID de assinatura do Azure

1. Entre no portal do Azure.
2. Selecione Assinaturas. Caso não veja Assinaturas, digite Assinaturas na barra de pesquisa. Conforme você começa a digitar, a lista é filtrada com base em sua entrada.
3. Se você já tiver uma assinatura do Azure, vá para a etapa 5. Se você não tiver uma assinatura do Azure, selecione + Adicionar no canto superior esquerdo.
4. Selecione a assinatura paga conforme o uso . Você será solicitado a inserir informações de card de crédito, mas não será cobrado pelo uso do serviço Cache Conectado da Microsoft.
5. Na página Assinaturas , você encontrará detalhes sobre sua assinatura atual. Selecione o nome da assinatura.
6. Depois de selecionar o nome da assinatura, você encontrará a ID da assinatura na guia Visão geral . Selecione o ícone Copiar para área de transferência ao lado da ID da assinatura para copiar o valor.

Solução de problemas de criação de recursos do Azure

Cache conectado A criação de recursos do Azure pode ser iniciada usando a interface do usuário do portal do Azure ou o conjunto de comandos da CLI do Azure.

Se você encontrar um erro durante a criação de recursos, marque se tem as permissões necessárias para criar recursos do Azure em sua assinatura e se preencheu todos os campos obrigatórios durante o processo de criação de recursos.

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

A configuração do nó de Cache Conectado pode ser feita usando a interface do usuário do portal do Azure ou o conjunto de comandos da CLI do Azure.

Se você estiver encontrando um erro de validação, Marque se preencheu todos os campos de configuração obrigatórios.

Se a configuração não parecer estar entrando em vigor, marque se você selecionou a opção Salvar na parte superior da página de configuração na interface do usuário do portal do Azure.

Se você alterou a configuração do proxy, precisará reimplantar o software Cache Conectado no computador host para que a configuração do proxy entre em vigor.

Solução de problemas de implantação de nó de cache no computador host Windows

Coletar logs de instalação hospedados no Windows

A implantação de um nó de Cache Conectado em um computador host Windows envolve a execução de uma série de scripts do PowerShell contidos no aplicativo Cache Conectado do Windows. Esses scripts tentam gravar arquivos de log no diretório de script do aplicativo de Cache Conectado, especificado por deliveryoptimization-cli mcc-get-scripts-path.

Existem três tipos de arquivos de log de instalação:

1. WSL_Mcc_Install_Transcript: Este arquivo de log registra as linhas impressas na janela do PowerShell ao executar o script de instalação
2. WSL_Mcc_Install_FromRegisteredTask_Status: Este arquivo de log registra o status de alto nível que é gravado durante a instalação de tarefas registradas
3. WSL_Mcc_Install_FromRegisteredTask_Transcript: Este arquivo de log registra a status detalhada que é gravada durante a instalação das tarefas registradas

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

Coletar outros logs hospedados do Windows

Depois que o nó de cache for instalado com êxito na máquina host do Windows, ele gravará periodicamente arquivos de log no diretório de instalação (C:\mccwsl01\ por padrão).

Você pode esperar ver os seguintes tipos de arquivos de log:

1. WSL_Mcc_Monitor_FromRegisteredTask_Transcript: Este arquivo de log registra a saída da tarefa agendada "MCC_Monitor_Task" que é responsável por garantir que o Cache Conectado continue em execução.
2. WSL_Mcc_UserUninstall_Transcript: Este arquivo de log registra a saída do script "uninstallmcconwsl.ps1" que o usuário pode executar para desinstalar o software de Cache Conectado do computador host.
3. WSL_Mcc_Uninstall_FromRegisteredTask_Transcript: Este arquivo de log registra a saída da tarefa agendada "MCC_Uninstall_Task" que é responsável por desinstalar o software de Cache Conectado do computador host quando chamado pelo script "uninstallmcconwsl.ps1".

Iniciando um processo do PowerShell como a conta de runtime de Cache Conectado

Para solucionar problemas com o software do Cache Conectado em um computador host Windows, talvez seja necessário executar comandos como a conta de tempo de execução do Cache Conectado. Você pode fazer isso iniciando um processo do PowerShell como a conta de runtime especificada durante a instalação do Cache Conectado.

• Se a conta de tempo de execução for uma conta local, você poderá iniciar um processo do PowerShell como a conta de tempo de execução executando o seguinte comando em uma janela do PowerShell com privilégios elevados:

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

• Se a conta de tempo de execução for uma conta de domínio ou de serviço, você poderá iniciar um processo do PowerShell como a conta de tempo de execução executando o seguinte comando em uma janela do PowerShell com privilégios elevados:

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

• Se a conta de tempo de execução for uma Conta de Serviço Gerenciado de Grupo (gMSA), você deverá usar o PsExec para iniciar um processo do PowerShell como a conta de tempo de execução executando o seguinte comando em uma janela do PowerShell com privilégios elevados:

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

Verificando se o contêiner de Cache Conectado está em execução

Depois que o software cache conectado tiver sido implantado com êxito no computador host Windows, você poderá marcar se o nó de cache está funcionando corretamente fazendo o seguinte no computador host Windows:

1. Iniciar um processo do PowerShell como a conta especificada como a conta de runtime durante a instalação do Cache Conectado
2. Execute wsl -d Ubuntu-24.04-Mcc para acessar a distribuição do Linux que hospeda o contêiner de Cache Conectado
3. Executar sudo iotedge list para mostrar quais contêineres estão em execução no runtime do IoT Edge

Se ele mostrar os contêineres edgeAgent e edgeHub, mas não mostrar o MCC, você poderá exibir o status do gerenciador de segurança do IoT Edge usando sudo iotedge system logs -- -f.

Você também pode reiniciar o tempo de execução do IoT Edge usando sudo iotedge system restart. Consulte a documentação de solução de problemas do IoT Edge para obter mais detalhes sobre como solucionar problemas do tempo de execução do IoT Edge.

A instalação do Cache conectado falha durante o registro do nó de cache

Como parte do processo de instalação em computadores host Windows, o Cache Conectado tentará se registrar no serviço de Otimização de Entrega chamando um ponto de extremidade geomcc.prod.do.dsp.mp.microsoft.comde registro. Essa chamada se origina de dentro da distribuição WSL2 que hospeda o contêiner de Cache Conectado e deve ser bem-sucedida para que o nó de cache seja instalado.

Para solucionar problemas de conexão, você pode tentar executar os seguintes comandos em uma janela do PowerShell com privilégios elevados como a conta de tempo de execução do Cache Conectado.

Primeiro, acesse a distribuição WSL2 que hospeda o contêiner de Cache Conectado:

wsl -d Ubuntu-24.04-Mcc

Em seguida, execute o seguinte comando bash para marcar a resolução DNS do ponto de extremidade de registro:

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

Verifique a conectividade TCP (porta 443 para HTTPS) com o ponto de extremidade de registro:

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

Verifique a resposta HTTPS no ponto de extremidade de registro:

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

MCC_Install_Task tarefa agendada não é executada

A instalação do Cache Conectado em computadores host Windows depende da tarefa agendada "MCC_Install_Task" para executar ações de instalação como a conta de tempo de execução do Cache Conectado designada. Se essa tarefa falhar na execução, pode ser devido a um dos seguintes motivos.

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

Habilitação da Política de Grupo Objeto: Acesso à rede: Não permitir o armazenamento de senhas e credenciais para autenticação de rede impedirá que o software de Cache Conectado registre as tarefas agendadas necessárias para o registro e a operação bem-sucedidos do nó de cache.

A conta de tempo de execução do MCC não tem permissões para fazer logon como trabalho em lotes

Verifique se você concedeu à conta de tempo de execução do Cache Conectado a permissão "Fazer logon como um trabalho em lotes". Essa permissão é necessária para que a conta de runtime do Cache Conectado 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 host Windows permita a execução de scripts. Você pode marcar a política de execução atual executando o seguinte comando em uma janela do PowerShell com privilégios elevados:

Get-ExecutionPolicy

O registro da Tarefa Agendada MCC falha com erro de credencial gMSA

Se você vir um erro de instalação informando que o nome de usuário ou a senha da gMSA está incorreto ao tentar registrar Tarefas Agendadas do MCC, o problema pode ser causado por uma incompatibilidade no tipo de criptografia Kerberos entre o computador host do MCC e o Controlador de Domínio. Para resolver isso, o tipo de criptografia na conta gMSA deve ser atualizado para corresponder ao tipo de criptografia configurado no Controlador de Domínio.

Você pode marcar e alinhar essas configurações revisando a Segurança de rede: Configurar tipos de criptografia permitidos para a política Kerberos no Controlador de Domínio e no atributo da msDS-SupportedEncryptionTypes conta gMSA. Entre em contato com a equipe do Active Directory para atualizar o tipo de criptografia da conta gMSA para corresponder ao Controlador de Domínio.

Falha ao instalar o WSL2 com a mensagem "Não existe uma sessão de logon especificada"

Se você estiver encontrando essa mensagem de falha ao tentar executar o comando wsl.exe --install --no-distribution do PowerShell em seu computador host Windows, verifique se você está conectado como administrador local e executando o comando em uma janela elevada do PowerShell.

Atualizando o kernel WSL2

Se a instalação do cache conectado estiver falhando devido a problemas relacionados ao 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

Depois que o contêiner de Cache Conectado estiver em execução, a tarefa agendada MCC_Monitor_Task é executada periodicamente na conta de runtime do Cache Conectado para impedir que o WSL interrompa a distribuição do WSL do Cache Conectado. Se o nó de cache ficar offline sem nenhuma ação do usuário, pode ser porque a tarefa agendada "MCC_Monitor_Task" não está sendo executada corretamente.

Você pode usar o Agendador de Tarefas no computador host para marcar o status desta tarefa agendada.

1. Abrir o Agendador de tarefas no computador host
2. Navegue até a seção Tarefas Ativas e clique duas vezes em 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 a guia Gatilhos e confirme se o Status é Habilitado
5. Selecione a guia Histórico e Marque se há erros ou avisos relacionados à execução da tarefa.

Se o MCC_Monitor_Task não estiver sendo executado com êxito, pode ser devido a credenciais de conta de runtime de cache conectado expiradas. Nesse caso, você pode usar 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.ps1arquivos .

   • Se você instalou o Cache Conectado usando o pacote de implantação de Visualização Pública, o diretório de scripts estará localizado na installationFolder especificada no comando de implantação original ("C:\mccwsl01\MccScripts" por padrão).
   • Se você instalou o Cache conectado usando o aplicativo Cache conectado do Windows, o diretório do script está localizado dentro do diretório retornado por deliveryoptimization-cli mcc-get-scripts-path.

3. Crie um Objeto PSCredential nomeado $myLocalAccountCredential representando a conta de runtime de Cache Conectado com a nova senha.

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

   .\updatetaskpasswords.ps1 -Credential $myLocalAccountCredential
   

Nó de cache implantado com êxito, mas não atendendo às solicitações

Se o nó de cache não estiver respondendo a solicitações fora do localhost, pode ser porque as regras de encaminhamento de porta do computador host não foram definidas corretamente durante a instalação do Cache Conectado. Como o WSL2 usa um adaptador ethernet virtualizado por padrão, as regras de encaminhamento de porta são necessárias para permitir que o tráfego chegue à instância do WSL2 da LAN. Para obter mais informações, consulte Acessando aplicativos de rede com o WSL.

O Cache conectado usa netsh portproxy para definir regras de encaminhamento de porta que direcionam o tráfego do endereço IP do computador host para a distribuição WSL que executa o contêiner MCC. O serviço Auxiliar de IP do Windows deve ser habilitado para que essas regras funcionem. Se o serviço Auxiliar de IP estiver desabilitado, as regras de encaminhamento de porta definidas por meio do não netsh portproxy entrarão em vigor e o contêiner do MCC não receberá nenhuma solicitação de cliente de um host local 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 encaminhamento de porta do computador host, use o seguinte comando do PowerShell.

netsh interface portproxy show v4tov4

Se você não vir nenhuma regra de encaminhamento de porta para a porta 80 a 0.0.0.0, poderá executar o comando a seguir em uma instância do PowerShell com privilégios elevados para definir o encaminhamento adequado para WSL.

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

Você pode recuperar o endereço IP do WSL do wslip.txt arquivo que deve estar presente no diretório de instalação do aplicativo de cache conectado (C:\mccwsl01 por padrão).

Regras de encaminhamento de porta WSL ausentes (443, 5000)

Para configurar com êxito seus nós de cache hospedados no Windows para dar suporte a HTTPS, você deve criar uma regra de encaminhamento de porta para encaminhar o tráfego da porta 443 no computador host para a porta 443 na distribuição WSL2 que hospeda o contêiner de Cache Conectado.

Para acessar remotamente a página Resumo conciso do nó de cache hospedado no Windows, você deve criar uma regra de encaminhamento de porta para encaminhar o tráfego da porta 5000 no computador host para a porta 5000 na distribuição WSL2 que hospeda o contêiner de Cache Conectado.

Você pode criar essas regras de encaminhamento de porta executando os seguintes comandos em uma janela elevada do PowerShell após concluir a implantaçã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

Você também precisará garantir que o firewall do computador host permita o tráfego de entrada nas portas 443 e 5000. Você pode fazer isso executando os seguintes comandos em uma 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 implantação do nó de cache no Windows falha com "ERRO: não é possível verificar o certificado"

Se você encontrar um erro durante a implantação do nó de cache que informa "ERRO: não é possível verificar o certificado", pode ser devido ao proxy de inspeção TLS da sua rede (por exemplo, ZScaler) interceptar a comunicação entre o software Cache Conectado e o serviço de Otimização de Entrega. Essa interceptação interrompe a cadeia de certificados e impede que o Cache Conectado seja implantado com êxito.

Para resolve esse problema, você deve configurar seu ambiente de rede para permitir chamadas de e para "*.do.dsp.mp.microsoft.com" para ignorar o proxy de inspeção TLS.

Você também deve definir as configurações de proxy para o nó de cache e, em seguida, colocar o arquivo de certificado de proxy (.pem) no caminho installationFolder desejado e adicioná-lo -proxyTlsCertificatePemFileName "mycert.pem" ao comando de implantação. Por exemplo, coloque o arquivo C:\mccwsl01\mycert.pem .pem e adicione-o -proxyTlsCertificatePemFileName "mycert.pem" ao comando de implantação.

Solução de problemas de implantação de nó de cache em computador host Linux

A implantação de um nó de Cache Conectado em uma máquina host do Linux envolve a execução de uma série de scripts Bash contidos no pacote de implantação do Linux.

Depois que o software Cache Conectado tiver sido implantado com êxito na máquina host do Linux, você poderá marcar se o nó de cache está funcionando corretamente fazendo o seguinte na máquina host do Linux:

1. Executar sudo iotedge list para mostrar quais contêineres estão em execução no runtime do IoT Edge

Se ele mostrar os contêineres edgeAgent e edgeHub, mas não mostrar o MCC, você poderá exibir o status do gerenciador de segurança do IoT Edge usando sudo iotedge system logs -- -f.

Você também pode reiniciar o tempo de execução do IoT Edge usando sudo systemctl restart iotedge.

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

Se você encontrar um erro durante a implantação do nó de cache que informa "ERRO: não é possível verificar o certificado", pode ser devido ao proxy de inspeção TLS da sua rede (por exemplo, ZScaler) interceptar a comunicação entre o software Cache Conectado e o serviço de Otimização de Entrega. Essa interceptação interrompe a cadeia de certificados e impede que o Cache Conectado seja implantado com êxito.

Para resolve esse problema, você deve configurar seu ambiente de rede para permitir chamadas de e para "*.do.dsp.mp.microsoft.com" para ignorar o proxy de inspeção TLS.

Você também deve definir as configurações de proxy para seu nó de cache e, em seguida, colocar o arquivo de certificado de proxy (.pem) no diretório do pacote de implantação extraído e adicionar proxytlscertificatepath="/path/to/pem/file" ao comando de implantação.

Geração do pacote de suporte para diagnóstico de nó de cache

Você pode gerar um pacote de suporte com informações de diagnóstico detalhadas executando o collectMccDiagnostics.sh script incluído no pacote de instalação.

Para computadores host Windows , você precisa fazer o seguinte:

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

2. Altere o diretório para o diretório "MccScripts" no diretório de instalação do aplicativo Cache Conectado (especificado no comando de implantação, o padrão é C:\mccwsl01\MccScripts) e verifique a presença de collectmccdiagnostics.sh

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

4. Depois que o script for concluído, observe a saída do console que descreve o local do pacote de suporte de diagnóstico

   Por exemplo, "Pacote compactado com êxito, envie o arquivo 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 do local dentro da distribuição do Ubuntu para o sistema operacional host do Windows

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

Para computadores host Linux, você precisa fazer o seguinte:

1. Altere o diretório para o diretório "MccScripts" dentro do pacote de implantação de Cache Conectado extraído e verifique a presença de collectmccdiagnostics.sh

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

3. Quando o script for concluído, observe a saída do console que descreve o local do pacote de suporte de diagnóstico

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

Solução de problemas de configuração de HTTPS

Se sua AC (autoridade de certificação) só puder gerar certificados assinados em formatos .pem ou .cer, você poderá alterar a extensão do arquivo de certificado para .crt se o arquivo estiver na codificação Base64.

Solução de problemas de monitoramento de nó de cache

O status e o desempenho do nó de Cache Conectado podem ser monitorados usando a interface do usuário do portal do Azure.

Se os visuais de monitoramento básicos na guia Visão geral estiverem mostrando valores inesperados ou incorretos, atualize a janela do navegador. Se o problema persistir, Marque se você configurou os filtros do nó Timespan e Cache conforme desejado.

Observe que o status "Íntegro" é determinado pela capacidade do contêiner de Cache Conectado de se comunicar com êxito com o serviço de Otimização de Entrega. Se o nó de cache estiver mostrando o status "Não íntegro", marcar se o nó de cache tem conectividade de saída com a Internet e pode acessar os pontos de extremidade do serviço de Otimização de Entrega.

O status "Íntegro" reflete apenas se o contêiner de Cache Conectado pode se comunicar com o serviço de Otimização de Entrega. Ele não verifica se os dispositivos cliente DO na rede podem acessar o nó de cache. Um nó "Íntegro" ainda pode estar inacessível dos clientes devido a regras de firewall, lacunas de encaminhamento de porta WSL2 ou segmentação de rede.

Solução de problemas de conectividade do cliente com o nó de cache

Para testar a acessibilidade do cliente, visite a seguinte URL 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

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

Opção DHCP 235 não recuperada devido à configuração LocalPolicyMerge

Se você estiver usando a Opção DHCP 235 para anunciar o nó de Cache Conectado para clientes, a configuração LocalPolicyMerge poderá impedir que o cliente DHCP recupere a Opção 235. Esse problema é especialmente comum em cenários de provisionamento do Windows Autopilot em que as linhas de base de segurança são aplicadas.

Se os clientes não estiverem descobrindo o nó de cache via DHCP, Marque se a LocalPolicyMerge configuração está configurada em seu ambiente. Se estiver, considere alternar da descoberta do DHCP Opção 235 para configurar diretamente a política DOCacheHost com o nome de host ou endereço IP do nó de cache.

Diagnosticar falhas de acessibilidade do cliente

Se os clientes na rede ainda não conseguirem acessar o nó de cache após concluir as etapas de verificação acima, use as etapas a seguir para diagnosticar o problema.

Etapa 1: Verificar se a tarefa agendada MCC_Monitor_Task foi executada

A MCC_Monitor_Task tarefa agendada é responsável por manter a distribuição do WSL de Cache Conectado em execução nos computadores host do Windows. Se a tarefa não estiver em execução, o nó de cache poderá estar offline, causando falhas de acessibilidade do cliente.

1. Abra o Agendador de Tarefas no computador host Windows.
2. Na seçã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 a guia Gatilhos e confirme se o Status do gatilho é Habilitado.

Se MCC_Monitor_Task estiver falhando ao executar, consulte a seção MCC_Monitor_Task tarefa agendada falha na execução para obter as etapas de resolução.

Etapa 2: examinar WSL_Mcc_Monitor_FromRegisteredTask_Transcript.txt

O WSL_Mcc_Monitor_FromRegisteredTask_Transcript.txt arquivo de log registra a saída de cada MCC_Monitor_Task execução e é útil para identificar se a distribuição ou o contêiner do WSL de Cache Conectado encontrou um erro.

1. Navegue até o diretório de instalação do Cache Conectado no computador host Windows.
   • O diretório de instalação padrão é C:\mccwsl01\.
   • Você pode confirmar o caminho exato executando deliveryoptimization-cli mcc-get-scripts-path em uma janela elevada do PowerShell.
2. Abra WSL_Mcc_Monitor_FromRegisteredTask_Transcript.txt em um editor de texto.
3. Examine o log em busca de erros indicando que a distribuição WSL falhou ao iniciar ou que o contêiner de Cache Conectado parou inesperadamente.

Etapa 3: validar a resolução DNS e a conectividade HTTP para b1.download.windowsupdate.com

O nó de Cache Conectado deve ser capaz de alcançar os pontos de extremidade de entrega de conteúdo da Microsoft upstream para atender às solicitações aos clientes. Use os comandos a seguir para verificar se o host do nó de cache pode resolver e se conectar ao b1.download.windowsupdate.com.

Nós de cache hospedados no Windows

1. Inicie um processo do PowerShell como a conta de tempo de execução do Cache Conectado.

2. Acesse a distribuição WSL2:

   wsl -d Ubuntu-24.04-Mcc
   

3. Verificar resolução de DNS:

   nslookup b1.download.windowsupdate.com
   

4. Verificar conectividade HTTP:

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

Nós de cache hospedados no Linux

Execute os seguintes comandos diretamente no computador host do Linux.

1. Verificar resolução de DNS:

   nslookup b1.download.windowsupdate.com
   

2. Verificar conectividade HTTP:

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

Se a resolução DNS falhar ou a solicitação HTTP for bloqueada, prossiga para a Etapa 4 para investigar os bloqueadores da camada de rede.

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

Se as verificações DNS ou HTTP da Etapa 3 falharem, uma ou mais das seguintes configurações da camada de rede poderão estar bloqueando a conectividade upstream do host do nó de cache.

• Firewall: Verifique se o tráfego de saída nas portas 80 e 443 da máquina host do nó de cache é permitido. Consulte Endpoints de Otimização de Entrega para obter a lista completa de endpoints necessários.
• Proxy: se o seu ambiente usa um proxy, verifique se as configurações de proxy do nó de cache estão configuradas corretamente. Consulte a documentação de configuração de configurações de proxy .
• Inspeção TLS: se sua rede usa um proxy de inspeção TLS (por exemplo, ZScaler), configure-o para ignorar o tráfego de *.do.dsp.mp.microsoft.com e para endpoints. Consulte A implantação do nó de cache no Windows falha com "ERRO: não é possível verificar o certificado" ou A implantação do nó de cache no Linux falha com "ERRO: não é possível verificar o certificado" para obter as etapas de resolução.
• Encaminhamento de porta WSL (somente nós hospedados no Windows): confirme se as regras de encaminhamento de porta para as portas 80 e 443 estão em vigor. Consulte Regras de encaminhamento de porta WSL ausentes (443, 5000) para obter instruções.

Etapa 5: coletar diagnósticos

Se o problema persistir após a conclusão das etapas anteriores, gere um pacote de suporte de diagnóstico para compartilhar com o suporte da Microsoft. Consulte Geração de pacote de suporte de diagnóstico de nó de cache para obter instruções.

Atualize o DNS do Docker para usar seu próprio resolvedor de DNS

Se o nó de cache hospedado no Linux estiver enfrentando problemas de conectividade de rede, atualizar a configuração de DNS do Docker para usar o resolvedor de DNS da sua organização pode resolver o problema.

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

   nano /etc/docker/daemon.json
   

2. Atualize o conteúdo do arquivo para incluir o endereço IP do resolvedor 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. Salve e feche o arquivo usando 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

Você também pode usar a funcionalidade Diagnosticar e resolver problemas fornecida pela interface do portal do Azure. Essa guia no recurso do Azure de Cache Conectado da Microsoft orienta você por alguns prompts para ajudar a restringir a solução para seu problema.