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"> <source> <product version="188.8.131.5270719 ">DirXML</product> <contact>Novell, Inc.</contact> </source> <input> <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"> <association>E123456</association> <add-attr attr-name="Description"> <value timestamp="1194374545#2" type="string">Jane Smith</value> </add-attr> <add-attr attr-name="Employee ID"> <value timestamp="1188460099#11" type="string">E123456</value> </add-attr> <add-attr attr-name="Full Name"> <value timestamp="1194374485#5" type="string">Jane Smith</value> </add-attr> <add-attr attr-name="nspmDistributionPassword"><!-- content suppressed --> </add-attr> <add-attr attr-name="OU"> <value timestamp="1189235553#34" type="string">User Services</value> </add-attr> </add> </input> </nds> [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 ------------------- Driver: \ACMEIDVAULT\acme\services\ACMEFLAT\ACME-APP Channel: Subscriber Object: \ACMEIDVAULT\acme\employees\active\JSmith Status: Error 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 NetIQ Cool Solutions, this content is definitely not supported by NetIQ, so Customer Support will not be able to help you if it has any adverse effect on your environment. It just worked for at least one person, and perhaps it will be useful for you too. Be sure to test in a non-production environment.