New-ClusterAffinityRule: cmdlet not recognized

[ahinterl]

Several *-clusteraffinityrule cmdlets are described in MS articles, but I cannot use either of them, PS reports that the respective cmdlet is not recognized. Is there a special module I need to install first?

[#2]

If you want to install the Clustering tools, you can use Add-WindowsFeature RSAT-Clustering-PowerShell on a Windows server. Or by adding the feature in Windows 11 following this article: https://allthings.how/how-to-install-rsat-tools-on-windows-11/. The functions are then available by the FailoverClusters module that is installed,

[#3]

Hi @Harm_Veenstra, thank you for your answer.

Unfortunately, your advice didn't help as I already have the RSAT failover cluster module installed (I can check by successfully running:

get-cluster -name <clustername>

which is a cmdlet provided by FailoverClusters according to the manual.

In fact, I have all Windows RSAT capabilities installed on my machine; looks like none of them provides any of the 'new' cmdlets:

New-ClusterAffinityRule
Set-ClusterAffinityRule
Get-ClusterAffinityRule
Add-ClusterGroupToAffinityRule
Add-ClusterSharedVolumeToAffinityRule
Remove-ClusterAffinityRule
Remove-ClusterGroupFromAffinityRule
Remove-ClusterSharedVolumeFromAffinityRule

described in the MS article Create server and site affinity rules for VMs.

The article shows how to use Windows Admin Center (WAC) for managing basic affinity rules, too. I saw the menu item some weeks ago in WAC, but MS seems to have eliminated it in a newer version 'cause I cannot find it anymore in my WAC GUI.

I must admit that I have some trouble understanding the AntiAffinityClassNames property:

While MS describe it as being of type System.Collections.Specialized.StringCollection (that's what I can read on other pages dealing with how to set affinity rules as well),

Get-ClusterGroup -Cluster 'atndfhcicl01' | get-member -Name 'AntiAffinityClassNames' | fl *

gives me:

TypeName : Deserialized.Microsoft.FailoverClusters.PowerShell.ClusterGroup
Name : AntiAffinityClassNames
MemberType : Property
Definition : Deserialized.System.String[] {get;set;}

To my understanding, this is a little different to the term string collection—but hey, I'm not that expert regarding .net and C++ classes...

The MS article AntiAffinityClassNames gives me the impression that I can simply assign a string (array? In the command result above, there are those brackets after Deserialized.System.String...) value to the AntiAffinityClassNames property of affected virtual machines (VMs) to define an anti-affinity 'rule'.

It would help me a lot if someone could tell me what MS article I can 'trust', and whether it's really that simple to create an affinity rule. In the end, all I want is to avoid two special VMs to run on the same cluster node...

[#4]

Ah, this is a lot deeper than I thought at first site... I don't have Azure Stack or a Failover cluster to test myself...

[#5]

@ahinterl @Harm_Veenstra 

Azure Stack HCI is its own operating system, as the subscription model-based replacement for Hyper-V Server (which was free.)

Unless you're running the Azure Stack HCI hypervisor, you will not see these commandlets.

Cheers,

Lain

[#6]

Thank you, @LainRobertson.

At least with PS 5.1 on one of the Azure Stack HCI nodes, I had no luck (cmdlet not recognized). I don't want to irritate the machine, so I refrain from installing PS 7.3 which may behave differently.

Maybe someone tell me whether it's sufficient to simply assign a string to a VM's AntiAffinityClassNames property like this:

(Get-ClusterGroup -Name "vm1").AntiAffinityClassNames = 'SeparateVMs'
(Get-ClusterGroup -Name "vm2").AntiAffinityClassNames = 'SeparateVMs'

to get the VMs separated onto two different cluster nodes?

[#7]

@ahinterl 

If you're running Azure Stack HCI, you shouldn't need to work with assigning values that way as you ought to have the commandlets you're looking for available to you - assuming you have the failover clustering feature enabled.

Maybe let's check that first.

If you run the following, do you see failover clustering service and the relevant management tools (including the PowerShell module) installed?

Get-WindowsFeature -Name *clus*

If not, then that's why you can't see the newer commandlets.

Cheers,

Lain

[#8]

@ahinterl 

PS: Windows PowerShell (aka 5.1) is fine.

You don't need PowerShell (aka 7.x) for this at all. In fact, not all shipped modules even work properly with PowerShell.

Cheers,

Lain

[#9]

@LainRobertson

Hi Lain, this is what I get:

Display Name Name Install State
------------ ---- -------------
[X] Failover Clustering Failover-Clustering Installed
[X] Failover Clustering Tools RSAT-Clustering Installed
[X] Failover Cluster Management Tools RSAT-Clustering-Mgmt Installed
[X] Failover Cluster Module for Windows ... RSAT-Clustering-Powe... Installed
[ ] Failover Cluster Automation Server RSAT-Clustering-Auto... Available
[ ] Failover Cluster Command Interface RSAT-Clustering-CmdI... Available

Maybe it's the last item that I'm missing...

But anyway, even if I can get the cmdlet to run directly on the cluster node itself, I wonder how I can make use of it on a remote management machine (I normally do things in Visual Studio Code there)...

[#10]

@ahinterl 

Right, so this is all coming together now that I know you were looking to run the commands remotely. Probably my poor attention span, but I didn't spot that in your earlier posts.

Okay, so you can still do things remotely. It just requires some preparation beforehand.

# Create the new session. Note: You may need to exclude -UseSSL if you haven't configured secure WinRM;
$Session = New-PSSession -ComputerName rpfile02.robertsonpayne.com -UseSSL;

# Load the FailoverClusters module into that remote session prior to importing the session.
Invoke-Command -Session $Session -ScriptBlock { Import-Module -Name FailoverClusters };

# Now, import the session. There's various parameters you can use here but I'm going with the simple approach.
Import-PSSession -Session $Session;

You can now run New-ClusterAffinityRule and so forth.

Cheers,

Lain