Migrating to OS/2 Warp Server for e-business

6.9 Step 1: Installing the New Backup Domain Controller (BDC)

First, we must install a new backup domain controller (BDC) with OS/2 Warp Server for e-business. The installation itself is straightforward because the BDC (\\DC02) has no network resources defined.

If network resources had been defined on this server, then migration of these resources would also be necessary. With this alternative scenario comes greater complexity.

The following shows the steps needed to install the new backup domain controller.

6.9.1 Installing OS/2 Warp Server for e-business

Install OS/2 Warp Server for e-business on the new system hardware. The installation can be either a CD-ROM panel-driven attended installation or a CID-based unattended installation. Make sure that the new system is configured exactly the same as the original BDC, as it will later replace it (in this case, \\DC02). The new BDC server must be installed with the role set to BACKUP.

Figure 107: Installing the Backup Domain Controller

If the server is installed on the production network, do not allow any LAN Server services to start after installation.

This can be achieved by commenting out the NET START SRV statement in the STARTUP.CMD (add the letters REM and one space character before the aforementioned statement), or renaming STARTUP.CMD to another name. Or, you can rename the STARTUP.CMD file so it does not execute upon system startup.

For example:

REN STARTUP.CMD STARTUP.OLD

then press Enter.

Alternatively, the server can be installed on an isolated LAN segment. Make sure that the STARTUP.CMD file is renamed or changed as above prior to moving the system to the production LAN.

6.9.2 Adding the Backup Domain Controller to the Network

First, remove the existing BDC (\\DC02) from the network. This can be done in one of two ways. Either stop all of the LAN Server services or shut the system down completely.

You can stop the server by issuing the following command and following the prompts to stop the services:

NET STOP REQ /Y

then press Enter.

When the original BDC (\\DC02) has been removed from the network, the newly-installed BDC (also configured as \\DC02) can be attached to the network and started.

Figure 108: Attaching the Backup Domain Controller to the Network

If the system is already attached to the network, simply start the server by issuing the following command:

NET START SRV

then press Enter.

Now the freshly installed OS/2 Warp Server for e-business image of the BDC (\\DC02) has replaced the original BDC (\\DC02). The PDC (\\DC01) is currently unchanged and will, therefore, continue to handle any logon requests. Up until this point, it is unlikely that any users will have experienced any disruption to service.

6.9.3 Allowing DCDB Replication to Complete

With the new BDC (\\DC02) in place, the LAN Server DCDB (Domain Control Database) Replicator Service will start to replicate user and group information from the PDC to the BDC (the \IBMLAN\DCDB subdirectory tree). This enables the BDC to handle user logon requests whenever the domain controller is busy.

Figure 109: Domain Control Database (DCDB) Replication

Since server \\DC02 is already defined as a valid Machine ID as part of the group SERVERS as a server in the domain, no further action is needed.

Provided that the DCDBREPL service is started on both the PDC (\\DC01) and the BDC (\\DC02), then DCDB replication will start. The status of the replication can be verified by issuing the following command locally:

NET START

then press Enter

or by using the NET ADMIN command and issuing the following command (Note: that if expected results are not seen, both PDC and BDCs should be checked):

NET ADMIN \\DC01 /C NET START

then press Enter.

If the DCDBREPL service has started successfully, it will be displayed as follows:

These services are started: REQUESTER MESSENGER SERVER NETLOGON LSSERVER DCDBREPL The command completed successfully.

Figure 110: Using the NET START Command to Query Services

If the DCDBREPL service is not yet started, you must start it. You can do so by issuing the following command locally or by pre-pending the NET ADMIN syntax as above when issued from a remote system:

NET START DCDBREPL

then press Enter.

Occasionally, the DCDB replicator service will not function correctly. The problem is usually seen on the BDC with it not receiving a copy of the master user accounts database. If this happens, the problem must be resolved before continuing. Please refer to Section 6.9.4 Correcting DCDB Replication Problems if you find that there are problems. There are several procedures that can help you.

6.9.4 Correcting DCDB Replication Problems

If DCDB replication is not working properly, it could be due to one of the following reasons:

A User is not logged on at the BDC.
The User logged on at the BDC does not have sufficient access rights.
The BDC is out of synchronization with the PDC.

The resolution for each of these situations is slightly different. In this section, the resolutions are described in turn.

6.9.4.1 DCDBREPL Problem 1: User Not Logged On

The DCDBREPL Service uses a UserID on the BDC that effectively logs on to the PDC in order to receive the updates to the master accounts database. This is specified normally in the IBMLAN.INI file with the keywords:

Logon =
Password =

If no user is logged on to the BDC, this can cause problems with the DCDB replication service.

To overcome this problem, you can set up a userid if one has not already been set up. You can do this by adding the information about userid and the password to the IBMLAN.INI of the BDC and then adding a userid. In our example, you could do this logged on to a server in the domain as an administrator as follows:

NET ADMIN \\DC01 /C NET USER DCDBUSR /PASSWORDREQ:NO /PRIV:ADMIN /WORKSTATION:DC02

then press Enter.

The /WORKSTATION parameter makes sure that this user only has access when logged on at DC02.

6.9.4.2 DCDBREPL Problem 2: User Lacks Access Rights

If the user defined lacks access rights, grant them. Otherwise, the replication will fail.

6.9.4.3 DCDBREPL Problem 3: NET3062 Errors

If a backup domain controller should fail while starting the server part with a NET3062 error, it is usually for one of two reasons.

The machine is not defined in DCDB.
The machine is out of sync with DCDB.

We will now describe the scenarios in more detail.

Machine Is Not Defined In DCDB

Using the name convention already discussed, the PDC is \\DC01, and the BDC is \\DC02. In order to solve these problems, you must log on as administrator and complete the following steps. On the BDC, type the command:

NET START SRV

then press Enter.

The following result is displayed:

The SERVER service is starting....
The SERVER service could not be started.
NET3062: The sub-service NETLOGON failed to start.
For more information, type HELP NET3062.

To find out what the problem is, we have to look into the error log of the machine by typing the following command on server \\DC02:

NET ERROR

then press Enter.

The following output is displayed:

Program Message Time
NETLOGON 3055 10-22-96 03:33pm
An error occurred. Refer to the help for the following message:
NET3084: The user accounts system is not configured correctly.
0C 0C ..
SERVER 3113 10-22-96 03:33pm
NET3113: Initialization failed because the requested NETLOGON service could not be started.
The command completed successfully.

This means that this new server is not defined into the domain controller data base (DCDB). In order to solve this problem, we have to do the following steps. First, you need to log on as an administrator to the domain by typing the following command (which is not needed if you have already logged on):

LOGON ADMIN /P:PASSWORD /V:D

where ADMIN and PASSWORD are valid variables. Then you should add the backup domain controller to the database by typing the following commands at the keyboard of the primary domain controller:

NET ADMIN \\DC01 /C NET USER DC02 /PASSWORDREQ:NO
/USERCOMMENT:"Backup DC" /ADD

After that, issue the following command:

NET ADMIN \\DC01 /C NET GROUP SERVERS DC02 /ADD

Finally, log off and start the server with the following commands:

LOGOFF
NET START SRV

The following result should be displayed:

The SERVER service is starting....
The SERVER service was started successfully.

Server Password is Out of Sync with PC

The second scenario can also be solved. On server \\DC02, type the following command:

NET START SRV

The following result is displayed:

The SERVER service is starting....
The SERVER service could not be started.
NET3062: The sub-service NETLOGON failed to start.
For more information, type HELP NET3062.

In order to find out the cause of the problem, we have to look into the error log of the machine by typing the following command:

NET ERROR

The following result is displayed:

Program Message Time
NETLOGON 3210 10-22-96 03:59pm
NET3210: This server failed to authenticate with DC1,
the domain controller for domain WSDOMAIN.
05 00 ..
NETLOGON 3056 10-22-96 03:59pm
NET3056: A system error has occurred.
05 00 ..
SERVER 3113 10-22-96 03:59pm
NET3113: Initialization failed because the requested NETLOGON
service could not be started.
The command completed successfully.

The following process will resolve the problem. Copy these two files onto a diskette:

PWDEXP.EXE
PWDIMP.EXE

Go back to the console of \\DC02. Copy the two files from the diskette to the server and set the server role into standalone. Log on locally. Type the following commands:

COPY A:\PWDEXP.EXE X:\IBMLAN\NETPROG

where X: is the drive letter where you installed OS/2 LAN or Warp Server. Then issue the following commands:

NET ACCOUNTS /ROLE:STANDALONE
LOGON USERID /P:PASSWORD /V:L

If this the first attempt of the server to reach the PDC, the default user ID will be USERID and the default password will be PASSWORD. Otherwise, ADMIN and PASSWORD will be valid variables (already) defined in your local database file, NET.ACC.

Extract the (encrypted) password from \\DC02 by typing the following command:

PWDEXP DC02

For example, a result like this could be displayed:

DC2:AAD3B435B51404EEAAD3B435B51404EE

Do it again and write the result to a file on diskette by typing the following command:

PWDEXP DC02 > A:\DC02.PWD

Log off from the local database of \\DC02 and perform a logon to the PDC \\DC01 by typing the following commands:

LOGOFF
LOGON ADMIN /P:PASSWORD /V:D

where ADMIN and PASSWORD are valid variables.

Get the saved file from the diskette and copy it to the PDC by typing the following command:

COPY A:\PWDIMP.EXE \\DC01\IBMLAN$\NETPROG

and type the following command to display the file:

TYPE A:DC02.PWD

For example, the result could be:

DC02:AAD3B435B51404EEAAD3B435B51404EE

Continue typing the following command:

NET ADMIN \\DC01 /C PWDIMP DC02:AAD3B435B51404EEAAD3B435B51404EE

It is better to use the clipboard function in order to copy the data. If you make a mistake in the number/letter combination, you will not be able to log on.

Change the server role to Member or Backup of your domain by typing the following commands:

NET ACCOUNTS /ROLE:BACKUP
LOGON USERID /P:PASSWORD /V:L

Note

For an additional server, you would need to change the first line to
NET ACCOUNTS /ROLE:MEMBER

Note
For an additional server, you would need to change the first line to `NET ACCOUNTS /ROLE:MEMBER`

Finally, log off and start the server with the following command:

LOGOFF
NET START SRV

The following result should be displayed:

The SERVER service is starting....
The SERVER service was started successfully.

Solving the NET3062 Problem the Simple Way

Because there is a lot of room for error, and the process is tedious, we wrote a tool that basically performs the same function as has just been described. It is called RESYNCPW.EXE. We have included this tool on the CD-ROM accompanying this redbook.

When the DCDBREPL services have started successfully on both the PDC and the BDC, and when DCDB replication appears to be functioning correctly, we must verify that all data has been replicated. We do this in the following manner.

6.9.5 Verifying that DCDB Replication Was Successful

If the DCDB replication service is replicating correctly, a file called OK.RP$ can be found in each of the \IBMLAN\DCDB subdirectories. To check whether this is the case, issue the following command and press Enter to display output that should look like the following:

[D:>]DIR \\DC02\IBMLAN$\DCDB\*.RP$ /S /B \\DC02\IBMLAN$\DCDB\APPS\OK.RP$ \\DC02\IBMLAN$\DCDB\Data\OK.RP$ \\DC02\IBMLAN$\DCDB\DEVICES\OK.RP$ \\DC02\IBMLAN$\DCDB\FILES\OK.RP$ \\DC02\IBMLAN$\DCDB\IMAGES\OK.RP$ \\DC02\IBMLAN$\DCDB\LISTS\OK.RP$ \\DC02\IBMLAN$\DCDB\PRINTERS\OK.RP$ The command completed successfully

Figure 111: Checking DCDB Replication Status by Looking for .RP$ Files

If the output displays any files called NO_SYNC.RP$, this means that the servers are communicating with each other, but that the DCDB replication service updates may not be current, for example, if additional time is needed to complete the replication.

Initially, this does not represent a problem. However, if OK.RP$ is still not displayed after some time, of course dependent on network traffic and the replication parameters in the IBMLAN.INI file, then the problem must be resolved.

If the output displays any files called NO_MASTER.RP$, then there is already a problem. The PDC and BDC are not communicating with one another for one of the following reasons.

The server exporting the directory is not operating.
Something is wrong with the replication setup.
The exporter has stopped exporting this directory.

This situation must be corrected before progressing.

Please refer to Section 6.9.4.1 DCDBREPL Problem 1: User Not Logged On through Section 6.9.4.3 DCDBREPL Problem 3: NET3062 Errors, or refer to the on-line documentation for further information on how to correct this condition.

When the file OK.RP$ exists in the DCDB subdirectories, this is still not a total guarantee that replication has completed. This simply means that the PDC and the BDC are communicating, and that the DCDB replicator service is functioning.

In a large domain, the replication process can take a long time to complete. This is, of course, dependent on network traffic, the size of the domain, and IBMLAN.INI replication parameters.

We wrote a procedure called LSC.CMD (LAN Server Check and Statistics) to help make sure that the DCDB replication has completed successfully. We have included this tool on the CD ROM accompanying this Red Book. LSC was written to query information about the DCDB directories and to check the status of the server services. This is important because the NETLOGON and DCDBREPL services must be running for DCDBREPL to work properly.

The syntax of LSC.CMD is
LSC {*} {ServerName} {/STAT}

where:

*: Looks at the LOCAL machine on which it is run.
ServerName: Represents the UNC name of the machine to be queried.
STAT: Performs a CHECK and provide statistics.

Another REXX tool, closely related to LSC, is called LSDCDB.CMD (Check Domain Controller Access Control Profiles). It can be used to check the DCDB directory structures on both the BDC and PDC to ensure that they match. We have included this tool on the CD ROM accompanying this Red Book.

To use the tool, run the command on both the PDC and BDC and simply inspect the output. Some patience may be required to wait until the replication has been completed. When the number of subdirectories in the PDC and BDC match, the replication is complete.

The syntax of LSDCDB.CMD is
LSCDCDB {DCName} {/FIX}

where:

DCName: Represents the UNC name of the PDC/BDC to be queried.
FIX: Is a request to fix damaged Access Control Profiles.

Note

Only run LSDCDB /FIX on the Primary Domain Controller. Changes made on the PDC are replicated to the BDC. Therefore, it does not make sense to fix the BDC since errors that existed on the PDC will continue to be replicated during normal server operation re-introducing a problem.

Note
Only run `LSDCDB /FIX` on the Primary Domain Controller. Changes made on the PDC are replicated to the BDC. Therefore, it does not make sense to fix the BDC since errors that existed on the PDC will continue to be replicated during normal server operation re-introducing a problem.

By looking at the two outputs in this example, we quickly see that only 13 of the expected 36 directories were replicated when the commands were run. When all 36 directories have been replicated, the process is complete.

One additional function of this tool that is extremely useful is that of checking and correcting Access Control Profiles within the DCDB directory structure. It would defeat the purpose of replicating a new DCDB definition to the new system if that definition were not correct.

When LSDCDB is run, the existing access control profiles of each user's directory in the DCDB are automatically compared against the default RWXCDAP access controls for each user. Incorrect, additional, and missing access controls found in these directories are highlighted.

If changes are necessary to correct problems with the PDC, it is advisable to make them before proceeding to the next step. Repeat the appropriate procedures described in Section 6.9.3 Allowing DCDB Replication to Complete and then to wait for a reasonable period of time for the replication to complete successfully.

When you are confident that the DCDB and access controls are OK, continue to the next step.

6.10 Step 2: Changing Server Roles