Problembehandlung bei Microsoft Connected Cache für Unternehmen und Bildungseinrichtungen

Dieser Artikel enthält Anweisungen zur Behandlung verschiedener Probleme, die bei der Verwendung von Connected Cache auftreten können. Diese Probleme werden nach der Aufgabe kategorisiert, in der sie auftreten können.

Bekannte Probleme

In diesem Abschnitt werden bekannte Probleme mit der neuesten Version von Microsoft Connected Cache for Enterprise and Education beschrieben. Weitere Informationen zu den In der neuesten Version enthaltenen Korrekturen finden Sie auf der Seite mit den Versionshinweisen .

Connected Cache Azure Ressource fehlt in der Bereichsauswahl auf der Registerkarte "Metriken"

Sie können benutzerdefinierte Diagramme im Azure-Portal Connected Cache erstellen, indem Sie die Registerkarte Metriken im Abschnitt Überwachung der Ressource Connected Cache Azure auswählen. Die Ressource Connected Cache Azure ist standardmäßig ordnungsgemäß als Bereich ausgewählt. Wenn Sie den ausgewählten Bereich ändern, können Sie die Ressource Connected Cache Azure nicht erneut auswählen, wodurch die nachfolgende Erstellung von benutzerdefinierten Diagrammen verhindert wird.

Als vorübergehende Problemumgehung können Sie von der Registerkarte Metriken weg navigieren und dann zu ihr zurückkehren. Die Ressource Connected Cache Azure ist erneut richtig als Bereich ausgewählt.

importCert.ps1 Einschränkungen

Das importCert.ps1 Skript wird verwendet, um Zertifikate im Rahmen des HTTPS-Konfigurationsprozesses für von Windows gehostete Cacheknoten in den Windows-Zertifikatspeicher zu importieren. Dieses Skript unterstützt derzeit keine Cacheknoten, die in Windows Server 2022 oder Windows Server 2025 mit einem gMSA Connected Cache-Laufzeitkonto bereitgestellt wurden.

Einschränkungen der Windows Installer-Anwendung für Connected Cache

Die Windows-Installationsprogrammanwendung für connected Cache ist ein MSIX-Paket, das zum Bereitstellen von Connected Cache auf Windows-Hostcomputern verwendet wird. Die Installationsprogrammanwendung unterstützt derzeit Windows Server Core nicht.

In der neuesten Version gepatcht

Allgemein verfügbares Release: 23.07.2025

• Bei der Installation des verbundenen Caches tritt ein Fehler auf, wenn der Windows-Hostcomputer mit einem Nicht-EN-Gebietsschema konfiguriert ist.
• In Windows gehostete Connected Cache-Knoten können über die konfigurierte Cachelaufwerkgröße herwachsen.

Schritte zum Abrufen einer Azure-Abonnement-ID

1. Melden Sie sich beim Azure-Portal an.
2. Wählen Sie Abonnements aus. Wenn Abonnements nicht angezeigt wird, geben Sie Abonnements in die Suchleiste ein. Wenn Sie mit der Eingabe beginnen, filtert die Liste basierend auf Ihrer Eingabe.
3. Wenn Sie bereits über ein Azure-Abonnement verfügen, fahren Sie mit Schritt 5 fort. Wenn Sie nicht über ein Azure-Abonnement verfügen, wählen Sie oben links + Hinzufügen aus.
4. Wählen Sie das Abonnement Nutzungsbasierte Bezahlung aus. Sie werden aufgefordert, eine Gutschrift Karte Informationen einzugeben, die Nutzung des Microsoft Connected Cache-Diensts wird Ihnen jedoch nicht in Rechnung gestellt.
5. Auf der Seite Abonnements finden Sie Details zu Ihrem aktuellen Abonnement. Wählen Sie den Abonnementnamen aus.
6. Nachdem Sie den Abonnementnamen ausgewählt haben, finden Sie die Abonnement-ID auf der Registerkarte Übersicht . Wählen Sie das Symbol In Zwischenablage kopieren neben Ihrer Abonnement-ID aus, um den Wert zu kopieren.

Problembehandlung bei Azure Ressourcenerstellung

Die Erstellung von Connected Cache Azure Ressourcen kann entweder über die Azure-Portal-Benutzeroberfläche oder den Azure CLI-Befehlssatz initiiert werden.

Wenn bei der Ressourcenerstellung ein Fehler auftritt, überprüfen Sie, ob Sie über die erforderlichen Berechtigungen zum Erstellen Azure Ressourcen unter Ihrem Abonnement verfügen und während des Ressourcenerstellungsprozesses alle erforderlichen Felder ausgefüllt haben.

Problembehandlung bei der Cacheknotenkonfiguration

Die Konfiguration ihres Connected Cache-Knotens kann entweder über die Azure-Portal-Benutzeroberfläche oder den Azure CLI-Befehlssatz erfolgen.

Wenn ein Überprüfungsfehler auftritt, überprüfen Sie, ob Sie alle erforderlichen Konfigurationsfelder ausgefüllt haben.

Wenn Ihre Konfiguration anscheinend nicht wirksam wird, überprüfen Sie, ob Sie die Option Speichern oben auf der Konfigurationsseite in der Azure-Portal-Benutzeroberfläche ausgewählt haben.

Wenn Sie die Proxykonfiguration geändert haben, müssen Sie die Connected Cache-Software erneut auf dem Hostcomputer bereitstellen, damit die Proxykonfiguration wirksam wird.

Problembehandlung bei der Bereitstellung von Cacheknoten auf dem Windows-Hostcomputer

Sammeln von Von Windows gehosteten Installationsprotokollen

Beim Bereitstellen eines Knotens für einen verbundenen Cache auf einem Windows-Hostcomputer wird eine Reihe von PowerShell-Skripts ausgeführt, die in der Windows-Anwendung "Connected Cache" enthalten sind. Diese Skripts versuchen, Protokolldateien in das Skriptverzeichnis der Connected Cache-Anwendung zu schreiben, das durch angegeben wird deliveryoptimization-cli mcc-get-scripts-path.

Es gibt drei Arten von Installationsprotokolldateien:

1. WSL_Mcc_Install_Transcript: Diese Protokolldatei zeichnet die Zeilen auf, die beim Ausführen des Installationsskripts im PowerShell-Fenster ausgegeben werden.
2. WSL_Mcc_Install_FromRegisteredTask_Status: Diese Protokolldatei zeichnet die allgemeine status auf, die während der Installation registrierter Aufgaben geschrieben wird.
3. WSL_Mcc_Install_FromRegisteredTask_Transcript: Diese Protokolldatei zeichnet die detaillierten status auf, die während der Installation registrierter Aufgaben geschrieben werden.

Das Transkript für registrierte Aufgaben ist in der Regel am nützlichsten für die Diagnose des Installationsproblems.

Sammeln anderer von Windows gehosteter Protokolle

Sobald der Cacheknoten erfolgreich auf dem Windows-Hostcomputer installiert wurde, schreibt er in regelmäßigen Abständen Protokolldateien in das Installationsverzeichnis (C:\mccwsl01\ standardmäßig).

Sie können davon ausgehen, dass die folgenden Arten von Protokolldateien angezeigt werden:

1. WSL_Mcc_Monitor_FromRegisteredTask_Transcript: Diese Protokolldatei zeichnet die Ausgabe der geplanten Aufgabe "MCC_Monitor_Task" auf, die dafür verantwortlich ist, dass der verbundene Cache weiterhin ausgeführt wird.
2. WSL_Mcc_UserUninstall_Transcript: Diese Protokolldatei zeichnet die Ausgabe des Skripts "uninstallmcconwsl.ps1" auf, das der Benutzer ausführen kann, um die Connected Cache-Software vom Hostcomputer zu deinstallieren.
3. WSL_Mcc_Uninstall_FromRegisteredTask_Transcript: Diese Protokolldatei zeichnet die Ausgabe der geplanten Aufgabe "MCC_Uninstall_Task" auf, die für die Deinstallation der Connected Cache-Software vom Hostcomputer zuständig ist, wenn sie vom Skript "uninstallmcconwsl.ps1" aufgerufen wird.

Lauching a PowerShell process as the Connected Cache runtime account

Um Probleme mit der Connected Cache-Software auf einem Windows-Hostcomputer zu beheben, müssen Sie möglicherweise Befehle als Laufzeitkonto des verbundenen Caches ausführen. Hierzu können Sie einen PowerShell-Prozess als Laufzeitkonto starten, das während der Installation des verbundenen Caches angegeben wurde.

• Wenn das Laufzeitkonto ein lokales Konto ist, können Sie einen PowerShell-Prozess als Laufzeitkonto starten, indem Sie den folgenden Befehl in einem PowerShell-Fenster mit erhöhten Rechten ausführen:

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

• Wenn das Laufzeitkonto ein Domänen- oder Dienstkonto ist, können Sie einen PowerShell-Prozess als Laufzeitkonto starten, indem Sie den folgenden Befehl in einem PowerShell-Fenster mit erhöhten Rechten ausführen:

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

• Wenn das Laufzeitkonto ein gruppenverwaltetes Dienstkonto (Group Managed Service Account, gMSA) ist, müssen Sie PsExec verwenden, um einen PowerShell-Prozess als Laufzeitkonto zu starten, indem Sie den folgenden Befehl in einem PowerShell-Fenster mit erhöhten Rechten ausführen:

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

Überprüfen, ob der Connected Cache-Container ausgeführt wird

Nachdem die Connected Cache-Software erfolgreich auf dem Windows-Hostcomputer bereitgestellt wurde, können Sie überprüfen, ob der Cacheknoten ordnungsgemäß ausgeführt wird, indem Sie auf dem Windows-Hostcomputer wie folgt vorgehen:

1. Starten Sie einen PowerShell-Prozess als das Konto, das während der Installation des verbundenen Caches als Laufzeitkonto angegeben wurde.
2. Führen Sie aus wsl -d Ubuntu-24.04-Mcc , um auf die Linux-Distribution zuzugreifen, die den Connected Cache-Container hostet.
3. Führen Sie aussudo iotedge list, um anzuzeigen, welche Container innerhalb der IoT Edge Runtime ausgeführt werden.

Wenn die Container edgeAgent und edgeHub, aber nicht MCC angezeigt werden, können Sie die status des IoT Edge-Sicherheits-Managers mithilfe sudo iotedge system logs -- -fvon anzeigen.

Sie können die IoT Edge Runtime auch mit sudo systemctl restart iotedgeneu starten.

Fehler bei der Installation des verbundenen Caches während der Registrierung des Cacheknotens

Im Rahmen des Installationsvorgangs auf Windows-Hostcomputern versucht Connected Cache, sich selbst beim Übermittlungsoptimierungsdienst zu registrieren, indem ein Registrierungsendpunkt geomcc.prod.do.dsp.mp.microsoft.comaufgerufen wird. Dieser Aufruf stammt aus der WSL2-Distribution, die den Connected Cache-Container hostet, und muss erfolgreich sein, damit der Cacheknoten installiert werden kann.

Zur Problembehandlung bei der Verbindung können Sie versuchen, die folgenden Befehle in einem PowerShell-Fenster mit erhöhten Rechten als Connected Cache-Laufzeitkonto auszuführen.

Greifen Sie zunächst auf die WSL2-Verteilung zu, die den Connected Cache-Container hostet:

wsl -d Ubuntu-24.04-Mcc

Führen Sie dann den folgenden Bash-Befehl aus, um die DNS-Auflösung des Registrierungsendpunkts zu überprüfen:

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

Überprüfen Sie die TCP-Konnektivität (Port 443 für HTTPS) mit dem Registrierungsendpunkt:

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

Überprüfen Sie die HTTPS-Antwort vom Registrierungsendpunkt:

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

MCC_Install_Task geplante Aufgabe kann nicht ausgeführt werden

Die Installation des verbundenen Caches auf Windows-Hostcomputern basiert auf der geplanten Aufgabe "MCC_Install_Task", um Installationsaktionen als festgelegtes Connected Cache-Laufzeitkonto auszuführen. Wenn diese Aufgabe nicht ausgeführt werden kann, kann dies auf einen der folgenden Gründe zurückzuführen sein.

Gruppenrichtlinie Object-Konflikte mit der Registrierung des geplanten Vorgangs

Das Aktivieren des Gruppenrichtlinie-Objekts: Netzwerkzugriff: Das Speichern von Kennwörtern und Anmeldeinformationen für die Netzwerkauthentifizierung nicht zulassen verhindert, dass die Connected Cache-Software die geplanten Aufgaben registriert, die für die erfolgreiche Registrierung und den Vorgang des Cacheknotens erforderlich sind.

DAS MCC-Laufzeitkonto verfügt nicht über Berechtigungen zum Anmelden als Batchauftrag.

Stellen Sie sicher, dass Sie dem Laufzeitkonto des verbundenen Caches die Berechtigung "Als Batchauftrag anmelden" erteilt haben. Diese Berechtigung ist erforderlich, damit das Laufzeitkonto des verbundenen Caches geplante Aufgaben ausführen kann.

Unternehmenssicherheitsrichtlinie verhindert die Ausführung von PowerShell-Skripts

Stellen Sie sicher, dass die PowerShell-Ausführungsrichtlinie auf dem Windows-Hostcomputer die Ausführung von Skripts zulässt. Sie können die aktuelle Ausführungsrichtlinie überprüfen, indem Sie den folgenden Befehl in einem PowerShell-Fenster mit erhöhten Rechten ausführen:

Get-ExecutionPolicy

WSL2 kann nicht mit der Meldung "Eine angegebene Anmeldesitzung ist nicht vorhanden" installiert werden.

Wenn diese Fehlermeldung beim Versuch auftritt, den PowerShell-Befehl wsl.exe --install --no-distribution auf Ihrem Windows-Hostcomputer auszuführen, überprüfen Sie, ob Sie als lokaler Administrator angemeldet sind, und führen Sie den Befehl in einem PowerShell-Fenster mit erhöhten Rechten aus.

Aktualisieren des WSL2-Kernels

Wenn die Installation des verbundenen Caches aufgrund von WSL-Problemen fehlschlägt, versuchen Sie, wsl.exe --update die neueste Version des WSL-Kernels zu erhalten.

MCC_Monitor_Task geplante Aufgabe kann nicht ausgeführt werden

Sobald der Connected Cache-Container ausgeführt wird, wird der MCC_Monitor_Task geplante Task in regelmäßigen Abständen unter dem Laufzeitkonto des verbundenen Caches ausgeführt, um zu verhindern, dass WSL die WSL-Verteilung des verbundenen Caches beendet. Wenn Ihr Cacheknoten ohne Benutzeraktion offline geschaltet wird, kann dies daran liegen, dass der geplante Task "MCC_Monitor_Task" nicht ordnungsgemäß ausgeführt wird.

Sie können den Taskplaner auf dem Hostcomputer verwenden, um die status dieser geplanten Aufgabe zu überprüfen.

1. Öffnen des Aufgabenplanungsmoduls auf dem Hostcomputer
2. Navigieren Sie zum Abschnitt Aktive Aufgaben, und doppelklicken Sie auf MCC_Monitor_Task
3. Überprüfen Sie die Spalten Letzte Laufzeit und Letzte Ausführungsergebnis , um festzustellen, ob der Vorgang erfolgreich abgeschlossen wurde.
4. Wählen Sie die Registerkarte Trigger aus, und vergewissern Sie sich, dass der Status Aktiviert ist.
5. Wählen Sie die Registerkarte Verlauf aus, und suchen Sie nach Fehlern oder Warnungen im Zusammenhang mit der Aufgabenausführung.

Wenn die MCC_Monitor_Task nicht erfolgreich ausgeführt werden kann, kann dies auf abgelaufene Anmeldeinformationen für das Connected Cache-Laufzeitkonto zurückzuführen sein. In diesem Fall können Sie das updatetaskpasswords.ps1 Skript verwenden, um die Anmeldeinformationen zu aktualisieren.

1. Öffnen Sie einen PowerShell-Prozess als Administrator.

2. Wechseln Sie in das Skriptverzeichnis, und überprüfen Sie, ob vorhanden ist updatetaskpasswords.ps1.

   • Wenn Sie Connected Cache mithilfe des Public Preview-Bereitstellungspakets installiert haben, befindet sich das Skriptverzeichnis im installationsordner, der im ursprünglichen Bereitstellungsbefehl angegeben ist ("C:\mccwsl01\MccScripts" standardmäßig).
   • Wenn Sie Connected Cache mithilfe der Windows-Anwendung Connected Cache installiert haben, befindet sich das Skriptverzeichnis in dem von deliveryoptimization-cli mcc-get-scripts-pathzurückgegebenen Verzeichnis.

3. Erstellen Sie ein PSCredential-Objekt namens $myLocalAccountCredential , das das Laufzeitkonto des verbundenen Caches mit dem neuen Kennwort darstellt.

4. Führen Sie das updatetaskpasswords.ps1 Skript mit dem folgenden Befehl aus:

   .\updatetaskpasswords.ps1 -Credential $myLocalAccountCredential
   

Cacheknoten erfolgreich bereitgestellt, aber keine Anforderungen verarbeiten

Wenn Ihr Cacheknoten nicht auf Anforderungen außerhalb von localhost reagiert, liegt dies möglicherweise daran, dass die Portweiterleitungsregeln des Hostcomputers während der Installation des verbundenen Caches nicht ordnungsgemäß festgelegt wurden. Da WSL2 standardmäßig einen virtualisierten Ethernet-Adapter verwendet, sind Regeln für die Portweiterleitung erforderlich, damit Datenverkehr die WSL2-instance von Ihrem LAN erreichen kann. Weitere Informationen finden Sie unter Zugreifen auf Netzwerkanwendungen mit WSL.

Verwenden Sie den folgenden PowerShell-Befehl, um die Portweiterleitungsregeln Ihres Hostcomputers zu überprüfen.

netsh interface portproxy show v4tov4

Wenn keine Portweiterleitungsregeln für Port 80 bis 0.0.0.0 angezeigt werden, können Sie den folgenden Befehl über eine PowerShell-instance mit erhöhten Rechten ausführen, um die ordnungsgemäße Weiterleitung auf WSL festzulegen.

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

Sie können die WSL-IP-Adresse aus der wslip.txt Datei abrufen, die im Installationsverzeichnis der Connected Cache-Anwendung vorhanden sein soll (C:\mccwsl01 standardmäßig).

Fehlende WSL-Portweiterleitungsregeln (443, 5000)

Um Ihre unter Windows gehosteten Cacheknoten erfolgreich für die Unterstützung von HTTPS zu konfigurieren, müssen Sie eine Portweiterleitungsregel erstellen, um Datenverkehr von Port 443 auf dem Hostcomputer an Port 443 der WSL2-Verteilung weiterzuleiten, die den Connected Cache-Container hostet.

Für den Remotezugriff auf die Terse-Zusammenfassungsseite Ihres unter Windows gehosteten Cacheknotens müssen Sie eine Portweiterleitungsregel erstellen, um Datenverkehr von Port 5000 auf dem Hostcomputer an Port 5000 in der WSL2-Verteilung weiterzuleiten, die den Connected Cache-Container hostet.

Sie können diese Portweiterleitungsregeln erstellen, indem Sie nach Abschluss der Bereitstellung des Cacheknotens die folgenden Befehle in einem PowerShell-Fenster mit erhöhten Rechten ausführen.

$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

Außerdem müssen Sie sicherstellen, dass die Firewall des Hostcomputers eingehenden Datenverkehr an den Ports 443 und 5000 zulässt. Führen Sie dazu die folgenden Befehle in einem PowerShell-Fenster mit erhöhten Rechten aus:

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

Fehler bei der Cacheknotenbereitstellung unter Windows mit "FEHLER: Zertifikat kann nicht überprüft werden"

Wenn während der Bereitstellung eines Cacheknotens ein Fehler mit dem Status "FEHLER: Zertifikat kann nicht überprüft werden" auftritt, kann dies daran liegen, dass der TLS-prüfende Proxy Ihres Netzwerks (z. B. ZScaler) die Kommunikation zwischen der Connected Cache-Software und dem Übermittlungsoptimierungsdienst abfängt. Dadurch wird die Zertifikatkette unterbrochen und die erfolgreiche Bereitstellung von Connected Cache verhindert.

Um dieses Problem zu beheben, müssen Sie Ihre Netzwerkumgebung so konfigurieren, dass Aufrufe von und von "*.prod.do.dsp.mp.microsoft.com" zugelassen werden, um den TLS-überprüfenden Proxy zu umgehen .

Sie müssen auch die Proxyeinstellungen für Ihren Cacheknoten konfigurieren, dann die Proxyzertifikatdatei (PEM) im gewünschten Installationsordnerpfad platzieren und dem Bereitstellungsbefehl hinzufügen -proxyTlsCertificatePemFileName "mycert.pem" . Platzieren Sie beispielsweise die PEM-Datei in C:\mccwsl01\mycert.pem , und fügen Sie dem Bereitstellungsbefehl hinzu -proxyTlsCertificatePemFileName "mycert.pem" .

Problembehandlung bei der Bereitstellung von Cacheknoten auf dem Linux-Hostcomputer

Die Bereitstellung eines Verbundenen Cache-Knotens auf einem Linux-Hostcomputer umfasst das Ausführen einer Reihe von Bash-Skripts, die im Linux-Bereitstellungspaket enthalten sind.

Nachdem die Connected Cache-Software erfolgreich auf dem Linux-Hostcomputer bereitgestellt wurde, können Sie überprüfen, ob der Cacheknoten ordnungsgemäß ausgeführt wird, indem Sie auf dem Linux-Hostcomputer wie folgt vorgehen:

1. Führen Sie aussudo iotedge list, um anzuzeigen, welche Container innerhalb der IoT Edge Runtime ausgeführt werden.

Wenn die Container edgeAgent und edgeHub, aber nicht MCC angezeigt werden, können Sie die status des IoT Edge-Sicherheits-Managers mithilfe sudo iotedge system logs -- -fvon anzeigen.

Sie können die IoT Edge Runtime auch mit sudo systemctl restart iotedgeneu starten.

Fehler bei der Cacheknotenbereitstellung unter Linux mit "FEHLER: Zertifikat kann nicht überprüft werden"

Wenn während der Bereitstellung eines Cacheknotens ein Fehler mit dem Status "FEHLER: Zertifikat kann nicht überprüft werden" auftritt, kann dies daran liegen, dass der TLS-prüfende Proxy Ihres Netzwerks (z. B. ZScaler) die Kommunikation zwischen der Connected Cache-Software und dem Übermittlungsoptimierungsdienst abfängt. Dadurch wird die Zertifikatkette unterbrochen und die erfolgreiche Bereitstellung von Connected Cache verhindert.

Um dieses Problem zu beheben, müssen Sie Ihre Netzwerkumgebung so konfigurieren, dass Aufrufe von und von "*.prod.do.dsp.mp.microsoft.com" zugelassen werden, um den TLS-überprüfenden Proxy zu umgehen .

Außerdem müssen Sie die Proxyeinstellungen für Ihren Cacheknoten konfigurieren, dann die Proxyzertifikatdatei (PEM) im extrahierten Bereitstellungspaketverzeichnis platzieren und dem Bereitstellungsbefehl hinzufügen proxytlscertificatepath="/path/to/pem/file" .

Generieren des Diagnoseunterstützungspakets für Cacheknoten

Sie können ein Supportpaket mit detaillierten Diagnoseinformationen generieren, indem Sie das collectMccDiagnostics.sh im Installationspaket enthaltene Skript ausführen.

Für Windows-Hostcomputer müssen Sie die folgenden Schritte ausführen:

1. Starten Sie einen PowerShell-Prozess als das Konto, das während der Installation des verbundenen Caches als Laufzeitkonto angegeben wurde.

2. Wechseln Sie zum Verzeichnis "MccScripts" im Installationsverzeichnis der Connected Cache-Anwendung (angegeben durch deliveryoptimization-cli mcc-get-scripts-path), und überprüfen Sie, ob das Verzeichnis vorhanden ist. collectmccdiagnostics.sh

3. Führen Sie aus wsl bash collectmccdiagnostics.sh , um das Diagnoseunterstützungspaket zu generieren.

4. Beachten Sie nach Abschluss des Skripts die Konsolenausgabe, die den Speicherort des Diagnoseunterstützungspakets beschreibt.

   Beispiel: "Paket erfolgreich gezippt, datei senden, die unter /etc/mccdiagnostics/support_bundle_2024_12_03__11_05_39__AM.tar.gz erstellt wurde"

5. Führen Sie den wsl cp Befehl aus, um das Supportpaket vom Speicherort in der Ubuntu-Distribution auf das Windows-Hostbetriebssystem zu kopieren.

   Beispiel: wsl cp /etc/mccdiagnostics/support_bundle_2024_12_03__11_05_39__AM.tar.gz /mnt/c/mccwsl01/SupportBundles/.

Für Linux-Hostcomputer müssen Sie die folgenden Schritte ausführen:

1. Wechseln Sie zum Verzeichnis "MccScripts" innerhalb des extrahierten Connected Cache-Bereitstellungspakets, und überprüfen Sie das Vorhandensein von collectmccdiagnostics.sh

2. Führen Sie aus collectmccdiagnostics.sh , um das Diagnoseunterstützungspaket zu generieren.

3. Beachten Sie nach Abschluss des Skripts die Konsolenausgabe, die den Speicherort des Diagnoseunterstützungspakets beschreibt.

   Beispiel: "Paket erfolgreich gezippt, datei senden, die unter /etc/mccdiagnostics/support_bundle_2024_12_03__11_05_39__AM.tar.gz erstellt wurde"

Problembehandlung bei der HTTPS-Konfiguration

Wenn Ihre Zertifizierungsstelle nur signierte Zertifikate im PEM- oder .cer-Format generieren kann, können Sie die Dateierweiterung der Zertifikatdatei in CRT ändern, wenn die Datei in Base64-Codierung vorliegt.

Problembehandlung bei der Überwachung von Cacheknoten

Die status und Leistung des Knotens "Connected Cache" können über die Benutzeroberfläche Azure-Portal überwacht werden.

Wenn die grundlegenden Überwachungsvisuals auf der Registerkarte Übersicht unerwartete oder fehlerhafte Werte anzeigen, aktualisieren Sie das Browserfenster.

Wenn das Problem weiterhin besteht, überprüfen Sie, ob Sie die Knotenfilter "Zeitraum" und "Cache" wie gewünscht konfiguriert haben.

Diagnose und Lösung

Sie können auch die Funktion Diagnose und Problembehandlung verwenden, die von der Azure-Portal-Schnittstelle bereitgestellt wird. Diese Registerkarte in der Microsoft Connected Cache Azure Ressource führt Sie durch einige Eingabeaufforderungen, um die Lösung für Ihr Problem einzugrenzen.