LDAP sync - some objects not being sync'd into 1IM (v8)

Did you test the scope by using the target system browser in Synchronization Editor? Does it show all records or just some? Is the object class different for the objects that are missing?

Hi Markus, the object class is the same. Unfortunately I'm unable to test via Target system browser in the production system, although I did test using an independent LDAP browser and using the same sync account and filter condition, and the missing objects are listed in the LDAP browser which leads me to believe the sync editor should be able to "see" these objects as well. Anything else you think I could try? 

Hi,

You say that all the objects have the same objectclass ..... but is this a structural or auxiliary objectclass?  The reason I ask is that I know from experience that OI will only 'see' objects where 'Top' is included in the hierarchy of objectclasses.  LDAP browsers and LDAP providers don't seem to care and are very lax about the schema definition and enforcement ...... but OI seems to insist on having 'Top'.

Take a look at the objectclasses for each of the objects and the schema definition for those classes.  At least one of the structural classes must have 'SUP Top'.

I have a suspicion that this is your issue.

HTH, Barry.

Hi Barry

Thanks for the tip, I looked at and compared the objectClasses of 2 objects, one which shows in LDAP explorer (I am onw able to use target system explorer in sync editor), and one which does not show.

Both objects belong to the same classes, although I'm not sue how I find out the "structural" object class of a particular object. When I look using an external tool (LDAP explorer), both objects have objectClass TOP assigned to them, yet only one shows in the target system explorer and one doesn't.

Any hints on finding out how the sync editor is determining the structural object class? I suspect this might be the key issue and difference between the two objects...

Hi,

Well it's not the sync editor that determines the structural objectclass ..... that is defined in the LDAP schema ..... so you need to look at the list of objectclasses and then look at each of those objectclasses in the LDAP schema.  The schema should show you what the kind is (abstract, structural, auxiliary) and what the superior is.

As stated, my suspicion is that the objects that sync editor cannot 'see' are missing Top.

For example if I look at this object using LDAPAdmin:

And then I look at the schema:

So we can see that 'Top' comes from the Superior for 'domain' so it's all good.

HTH, Barry.

Hi,

Well it's not the sync editor that determines the structural objectclass ..... that is defined in the LDAP schema ..... so you need to look at the list of objectclasses and then look at each of those objectclasses in the LDAP schema.  The schema should show you what the kind is (abstract, structural, auxiliary) and what the superior is.

As stated, my suspicion is that the objects that sync editor cannot 'see' are missing Top.

For example if I look at this object using LDAPAdmin:

And then I look at the schema:

So we can see that 'Top' comes from the Superior for 'domain' so it's all good.

HTH, Barry.

Great, thank you Barry, I'll look into this and I suspect we have a similar issue

BTW, another question: We have a lot of classes on the LDAP side however when I refresh schema not all of them show, could this be down to permissions?

Hi,

Do you mean when you do an 'Update Schema' in the target system connection in Sync Editor?

B.

Yes, when I do this in sync editor on the target system side

Hi,

I would expect an update schema to get all the schema from the LDAP side (and show any non-compliance).  I'm not sure why it isn't all being picked up.

And for the virtual schema classes .... again I'm not sure ..... perhaps they are part of the base sync project schema for LDAP but I don't know for certain.

Sorry.

You've been more than helpful Barry, much appreciated

FYI - the virtual schema classes are created if you configure LDAP in expert mode.