LDAPNightlySyncService: error though it seems to sync the users
Hi together,
we're facing trouble with our LDAP synchronizer. The LDAPNightlySyncService runs into an error evertime it runs. Although it seems that every user is synchronized correctly.
The error message is this:
I can put the whole message here if needed.
Our "Base Group DN" is "dc=rsint,dc=net" - the top of the tree of our AD. Wee need to search the whole AD tree because our user are in different containers that we cannot use a deeper base dn.
Any idea how to fix it? Or maybe is it a bug and needs to be fixed by IBM?
The problem on this is - our synchronzier is running every 10 minutes - so our log files are flooded with this pointless message and important issues cannot be tracked easily. We now faced this in splitting the logfiles that all ldap messages running into a different logfile but the problem is the same - logfile gets flooded with this message and we are not able to see important ldap messages.
Greetings,
Simon
Greetings,
Simon
we're facing trouble with our LDAP synchronizer. The LDAPNightlySyncService runs into an error evertime it runs. Although it seems that every user is synchronized correctly.
The error message is this:
|
2012-09-07 00:01:26,262 [ jts: AsynchronousTaskRunner-2] ERROR .internal.userregistry.ldap.LDAPNightlySyncService - CRJAZ1326E The members of the Jazz groups could not be retrieved.
javax.naming.PartialResultException: Unprocessed Continuation Reference(s); Remaining name: 'dc=rsint,dc=net' |
I can put the whole message here if needed.
Our "Base Group DN" is "dc=rsint,dc=net" - the top of the tree of our AD. Wee need to search the whole AD tree because our user are in different containers that we cannot use a deeper base dn.
Any idea how to fix it? Or maybe is it a bug and needs to be fixed by IBM?
The problem on this is - our synchronzier is running every 10 minutes - so our log files are flooded with this pointless message and important issues cannot be tracked easily. We now faced this in splitting the logfiles that all ldap messages running into a different logfile but the problem is the same - logfile gets flooded with this message and we are not able to see important ldap messages.
Greetings,
Simon
Greetings,
Simon
2 answers
I have found some thing I could change.
In advanced properties of https://<servername>:port/jts/admin there is the way to configure the ldap connection. For this search for "LDAPUserRegistryProvider"
There are two steps for searching:
1) Base User DN
2) Base Group DN
The Base User DN cannot be changed to a special OU because we face the users in different ous - parallel on the top node. But I'm not sure why this is even needed, because using the ldap debug mode of the log4j we've seen, that the synchronizer uses the DN of each user to allocate them.
So I changed the Base Group DN to the DN of the node where the Jazz groups are located. Since all are in the same node I could use this directly. Now it seems that the error is gone.
So - partly correct to choose a node more down in the AD but only for the Base Group DN
In advanced properties of https://<servername>:port/jts/admin there is the way to configure the ldap connection. For this search for "LDAPUserRegistryProvider"
There are two steps for searching:
1) Base User DN
2) Base Group DN
The Base User DN cannot be changed to a special OU because we face the users in different ous - parallel on the top node. But I'm not sure why this is even needed, because using the ldap debug mode of the log4j we've seen, that the synchronizer uses the DN of each user to allocate them.
So I changed the Base Group DN to the DN of the node where the Jazz groups are located. Since all are in the same node I could use this directly. Now it seems that the error is gone.
So - partly correct to choose a node more down in the AD but only for the Base Group DN
Comments
Simon Eickel
Sep 07 '12, 2:54 a.m.we're using RTC 4.0 on a Windows Server 2008