NetXMS Forum

Then we'll wait for a new patch release. 

Thanks for the quick support.

Regards
Peter

The log is from Windows 10.

Due to the rollback (Hyper-V checkpoint), the Server 2016 log file with the v5.2.0 entries is no longer available.
If it's important, I could enable the checkpoint with v5.2.0 installed. But since our system is in production, that wouldn't be desirable.

Because I rolled back to 5.1.3, I hope this is the correct section of the log file:
nxmc.log

Attempting to update NetXMS from version 5.1.3 to version 5.2.
The legacy client seemed to work, but the (modern) client closes without errors immediately after logging in.
The client was tested on different computers.
System environment: Server on Windows Server 2016, client on Windows Server 2016 or Windows 10.
How do i determine what the problem is?

Regards
Peter

@egert143 said in NetXMS 4.0 patch release 4.0.2157:

@victor said in NetXMS 4.0 patch release 4.0.2157:

@curuser said in NetXMS 4.0 patch release 4.0.2157:

Hi!

I'm facing some problems with package deployment.

For example: msi-Package "A" is successfully deployed to most nodes but for some the message "file transfer failed" appears.
msi-Package "B,C,D" are successfully deployed to nodes where Package "A" fails.

Another case: Message "timeout" appears - in fact package has been successfully deployed (not really a problem)

Best regards.

Hi,

could you provide logs from problematic agents (preferably on high debug level, 5 or 6)?

Best regards,
Victor

Possibly related: https://www.netxms.org/forum/general-support/agent-upgrade-via-package-manager-fails/

Hi!
some additional info

• there are no "part-files"
• the files are merged - setup can be started with the transfered file

Regards

nxagent.log

Hi!

I'm facing some problems with package deployment.

For example: msi-Package "A" is successfully deployed to most nodes but for some the message "file transfer failed" appears.
msi-Package "B,C,D" are successfully deployed to nodes where Package "A" fails.

Another case: Message "timeout" appears - in fact package has been successfully deployed (not really a problem)

Best regards.

Hi.
I'm trying to use getValue on Octet-String within scripting, but it returns an empty string.

transport = $node->createSNMPTransport();
if (transport != null)
{
  testStr = transport->getValue(".1.3.6.1.4.1.4196.1.1.5.2.100.2.1.4.0");
  if (testStr == "") println "huh ?";
}

The MIB-Browser shows Type Hex-String with Value "00 00 02 00 00"
The DCI with DataType String and no conversion collects the same value.
The code from above returns an empty string 

NetXMS version 3.9.156

Any hints?

Thanks in advance.

Hi,
updating from 3.8.366 to 3.9.156 works fine here (updated Windows package from 28-07-2021, 10:35).

Many Thanks for ongoing improvements.

But there are 2 'Problems':

1. The SMTP check via Network service is not longer working.
2. Trying to install any Agent-Version over version 3.9.156, via Package Deployment, fails with 'File transfer failed'  :-
   This might be a little desaster, when a new version has to be installed ..

Values in Server Configuration are
  StatusPropagationAlgorithm: Unchanged
  StatusCalculationAlgorithm: Most critical

I'll try to describe the 'issue' in other words:

The 'port down' event (minor) leads into 'port status' critical > minor ≠ critical
The 'port unexpected up' event (major) leads into 'port status' critical > major ≠ critical

A change within StatusPropagationAlgorithm and StatusCalculationAlgorithm won't fix it.
It's a decision of development or a bug.

Greetings

In general I like this Feature. 

Since every source can theoretically generate events with ID 0-65535, it should be possible to include/exclude a combination of source, level and ID (similar to Logwatch).
For example: A search for ID 1 on www.eventid.net shows a list of many different sources with different level.

I tried some keywords, but with version 3.8.266 level or severity is not supported?

My first and most important step would be to exclude level 4 (information).
That would greatly relieve the database.

I'm looking forward to new filter options. 

Thanks in advance.

>>> Which version are you using?
Version 3.8.266, but I think the behavior has always been like that.

>>> Just tried recent one, unexpected interface up is critical on an interface and changes node to critical. Same for interface down.
.. and I think it's not correct.
Why are events with the status minor or major processed as critical?

• Event 'Interface down' with severity 'minor'
• > Alarm 'Interface down' with severity 'minor'
• > Status 'Interface' gets 'critical'?  ???

>>> What about status calculation settings on the interfaces, not on the node, are they set to default?
All status calculation settings are default (server-configuration, interfaces, nodes, container).

Greetings

Hello.
While DCI-status is propagated to parent objects with the original status (warning, minor, major, critical),
the status for 'unexpected interface up' (major) or 'interface down' (minor) is always propagated with severity critical.

As the the interface in object tree shows the status critical, it may be intentionally.
But I would like to have the original interface severity propagated.

Status calculation is set to default.
Is there a setting to change this behavior?

Thanks in advance.

Hi,
a short description of what I'm doing:

• I create a dump of the netxms_db
• restore it on a test system
• and start NetXMS

On the test system all nodes are unreachable.
After a short time the network map looses allmost every information, as you can see in the pictures below.
On each restored database it is different which elements are removed and which remains on the map.  ???

It would be better when elements and links with their actual status remain on the map.

Changing "TopologyExpirationTime" seems to make no difference.

Best regards.

@victor said in NetXMS 2.0.3 released:

...

• Management console:
  ...
          - Fixed object selection issues in network maps
  ...

In Release 2.0.2 I recognized no issues with the selection of network elements.  ???
In Release 2.0.3 a selection is only possible when the network map is shown at "zoom level 0" (pressing Ctrl-0) - when scrollbars are shown, they have to be moved to the most upper and most left position.
On other zoom levels (+ or - button) or scrollbar positions the selection points are not below the elements.

I am using nxmc-2.0.3-win32-x86.

Many thanks for your answers.

@victor said in Function GetDCIValueByDescription returns (once) an empty string:

..
GetDCIValueByDescription reads last value from cache. It can happen that it was called faster then cache for queried DCI was populated (either by poll or from database). I'll think what I can do with that.
..

It would be nice if the behavior could be changed.
(Although a restart is a special situation ..)

Best Regards.

I set up an DCI with: origin-script, data type-string, polling intervall-300
The script returns possible node problems as string - amongst other things using the function GetDCIValueByDescription.
While NetXMS is constantly running, I get the last value (not empty as expected).
If the Core Server has been restarted, the function GetDCIValueByDescription returns (once) an empty string.  :-
I checked in the history that the last value was not empty.

I would call it a bug ::) , observed in version 2.0-RC1 and 2.0-RC2.

Best Regards.

Hi @all.
Up to now we use 'The Dude' from Mikrotik - but development is stopped for years.
I am testing NetXMS from version 1.2.12 up to 2.0-RC1.
It is a nice software with great potential - functions like autodiscover, automatic map layout, usage of scripts, templates etc. are very welcome.
But I have also some ideas for improvements - here is my first

Automatic cyclic reconnect-attempt of the Management Console, if the connection is lost.
In an multi-user-environment all users have to reconnect manually if one user decides to restart the core server (ex: Windows Updates).
It would be also helpful when a short network problem occurs or if the server temporarily is too busy.

Best Regards.