Hat die Sachbearbeiterin schon bestätigt ? Oder womöglich abgelehnt !? Hat die Userin überhaupt die Meldung bekommen?
Es kann u.U. hier dran liegen:
Why Does the Renaming Process Using AdminP Stop?
Problem:
You are renaming a user using the Administration Process (AdminP). After the initial prompt to accept the new name, the request stays in the Admin Request database and nothing further seems to happen. The Person document has a state of "Pending" in the Change Request field. There are no error messages.
Solution:
This issue occurs because the ID file(s) and the Person document(s) are out of synch. Examining the ID file reveals that there is a mismatch in the public key of the Person document and the public key of the ID file. How does this happen?
In one particular case, the customer had an Admin department that tried to make things easier for their users. After starting the rename process, the Admin staff used a backup copy of the user ID, logged in and accepted the name change on behalf of the user to set the rest of the Admin Process off.
This will work fine the first time around; the AdminP process completes, and the Person document goes back to a change request status of "None. "
However, if there is another name change, or a change in the user's unique organizational unit, and the Administrators again kick off the process by logging on with the backup copy of the ID file, this is when the problems occur.
Though the first name change has been fulfilled, the ID files are not in synch, and even though you can perform parts of the name change process, not everything goes through, and the change name request gets stuck in the Admin Request database.
Why does this happen? After the name change has completed the first time around, the ID file is actually updated with all the new information from the Person document, around 21 days after the final stage of the Administration Process; the same time that it changes the status of the Admin request in the Person document to "None."
This final change is reflected in the ID file that is used, and therefore does not update a backup copy. Next time you use the backup copy, though it works to log in, it is not fully updated. If the user is an infrequent user, the first name change will go through, but the user's ID file may not be updated with final changes. That way, no ID file will be fully correct and the public keys will not be in synch. The problem is that you are using two ID's (that are supposed to be the same, but are not) which are both partially updated.
If you look at the backup copy of the ID file, you will see it contains the old and the new user name. After AdminP has completed, you can use the backup copy to log in. Next time you look at it, you will see that the old name has vanished.
It is important that infrequent Notes users do log on during this process so their ID's are updated correctly. The user should also mail their ID's, to be used as a backup when everything is completed.
Andreas
