SPR

Technote

Problem:
The causes for this issue depends on whether the issue occurs in a multiple
Domain environment or a single Domain environment.

Multiple Domain

An example of how this issue occurs in a multiple Domain environment is as
follows:

A user belongs to Domain A, and the administrator renames this user in Domain
A. After the rename is initiated, the user then accesses Server B in Domain B,
Server B looks at the user's updated Person document, and the authentication
triggers the Accept Rename dialog window wherein the user accepts the name
change. Server B, not knowing the user belongs to a different domain,
erroneously generates the next document in the rename process ("Rename Person
in Domino Directory") in its own Admin4.nsf rather than the Admin4.nsf in
Domain A. This is a problem because this document must be completed by the
Administration Server in Domain A in order for the rename to complete
successfully. This issue has been documented in SPR JNON5RHRKF.

SPR #: JNON5RHRKF was reported to Quality Engineering, and has been fixed in
Domino Releases 6.5.1 and higher.
Excerpt from the Lotus Notes and Domino Release 6.5.1 MR fix list (available at
http://www.ibm.com/developerworks/lotus):

SPR# JNON5RHRKF - In a multi-Domain configuration, replicas of the directory
could exist on servers in both domains. When these servers replicate the change
request will also exist in the replicated copy located in the other domain. If
a user authenticated with a server in the other domain there was nothing to
prevent the client from posting the "Rename Person in Domino Directory" request
into the other domains admin4 database. This fix prevents the client from
posting a "Rename Person in Domino Directory" request into another domains
Administration Request database. The request is only posted when the "domain"
field in the "Server Document", the "Person Record", and the "Client's Location
Record" match.




Single Domain

This issue was reported to Quality Engineering as SPR #JNON5SRT6J and has been
fixed in Domino Release 6.5.4 and higher. The fix is scheduled to be added to
the next release of the 6.0.x codestream.
Excerpt from the Lotus Notes and Domino Release 6.5.4 MR fix list (available at
http://www.ibm.com/developerworks/lotus):
SPR# JNON5SRT6J - Prior to this fix, after an Administrator renamed users and
the users accept their new name, 21 days later their names were reverted back
to their original name. With this fix, rename reversion will no longer be
automatic after the expiration period. The Administrator must now approve the
reversion.

Note: The document titled "Views To Assist In Diagnosis of Name Reverting
After 21 Days in Notes" (#4006431) contains a link to two views that will help
provide the following information for customers experiencing the issue whereby
changed user names revert to their original state after 21 days.
Which users are potentially affected by the "AdminPOld" reversion fields?
How long have the ChangeRequests have been outstanding (Change Request Date).
You can determine if the users fall in the 14 to 60 day range that is allowable?
The Home mail servers of the affected people. You can track down AdminP
requests on these servers.


This issue is fixed in Domino release 6.5.4

If upgrading is not an immediate option, the only known workaround is to
register the user with the desired name.

To actually fix this issue after it has occured:

Delete the user's Person document.
Register the person again.
Modify the new Person document to point to the old mail file.
Send the new ID to the user.

The old ID should be retained so that it can be used to access fields,
documents and or databases encrypted with its keys.


Supporting Information:
Note: You can rename a user with the Administration Process by selecting People
> Rename from the Tools pane of the Domino Administrator.
The following is an excerpt from the "Rename Person" section of the Domino
Administrator's Guide that shows the expected progression of the execution of a
Rename Request by AdminP:

"Initiate rename in Domino Directory
Triggered by: Choosing a rename action.
Carried out on: The administration server for the Domino Directory.
Carried out: According to the "Interval" setting for the Administration Process
in the Server document.
Result: Adds the new name, certificate, and change request to the Person
document. Prompts the person to accept the new name upon next server
authentication.

Rename person in Domino Directory
Triggered by: Person accessing a server and accepting the new name.
Carried out on: The administration server for the Domino Directory.
Carried out: According to the "Interval" setting for the Administration Process
in the Server document.
Result: Updates the person's name in the Domino Directory -- except for Person
documents. Posts the "Rename in Person documents" and the "Rename person in
Unread Lists" administration requests.

Rename in Person documents
Triggered by: Completion of the "Rename person in Domino Directory" request.
Carried out on: The administration server for the Domino Directory.
Carried out: According to the "Execute once a day requests at" setting for the
Administration Process in the Server document.
Result: Updates the name in Domino Directory Person documents.

Rename person in unread list
Triggered by: Completion of the "Rename person in Domino Directory" request.
Carried out on: Each server in the domain.
Carried out: According to the "Execute once a day requests at" setting for the
Administration Process in the Server document.
Result: Each server in the domain examines every database on the server and
updates the person's name in any unread lists.

Rename in Access Control List
Triggered by: Completion of the "Rename person in Domino Directory" request.
Carried out on: Each server in the domain.
Carried out: According to the "Interval" setting for the Administration Process
in the Server document.
Result: Each server in the domain updates the person's name in ACLs of
databases for which it is an administration server.

Rename person in Free Time Database
Triggered by: Completion of the "Rename person in Domino Directory" request.
Carried out on: The person's home server.
Carried out: Immediately
Result: The person's name is changed in the Calendaring and Scheduling Free
Time Database.

Rename person in calendar entries and profiles in mail file
Triggered by: Completion of the "Rename person in Free Time Database" request.
Carried out on: The person's home server.
Carried out: Immediately
Result: The person's name is changed in their mail file's Calendar Profile and
appointment documents. If the person's common name was changed and the common
name is in the title of the mail file, the mail file title changes to reflect
the new name. If the person is the "chair person" of any future meetings, the
name is changed in those appointment documents.

Rename in Reader / Author Fields
Triggered by: Completion of the "Rename in Person documents" request on the
administration server for the Domino Directory.
Carried out on: Each server in the domain.
Carried out: According to the "Delayed Request" setting for the Administration
Process in the Server document.
Result: Each server in the domain updates the person's name in Reader / Author
fields of databases for which it is an administration server and that have the
advanced ACL option "Modify all Reader / Author fields" selected.

Delete Obsolete Change Requests
Triggered by: Expiration of the period in which a person can accept a new name,
by default 21 days. When you rename the person, you can change the expiration
period.
Carried out on: The administration server for the Domino Directory.
Carried out: According to the "Execute once a day requests at" setting for the
Administration Process in the Server document.
Result: The Administration Process deletes the word "Pending" from the Change
Request field from the Person document."

ND6 AdminP person rename process flow and comments:


Request Processed
What happens
Initiate Rename in Domino Directory
Carried out on the administration server for the Domino Directory. This request
adds the"AdminpOld" fields in person doc.
Fail ? --> Rename Person in Domino Directory
Carried out on: The administration server for the Domino Directory. This
Request is posted to the admin4.nsf of the server that is first accessed and
must be replicated back to the admin server. Successful processing of this
request triggers the creation of all subsequent requests.
Fail ? --> Rename in Person Documents
Carried out on: The administration server for the Domino Directory. This
request must be processed to remove "AdminpOld" fields in person doc.
Rename Person in Unread List
Carried out on: Each server in the domain.
Rename in Access Control List
Carried out on: Each server in the domain.
Rename Person in Free Time Database
Carried out on: The person's home server.
Rename Person in Calendar Entries and Profiles in Mail File
Carried out on: The person's home server.
Rename in Reader / Author Fields
Carried out on: Each server in the domain.
Delete Obsolete Change Requests*
Carried out on: The administration server for the Domino Directory. This
Request checks for AdminpOld and Change Request fields in the person docs.

AdminP Old Fields in Person docs:

"AdminpOldCertificate"
"AdminpOldFirstName"
"AdminpOldLastName"
"AdminpOldMI"
"AdminpOldFullName"
"AdminpOldOwner"
"AdminpOldAltFullName"
"AdminpOldAltFullNameLanguage"
"AdminpOldInternetAddress"
"AdminpOldShortName" More >