IBM Support

Procedures for renaming a Domino server or migrating to a new Domino server

Technote (troubleshooting)


What are the correct procedures for renaming a Lotus Domino® server? How do you migrate all users/applications from one Domino server to another?

Resolving the problem

Instead of just renaming a server, the best procedure is to create a new Domino server and migrate your data and users to the new server.

Renaming a server is not covered by any "adminp" process except for converting from a flat to a hierarchical naming convention. Renaming all existing fields in all replicas is a tedious task, even if you use agents. Refer to the Domino Administrator Online Help topic, Moving Databases.

NOTE: In the approach described below, you will add a new server to the existing Domino domain and then move the Domino environment and users to the new server with new server name. This process assumes that the new server will have a different IP address from the original server. For information on how to move a server from one system to another on the i5/OS or i operating system, refer to Document #1092419, "How to move a Domino server on i from one system to another ."

1. Register a new server with the desired server name. Be sure that your server name is a single string of alphanumeric characters (no periods or underscores).

2. Configure your network adapter to use the correct IP address for the new server. If you are configuring an additional partitioned server on the i or i5/OS operating system then you can create an additional interface for the IP address you will use for the new server. Also add the host name and IP address to the host table on the server. For assistance with this step, refer to your operating system's help. For i or i5/OS, refer to the Information Center at:

3. Add the new host name and IP address to your internal DNS. This will give your Notes clients the ability to resolve the new server name.

4. In order to run multiple Domino servers on a system, each server must be bound to its own port/IP address. If you currently run multiple partitions on this system, you can skip this step.

If you currently run one Domino server on this system, you must ensure this server is bound to an IP address. For help on binding your server to a specific IP address refer to the Domino Info Center Topic "Binding an NRPC port to an IP address".

5. Configure your new Domino server using your preferred configuration method.

6. Start your new server and verify you can access both the existing and new server.

NOTE: HTTP is not automatically bound when the NRPC port is bound. You may need to bind http at this time, especially if you are running more than one Domino server on this machine or partition. This configuration is found in the Server document. For more information refer to the Domino Info Center Topic "Binding an Internet Service to an IP address".

7. Review the Configuration Document for the old server and compare it to the new server. Make any necessary changes for the new server. Don't forget the SMTP inbound relay controls.

8. Review your existing connection and cross-certificate documents for the existing server. Create equivalent documents for the new server. Also, if you have connection documents for replication with other servers in your domain, you must verify that the new server has the appropriate authority on the other servers.

9. Review the notes.ini file for both servers. Are there any special settings that you must add to your new server? Remember to restart your server after making any .ini file changes.

10. Review the Server Document for both servers and ensure any custom settings on your existing server are set on the new server. This includes setting up directory assistance, directory catalog, and transaction logging. The steps below will help you work through this process.

a) Review the Security panel for both servers and set the appropriate values for the new server. Ensure that both servers have authority to create new and replica databases on the other server. You may have to modify the Server Document of the existing server in order to grant the new server access to the existing server.

b) If you are currently using Secure Socket Layer (SSL), you must create a new key ring for the new server. To review the SSL settings of the existing server, refer to the Ports --> Internet Ports panel.

c) Review the security settings for all ports. Are some ports disabled? Do you allow "anonymous" on all of the ports?

d) Compare all Server Task panels with the existing Server Document and make changes as appropriate.

e) Bind HTTP to the new host name, located on Internet Protocols --> HTTP panel. If the existing server is not bound, you must bind that server as well or HTTP cannot run on the new server. Also compare the configuration settings on all panels under Internet Protocols to ensure a matching HTTP configuration.

f) Review and compare the MTAs, Miscellaneous, Transaction Logging, and Administration panels. Make any necessary changes.

g) If you are using directory assistance, replicate your directory assistance database and any secondary address books located on your existing server. You may have to modify the directory assistance database to point to the new replicas. Once you modify the directory assistance database and created the replicas of the secondary address books, you can change the Server Document to use the directory assistance database (on the Basics panel).

h) If you are using a directory catalog, replicate your directory catalog to the new server. If your existing server was the aggregate server for the directory catalog, you must also modify the settings on the Server Tasks --> Directory Cataloger panel. Be sure to change the Directory Cataloger panel on both servers. The "dircat" task should only update the directory catalog on one server . Otherwise, replication conflicts may occur.

i) If you have configured Sametime awareness in DWA, be sure the hostinfo.js file on the new server reflects the correct server configuration. You will find the hostinfo.js file in the domino/html/Sametime/STLINKS subdirectory of your server.

11. If you are using your Domino server as a web server, consider the following steps:

a) Manually copy or FTP any HTML or other files to the new server's Data directory. By default, these files are placed in the /Notes/Data/Domino/html directory where /Notes/Data represents your server's Data directory. If you are using Domino's servlet engine, don't forget to move any servlets that may be placed in the Servlets directory.

b) Review your web Configuration documents and create any needed redirection, file protection, and other documents.

c) If you are using Single Sign-On (SSO), add your new server to the WebSSO document as appropriate.

d) If you are using a custom log-in form, be sure to copy domcfg.nsf to your new server or create a new domcfg.nsf database.

12. Replicate names.nsf between your servers and restart both servers to ensure you have the most current configuration data on both servers. Assuming you are using a unique IP addresses, you should now be able to access HTTP on both servers.

13. If you have a resource reservations database configured, you must move this database. Note that special considerations must be made when moving this database. For more information, refer to Document #1102642, "Moving Rooms and Resources from one Domain to Another Without Losing Reservations."

14. Determine if the new server must be added to the access control list (ACL) of any database that the server will access. Use the catalog.nsf database on the original server to help you review the databases to which the existing server had explicit access. Once you determine these databases, you can decide if you should add the new server to the ACL.

NOTE: The new server should be automatically added to the LocalDomainServers group, allowing access to most databases via this group. However, an explicit entry will override the LocalDomainServers group entry.

15. You now want to replicate between your existing server and new server to ensure your changes are made to both servers. At a minimum, create a Connection Document to schedule replication for names.nsf and admin4.nsf. This is important when using the administration process to move standard Notes users to the new server.

16. When you are ready to start receiving inbound mail, ensure that the appropriate MX and A records are added or changed on the DNS server.

17. Now you should migrate your users and applications to the new server. Special considerations should be made based on the type of users and applications you use. The users/applications are divided into the following groups: Standard Notes Applications, Custom or third-party Notes Applications, Standard Notes Mail Users, Domino Web Access Users, Domino Access for Microsoft Outlook Users (DAMO), and Web Applications. Refer to the appropriate section(s) for your environment.

18. Review all configured Program documents and change the "Run on server" parameter to be the new server or create additional Program documents for the new server.

NOTE: Other job schedulers should be considered as well, including third-party, WRKJOBSCDE for IBM i or i5/OS, and the notes.ini ServerTasksAtX lines.

Migrating Standard Notes applications

1. Reports: Replicate the reports database to the new server, ensure message tracking is enabled on the new server if it was enabled on the original server, and check the "run on" value for the agents.

2. SSL databases (Server Certificate Authority and Domino 5.x Certificate Authority): Replicate the databases to the new server and create a key ring file for the new server if not done up to this point.

3. Administration process: Modify the Administration Server name in the ACL of the databases (skip this step for standard Notes mail users).

4. DOLS: Create the appropriate security policy in the doladmin Offline Services database.

5. DDM/Stats and Events: Configure any probes and monitors configured on the old server in your events4.nsf database.

6. DECS: Replicate the decsadm DECS Administrator database and review Connection/Activity documents.

Migrating Custom or third-party Notes applications:

1. Contact the product vendor for assistance, if appropriate.

2. Replicate the application to the new server.

3. Review/test the application to ensure it will run on the new server. Some considerations to make are:

    -- Is the server name hard-coded?
    -- Is there a Profile Document that must be updated?
    -- Is the "run on" value for agents correct?

4. Notify the users of the server change

Migrating Standard Notes mail users:
NOTE: These steps cover the Move Mail File option in the Notes Administrator client.

1. Open the Administrator client --> People and Groups panel.

2. Select the people to move and click Move Mail File. Follow the prompts to complete the process.

The move will be completed by the administration process and be transparent to the users. As part of this process, the client's Location Document is updated.

Migrating Domino Web Access (DWA) users:

1. Replicate the mail file to the new server.

2. Give users the new URL for their mail files or configure a Domino Web Access redirect database. For assistance refer to the Domino Info Center topic " Using Domino Web Access Redirect to access mail in Domino Web Access".

3. If the user is an off-line user, he/she must download a new subscription to continue working off-line.

NOTE: If switching the URL is not possible, you can set up a virtual server on the new Domino server so it can use the old URL. For additional information refer to the Domino Info Center topic " Hosting multiple web sites on a partitioned server".

NOTE: You can also use the Administration process to move the users to the new server, however you should be aware of technote 1192453 " AdminP requests to 'Move Mail File' do not complete for Domino Web Access users "

Migrating DAMO users:
There is no direct migration for DAMO users. They must uninstall and reinstall DAMO. For more information see " DAMO does not recognize mail file move by Administration Process".

Migrating Web applications:

1. Contact the product vendor for assistance, if appropriate.

2. Replicate the application to the new server.

3. Review/test the application to ensure it will run on the new server. Some considerations to make are:
    -- Is the server name hard-coded?
    -- Is there a Profile Document that must be updated?
    -- Is the "run on" value for agents correct?

4. Consider how the new URL will be handled. Can you send a new URL to the users or must you set up a virtual server on the new Domino server so all existing URLs will be usable? If you need to be able to use both the old and new IP address or host name, refer to the Domino Info Center topic " Hosting multiple web sites on a partitioned server".

Related information

How to move a Domino server from one iSeries system to
Moving Rooms and Resources from one Domain to Another W
Steps to reinstall a Domino server or to move a Domino
AdminP requests to 'Move Mail File' do not complete for

Historical Number


Document information

More support for: IBM Domino

Software version: 6.0, 6.5, 7.0, 8.0, 8.5, 9.0, 9.0.1

Operating system(s): AIX, IBM i, Linux, Solaris, Windows

Reference #: 1102494

Modified date: 23 November 2009

Translate this page: