Since early May 2023 (more than 2.5 months ago), one of my clients has been experiencing an issue with their Veeam v12 infrastructure. The challenge lies in connecting the Veeam Enterprise Manager with the Veeam Backup & Replication Server (VBR server).
Both services are located on different VMs, but within the same subnet and also in the same cluster. Here are the technical specifications:
- Windows Server 2019 Datacenter on both VMs, up-to-date with the latest patches (July 2023)
- Veeam Backup & Replication 12.0.0.1420 Patch 20230412
- Veeam Enterprise Manager 12.0.0.1420 Patch 20230412
- PostgreSQL 15.2-2
What does the error look like, and what are the implications?
The Enterprise Manager logs the error „Session closed“ in the session log. It appears that there is communication from the Enterprise Manager to the VBR server, but the VBR server actively rejects the connection:
What has been done so far?
- Temporary deactivation of the Windows Firewall on both systems.
- Explicit addition of the corresponding service accounts as „Veeam Backup Administrator“ within the VBR and Enterprise Manager consoles.
- Test use of the local administrators on both systems.
- Reinstallation of the Enterprise Managers.
- Installation of a Private Fix provided by Veeam Support.
It’s worth mentioning that this system underwent a complete reinstallation, meaning the VBR server was newly set up as part of the project and configured without restoring a config backup.
In the context of other customer situations, I have already delivered several installations in this setup, and they are functioning flawlessly. The unique aspect here is that these are systems newly installed on PostgreSQL. Previous installations were carried out using Microsoft SQL.
Update 31st July 2023:
The issue has been identified and resolved! After installing Patch 20230718 on both the VBR and the Enterprise Manager Server, the problem was resolved.
According to Veeam (via the support ticket), there was a bug during the transition from Microsoft SQL to PostgreSQL. As I initially suspected, the issue was limited to PostgreSQL, and I am confident that the problem would not have occurred under Microsoft SQL.
Here is an excerpt from the ticket (email correspondence):
