ok, I have read some other posts similar to my issue, but wanted to describe what’s going on with my users.
I have used the rename process to move users to a new certifier, went into admin4 and approved the move and some have been successful and others not.
Admin4 shows the rename initiated and performed in the DD, but when the user connects to their home server they are never prompted to accept the name change so the rest of the adminp process doesn’t complete. There are no errors in admin4.
The person doc shows change pending for the users that haven’t been prompted to accept the new cert.
Any ideas what else to look for? I have restarted the adminp task.
something even more curious! I created a new ID, selected rename, move to new certifier, approved the name move in admin4, let adminp run, switched to the new ID file just renamed and the name change was accepted.
I try this with an old, maybe 5-7yrs older, and it gets renamed in the DD, but the ID never tries to accept the name change.
Could there be something in pre-7 ID files that is weird?
Some of these ID files have been around since the R4 days or maybe even longer. We used to have a flat structure way back when and we converted to heirarchical a few years ago, I wonder if something is left that adminp just doesn’t like!
no, we’ve got IDs dating back to R4 days and they have been recertified, moved to new certifier many times over so I don’t think it has anything to do with the IDs being old. However, I don’t believe any of out IDs used to be flat so you may have hit upon something there. Can you verify that all of the IDs not accepting the updates used to be flat at some point> If so it may be worth a call to IBM support.
The following changes to the address book person record fixes the stalled rename process. No need to back out and re-apply name changes, it unclogs adminp like a plumber’s helper.
ok, so another update. We removed the person doc for a user not being prompted to accept the name change, removed the adminp requests, recreated the person doc manually, pasted certificates from ID file, requeued the adminp rename/recert task and it processed normally!
So, it looks like there is something weird in the person docs that won’t allow adminp to finish properly.
So if anyone has any ideas as to what to look for I would greatly take any input. I will re-post if we find the culpret. Don
try comparing all of the fields in the old person docs with fields in 1 of the new person docs that you create and see if there is anything that jumps out as different.
users don’t actually get a physical prompt any longer, it should just happen automatically when the user reauthenticates with their home mail server. Have the user close their client then launch n Notes and log in and open thir mail file, this should make the update happen. If it still does not kick off then extract the user’s Public Key from their ID and compare it to the Certified Public Key stored in their person doc. If the keys don’t match then the ID will not update. At this point you would need to back out the rename request (best to delete the rename request docs and restore the person doc from a backup), then copy the users Public Key from their ID into the restored peson doc, let this replicate to the admin server of the DD and then try renaming the user again, HTH.
I left out that we are still using the R5 client against a 7.0.2fp2 server. We are in the process of upgrading to 7 clients.
I have tried the above. Before issuing the rename the public keys matched, once I issued a rename a new public key was issued and put in the users person doc, which I assumed was normal when switching certifiers. Anyway, the client still does not get prompted, nor when I am using a 7 client is it automatically accepted.
how many people did you rename and how many is this happening to? this is just a shot in the dark but try disabling the user’s alarms in their mail file: open the mail file and select Actions, Tools, Preferences; then switch to the Calendar tab, and then the Alarms sub-tab. Uncheck the “Enable Alarms” property.