Hi, to start with, the error message you receive would be useful.

if you go to the inventory view within VBR, does it show any servers as out of date or needing rescanning. If you haven’t got auto update enabled on the protection group you’ll need to manually update the agents.

VBR normally supports the latest agent and one major version behind, so if you had a v4 agent for example this would work on v11 but not v12

What Agent version are you on? Have you tried to upgrade the Agent then reattempt the backup? 

Hi guys and many thanks for your time on this.

The error message of a failed Rescan of VBR is: “Failed to send certificate, but certificate is required for remote agent management Error: Failed to establish connection: no valid IP addresses were found”.

In terms of the agent on VBR it is: v6.0.2.1090

Is your server being targeted by DNS? If so is your network IPv4 or dual-stack with IPv6? Wondering if you’ve got an IPv6 address being resolved by DNS that Veeam can’t reach

So, to be clear...you’re backing up your physical Veeam server with a Veeam Agent job? And, you’re backing it up through the Veeam Console, or are you backing it up as a standalone agent instance?

@MicoolPaul makes a good point, to verify your server has a record in DNS; if not, then make sure you either use IP, or add an entry to the VBR server hosts file.

You can try to solve this removing agent and installing again.

I think DNS is part of the issue (if not the entire cause). On VBR if I locally ping its hostname (non-FQDN) replies are returned in IPv6 format. If I ping using FQDN, then replies are returned in IPv4 format.

Many thanks.

you ever found the solution

Hi @VeeamQuestions -

Did you ever get your backup job failure issue resolved? Did one of the provided comments help? If so, could you please mark one as ‘Best Answer’ so those with a similar issue who come across your post may benefit?

Thank you.

Try this checks :

 

Re: Failed to send certificate, but certificate is required for remote agent management

• QUOTE

Post by Egor Yakovlev » Apr 23, 2020 1:06 pm 1 person likes this post

Hi Eimantas,

Here are 2 more checks for you:

- On your Windows Server, check "netstat -b" if you have anything but Veeam is listening on local port :6184. If some app took our default communications port, we will work over next one, 6185, which will need a firewall allow rule as well.
- Last but not least, check local policies under "Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options" on both servers(Windows agent + VBR). Following keys should be in NotConfigured\AllowAll state: Network security: LAN Manager authentication level], lRestrict NTLM: Incoming traffic], aRestrict NTLM: Outgoing traffic].

/Thanks!

We had the same error, while backing up veeam hardware server via agent backup. Only switching to IP adress instead of FQDN solved the problem. Resolving hostname ends in IPv6 address. FQDN ends in IPv4. IPv6 ist not used at our infrastructure. A bit weird, that this setup worked in v11.