Windows servers, that have SNMP enabled, and are scanned with an SNMP only behaviour, may get reclassified as Computers, Printers or Routers. The same would happen with a normal discovery, but where an iLO card or similar has SNMP open but not WMI/WinRM. If a Windows Discovery is then done, a new duplicate Windows Server CI will be created.

The 3 OIDs are:

OidClassifierOperatorTableManufacturerModelActive Network SwitchIsIP Switch [cmdb_ci_ip_switch]Microsoft
TRUE [cmdb_ci_computer]MicrosoftWindows CETRUE Network PrinterIsPrinter [cmdb_ci_printer]MicrosoftWindows 6.1TRUE

For example, SNMP - Classify probe may return this from a Windows Server:

<sysName oid="" type="SnmpOctetString"></sysName>
<sysUpTime oid="" type="SnmpTimeTicks">516748039</sysUpTime>
<sysDescr oid="" type="SnmpOctetString">
Hardware: Intel64 Family 6 Model 47 Stepping 2 AT/AT COMPATIBLE - Software: Windows Version 6.3 (Build 9600 Multiprocessor Free)
<sysObjectID oid="" type="SnmpObjectId">.</sysObjectID>

"" is one of the OIDs added in Orlando, which overrides any logic in the sensor, and makes the device a Network Printer class instead. Existing Windows Server CIs may get reclassified as Printers after upgrading to Orlando.

All SysObjectID OID values starting are generic OIDs for various Microsoft operating systems and versions. Any embedded devices with these OIDs have been implemented wrong, without a proper vendor/model specific unique OID. Any Servers with these OIDs shouldn't be discovered via SNMP as that is not supported, so none of these OIDs should be allowed in the OID table.

Steps to Reproduce

  1. Discover Windows Servers in a version Prior to Orlando
  2. Upgrade to Orlando, where thousands of OIDs were added.
  3. With a SNMP Only discovery behaviour, scan a Windows Server that has SNMP enabled.
  4. It will be reclassified as an IP Switch, Computer or Printer depedning on which specific microsoft OID it has.
  5. Data in fields that existed in the correct class, but not in the new class, will be lost.


This problem is currently under review. You can contact ServiceNow Technical Support or subscribe to this Known Error article by clicking the Subscribe button at the top right of this form to be notified when more information will become available.

As a workaround, deactivate these 3 OID records:
https://<instance name>

Note: Do not Delete these records, or they will just reappear with your next patch upgrade.

If this has already happened to you, the CIs can be re-classified back to the original Class, which is probably Windows Server [cmdb_ci_win_server]. You will then need to resolve the duplicates that had been created, usually by deleting the most recently created CI for each pair.

Related Problem: PRB1408983

Seen In

SR - IRM - GRC Profiles - Madrid 2019 Q2
SR - IRM - SIG Assessment Legacy - Madrid 2019 Q1
SR - IRM - SIG Questionnaire - New York 2019 Q3
SR - IRM - Vendor Risk Management - Madrid 2019 Q1
SR - ITOM - Fundamentals Istanbul Jakarta Kingston r1 - v5.99.6
SR - Security - Integration Framework - Madrid 2019 Q2
SR - Security - Support Common - Madrid 2019 Q2
SR - Security - Support Orchestration - Madrid 2019 Q2
SR - SIR - Security Incident Response - Madrid 2019 Q2
SR - SIR - Store SecOps Setup Assistant - Madrid 2019 Q2
SR - SIR - Store Threat Core - Madrid 2019 Q2
SR - SIR - Store Trusted Security Circles Client - New York 2019 Q3
SR - SIR - Threat intelligence - New York 2019 Q3
SR - VR - Qualys - New York 2019 Q3
SR - VR - Rapid7 - London 2019 Q2 v.6.2.1
SR - VR - Vulnerability Response - New York 2019 Q3

Fixed In

Orlando Patch 7

Associated Community Threads

There is no data to report.

Article Information

Last Updated:2020-09-13 14:58:26