Managing Objects

This guide covers common tasks for creating, finding, and operating on objects in NetXMS.

For an overview of the object tree, classes, and status model, see Object Model. For object property and permission details, see Object Properties Reference.

Object Creation

Most object types are created by right-clicking a parent object in the object tree and selecting Create > <object type>. The available types depend on the parent object — for example, nodes can be created under containers, and interfaces can be created under nodes. Some objects are created automatically: interfaces and subnets during configuration polls, access points from wireless controllers, and business service instances from prototypes.

Node Creation

Nodes can be created manually from the management client:

  1. Right-click a container in the object tree

  2. Select Create > Node

  3. Enter the node Name and Primary host name or IP address, or check Node without IP address

  4. Optionally configure:

    • Alias

    • Protocol ports (agent, SNMP, EtherNet/IP, Modbus TCP, SSH) and Modbus unit ID

    • SSH login and password

    • Options such as Communication through external gateway, Create as unmanaged object, Enter maintenance mode immediately, or disabling specific protocols for polls

    • Per-protocol proxy nodes (agent, SNMP, EtherNet/IP, Modbus, ICMP, SSH, MQTT, web services)

    • Zone (when zoning is enabled)

  5. Click OK

The new node is picked up by the regular polling schedule; its first configuration poll detects interfaces, capabilities, and supported protocols. Agent and SNMP credentials are not entered in this dialog — they are taken from the configured default credentials or set later in the node properties.

Automatic Creation via Discovery

NetXMS can automatically discover and create node objects. See Network Discovery for details.

Object Browser Filter

The object browser includes a filter bar (toggle with Ctrl+F2, Cmd+F2 on macOS) that filters the object tree in real time as you type.

By default, the filter searches by object name using * and ? wildcards. Use a prefix character to search by other criteria:

Prefix Searches Example

(none)

Object name

web* — all objects starting with "web"

>

IP address (prefix match)

>192.168.1. — objects with IP addresses starting with "192.168.1."

^

IP address (exact match)

^192.168.1.10 — object with exactly this IP address

#

Object ID

#1234 — object with ID 1234

/

Object comments

/maintenance — objects with "maintenance" in comments

@

Zone (ID or name)

@5 — objects in zone with ID 5; @London — objects in zone with "London" in the name

Additional browser options (available via the view menu):

  • Show hidden objects — include objects marked as hidden in the tree

  • Show child object count — display the number of child objects next to object names

  • Drag and drop — select drag-and-drop behavior for tree objects (Controlled by server, Enable, Confirm, or Disable)

Finding Objects

The Find Object view (Tools perspective) provides two search modes for locating objects across the entire system.

Filter

The Filter tab offers a GUI-based search with the following criteria:

  • Text search — match by object name using normal text, wildcard patterns (*, ?), or regular expressions

  • Class filter — limit results to specific object classes (Node, Interface, Container, etc.)

  • Zone filter — limit results to specific zones (available when zoning is enabled)

  • IP range — find objects with IP addresses within a specified range

Object Query

Object queries provide a powerful server-side search mechanism using NXSL expressions. This is useful for finding objects based on complex criteria that cannot be expressed with simple filters.

To execute an object query:

  1. Open Tools > Find Object

  2. Select the Query tab

  3. Enter an NXSL expression that returns true for matching objects

The expression is evaluated for each object the current user has read access to. The implicit variable $object represents the object being evaluated.

Example: find all Linux nodes in critical status
($object.type == 2) && ($object.platformName ~= "linux") && ($object.status == 4)
Example: find all nodes with custom attribute "location" set to "DC1"
($object.type == 2) && ($object.getCustomAttribute("location") == "DC1")
Example: find all interfaces with speed over 1 Gbps
($object.type == 3) && ($object.speed > 1000000000)

Object Query "with" Syntax

Object queries support an extended syntax using a with block to define additional computed columns that appear alongside the query results. This is useful for displaying DCI values, calculated metrics, or other derived data in the results table.

There are three equivalent ways to add computed columns:

Syntax 1: "with" block (recommended)
with
  criticalCount = {
    return GetDCIValue($object, FindDCIByDescription($object, "Critical Alarms"));
  },
  warningCount = {
    return GetDCIValue($object, FindDCIByDescription($object, "Warning Alarms"));
  }
$object.status > 0 && !$object.isInMaintenanceMode
Syntax 2: Global variables
if ($object.status == 0 || $object.isInMaintenanceMode)
  return false;
global criticalCount = GetDCIValue($object, FindDCIByDescription($object, "Critical Alarms"));
global warningCount = GetDCIValue($object, FindDCIByDescription($object, "Warning Alarms"));
return true;
Syntax 3: Returning a hash map
if ($object.status == 0)
  return false;
return {
  "criticalCount" => GetDCIValue($object, FindDCIByDescription($object, "Critical Alarms")),
  "warningCount" => GetDCIValue($object, FindDCIByDescription($object, "Warning Alarms"))
};

In all three cases, the variables criticalCount and warningCount become available as additional columns in the result table.

Predefined Object Queries

Frequently used object queries can be saved as predefined queries and managed centrally. Predefined queries are available to all users in the Find Object view’s Query tab under the Saved queries list.

To manage predefined queries, open the Object Queries view in the Configuration perspective. Each predefined query has:

  • Name — display name shown in the saved queries list

  • Description — optional description of the query’s purpose

  • Source — NXSL query script (same syntax as ad-hoc queries, including with blocks)

  • Input fields — optional user-prompted parameters accessible in the script via the $INPUT map

Input fields allow creating reusable queries with variable parameters. For example, a query that finds nodes by location can define a "Location" input field, and the script references it as $INPUT["Location"].

Predefined queries can also be referenced by ID from dashboard Object Query elements and the REST API.

Managing predefined queries requires the Manage object queries system access right.

Object Type Constants

Value Object Class

0

Generic

1

Subnet

2

Node

3

Interface

4

Network

5

Container

6

Zone

7

Service Root

8

Template

9

Template Group

10

Template Root

11

Network Service

12

VPN Connector

13

Condition

14

Cluster

15

Business Service Prototype

16

Asset

17

Asset Group

18

Asset Root

19

Network Map Root

20

Network Map Group

21

Network Map

22

Dashboard Root

23

Dashboard

24

Dashboard Template

27

Business Service Root

28

Business Service

29

Collector

30

Circuit

31

Mobile Device

32

Rack

33

Access Point

34

Wireless Domain

35

Chassis

36

Dashboard Group

37

Sensor

38

Cloud Domain

39

Resource

40

Traffic Observer

41

Observation Point

Common object properties available in queries:

Property Description

$object.type

Object class numeric ID (2=Node, 3=Interface, 5=Container, etc.)

$object.name

Object display name

$object.status

Numeric status (0=Normal through 8=Testing)

$object.ipAddr

Primary IP address (Node objects)

$object.platformName

Platform name as reported by agent

$object.snmpVersion

SNMP version configured (0=none, 1=v1, 2=v2c, 3=v3)

$object.isAgent

True if NetXMS agent is detected

$object.isSNMP

True if SNMP is available

$object.zone.uin

Zone UIN (unique identification number)

$object.getCustomAttribute("name")

Get value of a custom attribute

See NXSL Reference for the complete list of available object properties and methods.

Object Operations

Manage and Unmanage

Setting an object to unmanaged stops all polling, data collection, and event generation for it (SNMP traps, syslog messages, and Windows events from unmanaged nodes are still processed when the SNMP.Traps.ProcessUnmanagedNodes server configuration variable is enabled). Child objects inherit the unmanaged state — unmanaging a container also stops monitoring of all objects within it.

To change managed state: right-click the object and select Manage or Unmanage.

For details on how unmanaged state affects object status and behavior, see Unmanaged State.

Maintenance Mode

Put an object into maintenance mode during planned maintenance windows to prevent alarms and notifications while polling and data collection continue:

  • Right-click the object and select Maintenance > Start maintenance…​, optionally entering a comment

  • To end maintenance, select Maintenance > End maintenance

  • Maintenance > Start maintenance for period enters maintenance immediately and schedules the exit automatically

  • Maintenance > Schedule maintenance…​ creates a one-time or recurring maintenance window

Maintenance mode requires the Control maintenance mode access right on the object. See Maintenance Mode for what exactly happens to events while maintenance is active, and Scheduling for recurring maintenance windows.

Bind and Unbind

Objects can be bound to (placed under) multiple parents:

  • Right-click a container and select Bind

  • Select the objects to add

Unbinding removes the object from that parent without deleting it. An object is only deleted when it has no remaining parents.

When removing a template or cluster from an object (or an object from a template/cluster), a dialog prompts for how to handle DCIs created by the template or cluster:

  • Remove DCIs from node — deletes all DCIs created from this template on the target objects

  • Unbind DCIs from template — keeps the DCIs on the target objects as standalone items, no longer linked to the template

Delete

Deleting an object removes it from all parents and deletes all associated data (DCIs, collected values, alarms).

Object deletion is irreversible. All historical data for the object is permanently removed.

Decommission

Instead of immediate deletion, a node can be decommissioned using the right-click menu item Decommission…​. Decommissioning performs the following:

  1. Sets the node to unmanaged state, which stops all polling and data collection

  2. Schedules the node for automatic deletion by the housekeeper after the specified expiration time

  3. Optionally clears IP addresses from the node and all its interfaces

A decommissioned node cannot be set back to managed state. Decommissioned nodes are shown in the object tree with a [Decommissioned] label and grey text color.

This requires the same access rights as deleting a node (Delete permission).

Move

Move an object from one container to another. This is equivalent to binding to the new parent and unbinding from the old one.

Force Poll

Manually trigger a specific poll type (status, configuration, topology, etc.) on a node without waiting for the scheduled interval.

Right-click the node and select Poll > <poll type>.

Automatic Bind

Containers, collectors, clusters, templates, dashboards, dashboard templates, network maps, business services, and circuits support automatic binding rules. These rules use NXSL scripts to determine whether objects should be automatically bound (added) or unbound (removed).

To configure automatic binding:

  1. Open the object properties

  2. Navigate to the Automatic Bind Rules tab

  3. Enable the automatic bind option — its label varies by class, e.g. Automatically bind objects selected by filter to this container or Apply this template automatically to objects selected by filter — and optionally the corresponding unbind/remove option

  4. Write an NXSL script that returns true to bind or false to unbind

The auto-bind script is evaluated during configuration polls of each node. To control auto-bind separately from configuration polls, use the server configuration variable Objects.AutobindOnConfigurationPoll (enabled by default) and the dedicated auto-bind polling interval configured via Objects.AutobindPollingInterval.

Business services have two independent auto-bind filters (Object Auto Bind and DCI Auto Bind), each with separate enable/disable settings for binding and unbinding; all other classes have a single filter.

The following variables are available in auto-bind scripts:

Variable Description

$object

The candidate object being evaluated for binding.

$node

The node object (if the candidate is a node).

$container

The object performing automatic binding (set for every auto-bind source class, not only containers).

$template

The template object (when evaluating template auto-apply).

$dashboard

The dashboard object (when evaluating dashboard auto-bind).

$map

The network map object (when evaluating map auto-bind).

$service

The business service object (when evaluating service auto-bind).

$dci

The DCI being evaluated (set for business service DCI auto-bind filters).

$isCluster

Boolean indicating whether the candidate object is a Cluster object.
Example: auto-bind all Linux nodes to a container
return $node.platformName ~= "linux";
Example: auto-bind nodes with a specific custom attribute
return $node.getCustomAttribute("tier") == "production";

VNC Remote Control

The Remote Control option appears in the context menu for nodes where a VNC server is detected. This feature requires:

  1. Enable TCP proxy on the agent running on the remote node by setting EnableTCPProxy = yes in the agent configuration file, then restart the agent

  2. Run a Configuration Poll on the target node so NetXMS detects VNC availability

If no agent is installed on the remote node but VNC is present, a proxy agent can be used instead. Configure EnableTCPProxy = yes on the NetXMS server agent or on the agent acting as the zone proxy.

Access requirements:

  • The user must have the Initiate TCP proxy sessions system access right

  • The user must have Control access rights to the target node

The target VNC server may need to allow loopback connections, and firewall settings may need to be adjusted.