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.
Third, clear the Register this connection's addresses in DNS check box on the DNS tab of Advanced TCP/IP Settings. Win2K AS selects the box by default. However, when you're running NT 4.0 DNS, legacy DNS servers don't recognize a dynamic name registration. If you don't clear the box, you'll see several errors in the DNS server's System event log, including
Event ID 7053 DNS Server sendto() function failed. The data is the error.
and
Event ID 5000 DNS Server is logging numerous run-time events. This is usually caused by the reception of bad or unexpected packets, or from problems with or excessive replication traffic...
Configuring a Win2K Domain Controller
You create a Win2K domain controller when you install Win2K AS with the AD component. When you select the option for a new domain, the setup wizard asks you to enter the domain name, which is typically a TCP/IP Fully Qualified Domain Name (FQDN—e.g., win2000mag.com). The NetBIOS field on the same prompt displays the equivalent name for NT 4.0 systems (e.g., win2000mag); Win2K systems register this NetBIOS name in WINS for NT 4.0 compatibility. After you reboot the AD domain controller, you manage most aspects of the Win2K domain from three AD MMC snap-ins: Active Directory Users and Computers, Active Directory Domains and Trusts, and Active Directory Sites and Services. These three applications also appear individually in the Administrative Tools program group.
You run the command-line utility Dcpromo to demote a Win2K domain controller to a standalone server. You can run Dcpromo from the Configure Your Server applet in Administrative Tools, from the Start menu's Run option, or from a command prompt. After running Dcpromo, you must reboot the system to activate its new status as a standalone server. I promoted and demoted Win2K domain controllers during testing with excellent results, never once hanging the system. The demoted server had no problem changing its role from a Win2K domain controller to a Win2K server in my NT 4.0 domain.
When I installed DNS on my Win2K domain controller, I was pleased with the wizard that helped me define the zones, including the reverse-address zone, which you no longer have to create manually. DNS, like most Win2K services I tested, has a restart option which eliminates NT 4.0's stop-and-start steps.
I next wanted to test cross-account access between the Win2K and NT 4.0 domains. You set up an explicit trust between Win2K and NT 4.0 domains the same way you set up trusts in NT 4.0 domains. In Win2K, start the Active Directory Domains and Trusts utility, which displays a list of Win2K domains. Right-click the Win2K domain for which you want to create a trust, select Properties, and choose the Trusts tab. The screen you see is similar to the corresponding screen in NT 4.0. Figure 4, page 72, shows a two-way explicit trust that I configured between my Win2K domain (Wildwooda) and my NT 4.0 domain (Wildwood).
Win2K is much smarter than NT 4.0 about creating trusts. To display the trust's status, select the trusted or trusting domain and click the Edit button. At the resulting tabbed page (which Figure 5 shows), you can click the Verify button to troubleshoot and, if necessary, update the trust relationship. Because I was booting the same system as a standalone server and a Win2K domain controller, I used this feature frequently to confirm that the NT 4.0 trust still existed after the Win2K domain controller had been offline for most of the day.
RRAS and CA
As a longtime VPN fan, I was eager to explore Win2K's new VPN features on both the server and the client side, as well as interoperability between Win2K VPN clients and a legacy server and legacy clients and a Win2K VPN server. Using the default settings, I quickly set up a Win2K RRAS server. For my first RRAS test, I defined 10 PPTP ports and successfully created VPN connections from Win2K and NT 4.0 systems to the Win2K RRAS server. I also successfully connected a Win2K PPTP client to my NT 4.0 RRAS server. For my next Win2K RRAS server test, I defined 10 Layer 2 Tunneling Protocol (L2TP) ports and quickly confirmed that because L2TP relies on IP Security (IPSec) for encryption, a Win2K L2TP client needs a computer certificate to successfully connect to a Win2K RRAS server.
Win2K AS includes a CA service you can install in enterprise or standalone mode. When you install CA in enterprise mode, Group Policy defines how computers and users request certificates and, by default, CA automatically grants or denies requests based on the requestor's credentials.
When you install CA in standalone mode, you must use Microsoft Internet Explorer (IE) or another browser to manually request a certificate from CA. Standalone CA defines a \\server\CertSrv share that users can access to request certificates by filling out the displayed form. Unlike the enterprise version, the standalone version requires a Win2K domain administrator (or an account with sufficient permission to manage CA) to manually approve each user's certificate request. After installing standalone CA, I requested and received a computer certificate for my Win2K workstation, which successfully used L2TP/IPSec to connect to the Win2K RRAS server with no noticeable delay.
The animated network icons that appear in the lower-right corner of the Win2K screen are helpful for troubleshooting LAN, WAN, and VPN connections. At one point, my Win2K Pro system had an ISP connection, a LAN connection, and PPTP and L2TP/IPSec connections to the Win2K RRAS server. Each connection had an icon that showed exactly what was happening at both ends of the link. The icon feedback is a real confidence builder and a great first step for troubleshooting connectivity problems. And, as one Windows 2000 Magazine reader has pointed out, the transmit and receive indicators help you monitor the sometimes lengthy network delays you experience while a Win2K system is searching, possibly in vain, for a network resource.
As I booted different configurations on my Dell test system, some with and some without Win2K RRAS, I was pleased that RRAS successfully reestablished its connection to the Internet through my WAN link. I experience constant headaches with NT 4.0 RRAS, but the basic RRAS features I tested in Win2K operated correctly all the time.
Remote Administration with the MMC
Before you go too far testing Win2K, download the quick tutorial "Step-by-Step Guide to the Microsoft Management Console" from http://www.microsoft.com/windows2000/library/planning/ to learn how to customize the MMC. Organizing MMC snap-in windows to suit your personal preferences can save you time. I have one window for all AD services, another for CA and certificates, and another that presents all the information I need to monitor and manage my local system.
Many MMC snap-ins have a check box that lets you point the snap-in at remote systems. I recommend you select this check box because this feature lets you manage NT 4.0 systems remotely from a Win2K server or domain controller.
Figure 6 shows the expanded view of the MMC Computer Management snap-in monitoring three systems: a Win2K server (Local), an NT 4.0 domain controller (BDC), and an NT 4.0 server (ASPEN). To create this multisystem view, I selected the Allow the selected computer to be changed when launching from the command line check box when I loaded the snap-in so that I could direct the tools to remote systems. Although many Computer Management features (e.g., disk quotas, disk defragmentation, device manager) are specific to Win2K, you can examine shares and connections and stop and restart services on remote NT 4.0 systems from this interface. When you expand a function that NT doesn't support, the snap-in returns the message The connection to computername could not be established.
A Favorable Impression
In my small lab environment, I was pleasantly surprised by how well the new and legacy Windows technologies worked together. The ease with which I could promote and demote Win2K domain controllers and the cooperation between Win2K and legacy domains impressed me. The IBM ThinkPad easily booted Win2K Pro or Win2K AS, and the notebook power-management features were all operational. Win2K and NT 4.0 clients changed their domain membership between Win2K and NT 4.0 upon demand. During weeks of testing, I never experienced a blue screen or system hang. I enjoyed watching Win2K and NT 4.0 clients connect to the Win2K RRAS server concurrently and loved the feedback from the network icon status screen.
Win2K installation wizards facilitated the installation of new components, and I found the default settings for most components adequate for getting started. Go with the defaults the first time you install a new component or feature, and change them only if you don't get the results you want or expect. To facilitate testing, enable auditing for logon and logoff failures and privilege use on domain controllers or servers in both Win2K and NT 4.0 domains. When you get unexpected results, check the event logs on all affected systems for troubleshooting information.
I do have a few complaints about Win2K. The network timeouts are still too long, loading the vendor list of print drivers takes forever, and although Microsoft significantly reduced the number of required reboots, many situations still require a system restart. However, overall, I think you'll be pleased with how easy it is to integrate Win2K into your existing NT 4.0 network.
