Object Properties Reference

Primary communication settings for the node.

The node’s zone is not changed here — use the Change zone…​ object context menu action.

The Communication page has sub-pages for protocol-specific settings:

Polling behavior settings for the node:

Per-object polling intervals are not configured on this page — use SysConfig: prefixed custom attributes.

Capabilities the node is expected to have: NetXMS agent, SNMP, EtherNet/IP, Modbus TCP, and SSH. Marking a capability as expected prevents the server from dropping it after repeated communication failures.

TCP and UDP ports that the server must not connect to. Each entry is a single port number (1-65535) and a protocol: TCP, UDP, or TCP/UDP. Port ranges are not supported.

For a node, the server checks the list before opening a connection and does not open it if the port is listed. This applies to NetXMS agent (direct connections only, not agent tunnels), SNMP, EtherNet/IP, and Modbus TCP connections, and to SSH data collection. A node whose agent or SNMP port is listed is not polled over that protocol. Active network discovery does not probe ports listed for the zone being scanned.

The list contains TCP and UDP port numbers; it does not control which network interfaces are polled.

The list is inherited from parent Container, Collector, Cluster, and Subnet objects and from the zone; defining a local list stops inheritance. This page is also available on zone, container, and subnet objects.

The Proxy nodes list: zone proxy nodes used for communication with nodes in this zone.

The Communications page has sub-pages for zone-wide default credentials:

NXSL filter scripts that control automatic template application and removal. When enabled, templates are automatically applied to matching objects during automatic binding polls. See Automatic Bind.

Virtual IP addresses and associated resources tracked by the cluster. Used for resource migration monitoring between cluster member nodes.

Interconnect networks used for intra-cluster communication.

NXSL filter scripts for automatic binding of nodes to the cluster.

Select DCIs whose values are passed to the condition script as $1, $2, etc.

Configure activation and deactivation events, the event source object, and the status values for active and inactive states.

NXSL script that determines whether the condition is active or inactive.

Layout and configuration of dashboard widgets (charts, tables, maps, status indicators, etc.). See Dashboard Elements Reference.

Configure which object context is passed to dashboard elements for context-sensitive dashboards.

Name template (with macro support) for dashboards created from this template.

NXSL filter script that controls which objects this dashboard template applies to.

Starting nodes for automatic topology map generation.

Generic appearance page (present on most object classes): name shown on network maps, presentation image, and drill-down object.

Object display options (display mode, status indication), default link options (routing algorithm, color, line style), and other map display options. The layout algorithm is chosen from the map view toolbar, not from a property page.

Canvas type, map size, and the background image, geographic map, or color for the map.

NXSL script to filter which objects appear on the map.

NXSL script for custom link appearance based on link properties.

Configure object context for context-sensitive map display.

NXSL filter script controlling automatic creation of object-based checks.

NXSL filter script controlling automatic creation of DCI-based checks.

Business service prototypes additionally have an Instance Discovery page.

Rack Height (in rack units), unit Numbering scheme (Bottom to top or Top to bottom), and the Front side only option.

Patch panels, filler panels, organisers, and PDUs — non-monitored elements that occupy rack units.

Sensor-specific properties: device class, gateway node, MAC address, Modbus unit ID, device address, vendor, model, and serial number.

Custom attributes can be set:

Inheritance is controlled per attribute by the Inheritable flag (a checkbox in the attribute edit dialog), not by naming convention. When an inheritable attribute is set or changed on a parent object, the value is automatically propagated (pushed) to all child objects in the tree.

An inherited attribute on a child object shows its source object in the Origin column. If a child object redefines an inherited attribute locally, the local value takes precedence and the attribute is marked as redefined. If the same inheritable attribute arrives from more than one distinct parent object, it is marked as a conflict — even when the values are identical.

Custom attributes with names starting with a dot (.) are hidden from the management client by default. They can be viewed and updated if Show hidden custom attributes is enabled in the management client preferences.

The dot prefix only affects UI visibility — it has no effect on inheritance or any other server-side behavior.

Custom attributes with names starting with $ can only be set from NXSL scripts on the server side. The management client cannot create or modify $-prefixed attributes.

Use $-prefixed attributes when you need to:

Nodes provide the following read-only virtual attributes. They are not stored as custom attributes and never appear in the attribute list, but reading an attribute with this name (from NXSL or with the %{name} macro) returns the node’s SSH communication settings, unless a custom attribute with the same name exists:

They are useful, for example, in object tools that start an SSH client with the node’s credentials. SSH credentials themselves are configured on the node’s Communication > SSH property page, not with these attributes.

Custom attributes with the AgentEnv: prefix inject environment variables into the NetXMS agent running on the node.

Setting AgentEnv:MY_VAR to some_value on a node pushes the environment variable MY_VAR=some_value to the node’s agent. Variables are synchronized on every agent connection and whenever the attribute value changes. Removing the custom attribute removes the corresponding environment variable from the agent; however, deleting the last remaining AgentEnv: attribute is not pushed to the agent until another change triggers synchronization.

The agent’s AcceptedEnvironmentVariables configuration parameter controls which variable names are accepted. By default only NX_* and NETXMS_* patterns are accepted. Only works when the server has master or control access to the agent.

The following custom attributes alter SNMP-related behavior on node objects:

Attributes with the SysConfig: prefix override global server configuration variables for a specific object. The value in the custom attribute takes precedence over the global setting for that object and its children.