- Knowledge Base des Veeam Supports
- Win32-Fehler: Der Netzwerkpfad wurde nicht gefunden. Code 53
Win32-Fehler: Der Netzwerkpfad wurde nicht gefunden. Code 53
Cheers for trusting us with the spot in your mailbox!
Now you’re less likely to miss what’s been brewing in our knowledge base with this weekly digest
Huch! Da ist etwas schiefgegangen.
Bitte versuchen Sie es später noch einmal.
Problem
Ein Server innerhalb eines Job schlägt mit folgendem Fehler fehl:
Error: Failed to connect to guest agent. Errors: 'Cannot connect to the host's administrative share. Host: []. Account: [...]. Win32 error:The network path was not found. Code: 53 Cannot connect to the host's administrative share. Host: []. Account: [...]. Win32 error:The network path was not found. Code: 53
Hinweis: Dies gilt sowohl für VMware- als auch für Hyper-V-Umgebungen.
Ursache
Der Guest Interaction Proxy versucht zuerst, eine Verbindung über den Hostnamen herzustellen und kann fehlschlagen, wenn die IP-Adresse nicht aufgelöst werden kann.
Wenn der Guest Interaction Proxy keine Verbindung mit der Admin-Freigabe über den Hostnamen herstellen kann, wird versucht, die an den Hypervisor gemeldete IP zu verwenden.
Der Win32-Fehler "Der Netzwerkpfad wurde nicht gefunden" wird am Guest Interaction Proxy vom Betriebssystem empfangen, wenn versucht wird, eine Verbindung mit\\ < guest-hostname\ ip>\admin$ herzustellen.
Lösung
Der Schlüssel zur Behebung dieses Problems liegt darin, herauszufinden, welches Problem den Guest Interaction Proxy daran hindert, sich mit dem admin-freigabe des zu bearbeitenden Servers zu verbinden.
Tipp: Um die Verbindung zur admin-Freigabe zu testen, ohne den Job ausführen zu müssen, verwenden Sie die Schaltfläche "Test Now" in der Registerkarte "Guest Processing" des Jobs, um den Guest Credentials Test zu starten.
Fehlerbehebung:
- Testen Sie die Verbindung zur admin-Freigabe (z. B. \\\admin$) vom Guest Interaction Proxy aus mit den gleichen Anmeldeinformationen, die im Abschnitt Guest Processing des Auftrags angegeben sind.
Testen Sie den Zugriff von mehreren Computern, einschließlich des Veeam Backup & Replication -Servers und anderer Guest Interaction Proxies, um zu isolieren, ob es ein Verbindungsproblem gibt das spezifisch auf einen Guest Interaction Proxy zurückzuführen ist. - Stellen Sie sicher, dass der Guest Interaction Proxiy auf die VM zugreifen kann
- Ping des Hostnamens und der IP-Adresse
- Verbindung zu Port 445 testen
Test-NetConnection -computername <hostname\ip> -port 445- Deaktivieren Sie vorübergehend die Firewall auf dem Gastbetriebssystem . Wenn der Guest Credentials Test und der Job mit deaktivierter Firewall funktionieren, überprüfen Sie die Liste der verwendeten Ports (vSphere | Hyper-V) und nehmen Sie entsprechende Anpassungen vor.
- Stellen Sie sicher, dass die Windows-Zeit auf dem Veeam Backup Server und dem Guest Interaction Proxy mit der des Gastbetriebssystems übereinstimmt.
- Stellen Sie sicher, dass die Datei- und Druckerfreigabe im Gastbetriebssystem aktiviert ist.
- Sobald die Datei- und Druckerfreigabe auf dem Gastbetriebssystem aktiviert ist, stellen Sie sicher, dass die Firewall-Regeln so eingestellt sind, dass der Datenverkehr für die Datei- und Druckerfreigabe ermöglicht wird.
- Wenn das Gast betriebssystem Vista/2008 oder höher ist:
- Wenn im Netzwerk- und Freigabecenter das Netzwerk auf „Öffentlich“ eingestellt ist, wird die Firewall gesperrt und der Datenverkehr blockiert.
- Stellen Sie sicher, dass der Remote-Registrierungsdienst gestartet ist.
Weitere Informationen
Hinweis: Bei der Arbeit mit vSphere-Umgebungen ist es möglich, dass Veeam Backup & Replication eine netzwerklose Verbindungsmethode (VIX) verwendet, wenn die direkte Kommunikation fehlschlägt. Diese Methode verwendet VMware-Tools, um die Laufzeitkomponenten auf die Maschine zu schieben und zu verwalten. Wenn sich die zu schützende VM in einer DMZ oder einer anderen netzwerkisolierten Konfiguration befindet, ist es eventuell nicht möglich, RPC zum Laufen zu bringen und es notwending ist die Konnektivität über VIX zu verlangen. Referenz: https://www.veeam.com/kb1788.
Erzwingen von VIX in isolierten Umgebungen
Wenn Veeam Backup & Replication in einer vSphere-Umgebung betrieben wird, in welcher der Veeam-Server und seine Komponenten niemals eine direkte Netzwerkverbindung zum Gastbetriebssystem der virtuellen Maschinen haben, ist es möglich, VIX für den ersten Verbindungsversuch zu erzwingen.
Erstellen Sie dafür den folgenden Schlüssel in der Registierung auf dem Veeam Backup & Replication -Server:
Pfad zum Schlüssel: HKLM\SOFTWARE\Veeam\Veeam Backup and Replication\
Value Name: InverseVssProtocolOrder
Value Type: DWORD (32-Bit) Value
Value Data: 1
Zum Deaktivieren (Standardeinstellung) setzen Sie den Wert auf 0 (false).
If this KB article did not resolve your issue or you need further assistance with Veeam software, please create a Veeam Support Case.
To submit feedback regarding this article, please click this link: Send Article Feedback
To report a typo on this page, highlight the typo with your mouse and press CTRL + Enter.
