Seit mittlerweile Anfang Mai 2023 (also über 2,5 Monaten) gibt es bei einem meiner Kunden ein Problem mit der Veeam v12 Infrastruktur. Herausforderung ist, den Veeam Enterprise Manager mit dem Veeam Backup & Replication Server (VBR-Server) zu verbinden.
Beide Dienste befinden sich auf unterschiedlichen VMs, jedoch im selben Subnetz und auch im selben Cluster. Folgende technische Spezifikationen liegen vor:
- Windows Server 2019 Datacenter auf beiden VMs, aktuellste Patchstand (Juli 2023)
- Veeam Backup & Replication 12.0.0.1420 Patch 20230412
- Veeam Enterprise Manager 12.0.0.1420 Patch 20230412
- PostgreSQL 15.2-2
Wie sieht der Fehler aus bzw. was sind die Auswirkungen?
Der Enterprise Manager gibt im Session Log den Fehler „Session closed“ zurück. Offenbar findet eine Kommunikation vom Enterprise Manager zum VBR-Server statt, jedoch lehnt dieser die Verbindung aktiv ab:
Was wurde bisher gemacht?
- temporäre Deaktivierung der Windows-Firewall auf beiden Systemen
- explizites Hinzufügen der entsprechenden Service Accounts als „Veeam Backup Administrator“ innrehalb der VBR und der Enterprise Manager Konsole
- testweise Nutzung des lokalen Administrators auf beiden Systemen
- Neuinstallation des Enterprise Managers
- Installation eines Private Fix nach Bereitstellung durch den Veeam Support
Es handelt sich bei dem System um eine komplette Neuinstallation, demnach wurde auch der VBR-Server im Zuge des Projektes neu aufgesetzt und ohne Zurücksichern eines Config-Backups neu konfiguriert.
Im Rahmen anderer Kundensituationen habe ich bereits mehrere Installationen in dem Konstrukt übergeben, welche einwandfrei funktionieren. Die Besonderheit ist hier, dass es sich um auf PostgreSQL neuinstallierte Systeme handeln. Bisherige Installationen habe ich mit Microsoft SQL umgesetzt.
Update 31.07.2023:
Der Fehler konnte gefunden und behoben werden! Nach Installation des Patches 20230718 auf dem VBR- und dem Enterprise Manager Server konnte der Fehler gelöst werden!
Nach Statement von Veeam (via Ticket) gab es einen Bug bei der Umstellung von Microsoft SQL auf PostgreSQL. Wie initial von mir vermutet hat sich der Fehler auf Postgres limitiert und ich bin mir sicher, dass der Fehler unter Microsoft SQL nicht aufgetreten wäre.
Hier das ein Auszug aus dem Ticket (Mailverkehr):
