Migrating to OS/2 Warp Server for e-business

4.2 Preparing the Migration

The migration preparation sequence, or the roadmap, has been detailed in Section 2.2 Migration Decision Road Map, so we will just describe the steps needed for each type of server.

4.2.1 General Structure of a Server Disk

This section describes the disk layout we used in our test domain. This disk layout is the same on all servers and represents our real life experience. Your real structure may be different, but the adaptation of the scenario will be easy as long as the operating system and OS/2 Warp Server for e-business components occupy a dedicated partition. For illustration purposes, we show our structure in order to help you understand the various examples that may use a hard-coded boot drive letter.

Boot Manager (1 cylinder) C: Maintenance Partition (Primary, 20M, FAT Formatted, SoS) D: System Partition (Logical, 500M, HPFS Formatted, OS2) E: Dump Partition (Logical, Memsize+1M, FAT Formatted, SADUMP) F: File Area (Logical, Rest of the Disk, HPFS Formatted,Srv_F)

Figure 22: Partition Layout of Our Servers

The F: partition of our primary and backup domain controllers is either left empty or used for holding the distribution files for unattended installations.

The other servers hold the user directories and files on their F: partitions.

All our servers are using the 386 HPFS file system (even if this is not specifically needed for the primary and backup domain controllers).

Backup Your Data

It has been mentioned many times in this redbook, but it is worth repeating again: It is highly recommended to have a current and verified backup so that it can be used to restore in case something goes wrong.

Backup Your Data
It has been mentioned many times in this redbook, but it is worth repeating again: It is highly recommended to have a current and verified backup so that it can be used to restore in case something goes wrong.

4.2.2 Backup Domain Controller

Migrating the Backup Domain Controller is certainly the easiest task in our scenario. We can rely on the replication mechanism to actually refresh all the users related information that could have changed during the installation period. So, the tasks to accomplish are:

Check that the server is actually working as expected (using, for example, the LSC.CMD program from the CD-ROM accompanying this book).
Remove the Access Control Lists that are present on the system disk because they may prevent the installation program from accessing some of the OS/2 LAN Server-related subdirectories. (A Backup Domain Controller maintains ACLs on its \IBMLAN\DCDB subdirectory).
Install the new system.
Check that the server still works as expected. If it is needed, you will perhaps have to resynchronize the password of the server (using, for example, the RESYNCPW.CMD program from the same CD-ROM) Normally, the access control lists that are relative to the LAN Server subsystem would have been recreated automatically.

4.2.3 Migrating the File and Print Servers

For these types of machines, you should make sure you have a current NET.ACC backup. Note that the migration of one server of this type will imply the interruption of some services provided to your users. Files and printers under this server control will be unavailable during the migration. If such an interruption is unacceptable, you will have to move all the controlled resources to another server (using one of the means described in Chapter 6. Migrating Hardware) before migrating.

4.2.4 Migrating the Primary Domain Controller

This is certainly the most tricky element. In fact, the best way is to exchange the roles of the Backup and the Primary Domain Controllers. Once they are switched, migrate the Backup Domain Controller. Afterwards, exchange once again the roles to reach the same setup you had before. Performing the migration this way will guarantee that all the modifications that may occur on your domain while you're migrating will be validated and stored by the temporary Primary Domain Controller, and that after the replication of the DCDB tree on the temporary Backup Domain Controller, it will be ready to regain its role of Primary Domain Controller.

Switching Server

While it is helpful to have some CMD files that will do the job directly, the role switching between a Primary and a Backup Domain Controller is straightforward: Your domain will still be operational if you only have a Backup Domain Controller. Since you cannot have two Primary Domain Controllers, you must change the role of the Primary Domain Controller to Backup, and when this is done, you change the role of the Backup Domain Controller to Primary.
To change the roles, you must first stop the NETLOGON and DCDBREPL services on the PDC, then change the role and restart the two services. The sequence is:
NET STOP NETLOGON NET STOP DCDBREPL NET ACCOUNTS /ROLE:BACKUP NET START DCDBREPL NET START NETLOGON

These commands may be issued from any workstation using the NET ADMIN /Ccommand.

Switching Server
While it is helpful to have some CMD files that will do the job directly, the role switching between a Primary and a Backup Domain Controller is straightforward: Your domain will still be operational if you only have a Backup Domain Controller. Since you cannot have two Primary Domain Controllers, you must change the role of the Primary Domain Controller to Backup, and when this is done, you change the role of the Backup Domain Controller to Primary. To change the roles, you must first stop the `NETLOGON` and `DCDBREPL` services on the PDC, then change the role and restart the two services. The sequence is: NET STOP NETLOGON NET STOP DCDBREPL NET ACCOUNTS /ROLE:BACKUP NET START DCDBREPL NET START NETLOGON These commands may be issued from any workstation using the `NET ADMIN /C`command.

Obviously, this cannot be done if you have only one server (which will then be primary domain controller (PBC) and file and print server). In this case, you may consider using a spare machine (it does not have to be a powerful one, nor a machine with large disk space available) to act as a temporary Primary Domain Controller. This can be done in the following way:

Install OS/2 Warp Server for e-business on a machine specifying it will be a Backup Domain Controller. This installation can be used to get familiar with the product.
Add the server to your domain (for example, by using the ADDSRV.CMD file, which resides on the CD-ROM).
Check that the replication has been performed successfully (LSC.CMD and LSDCDB.CMD files may also be used here as described in the chapter dealing with the migration to a new hardware).
Define this machine as the Primary Domain Controller by switching the roles using the procedure described in the box above.
Migrate your old domain controller to OS/2 Warp Server for e-business.
Switch back the roles and free the spare machine.

Note that migration can take a few hours, and that no modification should occur on your network (NET.ACC and DCDB) during the process. Using a temporary Primary Domain Controller can be considered as an insurance policy: The LAN Server code will keep all your definitions (NET.ACC and DCDB). Access Control Lists (ACLs) are applied to your 386 HPFS disks through other methods.

You may consider making the temporary Primary Domain Controller the permanent Primary Domain Controller. If the temporary machine was just not good enough to run your company's favorite word processor, for example, a Pentium 100 with 32 MB of memory and 1 GB of disk space, it could easily perform the tasks of a Primary Domain Controller. Be aware, however, if you have many additional servers, NET.ACC replication can be quite I/O and CPU-intensive.

4.3 Performing the Migration