Device Identification Manager

How NetCrunch works out what a device is, why that answer decides how much of your monitoring happens by itself, and how to teach it about hardware it does not yet recognize.

why-it-matters

Why Device Classification Matters

NetCrunch does not treat a monitored address as an anonymous endpoint. It works out what the device is — its class, vendor, model and operating system — and that answer is used far more widely than most people expect.

Monitoring applies itself: Many predefined Monitoring Packs are assigned automatically on the basis of device type. Classify a device correctly and the monitoring appropriate to it arrives without anyone choosing it. See Monitoring Packs and Automatic Monitoring and Organizing.
Operating system monitoring depends on it: If a device is not set to a Windows type, Windows monitoring will not start — and is not even offered. The same holds for the other supported systems. Classification is not cosmetic; it gates whole monitoring engines.
Views organize themselves: Views and groupings follow device type, so an accurate classification produces a network map that sorts itself out.
The atlas reads correctly: Each device type carries an icon. A map where everything is a generic box is a map nobody reads carefully.
Your inventory gets better: Class, vendor and model are part of what NetCrunch records about every node. See NetCrunch as an Inventory Database.

The practical consequence is worth stating plainly: an unclassified device is both visibly wrong and quietly under-monitored. The icon shows a question mark, which people notice, and the automatic monitoring packs never arrive, which people do not.

Open a network map and look for question-mark icons. Each one is a device NetCrunch could be monitoring better.

how-classified

How a Device Gets Classified

Most of the time, automatically:

SNMP devices are recognized from their sysObjectID, or from sysDescr where the object ID alone is not distinctive. NetCrunch ships with a large set of definitions covering common hardware. See Monitoring SNMP Devices.
Windows machines, and anything else drawn from Active Directory, are typed from what the directory reports.

Everything else has to be set by hand — or taught to NetCrunch once, so that it and every device like it are recognized from then on. That is what this page is for.

the-manager

The Device Identification Manager

SettingsResourcesOtherDevice Identification Manager

Definitions are organized on two tabs:

Devices: Device Classes, each holding its Models. This is the hardware side — a class such as a switch or a UPS, and the specific models within it.
Systems: Operating systems, kept separately, because what a device is and what it runs are different questions.

Selecting a class, model or system shows its Identification Patterns — the evidence NetCrunch matches a real device against.

What a Definition Holds

Classification: The Class, Vendor and Model the match resolves to.
Operating System and OS Version: What the device runs, where that is part of the identity.
Sys Object ID: The SNMP object identifier. This is the precise match — a correct value identifies the hardware exactly.
Text Pattern / Description: Matched against sysDescr, for devices that a single object ID does not distinguish, or that report the same object ID across a family.

Each definition also carries the icon used for that device on maps and in views.

adding

Teaching NetCrunch a New Device

Three routes, and the first is almost always the right one:

New Identification from node: Start from a device you already monitor. NetCrunch reads what that node actually reports and builds the definition from it, which avoids transcribing an object ID by hand — the single most common way these definitions go wrong.
New Device Identification: Create a definition from scratch when you have the identifying values but no node to read them from.
Add Pattern: Extend a definition that already exists. Reach for this when a device is nearly recognized — right class, wrong model, or a firmware revision reporting something slightly different — rather than creating a competing definition.

A wrong Sys Object ID does not produce an error. It produces a device that is never recognized, which looks exactly like a device that has no definition at all. If a new definition does not take effect, check the object ID against what the device actually reports before assuming the definition is not being read.

when-to-use

When You Would Come Here

A device shows a question-mark icon and is not picking up monitoring packs
Something is classified, but as the wrong class or model
You have hardware the shipped definitions do not cover — new, niche, or in-house
A vendor has changed what a model reports, and an existing definition no longer matches

See Configuration Tips for the wider set of checks worth running after a discovery.

classificationdevice classdevice identificationdevice typediscoveryiconidentification patternmodelmonitoring packssnmpsysdescrsysobjectidvendor