Microsoft Hyperv fail-over-cluster ws2025 in workgroup environment

[pmfna]

Hello

A customer asked me to build a POC with a hyperv cluster 2025 in workgroup environment because now Microsoft supports live migration using Certificate-Based Authentication.

I was able to add the nodes individually to Veeam v13, but when I try to add by the cluster name is shows an error.

Anyone try this successfully?

[pmfna]

well,

I was able to test this further, and noe I'm able to add the hyper-v nodes individually to veeam inventory.
I've realized that veeam disabled NTLM access in V13.

I've created a VMgroup at cluster level, and if I add the group to the JOB (cluster is two nodes, so I've added two VMgroup with the same name) and the job runs.

One thing I've noticed, is, if I migrate the vm from one host to another, veeam is creating a new full job for that vm in a new disk in repository, is this the expected behaviour ?

Is this configuration supported by veeam, couldnt see anything otherway in docs

[DaStivi]

hello there!
i've noticed the exact same issue! but its not related to workgroup-cluster.. this is also on a domain-joined cluster! (even MS "supports" live-migration in workgroup now (it even worked before with some tricks) i wouldn't recommend a workgroup-cluster... microsoft don't write thit in the same docs, but don't having it domain joined also breaks a lot of other things... foremost the cluster-aware-updating for example... but this is all a different story)

i was able to add the domain-joined nodes individually, but can't add the cluster node!
have a support case open on this: 07831539

you can also find something about the error in the logs, but nothing to helpfull:

Code: Select all

   output:
[26.09.2025 13:37:57.362]    <08>   Error (1)    stdout: instance of OMI_Error
[26.09.2025 13:37:57.362]    <08>   Error (1)    {
[26.09.2025 13:37:57.362]    <08>   Error (1)        OwningEntity=OMI:CIMOM
[26.09.2025 13:37:57.362]    <08>   Error (1)        MessageID=OMI:MI_Result:1
[26.09.2025 13:37:57.362]    <08>   Error (1)        Message=Kerberos verify cred with password failed No credentials were supplied, or the credentials were unavailable or inaccessible
[26.09.2025 13:37:57.362]    <08>   Error (1)        MessageArguments={}
[26.09.2025 13:37:57.362]    <08>   Error (1)        PerceivedSeverity=7
[26.09.2025 13:37:57.362]    <08>   Error (1)        ProbableCause=117
[26.09.2025 13:37:57.362]    <08>   Error (1)        ProbableCauseDescription=Kerberos verify cred with password failed No credentials were supplied, or the credentials were unavailable or inaccessible
[26.09.2025 13:37:57.362]    <08>   Error (1)        CIMStatusCode=1
[26.09.2025 13:37:57.362]    <08>   Error (1)        OMI_Code=1
[26.09.2025 13:37:57.362]    <08>   Error (1)        OMI_Category=0
[26.09.2025 13:37:57.362]    <08>   Error (1)        OMI_Type=MI
[26.09.2025 13:37:57.362]    <08>   Error (1)        OMI_ErrorMessage=A general error occurred, not covered by a more specific error code.
[26.09.2025 13:37:57.362]    <08>   Error (1)    }
[26.09.2025 13:37:57.362]    <08>   Error (1)    stderr: /opt/veeam/vbr/omi/omicli: result: MI_RESULT_ACCESS_DENIED

there is also a commandline displayed what veeam is trying todo:

Code: Select all

   client options: Options { ToolPath = /opt/veeam/vbr/omi/omicli, AddressOrHostname = 172.22.240.220, UserName = backup-service, UserDomainName = domain, PasswordProvider = System.Func`1[System.String], LogInhibition = False, ConnectionTimeoutSeconds = 3600, Port = 5985, EncryptionType = Http, AuthType = Kerberos }
[26.09.2025 13:37:57.362]    <08>   Error (1)         command line: /opt/veeam/vbr/omi/omicli wql root/cimv2 'SELECT Version FROM Win32_OperatingSystem' --hostname HVCluster --port 5985 --encryption http --auth Kerberos -u backup-service@domain -pi

you'll see the port 5985 there... basically its winRM...

support told me to test with wbemtest tool, if i can connect to the cluster... and yes in my case its working as expected... allthough the cluster WMI space is somewhat secured, because as soon as i trying to connect this wmispace and make querys i get a warning in eventlog that this is only supported with encryped querys... not sure how to test this..

anyway. i've also tested with "invoke-command clustername" with kerberos and the service account, this is also working in my case...

today i also tested to add the v13-vsa to the domain (this can be done in the host mgmt interface) but also doesn't change the behaviour!

it even doesn't matter what user you choose, it fails before it checks the user i think!

[pmfna]

Hi,

thanks for your inputs, thats really strange when using ad-joined servers.

Lets see if someone at Veeam responds.

regards

[GT-Engineer]

I am glad you are working on this issue. I gave up on the VSA V13 after running into this issue. It seems to have a lot of bugs out the gate and support was not very helpful with my first ticket. I will follow, because I am very excited about this new release.

[Gostev]

Actually no, nothing like "a lot of bugs" at the moment for VSA, basically exactly the opposite (which frankly has been a bit shocking for such a huge rewrite). The number of installs and protected workloads are keep ramping up with little to no support cases so far. It seems that overall VSA "just works" although of course environment-specific issues may leave impression of "a lot of bugs".

Also, keep in mind our support process is designed to finish with providing the resolution for any product issue UNLESS you accept "not very helpful" response and agree to close the ticket. Otherwise, if support is unable to resolve it for you themselves, they will be forced to escalate the case into R&D ultimately.

[pmfna]

For me, as this is a POC requested by a customer, I've opened a case using the General Inquiry option.

Case #07836904

[Gostev]

Yeah that won't work, this is for the web site related queries so these cases do not go into the product support system in principle.
The form even specifically explains this with a hint in red font that appears when you select "General inquiry".
You should reopen the case using the top/default option "Technical product support"

[DaStivi]

i've tested this a little further... logged into vbr-vsa and run the omicli manually with all the different Parameters and options...

i also enabled

winrm set winrm/config/service/auth '@{Basic="false"}'

and

winrm set winrm/config/service '@{AllowUnencrypted="false"}'

to test different thing with basic and unencrypted authentication..

i've created a local user on my Hyper-V to test with... this worked at some point with the basic/unencrypted settings...

after that worked a created another domain-joined user with the same simple password to test with.
from the omicli i didn't get this domain-joined user to work. but from VBR Console i was able to add the cluster then with the newly created domain user, using "UPN-Style" ... (this user was just added as local admin on the cluster-owner node)

my best-case assumption right now is that my service account has some special character in the password that might break the connection! because even using the upn-style (usename@fqdn) does not work but the newly created user does... and there shouldn't be any differences...

[DaStivi]

update: after I've added the cluster i can change the user to the other, that not worked initially and its still working afterwards...

[pmfna]

Yeah that won't work, this is for the web site related queries so these cases do not go into the product support system in principle.
The form even specifically explains this with a hint in red font that appears when you select "General inquiry".
You should reopen the case using the top/default option "Technical product support"

Is it possible for me as a Veeam Platinum Partner open this type of cases? When chosing Technical product support it shows me Evaluation Product, it is ok to open this way ?

thanks

[Gostev]

Well this is really not an R&D kitchen but as far as I know, the license owner can assign anyone at all as a "case admin" (or something like this) in the Customer Portal, and then this person can open cases on their behalf.

[DaStivi]

I've tested it a little further... one thing i can say for sure, the message "Specified host is not a cluster node" can be a error for everything, even for authentication related stuff... so bad/wrong passwords, users that are not allowed, not enough permission... Everything!

in my tests before, where I created a new user with a simple password and it worked... I then used the same complex password as for my existing account for the newly created one, at it still worked.. so some special character can be out-ruled now...
one thing though i noticed, that my "old" account had set a password quite a few years ago... i've re-set the same password for the account again and suddenly the account also worked in VBR!

I've retested this with another old Service Account, with some other hacks i did (resetting just the lastpwdSet attribute in AD, that didn't worked) but as soon as i've resettet the password (even to the old existing one) the account starten to work for Cluster Connection...

my assumption right now is that the CISA/DISA-STIG Hardening of the VSA "blocks" accounts with old passwords?

[wku]

I ran into similar issues in a totally different (non-Veeam) context a while ago, so this will be vague, but - first Windows was storing password hashes only using the "old" algorithms, then over the years you could optionally enable storing old+new, then at some point old+new became the default, and since very recently (like... 2-3 months ago) old are now rejected by patched domain controllers.
So if you have an user who never had password changed since storing hashes with modern-algorithm has been enabled, and it has only old-algorithm, it's going to face issues in general, not just with Veeam.