This article provides information on how to manage or patch Neverfail Continuity Engine clusters through Windows Server Update Services, using Cozen Passive Node Management feature.
A WSUS server must be present and configured in your organization.
WSUS GPO for using the IP address of the WSUS server (rather than its DNS name) as Engine blocks by default DNS resolution from the passive servers.
Enable Cozen Passive Node Management
Neverfail Continuity Engine servers should be able to access WSUS in order to be managed remotely from there.
- On the active server this can be achieved through the Public IP address or through a Management IP Address.
- On the passive server, this can be achieved only through a Cozen Management Name and IP Address.
Thus, a Cozen Management Name and IP Address with access to WSUS must be configured on each node, in order to be able to connect to WSUS when both in active or passive role.
Managing a Neverfail Engine Cluster from WSUS Console
Neverfail Engine nodes will be discovered and added to WSUS Console, each one with its own configured Cozen identity.
Assets before switchover (P=>S)
Assets after switchover (S=>P)
Issues and workarounds
Only one Engine node (last one communicating with WSUS, usually active) is seen in WSUS console
WSUS Console shows only the public name of the Engine cluster (no Cozen names).
Root cause: Duplicated SusClientId
- the moment a client system communicates with a Windows Update server, it creates 2 registry keys that are essentially a security identifier (SID) [SusClientId] and a validation key [SusClientIDValidation] that gives a unique hardware identifier in a binary form.
- WSUS servers use the SusClientId to identify unique devices and then associate the computer’s hostname to the unique identifier for easy recognizable display purposes. Because more than 1 system has the exact same SusClientId, the WSUS server replaces the computer object’s hostname with the latest hostname that communicated with the server
- cloned images without some sort of SID generation tool (e.g. Microsoft Sysprep)
For validating this situation:
- check SusClientId in HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate
Workaround: Reset SusClientId - Execute the following script on passive server
net stop wuauserv
reg Delete HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate /v SusClientId /f
reg Delete HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate /v SusClientIDValidation /f
net start wuauserv
wuauclt.exe /resetauthorization /detectnow
- new SusClientId generated on passive server and all Engine nodes are seen in WSUS Console
Engine node Cozen names are not being updated in WSUS console after a switchover
Workaround procedure #1
After the switchover is completed, on each Engine Server perform a Windows Update → Check for updates.
This will force update in WSUS Console, and then, the name is shown correctly for all Engine nodes.
Workaround procedure #2
After the switchover is completed, execute following PowerShell script on all Engine nodes to update both server Cozen names in WSUS console.
WSUS 2008R2, 2012R2, 2016, 2019 (latest tested version 10.0.17763.1)
Neverfail Continuity Engine 8.5 and later