|
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, a
| |
