While helping an SE with a POC, I encountered an odd obscure error when trying to install a repository on one VM and a proxy on another VM.
The error message was received after we added the VMs as managed Windows servers and during the actual repository and proxy install.
The error I received was:
“Installing package Transport Error: Error 1920. Service Veeam Data Mover Service (VeeamTransportSvc) failed to start. Verify that you have sufficient privileges to start system services.”
I was a little panicked when I saw this as I have not encountered this error before, and the service installs work.
After my initial panic, my attention immediately turned to an account permissions issue.
The account being used is a domain account that was a member of the local administrators group on the servers. The account used was able to start and stop other services.
A check of Google yielded little insight. It did point me to the Veeam KB 1059 – which discusses this error.
The first step it mentioned was ensuring that the account being used had the “log on as a service “permissions set in the “Local security policy.”
The “Local Security Policy” applet can be accessed from the start menu under the “Windows Administrative tools” folder. The graphic below shows how to check that.
In this case, the account was granted the proper permission.
The KB article then recommends checking for a third-party application using a port we need:
• 6160 for the installer service
• 6162 for the Transport service
I thought that since this was a fresh install on a new VM, it couldn’t possibly be an application using a needed Veeam port. But in the spirit of troubleshooting, I followed the link to the referenced KB article for checking ports – Veeam KB 2065.
The KB article references checking for the installer service port of 6160, but the same process can be used to check the transport service port of 6162.
I used the PowerShell method listed in the KB article to check the port usage.
Get-Process -Id (Get-NetTCPConnection -LocalPort 6162).OwningProcess
You can also use the Windows netstat command. This command can be modified to check for 6160 or 6162.
netstat -an | find "6162"
(Note- the image below is a representation of what the PowerShell command will return - I didn’t want to use the customers error code for privacy reasons)
The results from the PowerShell command and netstatshow that a process named “process agent” was listening on port 6162.
Whatever was listening on port 6162 had stopped the Installer service from starting when we tried to install a proxy server and a repository on two separate new VM deployments.
Come to find out, the application that is using port 6162 is an application called DataDog.
Datadog is a cloud-based monitoring and error ticketing system.
The solution for being able to install the proxy and repository services as needed is to tell Datadog to use another port, or tell Veeam too. Since Datadog is a company-wide deployment, it was decided to have the Veeam transport service use a different port.
This is easy to do from the add a proxy/repo wizard in VBR.
We changed the port number for the installer service to port number 6175 and continued through the install wizard. The installation finished without an error or warning.
Problem solved!