Mastering Windows Server 2003: Chapter 2 ‘ The Basics: Networking Software, Servers, and Security

Mastering Windows Server 2003: Chapter 2 ‘ The Basics: Networking Software, Servers, and Security

Chapter 2 ‘ The Basics: Networking Software, Servers, and Security

Chapter 2 ‘ The Basics: Networking Software, Servers, and Security

In a lot of ways, Windows Server 2003, Standard Edition (which I’ll call “Server 2003” or “2003” in this chapter) should be named “NT 2.1.” Anyone coming into the Microsoft networking story without any previous experience with some version of NT, Windows 2000, or Server 2003 probably feels just as lost as someone who gets dragged into a movie theater to see The Empire Strikes Back while knowing nothing of the original Star Wars. They end up asking things like, “Who is the tall guy with the black shiny mask and the bad attitude; and speaking of attitude, what is with that woman whose hairdo looks like she strapped a couple of Danishes on her head?” In this chapter, I’ll give you a bit of history on Server 2003 and then take a very high-altitude look at why we’re using Microsoft’s networking software in the first place. This is not intended to prepare you for a test on networking essentials, nor is it a complete book on NTs past and present. (When I say “NT,” remember that Windows Server 2003, Standard Edition is really just NT Server 5.2.) What I’m trying to accomplish in this chapter is to answer the questions:

◆ Why should I care about all of this networking stuff, anyway?

◆Why does Microsoft’s networking software approach networking the way that it does? Here, I’m referring to the fact that much of why Server 2003 works the way that it does is simply because NT always did it that way—so knowing more about NT’s history makes 2003 make more sense.

What’s the Point of Networks and Networking?

In a way, this chapter is penance for my youthful misdeeds. When I was in the seventh grade, I had a math teacher named Mr. Schtazle. Seventh-grade math was a kind of potpourri of mathematical topics—I recall one chapter that took pains to drill into our heads the difference between precision and accuracy—and I’d plague the poor man at the beginning of every chapter by asking him, “How will we use this?”—a slightly more-polite version of “why do we care?” Well, nowadays I find that when I’m teaching a room full of people about Windows 2000, I’ve got to be careful to answer that question, “Why do you care?” even if it isn’t asked. Because if I don’t answer that, then many people in the room will leave the class with a pretty good notion of how to accomplish a bunch of tasks but not a really good feel for why they’d do the tasks in the first place. And you know what? Answering the “Why do I care?” question can be pretty rough some times. So, Mr. Schtazle, if you’re out there…my apologies.Let’s consider the two questions that I asked a paragraph or two back:

◆ Why network in the first place, and

◆ If we agree that networking is a good thing, why do we do it this way?

The answer to the first question will turn out to be pretty straightforward: Networking solves a set of problems for us. The answer to the question, “Why do we do it this way?” is a bit longer.First and foremost, you’re doing this to try to solve some problem that networking can help you with. Your company might want, for example, a great Web site, or to be able to send and receive e-mail, or a simple file and print server for a small office. These are the goals; a network is the means or tool to reach them. In short: The ultimate goal of any networking project is to provide some kind of service . Everything else is just a necessary evil—but there are a lot of those necessary evils! Second, there are many kinds of services that networks can provide, and every kind of service needs different software to make it work. For example, suppose you wanted to set up a Web site on the Internet. Network services, including Web sites, need two main pieces: a server piece and a client piece.

To put up that great Web site, you’ll create the site itself with HTML and drop that HTML onto a Web server. One way to get a Web server is by taking one of your computers and putting a piece of software on that computer to make it function as a Web server. But that’s only half the story—in order for your customers to enjoy that Web server’s content, they will need a piece of client software called a Web browser. That’s our first networking piece: Every network service needs server software and client software. Third, you need to ensure that there’s a way for your information to get from your server to your clients, a physical system that the service can travel over. If the clients and servers are in the same building, then you only need a local area network (LAN), and setting that up only requires pulling wires through the building. If, however, you want to offer your service to the world, as in the case of a Web server, then you’ll need some kind of WAN (wide area network) connection to the Internet.

In other cases, you’ll need a WAN connection, but not to the Internet: many organizations with more than one location connect those locations via private communications links with names like leased line, T1, or frame relay. That’s our next networking piece: Networks need connection hardware (switches, hubs, routers, modems) and links (phone lines, network cables, frame relay, DSL, cable modem, ISDN, etc.) or the clients can’t connect to the servers.

Fourth, to provide a service over a network, your server and your clients must agree on how to transmit information over that network. That agreement is called a network protocol, and the one that you’ll most probably use in the Windows 2003 world is called the Transmission Control Protocol/Internet Protocol (TCP/IP). You may have heard of it before, as it’s the network protocol that the Internet uses, but you needn’t be on the Internet to use it. In short: Clients and servers must speak the same network protocols

Fifth, once you’ve got the channels open, and before information starts flowing in both directions, you’ll almost certainly need to worry about security. When you use the tool that is networking, youwant to be sure it doesn’t increase your risk, and in fact you can shape the tool so it reduces hazards. Briefly: Networks need security.

Sixth and finally, once you’ve set up that terrific network service, you need a way for people to find that great service. You do that with a “naming” system. Windows 2003 has two of them—one that appeared years ago before the first version of NT, and a newer (to NT, anyway) method that the Internet’s been using for years. The last network piece, then is that: Networks must provide a way for users to find their services.

Let’s examine these pieces in order, take a closer look at why they work the way that they do, and get some insight into how Windows 2003 in particular handles them.

Network Client and Server Software

The reason that we network computers in the first place is so that computers acting as clients can benefit from the services of computers acting as servers. For example, suppose you want to visit my Web site, www.minasi.com Two of the ingredients that you’ll need to make that possible are software:

◆ You’ll need a computer running a program that knows how to request Web information and then how to receive it—in other words, a client application.

◆ I’ll need a computer running a program that knows how to listen for requests for Web information and then how to deliver that information—in other words, a server application.

As sometimes occurs too often in the computer business, you’ve got choices about both the client and the server.

The Client Piece: A Web Browser

I’ve said that first you’ll need a computer, of course, one that’s running a Web browser program like Netscape Navigator or Internet Explorer. But let me rephrase that in basic network client-server terms.

There is technically no such thing as “the World Wide Web.” Instead, there is an agreement about how to transfer text, pictures, and the like, and that agreement is called the HyperText Transfer Protocol—which is normally shortened to HTTP. The phrase World Wide Web just refers collectively to all of the HTTP servers on the Internet. When you think you’re surfing a Web page, what really happens is this:

1. Your client computer asks the Web server (oops, I meant the HTTP server ) something like, “Do you have any documents?”

2. The Web server responds by saying, “Here’s my default document,” a simple text file that is the so-called home page for that Web server. The Web server sends that file to your client using the HTTP protocol.

3. Once your client receives the text file, it notices that the page is full of references to other files. For example, if the home page that you requested has pictures on it, your Web browser (HTTP client) didn’t originally know to ask for them, so the Web server (HTTP server) didn’t send them. Your client notices the lack of the images and requests that the server send them, which it does—again using the HTTP protocol.

Here, “HTTP client” just means a program that knows how to speak a language that transfers a particular kind of data—Web data. Your computer is deaf to the Web unless it knows how to request and receive data via HTTP.Notice what client means here. It doesn’t refer to you, or even to your computer. Instead, it just means a program that your computer runs.

The Server Piece: A Web Server

Next, let’s consider what’s sitting on my side of the conversation. I’ll need a computer running a special piece of software that is designed to listen for your computer (or anyone else’s, for that matter) requesting to see my Web pages via the HTTP protocol, and that can respond to those requests by transferring those pages to the requesting client software. You might call such a piece of software an “HTTP server” program, although almost no one calls it by that name. You’d more commonly call it “Web server” software. There is a variety of Web server software that I might run on my Windows Server 2003 computer, but I’m most likely to run the one that comes free with Server 2003, a program called Internet Information Services (IIS) 6. Alternatively, I might find, download (probably using HTTP!), and install a popular piece of free Web server software called Apache.

Once again, notice carefully what “server” means here. It does not really refer to the particular computer hardware that I’ve got stashed in my network room connected to the Internet. Instead, “server” means “the program running on Mark’s computer that listens for HTTP requests and knows how to fulfill them.”

Now that I’ve gone through all of that, consider again the question that I asked at the beginning of the chapter—why are you bothering with a network? The answer is probably “because you want to offer a Web site, either internally or on the public Internet, and you that think that IIS is the best (highest-performance, cheapest, or some combination of the two) Web server software around”—which means that you must use Server 2003, as it’s the only operating system that supports IIS 6.(Or you could use an earlier version of Server and an earlier version of IIS, but why not go with the latest and greatest?)

Other Types of Servers

I’ll tend to use the Web client-server example for this discussion. But I don’t want to lose sight of the fact that there are quite a few client-server systems, besides Web servers, that are in common use and that you may want to use 2003 to create. Returning to the theme of this chapter, then—“Why do I care or why do I need this stuff?”—networks offer several valuable services, and you may want to set up a computer to act as a server and offer some of those services. Here are a few besides the Web server example.

File Servers

File servers act as central places to store data files. Why put them on a server rather than just keep them on your local computer? Well, in some cases someone else created the file, and placing a file on a central server is a simple way to make the files available to others. The other good thing about storing files in a central location is that they’re more easily backed up that way. 2003 comes with file server software built in.

Print Servers

Print servers let you share printers. Not everyone wants to put a printer on their desk, and besides, if you share the printers, you can afford more expensive (and presumably better) models. 2003 comes with print server software built in.

E-Mail Servers

Mail servers are essential if you’re going to do e-mail. Some computer (or computers) must act as the post office, collecting e-mail from the local users and sending it to other mail servers across the Internet and acting as a receiving point for other mail servers to send mail destined for your organization. You can outsource this function by letting your ISP act as your mail server, but running your own mail server gives you more flexibility. (However, it does require a persistent connection to the Internet.) 2003’s new features include a basic e-mail server. Yes, it’s “basic” because Microsoft really wants to sell you Exchange as your mail server.

But it’s not a bad server for many people’s needs.

Group Scheduling Servers

The centralized nature of servers means that they’re a great place to keep track of scarce resources like meeting rooms or your time. 2003 does not come with a scheduling server, as Microsoft wants to sell you Exchange to do that sort of thing. But there are alternatives to Exchange; there are some terrific Web-based scheduling tools that work great on 2003—for one example, take a look at www.mattkruse.com/scripts/calendar/ or other tools, like Lotus Notes.

E-Commerce Online Stores

If you’ve got something great to sell, then the Web’s one place to do it. There are thousands of online stores on the Web, and a good number of them run on 2003. While 2003 includes a Web server, it doesn’t include the other software that you’d need to create a complete online store. But there are a lot of consulting and programming firms that would be happy to help you create an online store atop 2003!

Networks Need Connection Hardware and Links

If I want to offer a server service and ensure that you can enjoy that service, then we’ll both need to be physically attached to the same network—the same series of cables, satellite links, or whatever—or your computer’s requests will never get to my computer in the first place. That probably means that we’re both on that huge network-of-networks called the Internet, but we could just be working for the same company in a single wired building, or a multilocation firm connected by a private intranet.

Now, notice that if I’m going to run a Web server, I’ll need to be connected to our common network (Internet or otherwise) persistently: I couldn’t decide to run a Web server out of my house and just dial in to the Internet now and then. Of course, if I’m only serving some private network that we share, then an Internet connection is unnecessary, as we already have connection to a common network.

People who worry about the physical connection part of networking concern themselves with getting cables run through walls, calling the phone company to arrange for persistently connected data links of various kinds—links with names like DSL, cable modem, frame relay, leased lines, T1 or T3 lines—and then work with a family of hardware that helps get the bits going off in the right direction—devices with names like switches, hubs, and routers.Does 2003 help you with this part of the job? In some parts, it can. Switches and hubs are very basic, simple devices, and 2003 has nothing to do with them—although clearly 2003 depends on their presence in order to network! Routers are, however, more complex devices. You probably know that the market leader in the router world is a firm named Cisco Systems, but you may not know that a router is really just a small, single-purpose computer. If you wanted to, you could use a computer running Server 2003 to replace a Cisco router. Additionally, if you wanted to allow people outside your network to dial in to your network, you could use a Windows Server 2003 to make that possible. (It’s not the best answer, as you’ll see in Chapter 6, but it is possible.)

Clients and Servers Must Speak the Same Protocols

But simply being connected to the same wire isn’t enough—we need a common communications lan-guage. If I were to pick up a phone and dial some number in Beijing, I’d have a physical connection with whatever poor soul picked the phone on the other end—but that would be the extent of our interaction. In the same way, computer networks need to agree on things like, “What’s the biggest block of data that I can ever send you?” and, “How shall I acknowledge that I actually got that block of data?” or, “Should I bother acknowledging receipt of data at all?” and hundreds of other questions.

The answers to all of those questions are contained in the “network language” or, in network techie terms, the network transport protocol . It probably won’t surprise you that more than one network transport protocol exists, and over the years NT has generally supported three of them:

◆ NetBEUI (Network Basic Input/Output System Extended User Interface), an old Microsoft/IBM/Sytek protocol designed to support small networks

◆ IPX/SPX (Internet Packet Exchange/Sequenced Packet Exchange), the protocol that Novell NetWare predominantly used for years

◆ TCP/IP (Transmission Control Protocol/Internet Protocol), the protocol of the Internet and intranets

Although you have three choices, it’s a good bet that your Microsoft software-based network uses TCP/IP. Why TCP/IP? Well, there have been some really great protocols over the years, but as the Internet uses TCP/IP and as the Internet is so popular, TCP/IP has sort of trumped the other protocols. In fact, it’s impossible to do a fair number of things that 2003 and its predecessors Windows 2000 and, to a lesser extent, Windows NT 4 are capable of without TCP/IP. So I’m going to assume for our discussion and indeed for most of this book that your network will use TCP/IP.

Oh, and one more thing—once you’ve decided that TCP/IP is your network protocol of choice, then you’ll need to install several more servers to support TCP/IP’s infrastructure. And here again, when I say “more servers,” I’m not suggesting that you have to buy more PCs, although you might. What I mean is that you’ll have to install software on some computer or group of computers to perform three basic pieces of plumbing or infrastructure jobs:

◆ A Domain Naming System (DNS) server keeps track of the names of the computers in your network (an important task, believe it or not).

◆ A Dynamic Host Configuration Protocol (DHCP) server configures the specifics of TCP/IP on each computer in your network, both great and small.

◆ A Windows Internet Name Server (WINS) does something like what DNS does—keeps track of names—but isn’t really necessary on a “pure” Windows 2003 network—its main job is to support older Microsoft operating systems like Windows 9x, Me, and NT 3.x and 4. You’ll learn more about the specifics of DNS, DHCP, and WINS in Chapter 7. I should point out that if you’re a one-person shop, then you might not need all of that, as your ISP might be handling it for you—but I’m assuming throughout this book that you are probably a network administrator/manager for a network of at least a few computers, and possibly for a tremendous number of computers.

Keeping the Bad Guys Away: Security

Once you’ve gotten the first four things done, then your job’s finished, in a sense—people can now read and write files on that file server, view pages on that Web server, print to that shared printer, set up meetings with you over your scheduling server, and so on. I mean, hey, networking’s all about sharing, so just open the doors and let ’em in!

As you’ve probably realized, there’s a missing piece here: security. While there’s a lot to security, it basically boils down to two things: authentication and permissions.

◆ First, you want to be able to identify who’s entering your network. That’s authentication.

◆ Second, once you know for sure who you’re talking to—once you’ve authenticated—then you

must be able to look up somewhere what that person is allowed to do, his permissions. For example, a network logon could figuratively go something like, “Okay, now I know you’re Jack…but I’ve been told to deny Jack access to everything.” Merely being authenticated doesn’t mean that you get access!

Authentication

The first part of security is called authentication, and you usually accomplish it through usernames and passwords, although as time goes on you’ll eventually use the more science-fiction means of authentication: One day, the computer may recognize you by your fingerprint, face, voice, retina blood vessel pattern, or some other item that’s distinctly you. The geek term for those authentication approaches is biometric. For now, however, it’s user accounts and passwords that identify users. I realize that nearly every-one who’s reading this book has undergone an authentication at some point—you’ve logged in to a network some time. It all sounds simple, doesn’t it? And yet user accounts and passwords present special problems.

Storing Authentication Information

First, you’ll need some kind of program that lets administrators create user accounts and store them in a file. In their simplest form, user accounts consist of a database of usernames and passwords. That’s no big deal—it’s a very simply structured database, and there are tons of database programs out there—but don’t forget that you need to encrypt that information. Otherwise, there’s the possi-bility that someone could come along and steal the database file, take it home, and perhaps crack it for your user’s passwords.

Just such a thing happened to NT 4. NT stored user information in a file named SAM. If you leave me in the same room as your server, then I can copy that SAM onto a floppy and take it off-site to analyze it. Wasn’t it encrypted? Well, yes, but sometimes encryption isn’t enough—a group of hackers figured out how to crack SAM’s encryption. With just a bit of work, anyone could extract passwords from an NT SAM. (Which is a good reason to keep your servers behind lock and key, so that it’s harder for someone to steal your account files.) Windows 2000- and 2003-based domains (a term I’ll define soon) use a more sophisticated encryption scheme on its user account/password file (which is named NTDS.DIT , not SAM), but unfortunately even that file can be cracked with some determination. Again, let me stress that this is only a danger if you let someone physically sit down at the servers that do logons, a set of servers called domain controllers, so don’t worry that 2003 isn’t secure. Any security person can tell you that you should never give the bad guys physical access to your important servers—lock ’em up!

The tool that lets administrators create, modify, or delete user accounts is called Active Directory Users and Computers. Active Directory refers to Windows 2000 and 2003’s system for storing user-names and passwords. It’s called a directory because directory is the current network lingo for “database of user accounts.” Personally, I think it’s kind of confusing—in my mind, directory conjures up visions of drive letters, like C:\DOS—but it’s the current argot, so it’s worth knowing. And, in case you’re wondering, the “Active” part is just Microsoft marketing; don’t look for any deep meaning there. (It’s not like Novell makes a product called Comatose Directory or Lethargic Directory.)

Authenticating without Compromising Security

So you’ve got a server somewhere that contains the list of usernames and passwords. Those are only good if someone can use her username and password to be authenticated and get access to things on the network. So you need some way for a user sitting at her workstation computer to be recognizedby that server. You’re already familiar with this recognition process: we call it logging on. Suppose I’m sitting at my Windows XP workstation and I want to get to some files on a file server named files-r-us.bigfirm.biz. Before files-r-us will give me access, I’ve got to submit myself for authentication—I’ve got to log on. One of the many programs that comes with every version of NT since version 3.1 is called winlogon.exe, and it’s the program that pops up when you first turn your workstation on, asking you to punch in your username, password, and domain. (Again, I’ll explain what a domain is in a minute.)

So imagine that I’m trying to access some data on files-r-us. Files-r-us responds by asking my workstation, “What’s his name and password?” Now I’ve got a problem. You see, what I’d like to do is to just say over the network line, “This is Mark and his password is ‘swordfish.’” Then files-r-us can just look in its directory file of usernames and passwords and see if it has a user named Mark with a password of “swordfish.” If so, then it lets me in. If not, it doesn’t. Simple, eh?

Well, there’s one flaw here—the part where my workstation passes “swordfish” over the network. A class of programs called “sniffers” can record and display any data that passes over a network wire.So passing passwords around on an unencrypted Ethernet cable isn’t a great idea. That means you’ve got another challenge: how to prove to a server across the network from you that you’ve got Mark’s password without actually showing that password to the server.Over time, networks have come up with different answers, but Active Directories, whether based on Windows 2000 or 2003, use an old authentication method called Kerberos which some folks at MIT first invented in the mid ’80s. It replaces an older method employed by NT 3.x and 4 called NTLM, which was short for NT LAN Manager, a reference to one of NT’s predecessors. What follows is an extremely simplified version of how Kerberos works. (It’s actually a wildly simplified description, but it’ll help you understand the more complete explanation that you’ll see in the next section.)

Let’s return to files-r-us. I try to access its data, so files-r-us needs to first log me in. It does that by saying, “I’ll tell you how to access my data,” and sends me some instructions on how to get to its data. But the data is encrypted—with my password! In other words, anyone could claim to be me, and files-r-us would happily send these vital instructions-for-connection. But only I can decrypt those instructions, so only I can benefit from them. So files-r-us ensured that only someone with my password could gain access, without sending my password over the wire.

Centralizing and Sharing User Account Information: Domains

But my simple example about trying to access one file server is, well, a bit too simple. Most com-panies will end up with more than one server, and in fact it’s not unusual to end up with dozens or hundreds of servers. And that leads to the following problem. Recall that I said a page or soback that if you’re going to employ user accounts, then you’ll need a file to store them in. But what if you have more than one server? What if in addition to the server named files-r-us.bigfirm.biz, I’ve also got a mail server named postoffice.bigfirm.biz and a Web server named www.bigfirm.biz? I might want to log in to any one of those three, so they all have to be able to accomplish logons. But now let’s examine what that actually means in terms of keeping track of user accounts. Should each server contain a complete copy of NTDS.DIT, the file containing the names and passwords for users?

That might work, but it’d be a pain, for several reasons. First, NTDS.DIT can get pretty big, and I’d end up burning up a lot of disk space copying it to every server in my enterprise. Second, if servers are connected by low-speed WAN links, the process of copying the changes to NTDS.DIT to all of the servers on my network (a process called directory replication) would take up a lot of time and network band-width. Third, do I really want to have to create a network “storm” of file copying amongst the servers every time someone just changes his password? And finally, what about the issue of securing the NTDS.DIT file in the first place? If I copy NTDS.DIT to every single server in the enterprise, there are bound to be a few that are out in the open, not physically secured. It’d be easy for an intruder to copy the NTDS.DIT from a poorly secured computer and spirit it off-site, to crack it at leisure. The better idea that we’ve used in networks for years is to put the user directory, the NTDS.DIT, not on every single server, but instead on a relatively small subset of the servers. Those NTDS.DIT-holding servers then serve in the role of logon server, doing the job of authenticating for the other servers. In Microsoft parlance, a logon server is more commonly called a domain controller. So, to return to the example of accessing data on files-r-us, imagine that files-r-us is not a domain controller and doesn’t contain a copy of NTDS.DIT, and that another computer, vault.bigfirm.biz, is a domain controller and contains a copy of NTDS.DIT. In this newer arrangement, I don’t directly log into files-r-us but instead enlist the aid of vault.bigfirm.biz in order to authenticate with files-r-us.In a purely Active Directory network (which can only include Windows 2000, XP, and 2003 sys-tems), vault.bigfirm.biz would help me log in to files-r-us with Kerberos. In order to understand how Kerberos works, you first need to understand that under Kerberos, not only do the users have pass-words, the server programs do also. Thus, the file server program running on files-r-us has its own password. So both the user and the server each have passwords—remember that.When I tell my workstation to try to get some data from files-r-us, my workstation sees that it’ll need to get me logged in to files-r-us. It does that by asking the domain controller, vault, to give me something called a “ticket” to the file server service on files-r-us. The domain controller responds by handing my workstation an encrypted piece of data, which is the Kerberos ticket.

The ticket can be decrypted with my password, making its contents a mystery to anyone but me (or my workstation, which obviously knows my password). My workstation decrypts the ticket, which contains two things. First, it contains a message saying “your special one-time-only password for accessing the file server at files-r-us is ‘opensesame.’” Second, it contains another encrypted message—but this one’s not encrypted with my password, so I can’t decrypt it! But my workstation knows to send it to the file server, which decrypts it successfully, as the file server has its own passwords. Once the file server receives and decrypts the part of the Kerberos ticket that I sent it, the file serversees that that ticket piece says something like, “The special one-time-only password for communi-cating with Mark is ‘opensesame.’ And by the way, you should have gotten this message from Mark sometime between 10:45 A.M. and 10:50 A.M. from his IP address, which should be 117.39.82.3.” Once the file server gets its half of the Kerberos ticket, it knows a few things:

◆ The user claiming to be Mark who wants access to the file server is indeed Mark.

◆ Any messages from that now-authenticated person named Mark should have originated from IP address 117.39.82.3.

◆ If Mark and the file server really want to maintain a secure connection, they could even encrypt their communications using this shared—but secret—password, opensesame.Security Roles and Definitions: Domains, Domain Controllers, and Member Servers Armed with this information, I can define a few Microsoft networking terms.

Domain You just saw an example where one machine (vault) let me log in to another machine (files-r-us). I haven’t mentioned this yet, but before I could get anywhere I needed to log in to the computer at my desk, my workstation—and when I first tried to log in to my workstation, it was once again vault.bigfirm.biz that authenticated me. Clearly, then, my workstation and files-r-us“trust” vault.bigfirm.biz in some fashion.

The collection of machines that share the same list of user accounts, the same NTDS.DIT, is a domain. Or, to put it a bit more specifically: several computers hold a copy of NTDS.DIT and are willing to act as “logon servers” (domain controllers) with that NTDS.DIT. The collection of machines that are willing to accept logons from those domain controllers (in Microsoft terms, who “trust” those domain controllers) and the domain controllers themselves are collectively called a domain. So my workstation, vault, and files-r-us are all part of the same domain.Domain Controller A server, such as vault.bigfirm.biz, that contains a copy of the user account/password data, and that therefore can let users log in to servers, is a domain controller. Domain controllers exist to centralize the user account/password information so that you needn’t put the NTDS.DIT on every server.

Member Server A machine that is running NT 3.x, 4.0, 2000, or Server 2003 but not acting as a domain controller will not contain a copy of NTDS.DIT and therefore can’t authenticate domain members. Such a machine is called a member server.Permissions and Access Control Lists (ACLs)Once a server has determined that I am indeed me, does that mean that I’ll get access to the server’s information? Not necessarily. Authentication just identifies me. The next step in security is access control, also known as (depending on what network operating system you are using) rights, permissions, or privileges.

Ever since its earliest versions, NT (which includes Windows Server 2003) has had a very flexible system of file and directory permissions. As you’ll see later in this book, you can exert very fine-grained control, such as specifying that Mary can read or write to a given file, that Bill can only read it, and that June cannot access the file at all. Don’t get the idea, however, that permissions

refer only to files. There are permissions to do things like create, modify, and destroy user accounts, and even permissions to create domains in the first place. The flexibility of these permissions is one of Microsoft networking’s great strengths.Just about everything in the Microsoft networking world has security on it. Want to read a file? You need the permissions to read it. Want to shut down the program that provides the Web server? You need the permissions to shut it down. Want to create a new user account on your network?

You need the permissions to create a new user.

These permissions are stored as a list. In the case of the file, the operating system sets aside a little space for every file that it creates, and keeps the permissions in that space. A set of permissions fora file, then, might look like

◆ A user named June can do anything that she wants to the file.

◆ Another user, Joe, can only read it.

◆ Any user in a group named Cube-dwellers can read or modify the file, but not delete it.

◆ The operating system can do anything that it wants to the file.

In Microsoft networking-speak, that list is called an access control list or, inevitably, ACL. Each of the four entries are called access control entries or ACEs. You will learn in this book that lots of things have ACLs, and adjusting those ACLs is how you configure security in your network.

Access to Earlier Security Systems

The last challenge that Windows 2000 and 2003’s security designers faced was the so-called “legacy” support—ensuring that they could interact with the security systems built into Windows for Workgroups, Windows 9x, NT 3.x, and 4. I’ve described in very broad strokes how Kerberos works, but Windows and NT didn’t use anything like that and in fact couldn’t do Kerberos logons; Kerberos first appeared in the Microsoft networking world in February 2000, with the introduction of Windows 2000. Microsoft knew that you wouldn’t be very happy if they required you to throw away all of your old Windows 9x and NT systems before you could implement Active Directory, so Windows 2000, XP, and Server 2003 know a variety of logon methods—NTLM 1.2 for Windows 9x and NTLM 2.0 for NT 3.x and 4—in addition to Kerberos.

It’s hard to overstate the importance of security. For example, in the past, one of Novell’s main advantages over NT was in the way that it stored user accounts and handled logins—Novell’s security was faster and more flexible. Sure, one could argue that Novell moved data around file servers more quickly, but not so much more quickly that anyone would really modify a buying decision. Basically, people were buying Novell for Novell’s security system, something called NetWare Directory Services (NDS). NDS was essentially a big-time user database, something with a more enterprise feel to it than NT’s older SAM-based system. In short, security is important.

Names: Finding Servers and Resources

When PC-based networking first appeared, we didn’t do much Web work—the earliest common LAN functions were file and print services. So from the very beginning (all of 15 years ago) of PC-based networking, we’ve done file and print services; they’re the most basic network services. But now suppose that you’ve got a network with more than one server on it, and you want to find out which server has a printer available for sharing, or you can’t remember which server holds that share called hrdocuments; how do you search for network functions?

That’s one of the oldest problems in networking, and not just in Microsoft networking. Microsoft’s most current answer to the “how can I find resource X on the network?” question is to store that information in the Active Directory database. But they’re not there by any means yet and, even if you have an all-Windows 2003 and XP network (which is unlikely), you’ll find that by default the Active Directory isn’t all that much help in finding file and printer shares. I’m sure that’s going to change as new versions of NT appear, but for now, we Microsoft operating systems users are pretty much stuck with an old technology known colloquially as the Network Neighbor-hood or, in Windows 2000 and later, My Network Places. Here’s where it came from and how it works.

How would you set up a system that provided a centralized directory of services on a network, a kind of “yellow pages” that lets a user quickly find a file share or shared printer? Microsoft net-working uses a name server system called the computer browser or browse services—it has nothing at all to do with the Web, it’s had that name since before the Web existed—where you, the network administrator, don’t have to do anything; the name servers set themselves up automatically. Sounds good? Well, it is for small networks, but it gets troublesome for larger ones—which is why Microsoft is trying to phase it out.

The servers in a Microsoft network that contain information about network services are called browse masters or master browsers. What’s different about the concept of Microsoft browse servers is that no one computer is fixed as the browse master. Instead, when your computer logs in to your network, it finds a browse master by broadcasting a request for one, saying, “Are there any browse masters out there?” The first browse master to hear the workstation (there can be multiple browse masters, as you’ll see) responds to the workstation by saying, “Just direct all your name service requeststo me.”

When a server starts up, it does the same thing. It broadcasts, “Are there any browse masters out there?” and when it finds one, it says to it, “I am a server with the following shares. Please add me to your list of servers.” The list of servers that a browse master maintains is called the browse list, not surprisingly.

Tip This is the really irritating thing about the browse list: it’s broadcast-based. That means that if your network isn’t 100 percent broadcast-friendly, then you’ll sometimes end up with an incomplete list of servers on your network. So ifyou have a network built in more than one segment (and who doesn’t?), or you use some kinds of Ethernet switches rather than hubs, then you may experience missing servers in the browse list. That’s part of why Microsoft is trying to phase out the browse list. But for now, understand that the browse list is a largely lame and unreliable technology. You’ll see lateron, in Chapter 7, that you can install a service called the Windows Internet Name Service (WINS) to reduce the chance that the browser breaks, but trust me—you’ll eventually come to a point where you’ve done everything that you can do, but the browser still doesn’t work. When that happens, don’t feel bad—we’ve all been there. I’ll suggest some ways to make it work better and reduce your dependence on the browser a bit later in this section.By now, you may be wondering, “How come I’ve never seen one of these browse lists?” You have. If you ever worked with earlier versions of NT or with Windows for Workgroups, then you saw Figure 2.1 when you opened the File Manager and clicked Disk/Connect Network Drive.

FIGURE 2.1

Sample browse list

from Windows for

Workgroups or

Windows NT

version 3.x

From Windows 9x or Windows NT 4, you can see a browse list by opening the Network Neighbor-

hood folder, as in Figure 2.2.

FIGURE 2.2

Sample browse list

from Windows NT 4

or Windows 9x

From DOS or indeed any command line, you can see a browse list by typing net view or net view

\ \ machinename. You see a screen like the one in Figure 2.3

FIGURE 2.3

Sample browse list

from a command line

Note What’s with that \\ thing? Microsoft’s network software has, since 1985, used a way of writing the names of servers and of shares on servers called a Universal Naming Convention or UNC. It looks like \\servername\ sharename. So, for example, if I had a server named bigserver that contained a file share called mydata, I’d refer to that share as \\bigserver\mydata—that would be the UNC for that share. ou’ll learn more about this in Chapter 11, on file shares, but I wanted to explain the mystifying \\ briefly here. And by the way, you pronounce “\\” as “whack-whack” in the Microsoft world. Now, to my way of thinking, that’d mean that a regular forward slash— / —wouldbe pronounced “backwhack” in Microsoftese, but I’ve never gotten confirmation on that.

Each figure shows you the list of servers available: Aldebaran, Artemis, and Astro, just to list a few. Other servers—Daffy and MWM66—appear only in some of the browse lists because a few minutes passed between taking the screen shots, and a few “test” servers went up or down in thosefew minutes. In all three cases, the workstations that these screens were taken from got their browse lists from a local browse master.

You can drill down further into these browse lists, as well. In Windows 9x/Me, Windows NT 4, 2000, XP, or Server 2003 (in 2000, XP, or Server 2003, open My Network Places), you can double-click any one of those servers and see the list of shares that the servers offer; that too, is information from the browse list. In Windows for Workgroups or Windows NT 3.x, you’d just click a server once, and the list of its shares would appear in the bottom pane of the dialog box. From DOS or any other command line, you’d get the list of servers by typing net view, as you’ve already seen, and then you get the list of shares for any given server by typing net view \ \servername, where servername is the name of the server whose shares you want to see.When Browse Lists Get Too Large: Workgroups to the RescueAs I’ve described them so far, browse lists seem pretty convenient. But in the little test network that I used for the previous screen shots, you saw only a few servers. Hell, everything works fine on small networks.

Now let’s talk about your network. Sit down at a corporate network of any size and you see dozens, hundreds, or thousands of servers. Scrolling down through a 500-server browse list would be a bit

time-consuming—to say nothing of how much work the browse master would have to do to keep it up-to-date! The problem to solve is, then, managing the size of the browse list. There are twoways to do that:

◆ Reduce the number of servers in your enterprise.

◆ Divide the enterprise-wide browse list into several smaller browse lists called workgroups.

Disable Peer-to-Peer Sharing on Workstations

The first answer is actually a bit off the main topic, but let me digress for a moment and talk about it before returning to the main item: workgroups. When I say, “Reduce the number of servers,” I’m talking about an unfortunate side effect of running Windows for Workgroups, Windows 9x/ME, Windows NT, 2000, or XP workstations—they all have the capability to become peer-to-peer servers. The browse masters don’t distinguish between industrial-strength servers running NT Server and low-octane peer-to-peer servers, so you could end up with a browse list that’s supposed to only list your servers, but actually lists all of your servers and workstations. In general, I think peer-to-peer networking is a bad idea. If a piece of data is important enough to be used by two employees, then it’s a company asset that should be backed up regularly and so should go on a managed file server, not a desktop machine that’s probably backed up once a decade. My recommendation is this: Disable the peer-to-peer sharing option on your Windows for Workgroups, Windows 9x/ME, Windows NT, 2000, and XP workstations. How you do this depends on the operating system of the work-stations in question. In NT 3.x and 4, open the Control Panel and then the Services applet; locate the service called Server and stop it, as well as disabling it for future reboots. In Windows 9x, go to Control Panel/Network/File and Print Sharing and make sure both options, to share files and printers, are unchecked. In Windows for Workgroups, make sure the sharing control in Network Setup is set not to enable file or printer sharing. In Windows 2000 and later, right-click My Computer and choose Manage, then find the Services folder and stop the Server service. (You’ll see more about doing this later in the book.)

Not only will your network have less traffic—workstations will no longer have delusions of server-dom, so they won’t be chattering at the browse master all of the time—but not loading the server part of the workstation’s operating system saves RAM on the workstation. Divide the Browse List into Workgroups The other approach to keeping a browse list to a manageable size is to subdivide it in some way.

That’s a reasonable thing to suggest if you realize that, no matter how large an organization seems to be, it’s usually composed of lots of smaller groups, such as Manufacturing, Sales, Marketing, Accounting, Finance, Personnel, Senior Management, and so on. Each of those groups can be called workgroups, and you can pretty much chop up your enterprise into workgroups in any way you like (but a rule of thumb says that a workgroup should be a group of people for whom 95 percent of the data generated by that group stays within that group).From a more network-technical point of view, the minimum definition of a workgroup is just a group of workstations that share a browse list. (That’s my definition, not Microsoft’s.) The idea is that when someone in Accounting opens up her browse list, you want her to see just the Accounting servers, not the Manufacturing servers, as she has no use for the Manufacturing servers. (Besides, there’s a good chance that she doesn’t have permission to access the Manufacturing servers anyway— but I’ll get to workgroups and security in a little bit.) How do you join a workgroup? See the sidebar “How Do I Join a Workgroup?”

How Do I Join a Workgroup?

Generally, all you need to do is to tell the networking software on your workstations and servers that they’re members of a given workgroup. There isn’t any “security” in being part of a workgroup—you pretty much just declare yourself a member and you are a member. (As a matter of fact, if you misspell the name of the workgroup, you end up accidentally founding a whole new workgroup all by yourself, which I’m sure was not your intention!) Specifically, you designate which workgroup you’re a member of in one of the following ways: From a DOS or Windows for Workgroups workstation In the [network] section of the SYSTEM.INI file you’ll find a WORKGROUP=parameter. (You’ll have a SYSTEM.INI even if you’re just running DOS, because the network client software creates one.) You can also set the workgroup from the MS-DOS Net-work Client Setup program, or in the Windows for Workgroups’ Network applet of the Control Panel.

From Windows 9x Open the Control Panel and double-click the Network icon. In the property sheetthat you see, click the Identification tab. You see the place to fill in the workgroup name. On Windows NT 3.x Open the Control Panel and double-click the Network applet. You’ll see a button labeled Domain or Workgroup. (NT has a kind of confusing way of blurring workgroups and domains, which I’ll make clearer later in this chapter.) Click that button, and you can change the workgroup you’re a member of. Again, NT complicates choosing a workgroup somewhat, so read the rest of this chapter if you want to change an NT workgroup.

On Windows NT 4 Open the Control Panel and double-click the Network applet. Like Windows 9x, Windows NT 4 has a property sheet with an Identification tab. Click Change to change the work-group. Again, with NT you may see no references to workgroups at all; instead you see references to domains. Read on to understand the differences. On Windows 2000 If you’re a member of a domain, then do not join a workgroup—I’ll explain that in a minute. Otherwise, right-click My Computer and choose Properties. Click the Network Identifica-tion tab and then the button labeled Properties. Fill in a new workgroup in the field named Workgroup; then close the dialog box and reboot.

On Windows XP and Server 2003 Right-click My Computer and choose Properties. (You may have to click the Start button to find My Computer.) Click the tab labeled Computer Name, then the button labeled Change. In the resulting dialog box, you’ll see the choice to become a “Member of:” either a domain or a workgroup. Click the radio button next to Workgroup and fill in the workgroup name, then close the dialog box and reboot.

Note Workgroup names are like Windows 9x and NT 3.x/4.x machine names and can be up to 15 characters long. So, to review what you’ve seen so far:

◆ Network browse lists allow a user at a workstation to see all of the servers on the network, and from there to see all of the shares on a given server.

◆ Browse lists can get fairly long, so you can partition your entire network into workgroups, which

are just groups of people that share a browse list.

◆ When you request a browse list, you don’t get the entire list of servers in your enterprise

network, you only get the list of servers within your workgroup.

◆ Each workgroup has one or more servers that act as gatherers of browse information. They’re

called browse masters or master browsers, and they’re picked automatically.

◆ Machines that are only workstations and don’t act as servers even in a peer-to-peer capacity

do not appear on browse lists.

As the question of what machines go on a browse list and what machines don’t is important to the length of a browse list, let me list the kinds of machines that can act as servers in a Microsoft enterprise network:

◆ Windows 3.x (with the Workgroup Add-On for MS-DOS clients)

◆ DOS (with Workgroup Add-On for MS-DOS clients)

◆ Windows for Workgroups

◆ Windows 9x/Me

◆ NT Workstation

◆ NT Server

◆ Windows 2000 Professional

◆ Windows Server 2003

How Do I View a Browse List?

Microsoft has built different browse programs into its various network client software.From a DOS or NT/2000/XP/2003 Command Line Type net view. That shows you the list of servers. You can view the shares on a given server by typing net view \\servername. To see the browse list for a workgroup other than your own, type net view /workgroup:workgroupname.

From NT, 2000, XP or Server 2003, don’t use /workgroup: in the command; instead, use /domain:

From Windows for Workgroups or Windows NT 3.x Open the File Manager, click Drive, and thenclick Connect Network Drive. You’ll see a window with two panes. The browse list for your workgroup and a list of the other workgroups on the network appears as the list of possible servers in the top pane and,when you click a server, that server’s shares appear in the bottom pane. To see the browse list for a workgroup other than your own, double-click the name of the workgroup in the top pane.

From Windows 9x or Windows NT 4 Open the Network Neighborhood folder. You’ll see the servers in your workgroup represented as PC icons in a folder. Double-click one of the servers, and a folder will open up showing you the shares. To see the browse list for a workgroup other than your own, double-click the Entire Network icon and you’ll see a list of workgroups. On Windows NT 4, click Entire Network and then Microsoft Network, and you’ll get a list of the other workgroups.

From Windows 2000 If your system is in a workgroup, open My Network Places and then the icon labeled Computers Near Me. If your system is part of a domain, then that icon isn’t available. Instead, open My Network Places and the icon labeled Entire Network, then the icon named Microsoft Win-dows Network. You’ll see one or more icons representing the workgroups on your network—open the one representing your workgroup and you’ll see your workgroup’s browse list.

From Windows XP or Server 2003 Open My Network Places. It might be on your desktop, or it might be on the Start menu, or you might have to right-click the Desktop and choose Properties, then click the Desktop tab, followed by the Customize Desktop button, then check the box next to My Network Places and click OK twice. My Network Places will be on your desktop. Once you have My Net-work Places open, then you’ll either see a Network Task on the left of the folder labeled View Workgroup Computers or you might have an icon labeled Entire Network, in which case you should double-click that, then double-click Microsoft Windows Network. You’ll then see an icon of three PCs representing your workgroup—click that and you’ll get your workgroup’s browse list.

As it’s an unusual product, let me just explain that the Workgroup Add-On for MS-DOS is a separate Microsoft product that lets you use a DOS machine as a peer-to-peer server. (Also, it’s pretty old, so I have no idea where you’d get a copy these days.) Again, I recommend that you disable file and print sharing on all of these machines except, of course, for the machines dedicated to the task of being servers, all of which are probably running NT Server.

And once you’re in a workgroup, you’ll no doubt want to see your browse list; the sidebar “How Do I View a Browse List?” tells you the specifics. Now, if you tried that on a working network, then you might have gotten one of NT and family’s less helpful responses, like “System error 1230 has occurred.” That gives me the chance to offer another important bit of advice for anyone using a modern Microsoft operating system: how to convert a numeric error code into a bit of explanatory English text—see the sidebar for more information.

How to Convert a Numeric Error Code to English Text

Just type net helpmsg number, where number is the error code. For example, you’ll probably stumble across error 5 now and then: “access is denied.” It means that you didn’t have the right to do something that you tried to do. Another common one is error 53, “the network path was not found.” It means that you tried to access some server that the system can’t find or, as is usually the case for me, you misspelled the server’s name.

Before leaving the topic of the browser, let me offer one more piece of advice: try to avoid it, as it’s unreliable. If your users need access to particular file shares, then you can deliver access to those shares in a few ways. First, you can map file shares, which means that you can create imaginary drive letters on your user’s workstations. In other words, if the user often uses \\server1\compdata, then you could set up her workstation so that she’d see a new drive V: which isn’t a local hard disk—although it looks like a local hard disk—but is instead a network drive. Or you could simply create a shortcut to the UNC on her desktop. You’ll learn how to do both of those things in Chapter 11.

Summary: The Necessary Evils

I hope in this section that I’ve provided a bit of an answer to the question, “Why do we have to worry about all of this stuff just to get a mail server up and running?”

◆ First, you need a piece of server software that can accomplish whatever it is that you’re trying to do—Web server, mail server, or whatever.

◆ Next, you need to be compatible with and connected to a physical network that connects to your clients—either the public Internet or a private network of some kind.

◆ Then your server must move its data around in the same way that your clients’ machines do, using the same network language or protocol, probably TCP/IP. TCP/IP itself will require some server functions as well, to maintain it.

◆ It wouldn’t be necessary in a perfect world, but in our imperfect world your network needs to protect its data with a security system, and in today’s world that unfortunately means an elaborate security system.

◆ Finally, you’ll need some way of finding what you put in that network, once you’ve got it working. Active Directory will become that way in the future, but for now it’s a kludgy thing called the Computer Browser that you see in My Network Places.

So presumably you now see why your network needs so many moving parts. Why buy them from Microsoft?

So Why Use NT/2000/Server 2003?

I hope that by now I’ve convinced you that networking seems like a good thing. But you could build your network atop any number of operating systems, including Unix, Linux, Novell NetWare, IBM’s OS/400 or MVS, or Compaq’s VMS, just to name a few. Why NT or its most recent incar-nation, Windows Server 2003?

Well, understand when I answer that question that (1) I’m not from Microsoft, (2) I’m not here to sell NT/2000/2003 to you, I’m just here to tell you how to make it work, and (3) the reality of the matter is that every one of the OSes that I just named are good products that have not only their adherents and detractors, but that also have many solid positive features. After decades of business computer use, the market has filtered out both the truly terrible products and some perfectly good but inadequately marketed products, leaving only products that are at least competent (and always well-marketed). So if you want to read that Server 2003 is not only your best choice, but also that you’re a total fool to try to use anything else, then I’m afraid you’ve come to the wrong place. Yes, I like NT, including its latest incarnation (Server 2003), but it’s not the only answer.But it is a very good answer. Here’s why.

It’s the Market Leader

Most stats that I see say that the Microsoft family of operating systems has the largest market share—43 percent of servers according to the last set of numbers that I saw. Being part of the biggest market share means that it’s easier to find consultants, support, and third-party tools. Oh, and it also means that there’s plenty of demand for your services once you become an expert!

Its Familiar GUI Makes It Easier to Get Started

The fact that Windows Server 2003 uses a GUI that is basically the same as Wintendo—oops, I meant Windows 9x/Me—means that hundreds of millions of people already know how to navigate the 2003 Desktop. Yes, some things have been moved around, but in general once you know Windows, you know how to get around on 2003.

In contrast, I have recently done a lot of work with Linux and, while it’s a quite powerful operating system, the user interface is not for novices; even its multitude of GUIs are still clumsy, although that’ll probably change with time. (That’s not to say that you shouldn’t use Linux—just that I think the Microsoft OSes have an easier-to-use GUI.) With 2003, you can often figure out how to solve a problem by noodling around in the GUI—it lends itself more to exploration than would an operating system that relies mainly upon command-line commands to control it.

Many Tools Come “in the Box”

When NT 3.1 first came out, it was pretty amazing that it came with a dial-in module and a host of other goodies that you had to buy separately in order to run its competition at the time, Novell NetWare. NT had a free TCP/IP stack when many other OSes were charging big bucks for it, a free Web server, and so on. Since then, other server operating systems have continued to include more and more things with the basic operating system—for example, the variety of tools that comes with Linux is nothing short of stunning—but Microsoft has kept the heat on the competition by including a variety of new tools with every release. At this point, the basic version of Server 2003 includes (in addition to its basic functionality of a file and print server) a Web server, an FTP server, a sophisticated Internet router, automated workstation rollout tools (Remote Installation Services), centralized software distribution tools (Group Policies), a two-level disk storage system (Remote Storage Manager), encryption (Encrypted File System), an e-mail server, a SQL-based database server and lots of other tools.

Not all of the tools are stellar; for example, the disk quota system, which allows you to keep any given user from stealing all of the disk space on the shared file servers, is pretty lame. But because Server 2003 provides at least a basic quota functionality, the many shops that are trying to minimize the number of vendors they deal with can get an awful lot of their networking needs met in just one package: Server 2003.

When you view Microsoft products, bear in mind that you usually won’t encounter really cutting-edge tools; in my judgment, that’s not Microsoft’s market niche. Instead, they seem to focus on incrementally improving existing products, as well as adding new tools by imitating competitors. Not being the first on the block can sometimes be a pretty good thing, as you get to watch the competi-tion’s mistakes. Very little in Windows Server 2003 is truly never-seen-before-in-the-world new. Instead, it’s a distillation of a lot of other people’s good ideas. Yes, some may see that as stealing other people’s good ideas, and there’s some merit to that view. And Microsoft has what some might call an unfair advantage in that they’ve got enough money to keep trying and trying and trying; for example, their first two networking products, MS-NET and LAN Manager, were pretty weak compared to the competition’s, but they had the money and tenacity to keep slugging away it, finally releasing the far-better NT product. Another example of this strategy occurred in 2001, with Microsoft’s release of the Pocket PC 2002 operating system. They’re trying to crush the PalmOS guys in the palmtop market, and they’ve made two weak attempts with Windows CE 1.0 and 2.0, but they’re learning. I don’t know if Pocket PC will beat PalmOS—as a long-time Palm user, I tend to think not—but they’ll definitely steal more of PalmOS’s market share with Pocket PC than they ever did with Windows CE. And while Microsoft’s detractors like to paint Microsoft as nothing but a bunch of rip-off artists, it’s actually hard to find who originated these ideas. Some say that Microsoft stole Novell and Apple’s best ideas; well, Novell certainly didn’t invent networking, and their IPX/SPX protocol is blatant “theft” of a Xerox protocol. Apple didn’t invent the GUI that Microsoft supposedly stole—Xerox did. (Hmmm, maybe there’s a pattern here.) Nor is Active Directory a rip-off of an original Novell product, Netware Directory Services—NDS is based on a directory standard called X.500 and terms that many people think that Novell invented, like “organizational unit,” are X.500 terms. In any case, it is something of a comfort for people to be able to buy a single product that is a decent fit for just about all of their networking needs, instead of looking for the best of breed in each area. Why?

Anyone who’s ever tried to troubleshoot a multivendor network problem knows why: Both vendors just point the finger at the other vendor and say, “That’s him—he’s the guy causing your problem.” (They’re hoping you’ll get tired and go away. Most of us do, sadly.)In contrast, the same people are developing all of 2003’s pieces; so you have to believe that at some point someone would have noticed if they didn’t fit together. Or that if someone didn’t notice it before they shipped, they’ll get around to fixing it afterward.

In sum, why use 2003? It’s fairly reliable, it does most of what you want a network operating system to do, it’s reasonably priced, and enough other people use it that you’re probably not going to go terribly wrong.A Brief History of NT Let’s finish this chapter with a look at how NT has grown and changed since its early days.Even in the early 1980s, Bill Gates knew that networking was a key to owning the computer business. So, on April 15, 1985, Microsoft released its first networking product, a tool called MS-NET, and its companion operating system, DOS 3.10. Most people knew about the new DOS and were puzzled at its apparent lack of new features. What it contained, however, were architectural changes to DOS that made it a bit friendlier to the idea of networks.

Now, Microsoft wasn’t big enough at that time to create much hoopla about a new network operating system, so they let others sell it—no matter how high or low you looked, you couldn’t buy a product called MS-NET. Instead, it sold mainly as an IBM product under the name of the IBM PC Network Support Program; IBM viewed it as little more than some software to go along with their PC Net- work LAN boards and, later, their Token Ring cards. The server software was DOS-based, offered minimal security, and, to be honest, performed terribly. (Believe me, I know; I used to install them for people.) But the software had two main effects on the market.

First, the fact that IBM sold a LAN product legitimized the whole industry. IBM made it possible for others to make a living selling network products. And that led to the second effect: the growth of Novell. Once IBM legitimized the idea of a LAN, most companies responded by going out and getting the LAN operating system that offered the best bang for the buck. That was an easy decision: NetWare. In the early days of networking, Novell established itself as the performance leader. You could effectively serve about twice as many workstations with Novell NetWare as you could with any of the MS-NET products. So Novell prospered.

As time went on, however, Microsoft got better at building network products. 3Com, wanting to offer a product that was compatible with the IBM PC Network software, licensed MS-NET and resold it as their 3+ software. 3Com knew quite a bit about networking, however, and recognized the limitations of MS-NET. So 3Com reworked MS-NET to improve its performance, a fact that didn’t escape Microsoft’s attention.

From 1985 to 1988, Microsoft worked on their second generation of networking software. The software was based on their OS/2 version 1 operating system. (Remember, Microsoft was the main driving force behind OS/2 from 1985 through early 1990. Steve Ballmer, Microsoft’s number two guy, promised publicly in 1988 that Microsoft would “go the distance with OS/2.” Hey, the world changes and you’ve got to change with it, right?) Seeing the good work that 3Com did with MS-NET, Microsoft worked as a partner with 3Com to build the next generation of LAN software. Called Microsoft LAN Manager, this network server software was built atop the more powerful OS/2 operating system. As with the earlier MS-NET, Microsoft’s intention was never to directly market LAN Manager. Instead, they envisioned IBM, 3Com, Compaq, and others selling it.

IBM did indeed sell LAN Manager (they still do in the guise of OS/2 LAN Server). 3Com sold LAN Manager for years as 3+Open but found little profit in it and got out of the software business. In late 1990, Compaq announced that they would not sell LAN Manager because it was too complex a product for their dealers to explain, sell, and support. Microsoft decided then that if LAN Manager was to be sold, they’d have to do the selling, so on the very same day as the Compaq withdrawal, they announced that they would begin selling LAN Manager directly.

Note Interesting side note: Ten years after Compaq decided that their sales force couldn’t sell network software, they reversed direction and said that they’d sell a special version of Windows 2000 called Datacenter Server. It’s special because you cannot buy it from Microsoft—you must buy it preinstalled on specially certified vendor hardware. In other words, the hardware vendors (Compaq’s not the only one selling Datacenter) now believe that they can sell complex network operating systems. I wish them the best of luck, but stay tuned to see the outcome of this particular marketing maneuver!

LAN Manager in its first incarnation still wasn’t half the product that Novell NetWare was, but it was getting there. LAN Manager 2 greatly closed the gap, and in fact, on some benchmarks LAN Manager outpaced Novell NetWare. Additionally, LAN Manager included administrative and security features that brought it even closer to Novell NetWare in the minds of many network managers. Slowly, LAN Manager gained about a 20 percent share of the network market.

When Microsoft designed LAN Manager, however, they designed it for the 286 chip (more accurately, I should say again that LAN Manager was built atop OS/2 1.x, and OS/2 1.x was built for the 286 chip). LAN Manager’s 286 foundation hampered its performance and sales. In contrast, Novell designed their premier products (NetWare 3 and 4) to use the full capabilities of the 386 and later processors. Microsoft’s breakup with IBM delayed the release of a 386-based product and, in a sense, Microsoft never released the 386-based product.

Instead of continuing to climb the ladder of Intel processor capabilities, Microsoft decided to build a processor-independent operating system that would sit in roughly the same market position as Unix. It could then be implemented for the 386 and later chips, and it also could run well on other processors, such as the PowerPC, Alpha, and MIPS chips. Microsoft called this new operating system NT, for new technology. Not only would NT serve as a workstation operating system, it would also arrive in a network server version to be called LAN Manager NT. No products ever shipped with that name, but the wallpaper that NT Server displays when no one is logged in is called LANMANNT.BMP to this day. In August 1993, Microsoft released LAN Manager NT with the name NT Advanced Server. In a shameless marketing move, they labeled it version 3.1 in order to match the version numbers of the Windows desktop products. This first version of NT Advanced Server performed quite well.

However, it was memory-hungry, lacked Novell connectivity, and had only the most basic TCP/IP connectivity. September 1994 brought a new version and a new name: Microsoft Windows NT Server version 3.5. Version 3.5 was mainly a “polish” of 3.1; it was less memory-hungry, it included Novell and TCP/IP connectivity right in the box, and it included Windows for Workgroups versions of the administrative tools so network administrators could work from a Workgroup machine rather than an NT machine. Where many vendors would spend 13 months adding silly bells and whistles, NT 3.5 showed that the Microsoft folks had spent most of their time fine-tuning the operating system, trimming its memory requirements, and speeding it up.

In October 1995 came NT version 3.51, which mainly brought support for PCMCIA cards (a real boon for us traveling instructor types), file compression, and a raft of bug fixes.NT version 4, 1996’s edition of NT, got a newer Windows 95–like face and a bunch of new features, but no really radical networking changes. Under the hood, NT 4 wasn’t much different from NT 3.51.

From mid 1996 to early 2000, no new versions of NT appeared, an “upgrade drought” such as we’d not seen in quite some time from Microsoft. Then, in February 2000, Windows 2000 (“NT 5.0”) shipped. 2000 included a whole lot of new stuff, but perhaps the most significant was a new way of storing and organizing user accounts and related information: Active Directory domains. Closely following AD in importance was the then-new notion of group policies, something that you’ll see has become quite important to anyone wanting to run a network based on XP and Server 2003.

The next version of NT shipped in pieces for the first time since 1993. First NT Workstation 5.1 or, as it’s better known, XP Professional and its lesser sibling, XP Home. Microsoft intended to follow up with the server version of NT 5.1, but events conspired to compel them to wait a bit longer, and produce NT Server 5.2—that is, Windows Server 2003. As you read in the last chapter, it’s a “1.1” version of Windows 2000, a welcome improvement to 2000’s fit and finish. That’s not the end of the story for NT. Sometime in 2004 or 2005, we will see a re-unified NT (5.3? 6.0? Time will tell) code-named Longhorn. That in turn will pave the way for yet another version of NT, code-named Blackcomb, but let’s wait for another edition or two of this book to cover that product.

Well, I hope this chapter wasn’t boring for those already expert in NT—I did warn you!—and helped bring the newbies up to speed. No matter what version of NT you’re running, however, you’ll need to configure it. And there are, as there always have been, two main ways to do it. The preferred way is through the GUI with windowed programs that offer help and a bit of error-checking, or its somewhat more complex relatives, the command-line tools. The less-preferred, but often necessary, way is to directly tweak some setting in its lair … a place called the Registry. The next two chapters introduce these two configuration approaches.