Windows Server 2025/2022 Failover Cluster Setup Step by Step

A failover cluster you have never failed over is a guess. This guide builds a two-node Windows Server failover cluster step by step, puts a highly available file server on it, then pulls the power on the active node while a client keeps writing to the share.

Original content from computingforgeeks.com - post 138327

The path covers everything Windows Server failover clustering needs for a working setup: domain join, the Failover Clustering feature, shared iSCSI storage, cluster validation, quorum with a disk witness, separate client and heartbeat networks, the file server role, a Cluster Shared Volume and Cluster-Aware Updating. Every command and output below comes from a lab run on Windows Server 2025 Datacenter in October 2026. The FailoverClusters cmdlets and the Failover Cluster Manager console are the same on Windows Server 2022.

This is the layout the guide builds:

Clients only ever talk to the FS01 role address. When NODE1 dies, the role moves to NODE2 and nobody repoints a drive mapping. The heartbeat subnet carries cluster traffic only, and both nodes see the same iSCSI disks, which is what lets the role move at all.

What you need

Four servers, all running the same Windows Server version and edition on the cluster nodes. The domain controller must not be one of the cluster nodes. These are the names and addresses used throughout:

Host	LAN address	Heartbeat	Job
DC01	10.0.1.10	none	AD DS and DNS for corp.example.com
NODE1	10.0.1.11	10.10.10.11	Cluster node
NODE2	10.0.1.12	10.10.10.12	Cluster node
STOR01	10.0.1.50	none	iSCSI target (skip it if you have a SAN)
WSFC01	10.0.1.100	none	Cluster name and address
FS01	10.0.1.110	none	Clustered file server role

Each node has two NICs. The LAN NIC has a default gateway and points DNS at the domain controller. The heartbeat NIC has no gateway and no DNS registration. If the domain doesn’t exist yet, set up AD DS with PowerShell first, and make sure the DNS server resolves every node by name.

Later commands refer to the adapters as LAN and Heartbeat, so rename them first. Check which alias holds which interface with Get-NetAdapter, then on NODE1 (use 10.0.1.12 and 10.10.10.12 on NODE2). A NIC that still has a DHCP lease needs Set-NetIPInterface -InterfaceAlias LAN -Dhcp Disabled first, or New-NetIPAddress fails because the gateway already exists:

Rename-NetAdapter -Name "Ethernet" -NewName "LAN"
Rename-NetAdapter -Name "Ethernet 2" -NewName "Heartbeat"
New-NetIPAddress -InterfaceAlias LAN -IPAddress 10.0.1.11 -PrefixLength 24 -DefaultGateway 10.0.1.1
Set-DnsClientServerAddress -InterfaceAlias LAN -ServerAddresses 10.0.1.10
New-NetIPAddress -InterfaceAlias Heartbeat -IPAddress 10.10.10.11 -PrefixLength 24
Set-DnsClient -InterfaceAlias Heartbeat -RegisterThisConnectionsAddress $false

Servers cloned from one template need Sysprep before they join the domain, or the join fails with a misleading password error. The fix is in the troubleshooting section.

Size the nodes for the workload, not for the lab. Each node must carry every role on its own when its partner is down, so a two-node cluster runs each node at no more than half of what it can handle. Keep the nodes identical in CPU, RAM, NICs and drivers, because validation flags differences and a cluster runs at the pace of its weakest member. The lab nodes had 2 vCPU and 6 GB RAM, which is a floor for following along, not a production recommendation. Storage traffic belongs on a dedicated NIC in production. The lab ran iSCSI over the LAN to keep the build small.

Firewall rules mostly take care of themselves. Installing the Failover Clustering feature enables the built-in “Failover Clusters” rule group on each node (TCP and UDP 3343, TCP 135, dynamic RPC and SMB 445), and the iSCSI Target Server role enables “iSCSI Target (TCP-In)” for port 3260. Third-party firewalls between the nodes are another matter: open those ports by hand, the same way you would open a port in Windows Firewall.

Join the nodes to the domain

Run this on NODE1, NODE2 and STOR01. It prompts for a domain admin password and reboots the server:

Add-Computer -DomainName corp.example.com -Credential CORP\Administrator -Restart

Microsoft recommends a dedicated OU for cluster nodes. It keeps Group Policy predictable and stops someone deleting the cluster computer objects by accident. On DC01, create the OU and move both nodes into it:

New-ADOrganizationalUnit -Name Clusters -Path "DC=corp,DC=example,DC=com"
Get-ADComputer NODE1 | Move-ADObject -TargetPath "OU=Clusters,DC=corp,DC=example,DC=com"
Get-ADComputer NODE2 | Move-ADObject -TargetPath "OU=Clusters,DC=corp,DC=example,DC=com"
Get-ADComputer -Filter * -SearchBase "OU=Clusters,DC=corp,DC=example,DC=com" | Format-Table Name, DistinguishedName

Both nodes now sit in the new OU:

Name  DistinguishedName
----  -----------------
NODE2 CN=NODE2,OU=Clusters,DC=corp,DC=example,DC=com
NODE1 CN=NODE1,OU=Clusters,DC=corp,DC=example,DC=com

The cluster creates its own computer object (the CNO) in this OU later on. That matters again when the file server role comes online.

Install the Failover Clustering feature

Every node needs Failover Clustering. The file server role used later also needs the File Server role service, which a fresh Windows Server 2025 install does not have (it showed as Available, not Installed). One command from NODE1 installs both on both nodes:

$nodes = "NODE1", "NODE2"
Invoke-Command -ComputerName $nodes -ScriptBlock {
    Install-WindowsFeature -Name Failover-Clustering, FS-FileServer -IncludeManagementTools
} | Format-Table PSComputerName, Success, RestartNeeded, ExitCode -AutoSize

NODE2 already had the features from an earlier run, so it reports NoChangeNeeded. Neither node asked for a reboot:

PSComputerName Success RestartNeeded ExitCode
-------------- ------- ------------- --------
NODE2             True No            NoChangeNeeded
NODE1             True No            Success

Confirm the feature, the PowerShell module and the File Server role service on both nodes:

Invoke-Command -ComputerName $nodes -ScriptBlock {
    Get-WindowsFeature Failover-Clustering, FS-FileServer, RSAT-Clustering-PowerShell
} | Format-Table PSComputerName, Name, InstallState -AutoSize

All six rows should read Installed:

PSComputerName Name                       InstallState
-------------- ----                       ------------
NODE2          FS-FileServer              Installed
NODE2          Failover-Clustering        Installed
NODE2          RSAT-Clustering-PowerShell Installed
NODE1          FS-FileServer              Installed
NODE1          Failover-Clustering        Installed
NODE1          RSAT-Clustering-PowerShell Installed

Prefer the GUI? In Server Manager, open Manage, Add Roles and Features, tick File and Storage Services, File and iSCSI Services, File Server on the Server Roles page, tick Failover Clustering on the Features page, accept the management tools, and repeat on the second node.

Prepare the shared iSCSI storage

Both nodes must see the same disks. A small one (1 GB is plenty) becomes the disk witness, and a larger one holds the file server data. The documented minimum for a witness disk is just over 512 MB.

No SAN? Build the target on Windows

Skip this part if a SAN or NAS already presents LUNs to both nodes. Otherwise the iSCSI Target Server role on STOR01 does the job. Install it, create one target that only accepts the two node addresses, and map two virtual disks to it:

Install-WindowsFeature FS-iSCSITarget-Server -IncludeManagementTools
New-Item -ItemType Directory C:\iSCSIVirtualDisks -Force
New-IscsiServerTarget -TargetName wsfc -InitiatorIds "IPAddress:10.0.1.11","IPAddress:10.0.1.12"
New-IscsiVirtualDisk -Path C:\iSCSIVirtualDisks\witness.vhdx -SizeBytes 1GB
New-IscsiVirtualDisk -Path C:\iSCSIVirtualDisks\fsdata.vhdx -SizeBytes 20GB
Add-IscsiVirtualDiskTargetMapping -TargetName wsfc -Path C:\iSCSIVirtualDisks\witness.vhdx
Add-IscsiVirtualDiskTargetMapping -TargetName wsfc -Path C:\iSCSIVirtualDisks\fsdata.vhdx
Get-IscsiServerTarget | Format-List TargetName, TargetIqn, InitiatorIds, LunMappings

Note the target IQN. The nodes connect to it by that name:

TargetName   : wsfc
TargetIqn    : iqn.1991-05.com.microsoft:stor01-wsfc-target
InitiatorIds : {IPAddress:10.0.1.11, IPAddress:10.0.1.12}
LunMappings  : {TargetName:wsfc;VHD:"C:\iSCSIVirtualDisks\witness.vhdx";LUN:0,
               TargetName:wsfc;VHD:"C:\iSCSIVirtualDisks\fsdata.vhdx";LUN:1}

A single Windows target is itself a single point of failure, so treat it as lab or branch storage. The iSCSI target and initiator guide covers CHAP and the GUI version of these steps.

Connect both nodes to the target

Run this on NODE1 and then on NODE2. Swap in your own portal address and IQN if the storage is a SAN:

Start-Service MSiSCSI
Set-Service MSiSCSI -StartupType Automatic
New-IscsiTargetPortal -TargetPortalAddress 10.0.1.50
Connect-IscsiTarget -NodeAddress "iqn.1991-05.com.microsoft:stor01-wsfc-target" -IsPersistent $true
Get-Disk | Format-Table Number, FriendlyName, Size, PartitionStyle, OperationalStatus -AutoSize

The two LUNs show up as disks 1 and 2. They arrive Offline and RAW, which is the default SAN policy for shared disks:

Number FriendlyName              Size PartitionStyle OperationalStatus
------ ------------              ---- -------------- -----------------
     1 MSFT Virtual HD     1073741824 RAW            Offline
     2 MSFT Virtual HD    21474836480 RAW            Offline
     0 QEMU QEMU HARDDISK 68719476736 GPT            Online

Format the disks on one node only

Do this on NODE1 alone. Formatting the same LUN from two nodes before the cluster owns it corrupts it. Check the disk numbers from the previous output first, because yours may differ:

Set-Disk -Number 1 -IsOffline $false
Set-Disk -Number 2 -IsOffline $false
Initialize-Disk -Number 1 -PartitionStyle GPT
Initialize-Disk -Number 2 -PartitionStyle GPT
New-Partition -DiskNumber 1 -UseMaximumSize | Format-Volume -FileSystem NTFS -NewFileSystemLabel "Witness" -Confirm:$false
New-Partition -DiskNumber 2 -UseMaximumSize | Format-Volume -FileSystem NTFS -NewFileSystemLabel "FSData" -Confirm:$false

No drive letters are assigned here. The cluster assigns letters itself when it brings the disks online, including one for the witness, which is removed after the quorum step.

Validate the cluster configuration

Microsoft only supports a cluster that passes validation, and it catches real problems before they become outages. Run it from NODE1:

Test-Cluster -Node NODE1, NODE2

It took about four minutes on the lab and finished with one warning:

WARNING: Network - Validate IP Configuration: The test reported some warnings..
WARNING:
Test Result:
HadUnselectedTests, ClusterConditionallyApproved
Testing has completed for the tests you selected. You should review the warnings in the Report.  A cluster solution is supported by Microsoft only if you run all cluster validation tests, and all tests succeed (with or without warnings).
Test report file path: C:\Users\administrator.CORP\AppData\Local\Temp\Validation Report 2026.10.07 At 17.34.56.htm

Open the HTML report and read every warning. Ours said neither node had “an adapter usable by the cluster with a defined default gateway”, plus a DNS suffix search list mismatch. Both are covered in the troubleshooting section. After fixing them, the second run came back clean in a little over three minutes: Inventory, Network, Storage and System Configuration all reported Success. A copy of each report also lands in C:\Windows\Cluster\Reports.

HadUnselectedTests is expected. The default run skips categories that do not apply here, such as the Hyper-V and Storage Spaces Direct tests.

Create the failover cluster

The cluster gets a name (WSFC01) and a static address on the LAN. -NoStorage stops it grabbing every shared disk on the way in, so you decide which disk becomes the witness:

New-Cluster -Name WSFC01 -Node NODE1, NODE2 -StaticAddress 10.0.1.100 -NoStorage

Creation took 46 seconds. Check the cluster and its nodes:

Get-Cluster | Format-List Name, Domain, SharedVolumesRoot
Get-ClusterNode | Format-Table Name, State, NodeWeight -AutoSize

Both nodes are up with one vote each:

Name              : WSFC01
Domain            : corp.example.com
SharedVolumesRoot : C:\ClusterStorage

Name  State NodeWeight
----  ----- ----------
NODE1    Up          1
NODE2    Up          1

Failover Cluster Manager (cluadmin.msc) shows the same cluster. A Windows Admin Center prompt appears on first launch; dismiss it and the console opens on the cluster summary. This capture was taken after the whole build, so it already shows the witness and the renamed networks from the next sections:

Straight after New-Cluster, the quorum type is Majority with no witness. Fix that next, after one permission change in AD.

Let the cluster create computer objects

Every clustered role with a network name (FS01 here) gets its own computer object, and the cluster account WSFC01$ creates it in the OU where the cluster lives. A fresh OU doesn’t let it. On the lab, the first attempt to bring FS01 online failed with event 1194 for exactly this reason. Grant the right up front on DC01:

dsacls "OU=Clusters,DC=corp,DC=example,DC=com" /G 'CORP\WSFC01$:CC;computer'

The command ends with “The command completed successfully”. The single quotes matter in PowerShell, since $ inside double quotes would be read as a variable.

Add the disks and configure the quorum witness

A two-node cluster needs a witness. Without one, losing either node leaves one vote out of two and the cluster cannot keep quorum reliably. Add the shared disks:

Get-ClusterAvailableDisk | Add-ClusterDisk

This catches people out: the resource names do not follow the disk numbers. On the lab, “Cluster Disk 1” was the 20 GB data disk and “Cluster Disk 2” the 1 GB witness candidate. Map each resource to its size before using it:

Get-ClusterResource | Where-Object ResourceType -eq "Physical Disk" | ForEach-Object {
    $disk = Get-CimInstance -Namespace root\MSCluster -ClassName MSCluster_Resource -Filter "Name='$($_.Name)'" | Get-CimAssociatedInstance -ResultClassName MSCluster_Disk
    [pscustomobject]@{ Resource = $_.Name; SizeGB = [math]::Round($disk.Size / 1GB, 1) }
} | Format-Table -AutoSize

The output settles which is which:

Resource       SizeGB
--------       ------
Cluster Disk 1     20
Cluster Disk 2      1

Rename both so later commands cannot point at the wrong disk, then make the small one the witness:

(Get-ClusterResource -Name "Cluster Disk 2").Name = "Witness Disk"
(Get-ClusterResource -Name "Cluster Disk 1").Name = "FS01 Data"
Set-ClusterQuorum -DiskWitness "Witness Disk"
Get-ClusterQuorum | Format-List Cluster, QuorumResource, QuorumType

The quorum resource is now the witness disk:

Cluster        : WSFC01
QuorumResource : Witness Disk
QuorumType     : Majority

On the lab the witness came online as F:, and Microsoft says the witness disk should not have a drive letter. Remove it on the node that owns the witness:

$o = (Get-ClusterResource "Witness Disk").OwnerNode.Name
Invoke-Command -ComputerName $o -ScriptBlock {
    $p = Get-Volume -FileSystemLabel Witness | Get-Partition
    if ($p.DriveLetter) { $p | Remove-PartitionAccessPath -AccessPath "$($p.DriveLetter):\" }
}

The witness stays Online with no letter. Dynamic quorum is on by default ((Get-Cluster).DynamicQuorum returned 1), so the cluster adjusts node and witness votes as members come and go.

File share witness instead of a disk

No shared disk to spare, or nodes in two sites? A file share on a third server works. The share is for this cluster only, and the cluster account needs Change on the share and Modify on the folder. On STOR01:

New-Item -Path C:\ClusterWitness -ItemType Directory
New-SmbShare -Name ClusterWitness -Path C:\ClusterWitness -ChangeAccess 'CORP\WSFC01$'
icacls C:\ClusterWitness /grant 'CORP\WSFC01$:(OI)(CI)M'

Then point the quorum at it from any node:

Set-ClusterQuorum -FileShareWitness "\\STOR01\ClusterWitness"

On the lab the “File Share Witness” resource came online in Cluster Group straight away, and switching back with Set-ClusterQuorum -DiskWitness "Witness Disk" worked just as cleanly. A cloud witness (an Azure Storage account) is the third option, set with Set-ClusterQuorum -CloudWitness -AccountName <account> -AccessKey <key>; it needs outbound HTTPS from every node, and we did not test it here. The Microsoft quorum witness documentation covers all three.

Separate client and heartbeat traffic

The cluster already guessed right. It set the subnet with a default gateway to ClusterAndClient and the gateway-less heartbeat subnet to Cluster only. Give the networks readable names and pin the roles so nobody has to remember which is which. Run Get-ClusterNetwork | Format-Table Name, Address first, because on another build “Cluster Network 1” may be the heartbeat subnet:

(Get-ClusterNetwork -Name "Cluster Network 1").Name = "Client-Network"
(Get-ClusterNetwork -Name "Cluster Network 2").Name = "Heartbeat-Network"
(Get-ClusterNetwork -Name "Heartbeat-Network").Role = 1
(Get-ClusterNetwork -Name "Client-Network").Role = 3
Get-ClusterNetwork | Format-Table Name, Role, State, Address, Metric -AutoSize

Role 1 is Cluster (heartbeat only), 3 is ClusterAndClient and 0 is None. The lower metric marks the network the cluster prefers for its own traffic:

Name                          Role State Address    Metric
----                          ---- ----- -------    ------
Client-Network    ClusterAndClient    Up 10.0.1.0    70240
Heartbeat-Network          Cluster    Up 10.10.10.0  30240

Create the highly available file server

FS01 gets its own name, its own address and the data disk. Clients connect to FS01, and whichever node owns it serves the share:

Add-ClusterFileServerRole -Name FS01 -Storage "FS01 Data" -StaticAddress 10.0.1.110

Confirm every resource in the role is online:

Get-ClusterResource | Where-Object OwnerGroup -eq FS01 | Format-Table Name, State, ResourceType -AutoSize

Four resources make up the role:

Name                   State ResourceType
----                   ----- ------------
File Server (\\FS01)  Online File Server
FS01                  Online Network Name
FS01 Data             Online Physical Disk
IP Address 10.0.1.110 Online IP Address

If the FS01 Network Name shows Failed instead, the computer object permission from earlier is missing. The fix is in the troubleshooting section.

The data disk came up as E: on the owner node. Create the folder and the share on NODE1 (the current owner), scoped to FS01 so it follows the role between nodes:

New-Item -Path "E:\Shares\SharedDocs" -ItemType Directory
New-SmbShare -Name "SharedDocs" -Path "E:\Shares\SharedDocs" -ScopeName "FS01" -FullAccess "CORP\Domain Admins" -ChangeAccess "CORP\Domain Users"
Get-SmbShare -ScopeName FS01 | Format-Table Name, ScopeName, Path, ContinuouslyAvailable -AutoSize

Shares on a clustered file server come out with ContinuouslyAvailable set to True. That flag is what lets SMB 3 clients ride through a failover instead of erroring:

Name       ScopeName Path                 ContinuouslyAvailable
----       --------- ----                 ---------------------
E$         FS01      E:\                                  False
SharedDocs FS01      E:\Shares\SharedDocs                  True

The Roles view in Failover Cluster Manager now lists FS01 running on NODE1:

The second entry, User Manager Group, is created by Windows Server 2025 on its own. It isn’t something you added.

Run a failover drill

Moving a role on an idle cluster proves little. Put a client on the share first. This loop ran on DC01 as a stand-in client, appending a timestamp to a file on \\FS01\SharedDocs every half second and logging how long each write took:

$end = (Get-Date).AddSeconds(480); $last = $null
while ((Get-Date) -lt $end) {
  $t = Get-Date
  try { Add-Content -Path \\FS01\SharedDocs\probe.txt -Value $t.ToString("HH:mm:ss.fff") -ErrorAction Stop; $s = "OK" } catch { $s = "FAIL " + $_.Exception.Message.Split("`n")[0] }
  $d = [int]((Get-Date) - $t).TotalMilliseconds
  ("{0} {1}ms {2}" -f $t.ToString("HH:mm:ss.fff"), $d, $s) | Out-File -Append -Encoding ascii C:\probe.log
  Start-Sleep -Milliseconds 500
}

The drill below starts with FS01 on NODE2, so move it there before starting the probe:

Move-ClusterGroup -Name FS01 -Node NODE2

With the probe running, three events hit the cluster. First a planned move of the role back to NODE1:

Move-ClusterGroup -Name FS01 -Node NODE1

Then a maintenance drain of the owner, which moves every role off it and pauses it, followed by a resume:

Suspend-ClusterNode -Name NODE1 -Drain -Wait
Resume-ClusterNode -Name NODE1

The drain sends FS01 back to NODE2. Last, a hard power-off of NODE2 while it owned FS01, done from the hypervisor with no shutdown at all. This is what the probe recorded:

Event	Longest write stall	Failed writes
Move-ClusterGroup to the other node	7.1 s	0
Suspend-ClusterNode -Drain on the owner	7.0 s	0
Owner node powered off	41.6 s	0

No write failed in any of the three. During the power-off, one write simply hung for 41.6 seconds and then completed on the surviving node. That is SMB continuous availability doing its job. Part of the wait is detection: with SameSubnetDelay at 1000 ms and SameSubnetThreshold at 20 (the defaults, read with Get-Cluster | Format-List SameSubnetDelay, SameSubnetThreshold), a dead node is declared down after about 20 missed heartbeats. Applications with their own short timeouts can still give up inside that window, so test your real workload the same way.

After the power-off, the survivor owned everything:

Name  State
----  -----
NODE1    Up
NODE2  Down

Name              OwnerNode   State
----              ---------   -----
Available Storage NODE1     Offline
Cluster Group     NODE1      Online
FS01              NODE1      Online

Available Storage reads Offline because it is empty once every disk belongs to a role. The Nodes view shows both members back with their votes after NODE2 boots and rejoins on its own:

Add a Cluster Shared Volume for Hyper-V

A file server role owns its disk from one node at a time. Hyper-V virtual machines and Scale-Out File Server need a Cluster Shared Volume (CSV) instead, which every node mounts at once under C:\ClusterStorage. Add a third LUN on STOR01:

New-IscsiVirtualDisk -Path C:\iSCSIVirtualDisks\csv01.vhdx -SizeBytes 10GB
Add-IscsiVirtualDiskTargetMapping -TargetName wsfc -Path C:\iSCSIVirtualDisks\csv01.vhdx

The nodes already have the target connected, so a rescan picks up the new disk. Run this on both nodes:

Update-HostStorageCache

Then format it on NODE1 only (it showed up as disk 3):

Set-Disk -Number 3 -IsOffline $false
Initialize-Disk -Number 3 -PartitionStyle GPT
New-Partition -DiskNumber 3 -UseMaximumSize | Format-Volume -FileSystem NTFS -NewFileSystemLabel "CSV01" -Confirm:$false

Add it to the cluster and convert it to a CSV:

Get-ClusterAvailableDisk | Add-ClusterDisk
Add-ClusterSharedVolume -Name "Cluster Disk 1"
Get-ClusterSharedVolume | Select-Object Name, State, @{n="Path";e={$_.SharedVolumeInfo.FriendlyVolumeName}} | Format-Table -AutoSize

The new disk took the free name “Cluster Disk 1” (the original was renamed earlier) and mounted as Volume1 on both nodes:

Name            State Path
----            ----- ----
Cluster Disk 1 Online C:\ClusterStorage\Volume1

The Disks view shows all three disks and what each one is assigned to:

From here, install Hyper-V on each node, store VM files under C:\ClusterStorage\Volume1, and make each VM highly available with Add-ClusterVirtualMachineRole -VMName <name>. The lab nodes had no nested virtualization, so the Hyper-V part was not run here.

Turn on Cluster-Aware Updating

Patching cluster nodes by hand means draining, patching, rebooting and resuming one node at a time. Cluster-Aware Updating (CAU) does that sequence for you. In self-updating mode the cluster runs it on a schedule. This sets the second Tuesday of every month:

Add-CauClusterRole -ClusterName WSFC01 -DaysOfWeek Tuesday -WeeksOfMonth 2 -MaxRetriesPerNode 3 -RequireAllNodesOnline -EnableFirewallRules -Force
Get-CauClusterRole -ClusterName WSFC01 | Format-Table Name, Value -AutoSize

-EnableFirewallRules opens the Remote Shutdown rules CAU needs to restart nodes. The role reports Online with the schedule:

Name                  Value
----                  -----
ResourceGroupName     CAUWSFC03ka
Status                Online
StartDate             10/8/2026 3:00:00 AM
MaxRetriesPerNode     3
RequireAllNodesOnline True
EnableFirewallRules   True
FailbackMode          Immediate
DaysOfWeek            Tuesday
WeeksOfMonth          {2}

The CAU role does not appear under Roles in Failover Cluster Manager or in Get-ClusterGroup output. Get-CauClusterRole is the place to check it. Nodes pull patches from Windows Update or from a WSUS server; the isolated lab had neither, so no update run was performed. Trigger one on demand with Invoke-CauRun -ClusterName WSFC01 -MaxRetriesPerNode 3 -Force, run from a machine outside the cluster (DC01 or a management server with RSAT-Clustering), or from Cluster-Aware Updating in Failover Cluster Manager.

Troubleshooting

Three real errors came up while building this cluster. Each one has an exact message worth searching for.

Event 1194: “failed to create its associated computer object”

FS01 came up as Failed, and the System log on the node carried this:

[1194] Cluster network name resource 'FS01' failed to create its associated computer object in domain 'corp.example.com' during: Resource online. The text for the associated error code is: Cannot complete this function. Please work with your domain administrator to ensure that: - The cluster identity 'WSFC01$' has Create Computer Objects permissions. By default all computer objects are created in the same container as the cluster identity 'WSFC01$'.

The cluster account had no right to create objects in the Clusters OU. Run the dsacls command from the “Let the cluster create computer objects” section on a domain controller, then start the role again:

Start-ClusterGroup -Name FS01

It came online on the first retry. When the security team will not delegate that right, ask them to prestage the computer object for the role and give WSFC01$ Full Control on it.

Validation warning: “does not have an adapter usable by the cluster with a defined default gateway”

Validate IP Configuration warns when no NIC on a node has a default gateway, and when the DNS suffix search lists differ between nodes. Give the LAN NIC its gateway and set the same suffix list everywhere:

New-NetRoute -InterfaceAlias LAN -DestinationPrefix 0.0.0.0/0 -NextHop 10.0.1.1
Set-DnsClientGlobalSetting -SuffixSearchList @("corp.example.com")

Leave the heartbeat NIC without a gateway. The gateway is also how the cluster decides which network may carry client traffic.

Domain join fails with “The user name or password is incorrect” on cloned servers

All the lab servers were cloned from one Windows Server template. The domain admin password was correct, yet Add-Computer kept failing with “The user name or password is incorrect”, and the domain controller logged event 4625 with status 0xC000006D. The clones all carried the same machine SID, and that SID had become the domain SID when DC01 was promoted. Compare the SIDs:

(Get-LocalUser Administrator).SID.Value

Every clone printed the same value, and it began with the domain SID that (Get-ADDomain).DomainSID.Value returns on the domain controller. The fix is to generalize each affected server with Sysprep before it joins the domain (C:\Windows\System32\Sysprep\sysprep.exe /generalize /oobe /shutdown, with an answer file if you want to skip the setup screens). A server that is already a domain controller should not be generalized; rebuild it instead. After Sysprep each node had a unique SID and joined at the first attempt.

Collect the cluster log

For anything the event log does not explain, generate the detailed cluster log. This pulls the last 60 minutes from every node into one folder:

New-Item -Path C:\Temp -ItemType Directory -Force
Get-ClusterLog -Destination C:\Temp -TimeSpan 60

One file per node, around 13 MB each after an hour of failover tests:

Name                Length
----                ------
NODE1_Cluster.log 13251506
NODE2_Cluster.log 12799886

Day-to-day cluster commands

Every command in this table ran against WSFC01 during the build. Run them from any node, or from a management server with RSAT-Clustering-PowerShell and -Cluster WSFC01 added.

Task	Command
Nodes and their state	Get-ClusterNode
Roles and owners	Get-ClusterGroup
Resources that are not online	Get-ClusterResource | Where-Object State -ne "Online"
Move a role	Move-ClusterGroup -Name FS01 -Node NODE2
Drain a node for maintenance	Suspend-ClusterNode -Name NODE1 -Drain -Wait
Bring it back	Resume-ClusterNode -Name NODE1
Evict a node	Remove-ClusterNode -Name NODE2 -Force
Add a node	Add-ClusterNode -Name NODE2 -Cluster WSFC01 -NoStorage
Quorum and witness	Get-ClusterQuorum
Network roles	Get-ClusterNetwork
Cluster Shared Volumes	Get-ClusterSharedVolume
Heartbeat timing	Get-Cluster | Format-List SameSubnetDelay, SameSubnetThreshold

Move roles and CSVs off a node before you evict it. On the lab, NODE2 was evicted and added back with -NoStorage in under a minute, and its LAN and heartbeat interfaces rejoined the right cluster networks without any manual work. For a browser-based view of the same cluster, Windows Admin Center connects to WSFC01 by name. The Microsoft create a failover cluster page is the reference for the wizard-driven path.