NetXMS Support Forum

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.

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!

I'm encountering a localization inconsistency in the NetXMS Web UI (Docker-based deployment).

Currently, even after explicitly selecting English in the user settings, several parts of the interface (menus and specific strings) continue to be displayed in Portuguese (Brazil), which is my browser's default locale.

It seems that the "Auto-Detect" logic—which is great as a default for new sessions—is still taking precedence over the manually selected language in the user profile.

The expected behavior should be:

• Default: Auto-detect based on Browser Locale (Accept-Language header).
• Override: If a user manually selects a language (e.g., English), this choice must take absolute priority, and no fallback to the browser locale should occur for any UI element.

What I've tried so far:

• Forcefully selecting "English" in settings.
• Logging off (user) and restarting the "netxms-web" container.
• Testing in Incognito mode (where it sometimes works, confirming the browser locale influence).

Environment:

• NetXMS Version: 6.1.1
• Platform: Docker / Web UI
• Client Browser: Chrome/Edge (Locale: pt-BR)

Thanks for your help!

I am deploying NetXMS via Docker using the official deployment-example/compose.yaml from netxms/docker (commit 55e823c), but replacing the built-in PostgreSQL container with an existing MariaDB instance.

During the database initialization phase, I encountered two related issues:

1. The server/files/dbinit.sh script has "pgsql" strictly hardcoded (nxdbmgr init pgsql), which forces PostgreSQL initialization regardless of the DBDriver configured in /etc/netxmsd.conf or environment variables.

2. If we manually override /dbinit.sh on init container to initialize MariaDB (nxdbmgr init mariadb), the process fails because nxdbmgr looks for a specific dbinit_mariadb.sql file in a directory that does not exist in the Docker image.

Environment:

- NetXMS Version: 6.1.1 (Build 6.1-452-gc20a8a4247)
- Deployment: Docker (using official deployment-example/compose.yaml)
- Database: MariaDB 10.11

Steps to Reproduce:

1. Setup the deployment using the example compose.yml file, pointing /etc/netxmsd.conf to a MariaDB database (DBDriver = mariadb.ddr).
2. Override /dbinit.sh (entrypoint) on init container via bind mount to execute nxdbmgr init mariadb.
3. Start the init container.

Error Log (when using mariadb driver for init):

NetXMS Database Manager Version 6.1.1 Build 6.1-452-gc20a8a4247
Initializing database...
ERROR: Cannot load SQL command file /usr/share/netxms/sql/dbinit_mariadb.sql
Database initialization failed
Unable to determine database syntax
Note: I verified inside the container that the directory /usr/share/netxms does not exist on the NetXMS Server Docker image.

If I change the /etc/netxmsd.conf  to use mysql instead (nxdbmgr init mysql), the database initializes perfectly, even though I am using a MariaDB container:

NetXMS Database Manager Version 6.1.1 Build 6.1-452-gc20a8a4247
Initializing database...
IMPORTANT: Generated admin password
   Login:    admin
   Password: PaSsWd
Please save this password - it will not be shown again.
You will be required to change it on first login.
Database initialized successfully
Suggested Fixes:

1. Dynamic Driver Selection: Update /dbinit.sh to dynamically read the database driver from a Docker environment variable (e.g., NETXMS_DB_DRIVER) or directly from /etc/netxmsd.conf, falling back to pgsql only if nothing is set. Changing nxdbmgr init pgsql to simply nxdbmgr init allows the utility to dynamically deduce the driver from /etc/netxmsd.conf, as intended by the documentation.
2. Template Mapping: Either include the dbinit_mariadb.sql template in the image build process or alias the mariadb initialization argument to use the mysql SQL template internally, since the schema structure is identical.