Tests in a small lab environment show the two OSs play well together
OK, you're ready to take the plunge and start testing Windows 2000 systems with your Windows NT 4.0 network. You might start by searching Microsoft's Web site, Windows 2000 Magazine, and other sources for procedures and techniques to help you build a cooperative mixed environment. But unless a great deal of new material has been published during the past few months, you'll most likely find only a scant offering of tips. I've been testing a mixed Win2K and NT 4.0 environment for months, and I'm ready to share what I've learned about configuring Win2K systems and integrating them into an NT 4.0 network.
Testing 1-2-3-4
My test environment consisted of an NT 4.0 domain with one primary domain controller (PDC) and one backup domain controller (BDC), a standalone NT 4.0 RAS PPTP server, and two NT 4.0 workstations. Most of my NT 4.0 systems were running Service Pack 5 (SP5) with selected hotfixes. On the Win2K side, I used an IBM ThinkPad 600E running Win2K Professional's prerelease version (build 2194). Later, I installed a second system root to boot the final Win2K Advanced Server release. I also configured four different versions of Win2K AS on a Dell XPS T system: a standalone server, a domain controller, a domain controller with the Certificate Authority (CA) enterprise version, and a VPN server with the CA standalone version.
I conducted four specific coexistence tests. First, I explored the setup and configuration steps you need to follow to successfully log Win2K Pro and Win2K AS standalone server systems on to an NT 4.0 domain. Second, I tested cross-domain access between a Win2K domain and an NT 4.0 domain, with and without a trust relationship between the domains. As part of the mixed-domain test, I alternately logged my Win2K Pro system on to both domains. Third, I'm a VPN fan, so I tried several VPN connections, including Win2K Pro to an NT 4.0 RRAS server, Win2K Pro to a Win2K RRAS server, and an NT 4.0 VPN client to a Win2K RRAS server. Fourth, I experimented with Microsoft Management Console (MMC) snap-ins for remotely administering NT 4.0 systems from a Win2K server.
Because I was booting from among four system roots on one Win2K system and three system roots on the other, I had to keep checking to see which version was running. I quickly discovered that you can display a Win2K system's name and domain in one of two ways:
- Right-click My Computer, choose Properties, and select the Network Identification tab.
- Right-click My Network Places, choose Properties, select the Advanced tab, and click Network Identification.
Booting Multiple Win2K System Roots
Win2K AS booted correctly with two system roots on the same physical drive and three system roots on the same logical drive. Remember that to successfully boot several installations, you must give each instance a unique system-root name. I also had no problems dual-booting Win2K and NT 4.0 on the notebook's C drive. On the Dell XPS T, I started with NT Workstation 4.0 in C:\winnt and installed Win2K Pro in C:\win2kpro, Win2K AS in D:\win2kas, my domain controller in D:\win2kdc, and my VPN server in E:\win2kserver. To keep from getting confused about which instance I was booting, I edited the boot.ini file and changed the default description for each system root to reflect the configuration I was booting (e.g., Win2K AS, VPN server).
To define the instance I wanted to boot automatically, I right-clicked My Computer, selected Properties, selected the Advanced tab, and clicked the Startup and Recovery button. As Figure 1 shows, the Startup and Recovery dialog box's System startup field displays all the entries from the boot.ini file. From this list, I selected the system root I wanted to boot by default. Win2K displays the boot.ini entries at system startup, so you can use the up and down arrow keys to override the default entry and select another root.
Logging a Win2K System on to an NT 4.0 Domain
As with NT 4.0 systems, you must create a computer account for a Win2K system before it can successfully join an NT 4.0 domain. After I took my Win2K Pro notebook off the network for a week, the password for the computer account on the notebook wasn't synchronized with the password on the NT 4.0 PDC, so I couldn't log on to the domain. While troubleshooting the computer-account problem, I found this error message in the notebook's System event log:
Because of repeated network problems, the time service has not been able to find a domain controller to synchronize with for a long time. To reduce network traffic, the time service will wait 960 minutes before trying again. No synchronization will take place during this interval, even if network connectivity is restored...
The Win2K time service synchronizes the system date and time, and Win2K systems look to the Win2K root domain controller as an official time server. Time synchronization is crucial in W2K because Kerberos authentication uses workstation time to generate an authentication ticket. When a system can't contact a Win2K domain controller for a time update, Kerberos can't generate a valid authentication ticket and computer and user accounts can't successfully log on.
My NT 4.0 PDC isn't a time server, so my Win2K systems had no time-synchronization source and thus routinely reported the time-service error above. If you don't have a time server on your NT 4.0 network, you can configure an NT 4.0 system as a time server or access one of several public Internet time servers to set the clock on Win2K systems. The command
net time /setsntp:<time server IP address>
establishes an official time source, and the command
net time /querysntp
displays the official time source.
To manually reactivate a Win2K computer account when the password isn't synchronized with the account password on the NT 4.0 PDC, you can delete and recreate the account in the NT 4.0 domain. After you recreate the account, you must reboot the Win2K machine to synchronize the new account credentials.
With the exception of the expired password on the computer account, the Win2K Pro workstation joined my existing NT 4.0 domain with no problems. It was equally cooperative when I logged on to the Win2K domain. To change domain membership on a Win2K system, I right-clicked My Computer, selected Properties, selected the Network Identification tab, clicked the Properties button, and entered the name of the target domain. At the resulting prompt, I entered a valid username and password for the Win2K domain. After a slight delay while Win2K Pro located the Win2K domain controller, the OS prompted me to shut down and reboot the workstation to activate the domain change. Upon reboot, the workstation joined the domain successfully. I successfully alternated the workstation's domain membership many times during the course of my testing. Figure 2 shows the Win2K workstation as a member of the NT 4.0 Wildwood domain and the Win2K Wildwooda domain. Don't let this window mislead you—a workstation can have an active account in several domains, but it can log on to only one domain at a time.
Win2K AS
The first time I configured a standalone Win2K AS server, I wanted to avoid mixing Win2K dynamic DNS (DDNS) and NT 4.0 DNS. When I checked Networking Services during server setup, the Details button showed that the setup wizard installs DNS and WINS services by default, so I unchecked these services to prohibit their installation. Later, when the setup program asked me whether I wanted to change the server's address from DHCP-assigned to static, I entered a static IP address, subnet mask, default gateway, and the addresses for my legacy DNS and WINS servers. A few screens later, the setup wizard rebooted my Win2K AS server, but the system couldn't locate the NT 4.0 domain controller. After the final reboot, I logged on as the local administrator and changed the server's domain membership to the NT 4.0 domain. The server then joined the NT 4.0 domain on the first try.
To ensure that your standalone Win2K servers experience no problems operating in an NT 4.0 domain, I have three important configuration tips for you. First, define a host record for the new Win2K system in the legacy DNS server before the new Win2K system joins the domain.
Second, define a DNS suffix for the standalone Win2K server. If you follow the installation procedure I outlined, your Win2K standalone server most likely won't have a DNS suffix because the setup wizard doesn't enter or prompt you to enter one. (According to Microsoft, the problem is with the Win2K AS standalone server installation only; the setup wizard enters a DNS suffix when you configure a Win2K domain controller.) Without a DNS suffix, your server might not be able to resolve TCP/IP names on the network, even if you use the DNS tab on Advanced TCP/IP Settings to enter the TCP/IP address for a legacy DNS server. To check whether a DNS suffix is defined for your system, run the command Ipconfig/all. If the Primary DNS Suffix field (the second line of the Ipconfig display) is blank, you need to define a DNS suffix.
To specify a Win2K computer name and its DNS suffix, right-click My Computer, select Properties, select the Networking Identification tab, and click the Properties button to open the Identification Changes dialog box. You define the computer's host name (e.g., w2kserver) in this box. Click the box's More button to open the DNS Suffix and NetBIOS Computer Name dialog box. Here you enter the DNS suffix (e.g., wildwooda.com). Figure 3 shows these two dialog boxes. You define all other TCP/IP information, including the TCP/IP address, gateway, DNS, and WINS information, on the Properties tab of the LAN adapter. After you enter the DNS suffix, click OK to reboot the server. Rerun the Ipconfig/all command to verify that the DNS suffix appears as you entered it.