Known Issues

Highly recommended

Service packs fix bugs: You can avoid most of these issues by installing the latest NAM service pack for your release.

NAM Server reports no ADoD data while NAM Probe has data files back ten days


Reference: APMODCRUMM-11187

Applies to: NAM 2019 GA and NAM 2019 SP1

Details: A NAM Server report can pull data day by day going backwards, but some days are missing entirely. The missing days seem to correspond to adding a new NAM Probe to the cluster. If any NAM Probe connected to the NAM Server does not have the data files for the requested time range, the error message that there is no data is returned. The data is there but the NAM Server can't detect it. There is no replication between probes, so if the query is only sent to one probe, data on the unincluded probe is expected to be missing. The issue is that one of the NAM Probes does not have the data files for the specific time window so the NAM Server drops all the results from all the NAM Probes.

Workaround 1: (for NAM 2019 GA and NAM 2019 Service Pack 1 only) To show data on reports for the missing days:

  1. Go to /rtmdebug on the master node
  2. Stop processing
  3. Go to /amdcfg
  4. Disable the "new" NAM Probe
  5. Rerun the reports for the days missing data
  6. Save out the reports that now have the data

Incorrect console connection properties error occurs while upgrading to NAM 2019 using full option


Reference: APMODCRUM-31813

Applies to: NAM 2019

Details: While performing the NAM Server upgrade with a Full option where you have a chance to modify any existing properties, if you alter the existing NAM Console private URL and choose option Get token automatically you will receive the console connection properties error without the possibility to continue.

Workaround 1: During the NAM Server upgrade, select the Enter token option instead. The token can be found in an Internal API token section of

From the main Dynatrace NAM menu, expand the Security section of the menu, and click the API tokens. On the API tokens, click Edit to expand the section and to view the generated token.

Workaround 2: Change the NAM Console address before upgrading NAM Server (using Add/Remove Programs) and then perform standard upgrade procedure without altering the NAM Console private URL.

Script recipients can't be displayed when accessing Console over HTTP protocol


Reference: APMODCRUMM-10412

Applies to: NAM 2018


After upgrade to NAM 2018 the user is not able to display the script recipients in the NAM Console anymore.

  • In Alert management, the user can switch to Recipients and open the dropdown menu recipient type.
  • But if the user chooses Script, an "Internal Server Error 500" occurs.


To be fixed in NAM 2018 SP1


Use HTTPS protocol to access NAM Console, or try Microsoft Internet Explorer 11.

Console can't connect to LDAP server due to unknown certificate


Reference: APMODCRUM-30590

Applies to: NAM 2018


The problem appears due to new JRE build (1.8.0_181) that has been included in RUM Console. In release notes there is an explanation (see

To improve the robustness of LDAPS (secure LDAP over TLS ) connections, endpoint identification algorithms have been enabled by default.

There may be situations where some applications that were previously able to successfully connect to an LDAPS server may no longer be able to do so. Such applications may, if they deem appropriate, disable endpoint identification using a new system property: com.sun.jndi.ldap.object.disableEndpointIdentification.


Apply correct certificate to LDAP server.


Define this system property (or set it to true) to disable endpoint identification algorithms.

In order to make Console working as previously it is enough the add the following flag to Console command line in registry:


Dictionary inconsistency

Reference: APMODCRUMM-8818

Applies to: DC RUM 2017 May


Fixing problems with dictionary inconsistency issues


Apply the following patch: dictionary consistency fix pack v17.jar

To clear dictionary inconsistency warning message:

  1. Delete all ExportConfig* files from <installation directory>\temp\directory

  2. Go to the http://<your_CAS_address>/DiagConsole#/diag CAS page

  3. In Search box type: ALL and then DICTIONARY CLEAR FLAG

It is important to do this in order - 1st remove all ExportConfig* files and then clear the flag.

Unable to connect to AMD after upgrade

Reference: SUPDCRUM-20563

Applies to: DC RUM 2017 May


When you've upgraded CAS to 17.0.x first and after that the AMD. After CAS upgrade it was able to process data from the AMD (12.4 ver yet), then AMD was upgraded to 17.0.x and the SSL connection (rtmgate) params have changed. AMD 17.0.x uses now TLS 1.2. While the CAS remembers the previous TLS connection params with this AMD (<1.2) it can't communicate any longer with AMD after upgrade.

The following messages may appear in server.log:

E ADM	17-09-05 14:15:46.369	Ex: Connection reset.

See full output.


The solution requires to restart CAS for it to re-establish SSL connection with AMD via TLS 1.2.

Compatibility issue between SP3 and pre-SP3 versions for intra-CAS-Cluster communication

Applies to: DC RUM 2017 May, SP1, SP2 and SP3


There is compatibility issue between SP3 and pre-SP3 versions of internal library (hazelcast) used for intra-CAS-Cluster communication. To avoid any issues when applying SP3 (on any < SP3 version), choose one of the following recommended solutions.



  • apply SP3 at the same time to all your CASes and ADSes, including Failovers, or

  • if you cannot do above then apply hazelcast-all-3.1.9.jar patch on less then SP3 version PRIOR starting applying SP3 anywhere.

If you do not apply either of the above recommendations, your CASes will not start and entries like the following will occur in server.log:

E FARM	18-01-12 13:34:55.635	com.hazelcast.nio.serialization.
Problem while reading DataSerializable, namespace: 0, id: 0,
class: com.hazelcast.partition.CheckReplicaVersion

ADS operations limit exceeded due to SSL handshake operations


Applies to: DC RUM 2017 May


Reporting on SSL handshake operations is a new feature in DC RUM 2017.

We're reporting them on purpose learn why - how SSL connection setup relates to the web page load time. The downside is enormous number of new operations reported in hpdata files in ADS - size of these files can grow by 70%. Not all customers want this and worse, it can't be disabled (easily) today, resulting in ADS servers stop processing (new) data early during a day, as only the number of operations limit (default 2M operations / day) is reached.

We have discussed this issue with Product Management and there would be a long term solution implemented in 17.04 (SP4) (avail January 2018) allowing users to control (on/off) if they want to have these operations reported in CAS, ADS or both, globally and/or on a per software service basis.

Meanwhile, our DEV team came up with a hotfix that will filter out all "SSL handshake" records while processing hpdata files by ADS servers - those would still be produced by AMDs, but they won't be stored in ADS database and therefore the hpdata processing cycles should take less time now and therefore eliminate the processing delay). In many cases it would reduce number of operations stored in ADS by 65-70% and that's a big save!

The make a similar change in CAS is not so straightforward. CAS works differently and relies on data consistency - metrics on operation related and "all other" entries have to sum up to what is passed in summary records. We can't remove only records with an operation as it would corrupt the data. We can't remove all records as we would lose track of whole servers.

Furthermore, SSL handshakes in hpdata do not necessarily have to correspond to what is passed to CAS in zdata and how long it takes in CAS. We have analyzed impact and it shows about 60% gain on ADS but only 20% on CAS end, therefore thus far we see this issue impacting ADS servers most often and not CAS servers that much.


In NAM May 2017 SP4, we have implemented a RUM Console switch to turn off SSL handshake operations globally per AMD or individually per software service for the CAS or ADS.

By default, SSL handshake operations are turned on. You can find the SSL handshake operations switch for the following decodes: HTTP, SSL, TDS and other database decodes, RMI, ICA, SMTP, Universal Decode, IBM-MQ and LDAP.

  • Report SSL handshake in CAS data
  • Report SSL handshake in ADS data
  • Report only errors in ADS data

To change SSL monitoring settings, in RUM Console, select Global > Front-End Monitoring > SSL. See Front-end monitoring - SSL.

Once upgraded, publishing configuration changes causes some of the AMDs to restart


Reference: APMODCRUMM-7636

Applies to: All deployments with mixed AMD releases managed by the same RUM Console.


Deployments with various AMD releases managed by the same RUM Console are not supported however, such situation may occur during a deployment upgrade where only partial upgrade has been performed. In such situations, if configuration changes are published, the RUM Console will upgrade the configuration globally to the latest version. Any AMD with an earlier release version will be forced to restart (only once) after receiving an upgraded configuration version.

While this restart is performed silently (no messages are displayed), it will be logged and may be indicated on AMD status reports.


Since these restarts happen only during the first publish, and the deployment scenario (mixed AMD releases) is not supported, no fix is planned.

Can't integrate AMD 17.0 with AppMon 6.5


Reference: APMODCRUM-24580

Applies to: AppMon 6.5, May 2017


This is a known issue for AppMon adding a new AMD.

Connection error will occur if the AMD being added presents the certificate that is already present in AppMon Certificate manager. This is a typical occurrence when a given AMD is reinstalled and its new self-issued certificate is presented to AppMon while a different (old) certificate is still listed in the AppMon certificate manager for that AMD.


Fixed in AppMon 7.0+


To resolve this issue, manually clear AppMon cache. The following procedure is based on AppMon 7.0 running on Windows:

Check if AppMon has a proper AMD configured:

  1. Log in to AppMon using remote desktop.
  2. Start Dynatrace Client.
  3. Go to System Profiles and edit it by RMB > Edit System Profile > Integration.
  4. In the DCRUM Data Import section check entries for every AMD that should get data from AppMon (the green dot indicates that everything is fine with the communication, the red dot indicates connection problems).

Stop the AppMon service (Dynatrace Server 7.0).

Edit <AppMon install folder>/dtserver.ini and add the following line: -Dcleardcrum

Start the AppMon service and wait for the service to become available.

Stop the AppMon service.

Remove the added line.

Start the AppMon service again.

Check the AMD status in all required system profiles (the dot indicator for problem AMD should change color to green).

AMD nCipher SSL decryption not working after upgrade



This issue DOES NOT impact any deployments using OpenSSL.

Reference: APMODCRUMM-9047

Applies to: AMD 17.0.0 with nCipher


Upgrade failing due to nCipher pieces missing.

This is a bug in the nCipher software, introduced in ncipher_pkcs11-12.10.00-2 (AMD 12.4.6).

The issue did not become immediately visible, instead it caused an issue with the next ncipher_pkcs11 package upgrade to ncipher_pkcs11-12.10.00-3 which also contains the same bug (AMD 12.4.13).

The bug is fixed in ncipher_pkcs11-12.30.00-0 (AMD, but the newest nCipher package will not fix the issue if it has already been introduced by AMD 12.4.10/12.4.13.

If you are using AMD 12.4.10 release or greater (but less than, prior to moving further with the AMD installation manually remove currently installed ncipher_pkcs11 package (rpm --erase ncipher_pkcs11).


Planned to be fixed in AMD; AMD 17.0.1 is not affected.


This will NOT remove the current nCipher configuration nor require card/security world reinitialization.

There are four possible upgrade paths:

  • AMD 12.4.5 (HS or Classic) or older:
    Upgrade directly to or later

  • AMD 12.4.6 (HS or Classic) and all versions up to and including AMD 12.4.14:

    1. Remove the ncipher_pkcs11 package.
      [root@AMD /]# rpm --erase ncipher_pkcs11  
      (This may generate some error messages. You can ignore them.)
    2. Install AMD or later.
  • AMD or newer:
    No action is needed. Problem does not occur.

  • AMD 17.0.0:

    1. Remove the ncipher_pkcs11 package.
      [root@AMD /]# rpm --erase ncipher_pkcs11  
      (This may generate some error messages. You can ignore them.)
    2. Install AMD 17.0.1 or later.

The issue also won't occur if you have never deployed AMD 12.4.5 or older. For example, you deployed a fresh installation of AMD 12.4.6 or later.