Skip to main content

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!

This is awesome Joe.  Love seeing troubleshooting tips like this as they are so useful.  👍


This is awesome Joe.  Love seeing troubleshooting tips like this as they are so useful.  👍

Thanks, Chris!  I search all over for some guidance on this issue and I did not find very much.  So I decided what the heck! I’ll blog.  This is the first time I have ever heard of Datdog and never released they would use 6162 like Veeam does.


This is a very detailed troubleshooting guide. Thanks a lot for sharing! 


This is awesome Joe.  Love seeing troubleshooting tips like this as they are so useful.  👍

Thanks, Chris!  I search all over for some guidance on this issue and I did not find very much.  So I decided what the heck! I’ll blog.  This is the first time I have ever heard of Datdog and never released they would use 6162 like Veeam does.

+1


thank you @vmJoe  for sharing, however those who are Wintel system administrators and are devoted to siciurity have a deep understanding of the subject.
In fact, each Domain or Local user must be assigned a granular grant (RBAC) with the minimum permissions dedicated to the application or service function.In fact, each Domain or Local user must be assigned a granular grant (RBAC) with the minimum permissions dedicated to the application or service function.


Great troubleshooting here.  Sounds like another argument for using a Linux Proxy/Repo server though.  I’m becoming more and more convinced that the Linux boxes are the way to go.  That said, who’s to say that DataDog doesn’t have a linux agent and doesn’t use the same port…


I like you writing this up @vmJoe . The more troubleshooting write-ups, the easier (hopefully) to find answers we need when encountering issues.

Cheers!


You are my hero! DataDog was the culprit. Thank you! 


So having the same issue here too due to datadog.  However, Edit is grayed out for the transport port.  Other ports, are not greyed out, but this one is.


So having the same issue here too due to datadog.  However, Edit is grayed out for the transport port.  Other ports, are not greyed out, but this one is.

Did you follow the OP and change the DataDog port as noted?  That is probably why it is grayed out.


The whole point of the orginal post was they did not change the datadog port , they opt to change the veeam port via the interface.  The same interface where edit for the transport port is greyed out.   “Since Datadog is a company-wide deployment, it was decided to have the Veeam transport service use a different port.  “


The whole point of the orginal post was they did not change the datadog port , they opt to change the veeam port via the interface.  The same interface where edit for the transport port is greyed out.   “Since Datadog is a company-wide deployment, it was decided to have the Veeam transport service use a different port.  “

Absolutely that is what you want.  Did you try shutting down Datadog to change the Veeam port then turn it back on?  That might allow the edit dialog to become available.


Comment