Backup server entry with FQDN

[chrisflyckelen]

Hey everyone,
Is there a supported way for VBR to add the backup server using its FQDN (to managed servers pane) instead of relying on NetBIOS?

I've frequently encountered name resolution issues, as NetBIOS is not exactly state-of-the-art. In most cases, customers don’t run any NetBIOS name servers, which complicates things further.

Has anyone else experienced similar issues, or do you have any advice on how to handle this more effectively?

Thanks in advance!
Christian

[tyler.jurgens]

Provided your VBR server can do any kind of DNS lookup, there should be nothing stopping you from adding the server via the FQDN. That's my preferred way of adding servers.

If you can't have your VBR server perform DNS lookups against your primary DNS server, you can always add those entries to your hosts file.

What problem are you running into?

[chrisflyckelen]

Hi Tyler,

maybe I was unprecise. That's not what I mean.

Imagine you have a Windows server deployed freshly and you are about to deploy VBR on it. The server is configured using a static IP and two DNS servers.
Opening up the console for the first time, navigating to the managed servers pane the backup server entry is always using the NetBIOS/hostname not an FQDN.

And I guess it would be helpful if it's possible to change or to do something that this entry is created using the servers FQDN.

Greets,
Chris

[Mildur]

Hi Chris

The windows machine doesn’t have a „FQDN“, if the backup server is not joined to a domain. What name should we <assume> if we cannot read it from the operating system?

May I ask what kind of issue you are trying to solve with this request? Did you open a support case where it was confirmed that the „backup server entry“ was the root cause? I never heard of it as a problem.

Best,
Fabian

[chrisflyckelen]

Hi Fabian,

I haven't opened a support case yet—I just wanted to start a discussion and explore potential solutions.

The issue I'm facing is that all backup infrastructure components rely on that specific name to connect to the backup server. However, tasks fail because the server’s IP cannot be resolved using this name. The only workaround I've found is adding an entry in the local HOSTS file on the backup proxy (for instance), as NetBIOS is often unavailable on modern networks. While this might work for smaller environments, managing local HOSTS files across a large-scale deployment isn't feasible.

Am I the only one who is thinking about this?

Looking forward to your thoughts.

Best,
Chris

[d.artzen]

Hi Chris,

could you not simply add a static Host entry into the DNS-Servers that are used by your components? That way the name can be correctly resolved and the server is reachable by name.
We do it that way (in our case it is the Domain DNS, even though the Backup Server itself is not domain joined, but the DNS answers to all systems that can reach it) and haven't seen any issues with backups or restores.

Best regards
Daniel

[tommy.oshea]

Hello Chris,

Does adding a Primary DNS Suffix (Under Computer/Domain Name changes > More) to the computer name before installing Veeam resolve this issue?

[DVS]

Simple solution to modify the local host file with the appropriate IP address. It’s fully qualified domain name as well as as a second entry say IP with the net bios name. This should resolve the issue and it takes less than two minutes.

[Andreas Neufert]

Hi everybody,

my 2 cents on this.

- You can save a shortcut with any IP, Name , FQDN configuration by clicking on the "Save shortcut" link in the console. This way you do not have to type the FQDN name in, in your specific case.

- Local NetBios name usage should always be possible as so many other things in Veeam or standard Windows services depend on it. If this is not working, then I would investigate here.

- Yes the local hosts file to add FQDN and Netbios name is seen as a workaround, but I would argue that it is a good idea in any way. In an emergecy situation, your DNS server might be down and you want to recover from the backup server and this way you can work as usual. I would even add all the other servers Veeam interacts with to the hosts file with NetBios and FQDNm just for the case.

[mjr.epicfail]

Going to chime in here, and maybe I didn’t understand it correctly but here goes:

When vbr installs and is installing components on other servers (lets say remote proxy or repository) the communication is configured to use the hostname of the VBR server (even when the vbr server is on windows and windows is ad joined.

Ofcourse you can add a dns A record for this but if the remote servers are not adding the dns suffix a DNS server cannot resolve the address as the dns request is not a FQDN but just a host name (barring that the remote servers arent using dns searchzones)

Wouldn’t it be “better” that there would be an option to configure a FQDN for veeam products (the enterprise manager exhibits the same “flaw” btw.

[Andreas Neufert]

Hi Danny, if you add other servers to Veeam as managed servers that can host any kind of components like Proxy/Repository/..., then we use by default what you have typed in into the add server wizard. It can be FQDN, NetbiosName or IP address. It might be the case that from there Veeam is trying to optimize login timing and security, but we ultimately fallback to this configuration.

Do you saw any issues with this?

[mjr.epicfail]

Hi Andreas,

Thats correct, however the connection that is being initiated from the remote server to the VBR server will be to the HOSTNAME/NETBIOS off the VBR server
example:
Zone: acme.com
VBR server: VBR01
REPO: VBRRepo01

Add repo on VBR: VBRRepo01.acme.com
Repo will be added as VBRRepo01.acme.com

Connection initiated from REPO to VBR: connecting to VBR01 instead of VBR01.acme.com.

its the same with VSPC and management agents.
When installing VSPC and adding VCC servers, the management agent on the VCC server will connect to the hostname of the VSPC server, not a FQDN.

Enterprise manager is only reachable on hostname, we need to add a regkey and some extra webconfiguration to be able to connect to it via a FQDN.

[Andreas Neufert]

It is a bit longer time that I looked into this more closely, but in your case where an external Veeam components starts a connection to the VBR server (regular routend environment, not VSPC case) then the VBR server tries to connect to NetBios and falls back to the list of IP addresses the server has (we read at rescan the list of IPs from the server). So without FQDN and without netbios usage it should work, too if Veeam tries to connect from one of it´s components to the VBR server. In the end we connect from VBR to Install Service to start a manager there and the manager start the transport service that initiates the connection as adviced by the VBR (netbios with fallback to all IPs from VBR).

I do not know details about VCC and VSPC.

[mjr.epicfail]

I understand the mechanisme, but it looks like that is failing for OP

The issue I'm facing is that all backup infrastructure components rely on that specific name to connect to the backup server. However, tasks fail because the server’s IP cannot be resolved using this name. The only workaround I've found is adding an entry in the local HOSTS file on the backup proxy (for instance), as NetBIOS is often unavailable on modern networks. While this might work for smaller environments, managing local HOSTS files across a large-scale deployment isn't feasible.

@chrisflyckelen,
I do think its prudent to create a supportcase as what Andreas just confirmed is that while netbios name could work, it would fail back to IP only and that should work either way.

@Andreas,
Could this be a FR to configure VBR with a FQDN so al connections that are being made will be using this FQDN instead of a hostname/netbios

[Andreas Neufert]

Chris lets create a support case and upload the logs. Then we can see why it is not working. Please add in the support case what you exactly tried and where it failed in order to extract it from the logs.

Please share support case number here so that we can follow the progress of the investigation. Thanks.

[chrisflyckelen]

Hey everyone,

It seems that I'm not the only one, who has some struggle. I'm going to open a support case, today or tomorrow, i think.

@tommy Yes, tried this. But it doesn't change anything.

And, especially in larger environments, I don't want to work with a local host file, which has to be customized when anything changes.

Thank you all!

Greetings,
Chris

[Andreas Neufert]

Maybe setting a primary domain, search domain in servers help. If you are not in an AD domain the following will work in DNS.

VBRServer1 not in AD domain. You create within DNS an entry in yourdomain.local

You will configure on another system the domain.local as search domain. "DNS suffix for this connection" or "append these DNS suffixes"

So when you ping VBRServer1 and it can not be resolved, it will fallback to the search domain and therefore ask dns VBRServer1.yourdomain.local for the IP and it would work.

[mjr.epicfail]

Maybe setting a primary domain, search domain in servers help. If you are not in an AD domain the following will work in DNS.

VBRServer1 not in AD domain. You create within DNS an entry in yourdomain.local

You will configure on another system the domain.local as search domain. "DNS suffix for this connection" or "append these DNS suffixes"

So when you ping VBRServer1 and it can not be resolved, it will fallback to the search domain and therefore ask dns VBRServer1.yourdomain.local for the IP and it would work.

This will work, however you need to add the "domain suffix" to every server that is not part of that domain.
Still feels like a workaround.

Veeam can avoid this If you can set the FQDN at the VBR side.
Would still like to push this as a FR.

[Andreas Neufert]

Let´s wait to for the support case. It might be that it is just a bug and fallback to IP address usage is not working.

As well let´s do the same for the Veeam Cloud Connect one, I would love to have a look there as well if we can optimize things without manual work.

[chrisflyckelen]

Hey guys,

the support case is now open. Let see the findings and answers of the support engineers.

Greetz,
Chris

[mjr.epicfail]

Can you also post the Case ID?

[chrisflyckelen]

Case ID is in the subject of my last post.

#07711219

Greetings,
Chris

[Andreas Neufert]

I have requested to escalate internally and share results with product management. For Veeam internal reference: ESC0110271