banshee/active-directory-collection/active-directory/winrm/dhcp-failover

DHCP failover, by WinRM

Returns, for each failover relationship of the DHCP Server of a Windows, its state as this server sees it, its partner and its mode. Two watches are proposed, both checked: a relationship out of its normal state, and a relationship that is no longer there.

How it works

The collector runs one PowerShell script, by WinRM, that reads the IPv4 failover relationships of the local DHCP Server:

$ErrorActionPreference = 'Stop'; [Console]::OutputEncoding = New-Object System.Text.UTF8Encoding; ConvertTo-Json -Compress -Depth 4 -InputObject @{relationships = @(Get-DhcpServerv4Failover | ForEach-Object { @{name = $_.Name; state = [string]$_.State; partner = $_.PartnerServer; mode = [string]$_.Mode} })}

WinRM hands the script to PowerShell itself: the script is the one of active-directory/ssh/dhcp-failover, without the powershell -Command "…" that cmd.exe needs there.
Get-DhcpServerv4Failover, without a name, returns every failover relationship of the server (Microsoft, DhcpServer module). Its objects are those of the WMI class DhcpServerv4Failover (namespace root\Microsoft\Windows\DHCP), whose properties Microsoft documents: Name, PartnerServer, Mode (HotStandby or LoadBalance) and State.
A relationship is named by its name. Its state is returned as Microsoft writes it: NoState, Normal, Init, CommunicationInterrupted, PartnerDown, PotentialConflict, Startup, ResolutionInterrupted, ConflictDone, Recover, RecoverWait, RecoverDone.
No failover relationship stops the collector as misconfigured: a server without one has nothing to watch here. An answer that is not the expected JSON stops it as misconfigured too.

Nothing is written to the Windows: the script only reads.

Prerequisites

A Windows Server 2012 or later with the DHCP Server role and its PowerShell module (DhcpServer, installed with the management tools of the role), with Windows PowerShell 3.0 or later.
The WinRM service listening in HTTPS, on TCP 5986 or the port set in protocol:winrm:port, open in the Windows firewall to the poller, with a certificate the poller judges by the TLS profile of the probe or pins in protocol:winrm:fingerprint: the steps are those of the windows/winrm/services collector of banshee/windows-collection. NTLM authentication, which the WinRM service accepts as installed.
An account for monitoring, without administrator rights, set in protocol:winrm:user (DOMAIN\account or account@domain) with its password in protocol:winrm:password, member of the group "Remote Management Users" and of the group "DHCP Users", which the role creates (of the domain on a domain controller, local elsewhere): Microsoft documents it as read-only access to the DHCP Server. Never "DHCP Administrators".

Outputs

Name	Label	Unit	Per instance
`state`	State	—	yes, per relationship
`partner`	Partner	—	yes, per relationship
`mode`	Mode	—	yes, per relationship

Watches

Name	Title	Kind	Defaults	Checked by default
`not-normal`	Failover not normal	expected value, on `state`	critical when the state is anything but `Normal` for 3 runs	yes
`missing`	Failover relationship missing	expected instances, on `state`	no relationship named: it raises nothing until names are set on the probe	yes

A relationship goes through Startup and the Recover states on its way back to Normal: the three runs let it.

Limits

Each server sees the relationship from its side: watch both partners.
Not yet checked on a real DHCP Server: the execution; that "DHCP Users" is enough for the cmdlet, through WinRM, as it is for the DHCP console; that State and Mode come out of the cmdlet as the words Microsoft lists.