Classification of Servers as Printers

[chandra_ym]

We scanned an IP range sometime back, discovered servers and populated the CMDB classes. Now when I scan the same IP (this range has servers, network devices and workstations) and for an already discovered server, if a WMI classification fails due to some reason (credential issue or timeout), discovery proceeds to SNMP classify stage. Then it classifies it as printer and changes the class from Windows server to Printer. OIDs returned in SNMP Classify does not match any OIDs in the discovery_snmp_oid table.

My question is why does discovery classifies a server as a printer if credentials fails during discovery? Is this expected behavior ?

[Patrick DeCarl1]

Chandrashekar,

What ports are open during shazzam for this device IP?

[miguelrios]

Hi,

Yes, this is the regular Discovery Behavior,

OOTB discovery has some port probes defined for each discovery and each one has a classification priority, so if the first one fails discovery continues with the next one and so on, you can take a look into your "Port Probes" module to see the order the ports are being check and also you can define new behavior if you need to restrict the number of port each discovery should be checking,

Reference:

Port probes

Discovery behaviors

Regards.

[VivekSattanatha]

Hi Chandra,

Seems SNMP port 161 is opened on those servers, Due to some printer configurations on the server, Discovery will match the classification criteria as "Printing as true". To avoid the issue you can add one more classification criteria in "Standard Network Printer" classifier as "sysdescr Does Not Contain "Windows". Otherwise, you can disable SNMP port on those servers or disable SNMP service on the servers.

Regards,

Vivek

[robertgeen]

Hello,

The reason this is happening is that when SNMP classification happens there is a script that runs to tries to assign a role to the device. This role falls into the category of whether it switches, routes, prints, or powers. More then likely because nothing else is matching at the OID level (which would tell it to use a specific classifier) it is matching on something in the sysDescr and assigning it the role of Printing. I've seen this happen before and generally it fixes itself once you get WMI access fixed. You could look deeper at the classification script includes that do that check and possibly tweak them to not assign Printing based on some other criteria.

The issue at the core here is that ServiceNow discovery isn't meant to discover server infrastructure with SNMP and as such some of the generic checks in the SNMP are actually giving you false positives and marking it as a printer. Fix your WMI credentials and it should auto correct it but if you want to fix the symptom you will have to dig into the script includes to somehow override it.