Working on a migration from GroupWise 7 to 8 using IDM because the client is simulatenously moving to a new restructured eDirectory. Realized the IDM driver cannot do the function of grafting the users, I have worked around the limitation of the GroupWise driver that it cannot do a graft. The way the process will work is that the client will migrate all the users into a "Migrated" container while the GroupWise IDM driver is down. We will graft them all there, then bring up the driver. This works, I have tested it, and the user can then log in via LDAP using their eDir password.

Problem is that the client wants to now move the user to a real context, And this does appear to work, the IDM driver knows it's a move, Logging in with the GroupWise client returns the dialog "LDAP failure detected" apparently because it does not update the LDAP context. I put in a policy to handle this:

<description>[WATTS] Synth LDAP DN</description>
<if-operation mode="case" op="equal">add</if-operation>
<if-operation mode="case" op="equal">modify</if-operation>
<if-operation mode="case" op="equal">move</if-operation>
<if-operation mode="case" op="equal">rename</if-operation>
<do-set-dest-attr-value name="59028">
<token-parse-dn dest-dn-format="ldap">
<token-xpath expression="@qualified-src-dn"/>

And with this you see the updated LDAP context in the GroupWise-->Account tab is corrected in the user object in ConsoleOne but the authenticaiton behavior is unchanged - I still cannot log in once the user is moved to a different context.

In the object API there is a method to do this, and I wrote some VB to invoke it but I don't want that to be my method to do this because the client wants to control everything from AD now.

Not allowing a user move is not an option.