NetXMS Support Forum

Regarding AI invocation - I've tried to check qwen3.6-35b-a3b model via OpenRouter, but looks like they don't have providers with tool calling support. From your screenshot it seems that tool call is not recognized and interpreted as part of an answer. Are you sure that runner or service you are using actually follows Open AI API?

Is there really only one row in SNMP walk result? If yes, try to do separate walks on 1.3.6.1.2.1.17.7.1.2.2.1.3 and 1.3.6.1.2.1.17.7.1.2.2.1.2 - there should be more entries. Also try walk on 1.3.6.1.2.1.17.4.3.1.3

Начиная с 5.x, для веба нужна 17 джава

tomcat 10.1.52
openjdk  11.0.30
After updating to 6.1.1, I encountered an error in the WebUI when trying to open a page.
It would be advisable to explicitly indicate which versions are required somewhere, for example on the download page. Is that the issue?

Description:
When attempting to localize/translate the NetXMS interface, I noticed that the items under the "Tools" menu for Infrastructure objects cannot be translated.



Upon further investigation, it appears these strings are hard-coded in the database under the `object_tools.tool_name` column, rather than being routed through the standard localization resource files.

NetXMS Version: 6.1.1
Operating System / Environment: Linux (Docker) [Server] / macOS [Client]

Steps to Reproduce:

• Configure the NetXMS console/WebUI to use a translated language profile.
• Navigate to the Infrastructure tree.
• Select on a node or object and navigate to the Tools context menu.
• Observe the language of the tool names.

Expected Behavior:
The names of the tools should support localization, either by mapping the database entries to localization keys or by allowing translations to be defined within the object tool configuration itself.

Actual Behavior:
The tool names are pulled directly from `object_tools.tool_name` in the database, bypassing the UI translation mechanism and forcing them to display in their original string format regardless of the user's language settings.

I would like to share some findings.

1. I managed to get the synchronization working at https://github.com/eduardomozart/netxms/tree/copilot/refactor-preferencestore-logic, but it synchronizes a series of preferences to the server, such as window size settings, which might not be the same when running NXMC on different computers. Also, some properties (like HTTP_* preferences for HTTP proxy settings on SWT) shouldn't be synced to the server and kept offline instead.

2. I started a second approach at https://github.com/eduardomozart/netxms/tree/copilot/refactor-preferencestoresync-logic aiming to synchronize only the `preferencepages`. However, some modules (like `networkmap`) don't seem to extend `PropertyPage` class, making it difficult to identify which preferences should be synced.

Currently, I'm thinking about creating a `PreferenceStoreServer` class and letting module developers choose which one to use. This way, using `PreferenceStore` saves locally (SWT) or in a cookie (RWT) as it is today, while using `PreferenceStoreServer` saves it as a custom user attribute.

Probably the solution is between those two. Using a secondary object would require merging both stores to make it usable with minimum impact to NXMC, as keeping different objects would make the PrefereceStore difficult to maintain and read. Maybe using the same PreferenceStore but first check if there's a custom user attribute with the same name than preference and if there's merge it with the PreferenceStore during startup and provide a way for modules to specify when saving a preference as a custom user attribute during save would be a better approach.

3. Another alternative would be to provide a Docker volume for the stateDir and map it to the netxms-web container. Actually, stateDir mounts to /tmp/jetty-<host>-<port>-<context>-<virtualhost>-<randomdigits>/state/nxmc.preference.<cookie_name_uuid>. Since the RWT preferencestore is kept there, user preferences are currently lost whenever the container is restarted.

Persisting this directory would bring other benefits as well, as I believe it also stores custom themes and important caches, such as 'Theme files', 'Map tile cache', and 'MIB file downloads'. The problem is even persistent this temp folder would be erased every time the .war file is updated.

4. Another alternative for the web client (RWT) would be using the browser's localStorage to save nxmc.preferences. Since the desktop client (SWT) simply stores its preferences in $HOME/.nxmc4—which is theoretically accessible by any other application running in the same user context—I assume this file doesn't contain highly sensitive data, making localStorage a perfectly viable and safe option. This would fix the nxmc.preferences persistence for RWT, but wouldn't fix the issue that preferences aren't synced per-user with the server.

Thank you very much for your reply.

Hi,

FDB related code was not changed, it still handles type 6 (secure) in a same way as type 3. Could you please show screenshot of "FDB" page for problematic switch, output of server debug command "show fdb <id>" (replace <id> with actual switch object ID), and result of SNMP walk on 1.3.6.1.2.1.17.7.1.2.2.1?

Best regards,
Victor

1. Summary / Problem Statement

Currently, the NetXMS Management Console applies language, date, and time format settings globally across the entire system. While this works for single-site organizations, it creates a significant usability bottleneck in MSP environments and multinational companies. Having a single global locale forces operators in different countries—or clients accessing a multi-tenant environment—to adapt to a foreign language or an unfamiliar date/time format (e.g., MM/DD/YYYY vs. DD/MM/YYYY).

2. Use Case / Business Impact

• MSP Operations: A centralized NOC might be located in one country (e.g., Brazil, requiring pt-BR and DD/MM/YYYY), while tier-support teams or clients accessing the console are based in the US or Europe.
• Incident Response: When viewing alarms, events, or performance data for a specific Node or Device, misinterpreting the timestamp due to an unfamiliar global date format can lead to errors in SLA calculations or delayed incident resolutions.
• Client Portal: In a multi-tenant setup, clients logging into the console expect to see the interface in their native language and local time format.

3. Proposed Solution

Decouple the locale and time format settings from the global configuration and introduce a hierarchical preference system:

• User Level: Add options within the User Profile settings allowing individual users to override the global default and set their preferred Language, Timezone, and Date/Time format.
• System/Group/Tenant Level (Optional but ideal): Allow administrators to define default locale settings per User Group or Tenant, ensuring that when a new operator from a specific region is created, they automatically inherit the correct regional settings.

4. Expected Behavior

When a user logs into the Management Console, the system should render the UI language and format all timestamp fields (Alarms, Event Logs, DCI Data, Node properties) based on the specific settings attached to their user account, falling back to the global configuration only if no user-specific preference is defined.

5. Alternatives Considered

Currently, the only alternative is deploying separate NetXMS instances per region, which defeats the purpose of centralized monitoring and drastically increases administrative and infrastructure overhead.

Is your feature request related to a problem? Please describe.
Currently, installing and maintaining the NetXMS Management Console on Windows requires manually downloading the installer from the official website and running through the setup wizard. While this method works perfectly fine, it bypasses the modern package management ecosystem that many Windows administrators now rely on for seamless software deployment and automated workstation updates.

Describe the solution you would like
I would like to request official support for installing the NetXMS client console on Windows using Winget (Windows Package Manager). This could be achieved by submitting and maintaining a package manifest for the NetXMS Management Console in the official Microsoft community repository (https://github.com/microsoft/winget-pkgs).

This would allow Windows users to simply open their terminal and run `winget install NetXMS.Console` (or a similar identifier) to get the software up and running natively. It would also allow IT professionals to easily keep the management client updated alongside their other administrative tools using `winget upgrade`.

Describe alternatives you have considered
The current alternative is performing a manual installation using the executable from the NetXMS website or deploying it via custom enterprise scripts. However, having an official Winget package would greatly simplify the deployment and update processes, especially for users who use automated scripts to provision their IT management workstations.

Additional context
Since the NetXMS client console already has a Homebrew package available for macOS users (https://formulae.brew.sh/cask/netxms-console), adding Winget support would provide excellent parity for Windows users. It would significantly increase accessibility and make version management much easier across different operating systems. Thank you for considering this enhancement and for the great work on the project!