Microsoft Windows NT Server Administrator's Bible: Option Pack Edition

Last Updated 9/18/2009 3:40:48 PM

Chapter 5: Linking Nodes and Networks -- RAS and TCP/IP

Abstract

This chapter explains how to plan and configure a RAS server, defines TCP/IP and explains how to install it, and shows you how to use RAS and TCP/IP together.

These days, no computer or network is an island. As enterprises become more geographically dispersed, as users become more mobile, and as the Internet becomes a more compelling force in the computing world, the need to access remotely and interconnect networks steadily increases. Windows NT Server 4.0 addresses these needs with two powerful features—namely, Remote Access Service and the TCP/IP protocol.

In this chapter, I fill you in on how to plan and configure a RAS server. Then, I get into the important aspects of TCP/IP and walk you through its installation. Finally, I show you how to use RAS and TCP/IP together.

Cross Reference: There are lots of acronyms defined in this chapter. If you forget the meaning of an acronym, you’ll find it defined in the glossary in Appendix B.

UNDERSTANDING THE WORLD OF RAS

Microsoft’s Remote Access Service, or RAS allows a variety of clients to become nodes on your LAN via modem, ISDN, or X.25 connections. Once connected, they operate as equal citizens with all other nodes attached to the network and are able to access any and all resources allowed by their user account.

RAS Clients

Windows NT Server 4.0 RAS supports a variety of RAS clients, including non-Microsoft clients that conform to certain standards. In NT 4.0 and Windows 95, clients support a new feature called AutoDial, which makes connecting automatic. It remembers the connections that you’ve made over RAS and automatically reconnects you the next time you attempt to access that resource. (It can be a little jarring to click a drive letter in Explorer and suddenly hear the modem dialing, but it beats having to manually reconnect each time.) Table 5-1 presents the clients that can connect to a Windows NT 4.0 RAS server, along with the software required on the client. Recall that PPP stands for Point-to-Point Protocol, which is used by RAS to communicate between RAS clients and servers.

TABLE 5-1 CLIENTS SUPPORTED BY NT SERVER’S RAS
*Clients*	*Using RAS*
Windows NT 4.0	Built-in Microsoft RAS or PPP
Windows NT 3.51	Built-in Microsoft RAS or PPP
Windows NT 3.5	Built-in Microsoft RAS or PPP
Windows NT 3.1	Built-in Microsoft RAS (no PPP support)
Windows 95	Built-in Dial-Up Networking
Windows for Workgroups	Microsoft Network Client 3.0 (included with NT Server 4.0)
DOS 3.1 (or later)	RAS version 1.1a
Microsoft OS/2 1.3	RAS version 1.1
Non-Microsoft PPP client	PPP using TCP/IP, IPX/SPX, or NetBEUI

Modem Compatibility

Most of the hundreds of NT-compatible modems comply with industry standards and should interoperate with each other without a hitch. However, I’ve seen some difficult-to-diagnose problems arise from using a different modem on each end of the connection. The manufacturers have sometimes interpreted the “standards” in slightly different ways. Thus, if you have the luxury of selecting modems for your RAS computers, use the same type of modem on clients and servers. Doing this will remove one potential trouble spot.

RAS Server

RAS Server supports TCP/IP, IPX/SPX, and NetBEUI protocols. Any combination of protocols can be handled across the maximum 256 RAS clients, as long as the RAS server computer is running those protocols. As I show you later in this chapter, each protocol can be individually configured to access either just the RAS server or the entire network.

On the security front, RAS server includes password encryption during the authentication process, along with encryption, to maintain the security of your data in case someone is eavesdropping. In addition, you can configure RAS to call back specific users at a predetermined phone number before allowing them access to the network.

On top of all this, NT 4.0 RAS offers an exciting new feature called Point-to-Point Tunneling Protocol, or PPTP, which allows you to use the Internet as a secure WAN connection between your LANs. I show you how to set this up later in this chapter.

Preparing to Install RAS Server

Before you install RAS on your Windows NT Server computer, make sure that the computer already meets all of the following RAS communications hardware requirements. Check the Windows NT Hardware Compatibility List to determine whether these devices are compatible with Windows NT Server:

The computer must contain a Windows NT-compatible network adapter card with an NDIS driver.

Cross Reference: See Chapter 2 for details on selecting and installing network adapters.

If your RAS clients are using phone lines to connect, the computer must have one or more NT-compatible modems attached to an available serial port.

Tip: If you want acceptable performance from multiple modems attached to your RAS server, install an NT-compatible multiport serial card. Products like those offered from DigiBoard offer high-performance serial ports. Just over 15 cards have been certified compatible, and most of them are DigiBoards.

If your RAS clients are using ISDN lines to connect, the computer must include one or more NT-compatible ISDN adapters. You’ll also need a separate ISDN line installed for each ISDN adapter. (Just over a dozen ISDN adapters are listed as compatible.)
If your RAS clients are using X.25 connections, the computer must be equipped with an NT-compatible X.25 smart card. (There’s a handful of compatible X.25 cards.)

Tip: The default COM2 device interrupt (IRQ 3) has slightly higher priority than the COM1 (IRQ 4) interrupt. If you have two serial ports, use COM2 for your higher-speed serial device (such as a high-speed modem).

All of the RAS communications hardware just listed must be installed, configured, connected, and powered up before you install RAS. This will make installation proceed smoothly and prevent wasted effort. RAS sometimes leads you along until it suddenly discovers that you don’t have all of the required hardware installed properly.

Some modems not on the Windows NT Hardware Compatibility List may work with RAS. However, this is one area where I highly recommend that you stick with what’s on the list. Differences in modems are subtle, and the resulting problems are very difficult to solve. So, adhere to the NT Hardware Compatibility List as gospel in the modem area. (If you do, you’ll also avoid having to deal with the painful process of understanding and modifying RAS’s MODEMS.INF file, which is covered in the NT RAS online documentation.)

Installing RAS after NT Installation

I recommend performing your RAS server installation after you have Windows NT Server up and running. Here are the steps you need to follow if you’re installing RAS after installing Windows NT Server on your computer:

While logged on with administrator privileges, click the Start Settings Control Panel option. Double-click the Modems choice.
Follow the Modem Wizard through the modem detection process. When you’ve completed modem installation, you should see a Modem Properties dialog box, similar to the one in Figure 5-1.

Figure 5-1: Modem properties result from the modem detection and installation process.

While still logged on with administrator privileges, select the Start Settings Control Panel option. Double-click the Network entry to start the Network Control Panel Application (NCPA).
In the Network dialog box, click the Services tab. Then click Add.
Under Network Services, select the Remote Access Service option and click OK, as shown in Figure 5-2.

Figure 5-2: Select Remote Access Service for installation.

NCPA asks for the path to the system files on your Windows NT Server 4.0 CD-ROM. Insert the NT CD-ROM in your CD-ROM drive. Type the path and click Continue, as Figure 5-3 illustrates.

Figure 5-3: Type the path of your Windows NT Server CD-ROM files.

If RAS couldn’t detect your serial port, modem, or other RAS device, you’ll see the error message shown in Figure 5-4. If you see this message, click OK, then recheck the configuration and connection of your serial ports, modems, ISDN adapters, and so on. Then go back to step 1. If you don’t see this message, go to step 8.

Figure 5-4: If RAS can’t find your RAS hardware, you’ll see this message.

In the Add RAS Device dialog box, verify that your serial ports, modems, and other RAS devices are listed correctly. Then click OK, as shown in Figure 5-5.

Figure 5-5: Verify that your RAS devices have been correctly detected.

In the Remote Access Setup dialog box, select the Configure option to establish how the device will be used by RAS. See Figure 5-6.

Figure 5-6: Remote Access Setup allows you to configure the RAS device and network parameters.

In the Configure Port Usage dialog box under Port Usage, choose either the Dial out only, Receive calls only, or Dial out and Receive calls options. Then click OK, as shown in Figure 5-7.

Figure 5-7: Select the Remote Access Service port usage.

In the Remote Access Setup dialog box, select the Network option to configure network protocols used by RAS. Refer to Figure 5-6 (above).
In the Network Configuration dialog box, under Server Settings, click to set or clear the check boxes associated with the network protocols that you’re planning to run on RAS clients. See Figure 5-8.

Figure 5-8: Select and configure the protocols that your RAS clients will be running.

12a.

If you’ve selected NetBEUI, click the Configure entry next to NetBEUI. If you want to grant NetBEUI clients access to the RAS server only, and not to the entire network, select the This computer only option. Then click OK. Figure 5-9 illustrates this.

Figure 5-9: Grant or restrict network access to NetBEUI clients.

Otherwise, RAS clients running NetBEUI will have access to nodes on the network running the NetBEUI protocol. Grant access to the entire network, unless you have a specific reason for limiting access of these clients to just the RAS server.

12b.

If you’ve selected TCP/IP, select the Configure entry next to TCP/IP. If you want to grant TCP/IP clients access to the RAS server only, and not to the entire network, click the option for This computer only. If you want to control the range of IP addresses assigned to RAS clients, select the Use static address pool option. Then type the range of IP addresses that the RAS server can assign and any IP address ranges to exclude from automatic assignment. Click OK. Figure 5-10 illustrates this.

Figure 5-10: Grant or restrict network access to TCP/IP clients and configure TCP/IP addressing.

For a detailed explanation of IP addresses and Dynamic Host Configuration Protocol (DHCP), which automatically assigns them, see the appropriate sections later in this chapter.

Caution: If you’re using the Dynamic Host Configuration Protocol (DHCP) to assign IP addresses automatically, and you’re using a static IP address pool for RAS clients, you must be sure that DHCP won’t assign any addresses in the range that you specify for the RAS server. If they overlap, you’ll have duplicate IP addresses on your network. See the DHCP section later in this chapter for more details.

12c.

If you’ve selected IPX, click the Configure entry next to IPX. If you want to grant IPX clients access to the RAS server only, and not to the entire network, select the This computer only option, as shown in Figure 5-11 Then click OK.

Figure 5-11: Grant or restrict network access to IPX/SPX clients.

This dialog box also allows you to configure how network numbers are assigned. You can keep the default settings for now.

Cross Reference: See Chapter 6 for details on how to integrate the NT RAS server into a NetWare environment.

In the Network Configuration dialog box, click OK. In the Remote Access Setup dialog box, click Continue.
NCPA again asks for the path to the system files on your Windows NT Server 4.0 CD-ROM. Verify that the NT CD-ROM is in your CD-ROM drive. Type the path and click Continue.
Click Close. After configuration completes, restart your computer as prompted.
Start the Remote Access Admin utility by selecting the Start Programs Administrative Tools Remote Access Admin entry. See Figure 5-12

Figure 5-12: Use Remote Access Admin utility to complete configuration of your RAS server.

Cross Reference: See Chapter 12 for additional RAS troubleshooting tips and details about using Event Viewer.

On the Users menu, click the Permissions check box. In the Remote Access Permissions dialog box, select individual user accounts that will be used on RAS clients and configure their dial-in and callback permissions, as shown in Figure 5-13 When you’re done, click OK.

Figure 5-13: Set RAS permissions for each user account that will participate as a RAS client.

You’ve now completed configuration of the RAS server. You can use the Remote Access Admin utility in the future to manage RAS permissions. This utility has some additional features that you can learn about through the online Help.

Cross Reference: In Chapter 7, I discuss how to configure various types of client computers, including RAS clients.

Enabling PPTP

PPTP (Point-to-Point Tunneling Protocol) is a new feature in Windows NT Server 4.0 that allows you to create virtual private networks (VPNs) over the Internet. You can create a completely secure connection between remote client computers and your corporate network, running NetBEUI, TCP/IP, IPX, or any combination of these protocols. PPTP encapsulates and encrypts packets before sending them on the Internet. As a result, you can shift the burden of supporting modems or ISDN adapters to Internet Service Providers (ISPs) and can save money that you’d have spent on long-distance dial-in charges.

To use PPTP, you must enable it for each network adapter that will participate in PPTP connections. For a PPTP connection to succeed, both the RAS server and the client must have PPTP installed. Once you’ve installed PPTP on a specific network adapter, only PPTP packets will get through this network adapter to your computer. Other packets will be ignored. Thus, you’d typically want to have multiple network adapters in your server with the one dedicated to PPTP connected to the Internet. The remaining adapters should be connected to your corporate network. Client computers running PPTP can then gain access to your corporate network through the dedicated adapter in your server.

Before enabling PPTP, you need to have the TCP/IP protocol already installed. You can find detailed instructions for doing this later in this chapter. Once you have TCP/IP installed, here are the steps you must complete to enable PPTP on your server:

While logged on with administrator privileges, select the Start Settings Control Panel option. Double-click the Network entry to start the Network Control Panel Application (NCPA).
In the Network dialog box, click the Protocols tab. Select TCP/IP Protocol and click Properties.
In the Microsoft TCP/IP Properties dialog box, click the IP Address tab. Then click Advanced.
Select the adapter that you want to participate in PPTP connections and click the Enable PPTP Filtering checkbox. When you’re done, click OK.
In the Microsoft TCP/IP Properties dialog box, click OK.
Click Close and restart the computer as prompted.

UNDERSTANDING THE WORLD OF TCP/IP

If you’ve worked before with UNIX running the TCP/IP protocol suite, you know that TCP/IP has a world of concepts and terminology all its own. If you haven’t worked with it before, you’ll soon see that this is true. If you want to know everything there is to know about TCP/IP, you’d better start now and hope you live to a ripe old age. I won’t burden you with every detail—just the salient points that you need to install and administer TCP/IP in an NT or mixed network environment.

Note: If you’re really interested in the detailed meanings of TCP/IP components, you’ll find them defined in a series of RFC (Request for Comments) documents. On the Web, visit www.internic.net and follow the trail to the RFCs, which you can download via FTP.

In the TCP/IP world, all nodes connected to the network are called hosts, whether they’re servers, clients, or even network-connected printers. The original definition of host assumed only one network interface per computer, but computers today can contain multiple network adapters. So, each adapter is really considered a separate host. Thus, if your computer running Windows NT Server contains two network adapters, it’s really considered two hosts by TCP/IP.

Addressing Your Host

I’m about to dig into the nitty-gritty details of how hosts are addressed in TCP/IP. Do we really have to? Yes, and here’s why. First, you’ll be expected to shoulder the burden of responsibility for managing the TCP/IP addresses within your network. Second, Windows NT Server 4.0 provides some key features that make this whole addressing effort easier for you to manage. You’ll first need to understand TCP/IP addressing to make effective use of these features.

Every host on a TCP/IP network must have a unique 32-bit address, known as its IP address. The addressing scheme uniquely identifies a specific network adapter in a specific computer on a specific network. Can it be more specific? In theory, if each computer contained only one network adapter, the IP addressing scheme would allow unique identification of nearly four billion computers. If you think that’s plenty, you might be surprised to learn that folks are already working on ways to expand the addressing scheme to handle even more computers. (If you have anywhere near four billion computers within your own corporate network, your needs and problems are somewhat beyond the scope of this book.)

Since TCP/IP is the protocol of the Internet, if you hook your LAN to the Internet, every one of your hosts must have a unique address that differentiates it from all other hosts in the world. So, who is responsible for assigning these addresses and assuring they’re unique, and who in their right mind would want to do this? Well, this responsibility is shared. An organization called the Internet Network Information Center, or InterNIC, assigns unique network addresses. You, as network administrator, are then responsible for further assigning addresses to individual hosts within your own network.

Dissecting an IP Address

IP addresses are typically expressed as four decimal numbers separated by periods, representing the four bytes of the 32-bit address (for example, 129.37.15.6). This is called dotted-decimal notation. The IP address contains two pieces of information—namely the network address and the host address. The network address, which is the part assigned by InterNIC, uniquely identifies your network. The host address, which you assign, uniquely identifies a node within that network.

Note: If you pick up literature on TCP/IP, you’ll probably run across the term octet in the context of IP addresses. Just mentally translate this to mean “byte.” The term octet was used earlier, before computers standardized on an 8-bit byte. For some reason, the term has attached itself like a leech to IP address discussions and won’t let go. I won’t use the octet term again in this book.

Get Your Own Address

If you know that you’ll never connect your network to the Internet or to any other TCP/IP network, you can get away with assigning your own network address without any involvement from InterNIC. However, I strongly advise against doing this. Few organizations today want to isolate themselves from the Internet. If you decide in the future to connect your network to it, you’ll have to reassign IP addresses to your network. You’re much better off getting a legitimate network address from InterNIC up front and using it from the start. InterNIC can be reached via e-mail at hostmaster@internic.net, by phone in the U.S. at 1-800-862-0677, or by phone outside the U.S. at 703-742-4777. InterNIC also maintains a very informative Web site at http://rs.internic.net/rs.internic.html. InterNIC may refer you to an ISP (Internet Service Provider) to obtain your new network address from them. You may have to pay a fee for obtaining a network address, depending on your ISP.

There are three ways that the bytes of the IP address are sliced to create the network and host addresses. The Internet community has created different classes of IP addresses, designed to accommodate different network sizes. Table 5-2 presents these classes. In the table, I’ve used the notation a.b.c.d to represent the dotted-decimal notation for the four bytes of an IP address.

As Table 5-2 shows, relatively few Class A addresses are available, but each Class A network can accommodate over 16 million nodes. Class B and C addresses are much more common, with fewer nodes per network available in each class. When requesting a network address, make sure that the class you request will accommodate your network now and in the future.

TABLE 5-2 CLASSES OF IP ADDRESSES
*Class*	*Network Address*	*Host Address*	*Total Number of Networks*	*Total Number of Hosts per Network*
A	a (1 byte)	b.c.d (3 bytes)	126	16,777,214
B	a.b (2 bytes)	c.d (2 bytes)	16,384	65,534
C	a.b.c (3 bytes)	d (1 bytes)	2,097,151	254

Caution: Never assign the values 0, 1, or 255 to any byte of an IP address. These values are reserved internally for broadcast and other purposes. If you use them in IP addresses, you’ll run into communication problems on your LAN. Some NT utilities prevent you from doing this, but others don’t.

Also, IP address 127.0.0.1 is reserved as a loopback address. If you send a packet to this address, it should get back to you unless there’s a network problem.

Looking Behind the Subnet Mask

Let’s say you’ve been assigned a Class B network address. However, your network is actually a WAN made up of several LANs scattered across the country, and each LAN has under 50 nodes. The number of LANs in your network will grow, but you know the number of nodes per LAN won’t ever go above 60. Rather than applying for a different network address for each of your LANs, you can break your block of IP addresses into smaller chunks, called subnets, one for each of your LANs.

In a Class B address, 16 bits are consumed by your assigned network address. The remaining 16 bits are meant for uniquely identifying hosts on your network. Since your individual LANs are never going to have more than 60 nodes each, you can allocate six bits for your individual host addresses and the remaining ten bits for your individual LAN network addresses (subnet addresses). In a sense, you’re further subdividing the block of IP addresses that you’ve been assigned to meet the specific needs of your network. You’re using the portion of the IP address intended for host identification to identify your LANs and nodes within those LANs.

Now, what’s the subnet mask, and how do you use it to accomplish this subdivision? A subnet mask looks almost like a four-byte IP address. For example, the standard subnet mask for a Class B network address is 255.255.0.0. The mask tells your nodes which part of the IP address is used for the network address and which part is the host address. The bits set to 1 in the subnet mask indicate which bits of the IP address make up the network address. The bits set to 0 in the mask indicate which bits of the IP address constitute the host address. Figure 5-14 illustrates this approach, using our example.

Figure 5-14: A subnet mask further subdivides the block of IP addresses that you’ve been assigned.

You can’t get away with an empty subnet mask. The default subnet mask for a Class B address is 255.255.0.0, since the first 16 bits are used for the network addresses, and the remaining 16 bits are used for the host address. So, a Class B address of 129.37.15.6 with a subnet mask of 255.255.0.0 tells you that 129.37 is the network address and 15.6 is the host address on that network. Likewise, the default subnet mask for a Class A address is 255.0.0.0 and the Class C default mask is 255.255.255.0.

In our example, only the last six bits of the subnet mask are set to zero, since you’re only using six bits for the host address. All of the remaining bits in the subnet mask are set to one. Thus, the subnet mask in this situation is 255.255.255.192, as shown in Figure 5-14 (above).

Caution: All nodes on your subnet must use the same subnet mask, the same network address, and a unique host address. Otherwise, you’ll definitely run into problems communicating among computers running TCP/IP on your network.

Routing Through the Gateway

Networks running TCP/IP are connected by routers. A TCP/IP router, which has its own IP address just like any other node on the network, passes IP packets from one network to another. Although it’s theoretically possible to maintain information resident on each host that tells it how to reach all other hosts on earth, this is clearly not practical. Instead, one host is given the responsibility of being the default gateway. A default gateway is attached to each network and knows how to get to all other networks. Once a packet has reached the right network, it can easily find its way to the right host.

Tip: If the default gateway attached to your LAN goes down, all TCP/IP communication outside the LAN is cut off. You can make your internetwork more fault tolerant by setting up multiple servers as default gateways and specifying their IP addresses in the Network Control Panel Application. After you’ve installed TCP/IP, click Advanced on the IP Address tab on the TCP/IP Properties dialog box. Under Gateways, click Add.

If you have only one LAN, and it’s not connected to any other LANs, you don’t have to worry about specifying a default gateway. However, if you’re connected to the Internet or you have multiple subnets in your network, you’ll have to specify a default gateway IP address for each subnet.

Dynamic Host Configuration Protocol

Wouldn’t it be great if IP addresses could be automatically assigned within your network, freeing you of keeping track of every host address? Windows NT Server provides a service called DHCP, which stands for Dynamic Host Configuration Protocol. You can install this service when you install TCP/IP on the server. Once installed, DHCP will automatically assign IP addresses to TCP/IP client computers whenever they start up. There’s no need to keep a static list of address assignments, since DHCP dynamically selects addresses from a pool that you specify.

You’ll have to configure the DHCP server itself manually, since it needs to know the range of available addresses and since it can’t dynamically assign an IP address to itself. You specify the range or pool of IP addresses that the DHCP server can use to assign to other TCP/IP nodes in the network. This address range is called a DHCP scope.

Tip: Use the DHCP approach on your NT server, unless you really enjoy manually updating files with a text editor and paying a visit to every computer on your network to set its IP address correctly. I know there are some people who really enjoy this sort of thing, so the manual approach is still there for those two people.

Windows NT Server includes a version of the TCP/IP protocol stack for Windows for Workgroups that can be dynamically configured by a Windows NT server running DHCP. The NT DHCP server service is compatible with other products that comply with the RFCs defining the DHCP protocol.

Cross Reference: I show you how to install and configure network clients in Chapter 7.

If you use DHCP, I recommend that you use the WINS feature of Windows NT Server to perform dynamic translation of computer names to IP addresses. WINS works closely with DHCP to keep these translations up to date at all times. I discuss setting up a WINS server later in this chapter.

Caution: The routers in your network must support RFCs 1532, 1533, 1541, and 1542. They specify how to handle forwarding DHCP packets across the router. If your routers don’t support these RFCs, the DHCP packets will be dropped by the router. On some routers, routing of these packets is a configuration option. Contact your router vendor for information on how to configure or upgrade your router software to handle these packets.

What if you have TCP/IP nodes on your network that don’t know how to work with DHCP? And what if you have nodes, like TCP/IP routers, that require fixed IP addresses? Using NT’s DHCP Manager utility, you can handle all of these situations by telling DHCP which addresses are static, which addresses not to dole out to other nodes, and so forth. Although dealing with these exception cases does take some effort on your part, DHCP can handle assignment of IP addresses automatically for the majority of TCP/IP nodes in your network.

Tip: You can avoid annoying pop-up error messages and network communication problems by installing the DHCP server before you install TCP/IP on any other computers that are running Windows for Workgroups or Windows NT. That way, all of the remaining computers can ask the DHCP server for an IP address while you’re installing NT on them.

Leasing an Address The DHCP server actually leases IP addresses to nodes for a fixed period of time, similar to how auto dealers lease cars. The lease must be renewed on a set schedule. If it isn’t renewed, DHCP repossesses the IP address for use on some other network node. For example, if a computer that was assigned an IP address by DHCP is shut down for a week and the lease expires during that time, DHCP may reuse that address for a different computer. When the first computer is powered back up, DHCP will assign it a new IP address.

You can control the length of the DHCP server’s lease period using DHCP Manager. Here are a few guidelines for picking the right lease length:

If you make frequent and drastic changes to your network structure (such as moving computers from one subnet to another), consider setting the lease period to less than a week.
If you have many portable laptop computers on your network, and they’re removed from the network frequently or are moved from one part of your network to another, opt for a shorter lease period (for example, under a week).
If the demand for IP addresses is high on your network (or the supply of available addresses is low), opt for a short lease period. For example, if you have only 254 available IP addresses and you have nearly as many users, the demand for IP addresses is high.
If the structure of your network is fairly stable and moving computers around is rare, consider setting the lease period to a month.

A Host by Any Other Name

If you’re like most humans, you probably prefer to address computers by name rather than by IP address. Your users probably feel the same way. If you’re running DHCP to assign IP addresses dynamically, the computer name becomes the only consistent way of referring to a particular node on your network.

The activity of translating between computer names and IP addresses is called name resolution. Several methods have been implemented over the years to perform this translation automatically. The earliest solution involves the use of simple text files. Each computer has a copy of a file containing a one-line translation for each host address on the network. This approach can work for very small networks but breaks down quickly in large networks that change frequently. Keeping all of the copies of the text file up to date on every computer can become a nightmare. Windows NT Server supports two text file approaches, discussed later in this chapter.

More modern approaches to name resolution centralize the required mapping information on one or more servers, removing the need for a mapping file on every computer. These server methods predominate today, but the text file methods still exist to support older TCP/IP implementations and to act as a backup mechanism if the name resolution servers fail.

An Internet address consists of two components—namely, a host name and a domain name. (Unfortunately, this domain name isn’t the same as an NT Server domain name. Yet another overloaded term.) The host name is the name of your computer, which is typically the computer name that you assigned when you installed the operating system. The domain name is typically the name of an organization followed by the type of organization. The organization type is called a domain extension, which is similar to a file extension. Table 5-3 presents the domain extensions in use today on the Internet. Microsoft’s domain name is microsoft.com, where microsoft is the organization name and .com is the domain extension–in this case, a commercial organization.

The domain name structure of the Internet is really organized as a hierarchical tree. The root of the tree is unnamed. The top-level domain names consist of organization types (as shown in Table 5-3) and geographical country codes. Although a U.S. country domain exists, most domains in the U.S. are organized under the organizational types. The second-level domain names are those assigned to specific organizations such as Microsoft, Adobe, or CMU. Figure 5-15 illustrates this tree structure.

TABLE 5-3 DOMAIN EXTENSIONS AND THEIR ORGANIZATION TYPES
*Domain Extensions*	*Organization Type*
.com	Commercial enterprises
.edu	Educational institutions
.gov	Government organizations
.mil	Military organizations
.net	Network support organizations
.org	Organizations that don’t fall into the above categories

The domain name and the host name combine to generate a Fully Qualified Domain Name, or FQDN, for the computer. (You just don’t see many Qs in acronyms anymore, do you?) Using the tree illustrated in Figure 5-15, the FQDN of the sales computer is sales.mycomp.com.

Figure 5-15: Domain names are organized into a hierarchical tree structure.

Microsoft WINS No, this isn’t a prediction about how Microsoft will do in the operating system race. WINS stands for Windows Internet Name Service. WINS automatically performs name resolution by translating between computer names and their associated IP addresses. It’s the easiest, most recommended method for name resolution on a Windows NT server network. In most configurations, WINS is faster and more reliable than other approaches.

You establish a WINS server by running the WINS service on any Windows NT Server computer that’s running TCP/IP. To assure availability of the service, you can establish backup WINS servers. WINS dynamically maintains a database of TCP/IP addresses and their associated computer names. It works hand-in-hand with DHCP to keep this database current. In fact, handling name resolution on a network using DHCP is almost impossible without a WINS server in the picture to sort everything out. Whatever other name resolution methods that you install, I recommend that you include WINS servers in your TCP/IP network.

Tip: Servers running WINS need to have fixed IP addresses. They shouldn’t look to DHCP for obtaining their addresses dynamically. Since DHCP servers have the same requirement, I recommend that you install your primary WINS server on the same Windows NT Server computer that’s running the DHCP server.

At a minimum, establish one WINS server and one backup WINS server for every 10,000 client computers. Establishing additional WINS servers in your network will provide more fault tolerance and load balancing.

Domain Name System DNS, which stands for Domain Name System, is a standard TCP/IP utility used for name resolution on the Internet. It implements a distributed database of mappings between host names and IP addresses. Unlike WINS, DNS is a static database that requires manual updating when changes are made to the network. Like WINS, you can establish backup DNS servers to balance the load and provide a degree of fault tolerance. In contrast to WINS, which maps computer names to IP addresses, DNS translates between FQDNs and IP addresses.

If you’re connecting your network to the Internet, and your network is small, you’ll probably get the address of an existing DNS server from your ISP. If your network is large, you may want to establish your own DNS servers. However, be prepared for significant manual configuration in setting up a DNS server.

I recommend using DNS if you’re operating in a network with computers running UNIX or if you’re attached to the Internet (which implies communicating with UNIX computers). DNS will provide the additional name resolution that you need for Internet domain and host names.

Putting DNS and WINS Together DNS doesn’t dynamically update its database as WINS does. By using DNS and WINS together, you can get the best of both worlds. A Windows NT Server computer that’s set up to serve as both a DNS and a WINS server must not be configured to use DNS for Windows name resolution. When you configure TCP/IP, make sure the Enable DNS for Windows Resolution checkbox is clear on the WINS Address tab in the Microsoft TCP/IP Properties dialog box.

HOSTS and LMHOSTS Computers located on LANs that don’t use WINS need to use static text files for name resolution. As mentioned earlier, these methods were developed before DNS and WINS were developed and represent the fallback position for subnets that don’t support WINS or that don’t have a working WINS server.

Tip: Since it’s so easy for these files to get out of date, I recommend that you identify one computer that holds the master text files, make all changes on that computer, and then propagate copies of the master files to all other nodes on the network. If you start editing independent copies of these files on various network nodes, the situation will quickly get out-of-hand, especially on a large network.

The most primitive form of this mapping text file is called HOSTS. It’s equivalent to having a local DNS. The HOSTS file simply contains a list of IP addresses and their associated host names. Once you’ve installed TCP/IP, you can find a sample HOSTS file in \SystemRoot\SYSTEM32\DRIVERS\ETC\HOSTS. Use a text editor (such as Notepad) to add a host address and name for each TCP/IP computer with which you need to communicate.

Note: If you’re familiar with BSD UNIX 4.3, the Windows NT Server HOSTS file format is identical to the /etc/hosts file. The file serves the same function, but it must reside in the \SystemRoot\SYSTEM32\DRIVERS\ETC directory on Windows NT computers.

Translations between computer names and IP addresses can be accomplished using the LMHOSTS file. It’s equivalent to having a local WINS server. The LMHOSTS file contains a list of IP addresses and their associated host names. Unlike the HOSTS file, LMHOSTS also allows several special directives. Once you’ve installed TCP/IP, you can find a sample LMHOSTS file in \SystemRoot\SYSTEM32\DRIVERS\ ETC\LMHOSTS.SAM. Copy the LHMOSTS.SAM file to LMHOSTS before editing it to add host names and addresses.

Note: If you’re familiar with the LAN Manager 2.x TCP/IP LMHOSTS file, the Windows NT Server LMHOSTS file format is fully compatible with it. The file serves the same function and uses exactly the same syntax. On NT, it must reside in the SystemRoot\SYSTEM32\DRIVERS\ETC directory.

Installing TCP/IP during NT Installation

If you want to install the TCP/IP protocol while you’re installing Windows NT Server, follow the steps outlined here. If you’ve already installed NT Server and you want to add the TCP/IP protocol to it, go to the next section for step-by-step instructions:

Setup asks if you’re going to use a DHCP server for IP addressing, as shown in Figure 5-16. If you want an existing DHCP server to automatically assign IP addresses to this computer, click Yes. If you want to manually configure this computer’s IP address, click No.

Figure 5-16: Select either automatic DHCP IP address assignment or manual configuration of this computer.

In the Microsoft TCP/IP Properties dialog box, click the IP Address tab.
Type the IP address and subnet mask in the appropriate fields. If you need to specify a default gateway, type its IP address in the appropriate field. Then click OK. See Figure 5-17.

Figure 5-17: Set the node IP address, subnet mask,and default gateway.

Figure 5-18

Figure 5-18: Use Advanced IP Addressing to specify addresses for multiple adapters and multiple default gateways.

If you know the IP address of your primary WINS server, click the WINS Address tab. Type the WINS server IP address and click OK, as shown in Figure 5-19.

Figure 5-19: If you’re using WINS, specify the IP addresses of primary and secondary WINS servers.

You can also specify a secondary WINS server IP address, if you have one. If the computer you’re currently configuring is intended to be a WINS server, you can skip this step completely.

If you don’t specify a WINS address, Setup will warn you that no WINS address was specified. If you get this warning, click Yes to specify a WINS address or No if you want to continue without one.

Note: Specifying TCP/IP during NT installation causes the DHCP Relay Agent to be installed by default. If you don’t specify an existing DHCP server IP address, Setup will warn you and won’t install the DHCP relay service. If there’s an existing DHCP server on your network and you know its address, you can specify it when prompted by Setup.

Installing TCP/IP after NT Installation

Here are the steps you need to follow if you’re installing the TCP/IP protocol suite after installing Windows NT Server on your computer:

While logged on with administrator privileges, select the Start Settings Control Panel option. Double-click the Network entry to start the Network Control Panel Application (NCPA).
In the Network dialog box, click the Protocols tab. Then click Add.
Under Network Protocol, choose TCP/IP Protocol and click OK, as shown in Figure 5-20.

Figure 5-20: Select the TCP/IP protocol for installation.

NCPA asks if you’re going to use a DHCP server for IP addressing, as shown earlier in Figure 5-16. If you want an existing DHCP server to assign IP addresses to this computer automatically, click Yes. If you want to configure this computer’s IP address manually, click No.
NCPA asks for the path to the system files on your Windows NT Server 4.0 CD-ROM. Insert the NT CD-ROM in your CD-ROM drive. Type the path and click Continue.
In the Network dialog box, click Close. After a few moments, NCPA displays the Microsoft TCP/IP Properties dialog box.
In the Microsoft TCP/IP Properties dialog box, click the IP Address tab.
Type the IP address and subnet mask in the appropriate fields. If you need to specify a default gateway, type its IP address in the appropriate field. Figure 5-17 illustrates this procedure.

Figure 5-18

If you know the IP address of your primary WINS server, click the WINS Address tab. Type the WINS server IP address and click OK, as shown earlier in Figure 5-19.
In the Microsoft TCP/IP Properties dialog box, click OK.
Click Close and restart the computer as prompted.
Verify that TCP/IP is running by opening a Command Prompt and typing PING followed by the IP address of this node. Press ENTER.
If you have another computer on the network already running TCP/IP, go to that computer and type PING followed by the IP address of the node that you just configured. Press ENTER.

Establishing a DHCP Server

Once you’ve installed Windows NT Server, you can set it up as a DHCP server. I highly recommend installing the DHCP server on your first Windows NT server that uses TCP/IP. Doing this will make subsequent TCP/IP installations go more smoothly. The DHCP server will be able to assign IP addresses to the new computers when they come up.

Here are the steps required to establish the DHCP server on a computer running Windows NT Server:

While logged on with administrator privileges, choose the Start Settings Control Panel option. Double-click the Network entry to start the Network Control Panel Application (NCPA).
In the Network dialog box, click the Services tab. Then click Add.
Under Network Service, select Microsoft DHCP Server and click OK, as shown in Figure 5-21.

Figure 5-21: Select the DHCP server for installation.

NCPA asks for the path to the system files on your Windows NT Server 4.0 CD-ROM. Insert the NT CD-ROM in your CD-ROM drive. Type the path and click Continue.
NCPA warns that you need to configure all network adapters in this computer with fixed IP addresses, as shown in Figure 5-22. Click OK.

Figure 5-22: You’ll have to configure the IP addresses manually for the DHCP server.

Microsoft DHCP Server appears in the list of network services. Click Close.
Restart the computer as prompted.
Start the DHCP Manager utility by selecting the Start Programs Administrative Tools DHCP Manager option. See Figure 5-23.

Figure 5-23: Use the DHCP Manager to complete configuration of your DHCP server.

On the Server menu, click Add. Type the IP address of the DHCP server that you’re configuring and click OK, as shown in Figure 5-24.

Figure 5-24: Add the IP address of your DHCP server.

On the Scope menu, click Create. Under IP Address Pool, specify the range of IP addresses that this server can assign, the subnet mask for your network, and any IP address ranges to exclude from automatic assignment. Figure 5-25 shows this.

Figure 5-25: Create a scope for your DHCP server to manage.

Caution: Be sure that your DHCP server’s own IP address doesn’t fall within the range of addresses it can hand out to other computers. If the range that you specify includes the DHCP server’s address, you must explicitly exclude it in the list of excluded addresses. This rule applies to all DHCP servers on your network. DHCP Manager won’t warn you if you include the server’s address in the pool of assignable addresses.

Under Lease Duration, specify how long an address remains valid for a node. The default is three days.

Caution: Even though NT gives you the option of setting an unlimited lease period, don’t do it. As changes occur on your network or while computers are shut down for long periods, the DHCP server will eventually run out of IP addresses to dole out. Unlimited leases make sense only if your computers remain up continuously and you don’t make any changes to your network configuration over time. Even then, you should opt for a long lease period (such as six months) rather than an unlimited lease.

You can type an optional Name and Comment to describe the scope that you’re creating. Then click OK.
If the information that you’ve entered appears to be valid, DHCP Manager will ask if you want to activate the scope that you’ve created. Click Yes. If there are errors in the address information, you’ll be prompted to correct them. After you do so, click OK.

Tip: If you ever want to alter the configuration of a DHCP scope, go to the Scope menu in DHCP Manager and click Properties. You’ll then be able to edit all of the information that you entered when you created the scope.

There are many other DHCP options available. Once you have your DHCP server up and running, you can explore these other options using the online Help provided in DHCP Manager.

Tip: DHCP Manager lets you do just about everything except start or stop the DHCP server. To do this, you can use the Control Panel Services application or type commands at a Command Prompt. NET STOP DHCPSERVER will stop the service, and NET START DHCPSERVER will start it.

Establishing a WINS Server

Once you’ve installed Windows NT server, you can set it up as a WINS server. I highly recommend installing the WINS service on at least one of your Windows NT Server computers, if you’re running TCP/IP. Since the WINS server must be assigned a fixed IP address, it’s convenient to install it on the same server that’s running DHCP.

Here are the steps to follow to establish the WINS server on a computer running Windows NT Server:

While logged on with administrator privileges, select the Start Settings Control Panel option. Double-click the Network entry to start the Network Control Panel Application (NCPA).
In the Network dialog box, click the Services tab. Then click Add.
Under Network Service, select the Windows Internet Name Service option and click OK, as shown in Figure 5-26.

Figure 5-26: Select the WINS service for installation.

NCPA asks for the path to the system files on your Windows NT Server 4.0 CD-ROM. Insert the NT CD-ROM in your CD-ROM drive. Type the path and click Continue.
Windows Internet Name Service appears in the list of network services. Click Close.
Restart the computer as prompted.
Start the WINS Manager utility by selecting the Start Programs Administrative Tools WINS Manager option. See Figure 5-27.

Figure 5-27: Use the WINS Manager to complete configuration of your WINS server.

If you have other WINS servers on your network, click Replication Partners on the Server menu. Add other WINS servers to the list of partners, and specify both Push Partner and Pull Partner under Replication Options. See Figure 5-28.

Figure 5-28: Establish push/pull replication partnerships with other WINS servers.

Figure 5-29

Table 5-4

TABLE 5-4 RECOMMENDED WINS REPLICATION INTERVALS
*Link between WINS Servers*	*Recommended Replication Interval*
LAN connection	15 minutes