NT 5.0 Gets Better and Better--Mostly

Most attendees of Microsoft's Professional Developers Conference (PDC) in September probably didn't expect to see many new Windows NT 5.0 developments. I certainly didn't because of the numerous developments Microsoft revealed at last year's PDC. (For an overview on the 1996 PDC developments, see my article, "The Evolution of NT," February 1997.) But Microsoft surprised the 7000 attendees with a healthy dose of new capabilities. NT 5.0 has key developments in five areas: the Active Directory (AD), security systems, infrastructures, hardware support, and networking tools.

Compelling New AD Features That You Might Lose Out On
From the beginning, NT 5.0's directory service, AD, has been in the spotlight. Microsoft intends AD to be a big, flexible, distributed, fault-tolerant database containing user account information, network shares information, security data, shared applications, and just about anything else that you want to put in it. AD eliminates or severely modifies the current notion of local and global groups, trust relationships, the Network Neighborhood, and user accounts.

Installing NT 5.0 and its directory service on your existing network will yield some positive features, but migrating to NT 5.0 will require major changes in your network. Most firms won't be able to switch all their domain controllers to NT 5.0 simultaneously, which means that many companies will live in a mixed environment including NT 3.x, 4.0, and 5.0 systems for a while. However, unless you convert every domain controller to NT 5.0, you will lose out on two compelling AD features: multimaster replication and nested groups.

Multimaster replication is an improvement that's long overdue. In NT 3.x and 4.0, user account information for a domain resides only on the Primary Domain Controller (PDC). Backup Domain Controllers (BDCs) contain copies of that information. If you want to change user account information (such as resetting a forgotten password or creating a new account), you must connect directly to the PDC--a major pain in large networks. But with NT 5.0, you can update account information at any domain controller, as long as you have a pure NT 5.0 environment.

The Global Catalog (GC) helps make multimaster replication possible. Different domains in an enterprise share a GC, which contains summarized information (e.g., user accounts and shares) about all the enterprise's domains. When you're logging on to one domain from another domain, the local domain controller can't authenticate you directly because it doesn't contain a user account for you. So, with the GC's help, the local domain controller determines what domain you belong to and the name of a domain controller in your domain.

Although an enterprise has only one GC, you can set up GC replicas anywhere in the enterprise. Thus, GC management will be an important part of NT 5.0 administration.

Another attractive feature of NT 5.0 is that you can nest groups. For example, you can create a group called Virginia_managers inside another group called Virginia_employees, which in turn might reside in a third group named American_employees, which finally resides in a group named Employees. You can't nest groups in NT 3.x or 4.0--and you can't nest groups in NT 5.0 until you've converted the last NT 3.x and 4.0 domain controllers.

Nested groups and multimaster replication will not work in a mixed environment because of the way in which NT 3.x and 4.0 systems look up security information. NT 5.0 domain controllers can pretend to be NT 3.x and 4.0 domain controllers for compatibility purposes, but once they flex their wings and act like full-fledged NT 5.0 domain controllers, the way in which they arrange user accounts would confuse an NT 3.x or 4.0 BDC.

So why doesn't Microsoft simply use a service pack to modify how an NT 3.x or 4.0 domain controller searches the domain's account information? According to a Microsoft program manager, Microsoft could certainly create a service pack to let NT 5.0 operate in a mixed NT environment without sacrificing features, but "customers won't accept" another service pack. This response is odd when you consider that Microsoft will release a service pack for NT 4.0 because NT 5.0 incorporates a new NTFS format, called NTFS 5. Apparently, disk formats are important enough to warrant a service pack, but the directory service isn't!

In addition to multimaster replication and nested groups, NT 5.0's AD has another important development: a networked Registry called the Class Store. Each Organization Unit (Microsoft's term for a subpart of a domain) has a Class Store. The Class Store is a list of all available applications and where to find them.

For example, suppose I send you an email with an attachment in Portable Document Format (PDF). Because Adobe Acrobat creates .pdf files, to read the file, you need Acrobat Reader, which you don't have on your system. When you try to open the .pdf file, your NT 3.x or 4.0 system searches the local Registry, discovers that the necessary software is missing, and realizes that it doesn't know what to do with the .pdf file. So NT gives you a dialog box that says, in effect, "I don't know what to do with a .pdf file, but I do know of these programs: Word, Notepad, and so on. Can any of them read a .pdf?"

In contrast, if NT 5.0 can't find the appropriate software in the Registry, it queries AD's Class Store about the software. The Class Store might respond, "Oh, yes, I know what program you need for .pdf. You can install this program from a file named \\APPSVRS\ADOBE\ACROBAT.CAB," or perhaps, "You can find a program that handles .pdfs at http://www.adobe.com/acrobat/acroread.zip." The Class Store extends HKEY_CLASSES_ROOT on your machine to a distributed directory of applications, whether the applications are local (via a universal naming convention or universal resource locator--URL) or distant (via a URL).