WINS Replication

You should recall from NT 4 that you could configure WINS servers to replicate information to one another, giving multiple WINS servers a more complete view of the network. This functionality still exists, with the ability to configure replication manually, as well as automatically. The automatic partner configuration can be set on a WINS server and uses multicast traffic (address to find and communicate with other WINS servers. By default, these servers will become push/pull partners of one another, and will replicate via ‘pull’ every 2 hours. The upside of using automatic configuration is that it is simple, but the downside is that you may want a higher degree of control. Also understand that all of your routers must support forwarding multicasts in order for this to work. Turned off by default, you can configure the WINS server to use multicasts via the Replication Partners properties Advanced tab.

The more traditional way of configuring WINS replication is manually, by making systems push/pull partners. These relationships can be one-way, or two-way, whichever best meets your needs.

Push partner – a push partner is configured notify its pull partner of changes to the WINS database after a certain number of changes. The push partner is simply a messenger – it tells the pull partner ‘I have changes’, and the pull partner grabs the changes. Push partner parameters are generally set in LAN environments where bandwidth is not a big issue.

Pull partner – a pull partner is configured to obtain changes from configured push partners as a function of time. That is, the pull partner can be configured to obtain changes at a certain time interval that is convenient for our network. For example, you might configure pull parameters in a WAN environment with limited bandwidth to replicate at midnight.

Remember the key – push partners get configured according to number of database changes; pull partners as a function of time. Configure for push in LAN environments and pull in WAN environments as a general rule. To have WINS servers replicate fully with one another, they must be push/pull partners of each other (since replication is set up one-way – pull obtaining changes from push – by default).

WINS Registration

Note that WINS is not installed on a Windows 2000 Server by default – you will need to add the service by accessing Windows Components via Add/Remove programs in Control Panel. As was the case in NT 4, systems configured to use WINS will register their NetBIOS name to IP address mapping when they start up. The actual process consists of a name registration, with a client renewing the registration once half the TTL (time to live assigned by the WINS server) for the registration has expired. If the name a client attempts to register is already in the database, the WINS server sends a challenge to the host who has the name registered to see whether the host is active. If not, the name registration will succeed. If the other client is active, the registration will fail since machine must have unique NetBIOS names. In the same way, a client will ‘unregister’ itself in WINS upon a proper shutdown. Note that when this happens, the entry is not immediately removed from the WINS database – instead, the entry is ‘tombstoned’ and marked for extinction, a process that allows the name release to be replicated to other WINS servers. Ultimately, the record is removed from WINS once the extinction timeout period has passed.

One of the more welcome features in Windows 2000 is the ability to change your IP address without a reboot. After doing so, you should ensure that you also reregister your name registration in WINS – a process accomplished by issuing the nbtstat –RR command.

LMHosts File

The LMHOSTS file is far from the most efficient solution to NetBIOS name resolution, but is of use in environments without WINS. Created on the same principal as the hostname-resolving HOSTS file, the LMHOSTS file is a plain text file that contains NetBIOS names in one column, followed by IP addresses in the other. A client can consult this file in trying to resolve a name to an address. Because the use of this file is associated with Microsoft B-node, it only makes sense to put mappings for remote hosts in this file – local hosts will always be found by the broadcast that happens prior to LMHOSTS consultation. By default, the LMHOSTS file can be found in the %systemroot%\system32\drivers\etc directory. You should also have an awareness of the optional tags that can be used with the file, as these provide additional functionality, as outlined below. Also note that you should place the most commonly used entries at the top of the LMHOSTS file, since the file is parsed from top to bottom.

Useful LMHOSTS file tags:

#PRE – Entries marked with the #PRE tag are pre-loaded into the NetBIOS name cache.

#DOM: – these entries designate domain controllers


– this entry marks the path to a centralized LMHOSTS file on the network. This can be a useful alternative to WINS (though still a great deal of work), but remember that the NetBIOS name-to-address mapping of the host with the centralized file must also be included in this LMHOSTS file.#MH – this entry designates that multiple entries exist for a name since the system is multihomed (has multiple network interfaces)

Note that Windows 2000 will use the LMHOSTS file by default, but this can be changed via the WINS tab in your Advanced TCP/IP settings. Consult the screen shot of the WINS tab later in the article to see the checkbox.

NetBIOS Name Resolution

Many people assume that NetBIOS name resolution is no longer necessary in Windows 2000 due to the heightened importance of DNS as the primary name resolution facility in the OS. Although Microsoft is certainly moving away from a reliance on NetBIOS as a network protocol, you simply cannot ignore the fact that programs exist that rely on NetBIOS. Yes, Windows 2000 does support resolving NetBIOS names in a variety of ways, including the use of DNS and related hostname-resolution techniques, but this is not necessarily efficient. Since so many products still use NetBIOS as their primary protocol, and since so many networks now run TCP/IP, it is still a good idea to run WINS on the network. If nothing else, it is impractical not to have it for the purpose of supporting downlevel clients such as Windows NT and Windows 98, who complete many important processes (such as logon) via NetBIOS.

A NetBIOS name is a 16-byte address that uniquely identifies a host on the network. This address is 15 characters long, with a 16th character that uniquely identifies a service that the system is running, such as the Server or Workstation services. A NetBIOS name is often referred to as a Computer name, although the line is blurring as Windows 2000 moves to a more integrated support of TCP/IP and DNS naming. Don’t forget that the purpose of WINS is mainly to resolve NetBIOS names to IP addresses. In the past, NetBIOS was the primary communication protocol used on Microsoft networks. The move to TCP/IP as the primary transport of choice has necessitated the ability to map NetBIOS names to IP addresses, and the ability to ‘piggyback’ NetBIOS over TCP/IP. However, WINS is not the only way to resolve these names to IP addresses. The official NetBIOS name resolution techniques in Windows 2000 include:

Local Broadcast – In this traditional method, a host will broadcast onto the local subnet trying to find the IP address associated with a given name. Obviously this method is restrictive, since it is limited in terms of reach on the network (as well as being inefficient)

NetBIOS Name Server – In most networks, a NetBIOS name server (such as WINS) is set up to handle name registration and queries directly. Clients systems (and servers) register their NetBIOS name to IP address mapping with WINS. When queried by a client, the NetBIOS name server replies with the requested IP address associated with the requested name.

NetBIOS Name Cache – Upon resolving a NetBIOS name to an IP address, the client stores this information in its NetBIOS name cache. By default, entries remain in cache for 600 seconds, and the cache holds only 16 names (configurable via the Registry). This makes the network more efficient, in that a client does not need to contact the network for every name resolution request. The reason for the low timeout is the fact that IP addresses may change due to the use of DHCP on the network. To view the NetBIOS name cache, use the nbtstat –c command.

LMHOSTS – This text file products a static way of mappings host names to IP addresses. A deeper look at LMHOSTS files follows later in this section.

DHCP Client Configuration

Configuring client systems for DHCP is really not much different than what you are used to from Windows NT. In the Network and Dial-up Connections, pick the appropriate network adapter, and access the Internet Protocol (TCP/IP) properties.

A nice feature in Windows 2000 is the fact that changing from DHCP to a static address and vice versa does not require a reboot – which allows you to mess around with settings all you like, minus the frustration element of waiting forever during the boot process.

As with Windows NT 4, you still use the Ipconfig tool from the command prompt to view, renew, and release IP addresses. However, you should also note that Ipconfig has more functionality that in NT 4, and now allows you to reregister in DNS, view and clear your DNS resolver cache, as well as set and show class IDs, as described previously.

The switches available for Ipconfig include:

/? – displays the help message
/all – displays all configuration information
/release – releases IP address from the specified adapter
/renew – renews IP address for the specified adapter
/flushdns – purges the DNS resolver cache
/registerdns – refreshes all DHCP leases and re-registers DNS names
/displaydns – displays the contents of the DNS resolver cache
/showclassid – displays the DHCP class IDs for an adapter
/setclassid – modifies the DHCP class id for an adapter

Moving the DHCP Database

You should have an awareness of how the DHCP database can be backed up on one machine and restored to another in Windows 2000. The DHCP database is stored on the DHCP server in the %systemroot%\system32\dhcp folder. Backing up DHCP involves first stopping the DHCP service, and then copying the DHCP directory to a temporary location. However, it also involves backing up the following key to a text file:


To do the restore, simply stop the DHCP service on the target system, replace the current DHCP directory with the one you originally backed up, and restore the registry hive file that you backed up initially.

DHCP Superscopes

Windows 2000 DHCP also has the ability to create 2 other types of scopes, one of which you may be familiar with, the other which is probably new to you. Superscopes were first introduced in Windows NT 4 SP2. Essentially, a superscope is used in situations where we run out of IP addresses on a subnet. For example, a network might be subnetted to allow only 254 hosts per subnet, and may be nearing (or have already passed) that number. As such, additional IP addresses are required. One solution would be to reevaluate our addressing scheme and by changing our mask values, make the subnets larger. However, this is not only impractical on a large network, but also often nearly impossible based on the size of such an undertaking. For this purpose, we can take two (or more) scopes and combine them into a single logical Superscope. This allows IP addresses from both scopes to be handed out on a single subnet. Of course, this presents an issue with local connectivity, since the second scope has addresses not considered local on the first subnet. For that reason, you need to ensure that important systems on that subnet (like your gateways or servers for example) are provided additional IP addresses to facilitate the necessary communication. To create a Superscope, right-click the DHCP server and choose ‘New Superscope’. The wizard that starts allows you to combine any number of existing scopes into a Superscope easily.

The second new type of scope in Windows 2000 DHCP is what is referred to as a Multicast scope. A multicast scope hands out addresses to multicast-enabled applications on the network. For those who are unsure about multicasts, a multicast is a type of data transmission where data is sent out by a host once, but received by many systems listening in on a single special IP address. These special addresses fall into the Class D range, which means their first octet ranges from 224-239, a range not valid for regular host addresses. Multicasts are usually used in conjunction with ‘streaming’ type applications, such as sending video and audio over the network. The benefit of multicasting is that only a single stream gets sent, and multiple systems receive the information – a much more efficient use of bandwidth than sending multiple streams simultaneously. Multicast scopes are often referred to as MADCAP – Multicast Address Client Allocation Protocol scopes. Note that in order to be able to obtain addresses from a MADCAP scope, a client application (such as NetMeeting) must support the MADCAP API.

Configuring DHCP Options

An important part of configuring your DHCP server is configuring the options that will be included along with the IP address and subnet mask when a client makes a request. Although there were many options defined in the original DHCP specification, in reality you’ll only probably use a handful of them. I have covered the most popular ones below:

003 – Router – this option specifies the default gateway address (or addresses) to be assigned to the client, in order of preference.
006 – DNS Servers – this option specifies the IP address of DNS Servers that you wish the client to use for host name resolution, again in order of preference.
015 – DNS Domain Name – this option specifies the domain name that the client should use when resolving host names using DNS.
044 – WINS / NBNS Servers – this option specifies the IP address WINS servers to be used for Netbios name resolution.
046 – WINS / NBT Node Type – this option specifies the node type, which controls in what order the client will attempt to resolve a Netbios name to an IP address. Usually this is set to option 0x8 (h-node or hybrid) when a WINS server is used.

Note that the options above fall into the category of standard options. A new type of option, called vendor specific options also exist in Windows 2000, accessible via the advanced option tab. The Microsoft Options that you should be aware of are listed below. Note that all of these are supported on Windows 2000 clients, but may not be supported for other vendors’ systems. It is possible to add additional vendor classes, much the same as adding user classes, which will be defined shortly.

001 – Microsoft Disable Netbios Option – this option allows you to use DHCP to disable Netbios functionality on Windows 2000 clients.
002 – Microsoft Release IP Address on Shutdown Option – as the name suggests, if this option is allocated, a Windows 2000 DHCP client will fully release its IP address on shutdown, regardless of the lease duration.
003 – Microsoft Default Router Metric Base – allows you to set a default router metric, a value to be assigned to default gateway addresses on the DHCP client, used for calculating the fastest or least expensive route.

The final type of option that can be defined is what is referred to as a user class option. A user class option is one that can be created and defined. For example, I could create a special user class called ‘laptop’ and define it in DHCP.

So why would I want to do this? Simple. After defining a new class, I can then provide special options to clients of that same class. For example, I might decide that all systems that have a class ID of ‘laptop’ would have the option to release their IP address on shutdown set. But how do I set the class ID on the actual client? Simple – by using the ipconfig /setclassid command on the client. The syntax of the command is shown below:

Ipconfig /setclassid * laptop

This command will set the class ID on all my client’s network adapters to ‘laptop’. As such, when I request an IP address, I will also let the DHCP server know that I should receive all options meant for the user class ‘laptop’ as well. If the command is issued without the ‘laptop’ part, it removes the class ID from the system.

Now that you are aware of the different options that can be offered to a client, if is essential that you understand the different ways these can be allocated. The levels at which options can be allocated are Server, Scope, and Client. Options configured at the Server level apply to all scopes on the server. This provides an easy way to allocate common options, such as the address of a DNS server. Options configured at the scope level only apply to that particular scope. Finally, options configured on a client reservation apply only to the client reservation itself. In the event of conflicting settings, Server options are overridden by Scope options, which are overridden by Client options.

Configuring DHCP Scopes

Certainly the most common task when configuring a DHCP server is creating and managing scopes. A scope is created for the purpose of allocating IP addresses and a subnet mask at a minimum, but usually gateway, DNS, and WINS server information as well. A given DHCP server will usually be configured with a number of scopes, capable of leasing addresses to hosts on a number of different subnets. Each of these scopes is configured independently, and can be enabled or disabled on a scope-by-scope basis.

In Windows 2000, the scope creation process has been simplified through the use of the New Scope Wizard. This tool walks you through the entire process of creating a scope. This includes:

  • Providing a scope name and description. As a best practice you should be sure to provide a description that provides additional information. Usually the name of the scope maps to its subnet, for example ‘Scope’
  • Providing a range of valid IP addresses and a subnet mask (as shown below). At a minimum, this is the basic information that must be provided. One important note – after creating the scope, you cannot change the subnet mask. That means if you make a mistake, you’ll need to delete and recreate the scope.
  • Adding exclusions. An exclusion is a group of IP addresses from within the provided range that you wish to not be handed out by the scope. Often these addresses are ones which you have statically assigned to hosts (such as servers) on the given subnet.
  • Lease duration. Unlike in NT 4 where the lease duration was 72 hours (3 days) by default, the lease duration in Windows 2000 is now 8 days (this can of course be changed)
  • Configure Options. The last portion of the wizard allows you to configure DHCP scope options, such as providing the IP address of the gateway or DNS server for example. These will be further described in a moment.

Note that by default, your DHCP scope will not be activated until you explicitly choose to do so (by right-clicking and choosing Activate), unless you choose to configure options with the wizard, in which case the last option allows you to activate the scope. Remember that the DHCP request message sent out by clients is a broadcast, and as such will not be passed beyond the local subnet unless you routers are configured to do BOOTP forwarding (sometimes called an IP Helper address). If you are using Windows 2000 RRAS, you can set up the DHCP Relay Agent to forward DHCP broadcasts to DHCP servers on different subnets. If you do not have a DHCP relay agent (or similar) on your network, you will need to configure at least one DHCP server per subnet to handle client requests.

A few additional things about a scope that you should be aware of:

  • You can now control whether a scope you create answers DHCP clients, BOOTP clients, or both.
  • If you want to view which addresses in a scope have been leased to clients, check the ‘Address Leases’ section for a scope. This will provide information as to the leased address, the name of the system to who the lease is issued, as well as the lease expiration time.
  • For any given scope, you can view statistics on available and leased addresses quickly by choosing the ‘Display Statistics’ option.
  • As mentioned in earlier DNS articles, a Windows 2000 DHCP Server can be configured to handle client registrations in DNS. This is especially useful for situations where the client system is not capable of using dynamic DNS directly. This functionality is enabled on a scope-by-scope basis, and is configured via the DNS tab in the properties of a scope.

Another new capability in Windows 2000 is the ability to grant a user the ability to manage a DHCP server, by making them a member of the DHCP Administrators group. This allows the user to control all DHCP properties, such as creating scopes, client reservations and so forth (they cannot authorize a server, though). For the purpose of letting a group of users view the information provided by the DHCP Server, a group called DHCP Users also exists. This is handy for situations where I only want level one support to view and perhaps diagnose, because members of this group have read-only access to the DHCP information.

DHCP and Active Directory

The first thing you’ll need to understand about Windows 2000 DHCP is that if your DHCP server is part of a Windows 2000 domain, the server must be ‘authorized’ in Active Directory. If a DHCP server has not been authorized, it will not hand out IP addresses to clients. The purpose of DHCP server registration stems from the fact that unwanted DHCP servers can wreak havoc on a network. At times this is done maliciously, but often an inexperienced administrator installs the service not understanding that any DHCP server who hears a request will reply offering an address. Windows 2000 tries to solve some of these problems by requiring that DHCP be authorized, thus eliminating the problems posed by ‘rogue’ DHCP servers. While this sounds great, unfortunately the total benefit is more limited. The only servers that will check to see whether or not they are authorized are Windows 2000 DHCP servers – your NT 4 DHCP servers (and others) will continue to hand out IP addresses regardless.

The authorization process itself is very simple. Using the DHCP console tool, simply right-click the DHCP icon, choose Manage Authorized Servers, and then authorize the server by adding its name or IP address, as shown below. Note that the only person who can authorize a DHCP server is a user who is a member of the Enterprise Admins group (this ability can be delegated if required)

When the DHCP server service attempts to start (which happens automatically during a reboot), it will send a DHCPINFORM message to Active Directory to determine its authorization state. If it has been authorized, the service starts correctly. If it hasn’t, the service does not start. The DHCP server will query Active Directory periodically (every 5 minutes by default) to ensure that its authorization status hasn’t changed.