• 5 — Using DHCP, WINS, and DNS
• Using the Dynamic Host Configuration Protocol
• Examining Design Goals for the Microsoft DHCP Protocol
• Planning Your DHCP Installation
• Managing Your DHCP Server with the DHCP Manager
• Managing DHCP Scopes
• Managing DHCP Clients
• Managing the DHCP Databases
• Using DHCP Server Registry Keys
• Using the Windows Internet Name Service
• Examining Design Goals for the WINS Service
• Planning Your WINS Installation
• Configuring the WINS Service with the WINS Manager
• Managing Your WINS Clients
• Managing the WINS Databases
• Using Performance Monitor to Monitor the WINS Service
• Using WINS Server Registry Keys
• Using the Domain Name System
• Examining Design Goals for the Microsoft DNS Service
• Planning Your DNS Installation
• Using the DNS Service Configuration Files
• BOOT
• CACHE
• PLACE.DOM
• ARPA-###.REV
• Summary

—5 —
Using DHCP, WINS, and DNS

If you have a TCP/IP-based network (at the very least, your IIS servers must support TCP/IP) and you want to make your administrative life a little easier, then nothing is more important than the Dynamic Host Configuration Protocol (DHCP) and the Windows Internet Naming Service (WINS). These two services give you the capability to automatically manage your client TCP/IP IP address allocations and NetBIOS name resolution, respectively. If you want to connect your network to the Internet or support clients that do not support the Microsoft implementation of DHCP and WINS, however, you also will be interested in the Microsoft Domain Name System (DNS). This version of DNS is WINS aware, which enables you to have your DNS service query the WINS service for name resolution of any names not included in the static configuration files. You also can use the DNS service instead of DHCP and WINS, but I do not recommend it unless this is for a standalone server or Internet firewall, because DHCP and WINS are much easier to administer.

All these services are client/server applications. In these situations, you have a service running on your Windows NT Server domain controller, which is the server side of the component, and a service running on a network client, which is, of course, the client component. Current supported DHCP and WINS clients include Windows NT Workstations, Windows 95, Windows for Workgroups, and MS-DOS (including Windows 3.1) clients using the Microsoft Network Client 3.0 as their network interface. All the various clients support the Microsoft DNS implementation as well.

The basic goal of this chapter is to provide you with an understanding of these services so that you can properly implement the DHCP, WINS, and DNS services on your network. You will learn about design goals, configuration, and management of these services, which covers most of the administrative issues. You also will learn about interoperability with existing UNIX services, tips to get the maximum mileage from these services, and some of the possible problems (gotchas) to avoid.

Using the Dynamic Host Configuration Protocol

The DHCP service is based on the Request for Comment (RFC) 1541; it is not a newly invented mechanism by Microsoft for managing your TCP/IP IP address allocations. The Microsoft implementation varies a bit from the actual design goals specified in RFC 1541, but it fulfills the basic design functionality quite well for your Microsoft network clients. There are a few concerns for interoperation with your existing TCP/IP-based clients that do not support DHCP, as well as some specific times not to use DHCP. Both of these issues require that you maintain an LMHOST file on your Windows NT Server domain controllers or install the DNS service and configure your network servers and clients properly. I point out these issues as they arise throughout this chapter.

Note: You can find RFC 1541 (and other RFCs mentioned in this chapter) on the Internet at http://www.internic.net. It is a rather interesting document, and I highly recommend that you read it to get a fuller understanding of the DHCP service.

This discussion of the DHCP service begins with some of the design goals of the service and then moves on to planning your installation, and using the DHCP Manager to administer the DHCP service. Installing the DHCP service is covered in Chapter 3, "Preparing Your System for IIS." Administering your DHCP service consists of creating or deleting scopes and configuring individual scope properties. A scope is 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, or you can subdivide a subnet into multiple scopes. This section also looks at the DHCP database management required from time to time to improve performance and some of the registry keys that you cannot configure from the DHCP Manager.

Examining Design Goals for the Microsoft DHCP Protocol

As with all companies that introduce products to the market, Microsoft set definite goals to reach for implementing DHCP for its operating systems prior to releasing its product. 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 of your IP addresses and the configuration parameters for each are stored in a central database located on your 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 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. 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. Often, however, 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 are lost for reuse. However, DHCP uses a time-based mechanism, called a lease, that 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.
  
  

Planning Your DHCP Installation

If you have a small network with no UNIX-based interoperation required, you have a fairly easy DHCP server installation. But this does not mean that you can just install the DHCP server components and forget about it. Instead, it just means that fewer issues exist for you to contend with in your network installation. When you begin planning your installation, you must consider two types of network configurations. The first, as shown in Figure 5.1, is a simple network with only one subnet. The second, as depicted in Figure 5.2, is a network with multiple subnets. The most common configuration is one with multiple subnets, and that is where most of this discussion focuses.

Figure 5.1. An example network with a single subnet.

Figure 5.2. A network with multiple subnets.

A single subnet is the easiest with which to work. All the DHCP and WINS servers are located on the same subnet, so you have to be concerned with very little maintenance. Maintaining the LMHOST files is not difficult unless you use many MS-DOS or Windows 3.x clients using the Microsoft Network Client 3.0 software. Because these computers are all on a single subnet, you can use the B-node node type for name resolution and bypass WINS configuration and LMHOST file maintenance all together. It pays in performance, however, to use the same techniques this chapter describes 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 of the issues you need to think about are these:

• Routers: Your routers must support RFCs 1532, 1533, and 1541. These RFCs deal with the forwarding of packets required by the DHCP service. If your routers do not support these RFCs, your routers may discard the network packets required for DHCP operation. In this case, you might need a firmware upgrade. Consult your documentation to determine whether your routers support these specifications. If your routers do support these RFCs but you have connectivity problems, check your documentation to see whether the default configuration passes or drops these packet types.
  
  
• WINS configuration: If you are planning to use DHCP to configure your WINS clients automatically, be sure to set options 44 and 46 (this is mentioned again later in this chapter in "Managing DHCP Scopes"). 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 or to convert a NetBIOS name to a TCP/IP IP address. Supported node types are these:
  
  
B-node: Resolves names using broadcast messages. This option is the worst possible option 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. The only reason I would recommend using the B-node is for a very small network with a single subnet, and one that does not have a dedicated network administrator to maintain the network (using broadcasts essentially can eliminate the need to maintain an LMHOST file or WINS database, and for a small network, very little network bandwidth is eaten by the broadcasts).

Note: One good reason to use B-node is that computers located on the same segment still can find each other, regardless of whether the WINS server or DNS server is down or otherwise unavailable.

P-node: Resolves names with a name server (WINS or DNS) using point-to-point communications. Point-to-point communications are based on IP address to IP address as the communication linkage. This is the most efficient mechanism, but should be used only on networks with a dedicated administrator, and one that religiously updates the various LMHOST files on the network. (If these files are not updated, the client might not be able to find a resource by name, or the resource computer might not be able to find the client.)

Note: If you are using WINS, the updates should occur automatically, except for network clients using the Microsoft Network Client 3.0 software. These clients must have their IP addresses added to the LMHOST files of the DHCP servers or added to the configuration files for any DNS server on the network. The domain controller's TCP/IP configuration also must be configured to use the LMHOST file or DNS server.

M-node: Uses B-node first (broadcasts) to resolve the name, and then P-node (name queries) if the broadcast fails to resolve a name. This method works, but has the same issue as a B-node because it can flood the network with broadcasts.

H-node: 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. This is my recommended node type, because it first uses a point-to-point connection to find a resource's IP address, and only if that fails does it use a broadcast to find the resource. This is the most efficient node type to use, and it practically guarantees that the resource will be found even if the LMHOST file or WINS database does not contain the requested resource's IP address.

Note: H-node is the default node type when configuring TCP/IP manually unless the WINS IP address field is left empty.

• Multiple DHCP servers: If you are planning to implement multiple DHCP servers, which is a good idea to distribute the load on a large network, each DHCP server must have a statically assigned IP address. You must exclude these IP addresses from the DHCP scope that you create.
  
  

Note: 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 RFCs mentioned previously, in which case you should not use DHCP.

• 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 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, a name/address conflict probably will occur, which may prevent your clients from communicating or even cause your network to crash (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 database is backed up automatically, and this backup is used if the original is 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.
  
  
• Lease expiration: The minimum lease expiration should be twice the maximum expected server down time. If you plan to upgrade the server over the weekends, for example, the expiration time should be at least four days. This prevents a client from losing his lease and his IP address, which prevents the computer from communicating 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, you should be aware that not all of the DHCP configuration options are supported by the Microsoft client. Specifically, the Microsoft DHCP clients only use the configuration options as specified in Table 5.1. Any other options received by the client are ignored and discarded.

Table 5.1. Microsoft DHCP client configuration options.

Number

Name

Data Type

Description

The Microsoft DHCP client and server do not support option overlays. Using 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, and that these values fit into the Microsoft 312-byte DHCP network packet allocation. You should apply the same consideration if you are using the Microsoft DHCP server to support your third-party DHCP clients: Fit your most important configuration options first. Although you can use the additional configuration options to support your third-party DHCP clients, they are not used by your Microsoft DHCP clients.

Managing Your DHCP Server with the DHCP Manager

Your interface to managing the DHCP service is the DHCP Manager. It is installed in the Network Administration Program Manager group and requires administrative privileges to use it. You can use the DHCP Manager to do everything but stop or start the DHCP service. To stop or start the service, you need to use the Control Panel Service applet and specify the Microsoft DHCP service as the service to control. Alternatively, you can issue the net stop dhcpserver or net start dhcpserver command from a console prompt.

The DHCP Manager's primary function is to work with scopes. This includes creating, deleting, activating, and deactivating scopes; these topics are discussed in the following section. Next, you will learn how to manage your DHCP clients. This includes managing your client leases and reservations, as well as setting individual DHCP properties for a reserved client that differ from those defined for the scope as a whole. Finally, you will look at the DHCP database administration that is required from time to time. These sections will prepare you for your duties as a network administrator for managing your TCP/IP-based network.

Managing DHCP Scopes

Before you can use the DHCP server to assign TCP/IP IP addresses and relevant configuration options to your DHCP clients, you have to create a DHCP scope. A scope is the heart of your DHCP server service. It is based on an IP address range (or subnet). The scope 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. The following section discusses how to create, delete, activate, and deactivate DHCP scopes. Next, you will read about configuring global, local, or default scope properties.

When you run the DHCP Manager for the first time, it does not have any scopes defined for it, although it does include a listing in the DHCP Servers 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 displays a listing in the DHCP Servers window for each DHCP server on your network (see Figure 5.3). This listing enables you to manage your other scopes, as well as these additional scopes as a reference point when creating new scopes.

Figure 5.3. The Microsoft DHCP Manager with multiple DHCP servers and scopes.

To add additional DHCP servers to your local DHCP Manager, follow these steps:

1. Choose Server|Add or press Ctrl+A to display the Add DHCP Server to Server List dialog box.
   
   
2. 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 Servers window.
   
   
3. 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. You can create a scope, which is the process to begin automating your DHCP client TCP/IP configuration. Before you can use a newly created scope, however, you must activate it. After you have an active scope, your DHCP clients can be assigned an IP address and relevant TCP/IP configuration information from the scope. When you finish using a DHCP scope, you can delete it. Before you delete a scope, though, you should deactivate it first. Deactivating a scope does not allow a client to renew his current lease and forces him to obtain a lease from another DHCP scope. This is a means of migrating clients to a new scope without manual intervention.

To create a scope, follow these steps:

1. Select the DHCP server in the DHCP Servers 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 is Local Machine; otherwise, it is an IP address.
   
   
2. Choose Scope|Create to display the Create Scope dialog box, as shown in Figure 5.4.
   
   


Figure 5.4. The Create Scope dialog box.


3. Enter the beginning IP address of your subnet in the Start Address field.
   
   
4. Enter the last IP address of your subnet in the End Address field.
   
   

---

Tip: If you are not planning to divide your subnet between two DHCP servers, enter the complete IP address range of your subnet. If you are planning to split your subnet, as I have, enter only half your IP address range in the Start Address and End Address fields. A split subnet is easier to work with and prevents complications with the second DHCP Manager's defined scope.


---

5. Enter the subnet mask to be assigned to your DHCP clients in the Subnet Mask field.
   
   
6. 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 list box.
   
   
7. In the Lease Duration group, choose the Unlimited or Limited To radio button to specify the lease type. If you choose Limited To (the default), specify the length of time for your DHCP clients to keep their assigned IP addresses.
   
   

---

Warning: Do not assign the Unlimited lease type unless you are absolutely sure that no computers will ever be upgraded, replaced, or moved; this scenario is extremely unlikely. An unlimited lease will never be able to recover IP addresses that have been assigned to a DHCP client.


---

8. Enter a name for the scope in the Name field. 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 Servers window.
   
   
9. Enter a description for the scope in the Comment field.
   
   
10. Click the OK button. You are prompted with a message box to activate the scope. You should not activate the scope now, unless all your default scope properties are correct.
    
    
11. Repeat these steps for each new scope to be created.
    
    

Only after you configure the scope, as described in the next section, should you activate it. To do so, choose Scope|Activate.

Before you delete a scope, you should deactivate it. To do so, choose Scope|Deactivate. After 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:

1. Select the DHCP server in the DHCP Servers window that contains 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.
   
   
2. After the DHCP server is connected to, the scopes for the server are listed. Select the scope you want to delete.
   
   
3. Choose Scope|Delete. A warning message appears, informing you that clients still may have active leases. Choose OK and the scope is deleted.
   
   
4. Repeat these steps for each scope you want to delete.
   
   

Configuring DHCP Scope Options

Scope options are divided into two classes. You can have a global scope setting that applies to all scopes for the DHCP server, or a local scope setting that applies only to the current scope. Local scope properties override globally defined scope properties. This gives you the capability to define common properties that apply to all scopes you create and then customize the scope properties for each scope you create. You can define the global router setting to contain the IP addresses for your routers based on subnets, for example. Then, after you create a new scope, you can delete the first entry in this list and then add it back. This process 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 in each router address manually.

To modify a scope property, follow these steps:

1. Select the DHCP server in the DHCP Servers window that contains 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.
   
   
2. After the DHCP server is connected to, the scopes for the server are listed. Select the scope you want to modify.
   
   
3. Choose DHCP Options|Global to set global properties for the scope, which displays the dialog box shown in Figure 5.5. Or, choose DHCP Options|Scope to display a similar dialog box to set local scope properties.
   
   


Figure 5.5. The expanded DHCP Options: Global dialog box.


4. 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.
   
   
5. Click the Value button to expand the dialog box and display the current value of the option. To change the current value , enter a new value in the edit field. If the value is an array, click the Edit Array button to modify the current values.
   
   
6. Repeat steps 3 through 5 for each option to modify. After you finish modifying the options, click the OK button.
   
   

Tip: To modify an existing option, select the option in the Active Options drop-down list box, and then click the Value button to expand the dialog box so that you can edit the entry.

Creating New DHCP Scope Options

Not only can you modify the predefined scope properties as mentioned in the preceding section 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 even can create new scope options to be assigned to your DHCP clients. Just because you can modify an existing configuration option or create new ones, however, doesn't mean that you should do so arbitrarily. Instead, do so only if absolutely necessary.

To change an existing configuration option default value, follow these steps:

1. Choose DHCP Options|Defaults to display the DHCP Options dialog box shown in Figure 5.6.
   
   


Figure 5.6. The DHCP Options: Default Values dialog box.


2. Select the class for the option you want to modify from the Option Class drop-down list box. The default is DHCP Standard Options.
   
   
3. From the Option Name drop-down list box, select the option that you want to modify.
   
   
4. In the Value section, specify the new value for the option.
   
   

To change a configuration option's name, unique identifier, or description, follow these steps:

1. Repeat steps 1 through 3 of the preceding procedure.
   
   
2. In the DHCP Options: Default Values dialog box, click the Change button to display the Change Option Type dialog box.
   
   
3. You now can 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 aware of the consequences should modify any of these settings.


---

4. After all your changes are complete, click the OK button.
   
   
5. Repeat these steps for each option you want to change.
   
   

To add a new configuration option, follow these steps:

1. Repeat steps 1 through 3 of the procedure used to change an existing configuration option default value.
   
   
2. In the DHCP Options: Default Values dialog box, click the New button to display the Change Option Type dialog box.
   
   
3. Enter a name for the new option in the Name field.
   
   
4. Specify a data type in the Data Type field. This can 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 in the form of 999.999.999.999
   
   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.
   
   
5. Enter a unique number between 0 and 255 in the Identifier field.
   
   
6. Enter a description in the Comment field for the new option.
   
   

---

Warning: Adding a new configuration option should be performed only by an expert aware of the consequences. It should be used only to support non-Microsoft DHCP clients, which require the additional options.


---

7. After you complete all changes, click the OK button.
   
   
8. 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 his lease on the client workstations. Management options on the server are covered in a later section of in this chapter. This section discusses the options for the command-line program IPCONFIG.EXE. The syntax for IPCONFIG follows:

IPCONFIG [adapter] /all / /release /renew

Descriptions of the syntax 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 host name, 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.

If executed with no parameters, the current DHCP configuration is displayed. This can be useful for determining the installed adapters and IP addresses. Listing 5.1, for example, lists the output displayed on my WinBook XP.

Listing 5.1. The DHCP configuration of a client computer.

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. After you select an active scope and choose Scope|Active Leases, the Active Leases dialog box appears, as shown in Figure 5.7.

Figure 5.7. The DHCP Manager Active Leases dialog box.

You can perform the following actions in the Active Leases dialog box:

• View the active or reserved leases for the scope. By default, all the leases are displayed in the dialog box. If you enable the Show Reservations Only checkbox, however, only the reserved leases are displayed.
  
  
• View the client properties, as shown in Figure 5.8. You do this by selecting an IP address/computer name in the Active Leases' Client list and clicking the Properties button. This displays the Client Properties dialog box, which can be very useful. It displays the Media Access Control (MAC) adapter address in the Unique Identifier field, for example, and several Windows NT server applications, including the DHCP Manager (when reserving a lease, for example), require a MAC address.
  
  

Figure 5.8. The Client Properties dialog box.

• Update the DHCP database after a restoration from a backup database copy. If you need to restore your DHCP database from a previous backup (either automatically updated by the system or manually updated by you), you should click the Reconcile button in the Active Leases dialog box to update the database. This adds lease entries for any leases that are not in the database.
  
  

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 gives you the capability to define global and local scope options for the majority of your DHCP clients when you create the scope, and then to specify certain DHCP options for those special DHCP clients that happen to be the exception to the rule.

To create a reservation for a client, follow these steps:

1. Select the scope where you want the client reservation to occur.
   
   
2. Choose Scope|Add Reservations to display the Add Reserved Clients dialog box.
   
   
3. In the IP Address field, enter an IP address within your current DHCP scope to be assigned to the client.
   
   
4. In the Unique Identifier field, Enter the MAC address for the client's network adapter.
   
   
5. In the Client Name field, enter the client computer name.
   
   
6. In the Client Comment field, enter an optional description for the client computer.
   
   
7. Click the Add button.
   
   
8. Repeat steps 3 through 6 for each reservation you want to add to the scope. When you have finished adding all of your reservations, click the Close button to exit the dialog box.
   
   

Changing the configuration options for a reserved lease requires a little more work. To change a configuration option, follow these steps:

1. Select the scope you want to modify.
   
   
2. Choose Scope|Active Leases to display the Active Leases dialog box.
   
   
3. 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.
   
   
4. In the Client Properties dialog box, click the Options button to display the DHCP Options:Reservation dialog box.
   
   
5. Select the option in the Unused Options list box that 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, just select it.
   
   
6. Click the Value button to expand the dialog box and display the current value of the option. To change the current value , enter the new value in the edit field. If the value is an array, click the Edit Array button.
   
   
7. Repeat steps 4 through 6 for each option to modify. Then click the OK button.
   
   
8. Repeat steps 3 through 7 for each reservation you want to modify. Then click the OK button.
   
   

Managing the DHCP Databases

As your DHCP server operates day in and day out, the databases may grow as records are added or deleted. These databases are located in the SystemRoot\System32\DHCP directory and include DHCP.MDB (the DHCP database), DHCP.TMP (a temporary file created by the DHCP server), JET*.LOG files (contains transaction records), and SYSTEM.MDB (contains structural information about the DHCP databases). This database growth affects the performance of the DHCP server, so as your DHCP.MDB database approaches the 10 MB limit, you should compact it.

To compact the database, follow these steps:

1. Stop the DHCP server service from the Control Panel Services applet, or issue the net stop dhcpserver command from a console prompt.
   
   
2. From a console prompt, run the JETPACK.EXE program located in your SystemRoot\System32 directory. The syntax for this program follows:
   
   JETPACK DatabaseName TemporaryDatabaseName
   
   Here, DatabaseName is the name of the database to compact and 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.
   
   

---

Caution: Do not compact the SYSTEM.MDB file. If you do, the DHCP server service fails to 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. Then 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.


---

3. Start the DHCP server service from the Control Panel Services applet, or issue the net start dhcpserver command from a console prompt.
   
   

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; instead, you need to use the Registry Editor (REGEDT32.EXE). The Registry Editor can be a dangerous tool to use. If you are administering a remote computer with a configuration problem so severe that the service cannot be started, 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 subkey

HKEY_LOCAL_MACHINE\Systems\CurrentControlSet\Services\DHCPServer\Parameters

If you modify any of these keys, aside from the RestoreFlag, you must restart the computer in order for your changes to be applied.

Using the Windows Internet Name Service

You can use the Windows Internet Name Service (WINS) as a replacement for a Domain Name Service (DNS) to provide NetBIOS name resolution for computers using the TCP/IP protocol. WINS is based on the protocol specifications defined in RFC 1001/1002 and can interoperate with any other NetBIOS Name Server (NBNS) that also supports these protocols. For a fuller understanding of these protocols, you can look at the RFCs 1001 and 1002 on the Internet at http://www.internic.net.

This section first explores some of the design goals of the WINS service, along with some of the concerns when implementing WINS on your network. Then, you will plan your WINS server installation, which includes looking at some guidelines for the number of WINS servers and WINS Proxy Agents to install. Installation of the WINS service is discussed in Chapter 3. Next, you'll move on to managing and configuring the WINS service with the WINS Manager. And because a major portion of WINS concerns client-related administration, you will look into how you can manage your WINS clients with the WINS Manager, along with some specific quirks for MS-DOS clients using the Microsoft Network Client network software. Finally, you will 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 or the WINS service.

Examining 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. The WINS server can replace a UNIX DNS service, which uses a static text file (one or more host files) to define the computer name to IP address mapping. 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. 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, or whenever the renewal time expires, the WINS client registers its name with the WINS server. When the WINS client terminates, such as when the computer shuts down, the name is released. This enables a client computer to change subnets or change its IP address and still be accessible from other computers, for example. It also alleviates the manual modifications to host files required by a UNIX DNS service. The 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 based on 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 still is 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, 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 (meaning that it did not crash or experience a power failure) it informs the WINS server, which then 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, then the WINS server does not challenge the registration. Instead, the new IP address is assigned to the name. This might occur, for example, with a DHCP-enabled portable computer (or another DHCP-enabled computer) that is moved to a different subnet.
  
  Renewal: Periodically, 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, 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 having to have a domain controller on each side of the router.
  
  
• Reduction of broadcast traffic: A WINS server provides the capability to lower 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.
  
  
• Interoperation with non-WINS clients: WINS can interoperate with non-WINS clients to provide name resolution, but only if you have one or more WINS Proxy Agents installed on the subnet. A WINS Proxy Agent is a computer running the WINS client service, which captures a name query request from a UNIX client, for example, obtains the IP address from the WINS server, and then passes this back to the requesting non-WINS client (the UNIX client, for example).
  
  

Planning Your WINS Installation

For a small Microsoft-based network, all you really need is to install the DHCP and WINS services 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. In theory, this means that you can use one WINS server, with a backup WINS server for every 10,000 clients. I prefer to use a WINS server per logical grouping, however, to provide additional fault tolerance and load balancing.

Note: These name query requests can be routed to other WINS servers and WINS Proxy Agents and ensure that a request eventually is fulfilled. If you enable replication of your WINS databases, however, then each WINS server will have a complete listing of every WINS client name and IP address. When a name query request is received, an IP address is returned without broadcasting on the network. This mechanism provides the capability to lower 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 can be based on domain controllers or servers in separate physical buildings or floors. It even can be based on domain controllers on the other side of a WAN link or similar property. And for every three to five domain controllers or servers, I like to install the WINS service. This provides fault tolerance, in case of required maintenance or a WINS server failure, as well as limits the load on a single WINS server. At the very least, you should have a minimum of 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 very well for Microsoft-based networks that use the Microsoft TCP/IP protocol stacks. But it fails 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. Instead, it only implies that you also need to install WINS Proxy Agents or the Microsoft DNS service. A WINS Proxy Agent should be installed on each subnet to provide a linkage between your non-WINS clients and the WINS servers (see Figure 5.9). 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.

Figure 5.9. Supporting your non-WINS clients in a multiple subnet network with WINS servers.

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 need to have one WINS Proxy Agent per subnet because broadcast messages are not passed across routers. When a non-WINS client attempts to find another computer, it uses a broadcast message to obtain the IP address of the requested computer. If this computer is on the same subnet, the request succeeds, but if the computer 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, as shown in Figure 5.10.

Figure 5.10. A WINS Proxy Agent interoperating with non-WINS clients.

In this figure, 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 non-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, 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. This is why you 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 can 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 name query request can be routed to WINS servers, but 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 address, 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: 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: A push partner is a WINS server that sends update notifications to its pull partners. When 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: A pull partner is a WINS server that requests updates from its push partner, and when the push partner responds, it receives the database replica.
  
  

These descriptions of push and pull partners, may seem like circular descriptions, which they are. In order 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, which can be used to replicate every WINS database to every other WINS database (see Figure 5.11). You can see from this example that some WINS servers receive update notifications from more than one WINS server, which can lead to increased network traffic.

Figure 5.11. WINS server push and pull replication in a nonlinear chain.

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 (see Figure 5.12). Only at a WAN link is this rule broken, where the WINS server at 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 the question, How often should you replicate? My basic methodology is based on the distance between replication points and the speed of the link. For your local area network, 10–15 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 between 30–60 minutes. Lower the rate only if you have a high turnover rate. For longer WAN links, choose a value of between 45–90 minutes. And for intercontinental WAN links, choose 6–12 hours and schedule it for the off-peak hours. The idea with all these scenarios is the more heavily you use the link, the lower the replication frequency (or the higher the number of scheduled minutes between replication attempts).

Figure 5.12. WINS server push and pull replication in a linear chain.

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 additional 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 additional WINS servers to the local WINS Manager, you need to 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.

The first recommended option is to choose Server|Configuration, which displays the WINS Server Configuration dialog box, as shown in Figure 5.13.

Figure 5.13. 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 four 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 four 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 four days, and the minimum is one day.
  
  

Note: The extinction interval and extinction default for a fully configured WINS server are based on the renewal time and whether the WINS server has replication partners on the replication time interval.

• Verify Interval: Specifies the time interval in which a WINS server must verify that old names owned by another WINS server still are valid. The default (24 days) is dependent on the extinction interval. The maximum is 24 days.
  
  
• Pull Parameters: The pull partner replication interval is set in the Preferences dialog box, as described later in this chapter. If you want the replication to be triggered when the WINS server service starts, however, enable the Initial Replication checkbox and specify a number in the Retry Count field.
  
  
• Push Parameters: To set push partner configurations, you can enable the following entries:
  
  Initial Replication: If this setting is enabled, push partners are informed that a change has occurred when the WINS server service starts.
  
  Replicate on Address Change: If this setting is enabled, push partners are informed whenever an entry in the database changes or when a new entry is added.
  
  
• Advanced WINS Server Configuration: You can access these options by clicking the Advanced button to expand the dialog box.
  
  Logging Enabled: Specifies that the WINS server service logs database changes and informs you of basic errors in the system event log. The default is enabled.
  
  Log Detailed Events: Specifies that detailed events are written into the system event log. You should use this only for a limited time, such as when you are troubleshooting WINS server problems, because it can consume considerable resources and impact system performance. The default is disabled.
  
  Replicate Only with Partners: This entry, if enabled, allows only replication with push or pull partners. If it is disabled, you can replicate data from any unlisted WINS server. The default is enabled.
  
  Backup on Termination: If enabled, this option automatically backs up the WINS database whenever the WINS server service is shut down. It does not perform a backup whenever the system is shut down, however. The default is enabled.
  
  Migrate On/Off: Enables or disables the treatment of static or multihomed records as dynamic whenever they conflict with a new registration or replica (data copied from another WINS server). You should enable this option if you are upgrading a non-Windows NT system (such as a LAN Manager server) to Windows NT Server. The default is disabled.
  
  Starting Version Count: Specifies the highest database entry version number. Normally, you will not need to change this value; however, if you restore the WINS database from a backup because your primary database is corrupted, you should increment this value to a number higher than any other copy of the WINS server partners to ensure proper replication.
  
  

Note: You can display the current values by choosing Mappings|Show Database from the menu. If you want to see the version numbers on other WINS servers, choose the WINS server before making the menu selection.

Database Backup Path: Specifies the full path to use for the backup copies of the WINS server database.

The next suggestion is to set your preferences for the WINS Manager and default settings for the WINS service. Choose Options|Preferences to display the Preferences dialog box, as shown in Figure 5.14.

Figure 5.14. Specifying the WINS Manager preferences and WINS server service defaults.

In the Preferences dialog box, you can take the following actions:

• Specify how the WINS Manager displays the names for the WINS servers it is connected to and, incidentally, the mechanism used for connecting to the service. These options follow:
  
  Computer Name Only: If selected, specifies that the computer name is displayed and uses named pipes to connect to the WINS server.
  
  IP Address Only: If selected, specifies that the IP address is displayed and uses TCP/IP to connect to the WINS server.
  
  Computer Name (IP Address): If selected, specifies that the computer name is displayed first and then the IP address, and uses named pipes to connect to the WINS server.
  
  IP Address (Computer Name): If selected, specifies that the IP address is displayed first and then the computer name, and uses TCP/IP to connect to the WINS server.
  
  
• Specify the refresh interval for updating the WINS Manager display. If you enable the Auto Refresh checkbox, you also should specify a value (number of seconds to wait before updating the display) in the Interval field.
  
  

Note: The display is refreshed automatically whenever you initiate an action with the WINS Manager.

• Specify the NetBIOS name compatibility. If the LAN Manager-Compatible checkbox is enabled (the default setting), NetBIOS names are limited to 15 bytes to contain the name, and the sixteenth byte is used to contain a special code for static mappings. If you use other applications that require a 16-byte NetBIOS name, such as Lotus Notes, you should disable this option. The special codes follow:
  
  0x0: Specifies that a NetBIOS name is used by the Redirector.
  
  0x1: Specifies that the NetBIOS name is used by the domain Master Browser.
  
  0x3: Specifies that the NetBIOS name is used by the messenger service.
  
  0x20: Specifies that the NetBIOS name is used by a LAN Manager server.
  
  0x1B: Specifies the Master Browser name that clients and browsers use to contact the Master Browser.
  
  0x1E: Specifies that the NetBIOS name is used for a normal group.
  
  0x1D: Specifies that the NetBIOS name is used for client-name resolution when an attempt is made to contact the Master Browser for server lists.
  
  0x1C: Specifies that the NetBIOS name is an Internet group name. An Internet group name contains the addresses of the primary and backup domain controllers for the domain. This name is limited to 25 addresses.
  
  
• Specify the miscellaneous support options:
  
  Validate Cache of "Known" WINS Servers at Startup Time: If this option is enabled, whenever you start the WINS Manager, it attempts to connect to all WINS servers you have added. If a WINS server cannot be contacted, you are prompted to remove the WINS server from the list of connected servers. The default is disabled.
  
  
• Confirm Deletion of Static Mappings & Cached WINS Servers: This option, if enabled (the default), prompts you with a message box whenever you attempt to remove a static mapping or cached WINS server. I find the constant message boxes a bit annoying, and normally disable this setting. Before you do, however, I suggest that you become a bit more familiar with the WINS Manager.
  
  
• If you click the Partners button, the dialog box expands and enables you to set defaults for the partner replication. These settings follow:
  
  New Pull Partner Default Configuration: The entries in this group specify the default replication settings for new pull partners that you create for the currently selected WINS server. These options include the following:
  
  Start Time: The time to start your WINS server database replication. There is no default, although I like to start at 12:00 a.m.
  
  Replication Interval: The interval at which to repeat the WINS server database replication. There is no default, although I generally choose a 15-minute interval for local area network WINS servers.
  
  New Push Partner Default Configuration: The entry in this group specifies the number of changes that have to occur in the WINS server database before a push notification is sent to the push partners you create for the currently selected WINS servers.
  
  Update Count: Specifies the number of changes that have to occur before a push notification is sent. There is no default, although I recommend a value of 1,000.
  
  

The next suggestion is to set the replication settings for the local WINS server by choosing Server|Replication Partners to access the Replication Partners dialog box, shown in Figure 5.15. Click the Add button to add the WINS servers to be configured as the local push or pull partners. You can choose to replicate to any or all WINS servers in a nonlinear fashion, or you can choose to pull from one WINS server and push to another WINS server in a linear fashion. These techniques were described in more detail earlier in this chapter in "Planning Your WINS Installation."

Figure 5.15. Specifying the WINS server replication partners.

Note: To remove a WINS server from the WINS Server list, select it and press the Delete key.

After you add your WINS servers, you can take the following actions:

• Specify the WINS servers to display in the WINS Server list by enabling or disabling the options in the WINS Servers To List field. These options follow:
  
  Push Partners: If enabled, push partners of this WINS server are displayed. The default is enabled.
  
  Pull Partners: If enabled, pull partners of this WINS server are displayed. The default is enabled.
  
  Other: If enabled, any non-partner of this WINS server is displayed. The default is enabled.
  
  
• Specify the individual settings for the currently selected WINS server to be a push, pull, or both partner in the Replication Options section. When you select a WINS server that already is configured as a push or pull partner, the Configure buttons are enabled. The settings in the Replication Options group follow:
  
  Push Partner: Enable the Push Partner checkbox to specify that the selected WINS server is a push partner. You then can click the Configure button to display the Push Properties dialog box, where you can view or set the update count.
  
  Pull Partner: Enable the Pull Partner checkbox to specify that the selected WINS server is a pull partner. You then can click the Configure button to display the Push Properties dialog box, where you can view or set the start time and replication interval.
  
  
• Initiate a replication trigger immediately, instead of waiting for it to occur based on the replication times set in the Configuration dialog box by setting the following values in the Send Replication Trigger Now group:
  
  Push: Specifies that a push trigger be sent to the selected WINS server.
  
  Pull: Specifies that a pull trigger be sent to the selected WINS server.
  
  Push with Propagation: Enabling this checkbox modifies the Push message to indicate that changes sent to the selected WINS server be propagated to all other pull partners of the selected WINS servers.
  
  

Managing Your WINS Clients

Managing your WINS clients consists of creating static mappings (which is a permanent computer name to IP address record) and viewing your current database records. You add static mappings by choosing Mappings|Static Mappings, which displays the Static Mappings dialog box shown in Figure 5.16. You can click the Add Mappings button to access the Add Static Mappings dialog box, in which you can enter a computer name, IP address, and type to add to the WINS server database. Table 5.2 lists the types of static mappings, which describe the special names the WINS server uses and show how WINS manages these names. You can delete a static mapping by selecting the mapping and then pressing the Delete button.

Figure 5.16. The Static Mappings dialog box.

Table 5.2. WINS server special names.

Type

Description

Managing the WINS Databases

Because your WINS server also uses the same database format (a modified Access database), it has the same basic issues as the databases for the DHCP server. As records are added and deleted, the database grows. The WINS databases are located in the SystemRoot\System32\WINS directory and include the following:

• WINS.MDB: The WINS database
  
  
• WINSTMP.MDB: A temporary file created by the DHCP server
  
  
• JET.LOG files: Contains transaction records
  
  
• SYSTEM.MDB: Contains structural information about the WINS databases
  
  

The database growth affects the performance of the WINS server. As your WINS.MDB database approaches the 30 MB limit, you should compact it. To do so, follow these steps:

1. Stop the WINS server service from the Control Panel Services applet, or issue the net stop wins command from a console prompt.
   
   
2. From a console prompt, run the JETPACK.EXE program, which is located in your SystemRoot\System32 directory. The syntax for this program follows:
   
   JETPACK DatabaseName TemporaryDatabaseName
   
   Here, 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.
   
   

---

Caution: Do not compact the SYSTEM.MDB file. If you do, the WINS server service will fail to start. If this occurs, restore your configuration from a previous backup.


---

3. Start the WINS service from the Control Panel Services applet, or issue a net start wins command from a console prompt.
   
   

Tip: Because a potential for failure is possible with the compact utility, or just plain data corruption on your SystemRoot partition, you should back up your WINS databases regularly, and definitely before you compact them. Choose Mappings|Backup Database. Make sure to perform a full backup by disabling the Perform Incremental Backup option if you plan to use this copy to restore your configuration.

Using Performance Monitor to Monitor the WINS Service

Although the WINS Manager displays the same statistics as those used by the Performance Monitor, the WINS Manager can display only the statistics for the currently selected WINS server. If you use the Performance Monitor, however, you can monitor multiple WINS servers simultaneously. This can be of enormous benefit when you are comparing the performance of multiple WINS servers. Table 5.3 lists the available WINS server performance object counters that you can use to monitor your selected WINS server.

Table 5.3. The Performance Monitor object types and object counters for the WINS server.

Object Counters

Description

Using WINS Server Registry Keys

The WINS server service also stores its configuration information in the Registry, just as the DHCP server service does. Once again, you might need to modify the Registry to modify one or more configuration settings if you need to modify a configuration setting that cannot be set from the WINS Manager, or if you are administering an inactive WINS server.

Warning: Remember that improperly using the Registry Editor can damage your system beyond repair.

The primary Registry keys are located in

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\WINS\Parameters

and include the following:

• DbFileNm: Specifies the full path name to the locations of the WINS database file. The default is %SystemRoot%\System32\WINS\WINS.MDB.
  
  
• DoStaticDataInit: If this item is set to 1, the WINS server initializes its database with records from one or more files in the DataFiles subkey. This initialization is performed at the time the process is executed and whenever a change to a key in the Parameters or Datafiles subkey occurs. If this item is set to the default (0), this initialization does not occur.
  
  
• InitTimePause: If this entry is set to 1, the WINS service starts in the paused state. It stays in this state until it replicates with its partners (push or pull) or fails in the replication attempt (at least once). If the entry is set to 1, you should set the following subkey to 1:
  
  WINS\Partner\Pull\InitTimeReplication
  
  Otherwise, you should remove the subkey from the Registry for proper operation. A value of 0 (the default) disables this option. Note that you can set the InitTimeReplication key value by choosing Options|Preference and clicking the Advanced button to expand the dialog box.
  
  
• LogFilePath: Specifies the location for the WINS server log files. The default is %SystemRoot%\System32\WINS.
  
  
• McastIntvl: Specifies the time interval, in seconds, for the WINS server to send a multicast and announce itself to other WINS servers. The minimum and default value is 2400 (40 minutes).
  
  
• McastTtl: Specifies the number of times a multicast announcement can cross a particular router. The default is 6, and the range is 1 to 32.
  
  
• NoOfWrkThds: Specifies the number of worker threads used by the WINS server. The default is 1 per processor on the system, with a range of 1 to 40. Note: You can change this value and place it into effect without restarting the WINS service.
  
  
• PriorityClassHigh: Set this entry to 1 to enable the WINS service to run in the high priority class. This prevents other applications and services running in lower priorities from preempting the WINS service. The default is 0. Note: If you choose to enable this setting, make sure that you monitor the system with the Performance Monitor to make sure that the WINS service is not using too much processor time and that other applications and services continue to function properly.
  
  
• UseSelfFndPnrs: Set this option to 1 (to enable) or 0 (to disable) the WINS service from automatically finding other WINS servers and configuring them as push and pull partners. The default is 0. If the push and pull partners are configured manually with the WINS Manager, the partnership information no longer is maintained automatically when a change occurs.
  
  

Note: If this option is enabled, the WINS service configures only WINS servers as push and pull partners across routers if the routers support multicasting. Otherwise, only WINS servers found on the local subnet are configured automatically as partners.

You can configure the following Registry keys by choosing Server|Configuration and modifying the entries in the WINS Server Configuration dialog box:

• BackupDirPath: Specifies the full path name to the location to be used to back up the WINS database.
  
  
• DoBackupOnTerm: If enabled (1), the WINS database is backed up whenever the WINS service is terminated. If disabled (0), the database is not backed up when the service is terminated. The default is 1. Note: The backup does not occur when the system is shut down. A backup occurs only when the service is stopped manually.
  
  
• LogDetailedEvents: If enabled (1), verbose logging of WINS events occurs. The default is disabled (0).
  
  
• LoggingOn: If enabled (1), WINS messages are placed in the event log. If disabled (0), no events are placed in the event log. The default is 1.
  
  
• MigrateOn: Enables (1) or disables (0) the treatment of unique and multihomed records as dynamic when a registration conflict is detected. The default is 0.
  
  
• RefreshInterval: Specifies the time, in seconds, for the client to register its name with the WINS server. The default is 0x54600 (four days).
  
  
• RplOnlyWCnfPnrs: Enables (1) or disables (0) the capability to replicate a WINS server from a WINS server that is not a partner. The default is 1.
  
  
• TombstoneInterval: Specifies the time, in seconds, between when a client record is released and when it is marked as extinct. The default is 0x54600 (four days).
  
  
• TombstoneTimeout: Specifies the time, in seconds, between when a client record is marked as extinct and when it is scavenged from the database. The default is 0x54600 (four days).
  
  
• VerifyInterval: Specifies the interval during which the WINS server must verify that old names, which is does not own, still are valid. The default is 0x1FA400 (24 days).
  
  

The Registry keys for partner replication are located in the

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\WINS\Partners

key and include the following:

• PersonaNonGrata: Specifies IP addresses for WINS servers from which you do not want to replicate data. This key may be very useful for Administrators to block replication from WINS servers that are not under their control.
  
  
• Pull\<IPAddress>\MemberPrec: Specifies the preference order of addresses in an Internet group. Values can be 0 for low precedence or 1 for high precedence. The default is 0. Note: This entry appears under an IP address (of a WINS server).
  
  

Using the Domain Name System

The primary purpose of a Domain Name System (DNS) is to supply friendly computer names instead of an IP address to locate a resource. This process often is referred to as NetBIOS name resolution. The DNS uses a hierarchical architecture. If a DNS server is unable to resolve an IP address at the local level, it queries other DNS servers at a higher level to resolve the name. If you do not mind maintaining multiple DNS servers and their associated configuration files, you can use DNS in place of DHCP and WINS. I prefer to use all three components working together because the Microsoft implementation complements each component to provide ease of administration as well as maximum compatibility.

Examining Design Goals for the Microsoft DNS Service

Although you could use other DNS servers on your network, they might not support the Microsoft WINS service. If this is the case, you also might lose the capability to manage a dynamic network. This is the real difference between the Microsoft DNS implementation and other DNS servers that run under Windows NT. The Microsoft implementation fully supports WINS, which, in turn, is aware of DHCP.

If you use DHCP, WINS, and DNS together, you can achieve the following:

• Using DHCP, your clients automatically allocate dynamic IP addresses. This enables you, the Administrator, to provide dynamic IP addresses to your network clients as they move between subnets (a consultant or temporary employee, for example).
  
  
• Using WINS, your clients automatically register their computer names and IP addresses every time they start up their computers. If the computers move between subnets, this information is updated automatically as well.
  
  
• Using DNS, your clients can find any non-WINS-aware resources through the static mappings maintained in the configuration files. This also works in reverse. Any non-WINS-aware client that uses DNS to resolve names and has a static mapping to your DNS service can locate a WINS client, as long as the Microsoft DNS server is configured to use a WINS server for additional names resolution.
  
  

This combination of DHCP, WINS, and DNS provides additional benefits as well. Dynamic address allocation also means dynamic address recovery. When a new IP address is allocated to a client on another subnet, the old address is released back to the DHCP scope's address pool. This can prevent the confusion caused by duplicate IP addresses on the network. The only thing DHCP and WINS really will not do for you is make it easy to get on the Internet. One of the requirements for registering your domain (often, your company name) with the InterNIC is that you maintain two or more DNS servers on your network so that clients who want to connect to your server—most likely, your WWW page—can find you. Many Internet Service Providers (ISPs) don't know how to deal with or support DHCP and WINS. So you might as well get used to using a DNS server if you plan to connect to the Internet, but you don't have to go through all the hassle of modifying your configuration files every time you move or add a client to your network if you also use DHCP and WINS.

Using a DNS server provides some additional benefits. It can provide some additional name-resolution capabilities that WINS cannot provide, for example. A DNS server includes e-mail name resolution by supporting the MX record type that associates an e-mail address with a host name. And when a DNS server cannot resolve a name locally, it refers the name query to another DNS server higher up the chain in an effort to resolve the name.

Planning Your DNS Installation

You should consider a few items before you install a DNS server on your network. If you plan to connect to the Internet, the most important of these is security. I suggest that you read the next chapter, "Windows NT and IIS Security Issues," and consider how this will affect your implementation. The other items are less serious but equally important.

First, consider who will be in charge of maintaining the configuration files. This person(s) maintains a master copy of all shared configuration files. Every one else uses a replicated copy of the master copy. Second, if you will have more than one person modifying any configuration file, be sure that they are trained to maintain the files in the same way. Make sure this training includes a standard naming convention for filenames and host names, as well as verification of IP addresses.

Caution: A duplicate host name or IP address on your network can cause serious problems. Make sure that your Administrators are aware of this and that your registration plan includes the capability to register a name and IP address before it is reassigned. An Access database, for example, can be used to maintain information (host name, IP address, filename, and so on) about your network and can be queried to verify that the host name and IP address are not in use.

Using the DNS Service Configuration Files

The configuration files used with the Microsoft DNS server can be replaced by those from a UNIX BIND installation if you are migrating or interoperating with a UNIX system. You might need to modify the files if you are using some outdated BIND commands, however.

These configuration files are divided into four basic types:

• BOOT: This file controls the startup behavior of the DNS server. It includes information on the default directory where the configuration files reside, the cache filename, the domain name for which the DNS server will provide service, and the domain name for secondary DNS servers.
  
  
• CACHE: This file contains information for Internet connectivity.
  
  
• PLACE.DOM: This file contains information on host names within the domain. It also includes references to reverse lookup filenames and WINS servers.
  
  
• ARPA-###.REV: These files (there should be one per subnet) include information to resolve an IP address to a host name.
  
  

BOOT

Not very many commands are supported in the boot file, so the syntax for the commands is fairly easy to remember. Listing 5.2 shows an example BOOT file for a simple network, such as the one in my office.

Listing 5.2. An example boot file for a small domain.

;   DNS BOOT FILE - Master configuration for DNS service

directory       %System32%\system32\dns

cache   .       cache

primary   nt-guru.com    nt-guru.dom

primary   127.in-addr.arpa          arpa-127.rev

primary   128.0.0.in-addr.arpa      arpa-128.rev

CACHE

The cache file is used for additional name resolution. If your DNS server cannot resolve a name, it queries the additional name servers listed in this file. If you are using this DNS server to resolve names on the Internet, your file should look similar to Listing 5.3.

Listing 5.3. The default cache file for a small network connected to the Internet.

;   DNS CACHE FILE

;   Initial cache data for root domain servers.

;   YOU SHOULD CHANGE:

;       - Nothing if connected to the Internet.  Edit this file only when

;         update root name server list is released.

;           OR

;       - If NOT connected to the Internet, remove these records and replace

;         with NS and A records for the DNS server authoritative for the

;         root domain at your site.

;   Internet root name server records:

;       last update:    Sep 1, 1995

;       related version of root zone:   1995090100

; formerly NS.INTERNIC.NET

.                        3600000  IN  NS    A.ROOT-SERVERS.NET.

A.ROOT-SERVERS.NET.      3600000      A     198.41.0.4

; formerly NS1.ISI.EDU

.                        3600000      NS    B.ROOT-SERVERS.NET.

B.ROOT-SERVERS.NET.      3600000      A     128.9.0.107

; formerly C.PSI.NET

.                        3600000      NS    C.ROOT-SERVERS.NET.

C.ROOT-SERVERS.NET.      3600000      A     192.33.4.12

; formerly TERP.UMD.EDU

.                        3600000      NS    D.ROOT-SERVERS.NET.

D.ROOT-SERVERS.NET.      3600000      A     128.8.10.90

; formerly NS.NASA.GOV

.                        3600000      NS    E.ROOT-SERVERS.NET.

E.ROOT-SERVERS.NET.      3600000      A     192.203.230.10

; formerly NS.ISC.ORG

.                        3600000      NS    F.ROOT-SERVERS.NET.

F.ROOT-SERVERS.NET.      3600000      A     39.13.229.241

; formerly NS.NIC.DDN.MIL

.                        3600000      NS    G.ROOT-SERVERS.NET.

G.ROOT-SERVERS.NET.      3600000      A     192.112.36.4

; formerly AOS.ARL.ARMY.MIL

.                        3600000      NS    H.ROOT-SERVERS.NET.

H.ROOT-SERVERS.NET.      3600000      A     128.63.2.53

; formerly NIC.NORDU.NET

.                        3600000      NS    I.ROOT-SERVERS.NET.

I.ROOT-SERVERS.NET.      3600000      A     192.36.148.17

; End of File

Tip: You can find an updated version of this file at the InterNIC FTP site ftp.rs.internic.net. Just log on anonymously, change to the \domain directory, and download the file called named.root.

If this DNS server will not be used for Internet name resolution, you should replace the name server (NS) and address records with the authoritative DNS server for your domain.

PLACE.DOM

This file is the heart of your DNS server's operation. It contains several record types, as summarized in Table 5.4, used to provide name resolution for the domain. Because the example file included with the Microsoft DNS service contains information for a non-existent domain, you should rename the file and modify it as appropriate for your domain. Listing 5.4 is a copy of my replacement file called nt-guru.dom. I use a naming convention of DomainName.dom, and I recommend that you do as well. This is particularly useful when administering multiple domains.

Table 5.4. Supported domain name records.

Identifier

Record Type

Description

Listing 5.4. An example of a domain name lookup file.

@   IN  SOA     srv.nt-guru.com.  admin.srv.nt-guru.com. ( ;source host e-mailaddr

                               1                           ; serial number of file

                               10800                       ; refresh interval

                               3600                        ; retry interval

                               604800                      ; expiration interval

                               86400 )                     ; minimum time to live

@               IN  NS      srv.nt-guru.com.               ; name server for domain

srv             IN  A       128.0.0.1                      ; IP address of name server

@   IN  WINS 128.0.0.1 129.0.0.1                           ; IP address of WINS servers

localhost       IN  A       127.0.0.1                      ; loop back

@               IN  MX      10      srv                    ; e-mail server

srv     IN  A       128.0.0.1                              ; IP address of e-mail server

ftp             IN  CNAME   srv                            ; alias name for FTP service

www             IN  CNAME   srv                            ; alias name for WWW service

gopher          IN  CNAME   srv                            ; alias name for Gopher service

The first entry in the file must be a Start of Authoritative (SOA) record. This record includes parameters that describe the following:

• The source host (where the file was created)
  
  
• An e-mail address for the administrator of the file
  
  
• A serial number (or version number) of the file
  
  
• A refresh interval (in seconds), which is used by secondary servers to determine when a revised file should be downloaded
  
  
• A retry time (in seconds), which is used to designate an interval during which secondary servers wait before attempting to download the file in case of error
  
  
• An expiration time (in seconds), which is used by secondary servers to determine when to discard a zone if it could not be downloaded
  
  

Your name servers (or DNS servers) for the domain then should be listed, followed by their IP addresses. Next, include the local host identifier, which is used for loopback testing, the name and address of any mail servers, and finally any host name aliases. A host name alias is used to provide a host (such as my server SRV) with more than one host name. This is particularly useful when you want your WWW site to be accessible in the commonly used format WWW.DomainName.COM (www.nt-guru.com, for example) rather than ServerName.DomainName.COM (srv.nt-guru.com, for example).

Note: When you specify a fully qualified domain name (FQDN), it must be appended with a period. Otherwise, the domain name is appended to the host name for resolution and causes the name query to fail. Suppose that I specified my domain name as nt-guru.com in line 7 of Listing 5.4 instead of nt-guru.com., for example. Then when trying to resolve the host name srv.nt-guru.com, the domain name of nt-guru.com would be appended once again (srv.nt-guru.com.nt-guru.com). Because there is no host by that name, the query would fail.

ARPA-###.REV

This file is used for reverse lookups of host names within a domain. Instead of resolving a name to an IP address, a reverse lookup resolves an IP address to a host name. Listing 5.5, for example, shows the reverse lookup file for my domain, which only has one subnet (128.0.0.0).

Listing 5.5. An example reverse lookup file for a small subnet.

@   IN  SOA     srv.nt-guru.com.  admin.srv.nt-guru.com. ( ;source host e-mailaddr

                               1                           ; serial number of file

                               10800                       ; refresh interval

                               3600                        ; retry interval

                               604800                      ; expiration interval

                               86400 )                     ; minimum time to live

@               IN  NS      srv.nt-guru.com.               ; name server for domain

@   IN  NBSTAT      nt-guru.com.                           ; domain name to append for NBSTAT lookups

1       IN  PTR     srv.nt-guru.com.                       ; SRV at 128.0.0.1

99      IN  PTR     winbookxp5.nt-guru.com.                ; WinBook XP5 at 128.0.0.99

Once more, the first record should be an SOA record. The next record lists the name (or DNS) server for the domain, followed by an NBSTAT record, and then the individual PTR records for each host in the domain. Table 5.5 lists these records and their use. Many people find the PTR records most confusing. Instead of supplying a complete IP address (such as 128.0.0.1) for the host, you only supply the last digit of the IP address (such as 1), followed by the fully qualified host name (host + domain name + .).

Table 5.5. Supported reverse lookup records.

Identifier

Record Type

Description

Summary

This chapter focused on implementing the DHCP, WINS, and DNS services on your network. You learned about the design goals for the services, basic planning issues, and the management options available for manipulating your DHCP and WINS clients.

You also looked at specific issues for using DHCP and WINS in a mixed Windows NT and UNIX environment. You also examined how to prepare for the possibility of a failure with the services database, some Registry keys you can use to configure otherwise unconfigurable options, and some basic performance tips.

In the next chapter, you will look at some of the security issues involved with connecting to the Internet and how you can configure your server to minimize unauthorized access to your network.