How to rebuild the ADLDS instance on a secondary DRA Server

  • 7016076
  • 19-Jan-2015
  • 28-Jun-2021


Directory and Resource Administrator 9.x
Directory and Resource Administrator 10.x


Directory and Resource Administrator uses a local Microsoft Lightweight Directory Services instance to store various configuration and other features used by DRA. It is possible for the LDS instance to have a problem that might require it to be re-created.


To rebuild the LDS instance, on a secondary DRA Server; follow the steps below.
  • For DRA 9.2 and newer:
  1. Remove the Secondary DRA Server from the MMS set, using the D&C console of the Primary DRA Server.
  2. Verify the ADLDS instance has been removed from Windows Add/Remove Programs
  3. Add the secondary server back into the DRA MMS
  • For DRA 9.0.x and DRA 9.1.x , follow the steps below
  1. Stop the NetIQ Administration Service on the affected Secondary DRA Server(s)
  2. Use Windows Add / Remove Programs to remove the existing ADLDS instance
  3. Modify the DRA specific ADLDS information with the Windows Registry, of affected secondary sever(s)
    • Registry path: HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Mission Critical Software\OnePoint\Administration\Modules\ServerConfiguration\ADAMConfiguration
    • Set ADAMInstallationFlag to a decimal value of 1
    • Set the AdminAccount to be the same value stored in the PrimaryAdminAccount
      • Regosty path HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Mission Critical Software\OnePoint\Administration\Data\Modules\ServerConfiguration\PrimaryADAMConfiguration
  4. Set a decimal value of 0 on the flowing keys
    • AQSchemaExtensionsFlag
    • AQSchemaExtensionVASupportFlag
    • DynamicGroupFlag
    • InstanceCreationFlag Note: If rebuilding the Primary DRA Server’s LDS instance this value will be set a decimal value of 1
    • LastLogonSchemaExtensionsFlag
    • RootContainersFlag
    • SHConfigRootContainersFlag
    • SHConfigSchemaExtensionsFlag
    • VAExchDynamicDLSchemaExtensionsFlag
    • VASchemaExtensionsFlag
  5. Set the LDAPPort value to be 50000 and SSLPort value to be 50001
    • Note: If using a different port number, ensure two way communication on the port between all DRA servers
  6. Verify key values under the path HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Mission Critical Software\OnePoint\Administration\Data\Modules\ServerConfiguration\PrimaryADAMConfiguration
    • PrimaryAdminAccount – This should be set a Domain Local group, which contains the AD account used to run the NetiQ Administration Service on every DRA server within the MMS
    • PrimaryInstanceStatusFlag – This should be set to decimal value 1
    • PrimaryLDAPPort – This should be set the value of LDAPPort in the Primary DRA Server’s local registry path HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Mission Critical Software\OnePoint\Administration\Modules\ServerConfiguration\ADAMConfiguration
  7. Once the LDS instance on the Secondary Sever(s) has been removed, local registry keys set, and the Primary Server’s LDS instance is running, run the DRA Health Check Utility
    1. Select only the Checks located under the AD LDS section
    2. Note: Exclude the AD LDS Replication and Instance Backup
    3. Run the checks
    4. Use the Fix it option, to repair the failing LDS checks
  8. Start the Local NetIQ Administration Service on the secondary DRA Server

Additional Information

To rebuild the ADLS instance hosted on the Primary Server, see KB 7025176

Before attempting to rebuild the LDS instance on a Secondary DRA Server
  1. Use the DRA Health Check Utility on the Primary DRA Server to validate the ADLDS checks
  2. Use Windows Event Viewer to check the ADAM event log for any regularly reoccurring warnings regarding FSMO role validation
    • It is normal to see a warning when the OS or ADLDS Service is restarted

The AdminAccount registry key value should be set to the same value used on the Primary DRA Server. The value on the Primary DRA Server is configured during initial DRA install, or when manually reinstalling ADLDS on the Primary Server. Once ADLDS is installed, this value may not be changed.

After the ADLDS instance is restored, a FACR will be started on each manage domain and managed tenant. This will occur on each secondary sever; after its local ADLDS instance is restored.