<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title><![CDATA[Feature Requests]]></title><description><![CDATA[Ideas and feature requests for NetXMS, in English or Russian — идеи и предложения можно писать на английском или русском.]]></description><link>https://forum.netxms.org/category/8</link><generator>RSS for Node</generator><lastBuildDate>Fri, 13 Nov 2026 06:50:41 GMT</lastBuildDate><atom:link href="https://forum.netxms.org/category/8.rss" rel="self" type="application/rss+xml"/><pubDate>Thu, 30 Jul 2026 13:31:54 GMT</pubDate><ttl>60</ttl><item><title><![CDATA[Sub Zone]]></title><description><![CDATA[Thanks for the reply and information
]]></description><link>https://forum.netxms.org/topic/8427/sub-zone</link><guid isPermaLink="true">https://forum.netxms.org/topic/8427/sub-zone</guid><dc:creator><![CDATA[richard21]]></dc:creator><pubDate>Thu, 30 Jul 2026 13:31:54 GMT</pubDate></item><item><title><![CDATA[Geo map Icons and objects]]></title><description><![CDATA[Objects already have a "presentation image" property that is meant to control exactly this. It turns out it's currently ignored when the object is rendered on the geo map, so you always get the default icon there. I've opened an issue to fix it — once done, your custom presentation image will be used on geo maps as well. Thanks for the report.
]]></description><link>https://forum.netxms.org/topic/8416/geo-map-icons-and-objects</link><guid isPermaLink="true">https://forum.netxms.org/topic/8416/geo-map-icons-and-objects</guid><dc:creator><![CDATA[alk]]></dc:creator><pubDate>Wed, 08 Jul 2026 23:46:29 GMT</pubDate></item><item><title><![CDATA[Per-User Locale and Date/Time Preferences in Management Console]]></title><description><![CDATA[Filed as https://github.com/netxms/netxms/issues/3480 for design discussion.
Option 3 is the right shape, but one thing needs settling before you build on it: user custom attributes will not work as a backing store for ordinary users. CMD_UPDATE_USER is handled by ClientSession::updateUser() and requires SYSTEM_ACCESS_MANAGE_USERS, with no exemption for modifying your own account — password change and 2FA binding both special-case userId == m_userId, custom attributes do not. A non-admin operator saving their own date format gets access denied.
So the per-user store needs a server-side change either way: a self-update path restricted to own custom attributes, or a separate per-user key/value store with its own command and access check. That choice determines the client API, so it should come before more work on the merge logic.
Beyond that, option 3 needs an explicit rule for which preferences are machine-local and which are per-user. Without one, every preference added later is a judgement call and the split rots — your HTTP_* and window geometry cases are exactly what such a rule has to answer.
Your points 3 and 4 are a separate problem, worth splitting off: the RWT store sits in the servlet container state directory, so it is lost on container restart and on .war update. Persisting that directory, or moving the store out of it, fixes preference loss in the web client on its own, with none of the per-user work — and it covers theme files, map tile cache and MIB downloads at the same time.
]]></description><link>https://forum.netxms.org/topic/8379/per-user-locale-and-date-time-preferences-in-management-console</link><guid isPermaLink="true">https://forum.netxms.org/topic/8379/per-user-locale-and-date-time-preferences-in-management-console</guid><dc:creator><![CDATA[alk]]></dc:creator><pubDate>Sat, 02 May 2026 15:52:28 GMT</pubDate></item><item><title><![CDATA[Support NetXMS Management Console installation on Windows via Winget]]></title><description><![CDATA[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!
]]></description><link>https://forum.netxms.org/topic/8378/support-netxms-management-console-installation-on-windows-via-winget</link><guid isPermaLink="true">https://forum.netxms.org/topic/8378/support-netxms-management-console-installation-on-windows-via-winget</guid><dc:creator><![CDATA[cold]]></dc:creator><pubDate>Sat, 02 May 2026 14:52:39 GMT</pubDate></item><item><title><![CDATA[Номера портов на вкладке Ports не совпадают с номерами интерфейсов]]></title><description><![CDATA[Сабж. Вводят в заблуждение - предлагаю убрать, оставив только квадратики пустые. Либо, что лучше, если возможно и позволит ширина квадратиков - заполнять автоматически giXX / %interface name%, как в всплывающем меню собственно.

[image: state-status.png]
]]></description><link>https://forum.netxms.org/topic/8343/номера-портов-на-вкладке-ports-не-совпадают-с-номерами-интерфейсов</link><guid isPermaLink="true">https://forum.netxms.org/topic/8343/номера-портов-на-вкладке-ports-не-совпадают-с-номерами-интерфейсов</guid><dc:creator><![CDATA[eugene1]]></dc:creator><pubDate>Mon, 02 Mar 2026 08:50:41 GMT</pubDate></item><item><title><![CDATA[Показания скорости у сетевых интерфейсов если его статус DOWN - отображать 0]]></title><description><![CDATA[Собственно предложение в топике. Сейчас если сетевой интерфейс в операционном статусе DOWN, то есть нет физического линка - система отображает в строке Speed видимо последнее значение. Это путает и не логично. Лучше если бы отображало в этом случае  0 принудительно, независимо от прочитанного по SNMP значения.
В данном случае на приложенной картинке специфичный коммутатор фирмы Planet, он видимо некорректно сам возвращает значение скорости, когда link down. Возможно такое поведение есть еще у каких либо промышленных коммутаторов.
Версия 5.2.8

[image: Безымянный2.png]
]]></description><link>https://forum.netxms.org/topic/8332/показания-скорости-у-сетевых-интерфейсов-если-его-статус-down-отображать-0</link><guid isPermaLink="true">https://forum.netxms.org/topic/8332/показания-скорости-у-сетевых-интерфейсов-если-его-статус-down-отображать-0</guid><dc:creator><![CDATA[eugene1]]></dc:creator><pubDate>Mon, 23 Feb 2026 06:47:33 GMT</pubDate></item><item><title><![CDATA[Weathermap like map view and clarity]]></title><description><![CDATA[Hi team,
I wanted to inquire if we are expecting any improvements to the map view in NetXMS to enhance clarity, similar to what we see in WeatherMap.
For reference, please check the map views in both NetXMS and WeatherMap. In WeatherMap, we get clear visibility into how much traffic is coming from which direction, with different colors for each direction based on traffic percentage. However, in NetXMS, it shows only one link color, making it unclear whether it's representing the inbound or outbound direction—this is handled much more clearly in WeatherMap. Additionally, data source labels cannot be placed differently in NetXMS, which further creates confusion regarding traffic direction.
It would be great if we could incorporate similar features to improve usability. Please let me know your thoughts or if there's any timeline for such enhancements.
dhaval lad

[image: weathermap_map.jpg]
[image: netxms_map.jpg]
]]></description><link>https://forum.netxms.org/topic/8316/weathermap-like-map-view-and-clarity</link><guid isPermaLink="true">https://forum.netxms.org/topic/8316/weathermap-like-map-view-and-clarity</guid><dc:creator><![CDATA[dhavalslad]]></dc:creator><pubDate>Fri, 06 Feb 2026 04:20:25 GMT</pubDate></item><item><title><![CDATA[SAML Authentication]]></title><description><![CDATA[Hi,
Yes, it's on the roadmap, but it might end up in the enterprise build -- we are not sure yet.
]]></description><link>https://forum.netxms.org/topic/8259/saml-authentication</link><guid isPermaLink="true">https://forum.netxms.org/topic/8259/saml-authentication</guid><dc:creator><![CDATA[alk]]></dc:creator><pubDate>Thu, 18 Sep 2025 17:02:41 GMT</pubDate></item><item><title><![CDATA[Zones / Multitenant]]></title><description><![CDATA[it would be really useful if you could nest Zones e.g have a Root Zone for a Customer then Child Zones for each site. or create multiple 'Entire Network' at the root level one for each customer.
this would also be very useful for assigning permission
]]></description><link>https://forum.netxms.org/topic/8250/zones-multitenant</link><guid isPermaLink="true">https://forum.netxms.org/topic/8250/zones-multitenant</guid><dc:creator><![CDATA[richard21]]></dc:creator><pubDate>Wed, 03 Sep 2025 15:27:28 GMT</pubDate></item><item><title><![CDATA[More configuration options for the "Dial" type Gague in Dashboards]]></title><description><![CDATA[Not sure if this has been requested before, but the Dial Gauge is pretty rigid in its configuration with regards to color and values.  
You can only have three color zones, and the color zones have to be, yellow, green, red in that order.   That assumes that something on the left/bottom is bad, something in the top/middle is good, and something far to the right is really bad.   This works fine for things like pressure, RPMs, etc but does not work very well for things like battery voltages where "8" could be just as bad as "15" for a 12V battery where both values need to be in the red.  A battery dial gauge really should be red, orange, green, orange, red.   (or possibly red, orange, green, red)
I think it would be much more useful to allow us to specify the number of color zones, and in which order.  This could be done with a table, kind of like how we can add multiple Dashboard Elements.  You click Add, specify the minimum and maximum values for the range you are creating, and then choose the color.   The item at the top would be the left/bottom color zone on the gauge.  The next item/range would be the next color zone on the gauge, etc  As a sanity check, you could require that the second color zone HAS to start from where the previous zone ends by pre-populating and graying out the field so it cant be changed.  This way, you couldn't overlap the end of color zone 1 with a value of like 11, and then start color zone 2 at 10.     I thought about having the ability to reorder these, but then I think you'd have to give up the sanity check...and that's probably not necessary anyhow since you can adjust the values and colors on each to match your needs.
]]></description><link>https://forum.netxms.org/topic/8238/more-configuration-options-for-the-dial-type-gague-in-dashboards</link><guid isPermaLink="true">https://forum.netxms.org/topic/8238/more-configuration-options-for-the-dial-type-gague-in-dashboards</guid><dc:creator><![CDATA[cbwecomm]]></dc:creator><pubDate>Sun, 17 Aug 2025 16:03:52 GMT</pubDate></item><item><title><![CDATA[Merging / Combining DCI's]]></title><description><![CDATA[Templates are GREAT, but, occasionally we realize after the fact there is a "better" way to build something, or we have a new use case that requires us to split DCI's defined in templates into new templates.  
Currently, we can keep historic data by removing the template, but not removing the DCIs however this isn't really ideal since the graphs are wrong anyhow.  
I was thinking it would be pretty nice if a template would automatically merge two DCI's based on identical matching names and other fields.   This could be enabled or disabled somehow in the configuration, just in case someone didn't want this behavior.     I think the DCI's would need to match identically, 100%... as would be the case when you copy or move DCI's between templates. 
If something doesn't match, then they wouldn't merge and a new one would be created.   If that happened accidentally, say for instance if you copied a DCI to a new template and then changed the name and then applied it.... then you could fix this by manually merging the DCI's (after you fixed the name change on the old one), by multi-selecting the two of them, right clicking, and then going to "Actions &gt; Merge" or something like that.  
[image: Untitled.png]
Merging DCI's manually through the menu would do the same thing as the automatic method; it would check to ensure 100% of the configuration fields were the same, and then move the oldest set of data into the newer DCI.   A warning prompt for Yes/No and brief explanation of what will happen wouldn't be a bad idea either.  
Just for simplicity, you could only merge 2 DCIs at a time.  
I'm sure I could poke around in the database and do this in psql... but I'd rather there be an official NetXMS supported method haha 
]]></description><link>https://forum.netxms.org/topic/8230/merging-combining-dci-s</link><guid isPermaLink="true">https://forum.netxms.org/topic/8230/merging-combining-dci-s</guid><dc:creator><![CDATA[cbwecomm]]></dc:creator><pubDate>Mon, 04 Aug 2025 02:51:57 GMT</pubDate></item><item><title><![CDATA[Integration with VCS]]></title><description><![CDATA[Hi,
git-enabled configuration might be nice, but then comes a question what should be included like templates and other stuff, so this may end up in serious development effort and the resources are limited.
What can be done currently - there's nxshell api that allows to do everything that management client can do. So you can import and export script library scripts (and get list which scripts are in the system).
]]></description><link>https://forum.netxms.org/topic/8212/integration-with-vcs</link><guid isPermaLink="true">https://forum.netxms.org/topic/8212/integration-with-vcs</guid><dc:creator><![CDATA[Filipp Sudanov]]></dc:creator><pubDate>Fri, 04 Jul 2025 14:29:34 GMT</pubDate></item><item><title><![CDATA[CISCO-WLC driver to recognize modern Cisco 9800 WLCs]]></title><description><![CDATA[Hello,
I have uploaded a walk from .1 (.txt) and the mib-files (.zip):
C9800-L-universalk9_wlc.17.12.05.SPA.bin-v2.zip
wlc-C9800-L-F-K9-walk.txt
I have edited the walk to remove company name and domains.
the data is from 2-Unit-Failover environment with currently 40 active AP. Also showing 86 rogue access points from the neighborhood.
Please keep the data confidential. Thanks.
best...
Detlev
]]></description><link>https://forum.netxms.org/topic/8194/cisco-wlc-driver-to-recognize-modern-cisco-9800-wlcs</link><guid isPermaLink="true">https://forum.netxms.org/topic/8194/cisco-wlc-driver-to-recognize-modern-cisco-9800-wlcs</guid><dc:creator><![CDATA[dj]]></dc:creator><pubDate>Tue, 10 Jun 2025 18:01:03 GMT</pubDate></item><item><title><![CDATA[Option to group software inventory by package]]></title><description><![CDATA[@filipp-sudanov said in Option to group software inventory by package:

Grouping by software package looks cumbersome - e.g. some software packages tend to have version number in the name, e.g. jdk-17... and jdk-21..., could be desirable to join them somehow... So unless it's a sponsored development we don't have resources available to go into this.
But, to mention, software package information is accessible from NXSL, so it might be that for some usecases you can just script something.

ah yes, I see that would complicate things a lot. fair point with NXSL.
@filipp-sudanov said in Option to group software inventory by package:

For expansion - I've registered a ticked to add expand/collapse buttons: https://track.radensolutions.com/issue/NX-2745

Thanks, that would basically remove the need for grouping by software (the idea was to click once to expand rather than hunting through all nodes clicking).   
So if you 1) filter up the top then 2) expand all, you can then 3) quickly export without too much clicking on each node.
]]></description><link>https://forum.netxms.org/topic/8151/option-to-group-software-inventory-by-package</link><guid isPermaLink="true">https://forum.netxms.org/topic/8151/option-to-group-software-inventory-by-package</guid><dc:creator><![CDATA[normalcy]]></dc:creator><pubDate>Thu, 10 Apr 2025 04:28:38 GMT</pubDate></item><item><title><![CDATA[Add RADIUS attribute]]></title><description><![CDATA[Implemented in upcoming 5.2. Both are configurable via server configuration parameters RADIUS.NASIdentifier and RADIUS.ServiceType.
]]></description><link>https://forum.netxms.org/topic/8107/add-radius-attribute</link><guid isPermaLink="true">https://forum.netxms.org/topic/8107/add-radius-attribute</guid><dc:creator><![CDATA[victor]]></dc:creator><pubDate>Fri, 14 Feb 2025 12:49:48 GMT</pubDate></item><item><title><![CDATA[(Option to) Don't interpolate missing data]]></title><description><![CDATA[There's a feature request for this in our bug tracker: https://track.radensolutions.com/issue/NX-1826
It's sort of low priority, but will be implemented as some point
Currently you may use scripting to collect some specific value if there is no reply, e.g. -10, then it will be visible on the chart.
]]></description><link>https://forum.netxms.org/topic/8106/option-to-don-t-interpolate-missing-data</link><guid isPermaLink="true">https://forum.netxms.org/topic/8106/option-to-don-t-interpolate-missing-data</guid><dc:creator><![CDATA[Filipp Sudanov]]></dc:creator><pubDate>Tue, 11 Feb 2025 20:10:13 GMT</pubDate></item><item><title><![CDATA[Offical NetXMS containers on dockerhub with updated installation documentation]]></title><description><![CDATA[https://github.com/netxms/docker/
]]></description><link>https://forum.netxms.org/topic/8090/offical-netxms-containers-on-dockerhub-with-updated-installation-documentation</link><guid isPermaLink="true">https://forum.netxms.org/topic/8090/offical-netxms-containers-on-dockerhub-with-updated-installation-documentation</guid><dc:creator><![CDATA[alk]]></dc:creator><pubDate>Fri, 10 Jan 2025 06:55:07 GMT</pubDate></item><item><title><![CDATA[Hope Add Feature of Push Reporting JAR to Server From Client]]></title><description><![CDATA[@alk said in Hope Add Feature of Push Reporting JAR to Server From Client:

@hmjvaline said in Hope Add Feature of Push Reporting JAR to Server From Client:

New NXMC already has mib file upload feature ,
There is no need to pull the mib file from the server side
another The jar file used in the report server also needs to be added to the server.
If it can be uploaded directly to the server through nxmc on the client, it will become very convenient to maintain or update.
;D ;D ;D

Just use built-in file manager to delete jar file and upload new version to definitions directory.

Are you talking about installing AGNET on the server, using filemgr.nsm in the agent, 
and using 「 file manager」 command on the node? Other commands, 
such as 「upload file 」on NODE, throw the server's files to the agent client, 
and others like There is no way to see the JAR file I have uploaded to C:\NetXMS\var\nxreportd\definitions using TOOL-&gt;UPLOAD FILE TO SERVER or CONFIRUATION-&gt;SERVER FILE MANAGER.
]]></description><link>https://forum.netxms.org/topic/8058/hope-add-feature-of-push-reporting-jar-to-server-from-client</link><guid isPermaLink="true">https://forum.netxms.org/topic/8058/hope-add-feature-of-push-reporting-jar-to-server-from-client</guid><dc:creator><![CDATA[hmjvaline]]></dc:creator><pubDate>Sun, 10 Nov 2024 11:59:29 GMT</pubDate></item><item><title><![CDATA[IOS App]]></title><description><![CDATA[Not implemented at the moment - the Objects tab covers the Infrastructure tree only. Noted as a feature request, no date on it.
]]></description><link>https://forum.netxms.org/topic/8057/ios-app</link><guid isPermaLink="true">https://forum.netxms.org/topic/8057/ios-app</guid><dc:creator><![CDATA[alk]]></dc:creator><pubDate>Thu, 07 Nov 2024 13:51:11 GMT</pubDate></item><item><title><![CDATA[Add support for keyboard shortcut]]></title><description><![CDATA[Hi, this is fixed in version 5.1 which should be available soon.
]]></description><link>https://forum.netxms.org/topic/8046/add-support-for-keyboard-shortcut</link><guid isPermaLink="true">https://forum.netxms.org/topic/8046/add-support-for-keyboard-shortcut</guid><dc:creator><![CDATA[uldis]]></dc:creator><pubDate>Tue, 15 Oct 2024 07:32:32 GMT</pubDate></item><item><title><![CDATA[Source node override in template or with NXSL/custom attribute]]></title><description><![CDATA[There's still no easy way. Theoretically there could be an option to set source node from nxsl (and may be some hook script to set this right when template is applied). And there are many other things which can not be done from nxsl, so there's a lot of work to improve that.
So yes, it's possible to configure Script DCIs and do data collection that way.
Or another possible workaround is to have nxshell script that is executed as server's action and that script would change source node.
]]></description><link>https://forum.netxms.org/topic/8029/source-node-override-in-template-or-with-nxsl-custom-attribute</link><guid isPermaLink="true">https://forum.netxms.org/topic/8029/source-node-override-in-template-or-with-nxsl-custom-attribute</guid><dc:creator><![CDATA[Filipp Sudanov]]></dc:creator><pubDate>Sun, 22 Sep 2024 07:17:45 GMT</pubDate></item><item><title><![CDATA[Option to use properties file for NXShell]]></title><description><![CDATA[Hi.
I created and issue you can track: https://track.radensolutions.com/issue/NX-2593
]]></description><link>https://forum.netxms.org/topic/8025/option-to-use-properties-file-for-nxshell</link><guid isPermaLink="true">https://forum.netxms.org/topic/8025/option-to-use-properties-file-for-nxshell</guid><dc:creator><![CDATA[zev]]></dc:creator><pubDate>Wed, 18 Sep 2024 04:57:00 GMT</pubDate></item><item><title><![CDATA[Remove files by "File Delivery" agent policy]]></title><description><![CDATA[Yes, for time being it's file delivery policy, not file removal policy. Could be nice thing, but development resources are limited and there are more important features to work on, so probably only with sponsored development.
It's probably possible to add files with 0 size - this will at least delete contents of files.
It's possible to configure action on agent that would do deletion of files.
And, also requires quite some effort - nxshell / java app can use file manager api to talk to agent nodes and to the deletion.
]]></description><link>https://forum.netxms.org/topic/8001/remove-files-by-file-delivery-agent-policy</link><guid isPermaLink="true">https://forum.netxms.org/topic/8001/remove-files-by-file-delivery-agent-policy</guid><dc:creator><![CDATA[Filipp Sudanov]]></dc:creator><pubDate>Mon, 19 Aug 2024 14:16:32 GMT</pubDate></item><item><title><![CDATA[Option to check database connection]]></title><description><![CDATA[Please, add button to installer to check database configuration (to verify database connection).
]]></description><link>https://forum.netxms.org/topic/7991/option-to-check-database-connection</link><guid isPermaLink="true">https://forum.netxms.org/topic/7991/option-to-check-database-connection</guid><dc:creator><![CDATA[saksham.adyso]]></dc:creator><pubDate>Fri, 02 Aug 2024 10:36:53 GMT</pubDate></item><item><title><![CDATA[Save window size and state]]></title><description><![CDATA[Will be included in next relese 5.1
]]></description><link>https://forum.netxms.org/topic/7981/save-window-size-and-state</link><guid isPermaLink="true">https://forum.netxms.org/topic/7981/save-window-size-and-state</guid><dc:creator><![CDATA[zev]]></dc:creator><pubDate>Fri, 19 Jul 2024 05:31:07 GMT</pubDate></item></channel></rss>