Veeam Failed To Update License Key On Backup Server
Carmina Piette
Which version of the Hyper-V server do you want to add?
Are you in the latest Veeam version ?
You have probably already try to use the built-in administrator ? No problem to open the admin share from the veeam to the hyper-v as mentionned @MicoolPaul ?
Any GPO apply in the hyper-v host ?
Have you try to reboot both Veeam & hyper-v ?
Try to use the built-in local administrator account, it has a unique SID which overrides the UAC. If you renamed the build-in local administrator, that should not be a problem because the SID is still the same. Try to use FQDN\Administrator to connect. Also disabled the Windows firewall.
Well it was worth a try ? My last idea would be to add the host via DNS to Veeam. If this also doesn't work then I would suggest to open a case with Veean support. With the community edition you'll have access to best effort support.
I had the same problem with v12 in my home lab. To resolve it using FQDN\IP, I explicitly defined the user I was attempting to use to add the Backup Server to Enterprise Manager as a Backup Administrator within Veeam Backup and Replication under Users and Roles. I then removed the Built-in Administrators Group.
I had the same problem when I upgraded from v11 to v12 using SQL DB. Before troubleshooting, my Veeam server died and I rebuilt Veeam from scratch on a new server last night with PG database and had the same issue. Totally clean install with no restore from old Veeam server backup config.
While there is a KB for this, I had to whitelist a specific folder in order for the backup to work. The moment the backups started failing was the same day I implemented Lockdown on one server. Once I whitelisted the folder below and re-ran the backup it was successful.
Backup that ran last night was successful. I'm going to remove the exclusion and see if the backup that runs tonight fails. If it does, I'll know for sure that the exclusion is what fixes the issue with Veeam backup not working when Lockdown is enabled.
Breakingcustom said:Backup that ran last night was successful. I'm going to remove the exclusion and see if the backup that runs tonight fails. If it does, I'll know for sure that the exclusion is what fixes the issue with Veeam backup not working when Lockdown is enabled.
Thank you for your patience. Our KB team has edited the article to hyperlink the word Veeam in step 5, to re-emphasize the exclusions outlined by Veeam's article (incase they ever change or are updated by Veeam).
It is Directly connected to a cluster of ISCSI Switches. a 10GB connection into either one and setup with Nic Teaming for the two 10GB Nic's
We have also tried this with just the singular 10gb with no Teaming and experience the same issues.
Randomly we have a major ISCSI failure which results in a total network loss which results in failed backups.
I have attempted to get support from Veeam But as far as they are concerned its an infrastructure issue and not their problem to deal with.
This issue occurs at what appears to be random to me (i cannot find a solid item to pinpoint the start of this issue from)
I am at the end of my tether, have attempted every fix i could find, including registry edits and as men=tioned above adding a secondary 10Gb Nic.
There are no Dropped packets or downs on the Switches.
The logs on the switches show no isses from their side, no drops or failures, It does register when the port goes offline but more from the server's network going offline then the port itself going down.
We have the server connected directly to the ISCSI switch which in turn is directly connected to our ReadyNas
We have a second backup server also setup using ISCSI initiator connected in the same manner to the ISCSI Switch then ReadyNAS and it never experiences any drops.
Besides for the regular Veeam and Windows updates Nothing Besides for us adding a 2nd 10GB Nic has changed
To add we use PRTG for Monitoring and within the PRTG logs we see a complete outage from the server in question all our snmp sensors show down
The Servers ISCSI appears to fallover which drops its entire network.
Basically disconnectig it from the network causing the mapped drives used for backups to drop. casuing off-load to our Nas backups to fail.
No corresponding logs found on our clustered netgear m4300
No corresponding logs found on our ReadysNas Nas device.
Same issue here :-(
I'm investigating this problem for weeks, updating Windows 2019 OS, network drivers, SAN storage firmware, etc., follwing suggestions like disabling VMQ, RSS, RSC - with no success. It always starts suddenly with iScsiPrt error 20 with subsequent different iScsiPrt error and of course disk errors for unreachable UPD files (it's a Remote Desktop Session Host VM on Hyper-V) and Ntfs errors for open files which lost connection...
The server becomes completely unresponsive und has to be hard reset. Maybe it would recover if waiting for hours - we didn't wair that long.
Were you able to resolve the problem in the meantime?
Kind regards
Well, I experience the same behavior with newer models (and also the newest version) of Tandberg QuikStation and Windows Server from version 2012 R2 to 2022 using Backup Exec or Acronis Cyber Protect on premise, usually connected via Gigabit network. (The most ancient and slowest version of Tandberg QuikStation does not show this behavior in an iSCSI connection even if used with the same network connection and server as the newer models.) Tandberg support could never find a solution for this. Using a direct network connection between the HP Proliant and the QuikStation made no difference either.
My opinion is that there is something up in the iSCSI communication (maybe a bug in the iSCSI connector components of Windows Server) communicating with the iSCSI stack in specific hardware). So a solution needs to be found either by Microsoft or by the hardware vendor.
I also have a similar problem, the preferred destinations show ipv6 fe80 in the details, but when outputting via Powershell I get the correct assignments. It could be that this is a display error. However, I have not checked whether data loss is prevalent
Good Morning,
Veeam backup & Replication CE 11 (last release) installed on Windows Server 2019 Hyper-V VM from about 1 month
Veeam Backup jobs use as destination a shared folder on Qnap Nas.
Windows 2019 VM Italian language standalone, Qnap Nas under domain.
R&W user used for Qnap autentication it's local user for Qnap and Administrator for Win2019 VM.
All go fine before KB5011503 update
After this installation Veeam Backup job works only with guest user.
No other user can autenticate to Qnap with SMB 1, 2, 3
Error message on Qnap is
"Processing MACHINENAME Error: Nome utente o password non corretta --tr:Error code: 0x0000052e Failed to process [isFileExists]. --tr:Client failed to process the command. Command: [isFileExists]. --tr:event:3:"
Trying to uninstal KB5011503 update, after reboot all veeam Backup Job returns to work.
Updating KB5011503 again all Job stop to work.
Could be this a bug?
Where I can report this to microsoft?
Thanks
Paolo
Domain Name System (DNS) resolution to IPv4 addresses is critical for Veeam Backup & Replication deployment, configuration and daily operations. All infrastructure components should be resolvable through a fully qualified domain name (FQDN). This is especially important for vSphere/Hyper-V hosts and clusters. Resolvable means that components are accessible through both forward (A) and reverse (PTR) lookups. While reverse resolution is not mandatory, forward resolution totally is.
For this reason, you need to ensure that the Veeam Backup & Replication server is installed on a machine that has a resolvable FQDN, and also all the other components are resolvable in the same way. To check that the FQDN is resolvable, type
Proper DNS resolution should always be the preferred method to find machines in the network. With it, a network administrator should only have to take care of the DNS server(s) and their zone files, and every time a zone is updated with a new record, the entire network will immediately see the changes in a consistent way. There are however situations where DNS resolution is not available; in these cases, you may add the infrastructure components (like e.g. VMware vCenter, ESXi and managed Veeam servers) to the local hosts file on all managed Veeam servers. When using this workaround, it is recommended to add both short name and fully qualified domain name in the hosts file.
4a15465005