You get a 9063 error - this is a generic, non-driver specific issue. An interesting but uninformative message you may see come across the trace is this:
Code(-9063) Object matching policy found an object that is already associated.
The obvious thing is go find the JSmith user object and check to see the association. This occurs in the trace shown below:
[12/11/07 12:41:22.086]:ACME-APP ST: Match found: src-dn='' association='E123456'
[12/11/07 12:41:22.086]:ACME-APP ST:Policy returned:
[12/11/07 12:41:22.088]:ACME-APP ST:
<nds dtdversion="3.5" ndsversion="8.x">
<product version="184.108.40.20670719 ">DirXML</product>
<add class-name="User" event-id="SUSE2#20071211174108#2#1" qualified-src-dn="O=acme\OU=employees\OU=active\CN=JSmith" src-dn="\ACMEIDVAULT\acme\employees\active\JSmith" src-entry-id="37344">
<value timestamp="1194374545#2" type="string">Jane Smith</value>
<add-attr attr-name="Employee ID">
<value timestamp="1188460099#11" type="string">E123456</value>
<add-attr attr-name="Full Name">
<value timestamp="1194374485#5" type="string">Jane Smith</value>
<add-attr attr-name="nspmDistributionPassword"><!-- content suppressed -->
<value timestamp="1189235553#34" type="string">User Services</value>
[12/11/07 12:41:22.107]:ACME-APP ST:Processing returned document.
[12/11/07 12:41:22.108]:ACME-APP ST:Processing operation <status> for .
[12/11/07 12:41:22.108]:ACME-APP ST:
DirXML Log Event -------------------
Message: Code(-9063) Object matching policy found an object that is already associated.
This trace is just after the matching rule fired on the subscriber channel, and the driver is searching for a matching object in the application. It found E123456, which is what the matching rule was looking for, in the first line.
So far, so good. But we end up with the "Code(-9063) Object matching policy found an object that is already associated." error.
What the message is trying to say is that some user elsewhere in the tree has the same association value set. This is different from a user elsewhere in the tree with the same Employee ID. Rather, it is the association value in the users DirXML-Associations list. In this particular case, the user had just changed last names, and the helpdesk had deleted the old user and recreated the new user under her new name. Alas, in the delete process an association to the connected system remained.
All further attempts to synchronize the user into the connected system would fail.
Once we tracked down the user with the bad association value, we cleared it, and the match proceeded normally.
To find it, we did an LDAP Search searching all users, and returning DirXML-Associations for all objects. Then we searched the output for the user's Employee ID. You could probably could do this in a single-line statement if you're good at scripting.
Disclaimer: As with everything else at Cool Solutions, this content is definitely not supported by Novell (so don't even think of calling Support if you try something and it blows up).
It was contributed by a community member and is published "as is." It seems to have worked for at least one person, and might work for you. But please be sure to test, test, test before you do anything drastic with it.