Troubleshooting delta import operation for Sun One MA

Reading Time: 3 minutes

Back from TechED, time for another troubleshooting case for ILM.

I have a customer who is using ILM (FIM synch service actually) to manage objects in Sun One directory (or Enterprise Directory how Oracle is calling this now). After some changes in the infrastructure, which resulted in one of Sun LDAP servers being taken out of service they have started to be hit by an issue that delta import operations has stopped to work. When ILM was configured against new LDAP replica it has not recognized it as a replica which supports delta import operations. So there was a difference between the old and new server somewhere.

For test purposes we have used another Sun ONE LDAP replica to check if ILM will work with it correctly when it comes to deltas, and it did. So apparently there was configuration difference between those two servers (we have confirmed using LDP.EXE that ILM agent account is allowed to read this information on both servers).

So what’s the difference? This was immediately visible when we have analyzed network traffic between ILM box and Sun One server, first looking at network traffic which is going on between ILM and server which was not recognized correctly as a source of change log, and later comparing this with network traffic which goes to the server which operated normally.

In first case, among other we could see following LDAP queries:

And response

In second case we could see similar information and requests but the answer was slightly different. Query:

And response:

So when ILM has sent query for rootDSE object (NULL as query base) and was looking for attribute called changelog it has been found and returned. For ILM this is indication that it can use this particular LDAP replica as a source of changes information.

If you are spending your daily job life in AD world this is something which you might be a bit surprised as in AD all servers can be used as a source of delta information. This is because of AD multimaster replication model and how it works. However in this case, even that information about the change log exists in given LDAP replica, if it is not marked with additional attribute in its rootDSE information it won’t be used as a source of such information.

Another problem solved quickly when network traffic was analyzed. This should be like rule of thumb for you that if you are troubleshooting something over the network you should start to look at what is being sent over a network first. It makes life simpler.