NetXMS Support Forum

Thanks for your reply.
For me matching by source IP would be the most logical. But I don't know if there could be a problem with nodes with multiple IP addresses or in other cases I don't know. But when the 'host'-field has priority now, why is there no problem in my second case (see 'edit' in my posting)? There are two nodes with the same host name (but different domain of course).
How fast would a solution be possible?

New problem with this feature:

Here the situation:
NetXMS -- GW1.DOMAIN1.XX -- VPN -- GW1.DOMAIN2.XX

Both 'GW1' send syslog to NetXMS server. GW1.DOMAIN1.XX ist the ZyXEL device which sends the syslog messages with wrong 'host'-field (where the new feature in V1.2.15 matches by source IP address). GW1.DOMAIN2.XX is newly connected. This Device sends correctly 'gw1' in 'host'-filed. Now the NetXMS server shows GW1.DOMAIN1.XX as source!! So we have all syslog messages from both nodes on 1 node. Big ghetto.

By the way I opened a support case at ZyXEL for the wrong 'host'-field with no success yet :-(

Edit:
I have two other devices from the same type as GW1.DOMAIN2.XX: FW1.DOMAIN3.XX and FW1.DOMAIN4.XX. Here the syslog message source in NetXMS is correct. Thirst I thought the same host-name (but different domain) is the problem. But this is refute with this second test.

thanks for the update, ok for me.

Yes thats way better of course. But I don't want to save all scripts also in the filesystem. If I have to make some changes to a script, I want to copy the existing script from NetXMS to Notepad++, edit and copy back.

Any news in this case. Or do you need more information or tests?

Copy/Paste (CTRL+C, CTRL+V) is not working at a lot of places in Java console (V1.2.16 on Windows-x64).
For example:
- Script Editor
- Agent Config Manager

That's very painful. Does others see this too?

any news in this case?

any news about these two new features?

is #2 already implemented? My newest test says NO. (I didn't saw the feature request in the bug tracker)

any plans for #4? To deliver the parser files by agent policy is in my opinion the most elegant way.

I 'solved' the unknown state by creating a pseudo interface on the node with excpected state = ignore and activating ICMP-pings for status polling. I know, absolutely not very elegant, more like bricolage :-)

Please take the second option as a feature request! I don't know what would be better: take the interface status of an other node for status or more generally a free configurable DCI (so you can check not only interface status of another node).

Thanks for your fast reply.
I tried your first suggestion but the node status only changes between 'critical' and 'unknown', no 'normal' when UP.
I also tried the unmanaged switch with a unexisting IP address (Polling: all=off beside status-polling and data collection), and a threshold on the DCI generating directly SYS_NODE_DOWN and SYS_NODE_UP, so I get UP and DOWN events but the node status changed also between 'unkown' and 'critical' but never 'normal'.
Do you know why this status 'unknown'?


But the new feature in your second passage would be much better and could help us a lot.

I'm looking for a possibility to have unmanaged switches as managed nodes in NetXMS.

Example:
NetXMS --- SwitchA --- SwitchB --- DeviceX
(NetXMS = Monitoring-Server, SwitchA = managed Switch, SwitchB = unmanaged Switch, DeviceX = some NetXMS node)

So I could use the Status of the switch port on SwitchA (on which SwitchB is connected) to determine the status of SwitchB. I defined for SwitchB a node in NetXMS with a DCI which reads the interface status from SwitchA. But so I only have a normal DCI on SwitchB and no 'Status' (with SYS_NODE-DOWN and UP).
I made some experiments with the 'This is address of remote management node' switch. But no luck.
Has anybody a good solution for such a situation? Thanks in advance for all suggestions.

Ok, now 'everything' is clear, I will migrate from local config files to a mix of server-config and agent policies.

Thank you Tatjana. So the documentation will become better and better. But the way is still long :-)

thanks
Dani

Ok, thanks for the input. Now it's more clear to me. I recap, as I have understood:

Agent Configuration Files on Server:

• Assignment is Rule based (In filter script only variables $1 - $5 are possible (changed in admin guide))
• Config download from server is each time the agent starts (if option '-M servername')
• When config is found on server, local config is overwritten, if not existing local policy is used
• At minimum the server connection parameters must be in Master config

Agent Policies:

• Not possible for bootstrap agent
• Also possible via proxy
• Assignment is only direct to nodes, not rule based
• Can be in XML or 'key = value' format
• Settings from different policies will be merged at agent startup
• SubAgent config sections also possible
• changed policies must be reinstalled on nodes (in console) and need agent restart

For me the only open question is the priority, when there are conflicting settings in Master config and in one or more agent policies.

Sorry I changed my last reply too much :-) So it's completly different.
Is anybody able to answer my open questions about agent config delivery?