How to repair ADLDS repplication issues within the LDS instance used by DRA

Each NetIQ Directory and Resource Manager (DRA) Sever hosts a local ADLDS instance. This allows for secure replication of various DRA configuration settings, as well certain AD object properties; only visible within DRA. Replication between each local instance on DRA servers is controlled via the built-in ADLDS replication settings. Each DRA server will register its hostname and ADLDS service name within the sites and services container of the ADLDS Configuration partition. Successful ADLDS replication is also required in order for the ADLDS instance hosted on the Primary Server to validate its invalid Flexible Single Master Operation (FSMO) roles.

The ADLDS instance on the Primary DRA Server will host the schema master and naming master ADLDS roles. This roles are required in order to modify the ADLDS schema and create new objects within the ADLDS instance. These actions are required in order to maintain the health of the DRA MMS as well as apply DRA product patches and version upgraded.
The status of the ADLDS Replication can be validated within the DRA 9.2 (and newer) built-in and standalone Health Check Utility. In addition the Windows Event Viewer ADAM Event logs will report on the health and status of the local ADLDS instance.

The status of the ADLDS Replication can be validated within the DRA 9.2 (and newer) built-in and standalone Health Check Utility. Should the HCU report a failure with the ADLDS replication, it will often provide the administrator with a Fix-It option.
Should the HCU utility not be able to fix the error, or you are running an older version of DRA; it is possible to use the Microsoft Replication Admin (RepAdmin) CMD utility to fix the issue.
Before launching the utility it is helpful to validate the current replication partners contained within configuration partition; located on each DRA servers local LDS instance. This can be done using Microsoft Active Directory Service Interface Editor (ADSIEdit). By default only the AD account running the DRA Services will have Admin rights into the local ADLDS instance. Once in ADSI Edit, you will need to connect to the Configuration naming context on the local server, using port 50000. Once in the configuration the replication partners are stored within the following path: CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,CN={<Unique Guid shared among all ADLDS instances in the current replication set>}. Each replication partner will be represented a Server Object with the naming format: <DRAServerName>$<ADLDS Windows Service Name on the DRA Server>. If any server objects listed are invalid, ADLDS replication will fail.
Once every DRA Server’s ADLDS instance has the correct replication partners, you will need to re-start the replication, using the steps below. These steps must be done from an Administrator CMD Prompt, in the context of the DRA Service Account.

1. Disable outbound replication on all DRA Servers:Repadmin /options <DRAServername>:50000 +DISABLE_OUTBOUND_REPL

2. Disable inbound replication on all DRA ServersRepadmin /options <DRAServerName>:50000 +DISABLE_INBOUND_REPL

3. Re-enable outbound replication ONLY on the Primary DRA ServerRepadmin /options <PrimaryDRAServername>:50000 -DISABLE_OUTBOUND_REPL

4. Re-enable inbound replication on all secondary DRA ServersRepadmin /options <DRAServerName>:50000 -DISABLE_INBOUND_REPL

5. Force the ADLDS instance on the Primary DRA Server to replicate its contents to all secondary DRA ServersRepadmin /syncall <PrimaryDRAServerName>:50000

6. Re-enable Inbound Replication on the Primary DRA ServerRepadmin /options <PrimaryDRAServerName>:50000 -DISABLE_INBOUND_REPL

7. Re-enable outbound replication on all secondary DRA ServersRepadmin /options <DRAServername>:50000 -DISABLE_OUTBOUND_REPL

8. Run another ADLDS ReplicationRepadmin /syncall <PrimaryDRAServerName>:50000

The replication status can be validated using: repadmin /showrepl <DRAservername>:50000. The DRA implementation of ADLDS features three naming contexts to be replicated:

• Configuration
• Schema
• DRA.COM

The ADLDS replication can fail for a number of reasons. One more common reason is invalid replication partners. Anyone common reason is multiple ADLDS instances running on a single DRA Server. When the ADLDS replication fails, successful validation of the FSMO roles will also fail. The replication must be fixed, before the ADLDS FSMO roles can be validated.

The DRA Standalone Health Check Utility , can be installed from the <path to NetIQAdmininstallationKit>\Evaluation Utilities folder. This HCU can be installed on any DRA 9.x server.