July 23, 2026

FIX | Duplication and inconsistency in the display of meter readings on the Lexmark XC9235

The meter readings for some Lexmark XC9235 equipment were being displayed inconsistently, with some equipment failing to display them at all and others showing duplicate entries. In addition, there was processing logic that prevented the complete removal of duplicate meter readings, resulting in the persistence of inconsistent data.

The problem occurred during the reading and processing of equipment meters, especially in scenarios where multiple meters of the same type were returned by the device or when the removal rule was partially triggered.

The inconsistency occurred in the layer responsible for processing device reading data, directly impacting the structure of the returned and stored meters, regardless of the specific firmware version, as evidenced by equipment with the same or different versions exhibiting distinct behaviors.

To fix this, we adjusted the logic responsible for removing duplicate meters, eliminating the break statement that prematurely closed processing after the first removal. This ensured that all duplicate meters are properly processed, preventing inconsistencies in data display and storage.

FIX | Failure to discover printers that exclusively support SNMP v1

Equipment that supported only SNMP v1 was not identified during the printer search process, specifically at the point when validation was performed to determine whether the discovered equipment was compatible with monitoring.

The inconsistency occurred in the call responsible for validating the device type during discovery, where NDD Orbix sent requests using only SNMP v2, even in scenarios where the equipment supported only SNMP v1, resulting in the exclusion of that device from the discovery process.

To fix this, we adjusted the device validation logic to ensure proper support for SNMP v1 during the discovery process. The call responsible for identifying printers now correctly considers equipment that responds only via SNMP v1, eliminating the previous limitation caused by the exclusive use of SNMP v2. As a result, compatible devices are now correctly identified and included in monitoring.

FIX | Failure in the print queue for printers with an SNMP read community other than public

When installing a print queue for a printer whose read community was not public, the queue appeared as offline in print management.

Upon receiving the print queue installation notification, the service attempts to communicate with all SNMP configurations registered in the portal.

When any of them returns a successful response, that configuration is linked to the print queue.

If none of them return successfully, SNMP is disabled for the queue, while print functions remain active.

FIX | Duplicate entries for the same printer when using the SNMP v3 configuration

• Location: Print queues > Printers

When creating a print queue and assigning an IP address to a printer with SNMP v3 configuration active, duplicate entries for the same device containing invalid or inconsistent values might be generated in addition to the correct entry.

To fix this, we replaced the logic for discovering and validating SNMP OIDs, adopting the same approach used in the NDD - Printer Monitor service.

FIX | Printer identification was performed more often than necessary

After the print queue was created, sending a print job would trigger the printer identification process. This identification, used to determine which printer was associated with the print queue, was occurring more often than necessary.

To fix this, we adjusted the printer identification process so that it does not occur more often than necessary. We also reimplemented the process so that it runs asynchronously, without depending on a print job. As a result, the printer is now identified as soon as the queue is created or modified, or when the service starts. This way, the saving takes effect starting with the very first print job.

APPROVAL | Approved printers

FIX | Incorrect prints during discovery of thermal printers on the network

In the service, when configuring a unicast search or setting static IP addresses to find thermal printers on the network, if the IP address being checked belonged to a printer from another manufacturer and the SNMP configuration was incorrect, preventing communication, a second validation was performed.

In this validation, the service attempted to communicate via TCP, sending a command on port 9100 to verify whether the equipment was manufactured by Honeywell. However, some printer manufacturers ended up printing this command.

To fix this, we replaced the TCP communication on port 9100 with an HTTP request to view the printer’s web page. As a result, these unintended printouts no longer occur.

IMPROVEMENT | Expansion of computer type identification

We have expanded the coverage of computer types identified by the agent based on the official SMBIOS list to correctly recognize the equipment's chassis type and correct incorrect classifications.

FIX | Failure to generate disk usage percentage

On some computers, the portal failed to correctly calculate the disk usage percentage during the agent’s automatic monitoring routine.

To fix this, we implemented processing improvements to process scenarios involving partial data.