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

Windows 2000 relies on some network services much more heavily than does Windows NT 4.0. You'll need to ensure that all your core networking services are functioning correctly once you've migrated to Windows 2000. In this lesson, you'll learn what to if these networking services fail.

After this lesson, you will be able to

Resolve name resolution problems.
Resolve replication issues.
Resolve NetBIOS service issues.
Resolve network service issues, including DHCP and DNS.

Estimated lesson time: 40 minutes

Name Resolution Problems

Name resolution problems can be critical during a migration from Windows NT 4.0 to Windows 2000. For example, if you can't perform name resolution properly, you'll be unable to run the Active Directory installation wizard in your Windows 2000 environment. A thorough understanding of the problems you might encounter with name resolution and how to solve them is essential if your Windows 2000 migration is to proceed smoothly.

To ensure that your name resolution problems are minimized, you should do the following:

Ensure that you use Active Directory–Integrated DNS wherever possible.
Ensure that all DNS clients have at least two valid DNS servers specified in their configuration.
Ensure that your DNS servers are configured to allow dynamic update.
Ensure that the zone corresponding to the root domain is available to all DNS clients.

If DNS is unavailable or doesn't support dynamic updates, the records for a new domain controller can't be created when you run the Active Directory installation wizard. The installation wizard will prompt you to confirm your DNS server settings at this point or ask whether you want to set up your own server as a DNS server.

NOTE
If you already have a DNS environment in place and are having network connectivity problems, you shouldn't create your own server as a DNS server while installing Active Directory. Doing so would result in two primary DNS servers for a particular zone. Instead, you should resolve the network connectivity problems and ensure that the DNS server information is correct in the TCP/IP settings of the server you're upgrading.

If name resolution isn't functioning as it should, it's quite possible that not all the records that should be in DNS are actually there. Ensure that you're using dynamic update on your DNS servers, or, if you've elected not to, ensure that all the records have been manually entered.

To ensure that the appropriate records are in DNS, you can use the DNS administrative tool or the Nslookup utility. To repopulate DNS with Active Directory information in the event of a failure, you can use the Netdiag utility. You might also need to run ipconfig /registerdns and restart the Netlogon service.

Practice: Testing Your Network and Recovering DNS

In this practice, you'll test network connectivity and recover from a DNS database corruption.

To check the status of DNS

Log on to MIGKIT1 as Administrator with the password secret.
If you haven't already copied the Tools folder from the Supplemental Course Materials CD to a Tools folder on the C: drive of PC2, MIGKIT1, do that now.
Open a command prompt to the Tools folder and type netdiag /L.
Note how Netdiag tests all the key elements of your server, including the availability of DNS. (See Figure 11.9.) All the tests should either be shown as skipped or passed at this stage.
Now look at the log created by the Netdiag command by typing notepad netdiag.log.
Note the number of tests listed in the log file and especially that the DNS test passed.
Leave the command prompt open.

Now you're about to use the DNS administrative tool to do some drastic damage—but don't panic (and don't do this on your live systems).

click to view at full size.

Figure 11.9 Running a Netdiag test

To purposely bring down the DNS service

Log on to TRAINKIT1 as Administrator with the password secret.
Open DNS from the Administrative Tools folder.
When the DNS console appears, expand the forward lookup zones to the trainkit.microsoft.com zone. Delete the _msdcs and _sites folders in trainkit.microsoft.com so that the screen looks like the one in Figure 11.10.

Figure 11.10 Corrupting the DNS database

To test the DNS service on MIGKIT1

Return to MIGKIT1 and the command prompt.
Type netdiag /L again.
Type notepad netdiag.log again.
Scroll through the log file until you reach the DNS test component.
You should see all DNS tests failing, as shown in Figure 11.11.

Figure 11.11 Confirming the DNS failure

To repair the DNS service

Return to the command prompt on MIGKIT1 and type netdiag /fix.
Switch to TRAINKIT1 and return to the DNS tool.
Right-click (if necessary) trainkit.microsoft.com and select Refresh from the shortcut menu.
Now check the forward lookup zone and confirm that the _sites and _msdcs folders have been recovered.

Netdiag is a useful troubleshooting tool for reporting and repairing problems.

Replication Failures

Domain controllers need to replicate with one another successfully to maintain Active Directory information across your enterprise. If replication doesn't occur successfully, problems such as failed logons and failure to access resources can occur.

The site structure you've chosen will significantly affect the replication topology. Recall that all intrasite replication occurs via remote procedure call (RPC) mechanisms, and intersite replication must also occur over RPC if the servers are in the same domain (otherwise, they can use SMTP).

Replication can fail for a number of reasons. Here are some of the most common ones:

Network hardware has problems.
DNS fails.
Replication should occur via RPC, but you don't have the appropriate links.
Replication should occur via SMTP, but you don't have an SMTP infrastructure to support it.
Your sites and site links aren't configured properly.
The Knowledge Consistency Checker (KCC) isn't creating a replication topology.

Two tools from the Microsoft Windows 2000 Server Resource Kit are particularly useful for troubleshooting replication problems: RepAdmin and Replmon. RepAdmin can be used to administer replication topologies and Replmon can be used to graphically locate and view replication topologies and instigate replication between partners. Figures 11.12 and 11.13 show some of the options available with Replmon.

click to view at full size.

Figure 11.12 Replmon options for a server

click to view at full size.

Figure 11.13 Replmon graphical representation of domain controllers in the trainkit forest and server properties of trainkit1

NetBIOS Service Issues

Once your migration is complete, if you have no NetBIOS applications, you'll have no real need for NetBIOS. However, during a migration, it's an important part of your Windows 2000 environment. Indeed, if NetBIOS applications remain, NetBIOS will also remain, potentially long after you're running Windows 2000 in native mode.

Failure of NetBIOS name resolution can occur in a number of situations. Some of the most common causes are listed here:

The WINS servers are unavailable.
The WINS database is corrupt.
The LMHOSTS or HOSTS file contains incorrect information.
The WINS clients have incorrect WINS server addresses specified.

If NetBIOS name resolution does fail during a migration, legacy clients might be unable to contact domain controllers, and problems can occur with synchronization between the Windows 2000 PDC emulator and Windows NT 4.0 BDCs. Ensure that you implement a fault-tolerant mechanism such as backing up WINS servers for maintaining NetBIOS services during the migration.

Don't remove WINS from your environment until you're sure that it's no longer required. (As seen in Chapter 3, "Assessing Your Current Infrastructure," you can use Performance Monitor to analyze your WINS servers before removing them from the Windows 2000 infrastructure).

DHCP Problems

DHCP servers function under Windows 2000 in much the same way as they do under Windows NT, with one fundamental exception—they must be authorized in Active Directory to function. When you upgrade a Windows NT server running DHCP, it ceases to function as a DHCP server until the upgrade is complete and you authorize the server. In a migration scenario, it often makes sense to migrate this role onto servers already running Windows 2000 rather than upgrade the server and lose DHCP in the meantime.

If you do choose to migrate the role, remember that the considerations you had for DHCP under Windows NT 4.0 still apply. For example, if you migrate the role to a server in a different subnet and you want to service the same clients as you always did, you'll need the router(s) separating you from the old subnet to forward BOOTP requests, or you'll need to use DHCP Relay agents.

NOTE
BOOTP might be shown as RFC 1542 in some manuals.

Although authorizing DHCP servers gives you a measure of control over which servers hand out IP addresses, remember, this doesn't stop anyone from bringing a DHCP server onto the network that can service Windows 2000 DHCP clients. For example, your old Windows NT 4.0 servers can service DHCP clients, as can authorized DHCP servers from a separate Windows 2000 forest. By registering your DHCP servers in Active Directory, it's harder for rogue DHCP servers to service Active Directory clients.

One significant difference between Windows NT 4.0 DHCP clients and Windows 2000 DHCP clients is their behavior in the event of not being able to find a DHCP server. Windows NT 4.0 clients are configured with an address of 0.0.0.0 under these circumstances, whereas Windows 2000 clients are automatically assigned with an address in the range of 169.254.0.1 through 169.254.255.254. (Incidentally, Microsoft Windows 98 and Microsoft Windows Me clients also behave this way.) This feature is known as Automatic Private IP Addressing (APIPA). Unusual network behavior such as certain subsets of clients being able to communicate with each other but not with the rest of the network can be caused by this "self-assignment" of IP addresses.

If you'd like to check whether DHCP addresses are being handed out to the clients, perform these steps:

Open a command prompt and type ipconfig /all.
Look at the IP address configuration.
If the IP addresses begin with 169.254. and no DHCP server is listed, the clients might be having connection problems with the DHCP server because these addresses are self-assigned. The incorrect IP addresses will be confirmed if you try to access servers on the network and fail to connect.

It is also worth mentioning the important role of the DHCP client in Windows 2000. Regardless of whether addressing is automatic or static on a client in a Windows 2000 environment, the DHCP client service is still important because it's responsible for registering the client with DNS by default. So if clients aren't being registered in DNS, it could actually be the DHCP client service that isn't running.

Lesson Summary

In this lesson, you learned how to troubleshoot a variety of network service failures, including DNS, WINS, DHCP, and replication problems.