In v13, the port logic for files restore is incorrect.

[danny.borghi]

Disclaimer: This is an improvement request, and the title was intended solely as a provocation to improve Veeam. I've been using Veeam for over 10 years, and I deeply respect the commitment and hard work they put into their products.

I'll get to the point: I recently upgraded from 12.3.2 to v13.0.1.1071 and noticed that, unlike v12, it behaves differently when attempting to restore files to a VM.

Here is the behavior encountered with v13.

The problem lies in a conflict between TCP port 6160, which is also used as the default port by the "Windows spooler," and the port used by VEEAM's VEEAM INSTALLER SERVICE, which uses the same port.

This is inherently incorrect behavior. I recently opened a case to see if Veeam can slightly vary its behavior during the RESTORE of FILES, when contacting TCP ports 6160 and 6162.

First of all, Windows predated VEEAM and has always used port 6160 for its spooler. Therefore, VEEAM's choice to use a port that the operating system uses by default for its service is wrong regardless. Furthermore, the VM spooler also spools all company printers, so it cannot be disabled for every restore files.

What could be done is to ask the Veeam programmers to do the right thing, that is, contact 6162 immediately, and not 6160.

Let me explain better now: Veeam v13 works like this:
I perform a file restore:
1- First, Veeam tries to contact 6160 (wrong).
2- Only then, if 6160 is contactable, does Veeam check if port 6162 is active and restore the file.

The correct behavior should be:
1- First, Veeam should contact 6162 (Veeam Transport), since it is the only port needed to restore the file and proceed with the restore.
2- If I can't reach 6162, then I try to contact 6160 to see if the VEEAM TRANSPORT and FIPS services still need to be installed on the destination VM

Many thank for all your help in advance
Best regards
Danny

[danny.borghi]

Sorry for further clarification:

Let me explain better now: Veeam v13 works like this:
I perform a file restore:
1- First, Veeam tries to contact 6160 (wrong). If it can't contact 6160, it freezes and, after a long time, times out without attempting to contact 6162. (In other words, if 6160 is reachable, it tries to contact 6162; otherwise, it won't even try.)
2- Only then, if 6160 is contactable, does Veeam check if port 6162 is active and restore the file.

The correct behavior should be:
1- First, Veeam should contact 6162 (Veeam Transport), since it is the only port needed to restore the file and proceed with the restore.
2- If I can't reach 6162, then I try to contact 6160 to see if the VEEAM TRANSPORT and FIPS services still need to be installed on the destination VM

[danny.borghi]

Can anyone help me solve this problem?
It's impossible to always have to stop the "Windows spooler on the destination VM" to restore a file.
Many Thanks in advance.

[Egor Yakovlev]

Hi Danny.
That behavior does seem unusual. To the best of my knowledge, the Microsoft Print Spooler has never used port 6160. If it had, we would likely have seen widespread conflicts on every Windows machine whenever a file-level restore was performed, ever since the introduction of the Veeam installer service.

Is it possible that there is a custom printing driver or third-party software installed on your machines that modifies the default spooler behavior? If so, that might explain the port usage you're observing.