Lesson 3: Maintaining Network Services | MCSE Training Kit (Exam 70-222): Migrating from Microsoft Windows NT 4.0 to Microsoft Windows 2000 (MCSE Training Kits)

Measures to be taken to keep many of the network services up and running during the migration have already been discussed in previous chapters, so in this lesson, you'll look at steps to take to ensure that the production environment isn't compromised by the migration. You'll be reminded of the various network operations that will be affected by the migration process.

After this lesson, you will be able to

Understand each of the issues in the migration and plan for how services will be maintained.

Estimated lesson time: 40 minutes

Earlier chapters have dealt with the need for proper risk assessment of the migration project. During the assessment, migration failure points should be identified for specific attention. A failure point is an action which, if it fails, will affect the functionality of the production environment. For each failure point, a contingency plan must identify fallback positions and how to return to the migration path after the failure has been resolved.

Maintaining Network Services

A number of network services can be affected by the migration process. For example, you've already seen how the migration would affect RRAS services (Chapter 4, "Assessing Your Network Infrastructure"), file and folder replication (Chapter 6, Lesson 3, "Maintaining File Replication During the Migration"), and the logon process (Chapter 11, "Troubleshooting Windows 2000 During and After Migration"). However, other network services will also require attention during a migration.

Protecting Domain Controllers

You need to take measures to protect the PDC and the BDC before upgrading them. These measures are different and are detailed next.

PDC Pre-Upgrade Procedures

Before starting the upgrade of a PDC, you should at least do the following:

Ensure that you have Windows 2000 drivers for all the hardware devices in the server to be upgraded.
Perform a backup of the PDC, including the registry, and verify that the PDC can be restored successfully.
Install a BDC in the site where the upgrade is being performed, and synchronize it with the PDC immediately before starting the upgrade. This BDC won't be upgraded but is there to service clients while the PDC is upgraded. Once the entire domain is upgraded, the spare BDC can be taken offline.
If you have sufficient hardware, install a second BDC, synchronize that with the PDC, and then shut it down or disconnect it from the network. This BDC can then be used as a fallback if the upgrade fails and the live BDC is corrupted. In this situation, disconnect the failed PDC and damaged BDC, reboot or connect the saved BDC, and then promote it to the PDC for the domain. A variant of this approach is to promote the spare BDC system to be the PDC, and then shut it down. The original PDC machine to be upgraded can then be repromoted to a PDC immediately before being upgraded.
Duplicate all required trust relationships from the source domain into the Windows 2000 destination domain. If a Windows NT system is being restructured into an Active Directory infrastructure (in other words, there is already a Windows 2000 forest to which the new system is being added), the Windows NT system might need to maintain contact with the other servers in the source and trusted domains of the source, including the all-important servers providing DNS.
If you're upgrading the DNS server in your domain, your network will be without DNS for the duration of the upgrade. This will affect all clients of the DNS server, so you might need to configure and deploy a temporary DNS system prior to upgrade. Creating a temporary server can be quite complicated because you will need to have the same IP address of the original DNS system or add the temporary DNS server's IP address to all clients who use the one being upgraded. On a Windows NT system, you can quickly add all the host records to the temporary DNS server by copying the DNS BIND files from the %Systemroot%\System32\Dns folder on the original Windows NT DNS server.

During the upgrade, Windows 2000 will attempt to detect the devices in the PDC. If devices in the PDC aren't found or are detected incorrectly, the upgraded Windows 2000 system won't function correctly and you'll need to manually install the missing drivers after the upgrade. Therefore, you should perform a test upgrade on an identical platform before upgrading the production system.

BDC Pre-Upgrade Procedures

The consequences if the upgrade of a BDC fails aren't as great as the consequences if a PDC fails; however, a number of issues need to be considered:

If the BDC that is being upgraded is the only one in a subnet, you might want to deploy a second BDC for the duration of the upgrade. This second BDC can perform authentication while the first BDC is being upgraded. Not following this procedure might result in additional network traffic because of retries and slower user logons as authentication requests are sent to other systems.
You'll need a working network connection to a server in the domain the BDC is to join. During the upgrade, there might be significant traffic on this connection while the Active Directory information from existing Windows 2000 domain controllers is copied over to the upgraded BDC.
All the other pre-upgrade points for the PDC should be considered here as well.

Continuing Application Services

When migrating corporate, line-of-business applications, Web servers, e-mail systems, and essential database systems, you'll need to take those servers offline. In Lesson 1, clustering was mentioned as a technique for keeping application services available. You might also want to consider using duplicate servers, although if the information is dynamic, you'll then have to migrate the additional information to the migrated servers. For example, in an e-mail system, users will be constantly sending and receiving e-mail; therefore, new messaging information will accumulate on the temporary e-mail server after the upgrade of the original e-mail server has completed. You'll need a plan to migrate this interim e-mail to the upgraded e-mail server. You can take various steps to then migrate the users over, but all of these steps include substantial planning and reconfiguration.

For example, in Microsoft Exchange Server 5.5, you can enable all new e-mail to go to a .pst file on the client's local hard disk or home folder. However, you will then need to consider how to deploy the changes to the user's configuration and then how to move all the extra messaging stored on the local hard disk to the migrated server. You can see that, wherever possible, best practice is to have a temporary moratorium on all application services such as e-mail while the upgrade is proceeding (perhaps over a public holiday or in the early hours when users aren't active).

DNS Services

The issues surrounding the DNS and the Windows 2000 migration have already been discussed at length in earlier chapters. Essentially, you must ensure the following:

The DNS service is retained in the production environment while systems are migrated.
The DNS regime is compatible with the Active Directory structure being created.
The DNS servers in use support SRV resource records and dynamic updates. These features are required by Windows 2000.

NOTE
BIND 8.1.2 and later versions of DNS support SRV resource records and dynamic updates. If a server running at this level is present on-site, it can be retained.

WINS Services

WINS provides a name resolution service to clients that need to connect to other services on the network. During migration of the WINS server, WINS will be unavailable. To ensure that name resolution services are still available during the migration process, you can do the following:

Revert to using LMHOSTS files for access to all servers and IP printers. The LMHOSTS files can then be distributed to all clients via a logon process while the WINS service is still running.
Ensure that all clients are configured to access at least two WINS servers.You can ensure this by doing the following:
- Use DHCP.
- Select the properties of TCP/IP manually and click the WINS tab.
- Deploy the change via a logon script using the Reg.exe utility in the Microsoft Windows NT Server Resource Kit to change the registry setting of a client. The WINS registry key parameters are as follows:
```
 ValueName: HKeyLocalMachine\System\CurrentControlSet\Services\NetBT\Adapters\Your  network card adapter name\NameServerBackup Data Type: REG_SZ Value: <input the IP Address of the secondary WINS server> 
```

Be sure to have a secondary WINS server in case the main WINS server goes down. However, during the upgrade, the secondary WINS server will experience an extra amount of traffic. You might want to reduce the extra traffic by adding an LMHOSTS file containing the most accessed servers and printers in the network.

Ensuring Continuity of DHCP Servers

DHCP servers allocate IP addresses to requesting client workstations. During the migration of a system acting as a DHCP server, the server won't provide IP addresses for any clients. You'll either have to provide a replacement server (which will have to supply addresses from a different scope of IP addresses) or perform the migration at a time when there's no demand for DHCP services.

If the present DHCP server is running on a Windows NT system, it will be upgraded to the Windows 2000 version of the DHCP service, as seen in Lesson 2 of Chapter 6 (Practice 2). The DHCP options and current leases will be migrated onto the new system.

To perform the upgrade, the DHCP server must be authorized within Active Directory to assign IP addresses to clients. Authorization is performed from within the DHCP administrative tool.

As you've seen, during migration of the DHCP server, clients might be unable to receive an IP address from the scope. Lack of an IP address will prevent users from accessing any network services. To ensure that clients receive their various IP configuration settings during migration, you'll need to install a secondary DHCP server with a complementary range of IP addresses that doesn't overlap the existing one. You'll probably find a secondary DHCP server already in place because it's common practice in case of a network failure.

If you don't have a secondary DHCP server, you'll need to add one with sufficient IP addresses to handle the existing clients. The range of addresses selected should have a short lease period, perhaps eight hours. The short lease period will ensure that once the upgrade of the existing DHCP server is complete, all clients on the backup DHCP server will be reregistered on the upgraded DHCP server within a day of the upgrade, provided the secondary DHCP server has been taken offline.

Once the original server has been migrated to Windows 2000, you'll need to verify that the DHCP server service has been authorized and then activated by booting up a DHCP client in the same subnet as the migrated DHCP server. If the client receives its IP address settings, you know that DHCP is working.

After the migrated DHCP server has been verified and tested, you can remove the temporary DHCP server. There is also a utility that comes with Windows 2000 called Netsh that will back up WINS and DHCP configuration information.

Practice: Verifying the Windows 2000 DHCP Service After Migration

In this practice, you'll install and use DHCP on a system. Then you'll extract the DHCP settings and see how they can be applied to another DHCP configuration.

Exercise 1: Installing the DHCP Service on Windows 2000

In this exercise, you'll install the Windows 2000 DHCP server service and set up a scope of IP addresses to give to clients. You'll need to perform this installation on TRAINKIT1.

On TRAINKIT1, log on as Administrator with the password secret.
Open Control Panel and then open Add/Remove Programs.
Click Add/Remove Windows Components in the left pane.
In the Components list of the Windows Components Wizard dialog box, click Networking Services without clicking the check box. Then click the Details button.
In the Networking Services dialog box, select the Dynamic Host Configuration Protocol (DHCP) check box, as shown in Figure 12.10.
NOTE
If the DHCP service is already installed (there is already a check mark next to DHCP), you can skip the rest of Exercise 1 and resume with Exercise 2.

Figure 12.10 Installing the Windows 2000 DHCP service
Click OK to close the Networking Services dialog box. Click Next in the Windows Components Wizard dialog box.
Click Finish to complete the wizard.
The DHCP service is now installed on the system, but it is presently not providing an IP addresses.
Close all open dialog boxes.

Exercise 2: Configuring DHCP

Now that you have DHCP on your system, it must be authorized in Active Directory and configured with a scope of addresses. The scope of the addresses must be made active.

On TRAINKIT1, open DHCP from the Administrative Tools folder, as shown in Figure 12.11.
Select trainkit1.trainkit.microsoft.com and from the Action menu, select New Scope.

Figure 12.11 Configuring Windows 2000 DHCP

The New Scope Wizard will start.
Click Next at the welcome screen to move on to the Scope Name dialog box. Type the name DHCP Exercise and the description DHCP Configuration Backup into the appropriate fields, as shown in Figure 12.12, and then click Next.

Figure 12.12 Scope Name dialog box
On the IP Address Range page, enter the scope as a range of IP addresses by entering a start address of 192.168.0.150 and an end address of 192.168.0.180. The subnet mask field should be set to 255.255.255.0, as shown in Figure 12.13. Click Next.

Figure 12.13 IP Address Range page

The Add Exclusions page appears.
You aren't going to exclude any addresses, so click Next.
The Lease Duration screen appears. Here you set the duration of each lease. The default is eight days. If a lease isn't renewed within this time, the lease will lapse and the IP address will return to the pool.
Change the lease value to 10 days and click Next.
The Configure DHCP Options page appears.
You can configure DHCP to provide other information to clients as well as IP addresses. You're given the option to perform this configuration now. Select No, I Will Configure These Settings Later, as shown in Figure 12.14, and then click Next.

Figure 12.14 Configure DHCP Options dialog box
Click Finish to complete adding the scope.
NOTE
If you have any other scopes already defined, select those and delete them so that only the new scope is listed.

The scope has been added. Now it must be authorized and made active.
Right-click trainkit1.migkit.microsoft.com and select Authorize from the menu, as shown in Figure 12.15. If it is already authorized (an upward-pointing green arrow is displayed on the server icon), move on to step 10.

Figure 12.15 Authorizing the DHCP scope
Now expand the domain and select the scope in the left pane.
Right-click the scope and select Activate from the shortcut menu to make the scope available for clients, as shown in Figure 12.16.

Figure 12.16 Active DHCP scope
Verify that the red arrow in the icon next to the scope disappears. This indicates that the scope is now active and TRAINKIT1 will respond to IP address requests.
NOTE
If you still see a red arrow on your screen, press F5 to refresh the display.

One potential component that can affect business continuity in migrated systems is duplicate IP addresses. To avoid duplicate IP addresses and ensure continuity of service, always enable conflict detection on migrated systems. You'll do this now.
Right-click trainkit1.trainkit.microsoft.com and select Properties from the shortcut menu.
Click the Advanced tab and enter 3 in the Conflict Detection Attempts box, as shown in Figure 12.17. Click OK.

Figure 12.17 Conflict detection in DHCP
In the DHCP left pane, under the scope, select Address Leases.
Leave the DHCP program running so that you can view the allocation of addresses to clients, as shown in Figure 12.18. At this point, there shouldn't be any clients listed in the right pane.

Figure 12.18 Monitoring DHCP address leases

Exercise 3: Verifying the Windows 2000 DHCP Service

You will now use MIGKIT1 as a client of the DHCP server and verify that DHCP services are operational by obtaining an IP address.

CAUTION
In general, it is not recommended that servers have addresses allocated by DHCP. They should have their addresses fixed when Windows NT or Windows 2000 is installed, and their addresses should be excluded from the DHCP addresses available.

Log on to MIGKIT1 as Administrator with the password secret.
Right-click My Network Places and select Properties from the shortcut menu. Right-click Local Area Connection and select Properties.
The Network And Dial-Up Connections dialog box appears.
Select Internet Protocol (TCP/IP) and click the Properties button.
In the Internet Protocol (TCP/IP) Properties dialog box, select Obtain An IP Address Automatically, as shown in Figure 12.19.

Figure 12.19 Obtaining an IP address automatically
Click OK to close the dialog box. Click OK to close the Local Area Connection Properties dialog box.
MIGKIT1 is now configured to use DHCP.
Open a command prompt and enter these commands in sequence:
```
 ipconfig /release ipconfig /renew 
```
This will cause MIGKIT1 to release and renew a lease, using the DHCP server installed on TRAINKIT1. It should be allocated the address 192.168.0.150 because this is the first available address in the scope you defined.
Verify that the settings are correct on MIGKIT1 by typing ipconfig /all.
On TRAINKIT1, verify that MIGKIT1 has been assigned an IP address by checking Address Leases in the right pane of the DHCP program, as shown in Figure 12.20.

Figure 12.20 IP address now leased to MIGKIT1

Exercise 4: Extracting DHCP Configuration Settings Using Netsh

You now have a DHCP lease allocated to a client. Next, you'll export all the DHCP configuration settings for TRAINKIT1 into a text file using the Windows 2000 Netsh program.

From a command prompt on TRAINKIT1, type netsh dump dhcp server > dhcp.dmp and press Enter.
Examine the dhcp.dmp file by opening it in Notepad.
You should see file contents similar to those shown in Figure 12.21.

Figure 12.21 File showing DHCP configuration
In Notepad, open the Find dialog box from the Edit menu and search for 192.168.0.150 until you find the scope you set previously.
Examine other parts of the file and then close Notepad.
Now remove the DHCP service from TRAINKIT1 by using the Add/Remove Windows Components Wizard in Add/Remove Programs.
Reboot TRAINKIT1. (You don't have to do this, but doing so will ensure that all traces of DHCP have been removed.)
Check for any traces of DHCP.
Now reinstall the DHCP service and open DHCP again.
Note that there is no trace of your previous DHCP scope settings.
Open the command prompt and type netsh exec dhcp.dmp.
Access the DHCP service. You might need to refresh the screen by pressing F5.
You should see all the configuration settings; however, note that all client information is missing.

The Netsh command is useful for backing up configuration settings of a DHCP and WINS server.

Lesson Summary

In this lesson, you examined the procedures to ensure availability of service for network services. You examined the procedures that you should perform before upgrading a server. There must be a BDC operating in the same site as a PDC that is being upgraded. A second PDC or BDC can be configured and taken offline to hold a copy of the domain in case of an upgrade failure. There must be valid network connections to other servers if the new domain is to be a child of any existing domain or a root of a new tree in an existing forest.

You also examined techniques for keeping DNS, WINS, and DHCP available. In previous chapters, you saw how to ensure the continuity of RRAS and file and folder replication.