I ran into a problem the other day and I thought I would share the solution. I have encountered it before elsewhere, and that means others have encountered it before as well. Before I dive into the problem, I just want to say something to James. When Bex wrote about ECM systems storing Content, not Users, he presents a powerful and logical argument. Outside of the lab, I’ve had several clients where the network wasn’t ideal, and we were more than happy to store a copy of the user information inside of Documentum, only talking LDAP for authentication. I know the solution should be to fix the network, but sometimes that isn’t entirely possible. That is another story.

[REVISED 2007-8-03 (I hate this network)]

Here was my problem. At some point, the LDAP Synchronization job was interrupted during an update. [The cause is external to Documentum and is not confined to one user] The problem was that it had imported the new users, but hadn’t gone through the groups and added the new users appropriately. How do I know? Simple. I had a user that was in the system, but had no rights. I could add the user manually to the group, but the next synchronization would undo it.

Why did this happen? I now suspect that somewhere in the routine, it checks the timestamp of the last change and adjusts accordingly. In this way it is only bringing in the changes. However, it was removing my manual fix.

The Solution

Well, my first thought was to just have the network admins remove the user from the group in question, save the change, and then add them back. Of course, finding a network admin turned out to be a challenge. So I started trying to determine what I could do to fix the situation. What follows is what I did, but in retrospect, I am sure that a few of the steps may not be required.

1. First, I deleted the user to see if the user would be recreated correctly. The user couldn’t use the system, so there was no real fallout from trying this. I re-ran the LDAP job and had no change. Note that I didn’t just delete the user. I merged the user into a new temporary user in order to preserve all recorded actions and content ownership. This probably wasn’t necessary, but is a good safe practice. Note that if I didn’t have my own user source, I wouldn’t have been able to create a purely local user. [NOT NEEDED]
2. I decided that the LDAP job was tracking things elsewhere besides the dm_user tables. I located the userguid_map table listing the User Name and the globally unique identifier. I removed the appropriate row, but no dice. [NOT NEEDED]
3. I then realized it had to be because the LDAP object had not changed since the last synchronization. So I decided to fool the system.
   • I updated the dm_ldap_config_s table, setting the a_last_run field to a date from a week ago. I was careful to only change the date and not the time.
   • I then did the same for the job definition, though I suspect that the LDAP Configuration is the driving force. I updated dm_job_s table, setting a_last_invocation and a_last_completion on the dm_LDAPSynchronization job to the same date as the LDAP Configuation. Once again I left the time untouched. [NOT NEEDED]
   • I reinitialized the Server Object. This was probably not necessary, but I wanted this to be done and it wasn’t going to hurt the system to do this additional step. [NOT NEEDED]
   • I ran the job and IT WORKED!!! The user had all the appropriate groups assigned.
4. The last step was to reassign the temporary user account back into now, working user. This restores everything and removes the temporary user account. This step is only required if you reassigned the user in Step 1. [NOT NEEDED]

The Next Time

I ran into this again, so I have updated this. You only need to trick the LDAP Configuration to go back in time. The other steps I am leaving documented because they reflect what I did, and they made add some insight to some people facing other problems.

On a side note, removing the group would have the same impact as removing the user. The user approach has the benefit of only impacting the already broken user. If the user has a lot of existing content, removing the group, through the same reassignment process, may be a better approach. However, with a highly populated and utilized group, it isn’t something that you just want to play with if you don’t have to do so.