Table of Contents

General Main Release 10.5.0 CU19 - Preview

Important

We are still working on this release. Some release notes may still be modified or moved to a later release. Check back soon for updates!

Important

Before you upgrade to this DataMiner version:

Tip

Changes

Enhancements

SLLogCollector: Separate log file per instance [ID 44668]

Up to now, all SLLogCollector logging of all SLLogCollector instances would end up in the following files, stored in the C:\ProgramData\Skyline\DataMiner\SL_LogCollector\Log folder:

  • SL_LogCollector_fulllog.log
  • SL_LogCollector_log.log

From now on, each SLLogCollector instance will have its own dedicated log file named log-[creation timestamp].txt, stored in the C:\ProgramData\Skyline Communications\SLLogCollector folder.

Up to 10 log files will be kept on disk, and the log file of the current instance will be added to the SLLogCollector package.

APIGateway: SLNet authentication [ID 46055]

A new REST endpoint, /APIGateway/api/authentication/ticket, can be used to authenticate a session with APIGateway using an SLNet connection ticket. You can then use this session to access DxM endpoints in an authenticated way, with APIGateway acting as a reverse proxy.

Enhanced performance when recalculating security keys [ID 46077]

Because of a number of enhancements, overall performance has increased when recalculating security keys.

DxM upgraded [ID 46124] [ID 46259]

The following DataMiner Extension Modules (DxM), which are included in the DataMiner upgrade package, have been upgraded to the indicated version:

  • DataMiner ArtifactDeployer 1.10.0
  • DataMiner CloudFeed 1.4.9
  • DataMiner CloudGateway 3.3.2
  • DataMiner CoreGateway 2.14.17
  • DataMiner FieldControl 2.12.2
  • DataMiner Orchestrator 1.11.0
  • DataMiner SupportAssistant 1.9.3

For detailed information about the changes included in these versions, refer to the DxM release notes.

Security enhancements [ID 46368] [ID 46411] [ID 46510] [ID 46515]

A number of security enhancements have been made.

Fixes

Agent element alarm and masking information could be out of sync after a Failover switch [ID 45601]

Up to now, when a DataMiner Agent came online after a Failover switch, the Agent element alarm tree and mask state could remain stale in memory. As a result, alarm and masking information for the Agent element could temporarily differ from what was stored in the database.

From now on, when the Agent comes online after the Failover switch, the Agent element's alarm and masking information are explicitly reloaded from the database. This ensures that the incoming Agent immediately reflects the correct alarm tree, correlated alarms, and mask state.

Table subscriptions with forceFullTable filter did not deliver updates for newly added rows on regular tables [ID 45970]

Up to now, when you created a subscription on a regular (non-partial) table and included the forceFullTable=true extra filter, updates for rows that did not yet exist at subscription creation time were not delivered.

From now on, this filter will be ignored for regular tables. As a result, subscriptions that include this filter now behave the same as subscriptions without it, and updates for newly added rows are delivered correctly.

View tables, direct view tables, partial tables, and matrixes are not affected.

SLAutomation deadlock when many subscripts were launched rapidly [ID 46056]

SLAutomation could deadlock when many subscripts were launched in a short time. This issue has been resolved.

SLAutomation could hang during shutdown [ID 46123]

In some cases, a race condition could cause the SLAutomation process to hang during shutdown.

As a result, a DataMiner upgrade could be delayed unnecessarily by up to 5 minutes.

Invalid cleared correlated alarms could be generated when DVE linking changed [ID 46174]

When a correlation rule with the AutoClear option disabled generated an alarm for base alarms on a linked DVE table, DataMiner could generate invalid cleared alarms if the linked row disappeared and reappeared or was unlinked and relinked.

Persistent element timeout caused by failed WMI actions [ID 46396]

Up to now, a WMI action that was not included in a poll group could fail. For example, this could occur when a QAction updated a parameter, and a trigger on that parameter executed a WMI action. As a result, the element would go into timeout and be unable to recover from the timeout status. This issue has now been fixed.

Advanced search syntax