Networking

Understanding new DHCP features in Windows 2000

Unsure of how to make DHCP work effectively with Windows 2000 and Active Directory? Jim Boyce gives you the scoop in this Daily Drill Down.


One of the easiest ways to manage the complex task of keeping up with all of the TCP/IP addresses on your network is by using Dynamic Host Configuration Protocol (DHCP). However, using DHCP in an Active Directory (AD) environment can be full of pitfalls if you’re not careful. In this Daily Drill Down, I’ll show you how DHCP works and how to make it work effectively with Windows 2000 and Active Directory.

What is DHCP?
As you know, each node on a TCP/IP network must have a unique IP address. Computers are typically nodes, but other devices such as printers and routers can also be nodes and thus require unique addresses, whether the network they’re connected to is local or connected to the Internet.

You have two options for assigning addresses. With the first option, static assignment, you manually assign an IP address to a given node. The address doesn’t change unless you manually change it. Devices that always need the same IP address, such as Web servers or other devices that clients access by their address, should generally be assigned static IP addresses.

The second option involves assigning IP addresses dynamically through DHCP. A DHCP server allocates IP addresses to clients as those clients start up. While the address retrieved through the lease from the server can remain the same from session to session, it may also change, meaning the node could have a different IP address for each session. This makes DHCP most useful for workstations and other devices that don’t require a fixed IP address.

The biggest benefit to using DHCP is simplified administration. You can centrally manage a range of IP addresses and associated settings (a gateway address, DNS server assignment, and so on) and effect changes to the network by simply changing the settings at the DHCP server. You don’t have to make changes manually at each workstation or device; instead, you can implement a change simply by restarting those systems or releasing and renewing the address lease. When the users restart their workstations, the changes will automatically take effect.

Active Directory integration and unauthorized server detection
Unauthorized servers can cause real headaches for network administrators by allocating conflicting or incorrect addresses or related settings to clients. For example, an inexperienced administrator or a power user might bring up a new DHCP server, unaware that it will cause a conflict on the network. Fortunately, Windows 2000 integrates DHCP into AD to provide detection and protection against unauthorized DHCP servers.

AD stores a list of authorized DHCP servers. When a Windows 2000 DHCP server starts up in a domain, the server checks to see if it is listed as an authorized server in AD. If the service finds itself in the list, it starts processing DHCP requests from clients. If the server doesn’t find itself in the list or isn’t able to connect to AD, the server assumes it is not authorized and ignores DHCP client requests.

Stand-alone servers that are not members of a domain provide a similar capability but through a slightly different mechanism. When the stand-alone DHCP server starts, it broadcasts a DHCPINFORM message on the network. Domain-member DHCP servers respond with a DHCPACK message and a notification of the directory domain to which they belong. If a stand-alone server receives a DHCPACK message, it assumes that it isn’t authorized and does not respond to DHCP client requests. So, workgroup DHCP servers will function by themselves or coexist with other workgroup DHCP servers, but they will not operate when domain-based DHCP servers are present.

Automatic addressing without DHCP
When a Windows 2000 client configured for automatic addressing comes up, it attempts to obtain an address from a DHCP server. If that attempt fails, the client attempts to ping the default gateway defined in its current lease. The client continues to use the existing lease if the ping succeeds, and then checks for a DHCP server every five minutes for a new lease. If the ping fails, the client assumes that DHCP services are not available on the network and automatically assigns itself a non-conflicting IP address in the private address range 169.254.n.n (subnet 255.255.0.0).

Installing and managing DHCP on Windows 2000
As with most services, you install DHCP through the Add/Remove Programs utility in Control Panel. Click Add/Remove Windows Components. Open the Networking Components item, select Dynamic Host Configuration Protocol (DHCP), and click OK. Click Next to finish the installation.

After you install DHCP, you manage the service through the DHCP console. You use the console to create scopes, which are ranges of IP addresses and their corresponding properties, such as gateway, DNS server addresses, and so on. You also use the console to create superscopes and multicast scopes. Superscopes are an administrative feature that lets you create and manage multiple scopes as a single entity. Multicast scopes are address scopes used for multicast address assignment (you’ll learn more about multicast addressing later). In addition, you use the DHCP scope to configure global DHCP service properties, view current address leases, and manage the service. Figure A shows the DHCP console.

Figure A
Use the DHCP console to manage DHCP servers locally and remotely.


Creating scopes
As mentioned, a scope is a set of properties that define a range of IP addresses and its related settings. Each DHCP server needs at least one scope. The scope can be either active or inactive, and the server allocates addresses only from active scopes. So, the next step in setting up your DHCP server is to create and activate at least one scope.

The DHCP console provides a wizard to help automate the process of setting up a scope. Open the DHCP console, right-click the server, and choose New Scope. Provide the following information to the wizard:
  • Name: This requires the name of the scope as it appears in the DHCP console.
  • Description: Use this optional description to help you identify the purpose or address range of the scope. The description appears in the scope’s General property sheet when you right-click the scope and choose Properties.
  • Start and End IP addresses: Specify, in dotted octet format (xxx.xxx.xxx.xxx), the starting and ending addresses that define the address range for the scope.
  • Length or subnet mask: Specify the subnet mask for the range or the address length to define the range’s subnet.
  • Exclusions, Start address, and End address: You can use this page of the wizard to define one or more ranges of addresses to be excluded from the scope (not assigned to clients). For example, you might need to exclude a range of addresses used by Web servers or other fixed-address nodes. You don’t need to create exclusions for address ranges outside the beginning and ending range of the scope. Any exclusion ranges you create must fall within the range defined by the scope on the previous page of the wizard.
  • Lease duration: Use this property to specify the length of time the address lease is valid to the client. This property defines the default lease duration unless it is modified by a vendor or user class property. The default value is eight hours.
  • Configure other options: The wizard lets you set other properties for the scope, such as the default gateway, DNS servers, and so on. I’ll examine these properties in the next section, “Configuring scope options and properties.”
  • Activate the scope: You can activate the scope as the last step in the wizard if you’ve defined all necessary properties. If not, you can configure the necessary properties after the wizard completes, and then activate the scope separately.

Configuring scope options and properties
To configure scope properties after you’ve created the scope, simply open the DHCP console, expand the server and then the scope, right-click Scope Options, and choose Configure Options. The Scope Options property sheet, seen in Figure B, will appear. Now define the settings that apply to all clients receiving address leases through the scope, as well as those settings that apply to specific types of clients.

Figure B
Use the Scope Options property sheet to define global DHCP lease properties.


The settings available through the General page apply to all clients. You simply select a property from the list and use the controls in the bottom half of the page to specify a value, range, and so on, depending on the requirements of the property.

Use the Advanced property page to configure properties for specific vendor and user classes. Windows 2000 provides a set of default vendor classes, which include the following:
  • DHCP standard options: These apply to all clients for which a vendor or user class isn’t specified and are the same as those that appear on the General property page.
  • Microsoft options: Use this class to specify DHCP properties for all Microsoft clients.
  • Microsoft Windows 2000 options: Use this class to specify DHCP properties for all Windows 2000 clients.
  • Microsoft Windows 98 options: Use this class to specify DHCP properties for all Windows 98 clients.

Windows 2000 also provides a set of default user classes, which include the following:
  • Default BOOTP Class: BOOTP provides a valid address and a boot image to BOOTP clients, enabling those clients to boot across the network. BOOTP is most commonly used for diskless workstations that have no local OS image from which to boot. The properties assigned to this class apply to all BOOTP clients.
  • Default Routing and Remote Access Class: These properties are assigned to clients that take their lease through RRAS connections.
  • Default User Class: This class allocates settings to clients not served by any other user class.

Whether you’re assigning properties globally or through vendor/user classes, you typically define the same types of settings in most installations. These include the router and DNS servers. The Router property defines the default gateway for the client. You can specify multiple addresses to allocate multiple gateways. The DNS Servers property assigns DNS servers to the clients. As with the router list, you can specify multiple DNS servers. Depending on the complexity, requirements, and capabilities of your network, you might also assign other properties such as time servers, SMTP, POP3 servers, and so on. We’ll cover more about vendor and user classes later.

Creating reservations
A DHCP reservation reserves a specific IP address for a specific MAC address, which is the unique physical hardware address of the client’s network adapter. In effect, the reservation assigns a specific address to the client, but to be more precise, the reservation assigns a specific IP address to a client’s network adapter. This is really a distinction only when the client has more than one network adapter. Reservations provide the best of both worlds—a static IP address with other variable settings (gateway, DNS, and so on).

To create a reservation, you need the MAC address of the client’s network adapter. On Windows 2000 and Windows NT systems the easiest way to determine the MAC address is by using the ipconfig /all command. On Windows 9x systems, run winipcfg to determine the MAC address.

Once you have determined the MAC address, open the DHCP console, expand the scope, right-click Reservations, and choose New Reservation. A wizard will prompt you for a reservation name, IP address, MAC address, description, and supported types (DHCP, BOOTP, or both).

Setting global options
Another aspect of setting up a scope is setting its global properties. You access these properties through the DHCP console by right-clicking the scope and choosing Properties. The options on the General page are self-explanatory. The DNS page shown in Figure C defines how DHCP integrates with Dynamic DNS, and it includes the following settings:

Figure C
The DNS page defines how DHCP integrates with Dynamic DNS.

  • Automatically update DHCP client information in DNS: This option configures the DHCP server to attempt to update host and pointer records in the DNS server(s) on behalf of clients.
  • Update DNS only if DHCP client requests: With this option the server attempts an update of the records in the DNS server only if the client submits an update request.
  • Always update DNS: Use this option to have the server attempt DNS updates even if the client doesn’t request it.
  • Discard forward (name-to-address) lookups when lease expires: This option causes the DHCP server to request that the DNS server discard the client’s host record when the client’s lease expires.
  • Enable updates for DNS clients that do not support dynamic update: This option enables the DHCP server to request DNS updates on behalf of clients that don’t support Dynamic DNS (such as Windows 9x and Windows NT clients).

Domain-based DHCP servers are by default unauthorized in AD, which prevents unauthorized servers from simply authorizing themselves at installation. So, you need to manually authorize a domain-based DHCP server after you install the service. After you’ve configured the server to fit your needs, open the DHCP console, right-click the server, and choose Authorize. You don’t need to authorize workgroup-based DHCP servers.

Using vendor and user classes
Vendor classes enable you to create predefined scope options that apply to a particular device or operating platform. You then use user classes to assign scope properties within each vendor class. For example, you might assign a shorter lease duration period to notebook computers on the network because they come and go more frequently than other clients.

For the most part, vendor classes are really just containers that group together DHCP options by name. Typically you’d use the vendor class to define new scope properties that are not already defined by the existing standard options. When you create a vendor class, you specify a name, description, and ID. The ID actually identifies the vendor class. The name and description simply provide a means to identify the vendor class within the DHCP console.

As you might expect, you use the DHCP console to create vendor classes. In the console, right-click the server and choose Define Vendor Class. Click Add in the DHCP Vendor Classes dialog box. In the resulting dialog box, specify the vendor class properties. When you specify the ID, use something that helps you identify the purpose of the class. For example, you might use the vendor name as part of the ID string.

Next, configure the custom options for the vendor class. In the DHCP console, right-click the server and choose Set Predefined Options to display the Predefined Options And Values dialog box. Click Add, and then provide the following information:
  • Name: This is the name that appears in the DHCP console in the Available Options list on the Scope Options property page. Pick a name that will help you identify it.
  • Data type: Select the type of data represented by the option.
  • Array: Select this option if you’re creating an array of data, such as a list of DNS servers or gateways.
  • Code: Enter a unique numeric ID for the option.
  • Description: Use this optional description to help you keep track of the option’s purpose.

Vendor classes can take awhile to set up and configure. You might find they’re more trouble than they’re worth unless you’re managing a very large number of computers with special requirements.

User classes, another new addition to DHCP in Windows 2000, let you allocate settings to individual clients based on an assigned client class ID. For example, you might create a user class called ShortLease that assigns a shorter lease duration period to certain types of clients, such as notebook computers, that connect and disconnect frequently from the network. Or, perhaps you have a group of computers that require a specific gateway or set of DNS servers. You can use class IDs to uniquely identify these clients and have their settings allocated accordingly.

User classes are not strictly a server-side feature. The client must support user classes by enabling the client to be assigned an appropriate class ID. The client passes the class ID to the DHCP server, which responds with the DHCP settings associated with that class ID, along with other settings that apply on a global basis. So, putting user classes to work is a two-phase process that involves first, configuring the user classes and their settings at the DHCP server, and second, assigning user classes to the clients that need them.

To configure a user class and settings at the server, open the DHCP console, right-click the server, and choose Define User Classes. Click Add, and then provide a name, description, and unique class ID for the new user class. You can enter the class ID as either an ASCII or hexadecimal value.

Next, you need to configure the non-global settings for the user class (those settings you want assigned specifically to the user class). To override the default settings, simply expand the server in the DHCP console, right-click Scope Options, and choose Configure Options. Click the Advanced tab, select the vendor class that defines the options you want to set, and then select the user class from the drop-down list, as shown in Figure D. Configure your settings as needed in the Available Options list, and then click OK. Keep in mind that you need to configure only nonstandard options for the user class. The client will take the global settings assigned to the scope for all settings not explicitly set by the user class.

Figure D
Use the Advanced tab to configure settings for the user class.


The last step is to configure the class ID at the client. You can use the Ipconfig command to do so. At the client, begin by opening a console prompt and issuing the following command:
ipconfig /setclassid adapter ClassID

Replace adapter with the network interface name for the adapter whose class ID you want to set. The adapter name appears in the Network and Dial-Up Connections folder under the connection’s icon. Replace ClassID with the class ID string you want to assign to the client, matching the string assigned on the server when you created the user class.

Using superscopes
Superscopes are a new administrative feature in Windows 2000 DHCP that enables you to collectively manage multiple DHCP address scopes as a single entity. For example, you might use superscopes to manage addresses on a multinet—a physical network that contains multiple logical IP networks. Superscopes also are useful for supporting DHCP clients on the far side of a DHCP or BOOTP relay agent, since those clients reside in different subnets from the local subnet.

You can create as many superscopes as you like on a given server—you aren’t limited to just one. In addition, the server can manage individual scopes outside of any defined superscopes, giving you a lot of flexibility in how you create and manage the scopes.

You’ll typically configure settings at three levels: server, scope, and class. Settings you apply at the server level apply to all clients, regardless of scope. Although you might equate server-level settings as superscope settings, keep in mind that a superscope is just an administrative entity—it doesn’t maintain or allocate any of its own settings.

Scope settings apply only within the selected scope. Default gateway is a setting you’ll typically configure at the scope level. All clients can probably use the same DNS servers, so those can be set at the superscope (server) level. You can then fine-tune settings through user class assignments.

You can’t create an empty superscope, so your first step is to create the scopes that will belong to the superscope. You can start with a single scope, and then add new scopes later if needed. After you’ve created at least one scope using the DHCP console, right-click the server and choose New Superscope. Specify a name for the superscope and select the existing scopes to add to the superscope. You can hold down the [Shift] key while you’re selecting to pick multiple scopes.

The way Windows 2000 treats the superscope for activation depends on the status of the scopes in the superscope. If one or more scopes in a superscope are already active, Windows 2000 automatically activates the superscope. If no scopes in the superscope are active, you must manually activate the superscope when you’re ready to start using it. You can activate individual scopes or activate all scopes by activating the superscope. In the DHCP console right-click a scope or the superscope, and then choose Activate. Likewise, when you deactivate a superscope, all scopes in the superscope are deactivated. If you want to deactivate a scope, right-click an individual scope and select Deactivate to deactivate only that scope.

You can remove a scope from a superscope, but you can’t add existing scopes to an existing superscope. So, make sure you really want to remove the scope, because you won’t be able to put it back in the superscope without deleting and recreating the scope. To remove a scope, expand the superscope in the console, right-click the desired scope, and select Remove From Superscope. You can also delete a superscope without affecting its member scopes. When you delete the superscope, the member scopes become individual scopes. You can then recreate a superscope to contain them, if necessary.

Using multicast scopes
One final aspect of DHCP we’ll touch on is multicast addressing and multicast scopes. Multicast addresses are used to broadcast IP traffic to a group of clients through a single broadcast IP address. In other words, a group of clients shares an address and receives traffic as a group through that address. Multicast addressing is typically used in video and audio conferencing. Multicast addressing decreases network traffic by sending a packet once to a group of clients rather than sending the same traffic individually to each client.

Windows 2000 supports the Multicast Address Dynamic Client Allocation Protocol (MADCAP) for allocating multicast addresses to clients. A Windows 2000 server can function as both a DHCP server and a MADCAP server, or perform either function independently. Clients can use DHCP, MADCAP, or both, as needed.

You can configure multiple multicast address scopes on a server, provided those address scopes don’t overlap. Windows 2000 doesn’t support multicast superscopes, so you’ll have to create the multicast scopes directly under the server level in the console and manage them individually.

To create a multicast scope, open the DHCP console, right-click the server, and choose New Multicast Scope. Windows 2000 will prompt you for the following information:
  • Name: Enter a scope name, which will appear in the DHCP console.
  • Description: Use this optional description to help identify the multicast scope.
  • Address range: Specify the multicast address range using addresses between 224.0.0.0 and 239.255.255.255.
  • Time to Live (TTL): Specify the number of routers on your local network through which the multicast traffic must pass.
  • Exclusion range: Define a range of addresses to be excluded from the multicast address range (optional).
  • Lease duration: Specify the lease duration for the multicast scope. The default is 30 days.

You can activate/deactivate multicast scopes just as you can a unicast scope. In the DHCP console, right-click the multicast scope and choose Activate to activate the scope.

Conclusion
DHCP can be a very handy tool for distributing and managing large numbers of TCP/IP addresses on your network. Microsoft has done a lot of work to make DHCP more flexible and powerful in Windows 2000. In this Daily Drill Down, I’ve shown you how DHCP works on Windows 2000.

Jim Boyce is a former contributing editor and monthly columnist for WINDOWS Magazine. Jim has authored and co-authored over 40 books about computer software and hardware. He has been involved with computers since the late 1970s as a programmer and systems manager in a variety of capacities. He has a wide range of experience in the MS-DOS, Windows, Windows NT, Windows 2000, and UNIX environments. In addition to a full-time writing career, Jim is a founding partner and vice president of Minnesota Webworks, a Midwest-based Web development firm.

The authors and editors have taken care in preparation of the content contained herein, but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for any damages. Always have a verified backup before making any changes.

Editor's Picks

Free Newsletters, In your Inbox