Compartir a través de


Solución de problemas de microsoft connected cache for Enterprise and Education

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 problemas conocidos con la versión más reciente de Microsoft Connected Cache for Enterprise and Education. 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. Este script no admite actualmente 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.

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

Asignación 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. Ejecución 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 systemctl restart iotedge.

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

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.

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 una máquina host Linux

La implementación de un nodo de caché conectada en una máquina host Linux implica ejecutar una serie de scripts de Bash contenidos 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 Linux, puede comprobar si el nodo de caché se ejecuta correctamente si hace lo siguiente en el equipo host 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.

Nota

Después de volver a implementar un nodo de caché de Linux para que se migre al contenedor de versión de disponibilidad general, el usuario debe ejecutar chmod 777 -R /cachedrivepath y reiniciar el contenedor sudo iotedge restart MCCde caché conectada . De lo contrario, el nodo reimplementado estará en funcionamiento, pero se producirá un error en las solicitudes de contenido.

Se produce un error en la implementación del nodo de caché en Linux 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 por deliveryoptimization-cli mcc-get-scripts-path) 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/

En el caso de las máquinas host linux , 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.

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.