With Windows 2000, NT grows up

Sure this NOS is more stable and performs better, but it's not for mixed networks.

By Thomas Henderson
Network World, 01/03/00

The long-awaited successor to Windows NT is finally seeing the light of day. You won't be able to buy Windows 2000 until the middle of next month, but we tested the final code Microsoft shipped to manufacturing late last month.

We found that most of the bells and whistles of Microsoft's new flagship product work as advertised, planning for, testing and deploying Windows 2000 is going to be a slow and daunting process.

We looked at both Windows 2000 Server and Advanced Server. These editions vary mostly by the number of concurrent CPUs they support: up to four for Server and eight for Advanced Server. Clustering is available on Advanced Server, as is load balancing.

Enterprise installations won't reap full benefits from server upgrades unless they also put Windows 2000 on all their desktop machines because the most useful features of Windows 2000 server editions are confined to networks that are homogeneously Windows 2000.

Microsoft has written Windows 2000 Active Directory client software for Windows 95, 98 and NT clients, which supports changes in the Windows 2000 distributed file system, connections to the closest Active Directory system and easier password management changes. However, these sub-Windows 2000 clients still cannot part take in the full benefits of IntelliMirror, group policy management, Kerberos security and IP Security (IPSec) virtual private networks (VPN).

Active Directory pay dirt

Active Directory is central to security, resource access, the IntelliMirror features, administrative control and the availability of network resources (Click for an overview of the Active Directory design). And this is the feature that requires the most advanced planning. While it's possible to move Active Directory organizational units, user objects and network resources around easily, many of the Active Directory resources are topologically dependent to one another. While you can correct mistakes and manipulate Active Directory information easily using Active Directory MMC snap-ins, you're better off getting it right the first time to avoid adversely affecting these dependencies.

Each Windows 2000 server can play one of three roles in the Active Directory infrastructure: stand-alone server (not a participant in Active Directory), member server (member of an Active Directory domain, but not a domain controller), or a domain controller. The default is a stand-alone server, and that type of server can be easily promoted to domain controller if desired. We tested all three scenarios.

Servers can run in mixed NT and 2000 mode, or in native 2000 mode, which precludes relationships with NT domains except through directory brokerage services. Running Windows 2000 in "native" mode removes many of the widely publicized NT-LAN Manager security problems and will make access to network resources quicker and simpler for both end users and administrators.

When running in a mixed NT/2000 domain environment, an Active Directory domain controller assumes the role of the NT primary domain controller, and removes the former PDC from the domain. Managing NT domains in this scenario still requires a small amount of duplicated effort. Communication changes between the newly deployed Active Directory domain controllers and NT Domain Backup Domain Controllers may result in inaccurate replication across the domains.

Because the directory service is based upon an extension to the Internet Domain Naming Service, DNS must be present and working on the network where a domain controller for Active Directory is deployed. Windows 2000 uses Dynamic DNS, an extension to DNS that allows automatic updates of machine names against IP addresses. Dynamic DNS lets you get rid of one of the albatrosses of Windows NT: the Windows Internet Naming Service (WINS).

If you don't have a DNS infrastructure in place, you can install the service that bundled with Windows 2000 Server editions. We suggest examining the settings Microsoft chooses for the domain name server, as several times, we found the settings weren't correct for intranet deployments.

Active Directory loosely follows X.500 standard naming conventions, though it's not necessary to know how X.500 works to make use of Active Directory.

A Microsoft utility called Lightweight Directory InterFace (LDIF) can import Lightweight Directory Access Protocol information from any LDAP-enabled directory into Active Directory. You can also use this command-line tool to modify individual records or large amounts of information in one pass.

While LDIF is a handy tool, populating Active Directory from scratch isn't quite as simple. There are many Active Directory fields to populate. With any luck, you will already have that information sitting in a database somewhere on your network. However, even importing existing data can raise issues because most of the fields that might migrate from NT domain information comprise only a fraction of the Active Directory fields offered.

We used both a generic and modified Active Directory schema to test its extensibility and found that additions to the schema can be made easily. Once we made the changes, the schema spawned an event that copied the structure of the schema to each domain controller as expected.

Managing the directory is relatively simple. The Microsoft Management Console (MMC) is the administrative nexus for the directory. It's considerably easier to use than the cadre of tools required to manage NT domains.

Mirror, mirror

Once you have Active Directory in place, you can begin to use other administration features that tap into it, such as IntelliMirror. IntelliMirror is a group of server and client-side features that help you manage desktop configurations.

With IntelliMirror's client-side file/folder caching service for mobile users, you can make server folders available offline by caching them on the desktop machine. This store of files could be groupings of standard documents, reports, works-in-progress, etc. You can set IntelliMirror to synchronize the cache on the user's desktop at logon, logoff, during idle time on the host PC, or on a schedule.

We tested this feature extensively and found that while it offers enormous convenience, it's not a substitute for workgroup/activity management environments like Notes or Microsoft Exchange. It's hampered by several practical limitations, including the datalink speed of a mobile connection. We found that synchronization at logon or logoff time tested our patience unless the number of items to be cached was very small.

When we changed files on the server, our notebook client resynchronized the files correctly. When we modified the same files in the client's cache pool and in the server cache area, a subsequent resynchronization offered us a choice of resolving duplicate filenames and versions. When a server-based file was changed, we were offered the option of overwriting the network file or folder, keeping the one on the network, or keeping both by changing the filename of the file we had cached.

If we deleted a cached file on our notebook, the file was deleted locally. However, at the synchronization point, the network file would remain. If the network version of the file was deleted, we were given the choice of saving the file to the network, or deleting it from our computer.

IntelliMirror also supports roaming user profiles allowing Windows 2000 desktop settings to be cached on a server. That means you can log on to a different physical machine but see your own familiar desktop icons and Windows Start menu items, as long as you're using a Windows 2000 Professional client. Applications don't have to be installed on the desktop for a user to see their icons or menu choices, and only items stored on the network will roam. Users are presented with a Start Menu with choices defined by administrators. When the user tries to run an application on a "foreign" desktop on which an application isn't installed, a Windows Installer will download the software (called a package file) to that machine.

The drawback of this scheme is that applications are not available unless they've been packaged and published by a network administrator. Additionally, few software packages are currently optimized for just-in-time (JIT) installation, so we had to use the WinInstallLE (Light Edition) to test deployment of a non-Microsoft application. MS Office 2000 is the only application that we could find that uses the JIT installation feature. Users who install their own applications on their personal Windows 2000 machines aren't going to be able to use them on other machines, unless they're stored them on the server, leaving an icon on their desktops for access. Microsoft packages Veritas' WinInstall program that lets administrators produce downloadable packages that can be much smaller than the "full-blown" application.

The portable desktop worked well in our environment. We found launching Word and Excel 2000 took 12 minutes to download onto an otherwise empty Windows 2000 PC over a Fast Ethernet intranet with no other traffic. While these are large applications and therefore may be worst-case scenarios, that's way too long to suit most users, even if the process need occur only once.

Security

An important consideration for any network operating system is security. Windows 2000 addresses security issues with Kerberos authentication, a bundled certificate server, an Encrypting File System and support for IPSec VPNs.

The Kerberos system in Windows 2000 generates Ticket Granting Tickets when a user logs on to Active Directory. These tickets are used as shortcuts to authenticate users to other domain controllers without forcing them to log on again. The entire process is transparent to users and is encrypted.

Windows 2000 supports a file-signing service called Authenticode. This service verifies that a file hasn't been tampered with. If your users are running Internet Explorer, you can screen software downloads through the Active Directory group policy mechanism.

A new Encrypting File System lets users encrypt their files and folders, and after these objects are encrypted, the process of decrypting them is transparent to the user. To be encrypted, the files must be stored on an NTFS partition of a Windows 2000 server. Fortunately, the administrator gets a data recovery certificate so that the files can be decrypted upon the untimely exit of the user. We found this worked easily but would prefer that service was not available to all users by default.

With Windows 2000 you can also now delegate administration tasks based on Active Directory groups. It's possible to create administrative authorities for specific individuals by making them part of groups within the directory. This feature eliminates the security risk associated with NT 4.0 in which you could not grant partial rights. If you wanted a help desk attendant to be able to change passwords, you formerly had to grant them full administrative rights.

IPSec is available in Windows 2000 clients and servers. It's used for VPNs and is implemented via a group policy snap-in to the MMC. Both editions of Windows 2000 Server include a certificate authority that provides the basis for a public-key infrastructure (PKI). The PKI provided is also the crux of smart card usage. We didn't test either of these features.

Performance and availability

Microsoft has made several improvements in this category with this new release.

We tested file I/O using Windows 2000 Professional clients against differing servers with bulk folder and file copying. We found performance of both Windows 2000 server editions to be comparable for gigabyte file transfers and approximately 18% faster than the same exact same platform using Windows NT 4.0 with Service Pack 5 applied.

Windows 2000 lets you cluster two nodes in Advanced Server, four in the unreleased DataCenter version servers to help promote high availability of server files and other resources. We found connecting two Compaq 3000R servers together into a cluster was surprisingly simple. The list of applications that can take advantage of Microsoft's clustering is not very long (see the Microsoft clustering partner list).

We ran Microsoft SQL Server 7 with Service Pack 1 on our cluster. When we simulated a server failure, the surviving member of a cluster took just 80% of the time - or thirty seconds - that a similar test with clustering on Windows NT 4.0 with Service Pack 4.

File and print improvements

While Active Directory and IntelliMirror are garnering most of the headlines with this release, Microsoft has made improvements to some other system features. These first-time Windows features are ones that competitors have been touting for several years and include user disk quotas, dynamic volume management so that changes to volumes no longer require a reboot, and bandwidth control/admittance support.

Microsoft has also improved its printing management capabilities. As an example, it's possible to use group policies within the Active Directory to define alternate printer location for shared printing devices.

Getting started

While Microsoft has added numerous features to the operating system, the company had simplified the installation process. We tested Server and Advanced Server editions on several platforms. We had no trouble upgrading a Windows NT to either Windows 2000 server edition.

Windows 2000 server editions support Plug and Play hardware discovery and integration. The number of hardware items supported has increased vastly from beta and early release candidates of the operating system. Nonetheless, several items that we expected to have in-the-box driver support for were missing.

Before completing the upgrade on each server or workstation that's being upgraded, Microsoft displays a list of hardware that worked in Windows NT 4.0 that may not work with Windows 2000.

You may be unable to install either Windows 2000 Server edition onto servers that use older ISA cards - especially network cards. Many older ISA cards are unable to provide Plug-and-Play information during installation, and manually setting these cards can be difficult. In our tests, Compaq and Hewlett-Packard hardware, which had BIOS settings that identified the hardware, worked well, but other "white box" brands didn't. Microsoft publishes an extensive hardware compatibility list; we recommend checking it closely.

The default installation for both server editions doesn't automatically install the Active Directory service. This suits the needs of smaller networks, or those networks that aren't in immediate need of the Active Directory service but isn't something you should consider for your enterprise network.

Microsoft has finally delivered on a long laundry list of features that began building more than five years ago. Like a long restaurant menu, making appropriate choices on how you will use Windows 2000 in your enterprise network is going to take some time. And although it's possible to drop a Windows 2000 server into an existing network, we don't recommend doing so until you've jumped through every planning hoop possible.

How we did it

We tested both Windows 2000 Server and Advanced on many platforms. The majority of the machines were Compaq Proliant 3000R servers with four, 550Mhz Pentium III CPUs with 4G bytes of RAM. We also ran tests on a pair of Proliant 1600 servers with 450 MHz Pentium CPUs and 256M bytes of RAM. We also tested Windows 2000 on "white box" machines. These are generic machines with a variety of motherboards, ranging from 166Mhz Intel motherboards to 700Mhz AMD Athlon motherboards. The Windows 2000 Server versions were tested against a variety of client machines including several Compaq Prosignia 2450s, Compaq, IBM and Sony notebooks; and a single Apple Macintosh G4. While most of the clients were running Windows 2000, we did include several Windows 95/98, Linux, and of course, MacOS 8 machines.

As Windows 2000 server editions are enabled through the design and deployment of the Active Directory and its domain controllers, we imported a 4844 user Lightweight Directory Access Protocol user database from another directory then propagated the directory among four Windows 2000 Active Directory domain controller servers in the lab. We then defined the elements of the Active Directory, manipulated user objects into groups, and then imposed Group Policies on the groups that we created.

These systems ran on both Fast and Gigabit Ethernet network segments. We designed several scenarios for Active Directory replication, and then emulated outages of key domain controller replication servers to see how the system reacted.

We also upgraded a multimaster Windows NT 4.0 server resource domain to see how the directory co-existed with the Active Directory. In addition, we evaluated how easily a conversion to a homogenous Active Directory infrastructure would work.

We tested file I/O using Windows 2000 Professional clients against various servers using bulk folder and file copying tools.

We tested IntelliMirror by choosing a number of server-based folders, populating them with document files, then forcing a synchronization on a Sony VAIO PictureBook PC running Windows 2000 Professional. We changed several dozen files, then reconnected the notebook to the network. We also deployed Roaming User profiles that cache Windows Desktop resources but found that there are a limited number of software applications that allow just-in-time installation; other packages must be distributed by using a light edition of Veritas WinInstall.

We also tested the simple failover clustering of Advanced Server by crashing the server. We tested clustering between two 3000R Compaq servers using Compaq Gigabit Ethernet Adapters against a Compaq Gigabit Ethernet switch. The second server in the cluster picked up the failed server's operations in about 30 seconds.