This chapter is here to give you some ideas about Windows NT configuration,
but it is not intended to replace the installation documentation
that comes with Windows NT. The information in this chapter covers
assorted topics that might be just enough for you to go on if
you have worked with other network operating systems before. If
you don't consider yourself an expert in networking, this chapter
alone isn't going to make you a system administrator, and I would
wholeheartedly advise you to pick up a copy of Windows NT Server
Survival Guide written by Rick Sant'Angelo and Nadeem Chagtai.
I consider their book to be perhaps the best buy on the market
when it comes to learning all the ins and outs of NT administration.
It's also the single best book to supplement this one on an NT
Webmaster's bookshelf, in my opinion.
Tip |
While I'm on the subject of useful sources for reference materials, I think that every Windows NT administrator should have a subscription to Windows NT Magazine. Each issue is packed with useful technical articles and product reviews to keep you informed about the BackOffice network. |
When buying Windows NT, you have a choice between the Server version and the Workstation version. Both are very capable, reliable, 32-bit, multithreading, preemptive-multitasking, GUI, network operating systems. In version 4, the biggest difference between the two is that the Server version now includes Internet Information Server (IIS) for free. IIS includes a high-performance Web server, an FTP server, and a Gopher server. (See Chapters 7 and 9.)
NT Workstation is more affordable than NT Server (street prices around $260 versus $675, respectively). Although the Workstation version is designed for better single-user performance, it can also reliably handle a Web server. The Server version does have several features that Workstation lacks, but most are probably not critical to building an Intranet. The following list details a few key differences:
When dealing with Intranets, the first difference in the preceding list is not a problem. The number of Web clients that can simultaneously connect to your server is not the same as the number of LAN users. With either version of NT, the number of possible Intranet client connections is limited by the performance of the network, the hard disk, and other factors. The performance of the kernel system software isn't really a major problem either, unless you are planning to process hundreds of transactions per minute. Therefore, I recommend NT Workstation for those who like to save a few hundred dollars.
For the rest of this chapter, I'm going to assume that you have already installed Windows NT 4. One of the first things you need to do after installing NT is to get TCP/IP running as your primary network protocol. As you recall from Chapter 1, the Web requires TCP/IP. Now I must confess that I lied-sort of. Thanks to the hard-working engineers at Microsoft, Winsock 2.0, which has just been released in Windows NT 4, enables Windows network applications to run transparently on other network protocols besides TCP/IP. If you are considering not running TCP/IP on your Intranet, keep in mind that this alternate protocol feature is very new, and you should investigate it carefully before adopting it. It may take some time to determine whether all Winsock 1.1 applications will run as is on Winsock 2.0 on top of alternate protocols. Also, you would need to deploy Winsock 2.0 on all your Intranet client machines. I haven't tested this feature, and I can't see any great gain in not using TCP/IP. If you have other pre-existing protocols that you must run in addition to TCP/IP, such as NetBEUI and/or IPX/SPX, you can be confident that Windows NT Server can handle practically everything you can dish up. (Windows 95 and Windows for Workgroups 3.11 can support up to three protocols at once.)
Follow these steps to add TCP/IP to Windows NT Server 4 (similar steps apply to NT Workstation):
Figure 6.1: Adding TCP/IP to the Network Protocols.
After you have TCP/IP installed, follow these steps to configure the protocol:
Note |
If the client machines on your Intranet are running Windows NT or Windows 95, you should have no trouble installing and configuring the built-in TCP/IP support that comes with those operating systems. If, however, you still have Windows for Workgroups 3.11 clients, you will need to install the free TCP/IP 32-bit stack as an add-on. You can either download the latest version from the Microsoft FTP site, or you can install it from the \Clients\Tcp32wfw directory on the Windows NT 4 Server CD-ROM. You can install it on the client machines across the LAN (assuming they are at least running NetBEUI to make an initial connection to the server). |
A lot of confusion exists about the difference between HOSTS and
LMHOSTS. These terms refer to text files that reside in the \winnt\system32\drivers\etc
subdirectory of Windows NT. I won't be covering these topics in
depth here, so again, please consult Windows NT Server Survival
Guide as a source for detailed information.
Tip |
I highly recommend that you create a desktop icon on your NT machine for the online books on the Microsoft Windows NT CD-ROM. Use Explorer to browse to the \support\books directory, and then drag the file server.hlp to your desktop to create a shortcut. The help files contain loads of technical information about everything from DHCP to User Manager. |
In addition to the confusion concerning the difference between HOSTS and LMHOSTS, a separate confusion exists concerning the difference between WINS and DHCP. To keep the differences straight, remember that HOSTS goes with DNS, and LMHOSTS goes with WINS. Notice that I didn't mention DHCP in that sentence; the choice to run DHCP is independent of your choice to use HOSTS files or DNS.
HOSTS files can serve as a replacement for DNS if you place identical files on all the Windows clients in your LAN. HOSTS files map IP addresses to computer names, one per line. The confusion comes about because these names are TCP/IP computer names, or host names, which are quite different from the NetBIOS names you can give to Windows computers. Microsoft and IBM adopted NetBIOS in the early days of pcs to provide an efficient network protocol without forcing users to endure the headaches of TCP/IP configuration (in those days, TCP/IP required knowledge of UNIX). If you run your own DNS server on your Intranet, or if you connect to an Internet Service Provider, you won't need to suffer with the maintenance headache of the HOSTS files.
DHCP, Dynamic Host Control Protocol, stands alone in this section as a way to lease valid IP addresses from a large block to the computers on your LAN as they log into the Windows NT domain. This capability can be a plus as your LAN grows because you don't have to worry about coming up with a new address when new computers are added to the network and, more importantly, you don't have to be present to help configure the IP address when a conflict occurs (DHCP only leases available addresses).
LMHOSTS maintains NetBIOS computer name mappings to IP addresses in the same way that HOSTS maintains DNS computer name mappings. WINS plays a similar role, but in an automatic fashion, of course, so you avoid the hassle of updating and copying LMHOSTS files all over the network. The LM in the name LMHOSTS comes from LAN Manager, which was an early Microsoft network technology-the grandparent of Windows NT.
Once you have your LAN up and running, you're going to want to share files and printers. One of the reasons you'll want to do this is so that you can write HTML files on your own workstation before you copy them to the Web server directory on the network server (assuming, as is most likely the case, that the server is not your workstation).
In Windows NT 4, you use Explorer to share drives and files on the computer where they reside. You can still use File Manager too, if that is what you are used to from NT 3.51. Once you have shared a drive or directory, such as the WWWRoot directory where IIS is installed, you can connect to that drive from another computer on the LAN in a process called mapping a network drive. The remote drive then becomes a drive letter on your machine that you can refer to as if it were a local drive.
This process establishes a mapping, or association, between, say, drive N on your computer and drive D on the server, which is named banana. But if my computer is on the same LAN, I might have chosen to map the server drive D to my own drive M, not knowing that you had called it N on your computer. This difference could lead to confusion when you and I refer to files on the server because we each look at the same file and think of it with a different name.
Windows uses a very simple syntax to refer to network shared drives in a manner that avoids this potential confusion. This syntax is called Unc naming, or Universal Naming Convention. The thing that remains unique in the preceding scenario is the server name (banana) and the server's drive (D). The only problem is that the Unc syntax should not conflict with the existing syntax used for local files and directories. Unc names begin with double backslash characters to make them unique, and the colon is removed from the drive letter designation. Continuing the preceding example, drive M on my computer would have an equivalent Unc name of \\banana\d\. Drive N on your computer would have the same Unc name, which is exactly the goal of Unc names. To refer to a file in a subdirectory on drive N using Unc names, you tack on the pathname and filename as you would for a local file, for example, \\banana\d\somedir\somefile.txt.
Chapter 7 demonstrates that one reason this topic is relevant to your Intranet is that Unc names are required to make IIS virtual directories to other computers.
Each of the tools listed in this section has its place in the toolbox that no NT Webmaster should be without. Knowing about these tools is one thing, but being familiar with them is another. Acquaint yourself with their capabilities at your earliest convenience, and you will be rewarded day in and day out.
This section introduces you to these tools' purposes and describes their basic capabilities. Most of these programs have dozens of options for all kinds of different needs and situations. It is up to you to try the programs and consult the appropriate documentation for further information.
If you're running on a network, ipconfig will tell you your own IP address and other facts about your Network Interface Card (NIC).
You use ping to determine whether another computer running TCP/IP is reachable from your machine and how long it takes for a packet to make the round trip back to your computer.
The tracert tool is the NT console mode application equivalent to UNIX traceroute. This tool can display the entire route your IP packets take from your server to the host that you select. If you have access to the Internet, this tool can be fascinating to play with when you want to see how fast data can travel halfway around the world.
The netstat tool is handy for looking at the status of the LAN. You can see active connections to all ports and get a statistical breakdown of all connections over time.
To examine the status of TCP/IP connections that are using NetBIOS over TCP/IP, use the nbtstat command-line tool.
The handy WinMSD tool is installed in the menu system under Start | Programs | Administrative Tools | Windows NT Diagnostics. You can also run this program from the command line (winmsd.exe), but I use it so often that I created a shortcut icon on the desktop. WinMSD enables you to browse a lot of valuable system information without having to resort to separate tools.
Although WinMSD does not let you change any system parameters, it is a handy one-stop utility for information on OS version, hardware, memory, drivers, services running, drives, devices, IRQ/port status, DMA memory, environment, and network configuration. You can print any of the information displayed or save it to a file. WinMSD also has a Tools menubar that lets you launch Event Viewer, Registry Editor, or Disk Administrator. If you ever sit down at an NT system that you are not familiar with, WinMSD is the tool to start with. (See Figure 6.3.)
Figure 6.3: Windows NT Diagnostics (winmsd.exe) displays the network settings.
Performance Monitor is a great GUI tool that is very easy to use
after you get a little used to it. It gathers good statistics
on IP/TCP/ICMP messages. This tool is your best all-around diagnostic
tool for both the network (if your copy of NT is on a LAN) and
the NT system itself (for example, CPU usage and disk I/O). For
more information about Performance Monitor, consult the Windows
NT Resource Kit.
Note |
To get the most out of Performance Monitor, install the SNMP service along with TCP/IP. With SNMP installed (through the Control Panel Network icon) and enabled (through the Control Panel Services icon), Performance Monitor can track IP packet statistics on your site. |
The Registry contains important Windows NT data about user preferences and the hardware and software installed on your computer. Many of the values kept in the Registry are similar to those that you would find in the WIN.INI and SYSTEM.INI files of a machine running Windows 3.1. The Registry is a hierarchical database used to maintain configuration information for Windows NT and the users of the computer.
The Registry is broken down into four subtrees. (Future versions of Windows NT might increase this number.) The root key names at the top of each subtree are prefixed with HKEY to indicate that they are handles to keys. Windows programmers speak of a handle as a reference to an operating system resource. A key is nothing more than a word by which you can look up an associated value (like a dictionary entry and its corresponding definition). The next sections cover the four root keys.
The HKEY_LOCAL_MAchINE key contains information about the local computer system, including hardware and operating system data such as bus type, memory, device drivers, and start-up control data. This key is the subtree that you will be most concerned with.
The HKEY_CLASSES_ROOT key contains object linking and embedding (OLE) and file-class association data.
The HKEY_CURRENT_USER key contains the user profile for the user who is currently logged on, including environment variables, personal program groups, desktop settings, network connections, printers, and application preferences. This key always refers to a user in the subtree of HKEY_USERS.
The HKEY_USERS key contains all actively loaded user profiles, including HKEY_CURRENT_USER and the default profile. Users who are accessing a server remotely do not have profiles under this key on the server; their profiles are loaded into the Registry on their own computers.
Many of the program configuration changes you make through the GUI in Windows NT (such as in Control Panel) will be automatically written into the Registry for you. Whenever possible, allow the friendly interface of Control Panel and other applications to write to the Registry on your behalf. Several advanced settings mentioned in this book, however, can be made only by directly editing the Registry. To make these changes, use REGEDT32.EXE (the Registry Editor) as shown in Figure 6.4.
Figure 6.4: Using the Registry Editor to change a DWORD value.
Warning |
If you are not very careful, making changes directly to the Registry can sometimes prevent your computer from working properly. Windows NT displays a standard warning about this problem whenever you invoke the Registry Editor. The warning reads as follows: Caution: Using Registry Editor incorrectly can cause serious problems, including corruption that may make it necessary to reinstall Windows NT. |
Most of the Registry values that are changed in this book are found under HKEY_LOCAL_MAchINE/SYSTEM/CurrentControlSet.
As you navigate through the Registry with Registry Editor, you will notice that each entry in the structure is one of three things: a root key, a subtree, or a value. Value entries don't appear until you reach the end of a given subtree. Although this structure might sound complicated, the whole idea is to keep a huge amount of data organized. You'll see that the Registry serves that purpose very well, once you get used to it.
I've already discussed the four root keys. Think of subtrees as branches off of the main trunk, assuming the root keys are the main trunk. Each value entry has three parts: name, data type, and the actual value. By default, the Registry recognizes the following five types of data. The Win32 API includes functions that programmers can call to add other data types as necessary.
The REG_BINARY type is used for binary data that is uninterpreted by the Registry Editor. Such data can be interpreted either by the program that writes the entry or by a system function inside NT that will process the data at the appropriate time in the execution of the program that wrote the value. This data type can be used for values that don't fit any of the other types. Because all data in digital computers always exists in binary form, usage of the other data types is only a matter of convenience when the data can be interpreted by the Registry Editor in a human-readable form.
The REG_DWORD data type can contain 4 bytes of data. The basic unit of memory on Intel and many other computer architectures is 4 bytes, or 32 bits. This data type is useful for storing integers.
The SZ in the REG_EXPAND_SZ stands for string zero, which means a NULL-terminated array of characters in C or C++. This data type indicates an expandable string of text that contains a variable that will be substituted at runtime. For example, the string %SystemRoot% appears throughout the Registry. This string will be replaced at runtime by the actual location of the Windows NT system directory.
The REG_MULTI_SZ data type is used to hold several string values, each one separated by NULL bytes.
The REG_SZ data type is used to represent a simple array of characters or byte values. As you traverse the Registry, you will come across numerous examples of its use for strings of text.
Now that TCP/IP is up and running, the next chapter will bring the Intranet to life. The Web server will be the vital hub of your effort.