Access Manager vcdn usedevice tag error after upgrade to 4.4

  • 7024417
  • 08-Feb-2020
  • 13-Mar-2020


  • Access Manager Admin Console 4.4.0


  • A dedicated Primary and Secondary Admin Console Server has been configured.

  • Both Admin Console Servers have been upgrade from NAM 4.3.1 to NAM 4.4.4.

  • All NAM services such as authentication at the IDP server or any AG Proxy Services are working without any problems.

  • Accessing device configuration through the admin console for some options are causing a JAVA Exception returning:
<vcdn:usedevice/> tag error]
Device Information MissingdeviceConfig is null, most likely the device name (appname parameter) was not passed or was lost.

This error indicates that the Admin Console is not able to read the device configuration (XML document stored on an attribute) from the configuration store (embedded eDirectory database with a special schema used to store all NAM configuration).

Using iMonitor to browse this eDirectory database, collision objects have been identified. These objects have names like  0_0, 1_6, etc. but the CN attribute will hold the original names. These collision objects corresponded to the Access Manager configuration being read when the vcdn usedevice tag errors occurred. Collision errors can occur when two objects have the same name or same timestamp.

It was suspected that there may have been an eDirectory issue before the upgrade commenced.
The Primary and Secondary Admin Consoles were restored and eDirectory health check was carried out to ensure that the two eDirectory replicas were fully in sync and communicating.

Running the upgrade again from a clean and working eDirectory again ended up with collision objects


Add the “export NDSD_CC_SKULK_DELAY=2” to the pre_ndsd_start script on the admin console before running the NAM upgrade. The upgrade was attempted again and completed successfully without any further issues.


The parameter NDSD_CC_SKULK_DELAY sets the number of seconds before changes in the local eDirectory replica are synced to other replicas.
With NAM 4.3.1 using eDirectory 888 the default value is 2
With NAM 4.4.0 using eDirectory 903 the default value is 0 (immediate).

What we think is happening is that the multiple changes are occurring, being sent too quickly and collisions are the result.

It is a good idea to leave this slower skulk delay parameter in place, in fact, make it a standard tuning step for Access Manager Admin Consoles.

The sync immediate option is good for some eDirectory applications where replicas need to be updated quickly.
There is no good reason for an Access Manager  primary Admin Console to sync immediate, it will increase resource usage for no gain. The secondary Admin Console is only there as a backup and syncing can happen at leisure.