OIM 11g LDAPSync Deployment Guidelines

OIM 11g can be configured to maintain its user and role population synchronized with an LDAP directory using the LDAPSync feature.  This functionality is based on asynchronous processing through orchestration events from OIM to LDAP and on scheduled tasks for synchronization from LDAP to OIM.  This approach could mean that at some point in time, some of the entries on both repositories may be out-of-sync.  Specially when executing long running Trusted Reconciliation scheduled jobs.  The entry differences can be caused by processing errors or time lapse between user creation in OIM and user creation in LDAP.  This post details some guidelines to minimize and troubleshoot possible errors for OIM LdapSync.

Consider upgrading to OIM 11.1.1.5.2 (OIM 11g Bundle Patch 02).  BP02 provides a number of fixes that improve stability specially during bulk processing (large trusted reconciliations).

Tuning and Tips

Tune the environment to allow for better ldapsync performance when executing large trusted reconciliation jobs in the order of +30K.  These are some tuning tips, some of them straight from the documentation, others from existing deployments.

OIM Tuning

1. JVM:  PORT_MEM_ARGS="-Xms768m -Xmx2048m" in setSOADomainEnv.sh

2. MDBs: In WLS Admin Console -> Environment->Worker Managers->MaxThreadsConstraints-1  set count to 100

3. Disable reloading of Adapters:  Using weblogicExportMetadata.sh and weblogicImportMetadata.sh edit the MDS file /db/oim-config.xml.  

   Replace:

     <ADPClassLoaderConfig adapterReloadingEnabled="true" loadingStyle="ParentFirst" reloadInterval="15"     reloadingEnabled="true">

   With:

    <ADPClassLoaderConfig adapterReloadingEnabled="false" loadingStyle="ParentFirst" reloadInterval="15" reloadingEnabled="false">

   And

    <storeConfig reloadingEnabled="true" reloadingInterval="20"/>

   With:

   <storeConfig reloadingEnabled="false" reloadingInterval="20"/>

4. Database:  Monitor Perfomance with AWR reports and collect complete schema statistics using:

                  DBMS_STATS.GATHER_SCHEMA_STATS(OWNNAME=> schema_owner,

                                                                                              ESTIMATE_PERCENT=>DBMS_STATS.AUTO_SAMPLE_SIZE,

                                                                                              DEGREE=>8,

                                                                                              OPTIONS=>'GATHER AUTO',

                                                                                              NO_INVALIDATE=>FALSE);

OID Tuning

1. Consider deploying multiple OID instances for Failover and Load Balancing. Front end the instances with an LB
2. Number of OID LDAP Server Processes = #cpus. EM -> Administration -> Server Properties -> Performance ( for each oid instance)
3. Number of DB Connections per Server Process = 10 (orclmaxcc). EM -> Administration ->server properties (for each oid instance)
4. Check Skip Referral for Search. EM -> Administration -> Shared Properties (Only if not using referrals in OID).

OVD Tuning (assuming no libOVD is used)

1. Consider deploying multiple OVD instances for Failover and Load Balancing. Front end the instances with an LB and use the OID LB virtual host as the LDAP server host.
2. The parameter Operations Timeout for the Adapters to 30000 if needed (using ODSM)
3. Consider increasing maxpoolsize  for the Adapters to 30-40 if needed (using ODSM)

LDAPSync Monitoring

During the time when the LdapSync Orchestration is running check the following tables and columns in the OIM Schema to verify processing:

Obtain the latest reconciliation job key (RJ_KEY) with the query:

        select max(RJ_KEY) from recon_events;

Table RECON_BATCHES:  using RJ_KEY and RB_NOTE verify that the orchestration events are being created.  The Column RB_NOTE shows the orchestration Process ID and the operation.  It could also show errors that occur.

Table ORCH_PROCESS:  Holds the generated orch processes.  ID being the Orchestration Process ID.  If Status shows Compensated it means that an event failed.  The detail can be seen in the table ORCH_EVENTS.

Table ORCH_EVENTS:  Linked to the orchestration process with the column PROCESSID.  The RESULT column has the error details in case of failure.

The Out-of-the-Box reconciliation job " Retry Failed Orchestrations " can be used to retry compensated orchestration processes.   Specify a date range ("ddMMyyyy") for multiple ones or "Orchestration ID" for single ones.  OIM BP02 also includes fixes for this task.

Note:  In the case when reconciling new users that come as disabled, an existing bug may create the orchestration disable event before the orchestration create event.  So, these disable events would fail in LDAP since the user doesn't exist yet.  As a workaround, these events can be retried with the above Recon Job (specify OPERATION=DISABLE and a date range) after all users are created in LDAP.