Previous Page TOC Next Page



— 12 —


Migrating from Notes 3.x


You should approach your migration with the same careful planning that you used with your initial installation. Careful planning for your migration can help prevent critical problems later on. Before starting your migration, you need to familiarize yourself with the new features in Notes Release 4.

This chapter lays out a standard plan for migrating your installation to Notes Release 4. Migrating can be a large job, and before diving in you should consider whether Notes Release 4 is the correct platform for you.

This chapter covers the following topics:


Why Migrate?


Lotus certainly acts as if it's a foregone conclusion that you will migrate your Notes installation to Release 4, but this isn't necessarily the case. Migrating to Release 4 involves retraining your support staff and end users, in addition to a considerable amount of planning and time to carry out the migration. Before migrating to Release 4, organizations should review their use of Notes to determine whether a migration to Release 4 is the best investment of their support staff's time.

You certainly will want to migrate to Release 4 if:

Medium and small organizations need to do some rough cost/benefit calculations before migrating to Release 4. Even if you decide that moving to Release 4 is a smart choice for your organization, the timing of the move can be important. Waiting for an update to Release 4 may make sense for any organization, large or small, that uses Notes to run mission-critical applications.

If you are currently experiencing problems with Notes Release 3, migrating quickly to Release 4 makes sense. Migrating to Release 4 often is easier than upgrading current Release 3 servers. If you plan to upgrade your Release 3 servers to the latest Notes Release 3 software, consider migrating to Notes Release 4 instead. Notes 4 servers can coexist with Notes 3 servers and clients without problems, and should prove to be a more stable platform over time.

Migration Overview


A Notes migration follows an eight-point plan similar to the eight-step plan for installing Notes described in Chapter 5, "Building a Deployment Plan," and Chapter 6, "Customizing Your Deployment Plan." The major difference between migrating and an initial install is that, when migrating, you upgrade your applications after installing Notes software, instead of developing applications before installing. Each of the steps that you followed during an initial installation should be redone during a migration. The eight steps in a migration plan are as follows:

  1. Create the migration team.
    The same team that you used to administer Notes, plus power users and IS executives, should be involved in a major systems migration such as migrating to Release 4.
  2. Assess the current installation.
    You need to reassess all your current plans regarding Notes, as well as take inventory of your current hardware and software installations.
  3. Train your support organization.
    Your entire Notes support staff should be trained, including administrators, application developers, and help desk personnel.
  4. Design your Notes network.
    Notes Release 4 has several features that can affect the topology of your Notes network. In addition, if you haven't already migrated to hierarchical naming, you should begin planning now.
  5. Update the standard operating procedures.
    Many of the procedures administrators carry out will change after you have installed Release 4. You need to update any documented procedures to reflect the new capabilities that Notes 4 delivers.
  6. Upgrade your Notes network.
    In this step, you actually install hardware and software on your system.
  7. Upgrade your applications.
    After you have converted your Notes network (or at least a few workgroups in a geographical area) to Release 4, you should begin upgrading applications to take advantage of Notes 4 features.
  8. Convert to hierarchical naming.
    Hierarchical naming offers many advantages over flat naming, and many of the disadvantages have been minimized with new administrative tools. Therefore, the author strongly recommends that all organizations convert to hierarchical naming after migrating to Release 4.

The following sections discuss each of these steps in detail. You also should review the chapters in Part II of this book, "Planning Your Notes Installation," before carrying out a migration.

Creating a Migration Team


A Notes migration team resembles a Notes installation team in many regards. The political aspects of migrating are far less important than those involved in initial installation, so the choice of project leader isn't quite as important. You also don't need a Notes evangelist as part of the migration team. A migration team should include the following members:

Large organizations may have both a Notes Release 3 administrative team and a separate migration team at one time. Medium or small organizations most likely will need to carry out the migration to Release 4 while maintaining the current Release 3 network. Consider adding some temporary personnel to the administrative team to help handle the load during the migration period. This method can benefit your organization by getting your organization up to speed with Release 4 faster than otherwise possible.

Assessing the Current Installation


The first thing you need to assess are your current plans regarding any Release 3 installations in progress. Consider whether it's worth the time to continue installing Release 3 software and then migrate it to Release 4 in the near future. In some cases, switching to Release 4 rather than continuing to install Release 3 software makes sense. Testing Release 4 in your environment before installing it may cause an unacceptable delay for some high-priority planned installations. But there is no other reason to continue installing Release 3 software rather than switching to Release 4. Release 4 clients can access Release 3 servers. Release 4 servers can support both Release 3 clients and servers. Replication mail routing works correctly in a mixed environment.

You also need to do a skills assessment as part of your migration planning, in order to develop a proper training plan. This step should be far easier than your initial Notes installation because all your users should be knowledgeable about Release 3 features and know how to operate a mouse in a graphical environment.

You also need to assess your current installed base of hardware and software. Follow the steps outlined in Chapter 7, "Determining Hardware and Software Needs," just as if you were installing Release 4 on brand new machines.

Training Your Support Organization


You need to train your administrators, application developers, and help desk personnel before you attempt to develop a comprehensive migration plan. Computer base training is sufficient for many of your support staff. You also can contact a training organization if you want on-site training.

Designing Your Notes Network


Notes Release 4 contains enhanced replication and new mail features that can alter your network topology. In particular, if you aren't already using a hub-and-spoke architecture or hierarchical naming, you should plan to convert now. Chapter 9, "Designing Your Notes Network," contains all the details you need to consider when developing your naming schemes and network topologies, but here is a summary:

You also can bundle other tasks into your migration, such as changing your operating system.

Updating Standard Operating Procedures


The procedures that change when you migrate to Release 4 are those concerned with certifying users, changing names, and issuing cross certificates. The Administration Process handles many of the tasks that were done manually in the past. Although you can register users and servers the same way as you did for Release 3, the Administration Process is designed to ease these tasks. You should update your standard operating procedure for handling employee terminations. Use the Administration Process to delete users from database and server access control lists.



When handling employee terminations, be sure to check the Administration Request Database to see that the request to terminate the employee has been completed. When you delete a person record from the Name and Address Book, you must use the button Delete Person rather than the Delete key. Pressing the Delete key doesn't generate a request in the Administration Request Database.

Cross certificates now can be issued over the phone. This system eliminates the need to exchange any media or even to have your computers connected at the time cross certificates are issued. Other standard operating procedures—such as backing up servers, monitoring the Notes log, and restoring the Public Address Book—don't change.

Upgrading Your Notes Network


Following are the steps involved in upgrading a server:

  1. Upgrade all hardware and software.
  2. Do a complete backup of the server.
  3. Install the Notes software.
  4. Upgrade the Public Address Book.
  5. Configure statistics and events monitoring.

The first step in upgrading your Notes network is to complete your planning. Before proceeding you should have a complete plan showing when all servers and clients will be upgraded. This plan should include all servers and clients that will be upgraded in the first eight weeks of your migration.

Your migration implementation should proceed by upgrading your servers first, followed by your clients. By upgrading your servers first, you minimize impact on end users and decrease the amount of effort required to perform the migration. Notes Release 4 servers have tools available to help you update and migrate client machines. All Release 3 clients can access Release 4 databases on Release 4 servers. Users shouldn't notice that the server has been upgraded to Release 4 or that databases stored on that server have been converted to Release 4 format.

You should develop a complete schedule for your servers and client upgrades. Client upgrades should be coordinated with your training schedule so that each end user receives training within 48 hours of his or her machine being upgraded. During the initial install, you had a way of enforcing the requirement that users receive training before receiving Release 4 on their machines. You could refuse to issue an ID until they received their training. You no longer have this option if users already have their IDs, so you have to rely on persuasion to get users into training. Release 4 is just different enough that users should receive some training before you begin to upgrade applications to use new Release 4 features.

Performing System Tests

Before installing any hardware or software, you should upgrade your test environment to Release 4. Test out a representative sample of your applications. Do a complete test of all third-party products (such as mail gateways and application-development tools) that you use in your environment. Contact the company from which you purchased your products for Release 4 upgrades. After you have tested all your gateways and a representative sample of your applications, you are ready to proceed with installing hardware and software.

In addition, test a sampling of your other applications, such as noncritical work flow and simple discussion databases. You should accomplish your testing before migrating a single production server to Release 4.

Upgrading the Hardware

You should have a complete list of your hardware and software upgrades required from Chapter 9, "Designing Your Notes Network." Now is the time to upgrade hardware on your server machines. You can begin to upgrade hardware on client machines as the machines become available. Try to upgrade the hardware and software on any laptops as they become available during the migration. After you have upgraded the hardware, update the operating system and network software on your server machines.

Upgrading the First Server

Before upgrading any server, perform a complete backup. Back up all Notes databases, as well as DESKTOP.DSK; NOTES.INI; all IDs, including server, user, and certifier IDs; the Public Address Book (NAMES.NSF); the Notes log (LOG.NSF); and the server's mailbox (MAIL.BOX). In addition to these databases, back up any Notes-supplied templates that you have customized, and all directory link files and database redirection files.

The first server upgrade differs from other server upgrades in that you need to upgrade the Public Address Book on the first server where you install Release 4. You should upgrade the Public Address Book on only one server, and then replicate these changes to other Release 4 servers.

After upgrading the hardware, operating system, and networking software on a server and completing a backup, install the Notes Release 4 software. Install the software in the same directories as the Release 3 files, following the steps in Chapter 10, "Installing and Configuring Notes Servers."

After you have completed the install and setup for Notes Release 4, manually copy any customized views or forms from your Release 3 template to your Release 4 template. You should never completely replace a Release 4 design element. Instead, modify existing elements, using your Release 3 customizations as a guide. For example, if you modified the people view in the Public Address Book, don't copy the customized Release 3 people view directly into the Release 4 Address Book. Instead, take each of your customizations, including a selection formula, and so on, and enter that information into the existing people view in your Release 4 Address Book. When updating forms, copy your customized fields directly into Release 4 templates rather than copying the entire Release 3 form. You also may need to edit the NOTES.INI file. You can use any of the methods outlined in Chapter 13, "Administrative Tools," for editing the Release 4 NOTES.INI file.



CAUTIONCAUTION
Never copy a Release 3 NOTES.INI file directly over a Notes 4 INI file.


The one file you shouldn't need to update is your desktop. DESKTOP.DSK isn't changed during the install program.

The first server you upgrade should be a hub server. By upgrading a hub server first, you minimize problems when replicating your new Public Address Book. You also avoid potential problems with end users acccessing a Release 4 server before you’ve tested it in your production environment.

Upgrading the Public Address Book

Upgrade the Public Address Book in each domain. Notes automatically replicates the changes as you install other Release 4 servers. If you are using cascaded address books, upgrade each of these databases on the first Release 4 server.

You upgrade an address book with these tasks:

To upgrade the Public Address Book, follow these steps:

  1. Start the workstation program on the Release 4 server.
    Notes asks whether you want to upgrade the Public Address Book.
  2. Select Yes.
  3. Select the Public Address Book from the workspace.
  4. Select Actions | Add Admin Roles to Access Control List.
    This step copies all roles from the Release 4 Address Book template to your current Address Book.
  5. Select OK.
    You are now ready to apply these roles to individuals in the access control list.
  6. For each entry in the access control list for the Public Address Book, specify the roles in which that entry should participate.
    Administrators who currently have editor access to the Address Book should be given author access with the ability to create documents. Administrators with editor access have full ability to edit and change all documents in the Public Address Book, regardless of the roles that they are assigned. To take advantage of the roles in the Public Address Book, you need to limit access to the author level. Not all organizations will want to use roles in the Public Address Book. Review Chapter 13, "Administrative Tools," to decide whether you should use roles in the Address Book. For general information on roles, see Chapter 3, "Understanding Security."
    After you have updated the access control list so that members are assigned proper roles, you need to update all documents in the Address Book. The design of these documents, and the documents themselves, must have fields added to them so that administrators can carry out their tasks.
  7. For each view in the Public Address Book, open the view, select the documents in the view, and select Actions | Apply Delegation to All Entries.


    TIP Do these tasks during off-peak hours, as updating all the documents in a large view can take some time. You may need to perform this step over a period of several days or weeks, depending on the size of your Address Book.

  8. Shut down the workstation software.
  9. Make sure that the Notes server is shut down.
    You are now ready to update the views and file format of the Address Book. Because both the workstation and the server always have the Address Book open, both of them must be shut down. This means that you must update the views and convert the file format from an operating system command prompt.
  10. Rebuild the views in the Public Address Book by entering one of the following commands:
  11. Enter your Notes ID password.
  12. To convert the Public Address Book to Release 4 format, run the Compact program from an operating system command line by entering one of the following commands:
  13. Enter your Notes ID at the prompt.

Before converting the file format of the Address Book, make sure that you have enough disk space to run Compact. In order to run on a database you need to have at least enough free disk space to hold a duplicate copy of the database being compacted. Because Address Books can be quite large, you should double-check before running Compact on your Address Book.

You don't need to rebuild view indexes manually, as Notes automatically updates the indexes when it is restarted. After completing the update of your Address Book, you can take advantage of new replication features that allow you to replicate databases more often with less system overhead. After you have converted all the servers in a hub-and-spoke topology, update the connection documents of the spoke servers to use the pull-push replication method. For more information on pull-push replication, see Chapter 15, "Administering Replication."

Configuring Statistics and Events Monitoring

Follow the steps outlined in Chapter 13, "Administrative Tools," to set up statistics and events monitoring. You should configure statistics and events monitoring before continuing to upgrade other Notes servers. Statistics and events monitoring enables you to monitor your network more easily as you migrate servers. Because Release 4 statistics and events monitoring is superior to Release 3 in several ways (see Chapter 13 for details), you should upgrade immediately.

In Release 3, statistics and events monitoring documents were stored in the Public Address Book. In Release 4 they are stored in the Statistics and Events Database. As you no longer need them, you can delete the statistics and events monitoring documents from the Public Address Book by following these steps:

  1. Open the Statistics and Events Database (EVENTS4.NSF).
  2. Open the Servers to Monitor View.
  3. Select Remove Monitor Views from NAB.

Make sure that you have upgraded all views on the Public Address Book before deleting the statistics and events documents from the database. In addition, you will need to have configured the Administration Process on the server before you can delete documents.

You don't need to copy your current statistics and events documents manually from the Public Address Book to the Statistics and Events Database. The Event server task does this the first time it is executed.

Upgrading Other Servers

Repeat the process described earlier for upgrading servers, with the exception that you don't need to upgrade the Public Address Book the second time. After you have completed upgrading all servers in a hub-and-spoke topology, edit the connection documents to use pull-push replication.

Converting Databases to Release 4 Format

Actually, this step happens automatically the next time server runs the Compact program. The Compact program runs on a database every one-third of the purge interval in days. For example, if a database has a purge interval of 90 days, Compact runs on that database every 30 days.

Databases that don't have an .NS3 extension will be converted to Release 4 file format. You can prevent your databases from being converted by changing the file name of the database from an .NSF extension to an .NS3 extension. (If you are going to change the file name of your databases, make sure that you give your users an easy way to update their desktops.)

There really is no advantage to keeping a database stored on a Release 4 server in Release 3 format. Because of the hassle of changing a file name that requires users to update their desktops, you should go ahead and convert files to Release 4 format. If you want to convert a database sooner, you can always run Compact from the server console on the database. For more information on Compact, see Chapter 13, "Administrative Tools."

Converting to Release 4 file format isn't a one-way street. You can revert to Release 3 file format by using the Compact routine. If you want to have a database revert to Release 3 format, enter this command on the server console:


Load Compact -R database name

Upgrading Notes Clients

Make a complete backup of every Notes client before proceeding with an upgrade. Back up NOTES.INI, DESKTOP.DSK, NAMES.NSF, all ID files, all local databases, directory links, and database redirection files, and any customized templates.

To install the Notes Release 4 workstation software, follow the steps outlined in Chapter 11, "Installing and Configuring Notes Clients." When you have completed the installation, restart the Notes workstation software. You may need to reenter the setup information if you haven't installed Release 4 in the directory previously used by Release 3. Finally, to allow a user access to several Release 4 features, compact the desktop. To compact a user's desktop, follow these steps:

  1. Right-click on the workspace.
    The Properties dialog box opens.
  2. Select the Information tab.
  3. Select Compact.

After you have compacted the user's database, he will be able to add and delete tabs from the workspace.

The Install program doesn't alter the user's desktop, personal address book, or customizations in the NOTES.INI file. The desktop file isn't touched at all until you manually compact it. Personal address books are automatically upgraded to use the new Release 4 design template (PERNAMES.NTF). Laptops with outgoing mailboxes also overwrite the outgoing mailbox design template (MALBOX.NTF).

Although the design templates of the mailboxes are updated, the mailboxes themselves aren't automatically upgraded by the Install program. You must use the Convert server task to upgrade mailboxes stored on a server. Users can upgrade local copies of address books, using a new agent stored in the design template for Release 4.



NOTEComplete your workstation upgrades for all workstations connected to a mail server before upgrading the mailboxes on the server.


The license types for many Release 3 clients will convert when upgrading to Release 4. The license type determines the features available to a user; the person document for each user must reflect the license type. An administrator needs to edit the user's person document and enter the correct type of license in the Client License field. After the person document has replicated throughout the domain, each user should upgrade her license type by following these steps:

  1. Choose File | Tools | User ID.
    The User ID dialog box appears.
  2. Choose More Options.
  3. Choose Upgrade License.
  4. Restart the Notes workstation.

Converting Mail Files

You should upgrade mailboxes only after all workstations have been upgraded to Release 4. Users who have customized their mailboxes will need to save these customizations and reapply them after conversion. Although preserving customizations for users would be nice, no automated task exists for this purpose. To upgrade all mail databases on a server, you use the Mail Conversion utility provided with Release 4. To use the Convert Utility to upgrade mailboxes, perform the following procedure:

  1. Shut down the router to prevent delivery of mail while the Convert Utility is running. From the server console, enter the following command:
    
    Tell Router Exit
    
    
  2. Run the Convert Utility. You can use the Convert Utility to update a single database, all databases in a directory, all databases in an entire subdirectory tree, or just those databases listed in a file. Choose the appropriate option from the following list.
    The STDNOTESMAIL and MAIL4.NTF parameters tell the Convert Utility to update the design template to MAIL.4 if and only if the current design template for the database is STDNOTESMAIL. If you don't want to update the design, or if the mailbox already had its design updated, you can skip these two parameters. You also can use wild cards for these parameters. For example, instead of entering STDNOTESMAIL, you could always just type STD*.
    For each mail database converted, the Convert Utility does the following:
    You can tell the Convert Utility to ignore the upper limit of 200 categories by using the -I parameter.
  3. Restart the mail router. At the server console, type the following command:
    
    Load ROUTER
  4. Have the users copy their customized views and forms back into their personal mailboxes. Make sure that users don't completely replace entire views or forms. Rather, they should copy individual fields into forms, and cut-and-paste selection formulas into views.

The syntax of the Convert Utility is as follows:


Load CONVERT (-F) (-L) (-R) (-I) (-D) (-N) (FULLPATH) database file name (CurrentDesignTemplate) (NewDesignTemplate)

where CurrentDesignTemplate is the name of the template that a mail file must be using in order for it to be converted, and NewDesignTemplate specifies the name of the new template that will be used by the mail file.

All parameters except the file name of the mail database are optional. The following list describes the parameters:



NOTEIf you don't specify a current template and a new template, the Notes Design won't be upgraded to Release 4. You must always specify current template and new template when using the Convert Utility on mail files that aren't already using the Release 4 mail design template.

You need to upgrade only the primary mailbox for each user. If they maintain local replicas, all changes will propagate. Don't upgrade both a user's primary mail file (the mail file to which the router delivers mail) and replicas stored on workstations or laptops. Documents may not appear in the correct folders if you convert both a primary mail database and its replica.

A user who has her primary mailbox on her local machine can upgrade to Release 4 by using an agent contained in the Release 4 mail design template. She must replace the design of the current mailbox so that it uses the new design template for mailboxes, run the agent contained in the design, and then copy over any customized forms or views. The user who wants to convert her personal mailbox should follow these steps:

  1. Be sure that the workstation has been upgraded to Release 4.
  2. Store any customized forms or views in a temporary database.
  3. Select the personal mailbox icon from the workspace.
  4. Choose File | Database | Replace Design.
    The Replace Database Design dialog opens, as shown in Figure 12.1.

    Figure 12.1.
    Use the Replace Database Design dialog box to update the design of your mailbox.

  5. From the list of templates, select the Mail (R4) Design Template (MAIL.NTL).
  6. Choose Replace.
    Notes prompts you with a warning that you should copy all customized views and forms before proceeding.
  7. Choose Yes.
  8. Open the Agent view.
  9. Double click the (Convert Categories to Folders) agent.
  10. Choose Actions | Run.
  11. Copy any customizations back to your personal mailbox. Don't replace any forms or views that exist on your Release 4 database. If you need to modify any of the forms or views that come standard with Release 4, copy individual fields or formulas rather than the whole design element. Because Notes Release 4 contains many additional standard features, you may not even need to use your customization any longer.

After you convert a user's primary mailbox on a server to use the new Release 4 mailbox template, the user needs to replicate the new design element to any local replicas of her mailbox, and ensure that all design elements will replicate. To ensure that all design elements replicate, follow these steps:

  1. Choose File | Replication | Settings.
    The Replication Settings dialog box opens.
  2. Click the Advanced icon.
  3. Make sure that all check boxes in the Replicate Incoming section are selected.
  4. Choose OK.

Alternatively, to maintain a Release 3 design of any local replicas, uncheck the Forms, Views, Etc. check box and the Agents check box.

Upgrading Your Applications


After you have converted a server, workstation, department, or workgroup to Release 4, you can start to take advantage of Release 4 features. You can use some features if even a single server has been upgraded, while other features, such as Release 4 Mail, should be used only after you have converted an entire workgroup.

Notes Release 4 contains two key features that enable you to replicate data faster and with less administrative burden than in Release 3. Release 4 databases can have multiple replicators updating them at a single time. Also, field-level replication reduces the amount of data that must be replicated. Replication is faster in a hub-and-spoke architecture, because Notes Release 4 doesn't scan the disk drive for new databases every time a replication starts, instead storing information on all databases in memory.

These features combine to greatly enhance the speed of replication in a hub-and-spoke topology, where a hub may contain several thousand databases. You can configure the spokes to push changes to the hub rather than relying on the hub to pull changes from a spoke. Because all the spokes can be pushing changes to a database at once, the amount of time it takes for a change to propagate is greatly reduced.

To take advantage of pull-push replication, you need to modify the connection documents for all spokes in your topology.

Setting Up the Administration Process

Chapter 13, "Administrative Tools," covers the Administration Process in detail. To set up the administrative process on a Notes server, follow these steps:

  1. Make sure that the server has been upgraded to Release 4.
  2. Add the ADMINP to the ServerTasks parameter in the NOTES.INI file.
  3. Convert the Public Address Book and modify its ACL, giving administrators at least author access with the ability to delete documents. Assign administrators to the proper roles.
  4. Add the Administration Request Database to your workspace and modify its access control list. Add all the groups or individuals who will need the ability to convert user or server names. They must have at least author access with the ability to create documents.
  5. Specify an administration server for the Public Address Book.
  6. Assign an administration server for other databases.

After you have the Administration Process up and running on a server, you can begin to convert your names.

Using Shared Mail

You can potentially regain a considerable amount of disk space on a server by using the shared mail feature of Release 4. Shared mailboxes that have shared mail enabled store their messages in a single common database on the server. Messages addressed to multiple recipients are stored a single time in the database. Several ways exist to configure shared mail; they are all discussed in Chapter 14, "Administering Notes Mail."

Converting to Hierarchical Naming


After you have upgraded your servers and clients to Release 4, you should certainly convert to hierarchical naming if you haven't done so already. The Administration Process greatly simplifies the burden of converting users and servers to hierarchical naming. You should carefully design your naming scheme before proceeding. See Chapter 9, "Designing Your Notes Network," for details on developing a naming scheme for your users, servers, domains, and networks.

Preconversion Planning

Before changing the name of a server or user, you need to carefully check the access control lists on other servers. This step is required in order to continue to have a functioning Notes network. If you change a server from flat to hierarchical naming, you may no longer be able to replicate changes to or from the server.

The first thing you need to do is to ensure that there is a certified public key in the server document for all servers that will be upgraded to hierarchical naming. You should also ensure that there is a certified public key in the server document for all administration servers. You can accomplish this by migrating the server to Notes Release 4 and letting the Administration Process run to completion. After the Administration Process is idle, reboot the server. This action will cause a certified public key to be copied into a server document.



TIP If you are having trouble using the Administration Process, make sure that you are starting the administration server before the workstation. If not, you need to shut down the workstation, start the server, and then restart the workstation. The Administration Process doesn't work if the server isn't started before the workstation.

Because the Administration Request Database will hold name-change requests for servers in your organization, you should control access to this database carefully. Only administrators who need to be involved in the conversion to hierarchical naming should have access to this database. Carefully control depositor, editor, and author access to this database. Don't forget to give your local domain servers access to this database so that they can replicate requests.

After you have set up the access control list for your Administration Request Database, turn off ACL replication so that a change made at one workstation doesn't replicate to all. To turn off ACL replication, follow these steps:

  1. Highlight the Administration Request Database and choose File | Replication | Settings.
    The Replication Settings dialog appears.
  2. Click the Advanced icon.
  3. Uncheck the Access Control List check box.
  4. Choose OK.

Processing a renamed-server request causes the Administration Process to access several views and documents in the Public Address Book. Make sure that the index updater isn't running while the Administration Process is handling a rename-server request. Your server's performance will be significantly lowered by contention between these two processes. To ensure maximum performance during a Rename Server command, follow these steps:

  1. Shut down the updater by entering the following command at the server console:
    
    Tell Update Quit
    
    
  2. Shut down the mail router with this command:
    
    Tell Router Quit
    
    
  3. Shut down the replicator with this command:
    
    Tell Replica Quit
    
    
  4. Start up a copy of the Administration Process by entering this command:
    
    Tell ADMINP Process New
    
    
  5. When the status of the Administration Process returns to idle, enter this command:
    
    Load Update
    
    
  6. When the updater has completed and is idle, restart the router with the following command:
    
    Load Router
    
    
  7. Now restart the replicator with this command:
    
    Load Replica
    
    
  8. You should immediately replicate the server name changes to other replicas of the Public Address Book in your domain. Use this command to force an immediate replication of the Public Address Book:
    
    Push ServerName Names.nsf
    
    
    where ServerName is the name of the server running the Administration Process.

You can't convert a mail server using shared mail from flat to hierarchical naming. Doing so would prevent you from accessing the shared mail database. The shared mail database is encrypted using the flat ID file for the server. Before converting to hierarchical naming, unlink all mail files. See Chapter 14, "Administering Notes Mail," for directions on unlinking shared mail files. Unlinking mail files takes at least a day to allow all messages to be purged from the shared mail file.

After you have completed the conversion to hierarchical naming, you can relink all mail files on the server.



TIP Make sure that you have enough disk space to unlink mail files before attempting to convert to hierarchical naming.


Users and servers that have only their common names listed in a database or server access control list are assumed to have used the same organizational certificate as the server on which the database resides. If this isn't the case, users and servers no longer can access the database or server that contains only their common names. When converting a server to hierarchical naming, you need to review all server access lists and database access lists on that server. Any common names should be converted to their full hierarchical names before converting the server to hierarchical naming. Check off each of the following items:

  1. Review all server access lists and database access lists on that server.
  2. Examine all group documents in the Public Address Book. Each member should have his or her full hierarchical name listed.
  3. Examine the server access control lists and upgrade all common names to the full hierarchical name.
  4. Issue the appropriate cross certificates. You need to issue one cross certificate for every other organization that accesses this server. This system allows your server to authenticate these other users after the upgrade to hierarchical naming.
  5. Other organizations should issue a cross certificate for the new organizational certificate for the server. This system allows other organizations to authenticate your server.
  6. Make sure that other organizations upgrade their server access lists and database access lists so that the full hierarchical name of the server is listed.
  7. Manually change the access control list on all MAIL.BOX files in the domain. The Administration Process can't update the access control list on MAIL.BOX files. Make sure that the server's full hierarchical name is listed.

Even when you take care to upgrade all access control lists, there will be a time during which Release 3 servers can't access a Release 4 server that has had its name upgraded to hierarchical naming. The Public Address Book must replicate throughout the domain in order to reestablish this access.

Completing the Conversion

When you are ready to proceed with your conversion to hierarchical naming, follow these steps:

  1. Manually convert a single server to hierarchical naming. You must convert servers to hierarchical naming before you convert users because only a server that uses hierarchical names can upgrade users to hierarchical naming. Don't change the common name of a server at the same time that you are upgrading it to hierarchical naming. If you want to change the company name of a server, do it either before you begin converting or after you have completed converting.
  2. Upgrade user IDs to hierarchical naming.

To convert the first server to hierarchical naming, follow these steps:

  1. Choose File | Tools | Server Administration.
    The Server Administration panel opens.
  2. Select the server's icon.
  3. Open the Servers view.
  4. Highlight the first server to be converted to hierarchical naming.
  5. Choose Actions | Upgrade Server to Hierarchical.
    The File Selection dialog box appears.
  6. Select the hierarchical certificate to be used with the current server.
  7. Enter an expiration date for the server.
  8. Choose Upgrade.
    The server ID file is upgraded to hierarchical naming. When the process is complete, a confirmation dialog box appears.
  9. Choose OK.
  10. Shut down the Notes server.
  11. Open the Public Address Book, using the workstation program.
  12. Open the server document for the server that was just converted.
  13. Put the server document in Edit mode, and delete the contents of the certified public key field.
  14. Open the Administration Request database.
  15. Open the Initiate Rename in Address Book document.
  16. Copy the contents of the Certified Public Key field to the server document.
  17. Copy the Change Request field to the Change Request field of the server document.
  18. Save the server document.
  19. Restart the Notes server.

After you have converted a single server to hierarchical naming, you can batch process the rest of the servers. All servers that will be certified using the same certificate can be processed at one time. To convert subsequent servers to hierarchical naming, follow these steps:

  1. Choose File | Tools | Server Administration.
    The Server Administration panel appears.
  2. Choose Servers.
  3. Open the Servers view.
  4. Select the servers that will be converted to hierarchical naming. Each of the servers you select must use the same certificate.
  5. Choose Actions | Upgrade Server to Hierarchical.
    The file selection dialog box opens.
  6. Select the hierarchical certificate for the servers.
  7. Enter an expiration date for the certificate.
  8. Select Upgrade.
    Requests are entered into the Administration Request database and server documents are upgraded by the Administration Process. When complete, Notes displays a confirmation dialog box.
  9. Choose OK.

Repeat this process for each set of servers that use a different certificate.

The Administration Process completes all the steps needed to convert your server names, including:

For more detail on how the Administration Process accomplishes its magic, see Chapter 13, "Administrative Tools."

After these requests have been processed by the Administration Process, you can begin the conversion of users to hierarchical naming. Once again, remember that you shouldn't change a user's common name at the same time that you are upgrading to hierarchical naming. Changing a common name at the same time results in the user being unable to access databases for a brief period of time.

You can batch process all user names that will be certified using the same certifier ID file. To upgrade a group of users to hierarchical naming, follow these steps:

  1. Choose File | Tools | Server Administration.
    The Server Administration panel appears.
  2. Select People.
  3. Open the People view.
  4. Select each of the users who will be upgraded to hierarchical naming. Each user will use the same certifier ID file.
  5. Choose Actions | Rename Person.
  6. Select Upgrade to Hierarchical.
    The file selection dialog appears.
  7. Select the certificate that should be used to certify these users.
  8. Enter an expiration date for the certificate.
  9. Select Upgrade.
    Notes upgrades the person documents and creates the proper request in the Administration Request database, and then display a confirmation box.
  10. Choose OK.

Repeat this process for each set of users in your organization.

Upgrading in a Mixed Environment


You may not be able to wait until you have completed a complete migration of all users to Release 4 before beginning your conversion to hierarchical naming. Of course, it is highly recommended that you complete your migration to Release 4 before converting to hierarchical naming because of the massive amount of effort saved with the use of the Administration Process. If this is impossible, keep in mind that access control lists for databases that have no replica on a Release 4 server won't be updated. If you use a hub-and-spoke replication topology, you need only upgrade the hub server to Release 4. For every database on the hub server, specify an administration server. This strategy enables you to have all database ACLs updated by the Administration Process. Changes to databases on the hub server will replicate to the Release 3 spokes.

Release 3 servers can't automatically upgrade users that contact them. Release 4 servers automatically upgrade a user's ID file when appropriate. If you want to upgrade user ID files by using the Administration Process, you should upgrade all mail servers to Release 4 format. Because everyone accesses their mail server frequently, this scheme enables you to have their IDs upgraded automatically when they contact the mail server.

Monitoring the Conversion to Hierarchical Naming


Check the Administration Request database several times a day while you are upgrading servers and users to hierarchical naming. The Administration Process creates response documents for all requests, indicating the current status of the request. If an error has occurred, a red x appears next to the response document. Be sure to fix any errors in a timely manner to minimize disruption of your Notes network.

You should set up ACL monitor documents in the Statistics and Events database. This plan causes the Events task to mail any errors directly to your mailbox.

In addition to the Administration Request database, you need to monitor the Certification Log database (CERTLOG.NSF). Additional information on errors is recorded in the Certification Log database.

Administering Mixed Environments


It is inevitable that for a period of time you will have some servers running Release 3 and some servers running Release 4. In addition, many organizations will end up with some users running Release 4 clients while other users are still running Release 3 clients. Lotus has planned ahead for these eventualities; you should have no problems in these environments if you don't break any of the following rules:

Three situations will arise during your migration for which Lotus has planned:

Release 3 workstations can't edit macros containing Release 4 features. Release 4 workstations, on the other hand, can edit either Release 3 or Release 4 macros. Macros in Release 3 format are stored in Release 3 format. If you alter a Release 3 macro to include features from Release 4, the macro will be stored in Release 4 format and will no longer be editable by Release 3 workstations.

Full-text indexes aren't interoperable across releases. A Release 4 workstation can't access a Release 3 full-text index, and a Release 3 workstation can't access a Release 4 full-text index. Notes Release 4 can read but not update a Release 3 index. During the migration, you may have some clients using Release 3 and some using Release 4. During this period of time, all databases should be maintained in Release 3 format. All updates to full-text indexes should be performed from Release 3 workstations.

Some features in Release 3 databases, such as navigators, don't work correctly when accessed from a Release 3 database. In general, a Release 3 database can't use special features from Release 4. In addition, large views or bitmaps stored in Release 4 databases may cause memory allocation problems in Release 3. The largest memory segment Release 3 can handle is 65,000 bytes.

If you are using a workstation that has both Release 3 and Release 4 installed, you may experience delays when opening databases. Each release of Notes needs to rebuild databases in its own format before using the database. In addition, if you are using a workstation with both Release 3 and Release 4 installed, you shouldn't use the Release 4 Workspace Edit feature. Release 4 allows you to create and delete tabs on the workspace, but Release 3 always handles exactly six tabs. If you use the Release 4 feature to edit your desktop and then later try to access it using Release 3, Release 3 will try to rebuild the desktop, thinking that it is corrupted.

Clients using Release 4 mail should be careful when sending mail to Release 3 users—yet another reason why you should wait until all users have been upgraded to Release 4 before upgrading mail files. You can avoid these problems:

Release 4 OLE objects can't be used by a Release 3 user. If you need to share OLE objects, you must create them using Release 3. Release 4 can launch OLE objects created using a Release 3 workstation.

Managing Template Names in a Mixed Environment


Several system databases received new design template names in Release 4. You must ensure that these design templates are replicated to all databases. You should avoid the situation where, for example, a Public Address Book on one server has the Release 4 template, and another server has a Release 3 template. This situation can cause your Notes 4 servers to be updated using the Notes 3 design. Avoid this situation by eliminating design updating or design replication. To turn off design updating, you simply need to replicate the R4 template name to all R3 Address Books using the following method:

  1. On the Release 3 server, check the Replicate Database Title, Categories, and Template Names box.
  2. On the Release 4 server, open the Database Properties dialog box, select the Basics tab, and uncheck the option Do Not Send Changes and Database Title and Catalog Info to Other Replicas.

The next time these two databases replicate, the Release 3 database will inherit the STDR4PublicAddressBook template name from the Release 4 Address Book. The Release 3 design will no longer be updated because the Release 3 server doesn't have a copy of this template. Instead, the design task on the Release 3 server simply generates an error indicating that it can't find the template.

You can also prevent servers from replicating design changes:

  1. On the Release 3 server, open the Replication Settings dialog box. Uncheck the option Replicate Database Title, Categories, and Template Names. Also uncheck the Inherit Design from Template option. Then open the Design Template Options dialog box and delete the Based on Template field.
  2. On the Release 4 server, open the Database Properties dialog box, select the Basics tab, and select the option Do Not Send Changes and Database Title and Catalog Info to Other Replicas.

By severing the link that updates the design, you prevent the Release 4 design from being overwritten from the Release 3 database. When the Release 3 server is eventually upgraded to Release 4, be sure to go back and re-enable replication of design changes.

Release 4 Workstations Accessing Release 3 Servers


Upgrade your servers before upgrading users. If you have users with a Release 4 workstation with access to a Release 3 server, the users must know exactly which features can and can't be used. The Release 3 server is unable to support all the features accessible to the client when using a Release 4 workstation.

If you migrate users to Release 4 before you have migrated their mail server to Release 4, they can't use these features:

Don't use Release 4 workstations to edit formulas of databases stored on a Release 3 server. Any Release 4 functions included in the view won't be recognized by the Release 3 server. Generally the Release 3 server can build a view, although the actual documents in the view probably won't match up with the ones that you wanted.

Summary


This chapter has discussed the why and how of migrating from Notes Release 3 to Release 4. Notes includes several tools to ease the transition to Release 4, such as

You should approach your migration with the same planning steps that you would use for an initial installation. Create a team, involve the entire organization, assess your hardware and software installation and needs, design your new Notes network, and upgrade your servers, clients, and applications to Release 4.

Don't forget to train your administrative staff and end users before migrating to Release 4. There are enough new and changed features to justify the training expense. The Notes training is the one task that Lotus wasn't able to automate.

You also need to do exhaustive testing on your third-party products and mission-critical applications before migrating to Release 4.

With all the new tools included in Notes, migrating to Release 4 should be simpler than migrating from one Release 3 version to another. With a little bit of planning, you should be able to avoid all critical problems. Be sure to review Part II of this book, "Planning Your Notes Installation," for a complete set of details to consider when installing or migrating Notes.

Previous Page Page Top TOC Next Page