DHCP – 2000Trainers.com

Managing Changes to DHCP with NETSH

How many times have you been approached by the Network Engineering Group with the news that the internal IP scheme needs to be changed or that VLAN’s are going to be implemented on all switching equipment? The first will require some configuration, but the second can mean large amounts of work to create and configure the new scopes and scope options needed to complement the additional subnets.

The DHCP MMC snap-in can definitely facilitate this procedure; however, the NETSH utility offers a method to script modifications to DHCP scopes automatically. For those of you who are still building your VBScript, WMI, and ADSI scripting skills, don’t fret. This is good old-fashioned command line work and doesn’t require knowledge of objects, methods, components, etc.

The NETSH utility has many different functional parameters within the DHCP context alone. As there are far too many options to cover at one time, this guide will focus on the following common administrative tasks in making changes to DHCP scopes that can be accomplished with NETSH:

Dumping scopes and configurations from and existing DHCP server into a text file.
Creating a new scope.
Defining the range of the scope.
Adding options to the scope.
Assigning reservations for IP addresses.
Listing authorized DHCP servers and authorizing DHCP servers.

Dumping Existing Scopes and Configurations

Getting your configuration in a text file is a great method to obtain as much or as little dhcp information as needed in a single document without navigating around the MMC. The following example run from the command line will dump all information for the scope 192.168.2.0 from the DHCP server 192.168.2.5 into a text file call test.txt. Note – You may also specify the DHCP server by name. For example: \\DHCP-SVR01.

C:\>netsh -c dhcp server 192.168.2.5 scope 192.168.2.0 dump > c:\test.txt

The first few lines of output will resemble the following:

# Changed the current scope context to 192.168.3.0 scope.Dhcp Server 192.168.2.5 add scope 192.168.3.0 255.255.255.0 "ScopeA" "First Scope" Dhcp Server 192.168.2.5 Scope 192.168.3.0 set state 1

# ============================================================
# Start Add Ipranges to the Scope 192.168.3.0, Server 192.168.2.5
# ============================================================

All lines with the hash mark (#) are ignored as input similar to the REM statement used in batch files. The two lines beginning with Dhcp Server are actual commands that can be edited to change information and then the file can be used as an input script which we will cover later in this work.

Creating a new scope

To create a new scope we will use one of the lines in the above example to create a scope for the network ID 192.168.3.0. For this example, the first non-commented line is copied to notepad and then the file is saved as C:\dhcp.txt.

Next, from the command line we run C:\>netsh exec c:\dhcp.txt. This creates and activates the new scope as shown below. Note – The scope does not have any Property Options set at this time, hence the blue information icon.

Defining the range of the scope

In order for the clients to lease IP’s, we must obviously assign a range from which leases will be distributed. This is done as follows in our script:

Dhcp Server 192.168.2.5 Scope 192.168.3.0 add iprange 192.168.3.1 192.168.3.254 Dhcp Server 192.168.2.5 Scope 192.168.3.0 add excluderange 192.168.3.1 192.168.3.10

Note – that an exclusion range is included in the example to prevent a range of IP addresses from being assigned to the clients.

As we are executing these commands in steps from our script, we will save the lines above to C:\range.txt. Going back to the command line, we now run C:\>netsh exec c:\range.txt which adds the ranges to the scope as shown below in the MMC:

Adding options to the scope

Now that the scope is created, we need to add some options for the clients to better define their DHCP leases. Note – Normally, these lines would be included in the script (dhcp.txt) underneath the line that defines the range of the scope and actually run in the previous step. Since it is activated upon creation, clients that might lease IP addresses from this scope would need the defined options at the time of lease. This has been broken into steps in this article for subject demonstration. To create a scope that was deactivated initially, the following line would need to be added after the first line in the script:

Dhcp Server 192.168.2.5 Scope 192.168.3.0 set state 0

This example will add the standard options: router (gateway), DNS servers, and lease expiration to the scope. All possible options can be scripted, but are beyond the scope of this example. It is possible to get the syntax for all options for scripts by creating a dump file at the server level instead of the scope level. The syntax for the three options we will use is as follows in the script file:

Dhcp Server 192.168.2.5 Scope 192.168.3.0 set optionvalue 3 IPADDRESS "192.168.2.2" Dhcp Server 192.168.2.5 Scope 192.168.3.0 set optionvalue 6 IPADDRESS "192.168.2.5" "192.168.2.6" Dhcp Server 192.168.2.5 Scope 192.168.3.0 set optionvalue 51 DWORD "691200"

The first line sets the router for the scope. This is the gateway the clients will use to leave the defined network. The second line assigns DNS servers to the client leases and can include as many as needed. The third line in this example assigns the expiration for the lease. In this case 8 days expressed in seconds (691200 seconds/60 = 11520 minutes/60 = 192 hours/24 = 8 days). Again, the changes can be verified in the MMC.

Note – The lease expiration is not viewable in this screen as it is a property of the scope and not an option. This may be viewed by right-clicking on the scope and selecting Properties.

Assigning reservations to the scope

To assign the same IP to a client whenever the lease is renewed, we can define reservations via the netsh script. As we are using multiple steps to create the scope in this example, we will use the following syntax and save the file as C:\reserve.txt.

Dhcp Server 192.168.2.5 Scope 192.168.3.0 add reservedip 192.168.3.20 00043c40fb6a SVR01 Dhcp Server 192.168.2.5 Scope 192.168.3.0 add reservedip 192.168.3.21 0600ba34f50c SVR02 Dhcp Server 192.168.2.5 Scope 192.168.3.0 add reservedip 192.168.3.22 02003b5d80ca SVR03

In this example, we are working on server 192.168.2.5 in scope 192.168.3.0. The number at the end of the line is the MAC (Media Access Control) address of the NIC card. This ensures that whenever this NIC requests a lease renewal, it will always get the same IP. The name on the end is simply for labeling the reservation in DHCP, it has no effect on the client. We now execute the script file with the following syntax from the command line: C:\>netsh exec c:\reserve.txt. Again, we can verify the results in the MMC.

Note – I have run into intermittent issues with reservation client types where the reservation will sometimes be assigned a lease type of BOOTP instead of DHCP. This can be forced by adding another entry to the end of each line of the script specifying any of the following options [BOOTP | DHCP | BOTH] as needed.

Listing and authorizing DHCP servers in Active Directory

It is possible to verify and list all the authorized DHCP servers in Active Directory from the command line using the following syntax: C:\netsh dhcp show server. This allows you to view all authorized servers to ensure that an over-eager administrator hasn’t added an unnecessary server to the network.

You may also authorize a DHCP server in AD remotely with the following command:

C:\ netsh dhcp add server DHCP-SVR01.yourdomain.com 10.2.2.2

This one can be extremely handy if you want to hand off the job of creating the DHCP scopes and/or server to a junior admin. As Enterprise rights are needed to authorize the server, the work could be verified before going into production and then authorized remotely from the command line. Note – Remember that it can take a DHCP server 15 minutes to authorize so if it doesn’t show up immediately, give it a little while to process.

Bringing it all together

This has been broken into steps for better demonstration; however, all of the steps can be combined into a single script after you are comfortable with the syntax. The completed script would look like the following:

Dhcp Server 192.168.2.5 add scope 192.168.3.0 255.255.255.0 "ScopeA" "First Scope" Dhcp Server 192.168.2.5 Scope 192.168.3.0 add iprange 192.168.3.1 192.168.3.254 Dhcp Server 192.168.2.5 Scope 192.168.3.0 add excluderange 192.168.3.1 192.168.3.10 Dhcp Server 192.168.2.5 Scope 192.168.3.0 set optionvalue 3 IPADDRESS "192.168.2.2" Dhcp Server 192.168.2.5 Scope 192.168.3.0 set optionvalue 6 IPADDRESS "192.168.2.5" "192.168.2.6" Dhcp Server 192.168.2.5 Scope 192.168.3.0 set optionvalue 51 DWORD "691200" Dhcp Server 192.168.2.5 Scope 192.168.3.0 add reservedip 192.168.3.20 00043c40fb6a SVR01 Dhcp Server 192.168.2.5 Scope 192.168.3.0 add reservedip 192.168.3.21 0600ba34f50c SVR02 Dhcp Server 192.168.2.5 Scope 192.168.3.0 add reservedip 192.168.3.22 02003b5d80ca SVR03 Dhcp Server 192.168.2.5 Scope 192.168.3.0 set state 1

This would all be saved to a single file and run using the C:\>netsh exec filename.txt command from the command line.

Netsh is a very powerful command line tool with MANY other options and uses. The syntax can be tricky but after a little practice, you’ll find that it simplifies several mundane administrative tasks.

DHCP Relay Agent

A DHCP Relay Agent should be configured on you RRAS server if you wish for remote access clients to obtain complete IP settings via DHCP. If you choose to have clients obtain settings from DHCP without setting up a Relay Agent, then the client will only obtain an IP address and subnet mask from the server, regardless of which options may exist. The traditional use of a DHCP Relay Agent was to act similar to a BOOTP Forwarder, a system that allows DHCP broadcasts to be directed to a DHCP server that may exist on another subnet. If DHCP Relay Agents (or equivalent) are not used, then a DHCP server must exist on the same subnet as the client, which may not be practical.

In RRAS, a DHCP Relay Agent is configured under the IP Routing section. By accessing the DHCP Relay Agent properties, you can configure to which servers DHCP requests will be forwarded by this agent.

Note also that by double-clicking on any interfaces in the DHCP Relay Agent interfaces, you can configure both the Hop-count Threshold (which controls the maximum number of relay agents that will handles a request), as well as the Boot Threshold (the number of seconds that the relay agent will wait prior to relaying requests) for the agent. The default value in both cases is 4.

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:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DHCPServer

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 192.168.1.0/24’
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.

DHCP Overview

At a minimum, you should certainly be familiar with the basic purpose of DHCP – to provide client systems with IP addresses. The main reason for the existence of DHCP as a service is the fact that it greatly simplifies the allocation of IP addresses to clients, a process that when done manually can lead to errors, duplication, and a great deal of time spent less than efficiently. Although DHCP does the basic thing that you expect it to in Windows 2000, there is a great deal more functionality that was found in the version from NT 4, and you’ll need to be aware of the differences. Some of the ‘new’ functionality isn’t actually new – for example, DHCP supported the ability to create Superscopes in NT 4 SP2. However, since many of you probably don’t have much experience with Superscopes, I’ll describe them here. On the whole, you’ll probably be impressed with some of the new features of DHCP in Windows 2000, while being able to build on the understanding you originally acquired under NT 4. Nothing like a nice and simple topic to get us started on the last portion of the series.

Windows DHCP Servers

The Dynamic Host Configuration Protocol is a core networking service offered in Windows 2000 Server used to dynamically allocate IP addresses and associated information to TCP/IP-based clients. Although the function provided by DHCP is similar to what was provided in NT 4, a number of minor changes have taken place that you should be aware of. Again, note that this section is meant as an introduction to DHCP, and is provided as a basis for the Server portion of the exam. A much more detailed explanation of the configuration of DHCP will be covered during the networking services exam portion of the series.

The DHCP Server service is installed automatically by Windows 2000 Server, but is not configured (and may even be disabled) without further input. It can be removed or added if necessary, using the Add/Remove Windows Components option in Add/Remove Programs in Control Panel (it falls under Networking Services). Once installed, the DHCP server is configured using the DHCP MMC snap-in, which can be found under Administrative Tools. If the server running Windows 2000 is part of a workgroup or non-Windows 2000 domain, the DHCP service will be started, but you will need to manually configure scopes of addresses for the DHCP service to hand out (more on this in a bit). If DHCP is installed on a system that is part of a Windows 2000 domain, the DHCP service cannot be started until the DHCP server is authorized in Active Directory.

The authorization of a DHCP server in Active Directory can only be done by a member of the Enterprise Admins group. This is meant to be used as a control mechanism in order to alleviate the problems caused by people (such as other administrators) installing ‘rogue’ DHCP servers which end up having an impact on the configuration of a TCP/IP-based network (since a client receives an IP address from the first server that responds to its request). In a Windows 2000 Active Directory domain, only authorized Windows 2000 DHCP servers can hand out IP addresses. Note that this only works in conjunction with Windows 2000. A Windows NT 4 DHCP server can (and will) still hand out addresses, and will not be impacted by authorization. However, if another administrator tried to install a Windows 2000 DHCP server and start the service without it being authorized, the server would query AD, and then not start the service since it would find it is not authorized on the network. Note that an unauthorized DHCP server appears in the DHCP tool with a downwards-pointing red arrow (which can also mean that the service is not started, or a scope is not configured).
In order to authorize a DHCP server, right-click on the server and choose Authorize. To manage authorized DHCP servers (including adding or removing authorized servers), right click the DHCP icon, and choose Manage Authorized Servers.

Pages: 12