Deploying DHCP

C H A P T E R 2
Deploying DHCP
Dynamic Host Configuration Protocol (DHCP) in the Microsoft® Windows® Server 2003 family of operating
systems enables centralized automatic management of IP addresses and other TCP/IP settings for network
clients. You can reduce administrative overhead in your organization by designing and implementing a reliable
and scalable DHCP solution.
In This Chapter
Overview of DHCP Deployment................................................................ .............70
Creating Your DHCP Server Design................................................................ ........72
Integrating DHCP with Other Services.......................................................... .........81
Defining Scopes........................................................................... .........................84
Implementing Your DHCP Solution...................................................................... ...95
Example DHCP Implementation.............................................. ............................102
Additional Resources.............................................................................. .............110
Related Information
• For more information about Dynamic Host Configuration Protocol (DHCP), see the
Networking Guide of the Microsoft® Windows® Server 2003 Resource Kit (or see the
Networking Guide on the Web at http://www.microsoft.com/reskit).
• For more information about integrating DHCP with Domain Name System (DNS), see
“Deploying DNS” in this book.
• For more information about integrating DHCP with Windows Internet Name Service (WINS),
see “Deploying WINS” in this book.
70 Chapter 2 Deploying DHCP
Overview of DHCP Deployment

Valid IP addresses and other network options must be configured for all computers and other devices on the
network, such as printers, in a corporate network. Manually configuring this information is a time-consuming
process that adds significant costs to an organization and is susceptible to user error.
Windows Server 2003 Dynamic Host Configuration Protocol (DHCP) reduces the complexity and
administrative overhead involved in managing network client IP addressing and configuration. DHCP allows
you to assign IP addresses to network clients automatically and dynamically, as needed, and to automate,
centralize, and simplify IP address and option configuration and distribution across your network. This protects
against common configuration errors that occur when values are entered manually at each computer and helps to
prevent address conflicts.
By using DHCP options, you can configure DHCP servers to supply a full range of configuration values when
assigning a DHCP lease, allowing you to configure a large number of computers at one time, and to change
configuration as necessary.
Different types of organizations can benefit from the automation and centralization that Windows Server 2003
DHCP provides, including:
• Organizations in which administrators are responsible for configuring IP addresses and options
for a large number of devices.
• Organizations that include a large population of mobile users or network configurations that
frequently change.
• Organizations that already use versions of DHCP earlier than Microsoft® Windows® 2000,
which can benefit from the added functionality of Windows Server 2003 DHCP by upgrading
their DHCP deployment.
If you are deploying DHCP in a new Windows Server 2003 environment, begin your deployment process by
creating a design for your DHCP servers. When you have completed all of the design steps for your DHCP
infrastructure, you can implement your DHCP solution by configuring your DHCP servers. If you are upgrading
your existing DHCP infrastructure to Windows Server 2003, begin by reviewing your current DHCP design and
modifying it if required, and then migrate your existing DHCP databases.
Additional Resources 71
DHCP Deployment Process

Deploying or upgrading DHCP in your organization involves several important planning, design, and
implementation steps. Figure 2.1 shows the process for deploying DHCP.
Figure 2.1 Deploying DHCP
Creating Your DHCP Server

Design
It is important to create a DHCP server design that meets the needs of your organization in terms of
functionality, availability, interoperability, and total cost of ownership (TCO).
Figure 2.2 shows the process for creating a DHCP server design.
Figure 2.2 Designing Your DHCP Server
Upgrading Your Existing DHCP Server

Hardware
Determine whether your current hardware and software, including routers, switches, and other servers and
clients, support Windows Server 2003 DHCP. Windows Server 2003 DHCP servers support Windows DHCP
clients and third-party operating systems that use DHCP and comply with RFC 2131. For more information
about the operating systems that support DHCP, see the Networking Guide of the Windows Server 2003
Resource Kit (or see the Networking Guide on the Web at http://www.microsoft.com/reskit).
If your current systems support Windows Server 2003, but are close to the end of their expected lifecycle,
consider upgrading your hardware at the same time that you upgrade to Windows Server 2003. Upgrading
DHCP servers running Microsoft® Windows NT® Server version 4.0 or earlier to Windows Server 2003 allows
you take advantage of benefits related to the Active Directory directory service, such as integrated secure
dynamic updates of the DNS database.
For information about hardware life expectancy, contact your hardware vendor or refer to any internal metrics
that your organization might have developed. For information about hardware compatibility, see the Windows
Catalog link on the Web Resources page at http://www.microsoft.com/windows/reskits/webresources.
For more information about performing a hardware inventory, see “Planning for Deployment” in Planning,
Testing, and Piloting Deployment Projects of this kit.
Determining DHCP Server Locations

To determine where to locate your DHCP servers, consider whether you are deploying a distributed, centralized,
or combined DHCP infrastructure.
For a distributed DHCP infrastructure, locate a DHCP server on each subnet. Because distributed infrastructures
use a DHCP server on each subnet, they require a greater number of servers than centralized networks. For
example, a network that includes 30 subnets and that is using a true distributed topology requires at least 30
DHCP servers, and possibly more to provide for redundancy.
In a centralized DHCP infrastructure, DHCP servers are placed in a central location. A centralized DHCP
topology requires the deployment of DHCP/bootstrap protocol (BOOTP) relay agents. Additional hardware
resources are not generally required for DHCP relay agents; in most cases, the routers that are positioned
between each subnet can assume this role, as defined in RFC 1542. If the routers cannot relay DHCP messages,
configure a computer running Windows Server 2003 to act as a DHCP/BOOTP relay agent. For more
information about configuring relay agents, see “Enabling DHCP Support for Multiple Subnets” later in this
chapter.
Combining both distributed and centralized DHCP infrastructures provides the maximum efficiency for your
network. In a combined DHCP infrastructure, the locations for DHCP servers are based on the physical
characteristics of the local area network (LAN) or wide area network (WAN) infrastructure, and not the logical
groupings defined by the Active Directory logical structure. DHCP servers are not required for every subnet if
the connecting routers support DHCP/BOOTP relay agents. You can administer Windows Server 2003 DHCP
servers remotely from a computer running Windows Server 2003 and Microsoft Management Console (MMC)
DHCP snap-in. You can also administer a DHCP server remotely at the command line by using Netsh
commands for DHCP, or you can remotely administer a DHCP server from a computer running Microsoft®
Windows® XP Professional that has the Windows Server 2003 Administration Tools Pack installed. You must
have the correct level of security permissions in order to administer a DHCP server. For more information about
using the Windows Server 2003 Administration Tools Pack, see “Windows Server 2003 Administration Tools
Pack” in Help and Support Center for Window Server 2003.
Optimizing DHCP Server Performance

You can optimize the performance of DHCP servers in your organization by doing the following:
• Extending the duration of the IP address lease.
• Improving DHCP server hardware, specifically upgrading to a faster hard drive or adding
random access memory (RAM).
Extending the IP Address Lease and Renewal Duration

The volume of traffic on your network can have a negative impact on DHCP performance. For example, a
subnet that relies on a DHCP server at a remote location on the WAN might experience poor performance at
start of day, when users turn on computers and a large load of requests might be sent over the network.
DHCP traffic does not use significant network bandwidth during periods of normal usage; however, the
following two phases of DHCP client configuration generate some network traffic load:
• IP address lease
• IP address renewal
When a DHCP client initializes TCP/IP or renews its address lease, it acquires an IP address from the DHCP
server. This process results in an exchange between the DHCP client and the DHCP server, which typically
consists of four packets, each containing a maximum of 4 kilobytes (KBs). For more information about the
DHCP exchange, see the Networking Guide of the Windows Server 2003 Resource Kit (or see the Networking
Guide on the Web at http://www.microsoft.com/reskit).
You can reduce the amount of network traffic generated by DHCP IP address lease and IP address renewal by
extending the lease duration. Before you extend the lease duration, you must take into consideration other
factors in your network, such as ratio of clients to available IP addresses, or clients that frequently lease
addresses on more than one subnet, such as laptops that move frequently. If you have a relatively stable network
and many more available IP addresses than DHCP clients, increasing the lease duration reduces network traffic,
because DHCP messages are sent less frequently. If, however, you have a limited number of IP addresses
available to your DHCP clients, or a network that changes frequently, a longer lease duration might cause you to
run out of IP addresses because IP addresses are not returned to the address pool and made available to other
DHCP clients until the lease expires. For more information about extending the lease duration, see “Determining
Lease Duration” later in this chapter.
Improving DHCP Server Hardware

You can optimize DHCP performance in your system by optimizing individual DHCP server performance.
Windows Server 2003 includes performance monitoring tools that you can use to test and monitor your servers.
For more information about performance monitoring tools, see “Performance Monitoring Tools” in Help and
Support Center for Windows Server 2003.
The primary factors that impact DHCP server performance include:
• The speed of the server disk drives.
• The amount of RAM installed in the DHCP server computer.
The greatest volume of disk usage occurs when the service is started and when the database is backed up. When
planning your DHCP server hardware specifications, evaluate the average time required for disk access and for
disk read/write operations. If necessary, maximize DHCP server performance by increasing RAM and
purchasing high-speed disk drives for the servers.
Enabling DHCP Support for Multiple Subnets

If you have multiple subnets in your network, and do not have a DHCP server on every subnet, determine
whether your current routers relay DHCP/BOOTP messages.
If your routers cannot be used for DHCP/BOOTP relay, set up a DHCP/BOOTP relay agent on at least one
computer running Windows Server 2003 on each subnet. The DHCP/BOOTP relay agent relays DHCP and
BOOTP message traffic between the DHCP-enabled clients on the local network and a remote DHCP server
located on another physical network by using the IP address of the remote DHCP server.
Figure 2.3 shows a simple, routed network in which the router acts as a DHCP relay agent.
Figure 2.3 Subnets Configured to Use a DHCP Relay Agent
If your routers cannot be used for DHCP/BOOTP relay and you choose not to configure DHCP/BOOTP relay
agents, you must configure your network so that a DHCP server has a network adapter on each subnet it serves.
You can accomplish this by either placing a DHCP server on each subnet, or by multihoming DHCP servers.
This distributed configuration does not provide fault tolerance. If a DHCP server becomes unavailable, DHCP
clients on the subnet cannot receive IP addresses and options.
Note
The DHCP Relay Agent service is available only on computers running
Windows Server 2003, Microsoft® Windows® 2000, or
Windows NT 4.0. To use the DHCP Relay Agent routing protocol, the
Routing and Remote Access service must be installed and enabled.
For more information about installing and configuring DHCP relay agents, see “Configure the DHCP Relay
Agent” in Help and Support Center for Windows Server 2003. For more information about the DHCP Relay
Agent service, see the Networking Guide of the Windows Server 2003 Resource Kit (or see the Networking
Guide on the Web at http://www.microsoft.com/reskit) or see Help and Support Center for Windows
Server 2003.
Determining How Many DHCP Servers to

Deploy
A single DHCP server can serve an almost unlimited number of clients. However, factors such as the size and
layout of your network, the IP address class selected for use, and the volume of traffic on your network often
make this impractical. You can deploy multiple DHCP servers to reduce the volume of DHCP-related traffic
across your network and create faster response times for DHCP messages. Deploying multiple DHCP servers
also creates fault tolerance on your network. If you choose to deploy more than one DHCP server, it is important
to weigh the benefits of increased response times against the costs required for additional hardware.
When deciding how many DHCP servers you need, consider:
• The location of DHCP-enabled clients on your network.
• The transmission speeds between the segments for which DHCP service is provided.
If you have slower WAN or dial-up links, place a DHCP server on both sides of these links to
improve DHCP response times for local clients.
• The network traffic that DHCP produces, as well as your current network traffic.
If your current volume of network traffic is high, consider deploying multiple DHCP servers to
reduce the volume of DHCP requests traveling across the network. Make sure to account for
periods when network traffic is heaviest, such as the beginning of the day, when many users
turn on their computers at the same time.
• Disk space requirements.
It is important to consider the database size when choosing your hardware. Each lease requires
approximately 600 bytes per lease for the database, plus 1200 bytes for backup (600 bytes for
the backup and 600 bytes for the temporary directory). In addition, the audit logs require
approximately 500 bytes per lease transaction and are stored for seven days.
Tip
In general, allow at least 50-70 MB for the audit logs, however the
number of lease transactions depends on the number of leases as well
as the lease duration.
To figure out how much hard disk space is required, first multiply the number of leases by 600
bytes, then multiply the estimated number of lease transactions by 500 bytes, and add these two
results. The sum is the minimum amount of disk space required by the DHCP server.
For example, a DHCP server with 10,000 leases and lease duration of one week requires
approximately 18 MB to store the leases and the backup (6 MB for the database, 6 MB for the
backup, and 6 MB for the temporary database). The audit logs would require an absolute
minimum of 10 MB: 5 MB (500 bytes x 10,000 leases) for startup, and 5 MB when the leases
renew halfway through the week. If the number of leases increases or if lease time is shortened,
this requirement will increase. A company might allocate 100 MB for audit logs to allow for
flexibility in adding leases or reducing lease duration, as well as dealing with any peak-load
events.
Optimizing DHCP Availability

A highly available solution must account for all possible points of failure, including server failures, WAN link
interruptions, and router failures. You can increase the fault tolerance and availability of your design by using
one or more of the following, depending on your needs and hardware cost considerations:
• Split-scope configurations
• Clustered DHCP servers
• Using standby servers
Using Split-Scope Configurations

You can increase fault tolerance by splitting DHCP scopes between multiple DHCP servers. With a split-scope
configuration, if one server becomes unavailable, the other server can take its place and continue to lease new IP
addresses or renew existing clients. Splitting DHCP scopes also helps to balance server loads.
When splitting the IP address pool of a scope between two servers, assign the same scope to both servers, and
exclude opposite portions of the address range. You also need to make identical reservations at both DHCP
servers, so that either server can assign the reserved IP address, ensuring that the intended device receives the
address that is reserved for its use.
Figure 2.4 shows a network that is using a split-scope configuration.
Figure 2.4 Split-Scope Configuration
In Figure 2.4, DHCP Server 1 has 80 percent of the addresses in the scope and DHCP Server 2 has 20 percent of
the addresses in the scope. Splitting a scope between servers in this way, which is commonly referred to as the
“80/20 rule,” often relies on the proximity of the DHCP servers to the clients it serves. For example, when a
DHCP client that is on the same subnet as DHCP Server 1 sends out a DHCP Discover packet, it takes longer
for DHCP messages from clients to reach the DHCP Server 2 than DHCP Server 1, because DHCP Server 2 is
on the other side of a router from the DHCP client. You can also configure a delay on the DHCP relay agent to
ensure the local DHCP server has adequate time to respond. Because DHCP clients always accept the lease from
the DHCP server that sends the first response, clients normally obtain leases from DHCP Server 1. If DHCP
Server 1 goes offline for any reason, clients accept leases from DHCP Server 2.
Using Clustered DHCP Servers

Windows Server 2003 DHCP can use Windows Clustering, which allows two or more servers to be managed as
a single system. You can increase DHCP (or multicast address dynamic client allocation protocol [MADCAP])
scalability, availability, and reliability by using the Cluster service to deploy a DHCP server cluster.
By using clustering support for DHCP, you can implement a local method of DHCP server failover. In this way,
you can achieve greater fault tolerance and minimize disruptions and work stoppages. Windows Clustering can
automatically detect the failure of an application or server and restart the application on or transfer the server
role to an alternate server. Users experience only a brief break in service.
Windows Clustering creates a virtual DHCP server so that if one of the clustered nodes fails, the namespace and
all of the services contained in that node are automatically transferred to a second node. No changes are visible
to the client, which sees the same IP address for the clustered DHCP servers.
Use Windows Clustering alone to create a fault-tolerant design that makes efficient use of available IP
addresses. To further enhance DHCP fault tolerance and availability, combine DHCP server clustering with a
remote failover configuration — such as a split-scope configuration across different segments of your network.
Although combining server clustering with a split-scope configuration increases DHCP availability, you must
consider whether the benefits to your organization outweigh the hardware costs involved.
Figure 2.5 shows an example of clustered DHCP servers. DHCP Server 1 is the active DHCP server, and DHCP
Server 2 is the backup DHCP server.
Figure 2.5 Clustered DHCP Servers
Example: Using a Split-Scope Configuration in Combination with a

DHCP Server Cluster to Enhance Availability and Fault Tolerance
A company has its main corporate office in North America, and two European offices in Milan and Seville. The
North American DHCP server cluster includes two servers, which are configured as nodes of the server cluster.
Twenty percent of the available IP leases for the Milan and Seville sites are configured on the North American
server cluster. The remaining 80 percent of the available IP leases are configured on the local Milan and Seville
DHCP servers.
This configuration provides the following levels of fault tolerance for the European sites:
1. Under normal circumstances clients in Milan and Seville request IP lease assignments from the
local DHCP server, which contains 80 percent of the available IP addresses for the subnet.
2. If either the Milan or Seville DHCP server is slow or unavailable, European DHCP clients use
the North American DHCP server, which contains 20 percent of the available IP addresses for
the Milan and Seville subnets. The relay agent between the European offices and the North
American office is configured to delay the DHCP messages from the European offices,
allowing the local (Milan or Seville) DHCP server enough time to respond.
3. Because the North American DHCP server is configured as a server cluster, if one node of the
cluster becomes unavailable, Windows Clustering automatically brings the other node online.
Using Standby Servers

A standby server and its scopes are not activated for use under normal conditions, and are activated by the
administrator only when needed, such as when a DHCP server fails or is taken offline for an extended period of
time. Standby servers require manual administration to ensure failover transition, and therefore might not be as
effective as other failover methods, such as split scopes and clustered servers.
To use a standby configuration, configure an additional DHCP server to server as a backup if the primary server
goes offline. You can either configure the standby server to be identical to your primary DHCP server or
configure the standby server with unused scopes to temporarily replace the primary DHCP server.
If you are configuring the standby server with the identical scope to your primary DHCP server, you must
implement server-side address conflict detection to prevent the assigning of duplicate addresses.
Important
Because server-side conflict detection uses Address Resolution
Protocol (ARP) and Internet Control Message Protocol (ICMP)
messages to detect conflicts, Internet Connection Firewall (ICF) or
other firewalls that are installed on clients on your network might
interfere with conflict detection.
For more information about backing up your DHCP servers, see “Backing Up the DHCP Database” or “Netsh
Commands for DHCP” in Help and Support Center for Windows Server 2003.
Integrating DHCP with Other

Services
If you use DHCP servers for Microsoft network clients, you must use a name resolution service. Networks that
support clients running Windows 2000, Microsoft® Windows® XP Professional, and Windows Server 2003 use
the DNS service to support name resolution. Networks that support clients running versions of the operating
system earlier than Windows 2000 must use a form of NetBIOS name resolution, such as WINS. Networks that
support both types of clients must implement both WINS and DNS servers.
Windows Server 2003 DHCP provides support for both DNS dynamic updates and secure DNS dynamic
updates. DHCP and DNS work together to perform dynamic updates and work with Active Directory to perform
secure DNS dynamic updates. DHCP also works with Active Directory to prevent unauthorized DHCP servers
from running on the network.
Figure 2.6 shows the process for integrating DHCP with other services.
Figure 2.6 Integrating DHCP with Other Services
Configuring Dynamic Update and Secure

Dynamic Update
The Windows Server 2003 DHCP Server service can be configured to perform DNS dynamic updates and
secure DNS dynamic updates for DHCP clients, which eliminates the need for administrators to update DNS
records manually when a client’s IP address changes. Clients running Windows 2000, Windows XP, or Windows
Server 2003 can also perform dynamic updates.
Clients running versions of Windows earlier than Windows 2000 do not support DNS dynamic update. To
enable the DHCP server to perform DNS dynamic updates on behalf of these clients, use the default client
preference settings. Clients using WINS for name resolution cannot make an explicit request for DNS dynamic
update protocol preference. For these clients, the DHCP service can be configured to update both the PTR and
the A resource records.
By itself, dynamic update is not secure; any client can modify DNS records. When secure dynamic update is
configured, the authoritative name server accepts updates only from clients and servers that are authorized to
make dynamic updates to the appropriate objects in Active Directory. Secure dynamic update is available only
on Active Directory–integrated zones. To configure secure dynamic updates, you can use the Windows
Server 2003 secure dynamic update feature.
Secure dynamic update protects zones and resource records from being modified by unauthorized users by
enabling you to specify the users and groups that can modify zones and resource records. By default, Windows
Server 2003, Windows XP Professional, and Windows 2000 clients attempt unsecured dynamic updates first. If
that request fails, they attempt secure updates.
When using multiple DHCP servers and secure dynamic updates, add each of the DHCP servers as members of
the DnsUpdateProxy global security group so that any DHCP server can perform a secure dynamic update for
any record. Otherwise, when a DHCP server performs a secure dynamic update for a record, that DHCP server
is the only computer that can update the record.
To configure dynamic update for DHCP clients and servers
1. In the DHCP snap-in, select and right-click the DHCP server you want to configure, and then
click Properties.
2. In the server name Properties dialog box, click the DNS tab.
3. On the DNS tab, select the Enable DNS dynamic updates according to the settings below
check box.
4. On the DNS tab, select the dynamic update method you want: either always updating DNS A
and PTR, or only updating the records when requested by the DHCP client.
Use the DNS snap-in to enable secure dynamic update. For more information about dynamic update and secure
dynamic update, see “Deploying DNS” in this book and in Help and Support Center for Windows Server 2003.
Important
If DHCP will perform DNS dynamic updates, do not install it on a
domain controller. Instead, install DHCP on a member server. When
DHCP is installed on a domain controller and is configured to perform
dynamic updates on behalf of clients in DNS zones that are configured
to allow only secure dynamic update, specify a user account to update
the DNS records. For more information about installing DHCP, see
“Checklist: Installing a DHCP server” in Help and Support Center for
Windows Server 2003.
Authorizing DHCP Servers in Active

Directory
An unauthorized DHCP server on a network can cause a variety of problems, such as the leasing of incorrect IP
addresses and options. To protect against this type of problem, when a Windows 2000 or Windows Server 2003
domain member DHCP server attempts to start on the network, it first queries Active Directory. The DHCP
server compares its IP address and server name to the list of authorized DHCP servers. If either the server name
or IP address is found on the list of authorized DHCP servers, the server is authorized as a DHCP server. If no
match is found, the server is not authorized in Active Directory and does not respond to DHCP traffic. The
process of authorizing DHCP servers is useful for only Windows 2000–based or Windows Server 2003–based
DHCP servers. This process cannot be used for DHCP servers running Windows NT Server, or servers running
non-Windows-based DHCP services. Only a member of the Enterprise Admins group can authorize or
unauthorize a DHCP server in Active Directory.
Important
You must be logged in as an enterprise administrator to authorize a
DHCP server.
To authorize a DHCP server in Active Directory

1. In the DHCP snap-in, right-click DHCP.
2. Select Manage authorized servers.
3. In the Manage Authorized Servers dialog box, click Authorize.
4. In the Authorize DHCP Server dialog box, type the name or IP address of the DHCP server,
and then click OK.
Note
Detection of unauthorized DHCP servers requires the deployment of
Active Directory and the DHCP service running on Windows 2000 or
Windows Server 2003. Other DHCP servers do not attempt to
determine whether they are authorized by Active Directory before
offering IP address leases.
Defining Scopes
Before DHCP clients can use a DHCP server for dynamic TCP/IP configuration, you must define and activate
scopes for your DHCP clients. A scope is the full, consecutive range of possible IP addresses for a subnet. The
IP addresses in a scope define a single subnet on which DHCP services are offered. DHCP servers use scopes to
manage network IP address distribution and the configuration of DHCP options.
Figure 2.7 shows the process for defining scopes.

Figure 2.7 Defining Scopes
Creating Scopes
You must create a DHCP scope for each subnet in your network. Each subnet has a DHCP scope, with a single
continuous range of IP addresses.
Before you create scopes, you must install DHCP on your server. For more information about installing DHCP,
see “Checklist: Installing a DHCP server” in Help and Support Center for Windows Server 2003.
You can use the DHCP MMC snap-in to create a new scope on your DHCP server.
To create a DHCP scope
1. In the DHCP snap-in, select the name of the DHCP server.
2. Select Action, and then select New Scope. This opens the New Scope Wizard. Complete the
New Scope Wizard by configuring the following properties:
• A scope name and description of the scope.
• A consecutive range of possible IP addresses.
• A unique subnet mask. For more information about defining subnet masks, see “Designing
a TCP/IP Network” in this book.
• The IP addresses that are to be excluded from the scope.
• Lease duration values.
• Options.
For a worksheet to assist you in completing the New Scope Wizard, see the “Scope Data Collection Worksheet”
(DNSDHC_1.doc) on the Windows Server 2003 Deployment Kit companion CD (or see the “Scope Data
Collection Worksheet” on the Web at http://www.microsoft.com/reskit).
After you create the scope, you can set reservations and configure any additional DHCP options. For
information about setting reservations, see “Creating Reservations” later in this chapter. For information about
configuring additional DHCP options, see “Configuring DHCP Options” later in this chapter.
Setting Exclusion Ranges

To prevent address conflicts, the scopes that you define must exclude the IP addresses of devices that you
statically configure, such as DHCP servers. By setting exclusion ranges, an administrator can exclude IP address
ranges within a scope so that those addresses are not offered to DHCP clients. When you create a new scope,
immediately exclude addresses of the existing statically configured computers. Excluded IP addresses can be
active on your network, but only when these addresses are manually configured or distributed as reserved IP
addresses. For more information about reservations, see “Creating Reservations” later in this chapter.
You can set exclusion ranges in the Add Exclusions page of the New Scope Wizard. For more information
about using the New Scope Wizard, see “Creating Scopes” earlier in this chapter.
To set an exclusion range after a scope is created
1. In the DHCP snap-in, expand the scope you want to configure.
2. Select and right-click Address Pool under the appropriate scope.
3. Select New Exclusion Range.
4. In the Add Exclusion dialog box, type the starting and ending IP addresses of the exclusion
range, and then click Add.
Determining Lease Duration

When a scope is created, the default lease duration is set to eight days. However, because lease renewal is an
ongoing process that can affect the performance of DHCP clients and your network, you can increase or
decrease the lease duration to fit your specific needs. Determine what segments of your network have specific
lease duration requirements, and decide how best to modify lease duration settings to improve DHCP
performance on your network.
You can set the lease duration in the Lease Duration page of the New Scope Wizard. For more information
about using the New Scope Wizard, see “Creating Scopes” earlier in this chapter.
To set the lease duration after a scope is created
1. In the DHCP snap-in, select and right-click the scope you want to configure.
2. Select Properties.
3. In the Lease duration for DHCP clients box, adjust the lease time for the scope.
Increasing the Default Lease Duration

You can increase the lease duration in a scope to reduce network traffic. Increase the lease duration only if that
segment of your network has a large number of IP addresses available and a configuration that rarely changes.
Increasing lease duration reduces the rate at which IP addresses are reclaimed when changes occur.
In a more stable environment, you can use a long lease, such as several months. This ensures both that addresses
are ultimately recovered, and that DHCP-related network traffic is kept to a minimum.
Caution
Use caution when configuring unlimited lease durations. Even stable
environments have a certain amount of client turnover. At a minimum,
roving computers might be added and removed, desktop computers
might be moved from one office to another, and network adapters
might be replaced. If a client with an infinite lease is removed from the
network, the DHCP server is not notified, and the IP address cannot be
reused.
Reducing the Default Lease Duration

Reduce the lease duration for segments of your network that have any of the following:
• A limited number of IP addresses available.
• Client configurations that change frequently.
• Clients that relocate often; for example, because they connect to conference rooms or wireless
networks.
Although reducing the lease duration creates more DHCP-related network traffic, it increases the rate at which
addresses are returned to the available address pool for reassignment. With an average volume of DHCP request
traffic, Windows Server 2003 DHCP has a four-hour default grace period after which an expired lease can be
reused. This means that an address is marked for deletion four hours after the lease expires, regardless of lease
duration. When the volume of DHCP-related traffic is heavy and no leases are available to service lease
requests, DHCP immediately instantiates a cleanup cycle, which reclaims any leases marked for deletion. By
default, the cleanup cycle occurs every 60 minutes. You can adjust the duration of the default grace period after
which an expired lease is marked for deletion by editing the following key in the registry:
HKLM\System\CurrentControlSet\Services\DHCPServer\Parameters\LeaseExtension
Caution
Do not edit the registry unless you have no alternative. The registry
editor bypasses standard safeguards, allowing settings that can
damage your system, or even require you to reinstall Windows. If you
must edit the registry, back it up first and see the Registry Reference
on the Windows Server 2003 Deployment Kit companion CD or at
http://www.microsoft.com/reskit.
Configuring DHCP Options

DHCP uses options to pass additional IP settings to DHCP clients on a network. Examples of DHCP
options include:
• The default gateway IP address
• The DNS server IP address
• The DNS domain name
You can configure DHCP options for specific values and enable them for assignment and
distribution to DHCP clients based on server, scope, class, or reserved client levels. For example,
you can enable the vendor class option Release on Shutdown for any laptops on your network to
allow IP addresses assigned to mobile clients to be reincorporated into the address pool more
quickly.
You can configure options for an entire server, a scope, or for a single reserved client. The most
specific options (reserved client) take precedence over the least specific options (server). Values
configured manually on a client override any DHCP options of any type and of any level.
Using the New Scope Wizard, you can configure some scope-level options, including router
(default gateway), domain name, DNS servers, and WINS servers. You can also configure options at
the server, scope, and reserved-client levels in the DHCP snap-in.
To configure server-level options
1. In the DHCP snap-in, expand the server for which you want to configure options.
2. Right-click Server Options, and then click Configure Options.
3. In the Server Options dialog box, select the options you want to configure.
4. In the Data Entry section of the Server Options dialog box, type the option parameters, and
then click OK.
To configure scope-level options
1. In the DHCP snap-in, expand the scope for which you want to configure options.
2. Right-click Scope Options, and then click Configure Options.
3. In the Scope Options dialog box, select the options you want to configure.
4. In the Data Entry section of the Scope Options dialog box, type the option parameters, and
then click OK.
To configure options for a reserved client
1. In the DHCP snap-in, expand the scope that holds the reservation for which you want to
configure options, and then expand Reservations.
2. Right-click the reservation for which you want to configure options, and then click Configure
Options.
3. In the Reservation Options dialog box, select the options you want to configure.
4. In the Data Entry section of the Reservation Options dialog box, type the option parameters,
and then click OK.
For more information about configuring reservations, see “Creating Reservations” later in this
chapter.
Many option types are predefined in Windows Server 2003 DHCP. Other standard DHCP option
types can be added as needed to support DHCP client software that recognizes or requires them.
Windows Server 2003 DHCP supports all DHCP options, including those defined in RFC 2132,
although most DHCP clients use or support only a small subset of the available option types.
In general, use the following guidelines when configuring DHCP options for clients on your network:
• Add or define new, custom option types only if you have new software or applications that
require a nonstandard DHCP option.
• If your network is large, be conservative and selective when assigning global options. These
options apply to all clients of a DHCP server, unless more specific options are specified.
• Use scope-level options for most options that clients are assigned. Setting options at the scope
level allows you to take scope-related differences into account, such as different client needs or
the use of a different DNS server from other scopes in the network.
• Use class-level options if you have a large network or diverse groups of clients that are able to
support membership in option classes.
• Use reserved client options only for clients that have special requirements, for example, if your
intranet has a DNS server that performs forwarding for resolving Internet DNS names not
authoritatively managed on your network. In this case, you need to add the IP address of an
external DNS server on your DNS server computer. You can configure your DNS server as a
reserved client in DHCP and set this address as another reserved client option.
Configuring Option Classes

Windows Server 2003 DHCP includes vendor-defined and user-defined option classes. Use DHCP option
classes to configure the parameters necessary for network clients to meet the special requirements of custom
applications. Equipment from multiple vendors on a network can also use different option numbers for different
functions. The option types used to support vendor-defined classes — the vendor class identifier and the vendor-
specific option — are defined in the Internet DHCP options standard reference, RFC 2132.
You can add and configure vendor-defined classes for submanaging DHCP options that are assigned to clients
identified by vendor type. You can also add and configure user-defined classes for submanaging DHCP options
that are assigned to clients identified by a common need for a similar DHCP option configuration.
After you configure specific user-defined and vendor-defined options classes, you must configure scopes to
assign the option classes to clients.
Vendor-Defined Classes
DHCP clients can use vendor-defined classes to identify the client’s vendor type and configuration to the DHCP
server when obtaining a lease. For a client to identify its vendor class during the lease process, the client needs
to include the vendor class ID option (option code 60) when it requests or selects a lease from a DHCP server.
When vendor options are specified, the server performs the following additional steps to provide a lease to the
client:
1. The server checks to see that the vendor class identified by the client request is a recognized
class defined on the server.
2. If the vendor class is recognized, the server checks to see whether any additional DHCP options
are configured for this class in the active scope.
3. If the vendor class is not recognized, the server ignores the vendor class identified in the client
request, and returns options allocated to the default vendor class (includes all DHCP Standard
Options).
4. If the scope contains options configured specifically for use with clients in this vendor-defined
class, the server returns those options and uses the vendor-specific option type (option code 43)
as part of its acknowledgment message.
In most cases, the default vendor class — DHCP Standard Options — provides a default grouping for any
Windows Server 2003 DHCP clients or other DHCP clients that do not specify a vendor class ID. In some cases,
you might define additional vendor classes for other DHCP clients, such as printers or some types of UNIX
clients. When you add other vendor classes for these purposes, be sure that the vendor class identifier that you
use to configure the class at the server matches the identifier used by clients for your third-party vendor.
User-Defined Classes
User-defined classes allow DHCP clients to specify what type of client they are, such as a remote access client
or a desktop computer. For Windows Server 2003 clients, you can define specific user class identifiers to relate
information about a client’s software configuration, its physical location in a building, or its user preferences. If
user-defined option classes are not specified, default settings are assigned.
Configuring DHCP Option Parameters

When a DHCP server actively provides option parameters, clients receive and use the associated
values in their local TCP/IP configurations for the period of leased configuration.
By default, Microsoft-based DHCP clients can recognize and use two categories of option
parameters: information options and protocol options.
Information Options
Use the MMC DHCP snap-in to explicitly configure information options and any associated values provided to
clients. These options are not required and can be assigned at your discretion. Use information options to assign
values, such as DNS servers, WINS servers, and domain name.
Windows Server 2003 Protocol Options

You implicitly configure values for protocol options based on properties configured at either the applicable
server or one of its scopes. These options are always included in DHCP client/server messages, as they are a
required part of protocol design. For example, Lease Duration/Time is a protocol option.
In most cases, the actual values included in these protocol options are provided to clients based on property
settings for the applicable DHCP server. Depending on the needs of your clients, you can also use the DHCP
snap-in to configure these options individually for defined scopes, identifying members of a specified user or
vendor class, or for a single reserved client.
Creating Reservations
For clients that require a constant IP address, you can either manually configure a static IP address, or assign a
reservation on the DHCP server. Reservations are permanent lease assignments that are used to ensure that a
specified client on a subnet can always use the same IP address. You can use DHCP reservations for hosts that
require a consistent IP address, but do not need to be statically configured. Reserved IP addresses differ from
statically configured IP addresses in one significant manner: when network parameters are changed at the DHCP
server, the device configured with a reserved IP address receives the new network parameters when the device
requests renewal of its lease. To change network parameters on a device configured with a static IP address, the
changes must be made manually to the device.
Determine the clients for which you need to manually configure an IP address — such as DHCP server, DNS
servers, WINS servers, routers, and domain controllers — and which clients can receive addresses from DHCP.
Keep in mind that for clients for which you manually configure static IP addresses, you must insert all
configuration parameters that the client requires in order to interact with the network. This includes IP
addresses, DNS and WINS parameters, and default gateway information. Clients that have reserved IP addresses
always have the same IP address, but still receive updated configuration information from the DHCP server.
You might want to assign network printers and certain servers DHCP reservations to ensure that they always
have the same IP address, but continue to receive updated configuration information from the DHCP server. For
example, create reservations for servers that must always have the same IP address, such as:
• Windows Internet Name Service (WINS) and Domain Name System (DNS) servers
• Print servers that use TCP/IP print services
• Firewalls
• Routers
DHCP-enabled clients receive any available options, such as DNS server or router (default gateway), from the
DHCP server when they renew their leases. If these devices are manually configured, an administrator must
reconfigure each device individually when a change occurs.
To create a reservation
1. In the DHCP snap-in, expand the scope for which you want to create a reservation.
2. Select and right-click Reservations, and then click New Reservation.
3. In the New Reservation dialog box, enter the Reservation name, IP address, MAC address,
and Description of the reservation.
4. Select the appropriate Supported types: DHCP only, BOOTP only, or Both.
5. Click Add.
Creating Superscopes
A superscope is an administrative grouping of scopes that can support multiple logical IP subnets on the same
physical subnet. Superscopes contain a list of member scopes that can be activated together. You cannot
configure scope-level properties on superscopes; you must configure these on the member scopes. A superscope
allows a DHCP server to provide leases from more than one scope to clients on a single physical network.
You can use superscopes to resolve DHCP service issues for the following situations:
• DHCP clients are located on a single physical network segment that includes multiple logical IP
subnets.
• Multiple DHCP servers manage separate logical subnets on the same physical subnet.
• The available address pool for an active scope is nearly depleted and more computers must be
added to the physical network segment.
• Clients are migrating to a new scope.
• You need to support DHCP clients on a network that has multiple logical subnets in one
physical subnet on the other side of a BOOTP/DHCP relay agent.
Before you create a superscope, you must use the DHCP MMC snap-in to define at least one scope to be
included in the superscope. Scopes added to a superscope are called member scopes. You can add additional
member scopes either from the superscope menu, or from the individual scope menus.
To create a new superscope
1. In the DHCP snap-in, create at least one scope to be included in the superscope. For
information about creating scopes, see “Creating Scopes” earlier in this chapter.
2. Select and right-click the DHCP server, and then select New Superscope. This opens the New
Superscope Wizard.
3. On the Superscope Name page of the New Superscope Wizard, type a name for the
superscope.
4. On the Select Scopes page of the New Superscope Wizard, in the Available Scopes list, select
one or more scopes to include in the superscope.
To add scopes to an existing superscope
1. In the DHCP snap-in, select and right-click the superscope, and then select New Scope. This
opens the New Scope Wizard.
2. Complete the New Scope Wizard. For information about creating scopes, see “Creating
Scopes” earlier in this chapter.
–or–
3. Create a new scope, right-click the new scope, and then select Add to Superscope.
4. In the Add Scope name to a Superscope dialog box, in the Available superscopes list, select
the superscope.
Note
Deleting the superscope does not delete the member scopes.
Configuring Multicast Scopes

Windows Server 2003 DHCP service offers MADCAP support in the form of multicast scopes. MADCAP
supports dynamic assignment and configuration of IP multicast addresses on TCP/IP-based networks. Multicast
scopes provide ranges of Class D IP addresses, which are reserved for multicast operation, by using directed
transmission from one point to multiple points. With the exception of DHCP-assignable options, which
multicast scopes do not support, you can configure a multicast scope in the same way that you configure a
regular DHCP scope.
Multicast IP addresses allow multiple clients to receive data that a server sends to a single IP address, enabling
point-to-multipoint communication. This type of transmission is often used for streaming media transmissions,
such as video conferencing.
Important
In all TCP/IP networks, each computer requires a unique primary
computer IP address from one of the standard address classes used
for building the network (Class A, B, or C range). You must assign this
required primary computer IP address before you can configure a
computer to support and use secondary IP addresses such as
multicast IP addresses.
Although the Windows Server 2003 DHCP service supports both DHCP and MADCAP, the services function
independently; clients that do not obtain IP addresses from the DHCP service can still obtain MADCAP
addresses from the DHCP service. DHCP scopes are used to allocate IP address ranges from Class A, B, or C
addressing schemes, which enable unicast for point-to-point communication between networked computers.
MADCAP scopes allocate Class D IP addresses to enable point-to-multipoint communication.
To configure a MADCAP scope
1. In the DHCP snap-in, select and right-click the DHCP server you want to configure. The New
Multicast Scope Wizard appears.
2. In the New Multicast Scope Wizard, type a name and description for this multicast scope.
3. Set the multicast IP address range and Time to Live (TTL).
4. Add any exclusion ranges and the lease duration, then activate the multicast scope.
Tip
Clients that use MADCAP must be configured to use the MADCAP API.
For more information about writing or programming applications that
use the MADCAP API, see the MSDN Online link on the Web
Resources page at
http://www.microsoft.com/windows/reskits/webresources.
Removing Scopes
Remove DHCP scopes when a subnet is no longer in use or when you need to renumber your network to use a
different IP address range.
Do not remove a scope while it has active leases. Before you remove a scope, deactivate the scope until all
client leases expire or all lease renewal requests are denied. When you have confirmed that the scope no longer
contains active leases, you can remove it by using the DHCP snap-in. For more information about deactivating
scopes, see Deactivate a scope in Help and Support Center for Windows Server 2003.
Implementing Your DHCP Solution

After you have planned your DHCP solution and made the necessary configurations, you must implement your
new or updated DHCP solution in your production environment. The DHCP implementation process involves
the following steps:
• Configuring your DHCP clients.
• Migrating existing DHCP servers, if necessary.
• Testing your DHCP solution.
Figure 2.8 shows the process for implementing your DHCP solution.
Figure 2.8 Implementing Your DHCP Solution
Installing DHCP on Your Server

Install DHCP on your server either by using Manage Your Server or by adding DHCP from Add/Remove
Windows Components. If you are migrating an existing DHCP server to a new Windows Server 2003–based
server, install DHCP on the Windows Server 2003–based server before continuing with your migration. For
more information about installing DHCP on your server, see “DHCP server role: Configuring a DHCP server,”
“Installing a DHCP Server,” and “Checklist: Installing a DHCP server” in Help and Support Center for
Migrating Existing DHCP Servers

If you already have a working DHCP infrastructure on your network, you can migrate your DHCP database and
server configuration from your existing servers to new Windows Server 2003–based servers. Migrating can save
you time because you do not need to reconfigure the scope, lease, and option information on the new server.
Before migrating the database, create a backup of your working configuration, and test the migration procedures
in a lab environment.
The following procedures migrate lease, scope, and option information, including reservations and exclusions. If
you have changed any registry settings from their defaults on the existing server, you must manually make these
changes on the new Windows Server 2003–based server for them to take effect.
Caution
The registry editor bypasses standard safeguards, allowing settings
that can damage your system, or even require you to reinstall
Windows. If you must edit the registry, back it up first and see the
Registry Reference on the Windows Server 2003 Deployment Kit
companion CD or at http://www.microsoft.com/reskit.
Exporting DHCP Settings

When migrating from an existing DHCP server running Windows NT 4.0 or Windows 2000 Server, the first step
is to export the current DHCP settings. Use the following procedure to export the DHCP database from an
existing Windows NT 4.0–based server or a Windows 2000–based server.
To export the DHCP server settings from a Windows NT 4.0–based server or
Windows 2000–based server
1. Run DHCPExim.exe. This opens the DhcpExim dialog box.
To download and install DHCPExim.exe, see the Resource Kit Tools link on the Web Resources
page at http://www.microsoft.com/windows/reskits/webresources.
2. In the DhcpExim dialog box, select Export configuration of the local service to a file.
3. In the DHCPEXIM Export To File dialog box, enter a file name and location to save the file,
and then click OK.
The target location the file is shown in the DhcpExim Export dialog box.
4. In the DhcpExim Export dialog box, select all of the scopes on the list to migrate all settings
on the server. Alternatively, you can only the specific scopes you want to export if you are not
migrating the entire server. Select the Disable the selected scopes on local machine before
export check box to disable the scopes on this server before exporting, and then click Export.
Tip
This step might take several minutes to complete, and there is no
dialog box to indicate the progress of the export. You can view the
process running on the Processes tab of the Windows Task
Manager.
5. Click OK when a message appears that says “The operation was completed successfully.”
6. Copy the exported file to a location where you can access it from the new Windows
Server 2003–based server.
Importing DHCP Settings

After exporting the DHCP settings and moving the exported file to a location where you can access it, you are
ready to use the Netsh command-line tool to import the DHCP settings to the new DHCP server running
Windows Server 2003. You might want to configure the new DHCP server to use the IP address that was
formerly used on the old DHCP server. Before you do this, make sure to disconnect the old server from the
network in order to avoid any IP address conflicts.
To import the DHCP server settings to Windows Server 2003–based DHCP server
1. Install DHCP on the Windows Server 2003–based server. DHCP must be installed before you
can import the file.
2. At the command prompt, type:
netsh DHCP server import <path of export file> all
This imports the configurations of all scopes that you exported from the server running
Windows NT 4.0 or Windows 2000.
For more information about the Netsh command-line tool, see “Netsh” in Help and Support Center for Windows
Server 2003.
Configuring DHCP Clients

When configuring your DHCP clients, it is important to consider the types of computers on each subnet of the
network. For example, you might configure one subnet with a shorter lease duration for portable computer
users. To configure a Windows client to obtain an IP address from the DHCP server, select Obtain an IP
address automatically from the Internet Protocol (TCP/IP) Properties window.
In addition to Windows-based clients, you can configure DHCP for UNIX, Linux, or Macintosh clients. Refer to
the documentation for these operating systems to configure the clients for DHCP.
Note
You can override DHCP information by configuring the individual client.
Any information entered manually into a client’s TCP/IP configuration
overrides dynamic settings.
Providing Support for Remote Access Clients

The remote access server can be configured to use DHCP to lease IP addresses in blocks of 10 from the DHCP
server and store them in the registry. The remote access server leases additional addresses in blocks of 10 as
needed.
When passing the leases on to remote access clients, the remote access server discards the options configured
for the scope. However, remote access clients receive WINS or DNS entries from the remote access server. This
information is not taken from the DHCP options of the lease that the remote access client is using; it is taken
directly from the settings of the remote access server.
You can use a DHCP relay agent to provide DHCP scope options to remote access clients. In this situation, the
remote access client continues to receive an IP address from the remote access server, but uses DHCPInform
packets to obtain WINS addresses, DNS addresses, domain names, or other DHCP options.
Note
DNS and WINS addresses obtained from DHCPInform packets
override DNS and WINS addresses obtained from the remote access
server.
For more information about using DHCP for remote access clients, see “Using Routing and Remote Access
servers with DHCP” in Help and Support Center for Windows Server 2003 and article Q216805, “RAS Server
Behavior When Configured to Use DHCP to Assign IP Addresses,” in the Microsoft Knowledge Base. For more
information about configuring a DHCP relay agent to provide DHCP options to remote access clients, see article
Q232703, “How to Use DHCP to Provide RAS Clients with DHCP Options,” in the Microsoft Knowledge Base.
To find these articles, see the Microsoft Knowledge Base link on the Web Resources page at
www.microsoft.com/windows/reskits/webresources.
Configuring Support for BOOTP Clients

Windows Server 2003 provides support for dynamic BOOTP, which allows you to provide BOOTP support
without making a reservation for each BOOTP client.
You can use DHCP to configure and support BOOTP clients. BOOTP clients can be configured to receive boot
file information, or IP address information. You can also use DHCP to configure options for your BOOTP
clients.
Configuring DHCP to Provide Boot File Information

To configure the DHCP service to provide boot file information to BOOTP clients, create BOOTP entries for
each client-specific platform in the BOOTP table on the DHCP server.
Information stored in the BOOTP table is returned to any BOOTP clients on the network that broadcast a
BOOTP request message. If the BOOTP table includes at least one BOOTP entry, the DHCP service replies to
BOOTP client requests. If no BOOTP entries are configured, the BOOTP client gets a lease, but no options or
other information are passed to the BOOTP client.
The reply message returned by the DHCP service indicates the name of a Trivial File Transfer Protocol (TFTP)
server on the network and the location of the boot file. The client then contacts the TFTP server to retrieve the
boot image file.
BOOTP clients download the image file from a TFTP server. Because Windows Server 2003 does not provide a
full TFTP file service, you might need to use a third-party TFTP server to support BOOTP clients that must start
from an image file (usually diskless workstations).
Configuring DHCP to Provide IP Address Information

Windows Server 2003 allows you to designate a pool of addresses from which IP addresses for BOOTP clients
are dynamically assigned, similar to the way that a scope is used for DHCP clients. After verifying that a
specified lease time has elapsed and that the BOOTP client IP address is not still in use, the DHCP service can
reclaim addresses used in the dynamic BOOTP address pool.
To include BOOTP client support in your DHCP scope design, designate the DHCP scope as a BOOTP address
pool or as both a DHCP and BOOTP address pool on the Advanced tab of the Scope Properties window in the
DHCP snap-in. For more information about configuring a BOOTP address pool, see “Add Dynamic BOOTP
Client Support to a Scope” in Help and Support Center for Windows Server 2003.
Configuring Options for BOOTP Clients

To retrieve all options, the client must specify option 55 (the Options Request List parameter) in the BOOTP
request. Windows Server 2003 DHCP servers return as many options to BOOTP clients as can fit in a single
datagram response. Because BOOTP only allocates 300 bytes for options, any options that exceed the 300 bytes
are not sent. Therefore, when configuring options on a server that will service BOOTP clients, be aware of the
size limitations for BOOTP response packets.
For more information about BOOTP options, see the Networking Guide of the Windows Server 2003 Resource
Kit (or see the Networking Guide on the Web at http://www.microsoft.com/reskit).
Important
DHCP options can apply to both DHCP and BOOTP clients. Therefore,
you must configure your scopes to ensure that DHCP options are
applied correctly.
Testing Your DHCP Solution

The ideal environment for validating a deployment plan is a test laboratory that is constructed to simulate your
production environment. If you do not have a DHCP infrastructure in place, create a new DHCP infrastructure
in the pilot lab. If you already have a DHCP infrastructure in place, recreate your existing infrastructure in the
pilot lab and then test your migration and your updated solution.
Use the following guidelines when testing your DHCP solution in the pilot lab:
• Ensure that your test servers come from the same vendor and are configured in the same way as
the servers that exist in your production environment. Represent all client computers that use
DHCP in your organization in your pilot lab.
• Duplicate the network configuration of your organization in the pilot lab. If the network uses
both Ethernet and Token Ring, you need to include both configurations in the test lab. If
possible, set up a separate Windows Server 2003 domain for the lab so that you can monitor the
performance of the domain controllers without interference from other network activity. If you
are planning to deploy DHCP on a WAN, include routers in your lab design and use a link
simulator to simulate network latency.
• Deploy a typical set of applications that run together in your production environment on the test
server. This allows you to identify any interoperability issues that might arise when users run
different applications simultaneously.
• Test your DHCP solution in burst traffic conditions. Make sure that all services on your servers
continue to be available during burst traffic conditions, such as following a large-scale power
outage, when many clients might restart simultaneously.
For more information about testing your design, see “Designing a Test Environment” in Planning, Testing, and
Piloting Deployment Projects of this kit.
Testing your DHCP solution in a pilot lab allows you to identify problems with your infrastructure, system
configuration, or software. After you have tested your configuration thoroughly in a pilot lab, you can roll out
your DHCP solution in your production environment.
Example DHCP Implementation

This DHCP example implementation depicts how a fictional company uses the Windows Server 2003–based
DHCP servers to streamline and automate administration and assignment of IP addresses and other client
configuration information. Though your network configuration might differ from this example, you can apply
the basic concepts.
The company has two offices, a main administrative office, and branch offices 25 miles away. The company
employs 600 people, many of whom travel frequently between the two offices with portable computers.
The main office is housed on two floors, with 75 desktop computer users per floor. Because many of these
employees also have portable computers, conference rooms are configured with wireless networking. Wireless
networking also provides ease of network connectivity to employees from the branch offices who are attending
meetings at the main office.
Connectivity and Routing

A digital subscriber line (DSL) account at a rate of 1.1 megabits per second (Mbps) is established for each of the
two company sites, providing a dedicated connection to the Internet through a DSL modem. Additional network
adapters are installed on the server computers at both sites, one network adapter per subnet.
The DSL-connected server in the main office has two additional network adapters, one for Subnet A and one for
Subnet B. On Subnet A, network cable runs from the network adapter to a hub. On wireless Subnet B, media
network cable runs from the network adapter to a hub, then to wireless access points stationed in conference
rooms.
The DSL-connected server computer in the branch office has four additional network adapters, one each for
subnets C through F. On wireless subnet C, network cable runs from the network adapter to a hub, then to
wireless access points stationed in conference rooms. On subnets D, E, and F, network cable runs from the
network adapters to hubs that extend to each individual subnet.
To provide secure, private, encrypted communication between the two sites over DSL, both DSL-connected
servers are also configured as virtual private network (VPN) servers.
To allow messages from both DHCP servers and DHCP clients to cross from site to site and between subnets at
each site, the Routing and Remote Access service on the DSL-connected servers have the DHCP relay agent
routing protocol installed and configured.
For more information about connecting remote sites, see “Connecting Remote Sites” in this book.
Transmission Security Between Sites

Because the company wants the highest level of security available for the VPN connection that allows the two
sites to communicate using their 1.1 Mbps DSL connections over the Internet, they install a Windows
Server 2003 certification authority (CA) and establish a Layer Two Tunneling Protocol (L2TP) connection,
relying on Internet Protocol security (IPSec) for encryption services. The combination of L2TP and IPSec is
known as L2TP/IPSec. With certificate-based authentication and an L2TP/IPSec connection, the company is
using the strongest form of authentication in Windows Server 2003. For more information about using a
certification authority, see “Designing an Authentication Strategy” in the Designing and Deploying Directory
and Security Services book of this kit. For more information about using IPSec, see “Deploying IPSec” in this
book.
Active Directory Domain Structure

The company uses Active Directory to list IP addresses of DHCP servers authorized for operation on the
network. If an unauthorized DHCP server running Windows 2000 or Windows Server 2003 is started on the
network, it determines its authorization status from the directory service. If the server determines that it is not
authorized, it stops functioning in the domain as a DHCP server, and cannot be used to provide IP address leases
to clients. There are two sites to define in Active Directory, one at the main administrative site and one at the
branch office site. Creating two sites optimizes the exchange of directory information and facilitates
administration by centralizing resources such as configuration information.
Subnets and IP Addressing

Although the company employs approximately 600 people, most employees use both a desktop computer and a
portable computer. Because the portable computers function primarily via wireless connections to the network,
one subnet at each of the two company sites is configured as a wireless subnet.
In all, there are six subnets on the company network, with 600 desktop clients and approximately 425 portable
clients divided among the subnets as shown in Table 2.1. All subnets on the network are configured with the
subnet mask 255.255.255.0. All six subnets are serviced by DHCP, with one DHCP server located at each site.
The main office houses 150 employees dispersed over two floors of the building. All users also have portable
computers that they frequently take to meetings in conference rooms. All of conference rooms are configured
for wireless networking.
The company has divided the main office into two Class C subnets:
• Subnet A — Floors 1 and 2
• Subnet B — Wireless subnet with wireless access points installed in conference rooms
The branch office houses 450 employees, dispersed throughout a three-story building. Over 200 users also have
portable computers that they frequently take to meetings in conference rooms, all of which are configured for
wireless networking.
The company has divided the branch office into four Class C subnets:
• Subnet C — Wireless subnet for conference rooms
• Subnet D — Floor 3
• Subnet E — Floor 2
• Subnet F — Floor 1
Table 2.1 Address Range and Clients per Subnet
Address Range Approximate Number of
Subnet
Clients
A 192.168.0.1/24 to 192.168.0.254/24 150
B 192.168.1.1/24 to 192.168.1.254/24 Up to 225
C 192.168.2.1/24 to 192.168.2.254/24 Up to 225
D 192.168.3.1/24 to 192.168.3.254/24 150
E 192.168.4.1/24 to 192.168.4.254/24 150
F 192.168.5.1/24 to 192.168.5.254/24 150
Before creating and activating scopes on the DHCP server, the company plans IP address ranges, exclusion
ranges, and reservations (where applicable) for each subnet. The company uses Class C IP address ranges on
every subnet, as each Class C address range provides 254 IP addresses when the subnet mask is defined as
255.255.255.0.
Because the client count per non-wireless subnet is 150 or fewer clients, 254 IP addresses per subnet allow the
company to provide static address assignments for any servers that require them, and dynamic assignments to all
clients on the network — with plenty of IP addresses remaining to provide for future network expansion.
The wireless subnets are configured with a lease duration of 15 minutes. Because of the short lease time, 254 IP
addresses per subnet is a sufficient amount for the wireless subnets, even though these subnets experience
substantial traffic, with portable computers joining and leaving the subnet at high volume during a typical day.
These short leases expire soon after the portable computer is disconnected from the network, and the IP address
used by that computer becomes available for lease to other DHCP clients as they connect to the wireless subnet.
Exclusion Ranges
Some network devices need to use statically assigned IP addresses rather than addresses dynamically assigned
through DHCP. For example, DHCP servers must have statically configured IP addresses. Also, some devices
(such as legacy network printers) do not support DHCP.
For the devices that need static IP assignments, the company creates an exclusion range from each IP address
range. Creating one or more exclusion ranges prevents the DHCP server from assigning a client lease with any
address in the exclusion range, thereby protecting it for use as a static IP address and preventing address
conflicts between statically configured devices and dynamically configured devices.
Although any addresses in the address range can be excluded, the company chooses to exclude the first 20
addresses from each address range for non-wireless subnets, and the first five IP addresses from each address
range for wireless subnets. The company uses additional exclusion ranges to configure load balancing and fault
tolerance using the 80/20 rule. For more information about DHCP scopes, see “Scope Configuration” later in
this chapter.
Address Pools
After the address range and exclusion ranges are defined, the remaining addresses form the available address
pool within the scope. These addresses are eligible for dynamic assignment by the server to DHCP clients on the
network. Table 2.2 shows the address pool for each subnet prior to adding the exclusion ranges used to apply the
80/20 rule.
Table 2.2 DHCP Address Pools per Subnet
Subnet Address Pool
A 192.168.0.21/24 to 192.168.0.254/24
B (wireless) 192.168.1.6/24 to 192.168.1.254/24
C (wireless) 192.168.2.6/24 to 192.168.2.254/24
D 192.168.3.21/24 to 192.168.3.254/24
E 192.168.4.21/24 to 192.168.4.254/24
F 192.168.5.21/24 to 192.168.5.254/24
For more information about DHCP scopes and the 80/20 rule, see “Scope Configuration” later in this chapter.
Reservations
The company uses IP address reservations for file and print servers on their network. Reservations are used to
create a permanent IP address lease assignment by the DHCP server. Reservations ensure that a specified
hardware device on the subnet can always use the same IP address.
When using the 80/20 rule and splitting a scope’s IP address pool between two servers for load balancing and
fault tolerance, identical reservations must be made at both DHCP servers. When reservations are made at both
servers, neither server assigns the reserved IP address to another client, assuring that the intended device
receives the address reserved for its use.
Table 2.3 shows two example address reservations. For more information about the 80/20 rule and for an
example of how these reservations are created in specific scopes at each DHCP server, see “Scope
Configuration” later in this chapter.
Table 2.3 Example Address Reservations
Device Subnet Reserved IP Address
Application server A 192.168.0.21/24
File server D 192.168.3.68/24
Note
Reservations can be created using any IP address in the scope’s
address range, even if the IP address is also within an exclusion range.
Because of this design, when the 80/20 rule is implemented and some
addresses in the scope are excluded (80 percent at one server, 20
percent at the other), reservations still function properly.
Message Routing
The company uses DHCP relay agents to relay DHCP messages between subnets and sites. To support and use
DHCP across multiple subnets, routers connecting each subnet should comply with DHCP/BOOTP relay agent
capabilities described in RFC 1542. To cut the cost of expensive network hardware such as routers, the company
uses the Windows Server 2003 Routing and Remote Access service including, DHCP relay agents, to forward
DHCP/BOOTP messages between subnets. Because the VPN servers act as routers for network traffic, the
DHCP relay agents are configured on the VPN servers.
For more information about installing and configuring DHCP relay agents, see “Configure the DHCP Relay
Agent” in Help and Support Center for Windows Server 2003.
Installing DHCP and Authorizing Servers in Active Directory

The company completes the following steps at both sites:
1. Configures the servers.

2. Installs the DHCP Server service.
3. Opens the DHCP snap-in from the MMC.
4. Authorizes the DHCP server in Active Directory.
5. Adds DHCP administrators to the DHCP Administrators group or the DHCP Users group,
depending on their user rights.
6. Creates, configures, and activates one scope for each subnet.
After creating scopes at the DHCP servers, the company defines a site in Active Directory for the branch office.
Each of the six subnets is then associated with the appropriate site. When configuring your network, however,
you can configure all sites in Active Directory before creating DHCP scopes.
Scope Configuration
By using the 80/20 split-scope configuration for fault tolerance and availability, scopes for all six subnets on the
company network are defined on both DHCP servers. Exclusion ranges are used to allocate available addresses
per scope, per server, as follows:
• The main office DHCP server is configured with 80 percent of the IP addresses available for
lease to clients in each scope serving subnets A and B and 20 percent of the IP addresses
available for lease to clients located at the branch office (subnets C through F).
• The branch office DHCP server has 80 percent of all addresses in all scopes available for lease
to clients in the branch office (subnets C through F) and 20 percent of all addresses in all scopes
available for lease to clients located in the main office (subnets A and B).
Thus, if either server suffers a hard-disk failure or other failure, the alternate server is available to assign and
renew leases on all subnets.
To achieve the 80/20 rule, each Class C IP address range of 254 IP addresses available in each non-wireless
scope is divided in the following manner:
• 20 IP addresses for static assignments.
• 187 IP addresses, or 80 percent of the addresses for lease, in the address pool of the DHCP
server at the same site.
• 47 IP addresses, or 20 percent of the addresses for lease, in the address pool of the DHCP server
at the other site.
The wireless scopes are divided in the following manner:

• 5 IP addresses for static assignments.
• 203 IP addresses, or 80 percent of the addresses for lease, in the address pool of the DHCP
server at the same site.
• 51 IP addresses, or 20 percent of the addresses for lease, in the address pool of the DHCP server
at the other site.
Table 2.4 shows the address pools and exclusion ranges configured on the main office DHCP server.
Table 2.4 Scope Configurations on the DHCP Server at the Main Office
Scope Name Address Range Exclusion Ranges Address Pool
A 192.168.0.1 to 192.168.0.1 to 192.168.0.20, 192.168.0.68 to
192.168.0.254 192.168.0.21 to 192.168.0.67 192.168.0.254
B (wireless) 192.168.1.1 to 192.168.1.1 to 192.168.1.5, 192.168.1.6 to
192.168.1.254 192.168.1.204 to 192.168.1.203
192.168.1.254
C (wireless) 192.168.2.1 to 192.168.2.1 to 192.168.2.203 192.168.2.204
192.168.2.254 to
192.168.2.254
192.168.3.1 to 192.168.3.1 to 192.168.3.20, 192.168.3.21 to
D
192.168.3.254 192.168.3.68 to 192.168.3.254 192.168.3.67
E 192.168.4.1 to 192.168.4.1 to 192.168.4.20, 192.168.4.21 to
192.168.4.254 192.168.4.68 to 192.168.4.254 192.168.4.67
F 192.168.5.1 to 192.168.5.1 to 192.168.5.20, 192.168.5.21 to
192.168.5.254 192.168.5.68 to 192.168.5.254 192.168.5.67
Table 2.5 shows the address pools and exclusion ranges configured on the branch office DHCP server.
Table 2.5 Scope Configurations on the DHCP Server at the Branch Office
A 192.168.0.1 to 192.168.0.1 to 192.168.0.20, 192.168.0.21 to
192.168.0.254 192.168.0.68 to 192.168.0.254 192.168.0.67
B (wireless) 192.168.1.1 to 192.168.1.1 to 192.168.1.203 192.168.1.204
192.168.1.254 to
192.168.1.254
(continued)
Table 2.5 Scope Configurations on the DHCP Server at the Branch Office (continued)
C (wireless) 192.168.2.1 to 192.168.2.1 to 192.168.2.5, 192.168.2.6 to
192.168.2.254 192.168.2.204 to 192.168.2.203
192.168.2.254
D 192.168.3.1 to 192.168.3.1 to 192.168.3.20, 192.168.3.68 to
192.168.3.254 192.168.3.21 to 192.168.3.67 192.168.3.254
E 192.168.4.1 to 192.168.4.1 to 192.168.4.20, 192.168.4.68 to
192.168.4.254 192.168.4.21 to 192.168.4.67 192.168.4.254
F 192.168.5.1 to 192.168.5.1 to 192.168.5.20, 192.168.5.68 to
192.168.5.254 192.168.5.21 to 192.168.5.67 192.168.5.254
Lease Duration
Subnet B in the main office and Subnet C in the branch office are both wireless subnets. Because wireless
clients (portable computers and other portable devices) are connected to and disconnected from the network in
large numbers and for short intervals throughout the average day, lease duration on these two subnets is set for
15 minutes. These short lease times help to ensure that the maximum number of IP addresses are available in the
scope as clients connect to the network.
Lease time for all other (nonwireless) subnets is eight days.
Scope Options
Each scope is configured with option 249, classless static routes. Using classless static routes, each DHCP client
can be easily configured with the route to any destination on the network, and the subnet mask can be specified.
Because each scope represents a physical subnet, the scope can be viewed as the start location for any message
that is to be sent by a client to another subnet. The parameters used to configure option 249 are Destination,
Mask, and Router. One or more static routes can be configured with option 249; the company provides all
DHCP enabled clients on the network with routes to all other subnets using option 249.
This option is not configured as a server option because it maps routes between subnets, so no one set of values
for the required parameters of Destination, Mask, and Router is always correct. For example, subnets A and D
each use a router (that is, a VPN server configured with the Routing and Remote Access service and DHCP
Relay Agent service enabled) to communicate with each other. Of course, the routers they use are different, and
the destination is different in each case.
Server Options
The DHCP standard options shown in Table 2.6 are configured as server options at the main office DHCP
server.
Table 2.6 Example DHCP Options
Option Description Value
Number
006 DNS servers 192.168.0.3, 192.168.3.3
044 WINS/NBNS servers 192.168.0.4, 192.168.3.4
132 Enable NBT hostname resolution Byte: 0x1 (1=on)
133 Enable gethostbyname() WINS Byte: 0x1 (1=on)
resolution
Other Settings
Scopes on both DHCP servers are configured with the same reservations, lease durations, scope options, and
server options.
Additional Resources
These resources contain additional information and tools related to this chapter.
Related Information
• The Networking Guide of the Windows Server 2003 Resource Kit (or see the Networking Guide
on the Web at http://www.microsoft.com/reskit) for more information about Dynamic Host
Configuration Protocol (DHCP).
• “Dynamic Host Configuration Protocol” in the TCP/IP Core Networking Guide of the
Microsoft® Windows® 2000 Server Resource Kit.
• “Deploying DNS” in this book.
• “Deploying IPSec” in this book.
• “Designing an Authentication Strategy” in the Designing and Deploying Directory and Security
Services book of this kit for more information about using a certification authority.
• DHCP for Windows 2000, by Neall Alcott, 2001, Sebastopol, CA: O’Reilly & Associates.
• RFC 1542: Clarifications and Extensions for the Bootstrap Protocol.
• RFC 2131: Dynamic Host Configuration Protocol.
• RFC 2132: DHCP Options and BOOTP Vendor Extensions.
Related Tools
• DHCPExim tool
For more information about DHCPExim, see the Resource Kit Tools link on the Web Resources
page at http://www.microsoft.com/windows/reskits/webresources.
• Netsh
For more information about Netsh, in Help and Support Center for Windows Server 2003, click
Tools, and then click Command-line reference A-Z.
Related Help Topics
For best results in identifying Help topics by title, in Help and Support Center, under the Search box, click Set
search options. Under Help Topics, select the Search in title only checkbox.
• “Checklist: Installing a DHCP server” in Help and Support Center for Windows Server 2003.
• “Checklist: Installing a DHCP Service resource” in Help and Support Center for Windows
Server 2003.
• “Checklist: Installing a MADCAP server” in Help and Support Center for Windows
Server 2003.
• “Cluster support for DHCP servers” in Help and Support Center for Windows Server 2003.
• “Configure the DHCP Relay Agent” in Help and Support Center for Windows Server 2003.
• “Netsh” and “Netsh commands for DHCP” in Help and Support Center for Windows
Server 2003.
• “Add Dynamic BOOTP Client Support to a Scope” in Help and Support Center for Windows
Server 2003.
• “Using Routing and Remote Access servers with DHCP” in Help and Support Center for

Deploying DHCP

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Deploying DHCP

Uploaded by

Copyright:

Available Formats

C H A P T E R 2

Overview of DHCP Deployment

DHCP Deployment Process

Creating Your DHCP Server

Upgrading Your Existing DHCP Server

Determining DHCP Server Locations

Optimizing DHCP Server Performance

Extending the IP Address Lease and Renewal Duration

Improving DHCP Server Hardware

Enabling DHCP Support for Multiple Subnets

Determining How Many DHCP Servers to

Optimizing DHCP Availability

Using Split-Scope Configurations

Using Clustered DHCP Servers

Example: Using a Split-Scope Configuration in Combination with a

Using Standby Servers

Integrating DHCP with Other

Figure 2.6 Integrating DHCP with Other Services

Configuring Dynamic Update and Secure

Authorizing DHCP Servers in Active

To authorize a DHCP server in Active Directory

Figure 2.7 shows the process for defining scopes.

Setting Exclusion Ranges

Determining Lease Duration

Increasing the Default Lease Duration

Reducing the Default Lease Duration

Configuring DHCP Options

Configuring Option Classes

Configuring DHCP Option Parameters

Windows Server 2003 Protocol Options

Configuring Multicast Scopes

Implementing Your DHCP Solution

Installing DHCP on Your Server

Migrating Existing DHCP Servers

Exporting DHCP Settings

Importing DHCP Settings

Configuring DHCP Clients

Providing Support for Remote Access Clients

Configuring Support for BOOTP Clients

Configuring DHCP to Provide Boot File Information

Configuring DHCP to Provide IP Address Information

Configuring Options for BOOTP Clients

Testing Your DHCP Solution

Example DHCP Implementation

Connectivity and Routing

Transmission Security Between Sites

Active Directory Domain Structure

Subnets and IP Addressing

Installing DHCP and Authorizing Servers in Active Directory

1. Configures the servers.

The wireless scopes are divided in the following manner:

You might also like