Meraki Switches Showing Incorrect Status Due to Duplicate Entries in Orchestrators_Nodes

7/20/2026 10:22 PM

7/20/2026 10:33 PM

Issue

After configuring Meraki device monitoring via the SolarWinds Meraki Orchestrator (api.meraki.com), one or more of the following symptoms are observed:

• Meraki switches or access points show Status=Up (green) in SolarWinds while the Meraki Dashboard reports them as offline

• In the Orchestrator Inventory view, the Status column shows the correct Meraki API status (for example, offline) while the node status icon on the same row shows green (Up)

• No Node Down events are generated for the affected devices despite the Meraki Dashboard reporting them as offline

The following error is found in the Collector.Service.log on the polling engine handling the Meraki Orchestrator node:

ERROR SolarWinds.Collector.FlowProcessingPool - Processing failed for
PollingPlanID=Declarative.OrchestratorCentric.DeviceNode.ResponseTime.Polling,
DescriptionID=N.DP.StatusAndResponseTime.Meraki_Device.REST:<OrchestratorNodeID>
System.ArgumentException: An item with the same key has already been added.
at SolarWinds.Orion.Core.Orchestrators.Collector.Node.Declarative.
ResultsDistributors.DeclarativeOrchestratorCentricDeviceNodeResultsDistributor
.Distribute()

Network Performance Monitor

Cause

The Meraki Orchestrator uses an orchestrator-based approach for status and response time polling. A single polling job collects device status data for all nodes managed by the orchestrator via the Meraki API endpoint /organizations/${OrganizationId}/devices/statuses. The data processing stage then distributes the result to each individual child node, writing the Meraki API status to the SolarWinds node status fields using the following mapping:

• online → Up

• offline → Down

• alerting → Warning

• dormant → Down

When duplicate DeviceID entries exist in the Orchestrators_Nodes table — where the same Meraki DeviceID is mapped to two different SolarWinds NodeIDs under the same OrchestratorNodeID — the distribution stage attempts to build a dictionary keyed by DeviceID. The duplicate key causes System.ArgumentException: An item with the same key has already been added to be thrown, aborting the entire distribution. No status update is written to any child node for that poll cycle. The affected nodes retain their last successfully written status indefinitely.

Duplicate entries in Orchestrators_Nodes commonly occur in the following scenarios:

• A Meraki device is replaced in the Meraki Dashboard but the old device entry is not removed from SolarWinds before the new device is rediscovered via the Orchestrator — the old DeviceID-to-NodeID mapping persists alongside the new one

• Meraki devices are discovered using API-only polling and the built-in deduplication mechanism cannot match the newly discovered API-only node to an existing SNMP node (due to differences in sysname, IP, or MAC address), resulting in a second node entry being created for the same physical device

Log File Locations

The following log files are relevant for troubleshooting this issue on the affected polling engine. On environments with a custom installation path (for example, D:\SolarWinds, substitute the custom path for %ProgramData%\SolarWinds\ accordingly.

Collector Service log:

%ProgramData%\SolarWinds\Collector\Logs\Plugins\Declarative.OrchestratorCentric.DeviceNode.ResponseTime.Polling.log

Orchestrators Business Layer log:

%ProgramData%\SolarWinds\Logs\Orion\Orchestrators.Meraki\Orchestrators.Meraki.BusinessLayer.log

JobEngine worker log:

%ProgramData%\SolarWinds\JobEngine.v2\Logs\SWJobEngineWorker_v2022_2_{GUID}_[{THREAD}]_SolarWinds.Orion.Orchestrators.Meraki.Collector.log

Resolution

Two resolution options are provided below. Review both options and select the one appropriate for your environment before proceeding.

WARNING — Read Before Proceeding (Both Options): A full database backup is required before making any changes under either option. Do not proceed without a confirmed backup.

	Option A — Recreate Orchestrator	Option B — Remove Duplicates via SQL
Historical Data	Lost — all child node history, events, and alerts are removed	Preserved — no nodes or historical data are deleted
Monitoring Downtime	Yes — all Meraki nodes absent until rediscovery completes	No — polling continues during SQL changes
Risk	High — irreversible without database restore	Medium — direct database modification; scoped DELETE required
Complexity	Low	Medium — requires SQL access and Support engagement
Confirmed Resolution	Yes — confirmed from cases	Yes — confirmed from cases

---

Option A — Recreate the Meraki Orchestrator (Historical Data Will Be Lost)

WARNING — Data Loss Risk: Deleting the Meraki Orchestrator parent node removes all child nodes discovered under it from SolarWinds, including all associated historical polling data, events, and alerts. This action is irreversible without a database restore. Confirm with your team that all affected Meraki nodes and their monitoring history are documented before proceeding.

WARNING — Monitoring Downtime Required: All Meraki-discovered nodes will be temporarily absent from SolarWinds monitoring from the time the Orchestrator is deleted until rediscovery completes. Plan this activity during a scheduled maintenance window.

Step 1 — Optional: Confirm Duplicate DeviceID Entries

Before proceeding, optionally run the following read-only SQL query to confirm duplicate DeviceID entries exist in the Orchestrators_Nodes table:

-- 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.

SELECT OrchestratorNodeID, DeviceID, COUNT(*) AS DuplicateCount
FROM Orchestrators_Nodes
GROUP BY OrchestratorNodeID, DeviceID
HAVING COUNT(*) > 1
ORDER BY OrchestratorNodeID, DeviceID

If one or more rows are returned, duplicate DeviceID entries are confirmed and the resolution below applies.

Step 2 — Take a Full Database Backup (Required)

Take a full backup of your SolarWinds database before making any changes.

Step 3 — Delete the Meraki Orchestrator Node (Downtime Begins)

• Log in to the SolarWinds Platform Web Console as an administrator.

• Navigate to Settings > Manage Nodes.

• Locate the affected Meraki Orchestrator parent node (api.meraki.com).

• Click the node to open the Node Details page.

• In the Management widget, click Delete Node.

• Confirm the deletion. All child Meraki nodes discovered under this orchestrator will be removed from SolarWinds.

Step 4 — Re-Add the Meraki Orchestrator

• Navigate to Settings > Manage Nodes and click Add a Node.

• In Polling Method, select Orchestrators: API.

• Under Orchestrators, select Cisco Meraki Devices.

• Provide the API Key generated in the Cisco Meraki Dashboard.

• If multiple organizations are registered, click Get Organization List and select the appropriate organization.

• Ensure the following options are selected as required for your environment:

  • Enable polling for Wireless devices

  • Enable polling for SD-WAN metrics

• Review and adjust device properties as needed.

• Click OK, Add Node.

• Allow the Orchestrator rediscovery to complete. All Meraki devices will be re-added as fresh entries with no duplicate DeviceID mappings in Orchestrators_Nodes.

Step 5 — Verify Resolution

After Step 4 is complete, monitor the Collector.Service.log on the polling engine handling the Meraki Orchestrator node for the next poll cycle (approximately 5 minutes) and confirm the ArgumentException: An item with the same key has already been added error no longer appears for the affected OrchestratorNodeID. The affected nodes should begin reflecting the correct Meraki API status on the next successful poll cycle.

---

Option B — Remove Duplicate Entries via SQL (Historical Data Preserved)

This option removes only the duplicate DeviceID entries from the Orchestrators_Nodes table without deleting the Orchestrator parent node or any child nodes. Historical polling data, events, and alerts are fully preserved. No monitoring downtime is required.

Step 1 — Take a Full Database Backup (Required)

Take a full backup of your SolarWinds database before making any changes.

Step 2 — Identify Duplicate DeviceID Entries (Read-Only)

Run the following query to confirm which DeviceIDs have more than one NodeID mapping under the same OrchestratorNodeID:

-- 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.

SELECT OrchestratorNodeID, DeviceID, COUNT(*) AS DuplicateCount
FROM Orchestrators_Nodes
GROUP BY OrchestratorNodeID, DeviceID
HAVING COUNT(*) > 1
ORDER BY OrchestratorNodeID, DeviceID

Step 3 — Identify Which NodeID Is the Duplicate (Read-Only)

For each duplicate DeviceID returned in Step 2, run the following query to determine which NodeID is orphaned and which is active:

-- 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.

SELECT ON2.OrchestratorNodeID, ON2.DeviceID, ON2.NodeID,
       ND.Caption, ND.IP_Address, ND.Status
FROM Orchestrators_Nodes ON2
LEFT JOIN NodesData ND ON ON2.NodeID = ND.NodeID
WHERE ON2.DeviceID IN (
    SELECT DeviceID FROM Orchestrators_Nodes
    GROUP BY OrchestratorNodeID, DeviceID
    HAVING COUNT(*) > 1
)
ORDER BY ON2.DeviceID, ON2.NodeID

Review the results:

• NodeIDs returning NULL for Caption, IP_Address, and Status are orphaned — they no longer exist in Orion.Nodes and are safe to remove from Orchestrators_Nodes

• NodeIDs returning identical Caption and IP_Address for the same DeviceID are true duplicate nodes — confirm which NodeID is the correct one to retain before removing the other via the web console

Step 4 — Remove Orphaned Entries 

WARNING — Take a full database backup immediately before executing this statement. Replace all placeholder values with the exact DeviceIDs, OrchestratorNodeID, and orphaned NodeIDs confirmed from Step 3. 

-- 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.DELETE FROM Orchestrators_Nodes
WHERE DeviceID IN ('<DeviceID_1>', '<DeviceID_2>')
AND OrchestratorNodeID = <OrchestratorNodeID>
AND NodeID IN (<OrphanedNodeID_1>, <OrphanedNodeID_2>)

Step 5 — Remove True Duplicate Nodes (Web Console — No SQL Required)

For DeviceIDs where both NodeIDs exist in Orion.Nodes with identical Caption and IP address, identify and remove the duplicate node via the web console:

• Navigate to Settings > Manage Nodes

• Locate the duplicate node entries by searching for the Caption confirmed in Step 3

• Confirm which NodeID has no historical data, alerts, or monitoring dependencies associated with it

• Open the duplicate node's Node Details page and click Delete Node

• After deletion, re-run the Step 2 query to confirm the duplicate entry is no longer present in Orchestrators_Nodes

Step 6 — Verify Resolution

After Steps 4 and 5 are complete, monitor the Collector.Service.log on the polling engine handling the Meraki Orchestrator node for the next poll cycle (approximately 5 minutes) and confirm the ArgumentException: An item with the same key has already been added error no longer appears for the affected OrchestratorNodeID. The affected nodes should begin reflecting the correct Meraki API status on the next successful poll cycle.

---

Prevention

To prevent duplicate entries from recurring:

• When replacing a Meraki device in the Meraki Dashboard, delete the old node from SolarWinds before triggering a new Orchestrator device discovery. This prevents the old DeviceID-to-NodeID mapping from persisting in Orchestrators_Nodes alongside the new device entry.

• When migrating Meraki nodes from SNMP polling to API-only polling, verify that the API-only discovery deduplication correctly matches the new API-only node to the existing SNMP node before completing the migration. If deduplication fails (due to sysname, IP, or MAC address mismatch), a duplicate node will be created. Confirm there are no duplicate entries in Orchestrators_Nodes after the migration is complete using the Step 1 query above.