NetXMS Support Forum

Hi,

it's not a step-by-step guide, but basic information is available in administration manual: https://www.netxms.org/documentation/adminguide/ssh-monitoring.html

Best regards,
Victor

Try to change DCI data type to "String" and request history - will it show something?

Best regards,
Victor

Hi,

we are using LDAP client provided by Windows (Wldap32.dll), so I suppose it has to use Windows certificate store for root CA certificate. There are no mention in documentation about any specific requirements for LDAP client to work over TLS. Are you sure that your LDAP server picks up correct certificate and actually supports secure connection? As I remember it is quite tricky process to setup Windows LDAP server for TLS. Did you check LDPAS connection with other tools (ldp.exe for example)?

Best regards,
Victor

Hi,

try to set debug level 6 for tag obj.netmap and check server log if objects and/or links are actually removed or added when layout changes.

Best regards,
Victor

Response time for community support is really not guaranteed, and depends on multiple factors, mostly complexity of the issue and available resources. We always try to do our best but we cannot cannot promise fast handling for all issues. This bug will be looked at when someone from the team will have time.

Best regards,
Victor

Sometimes it helps to undeploy application, stop Tomcat, clean Tomcat's working directory, and deploy application again.

Best regards,
Victor

Hi,

syntax for accessing event parameters within filter script is different from macro expansion. You can access event object via global variable $event. It has attribute "parameters" which is array of all event parameters. You can either use this attribute or you can use expandString method to expand standard macros. So your filter script could be in one of two forms:


return $event->parameters[6] ilike "C:\\";


or


return $event->expandString("%6") ilike "C:\\";


Best regards,
Victor

Hi all!

NetXMS 3.4 patch release 2 is published. Changes since previous release:

- PostgreSQL monitoring subagent
- Improved driver for Cisco Nexus
- Improved LLDP based network topology discovery
- Correctly detect LLDP capability on Mikrotik devices
- New NXSL functions GetServerNode and GetServerNodeId
- New NXSL function SendMail
- Fixed UI bug with accessing collected performance data from data collection editor
- Configurable size of SNMP proxy thread pool on agent
- Housekeeper optimization
- Added drivers for Cambium Networks devices (ePMP and cnPilot)
- Fixed issues:
        NX-1863 (Logwatch fails on parsing large Windows Event Log events)
        NX-1880 (Duplicate links on automatic maps with multiple seed nodes)
        NX-1895 (After server restart GUI is not showing from where a custom attribute is inherited)
        NX-1897 (ReadPersistentStorage returns incorrect value for non-existing key)
        NX-1901 (Get node of active NetXMS server in NXSL)
        NX-1910 (Spelling mistakes in Java API)

There were no changes in agents besides WIndows, so agent packages were not updated and 3.4.232 still good to use.

Best regards,
Victor

Да, получится. Серверу мониторинга нужен доступ по SNMP ко всем устройствам, а дальше собственно карты строятся на основе собранных данных. Для карт второго уровня это LLDP, CDP, таблицы MAC адресов, и т.д. Для карт IP уровня это сетевые интерфейсы и их адреса.

Hi,

pay attention to case - it is modifyObject, not modifyobject.

Best regards,
Victor

Возможно на сервере отключена прямая отсылка сообщений? Проверьте параметр сервера AllowDirectNotifications - должен быть включен.

I think it should be implemented as notification channel, but it is not a high priority currently, as there is a relatively easy workaround.

Best regards,
Victor

Script should find another alarm that is a root cause for current alarm. Script is expected to either return null (means no root cause) or alarm object. If root cause alarm is returned for current alarm then current alarm will be placed under root cause in alarm browser (so you'll see alarm as hierarchy instead of flat list). Acknowledging or terminating root alarm will also do the same to all sub-alarms.

Best regards,
Victor

It was caused by a bug in DB init script (wrong primary key). We have fixed it, fix will be included into next patch release.

Best regards,
Victor

That sounds useful, I've registered it as feature request (https://track.radensolutions.com/issue/NX-1911).

Best regards,
Victor