Hi @clownyboots178 → it would help to know what you’re trying to do in which this error occurs. Can you share 1. what you’re doing when this error occurs? ; 2. what you are using..VBR or an agent? Any & all details would be great to help us help you out.

Thanks.

sorry, I guess that would have helped

SQL Job

the machine has an agent on it and it is backing up a SQL cluster

VBR is running the job and these machines in the job belong to “Inventory > Physical Infrastructure > Job A”

Most all other machines in job run fin, there are a couple with this same error

No is not one of the “Out of Date" machines - those are processing successfully 

Ok, those help a lot...thanks. Welp, there are some things you can try which are basic → make sure the Veeam server can ping the device you’re trying to backup..make sure DNS is good; another thing I would try is to make sure your Repository (SOBR) where the backups are going is fine. Maybe the 2nd error you’re getting is related to the 1st, or even vice versa. In other words, verify your SOBR Repo is ok. Another thing I would do is go into your SQL Machines Protection Group (rt-click > properties), then in the Computers section, double-check the account you’re using to connect is ok (pwd expired or bad). There may be an issue there. Also, check on the Windows machine(s) to make sure User Account Control (UAC) is not running. Those are some first steps I’d try.

Also check any firewall settings to ensure nothing is being blocked.  Also check the logs for more details - C:\ProgramData\Veeam\Backup

I am going to the logs now, not sure what is going on, my DBAs may have some insight also

I will check with them tomorrow

thanks guys

Could there be something on the servers using the same port as Veeam?

Might be difficult to pinpoint the root cause. Here is a similar issue and how it was resolved: https://forums.veeam.com/servers-workstations-f49/job-fails-with-managed-session-failed-case-04354878-t68970.html

@clownyboots178 … @haslund brings up a good point as well; verify the port is open. You can check ports by referencing Veeam Agent for Windows port reference from the Guide. It appears port 135 is the main one used for Cluster services, but 137, 139, 6160/6162, 6184-6190 & 11731 are also used. I assume the job was working at some point though?

Often, connectivity issues arise when something is hindering access to a specific port or hostname. This obstruction can be due to a firewall blocking the connection or the service-hosting process not listening on the designated port. This could result from the service not running, or it might be listening on an alternative port. Consequently, establishing a connection becomes impossible.

To diagnose the problem, you can try running the netstat -anb command from the command line to check if anything is listening on the intended port. If it returns no results, consider changing the port number. In Windows operating systems, you can use the netstat command via the command line (cmd.exe), while on Linux, you may need to use netstat -anp.

Occasionally, when the target machine 'actively refuses' the connection, it could be because the server's 'backlog' is full. In such cases, you might consider increasing the server's backlog, but it's also essential to implement retry logic in your client code to handle this situation. This is necessary because even with an extended backlog, the server could be handling numerous other requests on the same port at that time.

Hey @clownyboots178 - did any of our suggestions help you out here? Just following up to see if anything here helped you out. 

Sorry, I am honestly not sure all of what I did as a lot has changed in my environment 

I did end up rebuilding the SQL groups, as well as reinstalling the agents, and 12.1 upgrade and some other network changes, so I am not 100% but I did verify the ports were open on the needed servers as well

but I took all of the advice on here into the things I did, so I am sure something helped

Ok, great. At least you’re up and going again. I just wanted to follow-up and make sure.

Best!

Glad to hear that "something” you did fixed the issue.  LOL

This is a fairly generic error in that a lot of things can cause it.  

I just resolved one instance I had  - Cause was the PostGresSQL service was not running