Can Win2K and NT 4.0 Coexist?

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.