Additional Pollers Down in Polling Engines but Standby in My Deployment after migration/HA rollback

2/20/2026 4:25 PM

2/20/2026 4:25 PM

This article covers a scenario where three Additional Polling Engines (APEs) suddenly show:

• My Deployment → Servers:

  • Status: Up

  • Type: Additional Poller – Standby

• Settings → All Settings → Polling Engines:

  • Same APEs are Down (red)

  • Last database sync is very old (hours/days)

  • No statistics updating for nodes on those pollers

Scenario:

• The primary SolarWinds server was migrated to another host, then rolled back to the original server.

• The APEs (e.g., APE01, APE02, APE03) were never migrated.

• HA was not intentionally used before the issue.

After the rollback, the three APEs were stuck as HA standby members even though HA was disabled globally and no HA pools were expected.

What to Check and Confirm

Use this section to confirm you are dealing with the same problem pattern.

1. UI symptoms

1. My Deployment → Servers

   • APEs (e.g., APE01, APE02, APE03) show:

     • Status: Up/green

     • Type: Additional Poller – Standby

   • No HA pools are intentionally configured.

2. Settings → All Settings → Polling Engines

   • Same APEs show:

     • Status: Down (red)

     • Last database sync: very old (e.g., thousands of minutes ago)

     • Polling completion may be 0 or stale.

   • Other engines (main poller and unaffected APEs) are Up with recent Last DB sync.

2. Database checks

Run these read-only checks (SQL Management Studio or Database Manager):

• Engines table
  Confirm each affected APE appears once in [Engines].

• OrionServers table
  Confirm each affected APE appears in [OrionServers] (current, valid rows).

• HA tables

  • [HA_Pools]

    • In this scenario, there are no active pools.

  • [HA_PoolMembers]

    • Affected APE hostnames still appear here with pool member types of AdditionalPollerStandby.

3. Registry on each affected APE

On each APE (e.g., APE01, APE02, APE03):

1. Open regedit.

2. Navigate to:
   HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\SolarWinds\HighAvailability

3. Check:

   • InstallType

   • RunType

For a normal, non‑HA Additional Poller, both should be:

• InstallType = AdditionalPoller

• RunType = AdditionalPoller

In the broken state, the APEs have HA‑style values (e.g., AdditionalPollerStandby) or mismatched RunType.

Orion Platform

A partial or abandoned HA configuration is left behind in the database and registry during the migration/rollback of the main poller:

• The APEs have records in HA_PoolMembers and related HA tables, marking them as HA standby members.

• On each affected APE, the RunType registry value under HighAvailability is set for HA (standby) instead of a normal Additional Poller.

• HA is disabled globally and there arre no valid HA pools, but:

  • My Deployment logic still treats the APEs as HA pool members (so they appear Up / Standby).

  • The Polling Engines view reflects the fact that those APEs are effectively not polling or writing to the DB, so they appear Down with stale Last DB sync.

This “HA ghost” state persists even after running the Configuration Wizard on the APEs, because the HA tables and RunType registry values were never corrected.

Summary of the Fix

To resolve the issue:

1. Stopp HA and SolarWinds services on the affected APEs.

2. Correct RunType (and confirm InstallType) in the registry to make each server a plain AdditionalPoller.

3. Clean HA tables for each affected hostname (removing orphan HA pool member records).

4. Restart HA and Platform services on each APE.

5. Confirm:

   • My Deployment → Servers: APEs now show as plain Additional Poller (no Standby).

   • Polling Engines: APEs now show Up/green with a recent Last database sync and normal polling.

---

Exact Resolution Steps

Important:

• Backup the SolarWinds database and Windows registry before making changes.

• Only perform these steps when you have a maintenance window.

Step 1 – Confirm HA is not required

• Confirm you do not intend to use HA for these APEs.

• If HA is actually desired, follow the standard How to rebuild SolarWinds High Availability and ensure correct RunType / InstallType values per role.

These steps assume HA is not required and you are converting the APEs back to standard Additional Pollers.

Step 2 – Stop services on each affected APE

On each APE (APE01, APE02, APE03):

1. In services.msc:

   • Stop SolarWinds High Availability Service.

2. In SolarWinds Platform Service Manager:

   • Stop all SolarWinds services (respect dependencies).

Repeat on all affected APEs.

Step 3 – Correct RunType/InstallType in the registry

On each affected APE:

1. Open regedit.

2. Go to:
   HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\SolarWinds\HighAvailability

3. Set the values to:

   • InstallType = AdditionalPoller

   • RunType = AdditionalPoller

4. Close regedit and re-open to ensure the values persist (they should not revert while HA service is stopped).

Step 4 – Clean HA records for each hostname in the DB

Warning: The following SQL is destructive and should be run only after DB backup and with approval. It is standard guidance for cleaning HA pool members.

For each affected APE hostname (replace 'NAME' with the actual hostname, e.g. 'APE01'):

-- Scripts are not supported under any SolarWinds support program or service.
-- Scripts are provided AS IS without warranty of any kind. SolarWinds further
-- disclaims all warranties including, without limitation, any implied warranties
-- of merchantability or of fitness for a particular purpose. The risk arising
-- out of the use or performance of the scripts and documentation stays with you.
-- In no event shall SolarWinds or anyone else involved in the creation,
-- production, or delivery of the scripts be liable for any damages whatsoever
-- (including, without limitation, damages for loss of business profits, business
-- interruption, loss of business information, or other pecuniary loss) arising
-- out of the use of or inability to use the scripts or documentation.

DECLARE @Hostname nvarchar(max)
SET @Hostname = 'NAME'

DECLARE @PMID int = (
    SELECT TOP 1 [PoolMemberId]
    FROM [HA_PoolMembers]
    WHERE [HostName] = @Hostname
)

DELETE FROM [HA_FacilitiesInstances]       WHERE [PoolMemberId] = @PMID
DELETE FROM [HA_PoolMemberInterfacesInfo]  WHERE [PoolMemberId] = @PMID
DELETE FROM [HA_ResourcesInstances]        WHERE [PoolMemberId] = @PMID
DELETE FROM [HA_PoolMembers]               WHERE [PoolMemberId] = @PMID

• Run this once per hostname (APE01, APE02, APE03).

• Confirm afterward that:

  • [HA_Pools] has no unwanted pools.

  • [HA_PoolMembers] no longer has rows for those hostnames.

Note: In this specific scenario, HA was not in use, so no HA pools were required. If HA is used elsewhere, adjust carefully and do not truncate global HA tables for unrelated pools.

Step 5 – Start services again

On each affected APE:

1. In services.msc:

   • Start SolarWinds High Availability Service (if keeping the service enabled in the environment).

2. In SolarWinds Platform Service Manager:

   • Start all SolarWinds services.

Wait a few minutes for services to register with the database.

Step 6 – Verify the fix

1. My Deployment → Servers

   • APEs (APE01, APE02, APE03) should now show as:

     • Type: Additional Poller (no “Standby”)

     • Status: Up

2. Settings → All Settings → Polling Engines

   • Same APEs should now show:

     • Status: Up (green)

     • Last database sync: Recent (seconds/minutes)

     • Elements: non‑zero and increasing as polling resumes.

3. Diagnostics / Health Check

   • Re-run diagnostics.

   • Any previous warning like
     “Machines from Engines table that are absent in OrionServers table: APE01/APE02/APE03”
     should now refer only to legacy/orphan data, which has been cleaned or is no longer relevant to current rows.

If all of the above checks pass and nodes assigned to those APEs are updating statistics, the issue is resolved.