Join Veeam Appliance 13 to domain or Not to backup Hyper-v 2025 Cluster

[fbroussey]

Hi, I just want to know if it is mandatory to join the veeam Appliance 13 to the active directory domain which hyper-vhosts belong in order to backup Vms from this Hyper-v cluster.
We don’t usually do that for security reasons but i'm facing a pb with the add of a 2025 Hyper-v Cluster to Veeam 13 giving me an error :
Failed to connect to cluster cluster.clusterhv.local
Failed to create Hyper-V Cluster Wmi utils: Failed to test connection to the host cluster.clusterhv.local with OMICLI.
Possible reason:
Specified host is not a cluster node.
I open a case Veeam Software Appliance #07899013 but i'm surprised that we need to add the veeam to the domain

Do you have any feedback about that?

Thanks

[Moderator: added Support Case #]

[Egor Yakovlev]

Hi Frederic,
to protect Hyper-V clusters (both native and SCVMM-managed) backup server appliance must be joined to a domain.

[halvorsond]

This info surprised me - is this a requirement for backing up hyper-v clusters? Doing a quick search, i couldn't seem to find anything in particular on that requirement in the user guide/release notes

[alen88]

Hi, can someone elaborate this request in more detail?

"[For Linux-based backup servers] Both the Hyper-V nodes and the backup server must be joined to the same Active Directory domain. If they are not joined to the same Active Directory domain, additional manual configuration of the krb5.conf file is required. For more information, see Performing Maintenance Tasks." stated in documentation.

Because, I successfully added two Windows Server 2025 clusters to a different V13 setup at another customer last week without this prerequisite, and everything is working as expected.
But, today, at different customer, I want to add WS2022 cluster to the backup and Im getting:

Failed to connect to cluster xxxx
Failed to create Hyper-V Cluster Wmi utils: Failed to test connection to the host xxxx with OMICLI.
Possible reason:
Specified host is not a cluster node.

I have tested everything I could find and arrived at this thread. I have added domain joined backup proxy for gMSA, but I dont want to add backup to the domain.

Thank you.

[JaySt]

having this problem right now with a 2025 cluster. I don't want to join the VSA to the domain. what's the latest recommendations here? currently thinking of trying the krb5.conf changes documented here: https://www.veeam.com/kb4841

[JaySt]

update: used the UPN format for the credentials ( e.g. username@domainFQDN) and we did not get the OMICLI message. (instead of DOMAIN\username format). Ah well. It works.

[Jan1987]

have you edit the krb5.conf file?

We have a VSA are not domain joined and a domain joined Hyper-V 2025 Cluster. after edit the "realm" and "domain_realms" in the config file i can connect to my cluster with Domain\User.

[JaySt]

in our case, editing the krb5.conf file like you said was tried but did not solve the OMICLI message/error. We eventually continued with the edited krb5.conf file AND switched to using UPN format username for connecting. Now all is working. So i'm not sure if the fix was the combination of the krb5.conf file and the UPN format usage or just the UPN format usage that did the trick, but it's working now.
here is a bit of clarification from veeam support on this:

When the Veeam Service Appliance (VSA) is not joined to the domain, it does not have a native relationship with the Active Directory environment. Using the legacy DOMAIN\Username format relies on NTLM/NetBIOS resolution, which often fails in cross-realm or non-domain-joined scenarios.
The UPN format (user@domain.com) allows the VSA to leverage Kerberos authentication more effectively without requiring a formal domain join. By providing the fully qualified UPN, you are explicitly defining the authentication realm, which allows the OMICLI utility to correctly resolve the cluster nodes and establish the WMI connection.

btw:
my krb5.conf file currently looks like this on the realms and domain_realm blocks.
[realms]
FQDN.DOMAIN = {
kdc = dcservername.fqdn.domain
}

[domain_realm]
.fqdn.domain = FQDN.DOMAIN
fqdn.domain = FQDN.DOMAIN