Win32-Fehler: Der Netzwerkpfad wurde nicht gefunden. Code 53

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.

Dieser Fehler tritt auf, wenn der Guest Interaction Proxy (vSphere | Hyper-V) keine Verbindung mit dem Gastbetriebssystem herstellen kann, während versucht wird, Application-Aware Processing zu verwenden(vSphere | Hyper-V).

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.

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

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

 

Für Veeam Backup & Replication 9.x und höher sollten Sie den Wert auch auf dem Guest Interaction Proxy
erstellen (beachten Sie, dass der Pfad anders ist)

Pfad zum Schlüssel: HKLM\SOFTWARE\Wow6432Node\Veeam\Veeam Backup and Replication\
Value Name:  InverseVssProtocol
Value Typ: DWORD (32-Bit)
Value Data: 1

Zum Deaktivieren (Standardeinstellung) setzen Sie den Wert auf 0 (false).

Ein Neustart des Veeam-Dienstes ist nicht erforderlich.