|
12
DHCP and WINS
When many people hear the acronyms DHCP and WINS, they immediately think of Microsoft. Although Microsoft was the first to introduce products based on these proposed Internet standards, they are by no means proprietary, nor are their uses completely limited to the Windows environments. DNS on the other hand, has long held a place of reverence in the world of TCP/IP.
DHCP and WINS are closely related services in the Microsoft TCP/IP networking world. Therefore, we discuss them first. Then we discuss the DNS server service in Windows NT Server 4.0 and how it is integrated with the WINS server to provide dynamic DNS.
The Windows Internet Naming Service (WINS) and Dynamic Host Configuration Protocol (DHCP) are client/server services, which means that there is at least one server-based service that provides information to clients on the network. Microsoft introduced its first WINS and DHCP servers in 1994 with Windows NT Server 3.5. Of course, both Windows NT Server and NT Workstation are also capable of being WINS and DHCP clients. Windows 95, Windows for Workgroups 3.11 with the Microsoft 32-bit TCP/IP stack (also known as Wolverine), and Windows 3.1 and DOS using the Microsoft Network Client 3.0 or LAN Manager client 2.2c can also act as DHCP/WINS clients.
So far, this list only contains Microsoft products, but there's more. The new networking stack on Macintosh computers, called OpenTransport, supports DHCP; and so do the newer TCP/IP-equipped Apple printers. In addition, many third-party TCP/IP stacks for the Windows/DOS environment, such as FTP Software's PC-TCP, support DHCP and WINS. Also many UNIX systems, such as HP’s HP/UX and SGI’s IRIX, also support DHCP.
Well, that's great, but what are WINS and DHCP for? To put it simply, DHCP is for dynamically assigning TCP/IP configuration information to network clients, and WINS is used to register and resolve names for NetBIOS clients on TCP/IP. This is very simplified, because in fact, there are many additional benefits to each service. There are also times when it is useful to install one service and not the other, as well as times when installing both services provides the best solution. In this chapter, we'll look more closely at the uses of each service, as well as deployment recommendations.
NOTE:Microsoft first provided a DNS service with the Windows NT 3.5 Resource Kit utilities. However, it was difficult to configure, not very robust, and considered to be unstable. The DNS server that ships with NT Server 4.0 is a complete rewrite and is designed to handle large loads. It is also much easier to configure, thanks to the new graphical DNS Manager utility.
The DNS Server included with NT Server 4.0 permits your NT Server to act as a standard domain naming system (DNS) server for resolving hostnames to IP addresses. Although this is often the most-used feature of a DNS server, there are other uses, such as reverse name resolution, in which a client can request the hostname that belongs to a particular IP address, as well as mail exchange information, which provides the location of mail hosts for machines listed in the DNS domain. Windows NT Server's DNS server supports all these standard DNS services. One unique feature of the Microsoft DNS server is the integration of DNS and WINS. It does this by providing a built-in interface that enables the DNS server service to look up names in a WINS database. It can then use this information to provide name-to-IP resolution.
The goal of this chapter is to provide you with an understanding of these services so that you can properly implement the DHCP and WINS services on your network. This chapter discusses design goals, installation, configuration, and management of these services; this covers most of the administrative issues. Specific discussions regarding interoperability with existing UNIX services, tips to get the maximum mileage from these services, and some of the possible problems (gotchas) to avoid also are discussed.
The Dynamic Host Configuration Protocol
The Dynamic Host Configuration Protocol (DHCP) is not a completely new development. It is actually an extension to the BOOTP protocol (originally defined in RFC 951), which had been the standard for assigning dynamic IP addresses and remote-booting diskless workstations. Contrary to popular fiction, DHCP was not officially designed by Microsoft but rather by a group under the auspices of the Internet Engineering Task Force (IETF). Although Microsoft was a major instigating force behind DHCP, there was a general agreement in the Internet community that a sophisticated method of dynamic IP allocation was necessary. Not only would such a service simplify the initial configuration of client computers, but it would dramatically reduce the administrative overhead necessary for maintaining the IP addresses and related information, such as subnet mask and default gateways. These were but some of the thoughts that brought DHCP into existence. DHCP is fully defined in the following Requests for Comments (RFC):
- RFC 1533: DHCP Options and BOOTP Vendor Extensions
- RFC 1534: Interoperation between DHCP and BOOTP
- RFC 1541: Dynamic Host Configuration Protocol (DHCP)
- RFC 1542: Clarifications and Extensions for Bootstrap Protocol
NOTE:The most interesting of these is RFC 1541, which defines the core structure and functionality of DHCP. This document can be obtained from ftp://ds.internic.net/rfc/rfc1541.txt.
Because DHCP is a client/server system, to have a fully functioning system, you must have at least one machine running the DHCP server service, and one machine with a DHCP-capable TCP/IP stack. In most scenarios, including our discussion here, the DHCP server will be a Windows NT Server with its built-in DHCP server service.
NOTE:The number of available DHCP server services is growing fairly quickly. Many third-party TCP/IP product vendors are developing DHCP server software for Windows NT, Windows 3.x, Novell, and even UNIX systems.
This discussion of the DHCP service begins with some of the design goals of the service and then moves on to planning your installation, installing the service, and using the DHCP Manager to administer the DHCP service. Administering your DHCP service consists of creating or deleting scopes and configuring individual scope properties. A scope is nothing more than a collection of IP addresses grouped into a single component for ease of administration. A scope can include all the IP addresses in a single subnet if desired, or you can subdivide a subnet into multiple scopes. Finally, this section looks at the DHCP database management required from time to time to improve performance. You also will learn about some of the Registry keys that cannot be configured directly using the DHCP Manager.
Looking at Design Goals for the Microsoft DHCP Protocol
All companies have definite goals they must reach prior to releasing their products into the market. And Microsoft had definite goals in mind for implementing DHCP for its operating systems. The primary concern was making administration of a TCP/IP-based network easier to implement and maintain, which incidentally makes it easier for the Microsoft Product Service Support (PSS) technical support groups as well, because TCP/IP is one of the most widely implemented protocols. The TCP/IP protocol is recommended for medium to large local area networks, it is the preferred protocol to use for wide area networks, and it is required for integration with a UNIX network or the Internet.
Some of the goals for the Microsoft DHCP implementation follow:
- Centralized administration of your TCP/IP IP subnets. All your IP addresses, along with the configuration parameters for each, are stored in a central database located on your DHCP server.
- Automatic TCP/IP IP address assignment and configuration. As a client computer starts up and accesses the network for the first time, it is automatically assigned an IP address, subnet mask, default gateway, and WINS server IP address. If the client computer then moves between subnets, such as a portable computer user, the original IP address and related configuration information are released back to the original pool of available IP addresses, and the client is assigned a new IP address and related configuration information at system startup.
- The return of unused IP addresses to the available pool of IP addresses. Normally, IP addresses are allocated statically by a network Administrator, and these IP addresses are stored on a piece of paper or a local database. But often this list can become out of date as clients move between subnets or new IP addresses are allocated without updating the list of IP addresses. This means that some IP addresses will be lost, so they cannot be reused. DHCP uses a time-based mechanism, called a lease, which a client must renew at regular intervals. If the lease expires and the client does not renew it, the IP address is returned to the pool of available IP addresses.
Understanding How a DHCP Lease Works
Leases are fundamental to the entire DHCP process. Every IP address offered by a DHCP server has an associated lease period. "Lease" is an accurate term, because the DHCP server is not giving the IP address to the client, but rather is allowing the client to use the information for a specified period of time. Also, the server or the client can terminate the lease at any time.
Because one of the goals of DHCP is to provide dynamic IP addresses, there must be a method of returning these addresses to the address pool, also called a scope. The lease period is defined independently for each scope. Lease periods can be anywhere from a few minutes to a few months to forever. Different lease periods are useful in different scenarios, and there is no single lease period that fits all needs. However, I don't recommend that you use unlimited lease periods, even if you are using DHCP to statically assign your IP addresses. Make the lease periods a few months long instead.
A DHCP client computer steps through one of six transition states in the process of establishing a valid IP address for use by the client computer:
- Initializing: When the TCP/IP stack on the client is started, it binds with an address of 0.0.0.0, since every machine on an IP network needs an address. It then sends out a DHCP Discover packet to its local subnet. This is a broadcast packet to UDP port 67, which is the DHCP/BOOTP server port.
- Selecting: Every DHCP server on the local subnet receives the DHCP Discover packet. Each DHCP server that receives the request checks to see if it has a valid free address for the requesting client. It then responds with a DHCP Offer packet containing the valid IP address, subnet mask, IP address of the DHCP server, lease duration, and any other configuration details specified for the DHCP scope. All servers that send a DHCP Offer reserve the IP address they offered. This address cannot be assigned to another client until it is unreserved. DHCP Offer packets are broadcast to UDP port 68, which is the DHCP/BOOTP client port. The response must be sent by broadcast, because the client does not have an IP address, which is required for it to be directly addressed.
- Requesting: The client usually selects the first offer to come in and responds by broadcasting a DHCP Request packet. This packet tells the server "yes, I want you to service me. I accept the DHCP lease you are giving me." Also, since it is broadcast, all the DHCP servers on the network see it. Any other DHCP server that made an offer which the client did not accept returns the reserved IP address to its pool of available addresses. The client also can use the DHCP Request to ask for additional configuration options from the server, such as DNS or gateway addresses.
- Bound: When the server receives the DHCP Request packet, it responds to the client with a DHCP Acknowledge packet, which provides any additional information the client might have requested. This packet is also sent by broadcast. It essentially says "Okay. Just remember you are only leasing this and you can’t keep it forever! Oh, and here’s the other information you requested." Okay, so it’s not really quite so polite!
- Renewing: When a client notices that its lease is 50% up, it tries to renew the lease. It does this by sending a directed UDP packet to the server it got its original information from. This packet is a DHCP Request, which asks if it can keep the TCP/IP configuration information and renew its lease. If the server is available, it would normally agree to the request by sending a DHCP Acknowledge packet back to the client.
- Rebinding: When the lease reaches approximately 87.5 percent of its expiration time, the client attempts to renew the lease once again—if it could not be renewed in the preceding attempt. If this fails, the client tries to contact any DHCP server to obtain a valid IP address. If another DHCP is able to assign a new IP address the client enters the bound state once again. If the lease on its current IP address expires, the client must give up the IP address and reenter the initializing state, at which point it repeats the entire process.
NOTE:When a DHCP client initially tries to acquire an IP address, only four network packets are exchanged across the network, DHCP Discover, DHCP Offer, DHCP Request, and DHCP Acknowledge. Each packet is less than 400 bytes. So you can see, the network overhead associated with DHCP is relatively small.
Planning Your DHCP Installation
If you have a small network in which all your TCP/IP hosts can take advantage of DHCP, then it will be fairly easy to install the DHCP Server. But this does not mean that you can just install the DHCP Server components and forget about it; it just means that there are fewer issues to contend with in your network installation. When you begin your planning, there are two types of network configurations to consider: The first is a simple network with only one subnet; and the second, is a network with multiple subnets. The most common configuration is one with multiple subnets, and that is the focus of this discussion.
A single subnet is the easiest to work with. All the DHCP and WINS servers are located on the same subnet, so very little maintenance is required. Maintaining the LMHOSTS files is not difficult unless you have many MS-DOS or Windows 3.x clients that use the Microsoft Network Client 3.0 software. Because these computers are all on a single subnet, you can use broadcast name resolution and bypass WINS configuration and LMHOSTS file maintenance all together. But it pays, in performance, to use the same techniques that will be described for your network just as if you did have multiple segments. It also pays off if your network grows and must be divided into separate segments.
For a multiple-segmented (subnets) network, you must do some planning before installing DHCP on your server and implementing DHCP on your clients. Some issues to consider follow:
- Routers: If you don’t plan on having a DHCP server on each subnet, your routers must support RFC 1542, commonly known as BOOTP/DHCP relay support. This means that the router can properly forward the DHCP packets from a subnet without a DHCP server to a remote subnet that can answer the DHCP request. For some older routers, this might require an upgrade. If your routers do not support this RFC, then your routers will discard the network packets required for DHCP operation. If your routers do support this RFC but you have connectivity problems, check your documentation to see whether the default configuration passes or drops these packet types.
TIP:If your routers do not support RFC 1542, you can use the DHCP Relay Agent included with NT Server. For more information on BOOTP/DHCP relay, see RFC 1542, which can be found at ftp://ds.internic.net/rfc/rfc1542.txt.
- WINS Configuration: If you are planning to use DHCP to configure your WINS clients automatically, set options 44 and 46 (these options are discussed in the "Working with DHCP Scopes" section later in this chapter). Option 44 specifies the WINS Server IP addresses to be assigned to the WINS client, whereas option 46 specifies the TCP/IP node type to be used. A node type specifies the mechanism the TCP/IP protocol uses to resolve NetBIOS name requests to a TCP/IP IP address.
Supported node types follow:
B-node (Broadcast mode): Resolves names using broadcast messages. This option is the worst possible one to use because it can flood your network segment with broadcast messages, lowering your network's capability to carry data over the network and effectively lowering your network bandwidth on the segment. Broadcasts also are not forwarded by routers, so if the requested resource is on the other side of a router, it will not be found. I recommend this type for a small network with a single subnet, one that does not have a dedicated network Administrator to maintain the network. (Using broadcasts can essentially eliminate the need to maintain an LMHOSTS file or WINS database, and for a small network, very little network bandwidth is eaten by the broadcasts.) Another good reason to use B-node is that computers located on the same segment still can find each other even if the WINS server or DNS server is down or unavailable.
P-node (Point-to-point mode): Resolves names with a NetBIOS name server (NBNS), such as WINS,) using point-to-point communications. Point-to-point communications are based on an IP-address-to-IP-address communication linkage. This is an efficient mechanism, but if the NBNS goes down, clients will be left without any method of locating other machines on the network.
M-node (Mixed mode): Uses B-node first (broadcasts) to resolve the name and then uses P-node (name queries) if the broadcast fails to resolve a name. This method works, but it has the same problem as a B-node because it can flood the network with broadcasts.
H-node (Hybrid mode): This is the default node type when configuring TCP/IP manually, unless the WINS IP address field is left empty. It uses P-node first (name queries) to resolve the name and then B-node (broadcasts) if the name service is unavailable or if the name is not registered in the WINS Server's database. I recommend this node type because it first uses a point-to-point connection to find a resource's IP address; it uses a broadcast to find the resource only if that fails. This is the most efficient node type to use, and it practically guarantees that the resource will be found even if the LMHOSTS file or WINS database does not contain the requested resource's IP address.
- Multiple DHCP Servers: If you are planning to implement multiple DHCP Servers, which is a good idea to distribute the load and provide redundancy on a large network, each DHCP Server must have a statically assigned IP address. These IP addresses must be excluded from the DHCP scope that you create. You do not necessarily have to have a DHCP Server on each subnet. Your router should be capable of forwarding DHCP requests across subnets, unless your router does not support the RFC mentioned previously, in which case you should update your router's firmware or use the DHCP Relay Agent that ships with NT Server 4.0.
- Static IP Addresses: Any static IP addresses—such as those used by other DHCP Servers, non-DHCP computers, routers, and non-Microsoft Remote Access Software (RAS) clients that do not support a dynamically assigned IP address and are using PPP (point-to-point protocol) to connect to your network—must be excluded from the DHCP scope. If you forget to exclude these IP addresses, an address conflict probably will occur and could prevent your clients from communicating or even cause your entire network to fail, such as in the case of a router.
- DHCP Server Database Replication: This feature doesn't exist in the current implementation, so if you install multiple DHCP Servers to support a single segment, you also must split the DHCP scope into distinct IP ranges.
- DHCP Server Database Backup: Because the DHCP database contains all the DHCP scopes for the server and the configuration parameters, it is a good idea to implement a backup policy. Normally, the DHCP service automatically keeps a backup copy of the database, and this backup is used if the original becomes corrupted. You should not rely on this mechanism as your only backup, however. Instead, back up the database regularly and then copy the files from the %SystemRoot%\System32\DHCP\Backup\Jet directory.
TIP:If you have a corrupted primary database file and this is not detected by the DHCP service, you can force the backup copy to be used by editing the Registry. Set the Registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DHCPServer\Parameters\RestoreFlag to 1. Then restart the DHCP service by using the following commands:
net stop dhcpserver
net start dhcpserver
- Lease Expiration: The minimum lease expiration should be twice the maximum expected server downtime. If you plan to upgrade the server over the weekend, for example, the expiration time should be at least four days. This prevents a client from losing its lease and IP address, which would prevent the computer from communicating with other resources on the network.
TIP:A good lease minimum should be based on your network turnaround. If you have many portable computer users, frequent computer upgrades, or many users passing between subnets, then you should have a lease time of about two weeks. This returns the unused IP addresses back to the pool, quickly making them available for reassignment. However, if you have a pretty static network, lease times of six months could be used. The one lease to avoid is an unlimited lease because these addresses will never be released automatically and returned to the IP address pool.
Another factor to consider in determining lease duration is the ratio of machines to IP addresses. For instance, if you have more machines on the network than IP address, you should consider using a much shorter lease duration, such as an hour or 30 minutes. This situation might occur if you connect your office to the Internet and have a limited number of IP addresses that must be shared among all machines on the network.
If you are planning to implement your Microsoft DHCP Server service in a mixed environment, such as with a third-party UNIX DHCP Server service, then you should be aware that not all the DHCP configuration options are supported by the Microsoft client. Specifically, the Microsoft DHCP clients only use the configuration options as specified in Table 12.1. Any other options received by the client are ignored and discarded.
Table 12.1. Microsoft DHCP client configuration options.
| Number | Name | Data Type | Description |
| 1 | Subnet Mask | Subnet Address | Specifies the TCP/IP subnet mask to be used by DHCP clients. NOTE:This value can be set only when you create a scope or when accessed from the DHCP Options | Scope Properties menu option. |
| 3 | Router | IP Address Array | Specifies a list, in order of preference, of router IP addresses to be used by the client. A locally defined gateway can override this value. |
| 6 | DNS Servers | IP Address | Array Specifies a list, in order of preference, for DNS name servers for the client. NOTE:A multihomed computer (a computer with more than one installed network adapter) can include only one IP address, not one IP address per adapter. |
| 15 | Domain Name | String | Specifies the DNS domain name the client should use for DNS hostname resolution. |
| 44 | WINS/NBNS | IPAddress Array | Specifies a list, in order of preference, of NetBIOS Name Servers (NBNS). |
| 46 | WINS/NBT Node Type | Byte | Specifies the node type for configurable NetBIOS clients (as defined in RFC 1001/1002). A value of 1 specifies B-node, 2 specifies P-node, 4 specifies M-node, and 8 specifies H-node. NOTE:On a multihomed computer, the node type is assigned to the computer as a whole—not to individual network adapters. |
| 47 | NetBIOS Scope ID | String | Specifies the scope ID for NetBIOS over TCP/IP (NBT) as defined in RFC 1001/1002. NOTE:On a multihomed computer, the scope ID is a global resource and is not allocated on a per-network adapter basis. |
| 50 | Requested Address | IP Address | Specifies that a client's preset IP address be used. |
| 51 | Lease Time | IP Address | Specifies the time, in seconds, from the initial IP address allocation to the expiration of the client lease on the IP address. NOTE:This value can be set only in the DHCP Options | Scope Properties menu option. |
| 53 | DHCP Message Type | Byte | Specifies the DHCP message type where the message type is 1 for DHCPDISCOVER, 2 for DHCPOFFER, 3 for DHCPREQUEST, 4 for DHCPDECLINE, 5 for DHCPACK, 6 for DHCPNAK, and 7 for DHCPRELEASE. |
| 54 | Server Identifier | IP Address | Used by DHCP clients to indicate which of several lease offers is being accepted by including this option in a DHCPREQUEST message with the IP address of the accepted DHCP Server. |
| 58 | Renewal (T1) Time Value | Long | Specifies the time, in seconds, from the initial IP address assignment to the time when the client must enter the renewal state. NOTE:This value cannot be specified manually because it is based on the lease time as set for the scope. |
| 59 | Rebinding (T2) Time Value | Long | Specifies the time in seconds from the initial IP address assignment to the time when the client must enter the rebinding state. NOTE:This value cannot be specified manually because it is based on the lease time as set for the scope. |
| 61 | Client ID | Word | Specifies the DHCP client's unique identifier. |
The Microsoft DHCP client and server do not support option overlays. An option overlay is the process of using free space in the DHCP option packet to contain additional DHCP options. So if you are using a third-party DHCP Server instead of the Microsoft DHCP server, you should make sure that your important configuration options are listed first; otherwise, they might be discarded. Microsoft clients are also limited regarding the size of the DHCP packet they can properly process. This limit is 312 bytes, so you must make all the options you choose fit within this allocation. The same consideration applies if you are using the Microsoft DHCP Server to support your third-party DHCP clients: Choose your most important configuration options first. And although you can use the additional configuration options (listed in Table 12.2) to support your third-party DHCP clients, these options will not be used by your Microsoft DHCP clients.
Table 12.2. Third-party DHCP client configuration options.
| Number | Name | Data Type | Description |
| 0 | Pad | Byte | Specifies that the following data fields will be aligned on a word (16-bit) boundary. |
| 2 | Time | Long | Specifies the Universal Coordinate Offset Time (UCT) in seconds. |
| 4 | Time Server | IP Address Array | Specifies a list, in order of preference, of time servers for the client. |
| 5 | Name Servers | IP Address Array | Specifies a list, in order of preference, of name servers for the client. |
| 7 | Log Servers | IP Address Array | Specifies a list, in order of preference, for MIT_LCS User Datagram Protocol (UDP) log servers for the client. |
| 8 | Cookie Servers | IP Address Array | Specifies a list, in order of preference, of cookie servers (as specified in RFC 865) for the client. |
| 9 | LPR Servers | IP Address Array | Specifies a list, in order of preference, for Line Printer Remote (as specified in RFC 1179) servers for the clients. |
| 10 | Impress Servers | IP Address Array | Specifies a list, in order of preference, of Imagen Impress servers for the client. |
| 11 | Resource Location Servers | IP Address Array | Specifies a list, in order of preference, of RFC 887 compliant Resource Location Servers for the client. |
| 12 | Hostname | String | Specifies the hostname (maximum of 63 characters) for the client. NOTE:The name must start with a alphabetic character, end with an alphanumeric character, and can contain only letters, numbers, or hyphens. The name can be fully qualified with the local DNS domain name. |
| 13 | Boot File Size | Word | Specifies the default size of the boot image file in 512 octet blocks. |
| 14 | Merit Dump File | String | Specifies the ASCII path of a file in which the client's core dump can be stored in case of an application or system crash. |
| 16 | Swap Server | IP Address | Specifies the IP address of the client's swap server. |
| 17 | Root Path | String | Specifies a path (in ASCII) for the client's root disk. |
| 18 | Extensions Path | String | Specifies a file that includes information that is interpreted the same as the vendor extension field in the BOOTTP response, except that references to Tag 18 are ignored. Note that the file must be retrievable through TFTP. |
| 19 | IP Layer Forwarding | Byte | Specifies that IP packets should be enabled (1) or disabled (0) for the client. |
| 20 | Nonlocal Source Routing | Byte | Specifies that datagram packets with nonlocal source route forwarding should be enabled (1) or disabled (0) for the client. |
| 21 | Policy Filters Mask | IP Address Array | Specifies a list, in order of preference, of IP address and mask pairs that specify destination address and mask pairs, respectively. Used for filtering nonlocal source routes. Any source routed datagram whose next hop address does not match an entry in the list is discarded by the client. |
| 22 | Max DG Reassembly Size | Word | Specifies the maximum size datagram that a client can assemble. NOTE:The minimum size is 576 bytes. |
| 23 | Default Time to Live | Byte | Specifies the Time to Live(TTL) that the client will use on outgoing datagrams. Values must be between 1 and 255 hops. |
| 24 | Path MTU Aging Timeout | Long | Specifies the timeout, in seconds, for aging Path Maximum Transmission Unit values. NOTE:MTU values are found using the mechanism defined in RFC 1191. |
| 25 | Path MTU Plateau Table | Word Array | Specifies a table of MTU sizes to use when performing Path MTU (as defined in RFC 1191). NOTE: The table is sorted from minimum value (68) to maximum value 68. |
| 26 | MTU Option | Word | Specifies the MTU discovery size. NOTE: The minimum value is 68. |
| 27 | All Subnets are Local | Byte | Specifies whether the client assumes that all subnets in the network will use the same MTU value as that defined for the local subnet. This option is enabled (1) or disabled (0), which specifies that some subnets may use smaller MTU values. |
| 28 | Broadcast Address | IP Address | Specifies the broadcast IP address to be used on the client's local subnet. |
| 29 | Perform Mask Discovery | Byte | A value of 1 specifies that the client should use ICMP (Internet Control Message Protocol) for subnet mask discovery, whereas a value of 0 specifies that the client should not use ICMP for subnet mask discovery. |
| 30 | Mask Supplier | Byte | A value of 1 specifies that the client should respond to ICMP subnet mask requests, whereas a value of 0 specifies that a client should not respond to subnet mask requests using ICMP. |
| 31 | Perform Router Discovery | Byte | A value of 1 specifies that a client should use the mechanism defined in RFC 1256 for router discovery. A value of 0 indicates that the client should not use the router discovery mechanism. |
| 32 | Router Solicitation Address | IP Address | Specifies the IP address to which the client will send router solicitation requests. |
| 33 | Static Route | IP Address Array | Specifies a list, in order of preference, of IP address pairs the client should install in its routing cache. NOTE: Any multiple routes to the same destination are listed in descending order or in order of priority. The pairs are defined as destination IP address/router IP addresses. The default address of 0.0.0.0 is an illegal address for a static route and should be changed if your non-Microsoft DHCP clients use this setting. |
| 34 | Trailer Encapsulation | Byte | A value of 1 specifies that the client should negotiate use of trailers (as defined in RFC 983) when using the ARP protocol. A value of 0 indicates that the client should not use trailers. |
| 35 | ARP Cache Timeout | Long | Specifies the timeout, in seconds, for the ARP cache entries. |
| 36 | Ethernet Encapsulation | Byte | Specifies that the client should use Ethernet version 2 (as defined in RFC 894) or IEEE 802.3 (as defined in RFC 1042) encapsulation if the network interface is Ethernet. A value of 1 enables RFC 1042, whereas a value of 0 enables RFC 894 encapsulation. |
| 37 | Default Time to Live | Byte | Specifies the default TTL the client should use when sending TCP segments. NOTE:The minimum octet value is 1. |
| 38 | Keepalive Interval | Long | Specifies the interval, in seconds, for the client to wait before sending a keepalive message on a TCP connection. NOTE:A value of 0 indicates that the client should send keepalive messages only if requested by the application. |
| 39 | Keepalive Garbage | Byte | Enables (1) or disables (0) sending keepalive messages with an octet of garbage data for legacy application compatibility. |
| 40 | NIS Domain Name | String | An ASCII string specifying the name of the Network Information Service (NIS) domain. |
| 41 | NIS Servers | IP Address Array | Specifies a list, in order of preference, of IP addresses of NIS servers for the client. |
| 42 | NTP Servers | IP Address Array | Specifies a list, in order of preference, of IP addresses of Network Time Protocol (NTP) servers for the client. |
| 43 | Vendor Specific Info | Byte Array | Binary information used by clients and servers to pass vendor-specific information. Servers that cannot interpret the information ignore it, whereas clients that do not receive the data attempt to operate without it. |
| 45 | NetBIOS Over TCP/IP NBDD | IP Address Array | Specifies a list, in order of preference, of IP addresses for NetBIOS datagram distribution (NBDD) servers for the client. |
| 48 | X Window System Font | IP Address Array | Specifies a list, in order of preference, of IP addresses of X Window font servers for the client. |
| 49 | X Window System Display | IP Address Array | Specifies a list, in order of preference, of IP addresses of X Window System Display Manager servers for the client. |
| 64 | NIS + Domain Name | String | Specifies a list, in order of preference, of NIS + domain names. |
| 65 | NIS + Server | IP Address Array | Specifies a list, in order of preference, of NIS + servers. |
| 255 | End | Byte | Specifies the end of the DHCP packet. |
Installing the DHCP Service
You can install the DHCP Server service through the Control Panel Network applet. But before you install the service on your current server, check for the existence of other DHCP servers on the network. These could be other Windows NT Servers or a UNIX server.
To install the DHCP Server service, follow these steps:
NOTE:To install the DHCP Server service, you must be a member of the Administrators group on the computer on which you want to install the service.
- Launch the Control Panel Network applet.
- Click the Services tab, and then the Add— button.
- Select Microsoft DHCP Server from the list of network services.
NOTE:If you don't have TCP/IP installed already, when you install the DHCP Server Service, TCP/IP will be automatically installed.
TIPTo use SNMP to configure the DHCP Server service remotely, install the SNMP Service as well.
- Click the OK button. When prompted, enter the path to the distribution files (that is, f:\i386) and click the Continue button. Setup warns you that DHCP servers cannot also be DHCP clients and any network adapter configured as a DHCP client must be reconfigured. This message is shown in Figure 12.1.
Figure 12.1
Network adapters on a DHCP Server cannot be configured to dynamically obtain IP addresses.
Click the OK button and then click Close to close the Network Control Panel.
If one or more adapters on your server was configured to obtain its IP address from a DHCP server, or if you are installing TCP/IP at the same time as the DHCP server service, you will be prompted to configure TCP/IP settings for each adapter on your system.
Now restart your system. After the system restarts, the DHCP Server service should be activated. If not, check your system event log for any error messages.
Managing Your DHCP Server with the DHCP Manager
Your interface to managing the DHCP Service is the DHCP Manager. It is installed in the Administrative Tools program group when you install the DHCP service and requires administrative privileges to use. With the DHCP Manager, you can do everything but stop or start the DHCP Service. To stop or start the service, use the Control Panel Services applet and specify the Microsoft DHCP Server as the service to control. Or, you can issue the following commands from a console prompt:
net stop dhcpserver
net start dhcpserver
The DHCP Manager's primary function is to work with scopes. This section discusses creating, deleting, activating, and deactivating scopes. Next, we discuss how to manage your DHCP clients. This includes managing your client leases and reservations, as well as setting individual DHCP properties for reserved clients that differ from those defined for the scope as a whole. Finally, we discuss the DHCP database administration required from time to time. This should provide you with a well-rounded education and prepare you for your duties as a network Administrator so that you can manage your TCP/IP-based network.
Managing DHCP Scopes
Before you can use the DHCP Server to assign IP addresses and relevant configuration options to your DHCP clients, you must create a DHCP scope. A scope is the heart of your DHCP Server service. It is based on an IP address range, or subnet, if you prefer. It can include only a single subnet, but within that subnet, you can define the IP range to be used as the basis for your DHCP client's IP address assignment, the subnet mask, any IP addresses to exclude from the scope, a lease duration, a name for the scope, and a comment that describes the scope. This section discusses how to create, delete, activate, and deactivate DHCP scopes. Next, it moves on to configuring global, local, or default scope properties.
When you run the DHCP Manager for the first time, it does not have any scopes defined, although it does include a listing in the DHCP Server's window for the local machine. Before you start creating scopes, I suggest that you add the additional DHCP Servers on your network to the DHCP Manager. When you do, your DHCP Manager includes a listing in the window of each DHCP Server on your network (see Figure 12.2). This gives you the capability to manage your other scopes, and you can use these additional scopes as a reference point when creating new scopes.
Figure 12.2
The Microsoft DHCP Manager with multiple DHCP servers and scopes.
To add DHCP Servers to your local DHCP Manager, follow these steps:
- Choose Add from the Server menu, or press Ctrl+A to display the Add DHCP Server to Server List dialog box.
- Enter the IP address of the DHCP Server in the DHCP Server field and click the OK button. The IP address appears in the DHCP Server window.
NOTE:The DHCP Manager deals with TCP/IP FQDN (fully qualified domain name)-compliant hostnames—also called DNS names. It does not recognize NetBIOS names. For an in-depth description of the differences between NetBIOS names and the standard TCP/IP hostnames, refer to the section "NetBIOS names versus TCP/IP hostnames" later in this chapter.
- Repeat these steps for each DHCP Server you want to add to your local DHCP Manager.
NOTE:Because the DHCP Server service does not replicate its database and configuration information to other DHCP Servers, you must configure the DHCP Manager on each server in order to manage all the DHCP scopes from any computer with the DHCP Manager installed on it.
Working with DHCP Scopes
Working with DHCP scopes consists of four possible functions:
- Creating a scope: This is the beginning process to automating your DHCP client TCP/IP configuration.
- Activating a scope: Before you can use a newly created scope, you must activate it. When you have an active scope, your DHCP clients can be assigned an IP address and relevant TCP/IP configuration information from the scope.
- Deactivating a scope: Before you delete a scope, you should deactivate it. Deactivating a scope prevents a client from renewing its current lease and forces it to obtain a lease from another DHCP scope. This is a means of migrating clients to a new scope without manual intervention.
- Deleting a scope: After you finish using a DHCP scope, you can delete it.
To create a scope, follow these steps:
- Select the DHCP Server in the DHCP Server window where you want to create the new scope. If you are creating a new scope on the computer running the DHCP Server service, this entry will be Local Machine; otherwise, it will be an IP address.
- Choose Create from the Scope menu. The Create Scope dialog box appears, as shown in Figure 12.3.
Figure 12.3
The Create Scope dialog box.
- In the Start Address field, enter the beginning IP address of your subnet.
- In the End Address field, enter the last IP address of your subnet.
TIP:If you are not planning to divide your subnet between two DHCP Servers, enter the complete IP address range of your subnet. However, if you are planning to split your subnet (as I have), enter only half of your IP address range in the Start and End Address fields. This is easier to work with and prevents complications with the second DHCP Manager's defined scope.
- In the Subnet Mask field, enter the subnet mask to be assigned to your DHCP clients.
- If your scope includes statically assigned addresses, such as those assigned to your network adapters in the computer or to the Remote Access Service, enter these addresses in the Exclusion Range group. To exclude a single IP address, enter the IP address in the Start Address field and click the Add button. To enter more than one consecutive IP address to be excluded, enter the beginning IP address in the Start Address field and the last IP address in the End Address field; then click the Add button. This places the IP address range in the Excluded Addresses box.
To modify or remove an address range, select it in the Excluded Addresses box and click the Remove button. This places the range in the Exclusion Range fields where you can modify it and later add it back to the Excluded Addresses box.
- In the Lease Duration group, choose the Unlimited or Limited To radio button to specify the lease type. If you choose Limited To, which is the default, specify the length of time for your DHCP clients to keep their assigned IP addresses. By default the lease expiration period is set to 3 days.
Choose your lease time on the basis of the frequency with which your computers are upgraded, replaced, or moved between subnets. If you have a high movement of computers, choose a lease of approximately two weeks. If you have an extremely low movement of computers, choose a monthly, trimonthly, or biyearly lease.
WARNING: Do not assign the Unlimited lease type unless you are absolutely sure that no computers will ever be upgraded, replaced, or moved. It is very improbable that you will be in this situation, I can assure you. If you choose an unlimited lease, you cannot automatically recover IP addresses that have been assigned to a DHCP client.
- In the Name field, enter a name for the scope. Your name can be a floor or building location, or a description for the type of subnet. This name, along with the scope address, is listed in the DHCP Server window. It can be up to 120 characters.
- In the Comment field, enter a description for the scope up to 120 characters long. You should make this comment as descriptive as possible.
TIP:To modify the scope properties for an existing scope, just double-click it. This displays the Scope Properties dialog box, which is identical to the Create Scope dialog box (aside from its name, of course). You can change any of the options described in the earlier steps.
- Click the OK button. A message box appears, prompting you to activate the scope. However, you should not activate the scope now, unless all your default scope properties are correct, as described in the "Configuring DHCP Scope Options" section.
- Repeat these steps for each new scope you want to create.
CAUTION:Activate a scope only after you have configured it; otherwise clients might get invalid configuration information. Also, be sure to make any necessary lease reservations before activating the scope; otherwise a client other than the indented recipient might take the IP address.
To activate a scope, choose Scope | Activate.
Before you delete a scope, you should deactivate it. To do so, choose Scope | Deactivate. When the scope lease time expires and you are sure that no DHCP clients are using a lease from the scope, you can delete it.
To delete a scope, follow these steps:
- Select the DHCP Server in the DHCP Server window containing the scope you want to delete. If you are deleting a scope on the computer running the DHCP Server Service, this entry is Local Machine; otherwise, it is an IP address.
- The scopes for the server are listed. Select the scope you want to delete.
- Choose Delete from the Scope menu. A warning message appears, informing you that clients still may have active leases. Click OK to delete the scope.
- Repeat these actions for each scope you want to delete.
TIP:If you delete a scope with active clients, you can force the client to discontinue using its current lease and obtain one from another DHCP Server by issuing the IPCONFIG /RENEW command at a command prompt on the client workstation. On a Windows 95 computer, you can use the WINIPCFG program. Click the Renew button to release the active lease and obtain a new lease.
Configuring DHCP Scope Options
Scope options are divided into two classes: You can have a global scope setting, which applies to all scopes for the DHCP Server, or a local scope setting, which applies only to a specific scope. Local scope properties override globally defined scope properties. This rule enables you to define common properties that apply to all scopes you create and then customize them. Suppose that you define the global router setting to contain the IP addresses for your routers using subnets. After you create a new scope, you can delete the first entry in this list and then add it back. This places the IP address entry at the end of the list. In effect, it changes the order of router preference so that the router closest to the user is used first. You can repeat this sequence to continue moving the router addresses for each subnet you create without having to type each router address manually.
To modify a scope property, follow these steps:
- Select the DHCP Server in the DHCP Server window containing the scope you want to modify. If you are modifying a scope on the computer running the DHCP Server Service, this entry is Local Machine; otherwise, it is an IP address.
- After the connection to the DHCP Server has been established, the scopes for the server are listed. Select the scope you want to modify.
- Choose Global from the DHCP Options menu. Here, you can set global properties for all scopes. Or, you can choose Scope from the DHCP Options menu to set local scope properties.
NOTE:The dialog box displayed by choosing the DHCP Options | Scope menu selection is the same as the dialog box displayed by choosing the Global menu option, aside from the name of the dialog box.
- In the Unused Options drop-down list box, select the option that you want to modify, and then click the Add button to move the highlight to the Active Options drop-down list box.
- Click the Value button to expand the dialog box and display the edit field, where you can click the Edit Array button to modify an array of IP addresses or just edit the field for a single entry type.
- Repeat steps 3—5 for each option to modify. When you finish modifying the options, click the OK button.
TIP:To modify an existing option, select it in the Active Options list box and then click the Value button to expand the dialog box.
Creating New DHCP Scope Options
Not only can you modify the predefined scope properties with the DHCP Manager, but you also can modify the name, unique identifier, and comment of existing configuration options. And if your DHCP clients can use them, you can even create new scope options to be assigned to your DHCP clients. However, just because you can modify an existing configuration option or create new ones doesn't mean that you should do so arbitrarily. Only do so if absolutely necessary.
To change an existing configuration option default value, follow these steps:
- Choose Defaults from the DHCP Options menu to display the DHCP Options dialog box, as depicted in Figure 12.4.
Figure 12.4
The DHCP Options: Default Values dialog box.
- In the Option Class drop-down list box, select the class for the option you want to modify. The default is DHCP Standard Options.
- In the Option Name drop-down list box, select the entry for the option class to modify.
- In the Value group, specify the new value for the option.
To change a configuration option's name, unique identifier, or description, follow these steps:
- Repeat steps 1—3 of the preceding procedure.
- Click the Change button to display the Change Option Type dialog box.
- Now change the name of the option in the Name field, the DHCP unique identifier number in the Identifier field, or the description in the Comment field.
WARNING: Changing the name or identifier may prevent a DHCP client from functioning properly. Only an expert who is aware of the consequences should modify any of these settings.
- After you complete all changes, click the OK button.
- Repeat these steps for each option you want to change.
To add a new configuration option, follow these steps:
- Repeat steps 1—3 for the procedure to change an existing configuration option default value.
- Click the New button to display the Change Option Type dialog box.
- In the Name field, enter a name for the new option.
- In the Data Type field, specify a data type. This can be one of the following:
- Binary: An array of bytes
- Byte: An 8-bit unsigned integer
- Encapsulated: An array of unsigned bytes
- IP address: An IP address (4 bytes) in the form of ###.###.###.###
- Long: A 32-bit signed integer
- Long integer: A 32-bit unsigned integer
- String: An ASCII text string
- Word: A 16-bit unsigned integer
If the data type is an array of elements, enable the Array checkbox.
- In the Identifier field, enter a unique number between 0 and 255.
- In the Comment field, enter a description for the new option.
WARNING: Adding a new configuration option should be performed only by an expert who is aware of the consequences. It must support non-Microsoft DHCP clients that require the additional options.
- After your changes are complete, click the OK button.
- Repeat these steps for each option you want to add.
Managing DHCP Clients
Managing your DHCP clients consists of working with client leases and client reservations on the DHCP Server and forcing the client to release or renew its lease on the client workstations. On a client, the main method of configuring DHCP is through the command-line program IPCONFIG.EXE.
The syntax for IPCONFIG follows:
IPCONFIG [adapter] /all /release /renew
Explanations of the syntax for this command follow:
- [adapter]: An optional component that is the specific adapter to list or modify the DHCP configuration. Use IPCONFIG with no parameters to obtain the adapter names.
- /all: Lists all the configuration information. This includes the hostname, DNS servers, node type, NetBIOS scope ID, whether IP routing is enabled, whether the computer is a WINS Proxy Agent, and whether the computer uses DNS for name resolution (instead of WINS). It also includes per-adapter statistics, which include the adapter name and description, the physical address (network adapter Ethernet address), whether the DHCP client is enabled, the IP address, the subnet mask, the default gateway, and the primary and secondary WINS server IP addresses.
- /release: Releases the current DHCP lease. If specified for all adapters (or if there is only one adapter), TCP/IP functionality is disabled.
- /renew: Renews the lease. If no DHCP Server is available to obtain a valid lease, TCP/IP functionality is disabled.
TIP:Use the /renew option to manually force a client to obtain a new lease from a new DHCP Server or a new DHCP scope.
NOTE:Windows 95 does not include IPCONFIG; instead, it includes a Windows GUI application called WINIPCFG.EXE.
If executed with no parameters, the current DHCP configuration is displayed. This can be useful for determining the installed adapters and IP addresses. The following output is displayed on my Winguide XP, for example:
Windows NT IP Configuration
Ethernet adapter Elnk31:
IP Address. . . . . . . . . : 128.0.0.254
Subnet Mask . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . :
Ethernet adapter NDISLoop9:
IP Address. . . . . . . . . : 129.0.0.1
Subnet Mask . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . :
Managing Client Leases
Managing your DHCP client leases, for the most part, consists of informational displays. When you select an active scope and choose Active Leases from the Scope menu, the Active Leases dialog box appears, as shown in Figure 12.5.
Figure 12.5
The DHCP Manager Active Leases dialog box.
You can perform the following actions in the Active Leases dialog box:
TIP:You can delete a lease by selecting the lease in the Client list and clicking the Delete button. However, this is not an action to be taken lightly, because you could wind up with a duplicate IP address on the network if the original lease is used by another computer. Suppose that you delete an active lease because you want to move the client to a new IP address. As soon as you delete the lease, reserve it (as described in the "Managing Client Reservations" section) to prevent the client from reusing the same IP address. Then force the client to establish a new lease by issuing the IPCONFIG /RENEW command on the client workstation. Or use the WINIPCFG command on a Windows 95 client and then click the Renew button to obtain a new lease.
Managing Client Reservations
Client reservations can be more useful than your average lease because you can preassign an IP address for a DHCP client. You also can change the DHCP configuration options for a DHCP client with a reserved lease. This is a pretty powerful option, because it enables you to define global and local scope options for the majority of your DHCP clients when you create the scope, and then specify the specific DHCP options for those special DHCP clients that are the exception to the rule.
To create a reservation for a client, follow these steps:
- Select the DHCP Server in the DHCP Server window containing the scope you want to modify. If you are modifying a scope on the computer running the DHCP Server Service, this entry is Local Machine; otherwise, it is an IP address.
- Select the scope where you want the client reservation to occur.
- Choose Add Reservations from the Scope menu to display the Add Reserved Clients dialog box.
- In the IP Address field, enter an IP address from your current DHCP scope to be assigned to the client.
- In the Unique Identifier field, enter the MAC address (the network adapter's unique identifier) for the client's network adapter.
- In the Client Name field, enter the client computer name.
- In the Client Comment field, enter an optional description for the client computer.
- Click the Add button.
- Repeat steps 3—6 for each reservation to add to the scope.
Changing the configuration options for a reserved lease requires a little more work. To change a configuration option, follow these steps:
- Select the DHCP Server in the DHCP Server window containing the scope you want to modify. If you are modifying a scope on the computer running the DHCP Server Service, this entry is Local Machine; otherwise, it is an IP address.
- Select the scope you want to modify.
- Choose Active Leases from the Scope menu to display the Active Leases dialog box.
- Select the reserved lease you want to modify and click the Properties button. If there are too many leases to scroll through, enable the Show Reservations Only checkbox. The Client Properties dialog box appears.
- Click the Options button to display the DHCP Options dialog box. This dialog box is exactly the same as the other DHCP Options dialog box.
- In the Unused Options list box, select the option you want to modify and then click the Add button to move the option to the Active Options list box. If the option to modify is already in the Active Options list box, just select it.
- Click the Value button to expand the dialog box and display the edit field, where you can click the Edit Array button to modify an array of IP addresses, or a field to edit the existing value.
- Repeat steps 4—6 for each option to modify. When you finish modifying the options, click the OK button.
- Repeat steps 3—7 for each reservation you must modify. When you finish modifying all the reservations, click the OK button.
Managing the DHCP Databases
As your DHCP Server operates day in and day out, the databases may grow or shrink as records are added or deleted. These databases are located in the %SystemRoot%\System32\DHCP directory and include the following:
- DHCP.MDB: The DHCP database
- DHCP.TMP: A temporary file created by the DHCP Server
- JET*.LOG files: Files that contain transaction records
- SYSTEM.MDB: Structural information about the DHCP databases
Database growth affects the performance of the DHCP Server. So, as your DHCP.MDB database approaches the 10MB limit, you should compact it.
To compact your database, follow these steps:
- Stop the DHCP Server Service from the Control Panel Services applet or issue the net stop dhcpserver command from a console prompt.
- From a console prompt, run the JETPACK.EXE program located in your %SystemRoot%\System32 directory. The syntax for this program follows:
JETPACK DatabaseName TemporaryDatabaseName
DatabaseName is the name of the database to compact, and it can be a fully qualified path name.
TemporaryDatabaseName is a name to use as a temporary database. It also can be a fully qualified path name.
WARNING: Do not compact the SYSTEM.MDB file. If you do, the DHCP Server Service will not start. If this occurs, restore your configuration from a previous backup, or delete all your files from the %SystemRoot%\System32\DHCP and %SystemRoot%\System32\DHCP\backup\Jet directories. Next, expand the SYSTEM.MDB file from your source media and restart the DHCP Server Service. Then reconcile your database by choosing Scope | Active Leases and clicking the Reconcile button.
- Start the DHCP Server Service from the Control Panel Services applet or issue a net start dhcpserver command from a console prompt.
TIP:Because failure is possible with the compact utility and data corruption is possible on your %SystemRoot% partition, you should back up your DHCP databases regularly, and definitely before you compact them. Just stop the DHCP Server Service temporarily and copy the files in the %SystemRoot%\System32\DHCP and %SystemRoot%\System32\DHCP\backup\Jet directories to another directory, or even another computer occasionally.
DHCP Relay Agent
Because DHCP relies so heavily on broadcast methods, you can run into problems when using it in a routed environment. This is because routers are typically configured to filter out broadcast messages, restricting the range of the message to the local subnet.
However, DHCP uses the well-known UDP ports originally reserved for BOOTP, ports 67 and 68, so DHCP has an advantage. BOOTP is a method used for supplying an IP address and information necessary to allow a diskless workstation to boot from the network. People needed to provide this support across subnets, so router vendors began providing mechanisms for passing ports 67 and 68 to remote subnets. This relay support is commonly known as BOOTP/DHCP relay support, and is defined in RFC 1452. Not all routers support this, and on routers that do, the default option differs.
Not all routers provide this functionality, and others required a prohibitively expensive upgrade, so Microsoft provided a DHCP relay agent. This agent runs as a service on a Windows NT 4.0 Workstation or Server and listens to UDP port 67 for DHCP Discover packets on the local subnet. When it detects such a packet, it passes this packet to one or more DHCP servers configured when you set up the Relay Agent. When the DHCP server receives the packet, it responds with a DHCP Offer, but instead of broadcasting this offer, as it would normally, it addresses it back to the DHCP relay agent. The agent then sends the offer to the client, on behalf of the DHCP server. In fact, the client doesn't even realize it's talking to an intermediary, rather than directly to the server.
Installing the DHCP Relay Agent
To install the DHCP Relay Agent service, follow these steps:
NOTE:You must be logged on as a member of the local Administrators group to install the DHCP Relay Agent.
- Open the Network Control Panel applet.
- Click on the Services Tab.
- Click the Add… button, and select DHCP Relay Agent.
- When prompted, enter the path to the distribution files (that is, f:\i386) and click the Continue button. This will bring you back to the Network Control Panel. DHCP Relay Agent should now be listed as an installed service.
- Click the Continue button to exit the Network Control Panel.
- You will receive a warning message, such as that shown in Figure 12.7, telling you that you must configure at least one DHCP server address before the DHCP Relay Agent can be activated. Click Yes to bring up the Microsoft TCP/IP Properties page.
12.7
Figure 12.7
Setup will warn you that you must configure at least one DHCP server before the DHCP Relay Agent can be started.
- From the Microsoft TCP/IP Properties page, click the DHCP Relay Agent tab. This displays the DHCP Relay Agent configuration page, shown in Figure 12.8.
Figure 12.8
The DHCP Relay Agent is configured from the Microsoft TCP/IP Properties window.
- Use the Add— button to enter the addresses of the DHCP Servers you want to service the local subnet.
- Change the Seconds Threshold and the Maximum Hops as necessary for your particular network.
NOTE:For most networks, you can leave the Seconds Threshold and the Maximum Hops values at their defaults, which is 4 seconds and 4 hops, respectively.
- Click OK to close the Microsoft TCP/IP Properties window.
You must restart your computer for the changes to take effect.
Using DHCP Server Registry Keys
Like most Windows NT services, the configuration information for the service is contained in the Registry. For the most part, you should use the DHCP Manager to modify your configuration. These listed Registry keys are not configurable from the DHCP Manager, and instead require that you use the Registry Editor (REGEDT32.EXE). The Registry Editor can be a dangerous tool to use. (See Chapter 18, Understanding the Registry, for more information.) If you are administering a remote computer with a configuration problem so severe that the service cannot be started, then you can modify the Registry and restore the database configuration remotely. After these changes are made, you can restart the service using Server Manager.
The Registry keys are stored in the HKEY_LOCAL_MACHINE\Systems\CurrentControlSet\Services\DHCPServer\Parameters subkey. If you modify any of these keys (aside from the RestoreFlag), you must restart the computer for your changes to be applied.
The keys of interest follow:
- APIProtocolSupport: This key's value specifies the transport protocol to be supported by the DHCP Server. The default is 0x1 for RPC over TCP/IP protocols. However, it also can be 0x2 for RPC over named pipe protocols, 0x4 for RPC over LPC (Local Procedure Calls), 0x5 for RPC over TCP/IP and RCP over LPC, or 0x7 for RPC over all three protocols (TCP/IP, named pipes, and LPC).
- BackupDatabasePath: This key specifies the location of the backup copy of the DHCP database. The default is %SystemRoot%\System32\DHCP\Backup. For additional fault tolerance, you can specify another physical drive in the system. NOTE:
You cannot specify a network drive because the DHCP Manager does not support remote drives for backup or recovery.
- BackupInterval: Specifies the default backup interval in minutes. The default is 60 (0x3C).
- DatabaseCleanupInterval: Specifies the interval in minutes for the time to remove expired client records from the database. The default is 864,000 (0x15180) minutes, or 24 hours.
- DatabaseLoggingFlag: Specifies whether to record the database changes in the JET.LOG file. This file is used to recover the database if a system crash occurs. The default is 1 (enable logging), but if your system is extremely stable, you can set this value to 0 to disable logging and increase overall system performance slightly.
- DatabaseName: Specifies the database filename to be used by the DHCP Server Service. The default is DHCP.MDB.
- DatabasePath: Specifies the location of the DHCP database files. The default is %SystemRoot%\System32\DHCP.
- RestoreFlag: this key specifies whether the DHCP Server should restore the DHCP database from its backup copy. Set this value to 1 to force a restoration, or leave it at 0 to continue to use the original database file. NOTE:
If you change this value, you must stop and then restart the service for the changes to be applied.
The Windows Internet Name Service
Now that we've taken a look at DHCP, we have a better foundation for exploring WINS. Although DHCP is not required for running WINS, they complement each other very well. The major impetus behind the creation of WINS was the need for a dynamic name resolution method that would work with DHCP. Because DNS in its standard form only supports static name resolution, it wouldn't have provided the level of necessary functionality.
So there you have it: WINS's primary job role is name registration and resolution on TCP/IP.
NOTE:WINS is based on RFC 1001 and 1002, which define NetBIOS name resolution over TCP/IP. WINS is fully interoperable with other NetBIOS Name Servers (NBNS). These RFCs can be found at ftp://ds.internic.net/rfc/rfc1001.txt and ftp://ds.internic.net/rfc/rfc1002.txt.
But wait, you might be saying, isn't that the job of DNS? Yes it is, but there are many things that DNS cannot do. Whereas DNS is designed for resolving TCP/IP hostnames to static IP addresses, WINS is specifically designed to resolve NetBIOS names on TCP/IP to dynamic addresses assigned by DHCP.
NOTE:It is important to understand the distinction between a NetBIOS name and a computer's TCP/IP hostname. A discussion of this can be found in the section titled "WINS versus DNS," later in this chapter.
Also, whereas DHCP is truly a cross-platform service, WINS is primarily focused on the Windows (and DOS) platforms. This is because NetBIOS is a Windows (and DOS) artifact.
This discussion of WINS begins with some of the design goals of the service, along with some of the concerns when implementing WINS on your network. It then moves on to planning your WINS Server installation, which includes some guidelines for the number of WINS Servers and WINS Proxy Agents to install. Following that, we look at the actual installation steps required to install the service. When that is out of the way, we move on to managing and configuring the WINS Service with the WINS Manager. And because a major portion of WINS involves client-related administration, you will see how you can manage your WINS clients with the WINS Manager and learn about some specific quirks for MS-DOS clients using the Microsoft Network Client network software. Finally, we look at managing your WINS database, using the Performance Monitor to monitor your WINS service, and using some of the Registry keys that control the behavior of the WINS service.
Looking at Design Goals for the WINS Service
The primary purpose of the WINS Server Service is to make an Administrator's job easier by automating the process of mapping computer names to IP addresses for NetBIOS name resolution in a TCP/IP-based network. In a nutshell, WINS maintains a database on the WINS server. This database provides a computer name to IP address mapping, enabling other computers on the network to connect to it simply by supplying a machine name. In many respects, WINS is like DNS, except it is designed for NetBIOS name resolution. There is more to WINS than just automating the name resolution process, however.
The WINS design also includes the following:
- Centralized management: Along with the WINS Server Service, Windows NT Server also includes the WINS Manager. And with the WINS Manager, you can administer other WINS Servers and set up replication partners. You'll learn more about replication partners in the section titled "Planning your WINS Installation," later in this chapter.
- Dynamic address mapping and name resolution: Every time a WINS client starts, and at specified intervals thereafter, the WINS client registers its name with the WINS Server. When the WINS client terminates, such as when the computer shuts down, it tells the WINS server and the name is released. This gives a client computer the capability to change subnets or to change its IP address and still be accessible from other computers, and it alleviates the manual modifications to host files required by a UNIX DNS service. These three stages (registration, release, and renewal) operate in the following manner:
Registration: A name registration request is sent to the WINS Server to be added to the WINS database. The WINS Server accepts or rejects a client name registration on the basis of its internal database contents. If the database already contains a record for the IP address under a different computer name, the WINS Server challenges the registration. A challenge is a means of querying the current holder of the IP address to see whether it is still using it. If it is, the new client request is rejected. If the current holder of the IP address is not using the IP address, then the new client request is accepted and is added to the database with a timestamp, a unique incremental version number, and other information.
Release: Whenever a computer is shut down properly by the user (that is, it did not crash or have a power failure), it informs the WINS Server, which marks the name entry in the database as released. If the entry remains marked as released for a specific period of time, the entry then is marked as extinct and the version number is incremented. Version numbers are used to mark a record as changed so that changes to WINS partners are propagated to all WINS Servers.
If a record is marked as extinct and a new registration arrives at the WINS Server with the same name but a different IP address, the WINS Server does not challenge the registration. Instead, the new IP address is assigned to the name. This might occur with a DHCP-enabled portable computer (or another DHCP-enabled computer) that is moved to a different subnet, for example.
Renewal: When half the renewal time has expired, a WINS client reregisters its name and IP address with a WINS Server. If the renewal time expires completely, the name is released, unless the client reregisters with the WINS Server.
- Domain-wide browsing: If you are using WINS Servers, then your clients (Windows NT, Windows 95, Windows for Workgroups, LAN Manager 2.x, and MS-DOS computers using the Microsoft Network Client 3.0) can browse for computer resources on a Microsoft network across a router without needing a Windows NT domain controller on each subnet.
- Reduction of broadcast traffic: A WINS Server decreases the amount of broadcast messages by supplying an IP address when a name query message is received for a computer name from its local database on a WINS server or from its cache on a WINS Proxy Agent. A broadcast occurs on the local subnet only if the name query request fails.
WINS Proxy Agents
As indicated previously, WINS is a relatively new service. Therefore, you might still have several NetBIOS over TCP/IP clients that cannot act as WINS clients. This is particularly true of older software and non-Microsoft NetBIOS networking clients, such as LAN Manager and other older OS/2-based clients. To enable these non—WINS-enabled clients to interact with a WINS service, Microsoft provides the capability to run WINS Proxy Agents.
A WINS Proxy Agent listens to the local network for clients trying to use broadcasts to resolve NetBIOS names. The WINS Proxy Agent picks these requests off the network and forwards them to the WINS Server, which responds with the resolved IP address. The WINS Proxy Agent provides this information to the client requesting the name resolution.
The neat thing about this process is that no changes must be made to the non—WINS-enabled client, and in fact it is completely unaware that the name resolution has been provided by the WINS service.
NOTE:It is important to realize that the WINS Proxy Agent is only for resolving name requests for NetBIOS clients. It does not provide any name resolution for UNIX or other systems that do not use NetBIOS.
You can use Windows NT 3.5 and higher or Windows for Workgroups as WINS Proxy Agents.
WINS versus DNS
The relationship between DNS and WINS (and even DHCP) is very complicated and would require a lot of space and time to fully explore, but understanding this concept is key to getting the most from WINS and DNS on a Microsoft network.
NOTE:This section clarifies the overall concepts behind WINS, DNS, NetBIOS names, DNS hostnames, and so on. To make this as useful as possible, I gloss over certain irrelevant parts of the puzzle, so remember, it's the overall scheme that's important here.
As discussed repeatedly throughout this guide, standard TCP/IP utilities (such as FTP and TELNET) use IP addresses for establishing connections between the client and server services. Recall also that people hate to remember long IP addresses, thus the development of hostname to IP address mapping facilities, of which local HOSTS files and DNS services are the two most popular.
Whereas standard TCP/IP utilities must resolve the hostname to an IP address to locate the host on the network, Microsoft networking (a.k.a. NetBIOS networking) works differently. It does not use an actual address for locating a network resource, but rather the NetBIOS name. NetBIOS is a session layer interface protocol developed in the early 1980s for IBM. It exposes a set of networking APIs that enable user applications to obtain and provide network services. It also provided a primitive transport protocol called NetBIOS Frames Protocol (NBFP), which evolved into NetBIOS Extended User Interface (NetBEUI) a few years later. NetBEUI's sole purpose in life was to efficiently transport NetBIOS traffic across small LANs.
For many years, NetBEUI was the standard transport protocol for Microsoft networks. Today, many people still get mixed up about the role that NetBEUI and NetBIOS play. NetBEUI is inextricably linked to NetBIOS. NetBIOS, however, can be abstracted and applied to other transport protocols, such as IPX/SPX, and TCP/IP, which of course is our interest here. But first, let's look quickly at the operation of NetBIOS over NetBEUI.
Remember that NetBIOS is a session layer protocol. However, it doesn't fully comply with the ISO OSI model, so the addressing takes place inside the NetBIOS layer. Also, the addressing is done by name and not by an address, like TCP/IP.
To see why this is significant, let's look at what happens when an application requests network services with NetBIOS over NetBEUI. Some NetBIOS application decides it wants to connect to a network resource. To do this it must know the NetBIOS name that identifies the resource on the network. The application says "Okay, I want to connect to the network resource called SERVER." It speaks this command into the NetBIOS API interface. The NetBIOS layer then instructs the NetBEUI transport to find the resource on the network. "NetBIOS to NetBEUI. Please find the network resource called SERVER on the network." The NetBEUI transport does this by broadcasting to the network asking for the specified network resource to identify itself. "Hello out there. Is anyone out there called SERVER? If you are, would you please respond to me with your MAC address?" If the specified resource is on the network, it will respond with its MAC address. "Yeah, I'm SERVER. My MAC address is—" NetBEUI then uses this MAC address for passing packets back and forth between the two machines.
So you can see that it is imperative that you know the NetBIOS name of the resource you want to connect to. NetBEUI is a small and fast protocol, but because it relies heavily on broadcasts and it cannot support internetwork routing, it doesn't scale well past a small workgroup (fewer than 100 machines). That's probably a little more about NetBEUI than you wanted to know, but it is key to understanding the evolution that brought us to the confusion between WINS and DNS name resolution.
As mentioned previously, Microsoft wanted to begin running NetBIOS applications over other protocols, such as IPX/SPX and TCP/IP. This would enable Windows users to participate more extensively in large networks and perform WAN communications. Also, users who wanted to connect to standard TCP/IP-based services as well, such as FTP and TELNET servers, would only have to install a single protocol stack, which would reduce overhead.
It was simple to create a TCP/IP implementation on DOS or Windows that acted like a normal TCP/IP stack for supporting standard TCP/IP connectivity. However, the problem was how to interface NetBIOS with TCP/IP. Remember, although NetBIOS is a session-layer protocol, it uses its own resource location system based on the NetBIOS name. TCP/IP, on the other hand, relies on the IP address for resource location. The problem was getting these two to work together. The idea is quite simple, but the method can be tricky.
NOTE:All current Microsoft stacks support NetBIOS over TCP/IP. However, many third-party TCP/IP stacks developed for the DOS and Windows environments still do not.
The essence of how NetBIOS interfaces with TCP/IP follows. The NetBIOS applications says, "I want to connect to a network resource called SERVER." The NetBIOS API interface then takes this information and passes it through a NetBIOS "helper" interface. This interface resolves the NetBIOS name into an IP address, which is required for locating the resource on an TCP/IP network. Remember, this step was not required under NetBEUI, because the NetBIOS name was actually used for locating the resource on the network.
This is the step where all the confusion usually occurs, and this is also where WINS plays its biggest role. Recall that there are four main methods of resolution, b-node, p-node, m-node, and h-node. They refer to the differing methods the NetBIOS client uses to register and resolve names on a TCP/IP network. We look more closely at each of these in the next section.
When the NetBIOS to TCP/IP interface has resolved the NetBIOS name into an IP address, the remainder of the process works the same way as standard TCP/IP. The IP address is resolved into a MAC address, either of the actual resource or of the router that can be used to locate the resource. And communications take place.
So the real question becomes, "How does this interface translate the NetBIOS name into an IP address?" Before WINS was developed, the three most common ways of performing this resolution were as follows:
- The interface can use broadcasts for name to IP address resolution, just as NetBEUI resolved the names. It broadcasts the NetBIOS name onto the TCP/IP network and waits for a response. However, this is not a terribly friendly thing to do to the network, so except in small LANs, it is undesirable.
- You can use an LMHOSTS file. The LMHOSTS file is a text file, similar to HOSTS, and is used to link NetBIOS names to their corresponding IP address. When the NetBIOS application asks to connect to a network resource, the NetBIOS to IP interface looks up the NetBIOS name in the LMHOSTS file and passes the resulting IP address down through the layers. Traditionally, this has been the most popular method of supporting NetBIOS name resolution on large TCP/IP networks.
- The newer TCP/IP stacks from Microsoft have an option to use the DNS service for resolving NetBIOS names. The caveat here is that the NetBIOS name for the resource must be the same as the DNS hostname, or you'll have problems. Also, it only works when connecting to machines at the same level of the DNS hierarchy as the client. For example, if my computer is called ntserver.xyzcorp.com, and I have the DNS resolution option set, then I can use the File Manager to connect to any NetBIOS resource in the domain xyzcorp.com by using DNS for the name resolution.
The way this works is the NetBIOS application (in this case File Manager) requests a connection to the resource by its NetBIOS name. The NetBIOS to IP translation layer looks up the resources name in the authoritative DNS server for the xyzcorp.com domain and gets an IP address back.
Although all these options have their advantages and disadvantages, the problem that none of them addresses is how to deal with name resolution for dynamically assigned IP addresses. This is the primary reason WINS was created. Although WINS can be used as the only method of name resolution, it is more commonly used in conjunction with one or more of the previously listed methods.
When you use WINS on your network, WINS clients register their current IP addresses and their NetBIOS names with the WINS server. Then when someone on the network wants to resolve the NetBIOS name for a network resource, he or she can ask the WINS server. Even if the IP assignment is obtained dynamically with DHCP, this process still works, because every time a DHCP client gets a new address, it registers the change with the WINS server.
I address why NetBIOS names are important and how NetBIOS name resolution works on TCP/IP networks. One area that remains to be explored is how WINS and DNS can be integrated. WINS works well for NetBIOS name resolution. This means that I can use the File Manager or other NetBIOS application (such as the Network Clipguide viewer) to connect to a machine registered in the WINS database.
Let's look at an example to explore the need for integration between WINS and DNS. I have an NT server called SERVER. I have a Windows for Workgroups (WfW) workstation called WORKSTATION. If the WfW machine wants to connect to a network drive on SERVER, then it uses the NetBIOS name SERVER when it tries to connect. It uses whatever resolution method is available for resolving the NetBIOS name to the IP address. If I am also running an FTP server on the machine called SERVER, and I want to connect to that, things work differently. FTP is not a NetBIOS-based application. FTP really wants the actual IP address of the host in order to connect. This means that if the machine named WORKSTATION wants to connect to SERVER using FTP, it must be given the IP address of SERVER. Or WORKSTATION must be given a name that can be resolved in the IP address using a local HOSTS (not LMHOSTS) file or a DNS service. But let's throw in a monkey wrench. Let's say that the machine called SERVER gets its IP address dynamically from DHCP. Neither the HOSTS file nor the DNS solution are capable of resolving names to dynamic IP addresses. And remember, WINS is only capable of resolving NetBIOS names.
This is where the concept of interfacing WINS and DNS becomes important. Let's extend the example to see how this interfacing works. Imagine: I run a mostly Windows-based network of 100 clients with a few NT servers. All resources receive their IP addresses dynamically with DHCP, except one NT Server, which is the WINS and DHCP server. I also run an FTP server on one of the NT Servers on the network, which also gets its address dynamically. Suppose there is a UNIX box on the other side of the world that wants to FTP into the NT Server. One way to connect is to discover what the current IP address is for the server and use this to connect. The disadvantage is that the IP address might change, and you'll need to rediscover it.
There's no other way to connect, right? Well, that's what DNS to WINS integration is for. It works by running the Microsoft DNS Server service on Windows NT. The Microsoft DNS server, discussed in further detail in the section titled "Using the Microsoft Domain Name System (DNS) Server," later in this chapter, has a special piece of interface code that works with the WINS server service. This lets the DNS server request a name to IP resolution request from the WINS server.
NOTE:We've just spent all this space talking about the differences between NetBIOS names and TCP/IP hostnames; yet in the last paragraph, you get the feeling the distinction became blurred. You're right. Fortunately for us, TCP/IP hostnames and NetBIOS names use a compatible set of conventions, so when using this service, the NetBIOS name and the TCP/IP hostname can be sued interchangeably.
To continue our example, the UNIX client on the other side of the world, let's say in Timbuktu, tries to connect to an NT Server called NTFTP.xyzcorp.com. Remember, this NT Server gets a dynamic IP address from a DHCP server. The UNIX client asks its local DNS server to try to resolve the name NTFTP.xyzcorp.com. The local DNS server then looks to the InterNIC for the IP address of the authoritative DNS server for domain xyzcorp.com. The InterNIC returns the authoritative server, which is the NT Server running the Microsoft DNS server and WINS server. The Microsoft DNS server is then asked for the identity of the machine called NTFTP. The Microsoft DNS server, in turn, asks the WINS server for the IP address of a machine called NTFTP. The IP address is ultimately returned to the UNIX machine in Timbuktu, which completes the connection now that it has an IP address for NTFTP.xyzcorp.com. This is an effective example of the integration between WINS and DNS.
Planning Your WINS Installation
For a small Microsoft-based network, all you really must do for your WINS installation is to install the WINS Service on each domain controller. This provides the means to configure your TCP/IP-based network clients to fully interoperate with any other server or client on the network. This recommendation is based on the fact that a single WINS Server can accommodate about 1,500 name registrations and 760 name query requests per minute. In theory, this means that you can use one WINS Server, with a backup WINS Server for every 10,000 clients. However, I prefer to use a WINS Server per logical grouping to provide additional fault tolerance and load balancing.
NOTE:These name query requests can be routed to other WINS Servers and WINS Proxy Agents to ensure that a request eventually will be fulfilled. If you enable replication of your WINS databases, however, each WINS Server will have a complete listing of every WINS client name and IP address. Then, when a name query request is received, an IP address will be returned without broadcasting on the network. This mechanism provides the capability to decrease the amount of broadcast traffic on the subnet.
This logical grouping should be based on the physical layout of your Windows NT Server domain controllers or servers. A logical group could be based on domain controllers or servers in separate physical buildings or floors. It could even be based on domain controllers on the other side of a WAN link or similar property. For every three to five domain controllers or servers, I like to install the WINS Service. This provides for fault tolerance, in case of required maintenance or a WINS Server failure, and also limits the load on a single WINS Server. At the very least, you should have two WINS Servers on your network supplying NetBIOS name resolution to prepare for a failure of the primary WINS Server, just as you should have a primary and backup domain controller to provide logon authentication in case of a primary domain controller failure.
This scenario works well for Microsoft-based networks that use the Microsoft TCP/IP protocol stacks. But it will fail if you use third-party TCP/IP protocol stacks that do not support WINS on your network clients. This does not mean that you cannot use WINS in this situation, however; it only implies that you also must install WINS Proxy Agents. A WINS Proxy Agent should be installed on each subnet to provide a link between your non-WINS clients and the WINS Servers. Your WINS Servers also should share their database to provide complete coverage of the entire network. This sharing process is provided by WINS replication, which is discussed in detail later in this section.
NOTE:You also can create static mappings, which add a permanent computer name to IP address mapping in the WINS database to support your non-WINS clients.
You must have a WINS Proxy Agent per subnet because broadcast messages are not passed across routers. When a non-WINS client tries to find another computer, it uses a broadcast message to get the IP address of the requested computer. If the computer is on the same subnet, the request succeeds, but if it is on a different subnet, the request fails (unless you have domain controllers on both sides of the routers). This is where the WINS Proxy Agent comes into play.
Client #1 is a WINS client, Client #2 is a non-WINS client, Client #3 is a WINS Proxy Agent, and Server #1 is a Windows NT domain controller running the WINS service. When the WINS Client #2 attempts to access WINS Client #1 by broadcasting to obtain the IP address for Client #1, the request fails because Client #1 and Client #2 are on different subnets. The broadcast is intercepted by Client #3, however, which then caches this name and IP address. Client #3 also returns the IP address for Client #1 to Client #2 so that a TCP/IP connection can be established. If another WINS client on a different subnet attempts to access Client #2 by issuing a name query request, the cached IP address for Client #2 that Client #3 has stored is returned to the requesting client.
A WINS Proxy Agent will not store information obtained from a broadcast in the WINS Server's database. You therefore must have a WINS Proxy Agent on each subnet that contains non-WINS clients. In this case, the WINS Proxy Agent can respond to name query requests from WINS clients or WINS Servers, and then broadcast on its local subnet to find the non-WINS client. After the non-WINS client is found, the IP address can be passed to the WINS client or server that issued the name query request.
When a WINS client requires access to another computer, it issues a name query request. This request can be routed to WINS Servers, but this occurs only if the primary or secondary WINS Server for the WINS client does not contain a registration for the requested computer. If the routed name query request cannot be resolved by any WINS Server, the WINS client then issues a broadcast message. Both broadcast messages and routed name query messages eat network bandwidth that could be used to pass data. If your WINS Servers have a complete listing of the computer names and IP addresses, however, the primary WINS Server then can respond to the name query request, limiting the number of routed name query requests and broadcast messages.
This leads to the next performance and planning tip, which is that every WINS Server on a network should replicate its database to other WINS Servers on the network so that every WINS Server has a complete listing of every WINS client's name and IP address. This method provides the fastest mechanism for resolving names to IP addresses and limiting broadcast messages and routed name query messages.
WINS Servers provide two mechanisms for replication:
- Push partners: This is a WINS Server that sends update notifications to its pull partners. After the pull partner receives this update message, it requests the changes from the push partner. The push partner then sends a replica of its database to the requesting pull partner.
- Pull partners: This is a WINS Server that requests updates from its push partner, and when the push partner responds, it receives the database replica.
As you can see from the description of push and pull partners, these are part of a circular process. To replicate the WINS database one way, one WINS Server must be a push partner and the other must be a pull partner. To completely replicate a WINS database between two or more WINS Servers, each WINS Server must be a push and pull partner of the other. This is a two-way nonlinear chain, as shown in Figure 12.14, which can be used to replicate every WINS database to every other WINS database. Some WINS Servers receive update notifications from more than one WINS Server, which can lead to increased network traffic.
A better method, although a bit slower, is to create a linear chain where one—and only one—WINS Server is the push or pull partner of another WINS Server. Only at a WAN link is this rule broken, where the WINS Server on the LAN side is a push and pull partner of a WINS Server on the LAN, and where it is also a push and pull partner of a WINS Server on a WAN link. And this leads to another point: How often should you replicate? My basic methodology is based on the distance between replication points and the speed of the link. For your LAN, 10㬋 minutes is a good choice because the network throughput is quite high. For local, heavily used WAN links, you should limit your replication period to 30㬸 minutes. Decrease the rate only if you have a high turnover rate. For longer WAN links, choose a value of 45㭖 minutes. And for intercontinental WAN links, choose 6㬈 hours and schedule it for the non-peak hours. The idea here is that the more heavily the link is used, the lower the replication frequency (or the higher the number of scheduled minutes between replication attempts).
Installing the WINS Service
You use the Control Panel Network applet to install the WINS Server Service.
NOTE:To install the WINS Server Service, you must be a member of the Administrators group on the computer on which you want to install the service.
Follow these steps to install the WINS Service:
- Launch the Control Panel Network applet.
- Click the Services tab, and then the Add button.
- Select Windows Internet Name Service from the list of network services.
NOTE:If you don't have TCP/IP already, when you install the WINS Server Service, TCP/IP will be automatically installed.
TIP:To use SNMP to configure the WINS Server Service remotely, install the SNMP Service as well.
- Click the OK button. When prompted, enter the path to the distribution files (that is, f:\i386) and click the Continue button.
- Click the Close button to close the Network Control Panel.
- When prompted, restart your system. After the system restarts, the WINS Server Service should be activated. If not, check your system event log for any error messages.
Configuring the WINS Service with the WINS Manager
The first time you use the WINS Manager, it displays only the WINS Server on the local computer. To add WINS Servers to the WINS Manager, choose Server | Add WINS Server and then supply the IP address or computer name in the Add WINS Server dialog box. To delete a WINS Server from your WINS Manager list, select it and then choose Server | Delete WINS Server. After adding your WINS Servers to the local WINS Manager, you should configure the local WINS Server for optimal performance. This includes setting your WINS Server configuration, replication partners, and preferences. Each of these options performs a slightly different task, which this section covers.
The first recommended option is to choose Server | Configuration, which displays the WINS Server Configuration dialog box. (See Figure 12.9.)
Figure 12.9
The expanded WINS Server Configuration dialog box.
You can set the following options in the WINS Server Configuration dialog box:
- Renewal Interval: Specifies how often a WINS client has to register its name with the WINS Server. The default is 6 days.
- Extinction Interval: Specifies the time interval between when a record is marked as released and when it is marked as extinct. The default and maximum time is 6 days.
- Extinction Timeout: Specifies the time interval between when a record is marked as extinct and when it is scavenged from the database. The default is 6 days and the minimum is 1 day.
NOTE:The extinction interval and extinction default for a fully configured WINS Server is based on the renewal time and whether the WINS Server has replication partners on the replication time interval.
TIP:You can manually scavenge the database by choosing Mappings | Initiate Scavenging. This process removes outdated records from the database.
- Verify Interval: This specifies the time interval in which a WINS Server must verify that old names owned by another WINS Server are still valid. The default (24 days) is dependent on the extinction interval. The maximum is 24 days.
- Pull Parameters: The pull partner replication interval is set in the Preferences dialog box, as described later in this section. If you want the replication to be triggered when the WINS Server Service starts, enable the Initial Replication checkbox and specify a number in the Retry Count list box.
- Push Parameters: To configure push partner configurations, you can enable these checkboxes:
Initial Replication: If this setting is enabled, then push partners are informed that a change has occurred when the WINS Server Service is started.
Replicate on Address Change: If this setting is enabled, push partners are informed whenever an entry in the database changes or when a new entry is added.
- The Advanced button: You can access the following options by clicking the Advanced button to expand the WINS Server Configuration dialog box:
Logging Enabled: This specifies that the WINS Server service will log database changes and inform you of basic errors in the system event log. The default is enabled.
Log Detailed Events: This specifies that detailed events will be written into the system event log. It should be used only for a limited time, such as when you are troubleshooting WINS Server problems, because it can consume considerable resources and affect system performance. The default is disabled.
Replicate Only with Partners: This allows replication only with push or pull partners. If this option is disabled, you can replicate data from any unlisted WINS Server. The default is enabled.
Backup on Termination: This automatically backs up the WINS database whenever the WINS Server Service is shut down. It does not perform a backup whenever the system is shut down, however. The default is enabled.
Migrate On/Off: This enables or disables the treatment of static or multihomed records as dynamic whenever they conflict with a new registration or replica (data copied from another WINS Server). This option should be enabled if you are upgrading a non-Windows NT System (such as a LAN Manager server) to a Windows NT Server. The default is disabled.
Starting Version Count: This specifies the highest database version number. Normally, you do not need to change this value; however, if you restore the WINS database from a backup because your primary database is corrupted, you should increment this value to a number higher than any other copy of the WINS Server partners to ensure proper replication.
NOTE:You can display the current value by choosing View | Database from the menu. To see the version numbers on other WINS Servers, choose the WINS Server before making the menu selection.
Database Backup Path: This specifies the full path to use for the backup copies of the WINS Server database.
I suggest setting your preferences for the WINS Manager and default settings for the WINS Service. You can access these preferences by choosing Options | Preferences to display the dialog box shown in Figure 12.10.
Figure 12.10
Specifying the WINS Manager preferences and WINS Server Services defaults.
You can take the following actions from this dialog box:
- Specify how the WINS Manager displays the names for the WINS Servers it is connected to and, incidentally, the mechanism used for connecting to the service. These options follow:
Computer Name Only: Specifies that the computer name is displayed and uses named pipes to connect to the WINS Server.
IP Address Only: Specifies that the IP address is displayed and uses TCP/IP to connect to the WINS Server.
Computer Name (IP Address): Specifies that the computer name is displayed first and then the IP address, and uses named pipes to connect to the WINS Server.
IP Address (Computer Name): Specifies that the IP address is displayed first, followed by the computer name; also specifies that TCP/IP be used to connect to the WINS Server.
- Specify the refresh interval for updating the WINS Manager display. If you enable the Auto Refresh checkbox, then you also should specify a value (number of seconds to wait before updating the display) in the Interval field.
NOTE:The WINS Manager display is also refreshed automatically whenever you initiate an action with the WINS Manager.
- Specify the NetBIOS name compatibility. If the LAN Manager Compatible checkbox is enabled (the default setting), then NetBIOS names are limited to 15 bytes to contain the name, whereas you are limited to 16 bytes for a special code for static mappings. If you use other applications that require a 16-byte NetBIOS name, such as Lotus Notes, this option should be disabled. The special codes follow:
0x0 Specifies that the NetBIOS name is used by the Redirector.
0x1 Specifies that the NetBIOS name is used by the master domain browser.
0x3 Specifies that the NetBIOS name is used by the messenger service.
0x20 Specifies that the NetBIOS name is used by a LAN Manager server.
0x1B Specifies the master browser name that clients and browsers use to contact the master browser.
0x1E Specifies that the NetBIOS name is used for a normal group.
0x1D Specifies that the NetBIOS name is used for client name resolution when an attempt is made to contact the master browser for server lists.
0x1C Specifies that the NetBIOS name is an Internet group name. An Internet group name contains the addresses of the primary and backup domain controllers for the domain. This name is limited to 25 addresses.
- Specify the miscellaneous support options:
Validate Cache of "Known" WINS Servers at Startup Time: If this option is enabled, whenever you start the WINS Manager, it attempts to connect to all WINS Servers you have added. If a WINS Server cannot be contacted, you are prompted to remove the WINS Server from the list of connected servers. The default is disabled.
Confirm Deletion of Static Mappings and Cached WINS Servers: This option, if enabled (the default), prompts you with a message box whenever you attempt to remove a static mapping or cached WINS Server. I find the constant message boxes a bit annoying and usually disable this setting. However, before you do so, I suggest that you become familiar with the WINS Manager.
- If you click the Partners button, the dialog box expands and enables you to set defaults for the partner replication. These settings follow:
New Pull Partner Default Configuration: The entries in this group specify the default replication settings for new pull partners that you create for the currently selected WINS Server. These options follow:
Start Time: The time to start your WINS Server database replication. There is no default, although I like to start at 12:00 a.m.
Replication Interval: The interval at which to repeat the WINS Server database replication. There is no default, although I generally choose a 15-minute interval for LAN WINS Servers.
New Push Partner Default Configuration: The entry in this group specifies the number of changes that must occur in the WINS Server database before a push notification is sent to the push partners that you create for the currently selected WINS Servers.
Update Count: This specifies the number of changes that must occur before a push notification is sent. There is no default, although I recommend a value of 1,000.
I suggest that you set the replication settings for the local WINS Server by choosing Server | Replication Partners. This displays the Replication Partners dialog box shown in Figure 12.11. Click the Add button to add the WINS Servers to be configured as the local push or pull partners. You can choose to replicate to any or all WINS Servers in a nonlinear fashion, or you can choose to pull from one WINS Server and push to another in a linear fashion. These techniques are described in more detail in the section titled "Planning Your WINS Installation."
Figure 12.11
Specifying the WINS Server replications partners.
NOTE:To remove a WINS Server from the WINS Server list, select it and press the Delete key.
After you add your WINS Servers, you can take the following actions:
- Specify the WINS Servers to display in the WINS Server list by enabling or disabling the options in the WINS Servers To List section. These options follow:
Push Partners: If enabled (the default), push partners of this WINS Server are displayed.
Pull Partners: If enabled (the default), pull partners of this WINS Server are displayed.
Other: If enabled (the default), any nonpartner of this WINS Server is displayed.
- Specify the individual settings for the currently selected WINS Server to be a push, pull, or both partner in the Replication Options section. When you select a WINS Server that is already configured as a push or pull partner, the following Configure buttons are enabled:
Push Partner: This specifies that the selected WINS Server is a push partner. You can then click the Configure button to display the Push properties dialog box, where you can view or set the update count.
Pull Partner: This specifies that the selected WINS Server is a pull partner. You can then click the Configure button to display the Pull properties dialog box, where you can view or set the start time and replication interval.
TIP:If you specified the default values in the Preferences dialog box, these settings are set automatically for new push or pull partners. If you are configuring a push or pull partner across a WAN link, however, you should set higher values, as described in the section titled "Planning Your WINS Installation."
- Initiate a replication trigger immediately instead of waiting for it to occur on the basis of the replication times set in the Configuration dialog box by setting the following values in the Send Replication Trigger Now group:
Push: This initiates a push trigger to send to the selected WINS Server.
Pull: this initiates a pull trigger to send to the selected WINS Server.
Push with Propagation: This modifies the Push message to indicate that changes sent to the selected WINS Server should be propagated to all other pull partners of the selected WINS Servers.
TIP:You can initiate a complete replication to the selected WINS Server by clicking the Replicate Now button.
Managing Your Non-WINS Clients
Managing your non-WINS clients consists of creating static mappings, which is a permanent computer name—to—IP address record, and viewing your current database records. When you create a static mapping, it is also a good idea to create a reservation (as described in the section "Managing Client Reservations") for this IP address to provide a more manageable environment. You can add static mappings by choosing Mappings | Static Mappings, which displays the Static Mappings dialog box, as shown in Figure . After you click the Add Mappings button, the Add Static Mappings dialog box appears. Here, you can enter a computer name, IP address, and type that will be added to the WINS Server database. Table 12.4 describes the special names the WINS Server uses and how WINS manages these names. You can delete a static mapping by selecting the mapping in the Static Mappings dialog box and then clicking the Delete Mapping button.
12.12
Figure 12.12
The Static Mappings dialog box.
TIP:You can import a series of static mappings by importing a host file from a DNS server to support your non-WINS computers.
Table 12.4. WINS server special names.
| Type | Description |
| Unique | A normal name, implying that only one computer name will be associated with the IP address. |
| Group | Does not have an associated IP address. Instead, when a group name is registered with the WINS Server and a name query request for this name is received, the WINS Server returns the broadcast address (FFFFFFFF) and the requesting client issues a broadcast message to find the requested computer. |
| Multihomed | A name that has multiple IP addresses associated with it. A multihomed device contains two or more network adapters that can register each IP address associated with the computer by sending a special name registration packet. A multihomed group name can contain a maximum of 25 IP addresses. |
| Internet | A group name that contains domain controller IP addresses. WINS gives preference to this name registration to the closest 25 addresses. After a request is received for the domain, the domain controller address and the additional 24 (maximum) IP addresses are returned to the client. |
Managing WINS Databases
Because your WINS Server also uses the same database format (a modified Access database), it has the same basic issues as the databases for the DHCP Server. As records are added and deleted, the database grows. The WINS databases are located in the %SystemRoot%\System32\WINS directory and include the following:
- WINS.MDB: The WINS database
- WINSTMP.MDB: A temporary file created by the DHCP Server
- JET.LOG: Contains transaction records
- SYSTEM.MDB: Contains structural information about the WINS databases
The database growth affects the performance of the WINS Server. As your WINS.MDB database approaches the 30MB limit, you should compact it. To do so, follow these steps:
- Stop the WINS Server Service from the Control Panel Services applet, or issue the net stop wins command from a console prompt.
- From a console prompt, run the JETPACK.EXE program, which is located in your %SystemRoot%\System32 directory. The syntax for this program follows:
JETPACK DatabaseName TemoraryDatabaseName
Here, DatabaseName is the name of the database to compact. It can be a fully qualified path name.
TemporaryDatabaseName is a name to use as a temporary database. It also can be a fully qualified path name.
WARNING: Do not compact the SYSTEM.MDB file. If you do, the WINS Server service will not start. If this occurs, restore your configuration from a previous backup.
- Start the WINS service from the Control Panel Services applet, or issue a net start wins command from a console prompt.
TIP:Before you back up or compact the database, choose the Mappings | Initiate Scavenging command to delete old records that are no longer needed.
TIP:Because the potential for failure or just plain data corruption on your %SystemRoot% partition is possible with the compact utility, you should back up your WINS databases regularly, and definitely before you compact it. You can do this by choosing Mappings | Backup Database. Be sure to perform a full backup by disabling the Perform Incremental Backup option if you plan to use this copy to restore your configuration.
Monitoring the WINS Server Service
Although the WINS Manager displays the same statistics as those used by the Performance Monitor, the WINS Manager can display only the statistics for the currently selected WINS Server. If you use the Performance Monitor, however, you can monitor multiple WINS Servers simultaneously. This can be of enormous benefit when you are comparing the performance of multiple WINS Servers. Table 12.5 lists the available WINS Server performance object counters that you can use to monitor your selected WINS Server. For additional details on how to use the Performance Monitor, see Chapter 19 titled Performance Tuning and Optimization.
Table 12.5. The Performance Monitor object types and object counters for the WINS server.
| Object Counter | Description |
| Failed Queries/sec | Total number of failed queries per second. |
| Failed Releases/sec | Total number of failed releases per second. |
| Group Conflicts/sec | The rate at which group registration received by the WINS Server resulted in conflicts with records in the database. |
| Group Registrations/sec | The rate at which group registrations are received by the WINS Server. |
| Group Renewals/sec | The rate at which group renewals are received by the WINS Server. |
| Queries/sec | The rate at which queries are received by the WINS Server. |
| Releases/sec | The rate at which releases are received by the WINS Server. |
| Successful Queries/sec | Total number of successful queries per second. |
| Successful Releases/sec | Total number of successful releases per second. |
| Total Number of Conflicts/sec | The sum of the unique and group conflicts per second. This is the total rate at which conflicts were seen by the WINS Server. |
| Total Number of Registrations/sec | The sum of the unique and group registrations per second. This is the total rate at which registrations are received by the WINS Server. |
| Total Number of Renewals/sec | The sum of the unique and group renewals per second. This is the total rate at which renewals are received by the WINS Server. |
| Unique Conflicts/sec | The rate at which unique registrations and renewals received by the WINS Server resulted in conflicts with records in the database. |
| Unique Registrations/sec | The rate at which unique registrations are received by the WINS Server. |
| Unique Renewals/sec | The rate at which unique renewals are received by the WINS Server. |
TIP:To get a feel for how well your WINS Server is performing, monitor the total number of conflicts, registrations, and renewals. You also should monitor the failed queries and releases.
Using WINS Server Registry Keys
The WINS Server Service also stores its configuration information in the Registry, just as the DHCP Server Service does. And, once again, you may need to modify the Registry to modify one or more configuration settings if you cannot set them from the WINS Manager or you are administering an inactive WINS Server. I am issuing this warning again because if improperly used, the Registry Editor can damage your system beyond repair. Refer to Chapter 21, "Understanding the Registry," for additional information and some tips for backing up your current Registry before using the Registry Editor (REGEDT32.EXE).
The following primary Registry keys are located in the HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\WINS\Parameters key:
- DbFileNm: This specifies the full path name to the locations of the WINS database file. The default is %SystemRoot%\System32\WINS\WINS.MDB.
- DoStaticDataInit: If this item is set to 1, the WINS Server initializes its database with records from one or more files in the DataFiles subkey. This initialization is performed at the time the process is executed and whenever a change to a key in the Parameters or Datafiles subkey occurs. If set to the default (0), then this initialization does not occur.
- [lb] InitTimePause: If this entry is set to 1, the WINS Service starts in the paused state. It stays in this state until it replicates with its partners (push or pull) or fails in the replication attempt (at least once). If this entry is set to 1, the WINS\Partner\Pull\InitTimeReplication subkey should be set to 1 or removed from the Registry for proper operation. A value of 0 (the default) disables this option. NOTE:
You can set the InitTimeReplication key value by choosing Options | Preference and clicking the Advanced button to expand the dialog box.
- LogFilePath: This specifies the location for the WINS Server log files. The default is %SystemRoot%\System32\WINS.
- McastIntvl: This specifies the time interval, in seconds, for the WINS Server to send a multicast and announce itself to other WINS Servers. The minimum and default value is 2400 (40 minutes).
- McastTtl: This specifies the number of times a multicast announcement can cross a particular router. The default is 6, and the range is 1 to 32.
- NoOfWrkThds: This specifies the number of worker threads used by the WINS Server. The default is one per processor on the system, with a range of 1 to 40. NOTE:
You can change this value and place it into effect without restarting the WINS service.
- PriorityClassHigh: If set to 1, this entry enables the WINS service to run in the high priority class. This prevents other applications and services running in lower priorities from preempting the WINS service. The default is 0. NOTE:
If you choose to enable this setting, make sure that you monitor the system with the performance monitor to ensure that the WINS service is not using too much processor time and that other applications and services continue to function properly.
- UseSelfFndPnrs: This option is used to configure the WINS service to automatically find other WINS servers and configure them as push and pull partners. Set this entry to 1 (to enable it) or 0 (to disable it). The default is 0. If the push and pull partners are configured manually with the WINS Manager, then the partnership information no longer is maintained automatically when a change occurs.
NOTE:If the UseSelfFndPnrs option is enabled, the WINS Service only configures WINS Servers as push and pull partners across routers if the routers support multicasting. Otherwise, only WINS Servers found on the local subnet are configured automatically as partners. If your routers do support multicasting, UseSelfFndPnrs can be a useful item to set because it relieves you of the burden of configuring your push and pull partners manually.
You can configure the following Registry keys by choosing Server | Configuration and modifying the entries in the WINS Server Configuration dialog box:
- BackupDirPath: This specifies the full pathname to the location to be used to back up the WINS database.
- DoBackupOnTerm: If enabled (1), the WINS database is backed up whenever the WINS Service is terminated. If disabled (0), the database is not backed up when the service is terminated. The default is 1. NOTE: The backup does not occur if the system is shut down. A backup occurs only when the service is stopped manually.
- LogDetailedEvents: If enabled (1), verbose logging of WINS events occurs. The default is disabled (0).
- LoggingOn: If enabled (1), WINS messages are placed in the event log. If disabled (0), no events are placed in the event log. The default is 1.
- RefreshInterval: This specifies the time, in seconds, for the client to register its name with the WINS Server. The default is 0x54600 (4 days).
- RplOnlyWCnfPnrs: This enables (1) or disables (0) the capability to replicate a WINS Server from a WINS Server that is not a partner. The default is 1.
- MigrateOn: This enables (1) or disables (0) the treatment of unique and multihomed records as dynamic when a registration conflict is detected. The default is 0.
- TombstoneInterval: This specifies the time, in seconds, between when a client record is released and when it is marked as extinct. The default is 0x54600 (4 days).
- TombstoneTimeout: This specifies the time, in seconds, between when a client record is marked as extinct and when it is scavenged from the database. The default is 0x54600 (4 days).
- VerifyInterval: This specifies the interval in which the WINS Server must verify that old names, which it does not own, are still valid. The default is 0x1FA400 (24 days).
The following Registry keys for partner replication are located in the HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\WINS\Partners key:
- PersonaNonGrata: This specifies IP addresses for WINS Servers from which you do not want to replicate data. This key is useful for Administrators to block replication from WINS Servers that are not under their control.
- Pull\<IPAddress>\MemberPrec: This specifies the preference order of addresses in an Internet group. Values can be 0 for low precedence or 1 for high precedence. The default is 0. NOTE: This entry appears under an IP address (of a WINS Server).
Using the Microsoft Domain Name System (DNS) Server
Unlike WINS and DHCP, which are barely two years old, the DNS is a relative old-timer in the TCP/IP arena. The primary purpose of a DNS is to supply friendly computer names instead of an IP address to locate a resource. This process is often referred to as name resolution. The DNS was developed a number of years ago to solve the problems of dramatic growth in the Internet and is defined in RFCs 1034 and 1035. Because its development centered around the Internet, which has no single authority, DNS utilizes a hierarchical architecture that allows the distribution of the name database and the decentralization of administrative tasks.
WINS and DNS share many similarities, but they also have numerous differences, in both the scope of their jobs and their actual implementation. Whereas WINS provides dynamic name resolution, DNS is based on static configuration files. DNS, on the other hand, allows hierarchical naming, whereas WINS, because of its ties to NetBIOS, only provides for a flat filename space. The major job of WINS is to provide name registration and resolution, whereas DNS also provides other services, such as mail exchange information that enables electronic mail to be properly routed for the entire domain. On a more bit-pushing level, DNS uses UDP port 53, and WINS uses UDP ports 137 and 138, which are reserved for NetBIOS name services.
CAUTION:Do not confuse the TCP/IP domain with the NT domain. DNS uses a hierarchical naming system, which is composed of a computer name and a domain name. The domain name provides information for locating the computer. An NT domain, in contrast, is a security database for managing an NT network. The computer's NT domain name, which follows a flat-file naming scheme, will always be different from the DNS domain name, which follows a hierarchical naming scheme. For example, an NT system might be a member of the XYZ-PROCURE NT domain, but its TCP/IP DNS domain name is xyzcorp.com.
The Design Goals for the Microsoft DNS service
Although you can use other DNS servers on your network, the Microsoft DNS Service that ships with NT Server 4.0 is the only one that can integrate with the WINS service to provide dynamic DNS. This is the real difference between the Microsoft DNS implementation and other DNS servers that run under Windows NT. The Microsoft implementation fully supports WINS, which in turn is aware of DHCP. If you use DHCP, WINS, and DNS together, then you too have the following capabilities:
- Utilizing DHCP, your clients automatically receive dynamic IP addresses and TCP/IP configuration information. Thus you can centrally administer IP assignments, provide support for roaming, clean up IP allocation by automatically returning unused IP addresses to the available pool for reuse, and have all the other benefits of DHCP.
- Utilizing WINS, machines automatically register their NetBIOS computer name and IP address, every time they start up. If the computer moves between subnets, this information is automatically updated as well.
- Utilizing DNS, your clients can find any non—WINS-aware resources through the static mappings maintained in the configuration files. This also works in reverse. Any non—WINS-aware client that uses DNS to resolve names and has a static mapping to your DNS service can locate a WINS client, even if the IP address is dynamically assigned with DHCP.
This combination of DHCP, WINS, and DNS provides additional benefits as well. Dynamic address allocation also means dynamic address recovery. When a new IP address is allocated to a client on another subnet, then the old address is released back to the DHCP scope's address pool. This can prevent the confusion caused by a duplicate IP addresses on the network. The only thing DHCP and WINS will not do for you is make it easy to get on the Internet. One of the requirements for registering your Internet domain with the InterNIC is that you maintain two or more DNS servers on your network so that clients that want to connect to your server, most likely your WWW page, can find you. You'll find that many Internet Service Providers (ISPs) don't know how to deal with, or support, DHCP and WINS. So you may as well get used to using a DNS server if you plan to connect to the Internet, but you don't have to go through all the hassle of modifying your configuration files every time you move or add a client to your network if you also use DHCP and WINS.
Another benefit of using a DNS server is that it can provide some additional name resolution capabilities that WINS cannot. A DNS server includes e-mail name resolution by supporting the MX record type, which associates an e-mail address with a hostname. And when a DNS server cannot resolve a name locally, it will refer the name query to another DNS server higher up the chain in a effort to resolve it.
Planning Your DNS Installation
First, consider who will be in charge of maintaining the configuration files. DNS is not a simple subject to be taken lightly. Entire guides have been written discussing all the nuances associated with configuring DNS servers. Fortunately, Microsoft has included a graphical configuration tool, the DNS Manager, for working with the DNS service in NT Server 4.0. This utility enables you to forgo the archaic process of editing configuration files by hand. If you use the Microsoft DNS service, you are not forced to use the graphical configuration tool. But if you prefer, you can edit the configuration files by hand.
CAUTION:A duplicate hostname, or IP address, on your network can cause serious problems. Make sure your administrators are aware of this and that your registration plan includes the capability to register a name and IP address before it is reassigned. An access database could be used to maintain information (hostname, IP address, filename, and so on) about your network and could be queried to verify that the hostname and IP address are not in use.
First and foremost, make sure that everyone who will make modifications to the DNS service has the proper training to understand the consequences of their actions. It took a lot of people with doctoral degrees quite some time to make DNS as complicated as it ended up!
There are three main ways to configure your DNS service:
- Primary Name Server: The primary name server for a domain holds the master copy of the name database. This database contains the records for all hosts in the zone, as well as records for all the subdomains.
- Secondary Name Server: Secondary name servers holds a copy of the record database for the domain and subdomains. When changes are made to the domain, they are made to the primary DNS, and the updated database is replicated to all secondary DNS servers.
- Caching Name Server: A caching name server does not actually contain a copy of the record database. Instead, it is configured with the address of either a primary or secondary DNS for a particular domain. When a caching name server receives a name query request, it asks the other name server to resolve the request. It then caches this information so that when it is asked for again, it will already cached. Effectively, the caching name server holds the all the frequently visited locations, and the size of its cached database will grow with time and use.
On a larger network, you might consider running multiple DNS servers to serve different subnets. This is an effective means of providing load balancing, fault tolerance, and improving network performance by limiting network traffic associated with name resolution.
Installing the Microsoft DNS Server Service
You can install the DNS Server service through the Network Control Panel applet. Follow these steps:
NOTE:To install the Microsoft DNS Server service, you must be a member of the Administrators group on the computer on which you want to install the service.
- Launch the Control Panel Network applet.
- Click the Services tab, then the Add— button.
- Select Microsoft DNS Server from the list of network services.
NOTE:If you don't have TCP/IP already, when you install the DNS Server Service, TCP/IP will be automatically installed.
- Click the OK button. When prompted, enter the path to the distribution files (that is, f:\i386) and click the Continue button.
- Click the Close button to close the Network Control Panel.
- Restart your system.
When you restart your system, the DNS Server will start automatically.
Managing the DNS Server with the DNS Manager
Your interface to managing the DNS Service is the DNS Manager. It is installed in the Administrative Tools program group when you install the DNS service. You must have administrative privileges to use this program. With the DNS Manager, you can do everything but stop or start the DNS Service. To stop or start the service, use the Control Panel Services applet and specify the Microsoft DNS Server as the service to control. Or, you can issue the following commands from a console prompt:
net stop dns
net start dns
The DNS Manager enables you to work with the DNS zones, the administrative unit in the DNS. This section discusses how to create a zone, create domains and subdomains within the zone, and manage hosts and other records in a domain. We also explore and learn more about the configuration files that form the heart of the DNS database. We also demonstrate how to configure the Microsoft DNS server service to take advantage of the WINS server for name resolution.
Creating a Zone
A zone is the administrative unit in the domain name system, so the first thing to do when you install the DNS service is to create a zone. A zone represents a subtree of the DNS, such as xyzcorp.com. For example, you could configure your system such that the domain xyzcorp.com, the subdomain eng.xyzcorp.com, and the subdomain admin.xyzcorp.com are all part of a single administrative zone configured by one organization. A separate organization could then be responsible for maintaining a zone that consists of the subdomains research.xyzcorp.com and testing.xyzcorp.com. This is part of the distributed nature of DNS.
The interface of the DNS Manager is similar the DHCP Manager and the WINS Manager. The first time you launch the DNS Manager tool it shows address of the local machine, as shown in Figure .
12.13
Figure 12.13
By default the DNS Manager focuses on the local machine.
If you have other NT Servers on the network running DNS, you can add them to the DNS Manager display using the following steps:
- Choose New Server from the DNS menu.
- Type in the fully qualified domain name or the IP address of the NT Server you wish to administer.
- Click OK. The IP address or hostname appears under the Server List.
- Repeat these steps for each NT Server running the DNS service you want to administer from your local machine.
NOTEYou can only use the DNS Manager to administer NT Servers running the DNS service. As nice as it would be, the DNS Manager cannot be used to configure non-NT DNS servers, such as those running on the UNIX platform.
To create an administrative zone, follow these steps:
- In the Server List, click the DNS server you want to administer.
- Choose New Zone from the DNS menu. The Create New Zone window appears.
- Choose Primary, and click the Next button.
- Give your zone a name, such as xyzcorp.com. You must also enter a filename for the zone. All the information for this zone is stored in %systemroot%\system32\dns\filename, where filename is the name of the file you enter here.
- Click the Next button, then click the Finish button.
The zone is now created and should appear under the listing for your server, as shown in Figure 12.14.
Figure 12.14
The xyzcorp.com zone now exists as an administrative unit on the local server.
By default, two records are created in the domain, an NS entry and an SOA entry. The NS record specifies the selected machine as a name server in the domain, and the SOA record is known as the Start of Authority. Every domain must contain an SOA, which details the name server that is the best source of authoritative information for the zone, as well as the e-mail address of a contact responsible for the domain.
Enabling WINS Resolution for the Zone
You can enable WINS resolution on a zone-by-zone basis. When the DNS is asked to resolve a DNS name and it can't find an entry for the name anywhere in the DNS database, the NT DNS service takes the left-most part of the hostname (the characters up to the first period) and passes this to the WINS server for resolution. If the WINS server has a matching NetBIOS name in its database, it returns the corresponding IP address to the DNS service, which returns it to the client. The client can then attach to the resource. As you can see, this is an effective means of permitting the DNS service to resolve even dynamically assigned IP addresses, because the WINS server understands dynamic addressing.
NOTE:The NT DNS server will only attempt to use WINS for resolution if it cannot find a matching hostname anywhere in its database.
To enable WINS resolution for a particular zone, follow these steps:
- Click the zone for which you want to enable WINS resolution.
- Choose Properties from the DNS menu.
- Click the WINS Resolution tab.
- Check the box for Use WINS Resolution.
- Enter WINS Servers in the order they should be queried, as shown in Figure 12.15
Figure 12.15
Enter WINS servers in the order they should be queried.
- Click OK to close the properties window for the zone.
- A WINS server record should appear in the zone information list for each WINS server you configured, as shown in Figure 12.16.
Figure 12.16
A zone record is created for each WINS server to be used for resolution.
Creating Subdomains
The DNS is a hierarchical naming system. This means that you can create nested domains to divide the network into administrative units. For most standard configurations, especially those connected to the Internet, your zone name will be the same as your base domain. For example, my company is called XYZ Corporation, so our domain is xyzcorp, but it is part of the .com hierarchy. So my complete domain name is xyzcorp.com. Now I can subdivide that domain into additional units by creating subdomains. For instance, if I want to use different domains for our administrative group and our testing group, I could call them admin.xyzcorp.com and testing.xyzcorp.com.
To create subdomains, use the following procedure:
- Click the zone where you want to create a subdomain.
- Choose New Domain from the DNS menu.
- Enter the name for the subdomain, such as admin or testing, and click OK.
- The new subdomain appears under the selected zone in the DNS Manager, as shown in Figure 12.17.
Figure 12.17
Subdomains appear under their respective zones.
TIP:You can create hostnames with the same name as a subdomain. For instance, admin.xyzcorp.com can refer to a machine name, but it can also refer to a subdomain that contains other machines, such as ftp.admin.xyzcorp.com.
Adding Hosts to a Domain
Now that you have created a domain, you can add hosts to populate it. To add a host, follow these steps:
- Click the domain (zone) or subdomain where you want the host to reside, such as xyzcorp.com.
- Choose New Host from the DNS menu.
- Enter the hostname and IP address, such as secundus and 128.1.1.2.
- To create an associated PTR record, click the Create Associated PTR Record button.
- Click the Add Host button, then click the Done button.
- A new record of type A is created for the host, as shown in Figure 12.18 for secundus.
Figure 12.18
A record of type A is created when you add a new host.
Adding a New Record
As mentioned earlier, the DNS provides many more services than just simple name—to—IP address resolution. Other services are provided by adding appropriate records to the domain. For instance, to specify a server to handle incoming e-mail for computers in the domain, you could create an MX record to identify the mail server.
To add records to the domain, follow these steps:
- Click the zone or subdomain where you want to create the new record.
- Choose New Resource from the DNS menu. The New Resource Record windows appears.
- Select the type of record you want to create, for example, an MX record. A description of the selected record type appears at the bottom of the screen, and the fields on the right change depending on the requirements of the particular record type, as shown in Figure 12.19.
Figure 12.19
The MX record type is used to specify a mail exchanger for the domain.
- Enter the remaining information required for the particular record type, such as the mail exchanger's DNS name and preference number in the case of an MX record type.
- Click OK.
The new record now appears in the domain listing.
The DNS Service Configuration Files
If you are the kind of person who likes to look at the nuts and bolts to see how things work, you actually have the option of directly viewing and editing the DNS configuration files. They are stored in the %systemroot%\system32\dns directory. The configuration files used with the Microsoft DNS server can be replaced by those from a UNIX BIND installation if you are migrating or interoperating with a UNIX system—although you may need to modify the files if you are using some outdated BIND commands.
NOTE:Before editing the DNS files directly, make sure they are up to date by issuing the Update Server Data Files command from the DNS menu in the DNS Manager application.
The configuration files for BIND are divided into four basic types:
- BOOT: This file controls the startup behavior of the DNS server. It includes information on the default directory where the configuration files reside, the cache filename, the domain name the DNS server will service, and the domain name for secondary DNS servers.
NOTE:The Microsoft DNS service can be configured to store the boot information in either the boot file, located in the %systemroot%\system32\dns directory or the Registry.
- CACHE: This file contains information for Internet connectivity.
- PLACE.DOM: This file contains information on hostnames in the domain. It also includes references to reverse lookup filenames and WINS servers.
- ARPA-###.REV: These files (there should be one per subnet) include information to resolve an IP address to a hostname.
BOOT
There are very few commands supported in the boot file, so the syntax for the commands, as summarized in Table 12.6, is fairly easy to remember. An example BOOT file for a simple network, such as the one in my office, looks like this:
; DNS BOOT FILE - Master configuration for DNS service
directory %System32%\system32\dns
cache . cache
primary xyzcorp.com xyzcorp.dom
primary 127.in-addr.arpa arpa-127.rev
primary 128.1.1.in-addr.arpa arpa-128.rev
Table 12.6. Applicable commands for the BOOT file.
| Command | Required | Description | Note |
| ; | No | Starts a comment. | Avoid using unnecessary comments because the file is parsed line by line. Each comment added to the file slows down name resolution for any name not in the cache. |
| directory PathName | No | Describes the location of the DNS configuration file where PathName is a fully qualified path. The default, if not specified is %SystemRoot%\Sysstem32\DNS | If the directory cannot be found, then the DNS service will not start. |
| cache FileName | Yes | Describes the location of the cache file used to find additional name servers, where FileName is the name of the file. | If the file cannot be found, the DNS service will not start |
Primary
DomainName
FileName | Yes | Specifies a domain DomainName name for which FileName this DNS server is authoritative and a configuration file name that contains information for the domain.
| Secondary
DomainName
HostList [FileName] | No | Specifies a domain name and associated IP address array from which to download zone information. | If a filename is specified, then the zone information will be downloaded and used if the domain DNS server, or alternate, cannot be located |
CACHE
The cache file is used for additional name resolution. When your DNS server cannot resolve a name, it queries the additional name servers listed in this file. If you are using this DNS server to resolve names on the Internet, your file should look similar to the following:
; DNS CACHE FILE
; Initial cache data for root domain servers.
; YOU SHOULD CHANGE:
; - Nothing if connected to the Internet. Edit this file only when
; update root name server list is released.
; OR
; - If NOT connected to the Internet, remove these records and replace
; with NS and A records for the DNS server authoritative for the
; root domain at your site.
; Internet root name server records:
; last update: Sep 1, 1995
; related version of root zone: 1995090100
; formerly NS.INTERNIC.NET
. 3600000 IN NS A.ROOT-SERVERS.NET.
A.ROOT-SERVERS.NET. 3600000 A 198.41.0.4
; formerly NS1.ISI.EDU
. 3600000 NS B.ROOT-SERVERS.NET.
B.ROOT-SERVERS.NET. 3600000 A 128.9.0.107
; formerly C.PSI.NET
. 3600000 NS C.ROOT-SERVERS.NET.
C.ROOT-SERVERS.NET. 3600000 A 192.33.4.12
; formerly TERP.UMD.EDU
. 3600000 NS D.ROOT-SERVERS.NET.
D.ROOT-SERVERS.NET. 3600000 A 128.8.10.90
; formerly NS.NASA.GOV
. 3600000 NS E.ROOT-SERVERS.NET.
E.ROOT-SERVERS.NET. 3600000 A 192.203.230.10
; formerly NS.ISC.ORG
. 3600000 NS F.ROOT-SERVERS.NET.
F.ROOT-SERVERS.NET. 3600000 A 39.13.229.241
; formerly NS.NIC.DDN.MIL
. 3600000 NS G.ROOT-SERVERS.NET.
G.ROOT-SERVERS.NET. 3600000 A 192.112.36.4
; formerly AOS.ARL.ARMY.MIL
. 3600000 NS H.ROOT-SERVERS.NET.
H.ROOT-SERVERS.NET. 3600000 A 128.63.2.53
; formerly NIC.NORDU.NET
. 3600000 NS I.ROOT-SERVERS.NET.
I.ROOT-SERVERS.NET. 3600000 A 192.36.148.17
; End of File
NOTE:An updated version of this file can be found at the InterNIC FTP site ftp.rs.internic.net. Just log on anonymously, change to the domain directory and download the file named.root.
If this DNS server will not be used for Internet name resolution, then replace the name server (NS) and address records with the authoritative DNS server for your domain.
PLACE.DOM
PLACE.DOM is the heart of your DNS server's operation. It contains several record types, as summarized in Table 12.7, which are used to provide name resolution for the domain. Because the example file included with the Microsoft DNS service contains information for a nonexistent domain, you should rename the file and modify it as appropriate for your domain. The following is a copy of my replacement file called xyzcorp.dom. I use a naming convention of DomainName.dom, and I recommend you do as well. This is particularly useful when administering multiple domains.
@ IN SOA primus.xyzcorp.com. admin.primus.xyzcorp.com. ( ;source host e-mailaddr
1 ; serial number of file
10800 ; refresh interval
3600 ; retry interval
604800 ; expiration interval
86400 ) ; minimum time to live
@ IN NS primus.xyzcorp.com. ; name server for domain
primus IN A 128.1.1.1 ; IP address of name server
@ IN WINS 128.1.1.1 128.1.1.2 ; IP address of WINS servers
localhost IN A 127.0.0.1 ; loop back
@ IN MX 10 primus ; e-mail server
primus IN A 128.1.1.1 ; IP address of e-mail server
ftp IN CNAME primus ; alias name for FTP service
www IN CNAME primus ; alias name for WWW service
gopher IN CNAME primus ; alias name for Gopher service
The first entry in the file must be a SOA record. This record includes parameters that describe the source host (where the file was created); an e-mail address for the administrator of the file; a serial number (or version number) of the file; a refresh interval (in seconds), which is used by secondary servers to determine when a revised file should be downloaded; retry time (in seconds), which is used so that secondary servers will wait before attempting to download the file in case of error; and expiration time (in seconds), which is used by secondary servers to determine when to discard a zone if it could not be downloaded. Then your name servers (or DNS servers) for the domain should be listed followed by their IP addresses. Next, include the LocalHost identifier, which is used for loop back testing, the name and address of any mail servers, and hostname aliases. A hostname alias is used to provide a host (such as my server primus) with more than one hostname. This is particularly useful when you want your WWW site to be accessible in the commonly used format WWW.DomainName.COM (www.xyzcorp.com, for example) rather than ServerName.DomainName.COM (primus.xyzcorp.com, for example).
NOTE:When you specify a fully qualified domain name (FQDN), it must be appended with a period; otherwise the domain name is appended to the hostname for resolution and can cause the name query to fail. For example, if I had specified my domain name as xyzcorp.com in line 7 instead of xyzcorp.com. Then when trying to resolve the hostname primus.xyzcorp.com, the domain name of xyzcorp.com would be appended once again (primus.xyzcorp.com.xyzcorp.com). Because there is no host by that name, the query would fail.
Table 12.7. Supported domain name records.
| Identifier | Record Type | Description |
| A | Address | Specifies the IP address of the associated hostname. |
| CNAME | Class Name | Specifies an alias for the associated hostname. |
| MX | Mail | Specifies the e-mail server hostnames. |
| NS | Name Server | Specifies the DNS servers in the domain. |
| SOA | Start of Authority | The first record in any configuration file, used to specify name. |
| WINS | WINS | Specifies the IP addresses of WINS servers used for additional name resolution. |
ARPA-###.REV
ARPA-###.REV is used for reverse lookups of hostnames within a domain. Instead of resolving a name to an IP address, a reverse lookup resolves an IP address to a hostname. For example, for my domain, which only has one subnet (128.0.0.0), the reverse lookup file is as follows:
@ IN SOA primus.xyzcorp.com. admin.primus.xyzcorp.com. ( ;source host e-mailaddr
1 ; serial number of file
10800 ; refresh interval
3600 ; retry interval
604800 ; expiration interval
86400 ) ; minimum time to live
@ IN NS primus.xyzcorp.com. ; name server for domain
@ IN NBSTAT xyzcorp.com. ; domain name to append for NBSTAT lookups
1 IN PTR primus.xyzcorp.com. ; primus at 128.1.1.1
99 IN PTR winguidexp5.xyzcorp.com. ; Winguide XP5 at 128.1.1.99
Once again, the first record should be a SOA record. The next record lists the name (or DNS) server for the domain, followed by an NBSTAT record, then the individual PTR records for each host in the domain. These records and their usage are summarized in Table 12.8. What is generally most confusing is the PTR records. Instead of supplying a complete IP address (such as 128.1.1.1) for the host, you only supply the last digit of the IP address (such as 1) followed by the fully qualified hostname (host + domain name).
Table 12.8. Supported reverse lookup records.
| Identifier | Record Type | Description |
| NBSTAT | NBSTAT | Specifies the domain name to append to any hostname found by an NBSTAT lookup. |
| NS | Name Server | Specifies the DNS servers in the domain. |
| PTR | Pointer | Specifies an IP address for a host. |
| SOA | Start of Authority | The first record in any configuration file, used to specify name |
Summary
This chapter's focus is on implementing the DHCP, WINS, and DNS services on your network. We discuss the design goals for the services, basic planning issues, and the management options available for manipulating your DHCP and WINS clients.
We also mention specific issues for utilizing DHCP and WINS in a mixed Windows NT and UNIX environment, and, where prudent, how to prepare for the possibility of a failure with the services database, some registry keys you can use to configure otherwise unconfigurable options, and some basic performance tips.
| About us | Categories | New Releases | Most Popular | Web Tutorial | Free Download | Drivers |
|
|
|
