1 server polls as Windows server & the other as ESX server - Why?

I have 2 servers running Server 2016 on Dell bare metal VxRails hosts. In Solarwinds 01 is listed a Windows server with usual data, but 02 is listed as an ESX Server with all the VxRail info rather than Windows info. Both look to have the same Properties listed under "Edit Properties" - any idea why this could be?

Find more posts tagged with

properties

solarwinds

Polling

Accepted answers

All comments

robert777

Good Day.

I'm not an expert in VMWare monitoring. But I have some experience working with the VxRails.

VxRails are enclosures that contain 'sleds', that is, plug-in servers ('server on a card'). The VxRail enclosures mount a flavor of PostGRE SQL internally. In general you would poll the VxRail enclosures similar to a Linux server.

Unless... you poll your VMWare system with a VCenter polling account, in which case SolarWinds collects VxRail information via the VCenter polling.

Assuming you have one of the 'sleds' built as a Windows server you should expect 2 nodes in SolarWinds - one for the Windows server and one for the VxRail enclosure. I have found that, for a Windows server built on a VxRail card, SolarWinds will often reads the hardware type as 'VMWare ESX' or 'VxRail'.

Anyone on the thread feel free to expand or correct as needed. Cheers.

zennifer

Try #2 - I have had many lovely experiences troubleshooting my virtual environment. The one thing I can say about SolarWinds, she does not lie! I am glad I saved most of my reply on a word doc, as I stared on this reply to you a couple of hours ago!

Likely Causes:

Incorrect Polling Method Assigned (Despite Appearances): This is still the prime suspect. Even if the "Edit Properties" page looks the same, the effective polling method for each node might be different. SolarWinds determines the polling method during the initial discovery and can sometimes default incorrectly or be manually changed without being immediately obvious in all property views.
Multiple IP Addresses/Hostnames Associated with the Node: It's possible that the SolarWinds node for "02" has multiple IP addresses or hostnames associated with it, and one of them might be resolving to the underlying ESXi host's management IP or hostname, causing SolarWinds to poll via SNMP.
SNMP Configuration on the Windows VM (Less Likely): While you'd typically use WMI or Agent for Windows, if SNMP is accidentally configured and enabled within the Windows Server 2016 VM with VxRail-related information, SolarWinds might be picking that up. This is unusual for a standard Windows Server setup.
Discovery Rules or Polling Engines: If you have specific discovery rules or are using multiple polling engines in SolarWinds, there might be a rule incorrectly identifying "02" or a specific polling engine attempting to manage it via SNMP.
Data Corruption in SolarWinds Database (Less Likely): In rare cases, the SolarWinds database might have inconsistent data for the two nodes, leading to this misinterpretation.

Refined Troubleshooting Steps:

Force Repoll with Specific Method:
- Navigate to the node details page for "02" in SolarWinds.
- Click "Poll Now" and specifically select "WMI" or the "SolarWinds Agent" as the polling method. Observe if the data changes to Windows-specific metrics. If it does, the default polling method for this node is likely the issue.
Examine All Associated IPs/Hostnames:
- In the "Edit Properties" page for "02," carefully review all listed IP addresses and hostnames. Ensure only the Windows Server 2016 IP and hostname are present. Remove any entries related to the VxRail host.
Check Assigned Polling Engine:
- If you have multiple polling engines, verify which engine is assigned to monitor "02." Ensure it's the same engine used for your other Windows servers.
Investigate SNMP Configuration on the VM:
- Log in to the Windows Server 2016 VM ("02").
- Open "Services" (services.msc).
- Check if the "SNMP Service" is running. If it is, disable it temporarily and then force a repoll in SolarWinds. If the data changes, then SNMP was the culprit.
Review Discovery Rules:
- Go to "Settings" > "All Settings" > "Discovery Central" (or similar, depending on your SolarWinds version).
- Review your discovery jobs and rules to see if any might be incorrectly identifying "02" as an ESX server based on certain criteria (e.g., a specific service running).
Check Database Records (Advanced):
- Caution: This is an advanced step and should be done with care or with SolarWinds support guidance.
- Using Database Manager, directly query the Nodes table and examine the ObjectSubType and Pollers columns for both "01" and "02." Look for any discrepancies that might indicate different polling profiles are associated with them.
Restart SolarWinds Services (If Necessary):
- As a last resort, restarting the SolarWinds services on your polling engine server can sometimes resolve inconsistencies.

By focusing on the actual polling method being used and ensuring the correct IP/hostname association, you should be able to pinpoint why SolarWinds is misidentifying your Windows Server 2016 VM.