NetXMS Support 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

Quote from: Egert143 on February 23, 2022, 01:52:05 PM

Quote from: Victor Kirhenshtein on February 22, 2022, 10:34:17 PM

Quote from: Watchman on February 22, 2022, 05:15:21 PM
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

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':

• The SMTP check via Network service is not longer working.
• 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.

Quote from: Victor Kirhenshtein on March 30, 2016, 06:43:10 PM
...
- 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.

Quote from: Victor Kirhenshtein on October 19, 2015, 11:23:25 AM
..
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.