Compartilhar via

Resolver problemas da Cache Ligada da Microsoft para Empresas e Educação

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 da Cache Ligada da Microsoft para Empresas e Educação. 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. Atualmente, este script não suporta nós de cache implementados no Windows Server 2022 ou Windows Server 2025 com uma conta de runtime da Cache Ligada gMSA.

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".

Criar 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 do Linux que aloja o contentor de 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 systemctl restart iotedge.

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

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).

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 no computador anfitrião do Linux

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 do Linux.

Depois de o software de Cache Ligada ter sido implementado com êxito no computador anfitrião do 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.

Observação

Depois de reimplementar um nó de cache do Linux para que seja migrado para o contentor de versão ga, o utilizador tem de executar chmod 777 -R /cachedrivepath e, em seguida, reiniciar o contentor sudo iotedge restart MCCda Cache Ligada. Caso contrário, o nó reimplementado estará operacional, mas os pedidos de conteúdo falharão.

A implementação do nó de cache no Linux 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 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 por deliveryoptimization-cli mcc-get-scripts-path) 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 máquinas anfitriãs do Linux , 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.

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.

  • Last updated on