Where NT 5.0 is headed

Last month, Windows NT Magazine gave you a quick overview of what Microsoft talked about at its November Professional Developer's Conference in Long Beach, California. We've now had time to assimilate more of what Microsoft showed.

Microsoft delivered several big messages at Long Beach. First, Windows NT 5.0 isn't Cairo. Second, the Internet continues to be the basis of Microsoft's plan for the future. Third, NT 5.0 will be almost completely different from 4.0, mainly because of a change in the user interface and an X.500-like directory service, Active Directory. Fourth, the Internet is important, really important. Fifth, setting up and maintaining NT on user machines will be easier. And did I mention the Internet?

Cairo: It's Not a Release--It's a State of Mind
Once upon a time, Cairo was a beta name for a version of NT. This version was to be a major milestone in NT development. Now the name is a sort of software gestalt, a kind of catch all phrase.

Think of NT's evolution this way: If you're running a small- to medium-sized network, NT 4.0 is an excellent answer. The domain structure works well for a few dozen servers and up to several thousand users, depending on whom you talk to. NT 4.0's Windows interface means that you can get a network administrator up to speed in fairly short order. But building a multidomain network, or building a network whose directory structure includes user-defined attributes (more on this later), is impossible on NT 4.0.

So, take today's NT. Keep all the things we like--the security, the stability--and add the tools to create and maintain a globe-spanning network. The result is Cairo. Some of what Microsoft calls Cairo is already shipping in the form of NT 4.0's user interface and the Distributed Component Object Model (DCOM). In fact, you can say that we've already got the "C," and still await the "airo." NT 5.0 will be mainly "air," with the "o" still to come. (For more information on DCOM, see Keith Pleas, "DCOM in NT 5.0," )

NT 5.0 Features
NT 5.0 will, according to Microsoft's claims in Long Beach, contain concepts old and awaited, and new and revolutionary. In roughly decreasing order of importance, NT 5.0 will probably contain Active Directory; Active Server, a plan for extending the power of NT-based Web servers; a new Page and Link metaphor for much of the user interface; Distributed File System (Dfs); Plug and Play; and Microsoft Management Console. (For more on NT's new management interface, see Keith Pleas and Dean Porter, "Microsoft Management Console," page 78.) Additionally, BackOffice will grow with the addition of Microsoft Proxy Server (formerly called Internet Access Server, code-named Catapult) and Microsoft Transaction Server, previously known as Viper.

This list looks like a lot of new stuff, and it is. Most developers at the conference walked around with looks on their faces that could be described as a cross between excitement and bewilderment with a little hope thrown in.

Active Directory
NT 4.0 is better for small- to medium-sized networks than large networks, for two reasons. The trust relationship problem is the first reason. NT security and network administration are based on organizational units called domains. Domains act as authentication areas, groups of machines that all agree to accept login information from the same source: A computer called a Primary Domain Controller (PDC), which will disappear from 5.0.

Domains are a convenient way to centrally manage a network of many servers. But you can't always build your company's network as one big domain, so you must create multiple domains. The problem with multidomain networks is getting those domains to talk to each other; you must first set up a trust relationship. Trust relationships aren't transitive: If A trusts B, and B trusts C, A does not trust C, unless you create an explicit trust between A and C. As a result, you can't create hierarchies of domains. For example, if you have 15 domains in your organization and want each to trust the other, you have to create 15 * 14, or 210, separate trust relationships.

The second reason is the way that NT stores information about people. NT keeps a database of information about users. This Security Accounts Manager (SAM) database records your identity, your password, and the user groups you belong to. But you can't extend the SAM to contain information about how you like your mail delivered.

Microsoft's answer to both problems is Active Directory. Based on the CCITT X.500 and Lightweight Directory Access Protocol (LDAP), Active Directory is a massively extensible database of information on, well, just about anything. It can maintain information about servers on the network, security relationships in the network, and most important, the users in the network.

My name in an Active Directory setting might be something like CN=Mark Minasi,OU=management,O=TTI,C=US. You read this right to left: I'm in the country (C=) United States, my organization (O=) is TTI, the department or organizational unit (OU=)in TTI is management, and my common name (CN=) is Mark Minasi. Get used to seeing such names; they're central to NT 5.0 naming. The hierarchy includes the country name because, believe it or not, some folks working on X.500 and LDAP want to use these directory structures as the basis for a worldwide directory structure.

Active Directory names will benefit NT in several ways. First, they'll reduce NT's current dependence on 15-character NetBIOS server names. For example, Active Directory is a major ingredient in another NT 5.0 tool, Dfs. Dfs with Active Directory can support more flexible universal naming convention (UNC) names. Today, you must address a share named data on a server called S1 as \\s1\data--the name of the machine is part of the UNC. If you rename the machine, or move the share to another, perhaps larger machine (call it S2), you have to find everyone who uses \\s1\data and tell them to change the UNC to \\s2\data. But with Active Directory, you can identify a share by the domain in which it lives. For example, if S1 and S2 are both part of a domain named servfarm, you can use Dfs and Active Directory to call the share \\servfarm\data. Then you can place the data share on any server in the servfarm domain without changing the UNC whereby a user accesses the share. (For more information on the potential for this technology, see Sean Deuby and Tim Daniels, "Dfs--A Logical View of Physical Resources," December 1996.)

You can have organizational units (OUs) inside organizational units, so you can build the kind of hierarchy of business units that you couldn't build with domains. Under NT 5.0, domains still exist, but trust relationships can be transitive, making hierarchies of domains possible. And the directory is completely expandable. In addition to the usual name, full name, description, and similar user information, you can add data fields such as shoe size or "in case of emergency call."

Active Server and Cooler Logons
With NT 5.0, you can modify the basic NT definition of user. Doesn't that capability make the User Manager a bit messy? Well, no because the User Manager disappears altogether. Instead, you use Internet Explorer (IE) to manage user accounts, as shown in Screen 1.

Microsoft believes that the next step in graphical user interface effectiveness is to de-emphasize the old menus/dialog boxes aspect of Windows and move to a page-and-link metaphor: The user interface will look like a Web page. Look at Screen 1, and you see a few elements of that approach. First, look at the title bar. This next-generation User Manager is really IE. See the bar that runs down the left side with General Information, Contact Information, and the like? Those topics are hyperlinks in the Web page. It's a menu, certainly, but one implemented in a different way from what we're used to. Some of these screens show up with a menu down the side and across the top: a main menu and a submenu. Is it the basis of a great new user interface (UI), or is it just alloy wheels, tail fins, and fuzzy dice on the mirror? Honestly, I don't know yet.

But why the heck is IE the UI for this utility, called DS Web? Because this computer is running a beta version of Internet Information Server (IIS) 3, the latest in Microsoft's line of free NT-based Web servers. IIS 3 supports a new kind of Web page called an Active Server Page, identified by the extension ASP rather than the typical Web page extension HTM. ASP pages are basically the same as HTM pages, but with one big difference: ASP pages contain code--Visual Basic (VB) code.

For those of us who don't feel like learning Java, here's the answer to building Web pages that aren't just static HTML documents. Here's the world's simplest ASP page:

The time is <%= time() %>

Put those three lines in a text file, call it something with an ASP extension, and put it in your IIS documents directory. Then look at the file with a Web browser, and you'll see a page that says, "The time is 5:09 pm."

Sure, the hard-core Webmeisters out there won't care a fig or a farthing about this, as they've already tested their mettle on Perl and Java. But this solution is great for the rest of us who write no more than a handful of programs a year and whose previous programming experience consists of finding and removing the noisemaking lines in gorilla.bas.

Anyway, ASPs are the heart of DS Web, the tool that you saw in Screen 1. And speaking of VB, ASPs containing VB are also the new language for building NT logon scripts. Now getting onto your network can be a much more visual--the term du jour seems to be richer--experience. Just imagine the possibilities: VB can control multimedia, so when you log on, you might hear, "Good morning, Mr. Phelps. Your mission, should you decide to accept it..."

Login scripts will also get a vitally important feature--"deep" NET USEs. You'll typically put all the home directories in a directory on a server. For example, let's say server S1 has a directory on it named d:\users, and users contains directories below it. The home directory for a user named Bill might be d:\users\bill. You share d:\users as users, and so someone attaches to Bill's home directory by doing a


The problem is that Bill is now attached to d:\users, rather than d:\users\bill. NT 5.0 will allow


so Bill will never see the general root directory of the users directories--good for security and reducing confusion.

Distributed File System
NT's new Dfs is another step in disconnecting network objects from physical objects. Let's say you're working on your company's annual report. This project requires graphs, text, and a project time line to help manage the schedule. But the finance department is creating the graphs on its servers, Marketing is writing the prose, and the time line is in Microsoft Project on another server. The ability to just stitch it all together into one big directory would be awfully nice. That's Dfs's job, or at least one of Dfs's jobs.

NT 5.0 will contain concepts old and awaited, and new and revolutionary.

With Dfs, you go to an NT server (call it A) and create a share called, for example, annrpt. But the share isn't on machine A, only the share name is. You tell A that the annrpt share consists of a directory, anngrafs, the graphics, which are on another machine (call it B); another directory rpttext on one of the marketing department's machines (call it C); and a directory timeline on yet another machine, D. All a user must do is NET USE to the share annrpt to see all the data from the three directories all in one share.

Now, to make this work, you not only need snazzier software on the server, you also need it on the workstation: You need a Dfs client. The good news is that the Dfs client is built into NT 4.0 and apparently will appear in the next Windows 95 service pack.

Dfs can also accomplish fault tolerance. Suppose you have a share, web pages, where the HTML pages for your Web server reside. If the computer that webpages resides on goes down, you want the Web server to still find the document content of your Web site. Well, you can install disk mirroring, but here's something even easier: Copy all the HTML pages to another directory, on a different computer if you like. Then create a fault tolerant Dfs volume called webpages. Now, when your Web server requests a file from webpages, the Dfs volume will randomly direct it to one copy or the other. If one copy is unavailable, the Dfs volume will direct all webpages requests to the functioning copy.

With Active Directory, Dfs lets you create shares that are relatively machine-independent. Right now, you must specify a share by its share name and the name of the server that the share is on physically. For example, to access a share schedules on a server central in a domain railroad, you must use \\central\schedules. If you decide to put schedules on another server, you have to inform all the schedules users to look for that share in a new place. A lot more convenient approach is to name the share with a more generic name, such as \\railroad\schedules. In other words, you can avoid mentioning a specific server altogether by creating Dfs volumes addressed by their domain, not their machine name. Because you never mention particular machine names, you can move the shares from machine to machine within a domain without telling the shares' users to reconfigure their attachments to the shares.

Odds and Ends
NT 5.0 will support Plug and Play and power management, but with a catch: NT 5.0 will not support the current power management system, a BIOS-based approach called Advanced Power Management (APM). The bottom line is that NT 5.0 will support power management with a new approach, but only with recent machines. NT's hardware horizons will expand with support of Universal Serial Bus, P1394, and Advanced Graphics Bus. Universal Serial Bus and P1394 are high-speed, daisy-chainable interfaces that make hot Plug and Play work. In one demonstration, a Microsoft presenter attached a hard disk to an already-running system. The system recognized the new hard disk and transparently merged it into an existing drive. A 1GB volume became a 4GB volume without the presenter rebooting!

Yet another database programming interface, Object Linking and Embedding (OLE) DB, lets companies centralize their data stores into single large databases and then present a simple flat-file view of that data to programs. The idea is to have most of your firm's data not in SQL databases but in ASCII files and Excel spreadsheets, for example. The interface makes all those disparate data objects look like one big consistent database for administration purposes. This concept is an old idea and a good one, but I wonder if it's practical. You often implement OLE DB atop Open Database Connectivity (ODBC), a tool that makes different kinds of databases look uniform. At my company, we've written a client/server application with VB on the front end and SQL Server on the back end. We connected the two with ODBC drivers. Good heavens, it was slow--so slow, in fact, that we're rebuilding it with direct passthrough SQL commands to the server, which is turning out to be pleasingly faster. I wonder how horrible performance would be on our system if it ran OLE DB in addition to ODBC?

NT 5.0 brings 64-bit programming to NT, albeit in a limited way. A new set of memory allocation and management APIs will support 64-bit memory manipulation, but the memory references and structures have to be in physical memory. So you'll be able to store records from big databases (opticals are the ones that are most frequently cited as causing troubles), but programmers will have to know a little more about the target machine than they do nowadays: For most NT programming, if your program runs out of RAM, NT automatically uses disk space to stand in for RAM. But 64-bit programming won't allow that solution. (For more on this memory technology, see Keith Pleas, "64-bit Architecture.")

TCP/IP in NT 5.0 will support the Quality of Service interface, QoS. With this support, you can pay your ISP to make your IP packets higher-priority packets. Those packets will zip through the increasingly congested Internet more easily.

NT will also move away from a domain structure with one PDC and one or more Backup Domain Controllers (BDCs) to a model with simply Domain Controllers (DCs). Currently, the PDC and the BDCs contain copies of the SAM user database, but you can modify that database only on the PDC--the system replicates changes out to the BDCs, but the BDC copies are read-only.

Let's say that you work in Timbuktu, at a branch office. The BDC on site handles your logins. It's connected to a PDC over a WAN link to the central office. Now, if the WAN link goes down, you can't modify your account--change your password, groups, description, or the like. Under NT 5.0, that situation won't be a problem. You can modify your account, and the local DC will note the change. Then, when the central office's DC is once again connected to your local DC, the central office's DC will say to your local DC, "Hey, what did I miss while I was gone?" This configuration will be convenient for folks building NT networks that span multiple locations--but boy, I'm glad I don't have to write the code to make that work!

Virtually all NT security will change. As users and administrators, we won't see the changes because they're under the hood; an Internet method called Kerberos will supplant the current method of authentication.

What Does This Stuff Mean for NT 4.0 Users?
You're probably thinking, "Hey, I just got 4.0. What are they doing dropping another version on me?" Here's some advice.

First, remember this is all just the initial overture--not only hasn't the fat lady sung, she's probably not even back from dinner yet. Active Directory, the new domain controller model, and Kerberos security will probably constitute the largest change to NT's innards since 3.1. Given that Microsoft intends to ship the first beta by the first half of 1997, we probably won't see NT 5.0 until early to middle 1998.

That prediction is not a criticism, by the way. If anything, let's all beg Microsoft to take its time on this next version of NT! Microsoft has shipped a version of NT about every 12 months, so my guess is that we'll see some interim version in late 1997, perhaps NT 4.5 or the like. That guess is not insider information, and no Microsoft person has so much as breathed the words NT 4.5. This is just my analysis based on current release patterns.

Should you skip NT 4.0 and wait for 5.0? On the workstation side, definitely not. NT 4.0 workstation is an attractive product, and as workstation tools go, it's easy to recommend.

Server 4.0 is another story, however. Several months' work with it has raised, in my mind at least, some very disturbing questions about its stability. Under 4.0, machines that have run NT 3.1, 3.5, and 3.51 suffer random UI freeze-ups, where people connected to the file server can still access files, but NT 4.0 ignores mouse motions and keystrokes at the server--even on machines with NT 4.0's Service Pack 1 installed.

That glitch, coupled with the requirement to buy new client access licenses for your entire network when you install just one NT 4.0 Server, makes me hesitate to recommend upgrades to 4.0 Server. We did it. But if we had it to do again, I doubt that we would.

Assuming that you're using 3.51 or 4.0, what can you do to get ready for 5.0? Not much, really. The main work of a 5.0 upgrade will be reconfiguring your domain structure to use Active Directory. Microsoft is working hard to build tools to make that conversion easy, so don't lose any sleep over it. Other than that recommendation, I recommend getting comfortable with IIS because it will be an important network management tool under NT 5.0.

NT's progress, with the exception of some of 4.0 Server's warts, has been a steady, upward evolution. NT 5.0 will provide a bit more evolution than we're used to from NT--think of it as a mini-revolution. In the end, we'll probably enjoy the results.