Rules to follow when you change a Notes name

When you change a user’s Notes® name, you must follow these rules.

  • Before you change a name, use the Rename Report tool to check for errors that can prevent successful renaming. For more information, see the first step in the topic Changing a Notes user name .
  • Check the Advanced ACL settings of your on-premises Domino® Directory to see what action you allow for the Administration server. For a Domino Directory, this should be set to Do not modify Names fields. Failure to set this field properly might result in the previous name be removed from the user's Person document before the new name has been fully processed. To check the setting, open your Domino Directory and click File > Application > Access Control. On the Advanced tab, in the Administration Server section, select Do not modify Names fields for the Action.
  • If you want to change multiple parts of a user's name, do so in one rename request. Do not issue one request to change a common name and then a separate request to change a certifier name. For example, change Samantha Daryn/Renovations to Samantha Brown/Power Renovations with one rename request.
  • To change both a user's name and Internet address, change the Internet address as part of the rename request. Do not issue a rename request for the name change and then edit the Person document separately to change the Internet address.
  • Never start a second rename until the first rename is complete, for example, if you make a mistake in a rename request. Wait until the first rename is complete and the user accesses the service under the first changed name before you rename the user again. If the first rename is not complete, fields with names that begin with AdminpOld remain in the Person document.
  • Never change the Notes name by editing the name manually in the Person document. Instead, always initiate the name change through the Domino Administrator client. When you use the Domino Administrator client, the Administration Process makes the changes throughout your environment and required directory changes can replicate to the service during directory synchronization.
  • Never rename a user who is being provisioned or whose mail is being transferred to the service. Wait until the user accesses the SmartCloud Notes service at least one time under the current name before you rename the user.
  • If a rename does not complete within a reasonable amount of time, contact SmartCloud Notes Support. Do not remove the user account, the SmartCloud Notes subscription, or the Person document and attempt to re-create a user.
  • After you start a rename of a Notes client user, tell the user not to switch to a Location document that refers to an on-premises mail server. Doing so can cause the user to accept the new name on-premises rather than in the service, which is not allowed.
  • Never rename a user at the same time that you change the user’s Domino domain.
  • If the user has a Notes ID file and uses it in the service, the ID file must be stored in the service ID vault before you rename the user. To determine whether a user ID is stored in the vault, open SmartCloud Notes Administration, click Users, search for the user page, and look at the Notes ID file field. If the ID is not in the vault, an administrator can upload the ID file to the vault manually from the user page in SmartCloud Notes Administration.
  • If the rename includes a move to a different certifier, verify that the directory contains a Vault Trust Certificate issued from the new certifier (or an ancester of the certifier) to the service ID vault. If such a certificate does not exist, create one and wait for directory synchronization to replicate it to the service before you rename the user.
  • A web client user or Traveler user can have a Notes ID file that is never used in the service and that is not stored in the service ID vault. Before you rename a user such as this, either upload the ID to the vault or delete the public key information from the following fields in the user’s Person document:
    • Certificate
    • CertificateExpiration
    • CertificateIssuer
  • If the name of a mail file delegate changes, the mail file owner must reassign delegation to the new name. Doing so updates the mail file ACL to allow the delegate access under the new name.