Risolvere i problemi di Microsoft Connected Cache per aziende e istruzione

Questo articolo contiene istruzioni su come risolvere i diversi problemi che possono verificarsi durante l'uso di Cache connessa. Questi problemi sono classificati in base all'attività in cui possono essere rilevati.

Problemi noti

Questa sezione descrive i problemi noti relativi alla versione più recente di Microsoft Connected Cache per aziende e istruzione. Per altre informazioni sulle correzioni incluse nella versione più recente, vedere la pagina Note sulla versione.

La risorsa Azure cache connessa non è presente nella selezione ambito nella scheda "Metriche"

È possibile creare grafici personalizzati nella portale di Azure cache connessa selezionando la scheda Metriche nella sezione Monitoraggio della risorsa cache connessa Azure. La risorsa Azure cache connessa è selezionata correttamente come ambito per impostazione predefinita, ma se si modifica l'ambito selezionato non è possibile deselezionare la risorsa Azure Cache connessa, impedendo la successiva creazione di grafici personalizzati.

Come soluzione temporanea, è possibile spostarsi dalla scheda Metriche e quindi tornare a tale scheda. La risorsa Azure cache connessa viene nuovamente selezionata correttamente come ambito.

importCert.ps1 limitazioni

Lo importCert.ps1 script viene usato per importare certificati nell'archivio certificati di Windows come parte del processo di configurazione HTTPS per i nodi della cache ospitata in Windows. L'applicazione Windows cache connessa v1.0.24.0 non supporta l'esecuzione di questo script nei nodi della cache distribuiti in Windows Server 2022 o Windows Server 2025 con un account di runtime della cache connessa gMSA. Usare l'applicazione v1.0.26.0 o versione successiva per eseguire questo script in tali ambienti.

Limitazioni dell'applicazione Windows Installer della cache connessa

L'applicazione Windows Installer della cache connessa è un pacchetto MSIX usato per distribuire Cache connessa nei computer host Windows. L'applicazione del programma di installazione non supporta attualmente Windows Server Core.

Patch nella versione più recente

Versione ga: 23/7/2025

• L'installazione della cache connessa non riesce quando il computer host Windows è configurato con impostazioni locali non EN.
• I nodi di Cache connessa ospitati in Windows possono superare le dimensioni dell'unità cache configurata.

Procedura per ottenere un ID sottoscrizione Azure

1. Accedere al portale di Azure.
2. Selezionare Sottoscrizioni. Se sottoscrizioni non vengono visualizzate, digitare Sottoscrizioni nella barra di ricerca. Quando si inizia a digitare, l'elenco viene filtrato in base all'input.
3. Se si dispone già di una sottoscrizione Azure, andare al passaggio 5. Se non si ha una sottoscrizione Azure, selezionare + Aggiungi in alto a sinistra.
4. Selezionare la sottoscrizione con pagamento in base al consumo . Verrà richiesto di immettere le informazioni sulla carta di credito, ma non verrà addebitato alcun costo per l'uso del servizio Microsoft Connected Cache.
5. Nella pagina Sottoscrizioni sono disponibili informazioni dettagliate sulla sottoscrizione corrente. Selezionare il nome della sottoscrizione.
6. Dopo aver selezionato il nome della sottoscrizione, è possibile trovare l'ID sottoscrizione nella scheda Panoramica . Selezionare l'icona Copia negli Appunti accanto all'ID sottoscrizione per copiare il valore.

Risoluzione dei problemi relativi alla creazione di risorse Azure

La creazione di risorse Azure cache connessa può essere avviata usando l'interfaccia utente portale di Azure o il set di comandi dell'interfaccia della riga di comando Azure.

Se si verifica un errore durante la creazione delle risorse, verificare di disporre delle autorizzazioni necessarie per creare Azure risorse nella sottoscrizione e di aver compilato tutti i campi necessari durante il processo di creazione delle risorse.

Risoluzione dei problemi di configurazione dei nodi della cache

La configurazione del nodo Cache connessa può essere eseguita usando l'interfaccia utente portale di Azure o il set di comandi dell'interfaccia della riga di comando Azure.

Se si verifica un errore di convalida, verificare di aver compilato tutti i campi di configurazione necessari.

Se la configurazione non sembra avere effetto, verificare di aver selezionato l'opzione Salva nella parte superiore della pagina di configurazione nell'interfaccia utente portale di Azure.

Se è stata modificata la configurazione del proxy, è necessario ridistribuire il software della cache connessa nel computer host per rendere effettiva la configurazione del proxy.

Risoluzione dei problemi di distribuzione dei nodi della cache nel computer host Windows

Raccolta dei log di installazione ospitati da Windows

La distribuzione di un nodo della cache connessa in un computer host Windows comporta l'esecuzione di una serie di script di PowerShell contenuti nell'applicazione Windows cache connessa. Questi script tentano di scrivere file di log nella directory script dell'applicazione Cache connessa, specificata da deliveryoptimization-cli mcc-get-scripts-path.

Esistono tre tipi di file di log di installazione:

1. WSL_Mcc_Install_Transcript: questo file di log registra le righe stampate nella finestra di PowerShell durante l'esecuzione dello script di installazione
2. WSL_Mcc_Install_FromRegisteredTask_Status: questo file di log registra lo stato di alto livello scritto durante l'installazione delle attività registrate
3. WSL_Mcc_Install_FromRegisteredTask_Transcript: questo file di log registra lo stato dettagliato scritto durante l'installazione delle attività registrate

La trascrizione attività registrata è in genere la più utile per diagnosticare il problema di installazione.

Raccolta di altri log ospitati da Windows

Dopo che il nodo della cache è stato installato correttamente nel computer host Windows, scriverà periodicamente i file di log nella directory di installazione (C:\mccwsl01\ per impostazione predefinita).

È possibile prevedere che vengano visualizzati i tipi di file di log seguenti:

1. WSL_Mcc_Monitor_FromRegisteredTask_Transcript: questo file di log registra l'output dell'attività pianificata "MCC_Monitor_Task" responsabile dell'esecuzione della cache connessa.
2. WSL_Mcc_UserUninstall_Transcript: questo file di log registra l'output dello script "uninstallmcconwsl.ps1" che l'utente può eseguire per disinstallare il software della cache connessa dal computer host.
3. WSL_Mcc_Uninstall_FromRegisteredTask_Transcript: questo file di log registra l'output dell'attività pianificata "MCC_Uninstall_Task" responsabile della disinstallazione del software della cache connessa dal computer host quando viene chiamato dallo script "uninstallmcconwsl.ps1".

Avvio di un processo di PowerShell come account di runtime della cache connessa

Per risolvere i problemi relativi al software della cache connessa in un computer host Windows, potrebbe essere necessario eseguire i comandi come account di runtime della cache connessa. A tale scopo, avviare un processo di PowerShell come account di runtime specificato durante l'installazione della cache connessa.

• Se l'account di runtime è un account locale, è possibile avviare un processo di PowerShell come account di runtime eseguendo il comando seguente in una finestra di PowerShell con privilegi elevati:

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

• Se l'account di runtime è un dominio o un account del servizio, è possibile avviare un processo di PowerShell come account di runtime eseguendo il comando seguente in una finestra di PowerShell con privilegi elevati:

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

• Se l'account di runtime è un account del servizio gestito di gruppo ,è necessario usare PsExec per avviare un processo di PowerShell come account di runtime eseguendo il comando seguente in una finestra di PowerShell con privilegi elevati:

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

Verifica dell'esecuzione del contenitore della cache connessa

Dopo aver distribuito correttamente il software della cache connessa nel computer host Windows, è possibile verificare se il nodo della cache è in esecuzione correttamente eseguendo le operazioni seguenti nel computer host Windows:

1. Avviare un processo di PowerShell come account specificato come account di runtime durante l'installazione della cache connessa
2. Eseguire wsl -d Ubuntu-24.04-Mcc per accedere alla distribuzione Linux che ospita il contenitore Cache connessa
3. Eseguire sudo iotedge list per visualizzare i contenitori in esecuzione all'interno del runtime di IoT Edge

Se vengono visualizzati i contenitori edgeAgent e edgeHub ma non viene visualizzato MCC, è possibile visualizzare lo stato del gestore della sicurezza IoT Edge usando sudo iotedge system logs -- -f.

È anche possibile riavviare il runtime di IoT Edge usando sudo iotedge system restart. Per altre informazioni sulla risoluzione dei problemi relativi al runtime di IoT Edge, vedere IoT Edge documentazione sulla risoluzione dei problemi.

L'installazione della cache connessa non riesce durante la registrazione del nodo della cache

Come parte del processo di installazione nei computer host Windows, La cache connessa tenterà di registrarsi con il servizio Ottimizzazione recapito chiamando un endpoint geomcc.prod.do.dsp.mp.microsoft.comdi registrazione. Questa chiamata ha origine dall'interno della distribuzione WSL2 che ospita il contenitore Cache connessa e deve avere esito positivo per l'installazione del nodo della cache.

Per risolvere i problemi di connessione, è possibile provare a eseguire i comandi seguenti da una finestra di PowerShell con privilegi elevati come account di runtime della cache connessa.

Accedere innanzitutto alla distribuzione WSL2 che ospita il contenitore Cache connessa:

wsl -d Ubuntu-24.04-Mcc

Eseguire quindi il comando bash seguente per controllare la risoluzione DNS dell'endpoint di registrazione:

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

Controllare la connettività TCP (porta 443 per HTTPS) all'endpoint di registrazione:

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

Controllare la risposta HTTPS dall'endpoint di registrazione:

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

MCC_Install_Task'esecuzione dell'attività pianificata non riesce

L'installazione della cache connessa nei computer host Windows si basa sull'attività pianificata "MCC_Install_Task" per eseguire le azioni di installazione come account di runtime della cache connessa designata. Se l'esecuzione di questa attività non riesce, può essere dovuta a uno dei motivi seguenti.

Criteri di gruppo oggetto è in conflitto con la registrazione pianificata dell'attività

Abilitazione dell'oggetto Criteri di gruppo: accesso alla rete: non consentire l'archiviazione di password e credenziali per l'autenticazione di rete impedirà al software della cache connessa di registrare le attività pianificate necessarie per la corretta registrazione e l'operazione del nodo della cache.

L'account di runtime di MCC non dispone delle autorizzazioni per l'accesso come processo batch

Assicurarsi di aver concesso all'account di runtime della cache connessa l'autorizzazione "Accedi come processo batch". Questa autorizzazione è necessaria per l'account di runtime della cache connessa per l'esecuzione di attività pianificate.

I criteri di sicurezza aziendali impediscono l'esecuzione di script di PowerShell

Assicurarsi che i criteri di esecuzione di PowerShell nel computer host Windows consentano l'esecuzione di script. È possibile controllare i criteri di esecuzione correnti eseguendo il comando seguente in una finestra di PowerShell con privilegi elevati:

Get-ExecutionPolicy

Registrazione attività pianificata mcc non riuscita con errore delle credenziali gMSA

Se viene visualizzato un errore di installazione che indica che il nome utente o la password gMSA non è corretto durante il tentativo di registrare attività pianificate mcc, il problema potrebbe essere causato da una mancata corrispondenza nel tipo di crittografia Kerberos tra il computer host MCC e il controller di dominio. Per risolvere questo errore, è necessario aggiornare il tipo di crittografia nell'account gMSA in modo che corrisponda al tipo di crittografia configurato nel controller di dominio.

È possibile controllare e allineare queste impostazioni esaminando sicurezza di rete: configurare i tipi di crittografia consentiti per i criteri Kerberos sia nel controller di dominio che nell'attributo dell'account msDS-SupportedEncryptionTypes gMSA. Contattare il team di Active Directory per aggiornare il tipo di crittografia dell'account gMSA in modo che corrisponda al controller di dominio.

L'installazione di WSL2 non riesce con il messaggio "Una sessione di accesso specificata non esiste"

Se si verifica questo messaggio di errore durante il tentativo di eseguire il comando wsl.exe --install --no-distribution PowerShell nel computer host Windows, verificare di essere connessi come amministratore locale ed eseguire il comando da una finestra di PowerShell con privilegi elevati.

Aggiornamento del kernel WSL2

Se l'installazione di Cache connessa ha esito negativo a causa di problemi correlati a WSL, provare a eseguire wsl.exe --update per ottenere la versione più recente del kernel WSL.

MCC_Monitor_Task'esecuzione dell'attività pianificata non riesce

Dopo l'esecuzione del contenitore cache connessa, l'attività pianificata MCC_Monitor_Task viene eseguita periodicamente nell'account di runtime della cache connessa per impedire a WSL di arrestare la distribuzione WSL della cache connessa. Se il nodo della cache passa offline senza alcuna azione dell'utente, potrebbe essere dovuto all'attività pianificata "MCC_Monitor_Task" non eseguita correttamente.

È possibile usare Utilità di pianificazione nel computer host per controllare lo stato di questa attività pianificata.

1. Aprire Utilità di pianificazione nel computer host
2. Passare alla sezione Attività attive e fare doppio clic su MCC_Monitor_Task
3. Controllare le colonne Last Run Time e Last Run Result per verificare se l'operazione è stata completata correttamente.
4. Selezionare la scheda Trigger e verificare che lo stato sia abilitato
5. Selezionare la scheda Cronologia e verificare la presenza di errori o avvisi correlati all'esecuzione dell'attività.

Se l'esecuzione del MCC_Monitor_Task non riesce, potrebbe essere dovuta alle credenziali dell'account di runtime della cache connessa scadute. In questo caso, è possibile usare lo updatetaskpasswords.ps1 script per aggiornare le credenziali.

1. Aprire un processo di PowerShell come amministratore.

2. Passare alla directory script e verificare la presenza di updatetaskpasswords.ps1.

   • Se la cache connessa è stata installata usando il pacchetto di distribuzione Anteprima pubblica, la directory dello script si trova all'interno dell'installationFolder specificato nel comando di distribuzione originale ("C:\mccwsl01\MccScripts" per impostazione predefinita).
   • Se è stata installata la cache connessa usando l'applicazione Windows della cache connessa, la directory dello script si trova all'interno della directory restituita da deliveryoptimization-cli mcc-get-scripts-path.

3. Creare un oggetto PSCredential denominato $myLocalAccountCredential che rappresenta l'account di runtime della cache connessa con la nuova password.

4. Eseguire lo updatetaskpasswords.ps1 script con il comando seguente:

   .\updatetaskpasswords.ps1 -Credential $myLocalAccountCredential
   

Il nodo della cache è stato distribuito correttamente ma non gestisce le richieste

Se il nodo della cache non risponde alle richieste esterne a localhost, è possibile che le regole di inoltro delle porte del computer host non siano state impostate correttamente durante l'installazione di Cache connessa. Poiché WSL2 usa una scheda Ethernet virtualizzata per impostazione predefinita, sono necessarie regole di inoltro delle porte per consentire al traffico di raggiungere l'istanza WSL2 dalla lan. Per altre informazioni, vedere Accesso alle applicazioni di rete con WSL.

La cache connessa usa netsh portproxy per impostare le regole di inoltro delle porte che indirizzano il traffico dall'indirizzo IP del computer host alla distribuzione WSL che esegue il contenitore MCC. Per il funzionamento di queste regole, è necessario abilitare il servizio Helper IP di Windows. Se il servizio helper IP è disabilitato, le regole di inoltro delle porte impostate tramite netsh portproxy non saranno effettive e il contenitore MCC non riceverà richieste client dall'esterno di localhost.

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

Per controllare le regole di inoltro delle porte del computer host, usare il comando di PowerShell seguente.

netsh interface portproxy show v4tov4

Se non vengono visualizzate regole di inoltro delle porte per la porta da 80 a 0.0.0.0, è possibile eseguire il comando seguente da un'istanza di PowerShell con privilegi elevati per impostare l'inoltro corretto su WSL.

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

È possibile recuperare l'indirizzo IP WSL dal wslip.txt file che deve essere presente nella directory di installazione dell'applicazione Cache connessa (C:\mccwsl01 per impostazione predefinita).

Regole di inoltro porte WSL mancanti (443, 5000)

Per configurare correttamente i nodi della cache ospitata in Windows per supportare HTTPS, è necessario creare una regola di inoltro delle porte per inoltrare il traffico dalla porta 443 nel computer host alla porta 443 nella distribuzione WSL2 che ospita il contenitore Cache connessa.

Per accedere in modalità remota alla pagina Riepilogo Terse del nodo cache ospitata in Windows, è necessario creare una regola di inoltro delle porte per inoltrare il traffico dalla porta 5000 nel computer host alla porta 5000 nella distribuzione WSL2 che ospita il contenitore cache connessa.

È possibile creare queste regole di inoltro delle porte eseguendo i comandi seguenti in una finestra di PowerShell con privilegi elevati dopo aver completato la distribuzione del nodo della 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

È anche necessario assicurarsi che il firewall del computer host consenta il traffico in ingresso sulle porte 443 e 5000. A tale scopo, eseguire i comandi seguenti in una finestra di PowerShell con privilegi elevati:

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

La distribuzione dei nodi della cache in Windows ha esito negativo con "ERRORE: impossibile verificare il certificato"

Se si verifica un errore durante la distribuzione del nodo della cache che indica "ERRORE: impossibile verificare il certificato", potrebbe essere dovuto al proxy di controllo TLS della rete (ad esempio ZScaler) che intercetta la comunicazione tra il software della cache connessa e il servizio Ottimizzazione recapito. Questa intercettazione interrompe la catena di certificati e impedisce la corretta distribuzione di Cache connessa.

Per risolvere questo problema, è necessario configurare l'ambiente di rete per consentire le chiamate da e verso "*.prod.do.dsp.mp.microsoft.com" per ignorare il proxy di controllo TLS.

È anche necessario configurare le impostazioni proxy per il nodo della cache, quindi inserire il file del certificato proxy (con estensione pem) nel percorso di cartella desiderato e aggiungere -proxyTlsCertificatePemFileName "mycert.pem" al comando di distribuzione. Ad esempio, inserire il file con estensione pem in C:\mccwsl01\mycert.pem e aggiungere -proxyTlsCertificatePemFileName "mycert.pem" al comando di distribuzione.

Risoluzione dei problemi di distribuzione dei nodi della cache nel computer host Linux

La distribuzione di un nodo della cache connessa in un computer host Linux comporta l'esecuzione di una serie di script Bash contenuti nel pacchetto di distribuzione Linux.

Dopo aver distribuito correttamente il software della cache connessa nel computer host Linux, è possibile verificare se il nodo della cache è in esecuzione correttamente eseguendo le operazioni seguenti nel computer host Linux:

1. Eseguire sudo iotedge list per visualizzare i contenitori in esecuzione all'interno del runtime di IoT Edge

Se vengono visualizzati i contenitori edgeAgent e edgeHub ma non viene visualizzato MCC, è possibile visualizzare lo stato del gestore della sicurezza IoT Edge usando sudo iotedge system logs -- -f.

È anche possibile riavviare il runtime di IoT Edge usando sudo systemctl restart iotedge.

La distribuzione del nodo della cache in Linux non riesce con "ERRORE: impossibile verificare il certificato"

Se si verifica un errore durante la distribuzione del nodo della cache che indica "ERRORE: impossibile verificare il certificato", potrebbe essere dovuto al proxy di controllo TLS della rete (ad esempio ZScaler) che intercetta la comunicazione tra il software della cache connessa e il servizio Ottimizzazione recapito. Questa intercettazione interrompe la catena di certificati e impedisce la corretta distribuzione di Cache connessa.

Per risolvere questo problema, è necessario configurare l'ambiente di rete per consentire le chiamate da e verso "*.prod.do.dsp.mp.microsoft.com" per ignorare il proxy di controllo TLS.

È anche necessario configurare le impostazioni proxy per il nodo della cache, quindi inserire il file del certificato proxy (con estensione pem) nella directory del pacchetto di distribuzione estratto e aggiungere proxytlscertificatepath="/path/to/pem/file" al comando di distribuzione.

Generazione del bundle di supporto per la diagnostica dei nodi della cache

È possibile generare un bundle di supporto con informazioni di diagnostica dettagliate eseguendo lo collectMccDiagnostics.sh script incluso nel pacchetto di installazione.

Per i computer host Windows , è necessario eseguire le operazioni seguenti:

1. Avviare un processo di PowerShell come account specificato come account di runtime durante l'installazione della cache connessa

2. Passare alla directory "MccScripts" all'interno della directory di installazione dell'applicazione Connected Cache (specificata nel comando di distribuzione, il valore predefinito è C:\mccwsl01\MccScripts) e verificare la presenza di collectmccdiagnostics.sh

3. Eseguire wsl bash collectmccdiagnostics.sh per generare il bundle di supporto diagnostico

4. Al termine dello script, prendere nota dell'output della console che descrive la posizione del bundle di supporto diagnostico

   Ad esempio, "Pacchetto compresso correttamente, inviare il file creato in /etc/mccdiagnostics/support_bundle_2024_12_03__11_05_39__AM.tar.gz"

5. Eseguire il wsl cp comando per copiare il bundle di supporto dal percorso all'interno della distribuzione Ubuntu nel sistema operativo host Windows

   Per esempio wsl cp /etc/mccdiagnostics/support_bundle_2024_12_03__11_05_39__AM.tar.gz /mnt/c/mccwsl01/SupportBundles/

Per Linux computer host, è necessario eseguire le operazioni seguenti:

1. Passare alla directory "MccScripts" all'interno del pacchetto di distribuzione della cache connessa estratta e verificare la presenza di collectmccdiagnostics.sh

2. Eseguire collectmccdiagnostics.sh per generare il bundle di supporto diagnostico

3. Al termine dello script, prendere nota dell'output della console che descrive la posizione del bundle di supporto diagnostico

   Ad esempio, "Pacchetto compresso correttamente, inviare il file creato in /etc/mccdiagnostics/support_bundle_2024_12_03__11_05_39__AM.tar.gz"

Risoluzione dei problemi relativi alla configurazione HTTPS

Se l'autorità di certificazione (CA) è in grado di generare certificati firmati solo nei formati con estensione pem o .cer, è possibile modificare l'estensione del file del certificato in .crt se il file è in codifica Base64.

Risoluzione dei problemi relativi al monitoraggio dei nodi della cache

Lo stato e le prestazioni del nodo della cache connessa possono essere monitorati usando l'interfaccia utente portale di Azure.

Se gli oggetti visivi di monitoraggio di base nella scheda Panoramica mostrano valori imprevisti o errati, aggiornare la finestra del browser. Se il problema persiste, verificare di aver configurato i filtri dei nodi Timespan e Cache come desiderato.

Si noti che lo stato "Integro" è determinato dalla capacità del contenitore di Cache connessa di comunicare correttamente con il servizio Ottimizzazione recapito. Se il nodo della cache mostra lo stato "Non integro", verificare che il nodo della cache abbia connettività in uscita a Internet e possa raggiungere gli endpoint del servizio Ottimizzazione recapito.

Lo stato "Integro" riflette solo se il contenitore Cache connessa può comunicare con il servizio Ottimizzazione recapito. Non verifica che i dispositivi client DO in rete possano raggiungere il nodo della cache. Un nodo "Integro" può comunque non essere raggiungibile dai client a causa delle regole del firewall, dei gap di inoltro delle porte WSL2 o della segmentazione di rete.

Risoluzione dei problemi di connettività client al nodo della cache

Per testare la raggiungibilità del client, visitare l'URL seguente da un dispositivo client nella stessa rete del nodo della cache, sostituendo CacheNodeIPAddress con l'indirizzo IP del nodo della cache:

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

Per istruzioni più dettagliate, vedere l'articolo Verificare il nodo della cache .

Opzione DHCP 235 non recuperata a causa dell'impostazione LocalPolicyMerge

Se si usa l'opzione DHCP 235 per annunciare il nodo Cache connessa ai client, l'impostazione LocalPolicyMerge può impedire al client DHCP di recuperare l'opzione 235. Questo problema è particolarmente comune negli scenari di provisioning di Windows Autopilot in cui vengono applicate le baseline di sicurezza.

Se i client non individuano il nodo della cache tramite DHCP, verificare se l'impostazione LocalPolicyMerge è configurata nell'ambiente. In caso affermativo, provare a passare dall'individuazione dell'opzione DHCP 235 alla configurazione diretta dei criteri DOCacheHost con il nome host o l'indirizzo IP del nodo della cache.

Diagnosticare gli errori di raggiungibilità del client

Se i client nella rete non riescono ancora a raggiungere il nodo della cache dopo aver completato i passaggi di verifica precedenti, seguire questa procedura per diagnosticare il problema.

Passaggio 1: Verificare che l'attività pianificata MCC_Monitor_Task sia stata eseguita

L'attività MCC_Monitor_Task pianificata è responsabile del mantenimento della distribuzione WSL della cache connessa in esecuzione nei computer host Windows. Se l'attività non è in esecuzione, il nodo della cache potrebbe essere offline, causando errori di raggiungibilità del client.

1. Aprire Utilità di pianificazione nel computer host Windows.
2. Nella sezione Attività attive individuare MCC_Monitor_Task.
3. Controllare le colonne Last Run Time e Last Run Result per verificare che l'attività sia stata eseguita correttamente.
4. Selezionare la scheda Trigger e verificare che lo stato del trigger sia Abilitato.

Se MCC_Monitor_Task l'esecuzione non riesce, vedere la sezione MCC_Monitor_Task'esecuzione dell'attività pianificata non riesce per i passaggi di risoluzione.

Passaggio 2: Esaminare WSL_Mcc_Monitor_FromRegisteredTask_Transcript.txt

Il WSL_Mcc_Monitor_FromRegisteredTask_Transcript.txt file di log registra l'output di ogni MCC_Monitor_Task esecuzione ed è utile per identificare se la distribuzione WSL della cache connessa o il contenitore ha rilevato un errore.

1. Passare alla directory di installazione di Cache connessa nel computer host Windows.
   • La directory di installazione predefinita è C:\mccwsl01\.
   • È possibile confermare il percorso esatto eseguendo deliveryoptimization-cli mcc-get-scripts-path in una finestra di PowerShell con privilegi elevati.
2. Aprire WSL_Mcc_Monitor_FromRegisteredTask_Transcript.txt in un editor di testo.
3. Esaminare il log per individuare gli errori che indicano che la distribuzione WSL non è stata avviata o che il contenitore della cache connessa è stato arrestato in modo imprevisto.

Passaggio 3: Convalidare la risoluzione DNS e la connettività HTTP per b1.download.windowsupdate.com

Il nodo Cache connessa deve essere in grado di raggiungere gli endpoint di recapito del contenuto Microsoft upstream per gestire le richieste ai client. Usare i comandi seguenti per verificare che l'host del nodo della cache possa risolvere e connettersi a b1.download.windowsupdate.com.

Nodi della cache ospitata in Windows

1. Avviare un processo di PowerShell come account di runtime della cache connessa.

2. Accedere alla distribuzione WSL2:

   wsl -d Ubuntu-24.04-Mcc
   

3. Controllare la risoluzione DNS:

   nslookup b1.download.windowsupdate.com
   

4. Controllare la connettività HTTP:

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

nodi della cache ospitati Linux

Eseguire i comandi seguenti direttamente nel computer host Linux.

1. Controllare la risoluzione DNS:

   nslookup b1.download.windowsupdate.com
   

2. Controllare la connettività HTTP:

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

Se la risoluzione DNS ha esito negativo o la richiesta HTTP è bloccata, passare al passaggio 4 per analizzare i blocchi a livello di rete.

Passaggio 4: Controllare le impostazioni di ispezione di firewall, proxy e TLS

Se i controlli DNS o HTTP del passaggio 3 hanno esito negativo, una o più delle configurazioni a livello di rete seguenti potrebbero bloccare la connettività upstream dall'host del nodo della cache.

• Firewall: assicurarsi che il traffico in uscita sulle porte 80 e 443 dal computer host del nodo della cache sia consentito. Per l'elenco completo degli endpoint necessari, vedere Endpoint di ottimizzazione recapito.
• Proxy: se l'ambiente usa un proxy, verificare che le impostazioni proxy del nodo della cache siano configurate correttamente. Fare riferimento alla documentazione di configurazione delle impostazioni proxy .
• Ispezione TLS: se la rete usa un proxy di controllo TLS ,ad esempio ZScaler, configurarlo per ignorare il traffico da *.do.dsp.mp.microsoft.com e verso gli endpoint. Per i passaggi di risoluzione, vedere La distribuzione dei nodi della cache in Windows non riesce con "ERRORE: non è possibile verificare il certificato" o La distribuzione del nodo della cache per Linux ha esito negativo con "ERRORE: non è possibile verificare il certificato".
• Inoltro delle porte WSL (solo nodi ospitati da Windows): verificare che le regole di inoltro delle porte per le porte 80 e 443 siano valide. Per istruzioni, vedere Regole di inoltro porte WSL mancanti (443, 5000).

Passaggio 5: Raccogliere la diagnostica

Se il problema persiste dopo aver completato i passaggi precedenti, generare un bundle di supporto diagnostico da condividere con il supporto tecnico Microsoft. Per istruzioni, vedere Generazione del bundle di supporto per la diagnostica dei nodi della cache .

Aggiornare il DNS Docker per usare il proprio resolver DNS

Se nel nodo della cache ospitata Linux si verificano problemi di connettività di rete, l'aggiornamento della configurazione DNS di Docker per usare il resolver DNS dell'organizzazione potrebbe risolvere il problema.

1. Aprire il file di configurazione del daemon Docker:

   nano /etc/docker/daemon.json
   

2. Aggiornare il contenuto del file in modo da includere l'indirizzo IP del resolver DNS dell'organizzazione:

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

3. Salvare e chiudere il file usando CTRL+X, quindi Y per confermare.

4. Riavviare Docker per rendere effettiva la modifica:

   systemctl restart docker
   

5. Eseguire di nuovo il comando IoT Edge check per convalidare la connettività corretta:

   iotedge check --verbose
   

Diagnosticare e risolvere

È anche possibile usare la funzionalità Diagnostica e risoluzione dei problemi fornita dall'interfaccia portale di Azure. Questa scheda all'interno della risorsa Microsoft Connected Cache Azure illustra alcune richieste per ridurre la soluzione al problema.