Managing And Patching Neverfail Continuity Engine Clusters Using Passive Node Management Feature With Windows Server Update Services (WSUS)

Managing And Patching Neverfail Continuity Engine Clusters Using Passive Node Management Feature With Windows Server Update Services (WSUS)

Summary

This article provides information on how to manage or patch Neverfail Continuity Engine clusters through Windows Server Update Services, using Passive Node Management feature.

Prerequisites

WSUS Server

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 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 Management Name and IP Address.

Thus, a 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 Management identity.

Resulting configuration

Physical Hardware Identity

Management Name

Public Name

Primary
ag-wsus-p
ag-wsus
Secondary
ag-wsus-s
ag-wsus

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 Management names).

Root cause: Duplicated SusClientId

  1. 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.
  2. 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
  3. cloned images without some sort of SID generation tool (e.g. Microsoft Sysprep)
For validating this situation:
  1. check SusClientId in HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate



Workaround: Reset SusClientId - Execute the following script on passive server
  1. net stop wuauserv
  2. reg Delete HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate /v SusClientId /f
  3. reg Delete HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate /v SusClientIDValidation /f
  4. net start wuauserv
  5. wuauclt.exe /resetauthorization /detectnow
  6. wuauclt.exe /reportnow

Result:
  1. new SusClientId generated on passive server and all Engine nodes are seen in WSUS Console



Engine node management 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 management names in WSUS console.
  1. $updateSession = new-object -com "Microsoft.Update.Session"; $updates=$updateSession.CreateupdateSearcher().Search($criteria).Updates
  2. wuauclt /reportnow

Applies to

WSUS 2008R2, 2012R2, 2016, 2019 (latest tested version 10.0.17763.1)

Neverfail Continuity Engine 8.5 and later