Solución de problemas de Caché conectado de Microsoft para empresas y educación

Este artículo contiene instrucciones sobre cómo solucionar diferentes problemas que puede encontrar al usar la caché conectada. Estos problemas se clasifican por la tarea en la que se pueden encontrar.

Problemas conocidos

En esta sección se describen los problemas conocidos con la versión más reciente de Caché conectado de Microsoft para empresas y educación. Consulte la página Notas de la versión para obtener más detalles sobre las correcciones incluidas en la versión más reciente.

Falta el recurso de Azure de caché conectada de la selección ámbito en la pestaña "Métricas"

Puede crear gráficos personalizados en la Azure Portal De caché conectada; para ello, seleccione la pestaña Métricas en la sección Supervisión del recurso de Azure caché conectada. El recurso de Azure de caché conectada está seleccionado correctamente como ámbito de forma predeterminada, pero si cambia el ámbito seleccionado, no podrá volver a seleccionar el recurso De caché conectada Azure, lo que impide la creación posterior de gráficos personalizados.

Como solución alternativa temporal, puede salir de la pestaña Métricas y volver a ella. El recurso de Azure caché conectada vuelve a seleccionarse correctamente como ámbito.

limitaciones de importCert.ps1

El importCert.ps1 script se usa para importar certificados en el almacén de certificados de Windows como parte del proceso de configuración HTTPS para los nodos de caché hospedados en Windows. La aplicación windows de caché conectada v1.0.24.0 no admite la ejecución de este script en nodos de caché implementados en Windows Server 2022 o Windows Server 2025 con una cuenta en tiempo de ejecución de caché conectada de gMSA. Use la aplicación v1.0.26.0 o posterior para ejecutar este script en esos entornos.

Limitaciones de la aplicación del instalador de Windows de caché conectada

La aplicación del instalador de Windows de caché conectada es un paquete MSIX que se usa para implementar la caché conectada en máquinas host de Windows. La aplicación del instalador no admite actualmente Windows Server Core.

Revisión en la versión más reciente

Versión de disponibilidad general: 23/7/2025

• Se produce un error en la instalación de caché conectada cuando el equipo host de Windows está configurado con una configuración regional que no es EN.
• Los nodos de caché conectada hospedada en Windows pueden crecer más allá del tamaño de la unidad de caché configurada.

Pasos para obtener un identificador de suscripción de Azure

1. Inicie sesión en el Azure Portal.
2. Seleccione Suscripciones. Si no ve Suscripciones, escriba Suscripciones en la barra de búsqueda. Cuando empiece a escribir, la lista se filtra en función de la entrada.
3. Si ya tiene una suscripción Azure, vaya al paso 5. Si no tiene una suscripción Azure, seleccione + Agregar en la parte superior izquierda.
4. Seleccione la suscripción de pago por uso. Se le pedirá que escriba la información de la tarjeta de crédito, pero no se le cobrará por usar el servicio Microsoft Connected Cache.
5. En la página Suscripciones , encontrará detalles sobre la suscripción actual. Seleccione el nombre de la suscripción.
6. Después de seleccionar el nombre de la suscripción, encontrará el identificador de suscripción en la pestaña Información general . Seleccione el icono Copiar en el Portapapeles situado junto al identificador de suscripción para copiar el valor.

Solución de problemas Azure creación de recursos

La creación de recursos Azure caché conectada se puede iniciar mediante la interfaz de usuario Azure Portal o el conjunto de comandos de la CLI de Azure.

Si encuentra un error durante la creación de recursos, compruebe que tiene los permisos necesarios para crear Azure recursos en su suscripción y que ha rellenado todos los campos necesarios durante el proceso de creación de recursos.

Solución de problemas de configuración del nodo de caché

La configuración del nodo Caché conectada se puede realizar mediante la interfaz de usuario Azure Portal o el conjunto de comandos de la CLI de Azure.

Si encuentra un error de validación, compruebe que ha rellenado todos los campos de configuración necesarios.

Si parece que la configuración no surte efecto, compruebe que ha seleccionado la opción Guardar en la parte superior de la página de configuración de la interfaz de usuario Azure Portal.

Si ha cambiado la configuración del proxy, debe volver a implementar el software de caché conectada en la máquina host para que la configuración del proxy surta efecto.

Solución de problemas de implementación de nodos de caché en la máquina host de Windows

Recopilación de registros de instalación hospedados en Windows

La implementación de un nodo de caché conectada en una máquina host de Windows implica ejecutar una serie de scripts de PowerShell contenidos en la aplicación De Windows de caché conectada. Estos scripts intentan escribir archivos de registro en el directorio de script de la aplicación De caché conectada, especificado por deliveryoptimization-cli mcc-get-scripts-path.

Hay tres tipos de archivos de registro de instalación:

1. WSL_Mcc_Install_Transcript: este archivo de registro registra las líneas impresas en la ventana de PowerShell al ejecutar el script de instalación.
2. WSL_Mcc_Install_FromRegisteredTask_Status: este archivo de registro registra el estado de alto nivel que se escribe durante la instalación de tareas registradas.
3. WSL_Mcc_Install_FromRegisteredTask_Transcript: este archivo de registro registra el estado detallado que se escribe durante la instalación de tareas registradas.

La transcripción de tareas registradas suele ser la más útil para diagnosticar el problema de instalación.

Recopilación de otros registros hospedados en Windows

Una vez que el nodo de caché se haya instalado correctamente en el equipo host de Windows, escribirá periódicamente archivos de registro en el directorio de instalación (C:\mccwsl01\ de forma predeterminada).

Puede esperar ver los siguientes tipos de archivos de registro:

1. WSL_Mcc_Monitor_FromRegisteredTask_Transcript: este archivo de registro registra la salida de la tarea programada "MCC_Monitor_Task" que es responsable de garantizar que la caché conectada continúe ejecutándose.
2. WSL_Mcc_UserUninstall_Transcript: este archivo de registro registra la salida del script "uninstallmcconwsl.ps1" que el usuario puede ejecutar para desinstalar el software de caché conectada de la máquina host.
3. WSL_Mcc_Uninstall_FromRegisteredTask_Transcript: este archivo de registro registra la salida de la tarea programada "MCC_Uninstall_Task" que es responsable de desinstalar el software de caché conectada de la máquina host cuando lo llama el script "uninstallmcconwsl.ps1".

Inicio de un proceso de PowerShell como cuenta en tiempo de ejecución de caché conectada

Para solucionar problemas con el software de caché conectada en una máquina host de Windows, es posible que tenga que ejecutar comandos como cuenta en tiempo de ejecución de caché conectada. Para ello, inicie un proceso de PowerShell como la cuenta en tiempo de ejecución especificada durante la instalación de la caché conectada.

• Si la cuenta en tiempo de ejecución es una cuenta local, puede iniciar un proceso de PowerShell como cuenta en tiempo de ejecución ejecutando el siguiente comando en una ventana de PowerShell con privilegios elevados:

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

• Si la cuenta en tiempo de ejecución es una cuenta de dominio o servicio, puede iniciar un proceso de PowerShell como cuenta en tiempo de ejecución ejecutando el siguiente comando en una ventana de PowerShell con privilegios elevados:

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

• Si la cuenta en tiempo de ejecución es una cuenta de servicio administrada de grupo (gMSA), debe usar PsExec para iniciar un proceso de PowerShell como cuenta en tiempo de ejecución mediante la ejecución del siguiente comando en una ventana de PowerShell con privilegios elevados:

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

Comprobación de si el contenedor de caché conectada se está ejecutando

Una vez que el software de caché conectada se ha implementado correctamente en la máquina host de Windows, puede comprobar si el nodo de caché se ejecuta correctamente haciendo lo siguiente en el equipo host de Windows:

1. Iniciar un proceso de PowerShell como la cuenta especificada como cuenta en tiempo de ejecución durante la instalación de la caché conectada
2. Ejecutar wsl -d Ubuntu-24.04-Mcc para acceder a la distribución de Linux que hospeda el contenedor de caché conectada
3. Ejecutar sudo iotedge list para mostrar qué contenedores se ejecutan en el entorno de ejecución de IoT Edge

Si muestra los contenedores edgeAgent y edgeHub pero no muestra MCC, puede ver el estado del administrador de seguridad de IoT Edge mediante sudo iotedge system logs -- -f.

También puede reiniciar el entorno de ejecución de IoT Edge mediante sudo iotedge system restart. Consulte IoT Edge documentación de solución de problemas para obtener más información sobre la solución de problemas del entorno de ejecución de IoT Edge.

Se produce un error en la instalación de caché conectada durante el registro del nodo de caché

Como parte del proceso de instalación en máquinas host de Windows, la caché conectada intentará registrarse en el servicio Optimización de distribución llamando a un punto de conexión geomcc.prod.do.dsp.mp.microsoft.comde registro . Esta llamada se origina desde dentro de la distribución de WSL2 que hospeda el contenedor de caché conectada y debe ser correcta para que se instale el nodo de caché.

Para solucionar problemas de conexión, puede intentar ejecutar los siguientes comandos desde una ventana de PowerShell con privilegios elevados como cuenta en tiempo de ejecución de caché conectada.

En primer lugar, acceda a la distribución de WSL2 que hospeda el contenedor de caché conectada:

wsl -d Ubuntu-24.04-Mcc

A continuación, ejecute el siguiente comando de Bash para comprobar la resolución DNS del punto de conexión de registro:

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

Compruebe la conectividad TCP (puerto 443 para HTTPS) con el punto de conexión de registro:

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

Compruebe la respuesta HTTPS desde el punto de conexión de registro:

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

MCC_Install_Task tarea programada no se puede ejecutar

La instalación de caché conectada en máquinas host windows se basa en la tarea programada "MCC_Install_Task" para realizar acciones de instalación como la cuenta en tiempo de ejecución de caché conectada designada. Si esta tarea no se ejecuta, puede deberse a uno de los siguientes motivos.

directiva de grupo objeto entra en conflicto con el registro de tareas programadas

Habilitación del objeto directiva de grupo: acceso a la red: no permitir el almacenamiento de contraseñas y credenciales para la autenticación de red impedirá que el software de caché conectada registre las tareas programadas necesarias para el registro y la operación correctos del nodo de caché.

La cuenta en tiempo de ejecución de MCC no tiene permisos para iniciar sesión como trabajo por lotes

Asegúrese de que ha concedido a la cuenta de tiempo de ejecución de caché conectada el permiso "Iniciar sesión como trabajo por lotes". Este permiso es necesario para que la cuenta en tiempo de ejecución de la caché conectada ejecute tareas programadas.

La directiva de seguridad empresarial impide la ejecución de scripts de PowerShell

Asegúrese de que la directiva de ejecución de PowerShell en la máquina host de Windows permite la ejecución de scripts. Puede comprobar la directiva de ejecución actual ejecutando el siguiente comando en una ventana de PowerShell con privilegios elevados:

Get-ExecutionPolicy

Error en el registro de la tarea programada de MCC con el error de credencial gMSA

Si ve un error de instalación que indica que el nombre de usuario o la contraseña de gMSA son incorrectos al intentar registrar las tareas programadas de MCC, el problema puede deberse a una falta de coincidencia en el tipo de cifrado Kerberos entre el equipo host mcc y el controlador de dominio. Para resolver esto, el tipo de cifrado de la cuenta gMSA debe actualizarse para que coincida con el tipo de cifrado configurado en el controlador de dominio.

Puede comprobar y alinear esta configuración revisando la seguridad de red: Configurar los tipos de cifrado permitidos para la directiva Kerberos tanto en el controlador de dominio como en el atributo de la cuenta gMSA msDS-SupportedEncryptionTypes . Póngase en contacto con el equipo de Active Directory para actualizar el tipo de cifrado de la cuenta gMSA para que coincida con el controlador de dominio.

WSL2 no se puede instalar con el mensaje "No existe una sesión de inicio de sesión especificada"

Si encuentra este mensaje de error al intentar ejecutar el comando wsl.exe --install --no-distribution de PowerShell en el equipo host de Windows, compruebe que ha iniciado sesión como administrador local y ejecute el comando desde una ventana de PowerShell con privilegios elevados.

Actualización del kernel de WSL2

Si se produce un error en la instalación de la caché conectada debido a problemas relacionados con WSL, intente ejecutar wsl.exe --update para obtener la versión más reciente del kernel de WSL.

MCC_Monitor_Task tarea programada no se puede ejecutar

Una vez que se ejecuta el contenedor de caché conectada, la MCC_Monitor_Task tarea programada se ejecuta periódicamente en la cuenta en tiempo de ejecución de caché conectada para evitar que WSL detenga la distribución de WSL de caché conectada. Si el nodo de caché se desconecta sin ninguna acción del usuario, puede deberse a que la tarea programada "MCC_Monitor_Task" no se ejecuta correctamente.

Puede usar el Programador de tareas en la máquina host para comprobar el estado de esta tarea programada.

1. Abrir el programador de tareas en el equipo host
2. Vaya a la sección Tareas activas y haga doble clic en MCC_Monitor_Task
3. Compruebe las columnas Last Run Time y Last Run Result para ver si la operación se completó correctamente.
4. Seleccione la pestaña Desencadenadores y confirme que el estado está habilitado.
5. Seleccione la pestaña Historial y compruebe si hay errores o advertencias relacionados con la ejecución de la tarea.

Si el MCC_Monitor_Task no se ejecuta correctamente, puede deberse a credenciales de cuenta en tiempo de ejecución de caché conectada expiradas. En este caso, puede usar el updatetaskpasswords.ps1 script para actualizar las credenciales.

1. Abra un proceso de PowerShell como administrador.

2. Cambie el directorio al directorio de script y compruebe la presencia de updatetaskpasswords.ps1.

   • Si instaló La caché conectada mediante el paquete de implementación de versión preliminar pública, el directorio de script se encuentra dentro de la installationFolder especificada en el comando de implementación original ("C:\mccwsl01\MccScripts" de forma predeterminada).
   • Si instaló la caché conectada mediante la aplicación De Windows de caché conectada, el directorio de script se encuentra dentro del directorio devuelto por deliveryoptimization-cli mcc-get-scripts-path.

3. Cree un objeto PSCredential denominado $myLocalAccountCredential que represente la cuenta en tiempo de ejecución de la caché conectada con la nueva contraseña.

4. Ejecute el updatetaskpasswords.ps1 script con el siguiente comando:

   .\updatetaskpasswords.ps1 -Credential $myLocalAccountCredential
   

Nodo de caché implementado correctamente, pero sin atender solicitudes

Si el nodo de caché no responde a solicitudes fuera de localhost, puede deberse a que las reglas de reenvío de puertos de la máquina host no se establecieron correctamente durante la instalación de la caché conectada. Dado que WSL2 usa un adaptador Ethernet virtualizado de forma predeterminada, se necesitan reglas de reenvío de puertos para permitir que el tráfico llegue a la instancia de WSL2 desde la LAN. Para obtener más información, consulte Acceso a aplicaciones de red con WSL.

La caché conectada usa netsh portproxy para establecer reglas de reenvío de puertos que dirigen el tráfico desde la dirección IP de la máquina host a la distribución WSL que ejecuta el contenedor MCC. El servicio auxiliar de IP de Windows debe estar habilitado para que funcionen estas reglas. Si el servicio auxiliar de IP está deshabilitado, las reglas de reenvío de puertos establecidas a través netsh portproxy de no surtirá efecto y el contenedor MCC no recibirá ninguna solicitud de cliente desde fuera de localhost.

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

Para comprobar las reglas de reenvío de puertos de la máquina host, use el siguiente comando de PowerShell.

netsh interface portproxy show v4tov4

Si no ve ninguna regla de reenvío de puertos para el puerto 80 a 0.0.0.0, puede ejecutar el siguiente comando desde una instancia de PowerShell con privilegios elevados para establecer el reenvío adecuado en WSL.

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

Puede recuperar la dirección IP de WSL del wslip.txt archivo que debe estar presente en el directorio de instalación de la aplicación Caché conectada (C:\mccwsl01 de forma predeterminada).

Reglas de reenvío de puertoSL que faltan (443, 5000)

Para configurar correctamente los nodos de caché hospedados en Windows para que admitan HTTPS, debe crear una regla de reenvío de puertos para reenviar el tráfico desde el puerto 443 de la máquina host al puerto 443 en la distribución de WSL2 que hospeda el contenedor de caché conectada.

Para tener acceso remoto a la página Resumen de terse del nodo de caché hospedada en Windows, debe crear una regla de reenvío de puertos para reenviar el tráfico desde el puerto 5000 de la máquina host al puerto 5000 en la distribución de WSL2 que hospeda el contenedor de caché conectada.

Puede crear estas reglas de reenvío de puertos ejecutando los siguientes comandos en una ventana de PowerShell con privilegios elevados después de completar la implementación del nodo de caché.

$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

También deberá asegurarse de que el firewall de la máquina host permite el tráfico entrante en los puertos 443 y 5000. Para ello, ejecute los siguientes comandos en una ventana de PowerShell con privilegios elevados:

[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")

Se produce un error en la implementación del nodo de caché en Windows con "ERROR: no se puede comprobar el certificado"

Si encuentra un error durante la implementación del nodo de caché que indica "ERROR: no se puede comprobar el certificado", puede deberse al proxy de inspección tls de la red (por ejemplo, ZScaler) que intercepta la comunicación entre el software de caché conectada y el servicio optimización de entrega. Esta interceptación interrumpe la cadena de certificados e impide que la caché conectada se implemente correctamente.

Para resolver este problema, debe configurar el entorno de red para permitir llamadas a y desde "*.prod.do.dsp.mp.microsoft.com" para omitir el proxy de inspección de TLS.

También debe configurar los valores de proxy para el nodo de caché y, a continuación, colocar el archivo de certificado de proxy (.pem) en la ruta de acceso de installationFolder deseada y agregarla -proxyTlsCertificatePemFileName "mycert.pem" al comando de implementación. Por ejemplo, coloque el archivo .pem en C:\mccwsl01\mycert.pem y agregue -proxyTlsCertificatePemFileName "mycert.pem" al comando de implementación.

Solución de problemas de implementación de nodos de caché en Linux máquina host

La implementación de un nodo de caché conectada en una máquina host de Linux implica ejecutar una serie de scripts de Bash incluidos en el paquete de implementación de Linux.

Una vez que el software de caché conectada se ha implementado correctamente en la máquina host de Linux, puede comprobar si el nodo de caché se ejecuta correctamente haciendo lo siguiente en la máquina host de Linux:

1. Ejecutar sudo iotedge list para mostrar qué contenedores se ejecutan en el entorno de ejecución de IoT Edge

Si muestra los contenedores edgeAgent y edgeHub pero no muestra MCC, puede ver el estado del administrador de seguridad de IoT Edge mediante sudo iotedge system logs -- -f.

También puede reiniciar el entorno de ejecución de IoT Edge mediante sudo systemctl restart iotedge.

La implementación del nodo de caché en Linux produce un error con "ERROR: no se puede comprobar el certificado"

Si encuentra un error durante la implementación del nodo de caché que indica "ERROR: no se puede comprobar el certificado", puede deberse al proxy de inspección tls de la red (por ejemplo, ZScaler) que intercepta la comunicación entre el software de caché conectada y el servicio optimización de entrega. Esta interceptación interrumpe la cadena de certificados e impide que la caché conectada se implemente correctamente.

Para resolver este problema, debe configurar el entorno de red para permitir llamadas a y desde "*.prod.do.dsp.mp.microsoft.com" para omitir el proxy de inspección de TLS.

También debe configurar los valores de proxy para el nodo de caché y, a continuación, colocar el archivo de certificado de proxy (.pem) en el directorio del paquete de implementación extraído y agregarlo proxytlscertificatepath="/path/to/pem/file" al comando de implementación.

Generación de una agrupación de compatibilidad de diagnóstico de nodo de caché

Puede generar una agrupación de soporte técnico con información de diagnóstico detallada mediante la ejecución del collectMccDiagnostics.sh script incluido en el paquete de instalación.

En el caso de las máquinas host de Windows , debe hacer lo siguiente:

1. Iniciar un proceso de PowerShell como la cuenta especificada como cuenta en tiempo de ejecución durante la instalación de la caché conectada

2. Cambie el directorio al directorio "MccScripts" dentro del directorio de instalación de la aplicación De caché conectada (especificado en el comando de implementación, el valor predeterminado es C:\mccwsl01\MccScripts) y compruebe la presencia de collectmccdiagnostics.sh

3. Ejecución wsl bash collectmccdiagnostics.sh para generar la agrupación de compatibilidad de diagnóstico

4. Una vez completado el script, anote la salida de la consola que describe la ubicación de la agrupación de compatibilidad de diagnóstico.

   Por ejemplo, "Paquete comprimido correctamente, envíe el archivo creado en /etc/mccdiagnostics/support_bundle_2024_12_03__11_05_39__AM.tar.gz"

5. Ejecute el wsl cp comando para copiar la agrupación de compatibilidad desde la ubicación dentro de la distribución de Ubuntu al sistema operativo host de Windows.

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

Para Linux máquinas host, debe hacer lo siguiente:

1. Cambie el directorio al directorio "MccScripts" dentro del paquete de implementación de caché conectada extraído y compruebe la presencia de collectmccdiagnostics.sh

2. Ejecución collectmccdiagnostics.sh para generar la agrupación de compatibilidad de diagnóstico

3. Una vez completado el script, observe la salida de la consola que describe la ubicación de la agrupación de compatibilidad de diagnóstico.

   Por ejemplo, "Paquete comprimido correctamente, envíe el archivo creado en /etc/mccdiagnostics/support_bundle_2024_12_03__11_05_39__AM.tar.gz"

Solución de problemas de configuración de HTTPS

Si la entidad de certificación (CA) solo puede generar certificados firmados en formatos .pem o .cer, puede cambiar la extensión de archivo del archivo de certificado a .crt si el archivo está en codificación Base64.

Solución de problemas de supervisión de nodos de caché

El estado y el rendimiento del nodo de caché conectada se pueden supervisar mediante la interfaz de usuario Azure Portal.

Si los objetos visuales de supervisión básicos de la pestaña Información general muestran valores inesperados o erróneos, actualice la ventana del explorador. Si el problema persiste, compruebe que ha configurado los filtros de nodo Intervalo de tiempo y Caché como desee.

Tenga en cuenta que el estado "Correcto" viene determinado por la capacidad del contenedor de caché conectada para comunicarse correctamente con el servicio optimización de distribución. Si el nodo de caché muestra el estado "Incorrecto", compruebe que el nodo de caché tiene conectividad saliente a Internet y puede llegar a los puntos de conexión del servicio Optimización de distribución.

El estado "Correcto" solo refleja si el contenedor de caché conectada puede comunicarse con el servicio optimización de distribución. No comprueba que los dispositivos cliente DO de la red puedan llegar al nodo de caché. Un nodo "Correcto" todavía no se puede acceder a los clientes debido a reglas de firewall, brechas de reenvío de puertoSL2 o segmentación de red.

Solución de problemas de conectividad de cliente con el nodo de caché

Para probar la accesibilidad del cliente, visite la siguiente dirección URL desde un dispositivo cliente en la misma red que el nodo de caché y reemplace por CacheNodeIPAddress la dirección IP del nodo de caché:

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

Consulte el artículo Comprobar nodo de caché para obtener instrucciones más detalladas.

Opción DHCP 235 no recuperada debido a la configuración localPolicyMerge

Si usa la opción DHCP 235 para anunciar el nodo Caché conectada a los clientes, la configuración LocalPolicyMerge puede impedir que el cliente DHCP recupere la opción 235. Este problema es especialmente común en escenarios de aprovisionamiento de Windows Autopilot en los que se aplican líneas base de seguridad.

Si los clientes no detectan el nodo de caché a través de DHCP, compruebe si la configuración está configurada en el LocalPolicyMerge entorno. Si es así, considere la posibilidad de cambiar de la detección de la opción 235 dhcp a configurar directamente la directiva DOCacheHost con el nombre de host o la dirección IP del nodo de caché.

Diagnóstico de errores de accesibilidad del cliente

Si los clientes de la red siguen sin poder acceder al nodo de caché después de completar los pasos de comprobación anteriores, siga estos pasos para diagnosticar el problema.

Paso 1: Comprobar que se ejecutó la tarea programada MCC_Monitor_Task

La MCC_Monitor_Task tarea programada es responsable de mantener la distribución WSL de caché conectada en ejecución en máquinas host windows. Si la tarea no se está ejecutando, el nodo de caché puede estar sin conexión, lo que provoca errores de accesibilidad del cliente.

1. Abra el Programador de tareas en el equipo host de Windows.
2. En la sección Tareas activas , busque MCC_Monitor_Task.
3. Compruebe las columnas Last Run Time y Last Run Result para confirmar que la tarea se ejecutó correctamente.
4. Seleccione la pestaña Desencadenadores y confirme que el estado del desencadenador es Habilitado.

Si MCC_Monitor_Task no se puede ejecutar, consulte la sección MCC_Monitor_Task tarea programada no se puede ejecutar para ver los pasos de resolución.

Paso 2: Revisar WSL_Mcc_Monitor_FromRegisteredTask_Transcript.txt

El WSL_Mcc_Monitor_FromRegisteredTask_Transcript.txt archivo de registro registra la salida de cada MCC_Monitor_Task ejecución y es útil para identificar si la distribución de WSL de caché conectada o el contenedor encontraron un error.

1. Vaya al directorio de instalación de caché conectada en el equipo host de Windows.
   • El directorio de instalación predeterminado es C:\mccwsl01\.
   • Puede confirmar la ruta de acceso exacta si se ejecuta deliveryoptimization-cli mcc-get-scripts-path en una ventana de PowerShell con privilegios elevados.
2. Abra WSL_Mcc_Monitor_FromRegisteredTask_Transcript.txt en un editor de texto.
3. Revise el registro en busca de errores que indiquen que la distribución de WSL no se pudo iniciar o que el contenedor de caché conectada se detuvo inesperadamente.

Paso 3: Validar la resolución DNS y la conectividad HTTP a b1.download.windowsupdate.com

El nodo Caché conectada debe poder llegar a los puntos de conexión de entrega de contenido de Microsoft ascendentes para atender las solicitudes a los clientes. Use los siguientes comandos para comprobar que el host del nodo de caché puede resolver y conectarse a b1.download.windowsupdate.com.

Nodos de caché hospedados en Windows

1. Inicie un proceso de PowerShell como cuenta en tiempo de ejecución de caché conectada.

2. Acceso a la distribución de WSL2:

   wsl -d Ubuntu-24.04-Mcc
   

3. Comprobación de la resolución dns:

   nslookup b1.download.windowsupdate.com
   

4. Comprobación de la conectividad HTTP:

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

nodos de caché hospedados en Linux

Ejecute los siguientes comandos directamente en el equipo host de Linux.

1. Comprobación de la resolución dns:

   nslookup b1.download.windowsupdate.com
   

2. Comprobación de la conectividad HTTP:

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

Si se produce un error en la resolución DNS o se bloquea la solicitud HTTP, continúe con el paso 4 para investigar los bloqueadores de capa de red.

Paso 4: Comprobación de la configuración de inspección del firewall, proxy y TLS

Si se produce un error en las comprobaciones DE DNS o HTTP del paso 3, es posible que una o varias de las siguientes configuraciones de capa de red bloqueen la conectividad ascendente desde el host del nodo de caché.

• Firewall: asegúrese de que se permite el tráfico saliente en los puertos 80 y 443 desde la máquina host del nodo de caché. Consulte Puntos de conexión de optimización de distribución para obtener la lista completa de puntos de conexión necesarios.
• Proxy: si el entorno usa un proxy, compruebe que la configuración del proxy del nodo de caché está configurada correctamente. Consulte la documentación de configuración de configuración de proxy .
• Inspección de TLS: si la red usa un proxy de inspección de TLS (por ejemplo, ZScaler), configúrelo para omitir el tráfico hacia y desde los puntos de *.do.dsp.mp.microsoft.com conexión. Consulte Implementación de nodos de caché en Windows con el error "ERROR: no se puede comprobar el certificado" o Implementación de nodo de caché para Linux se produce un error con "ERROR: no se puede comprobar el certificado" para ver los pasos de resolución.
• Reenvío de puertos WSL (solo nodos hospedados en Windows): confirme que hay reglas de reenvío de puertos para los puertos 80 y 443. Consulte Reglas de reenvío de puertoSL que faltan (443, 5000) para obtener instrucciones.

Paso 5: Recopilación de diagnósticos

Si el problema persiste después de completar los pasos anteriores, genere una agrupación de soporte técnico de diagnóstico para compartirla con el soporte técnico de Microsoft. Consulte Generación de una agrupación de compatibilidad con el diagnóstico del nodo de caché para obtener instrucciones.

Actualización del DNS de Docker para usar su propia resolución DNS

Si el nodo de caché hospedada en Linux está experimentando problemas de conectividad de red, la actualización de la configuración dns de Docker para usar la resolución DNS de su organización puede resolver el problema.

1. Abra el archivo de configuración del demonio de Docker:

   nano /etc/docker/daemon.json
   

2. Actualice el contenido del archivo para incluir la dirección IP del solucionador DNS de su organización:

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

3. Guarde y cierre el archivo con Ctrl+X y, a continuación, Y para confirmar.

4. Reinicie Docker para que el cambio surta efecto:

   systemctl restart docker
   

5. Vuelva a ejecutar el comando IoT Edge check para validar la conectividad adecuada:

   iotedge check --verbose
   

Diagnóstico y resolución

También puede usar la funcionalidad Diagnosticar y resolver problemas proporcionada por la interfaz de Azure Portal. Esta pestaña del recurso de microsoft connected cache Azure le guiará a través de algunas indicaciones para ayudar a restringir la solución al problema.