Dynamic Host Configuration Protocol (DHCP)

Dynamic Host Configuration Protocol (DHCP) is an IP standard designed to reduce the complexity of administering address configurations by using a server computer to centrally manage IP addresses and other related configuration details used on your network. The DHCP service enables the server computer to perform as a DHCP server and configure DHCP-enabled client computers on your network.

DHCP includes Multicast Address Dynamic Client Allocation Protocol (MADCAP) which is used to perform multicast address assignment. When registered clients are dynamically assigned IP addresses through MADCAP, they can participate efficiently in the data stream process, such as for real-time video or audio network transmissions.

In this help file:

  • DHCP Overview

  • Installing the DHCP Server Role

  • Configuring DHCP Server Role Settings

  • Recommended tasks for the DHCP server role

For More Information

For updated detailed IT pro information about DHCP, see the Windows Server® 2008 documentation on the Microsoft TechNet Web site.


DHCP Overview

When you deploy Dynamic Host Configuration Protocol (DHCP) servers on your network, you can automatically provide client computers and other TCP/IP based network devices with valid IP addresses. You can also provide the additional configuration parameters these clients and devices need, called DHCP options, that allow them to connect to other network resources, such as DNS servers, WINS servers, and routers.

What a DHCP server can provide

DHCP is a client-server technology that allows DHCP servers to assign, or lease, IP addresses to computers and other devices that are enabled as DHCP clients. With DHCP, you can do the following:

  • Lease IP addresses for a specific amount of time to DHCP clients, and then automatically renew the IP addresses when the client requests a renewal.

  • Update DHCP client parameters automatically by changing a server or scope option at the DHCP server rather than performing this action individually on all DHCP clients.

  • Reserve IP addresses for specific computers or other devices so that they always have the same IP address and also receive the most up-to-date DHCP options.

  • Exclude IP addresses or address ranges from distribution by the DHCP server so that these IP addresses and ranges can be used to statically configure servers, routers, and other devices that require static IP addresses.

  • Provide DHCP services to many subnets, if all routers between the DHCP server and the subnet for which you want to provide service are configured to forward DHCP messages.

  • Configure the DHCP server to perform DNS name registration services for DHCP clients.

  • Provide multicast address assignment for IP-based DHCP clients.

Components of a DHCP server

The primary components of DHCP allow you to deploy a DHCP server and a Multicast Address Dynamic Client Allocation Protocol (MADCAP) server.

Note

MADCAP is supported in IPv4 only. The DHCPv6 server does not support MADCAP.

DHCP server

All computers and other devices on your TCP/IP network must have an IP address in order for the network to function properly. IP addresses can be configured manually at each computer, or you can deploy a DHCP server that automatically assigns IP address leases to all DHCP clients on the network.

Most client operating systems seek an IP address lease by default, so no configuration on the client computer is necessary to implement a DHCP enabled network; the first step is to deploy a DHCP server.

Before your DHCP server can provide IP address leases to clients, however, a range of IP addresses must be defined at the DHCP server. This range, known as a scope, defines a single physical subnet on your network to which DHCP services are offered. So, for example, if you have two subnets, your DHCP server must be connected to each subnet and you must define a scope for each subnet. Scopes also provide the primary way for the server to manage distribution and assignment of IP addresses and any related configuration parameters to clients on the network.

MADCAP server

When you deploy DHCP as a MADCAP server, the DHCP server can dynamically assign multicast IP addresses to clients that want to join the group of clients that receive the information sent in the multicast messages.

Multicasting is useful for the point-to-multipoint delivery of information, such as audio or video information, on an internetwork. Multicasting allows one point, such as a media server, to send the information in a single packet to many recipients by using a multicast address.

The advantages of this method are the use of a single packet and no overhead for keeping lists of recipients. Unlike broadcast packets, multicast traffic does not disturb those nodes who are not listening for it. Routers can be multicast-capable and forward the multicast packet to all networks where there is at least one node listening.

Managing a DHCP server

The primary tools that you use to manage DHCP servers are the Netsh commands for DHCP and the DHCP console.

Netsh commands for DHCP

You can type the Netsh commands for DHCP in a command prompt window at the netsh dhcp> command prompt, or you can run the Netsh commands for DHCP in batch files and other scripts. All of the functionality that is available in the DHCP console is available at the netsh dhcp> command prompt. This can be useful in the following situations:

  • When managing DHCP servers in wide area networks (WANs), commands can be used in interactive mode at the netsh> command prompt to better manage across slow-speed network links.

  • When managing a large number of DHCP servers, commands can be used in batch mode to help script and automate recurring administrative tasks that need to be performed for all DHCP servers.

DHCP console

The DHCP console is added to the Administrative Tools folder in Control Panel when you install the DHCP server role. The DHCP console appears as a Microsoft Management Console (MMC) snap-in.

The DHCP console also contains enhancements that were suggested by network managers. These include enhanced server performance monitoring, more predefined DHCP option types, dynamic update support for clients running earlier versions of Windows, and the detection of unauthorized DHCP servers on your network.

Common Administrative Tasks for DHCP

After you install a DHCP server, you can use the DHCP console or the Netsh commands for DHCP to perform these basic administrative server tasks:

  1. Create scopes.

  2. Add and configure superscopes and multicast scopes.

  3. View and modify properties for scopes, such as setting additional exclusion ranges.

  4. Activate scopes, multicast scopes, or superscopes.

  5. Monitor scope leasing activity by reviewing the active leases for each scope.

  6. Create reservations in scopes as needed for DHCP clients that require a permanent IP address for leased use.

In addition, you can also use the DHCP console or the Netsh commands for DHCP to perform the following optional or advanced setup tasks:

  • Add new custom default option types.

  • Add and configure any user or vendor-defined option classes.

  • Further configure other server properties, such as audit logging or boot protocol (BOOTP) tables.

Note

Superscopes are supported only in IPv4. The DHCPv6 server does not support superscopes.

For More Information

For updated detailed IT pro information about DHCP, see the Windows Server® 2008 documentation on the Microsoft TechNet Web site.


Installing the DHCP Server Role

DHCP server role: Configuring a DHCP server

DHCP servers centrally manage IP addresses and related information and provide it to clients automatically. This allows you to configure client network settings at a server, instead of configuring them on each client computer. If you want this computer to distribute IP addresses to clients, then configure this computer as a DHCP server.

This topic explains the basic steps that you must follow to configure a DHCP server. When you have finished setting up a basic DHCP server, you can complete additional configuration tasks, depending on how you want to use the DHCP server.

Before you begin

Before you configure your computer as a DHCP server, verify that:

  • You are familiar with DHCP concepts such as scopes, leases, and options.

  • The operating system is configured correctly. In Windows Server® 2008, DHCP depends on the appropriate configuration of the operating system and its services.

  • This computer has a static IP address (see Configuring a DHCP server static IP address.)

  • All existing disk volumes use the NTFS file system. FAT32 volumes are not secure, and they do not support file and folder compression, disk quotas, file encryption, or individual file permissions.

When you add the DHCP server role, you create one scope that defines the range of IP addresses that the DHCP server allocates to the clients on one subnet. You need to create one scope for each subnet that has clients that you want to manage using DHCP. The following table lists the information that you need to know before you add the DHCP server role, so that you can create the first scope. You need to collect the same information for each additional scope.

Before adding a DHCP server role | Comments
Review DHCP security issues. | Security issues might affect the way you deploy DHCP servers. Make sure you understand how DHCP uses security groups. For more information, see More About DHCP Security Groups.
Identify the range of IP addresses that the DHCP server should allocate to the clients. | Use the entire range of consecutive IP addresses that make up the local IP subnet. In many cases, a private address range is the best choice. For more information and a list of all the IP address ranges approved for use on private networks, see RFC 1918, "Address Allocation for Private Internets", at the Internet Engineering Task Force Web site.
Determine the correct subnet mask for the clients. | When the DHCP server leases an IP address to a client, the server can specify additional configuration information, including the subnet mask.
Identify any IP addresses that the DHCP server should not allocate to clients. | For example, a server or a network-connected printer often has a static IP address, and the DHCP server must not offer this IP address to clients.
Decide the duration of the lease of the IP addresses. | The default is eight days. In general, the duration of the lease should be equal to the average time that the clients on this subnet are active. For example, the ideal duration may be longer than eight days if the clients are desktop computers that are rarely turned off, or it may be shorter than eight days if the clients are mobile devices that frequently leave the network or are moved between subnets.
(Optional) Identify the IP address of the router (default gateway) that the clients should use to communicate with clients on other subnets. | When the DHCP server leases an IP address to a client, the server can specify additional configuration information, including the IP address of the router.
(Optional) Identify the name of the DNS domain of the clients. | When the DHCP server leases an IP address to a client, the server can specify additional configuration information, including the name of the DNS domain to which the clients belong.
(Optional) Identify the IP address of the DNS server that the clients should use. | When the DHCP server leases an IP address to a client, the server can specify additional configuration information, including the IP address of the DNS server that the clients should contact to resolve the name of another computer.
(Optional) Identify the IP address of the WINS server that the clients should use. | When the DHCP server leases an IP address to a client, the server can specify additional configuration information, including the IP address of the WINS server that the clients should contact to resolve the NetBIOS name of another computer.

Installing DHCP server

To install a DHCP server

  1. Click Start, click Administrative Tools, click Server Manager, and then acknowledge User Account Control.

  2. In Roles Summary click Add Roles, click Next, check DHCP server, and then click Next.

Additional Resources

For updated detailed IT pro information about DHCP and server roles, see the Windows Server 2008 documentation on the Microsoft TechNet Web site.


Configuring DHCP Server Role Settings

There are seven screens used to configure the DHCP Server role in Server Manager. The screen titles are in bold below and the help topic links provided on each screen of Server Manager are listed under the screen title:

Screen 1: DHCP Server

DHCP Overview

More about adding scopes

Integrating DHCP with DNS

Screen 2: IPv4 DNS Settings

More about DNS server settings->Integrating DHCP with DNS

Screen 3: IPv4 WINS Settings

More about WINS server settings

Screen 4: DHCP Scopes

More about adding scopes

Screen 5: Configure DHCPv6 Stateless Mode

More about DHCPv6 stateless mode

Screen 6: IPv6 DNS Server Settings

Integrating DHCP with DNS

Screen 7: Authorize DHCP Serve

More about authorizing DHCP servers in AD DS

Additional Resources

For more information about security group requirements and configuration, see:More About DHCP Security Groups.

For updated detailed IT pro information about DHCP, see the Windows Server 2008 documentation on the Microsoft TechNet Web site.


Configuring a DHCP server static IP address

For certain types of servers, you must assign a static IP address and subnet mask during or after Setup. These servers include DHCP servers, DNS servers, WINS servers, and any server providing access to users on the Internet. It is also recommended that you assign a static IP address and subnet mask for each domain controller. If a computer has more than one network adapter, you must assign a separate IP address for each adapter.

To configure IPv4 for static addressing

  1. Click Start, click Control Panel, click Network and Internet, click Network and Sharing Center and then click Change Adapter Settings.

  2. Right-click the connection to which you want to add a static IP address and then click Properties.

  3. Acknowledge the UAC dialog and then double-click Internet Protocol Version 4 (TCP/IP/IPv4).

  4. Click Use the following IP address, and do one of the following:

    • For a local area connection, in IP address, Subnet mask, and Default gateway, type the IP address, subnet mask, and default gateway addresses.

    • For all other connections, in IP address, type the IP address.

  5. Click Use the following DNS server addresses.

  6. In Preferred DNS server and Alternate DNS server, type the primary and secondary DNS server addresses.

To configure advanced static IPv4 address settings for a local area connection, click Advanced.

To configure IPv6 for static addressing

  1. Click Start, click Control Panel, click Network and Internet, click Network and Sharing Center and then click Change Adapter Settings.

  2. Right-click the connection to which you want to add a static IP address and then click Properties.

  3. Acknowledge the UAC dialog and then double-click Internet Protocol Version 4 (TCP/IP/IPv6).

  4. Click Use the following IPv6 address, and then do one of the following:

    • For a local area connection, in IPv6 address, Subnet prefix length, and Default gateway, type the IP address, subnet prefix length, and default gateway address.

    • For all other connections, in IPv6 address, type the IP address.

  5. Click Use the following DNS server addresses.

  6. In Preferred DNS server and Alternate DNS server, type the primary and secondary DNS server addresses.

To configure advanced static IPv6 address settings for a local area connection, click Advanced.

Additional Resources

For a list of Help topics providing related information, see Configuring DHCP Server Role Settings.

For updated detailed IT pro information about DHCP and TCP/IP, see the Windows Server 2008 documentation on the Microsoft TechNet Web site.


More about WINS server settings

When adding the DHCP Server role in Server Manager, you can specify whether or not WINS is required for applications on the network. WINS primarily supports clients that run older versions of Windows and applications that use NetBIOS. Windows 2000, Windows XP, Windows Vista®, Windows Server 2003, and Windows Server® 2008 use DNS names in addition to NetBIOS names. Environments that include some computers that use NetBIOS names and other computers that use domain names must include both WINS servers and DNS servers.

If all of your network computers are running Windows 2000, Windows XP, Windows Vista, Windows Server 2003 and Windows Server 2008, and you are not supporting any applications that require NetBIOS names, you should establish DNS as your only method of name resolution. However, before you consider decommissioning or not installing WINS servers, identify any computers or applications that rely on NetBIOS, and determine the impact of removing NetBIOS. You might find that a critical application relies on NetBIOS (with no alternative currently available) in which case, you must continue to use WINS. For example, older versions of certain applications, such as Microsoft® Systems Management Server (SMS) and Microsoft® BackOffice® client/server mail configurations using Exchange Server, might require NetBIOS naming.

Additional Resources

For a list of Help topics providing related information, see Configuring DHCP Server Role Settings.

For updated detailed IT pro information about DHCP and WINS, see the Windows Server® 2008 documentation on the Microsoft TechNet Web site.


Integrating DHCP with DNS

DNS servers provide domain name resolution for network resources. They associate the TCP/IP address assigned by DHCP to a client with its fully qualified domain name (FQDN). This association, or mapping, of an IP address to a domain name requires that a change in either the address or the name necessitates an update of the information in DNS. The DHCP protocol does not automatically update DNS in the event that the DHCP server changes the IP address of a client. To facilitate this interaction, servers running Windows Server® 2008 and DHCP and clients running DHCP can register with DNS, allowing cooperation between the two. When DHCP changes IP address information, corresponding DNS updates synchronize name-to-address associations for the computer.

When a DHCP server registers and updates DNS pointer (PTR) and address (A) resource records on behalf of its DHCP-enabled clients, it uses the information contained within an additional DHCP option: the Client FQDN option (option 81), which permits a client to provide its FQDN and any instructions to the DHCP server that is used to process DNS dynamic updates on its behalf.

The following reasons or events can trigger a dynamic update:

  • Added, removed, or modified IP addresses in the TCP/IP properties configuration for any of the installed network connections.

  • An IP address lease changes or renews any of the installed network connections with the DHCP server. For example, when a computer starts or after use of the ipconfig /renew command.

  • Upon use of the ipconfig /registerdns command, which manually forces a refresh of the client name registration in DNS.

When one of these events triggers a dynamic update, the DHCP Client service (not the DNS Client service) sends updates. The DHCP Client service performs this function for all network connections on the client, including any that are not configured to use DHCP.

When a qualified DHCP client issues an update, such as a DHCP-enabled computer running Windows XP Professional or Windows Vista®, servers running Windows Server 2008 and DHCP process the update to determine in which of three ways the server will initiate updates on behalf of the client:

  • The DHCP server always registers the DHCP client for both the forward (A resource records) and reverse lookup or pointer (PTR resource records) with DNS.

  • The DHCP server never registers the name-to-address (A resource records) for DHCP clients.

  • The DHCP server registers the DHCP client for both forward (A resource records) and reverse lookup or pointer (PTR resource records) when requested to do so by the client.

The ability to register both A and PTR resource records enables a DHCP server to act as a proxy for clients running other operating systems, such as Microsoft Windows Millennium Edition, or Windows 98, for the purpose of DNS dynamic update registration. The DHCP server can automatically differentiate between Windows 2000, Windows XP Professional, Windows Vista, and other clients.

DHCP requires the use of DNS dynamic update to keep name-to-address mapping information synchronized. Using DHCP and DNS together on a network might cause problems when using older, static DNS servers, which cannot interact dynamically when DHCP client configurations change. You can avoid failed DNS lookups for DHCP-registered clients when using static DNS service by doing the following:

  • If you are using Windows Internet Name Service (WINS) servers on a network, enable WINS lookup for DHCP clients that use NetBIOS.

  • Assign IP address reservations with an infinite lease duration for DHCP clients that use DNS only and do not support NetBIOS.

  • Wherever possible, upgrade or replace older static DNS servers with DNS servers that support DNS dynamic updates.

Additional Resources

For a list of Help topics providing related information, see Configuring DHCP Server Role Settings.

For updated detailed IT pro information about DHCP and DNS, see the Windows Server 2008 documentation on the Microsoft TechNet Web site.


More about adding scopes

Configuring scopes

A scope is an administrative grouping of IP addresses for computers on a subnet that use the DHCP service. The administrator first creates a scope for each physical subnet and then uses the scope to define the parameters used by clients. A scope has the following properties:

  • A range of IP addresses from which to include or exclude addresses used for DHCP service lease offerings.

  • A subnet mask, which determines the subnet for a given IP address.

  • A scope name assigned when it is created.

  • Lease duration values, which are assigned to DHCP clients that receive dynamically allocated IP addresses.

  • Any DHCP scope options configured for assignment to DHCP clients, such as DNS server, router IP address, and WINS server address.

  • Reservations, optionally used to ensure that a DHCP client always receives the same IP address.

Before adding scopes

A DHCP scope consists of a pool of IP addresses on a given subnet, such as 192.168.0.1 to 192.168.0.254, that the DHCP server can lease to clients.

Each subnet can have only a single DHCP scope with a single continuous range of IP addresses. To use several address ranges within a single scope or subnet for DHCP service, you must first define the scope and then set any needed exclusion ranges.

  • Defining the scope

    Use the entire range of consecutive IP addresses that make up the local IP subnet for which you are enabling DHCP service.

  • Setting exclusion ranges

    You should set exclusion ranges for any IP addresses within the scope that you do not want the DHCP server to offer or use for DHCP assignment. For example, you can exclude the first 10 addresses in the previous example scope by creating an exclusion for 192.168.0.1 to 192.168.0.10.

    By setting an exclusion for these addresses, you specify that DHCP clients are never offered these addresses when they request leased configuration from the server. Excluded IP addresses can be active on your network, but only by manually configuring these addresses at hosts that do not use DHCP to obtain an address.

Creating scopes

When you create a DHCP scope, you use the DHCP console to enter the following required information:

  • A scope name, assigned by you or the administrator who created the scope.

  • A subnet mask used to identify the subnet to which an IP address belongs.

  • A range of IP addresses contained within the scope.

  • A time interval (known as a lease duration) that specifies how long a DHCP client can use an assigned IP address before it must renew its configuration with the DHCP server.

Using the 80/20 rule for scopes

For balancing DHCP server usage, a good practice is to use the "80/20" rule to divide the scope addresses between the two DHCP servers. If Server 1 is configured to make available most (approximately 80%) of the addresses, then Server 2 can be configured to make the other addresses (approximately 20%) available to clients. The following illustration is an example of the 80/20 rule:

After scopes are added

After you define a scope, you can additionally configure the scope by performing the following tasks:

  • Set additional exclusion ranges.

    You can exclude any other IP addresses that must not be leased to DHCP clients. You should use exclusions for all devices that must be statically configured. The excluded ranges should include all IP addresses that you assigned manually to other DHCP servers, non-DHCP clients, diskless workstations, or Routing and Remote Access and PPP clients.

  • Create reservations.

    You can choose to reserve some IP addresses for permanent lease assignment to specified computers or devices on your network. You should make reservations only for devices that are DHCP-enabled and that must be reserved for specific purposes on your network (such as print servers).

  • Adjust the length of lease durations.

    You can modify the lease duration to be used for assigning IP address leases. The default lease duration is eight days.

    For most LANs, the default value is acceptable but can be further increased if computers seldom move or change locations. Also, infinite lease times can be set but should be used with caution.

  • Configure options and classes to be used with the scope.

    To provide full configuration for clients, DHCP options need to be configured and enabled for the scope.

    For more advanced discrete management of scope clients, you can add or enable user or vendor-defined option classes.

Note

  • After you define and configure a scope, the scope must be activated before the DHCP server begins providing service to clients. However, you should not activate a new scope until you have specified the DHCP options for it.

  • After you activate a scope, you should not change the range of scope addresses.

Additional Resources

For a list of Help topics providing related information, see Configuring DHCP Server Role Settings.

For updated detailed IT pro information about DHCP, scopes and activation, see the Windows Server 2008 documentation on the Microsoft TechNet Web site.


More about authorizing DHCP servers in AD DS

In Windows Server® 2008, the DHCP Server service is integrated with Active Directory to provide authorization for DHCP servers. An unauthorized DHCP server on a network can disrupt network operations by allocating incorrect addresses or configuration options. A DHCP server that is a domain controller or a member of an Active Directory domain queries Active Directory for the list of authorized servers (identified by IP address). If its own IP address is not in the list of authorized DHCP servers, the DHCP Server service does not complete its startup sequence and automatically shuts down.

This is a common issue for network administrators who attempt to install and configure a DHCP server in an Active Directory environment without first authorizing the server.

For a DHCP server that is not a member of the Active Directory domain, the DHCP Server service sends a broadcast DHCPInform message to request information about the root Active Directory domain in which other DHCP servers are installed and configured. Other DHCP servers on the network respond with a DHCPAck message, which contains information that the querying DHCP server uses to locate the Active Directory root domain. The starting DHCP server then queries Active Directory for a list of authorized DHCP servers and starts the DHCP Server service only if its own address is in the list.

How Authorization Works

The authorization process for DHCP server computers depends on the installed role of the server on your network. There are three roles or server types for which each server computer can be installed:

  • Domain controller -- The computer keeps and maintains a copy of the Active Directory database and provides secure account management for domain member users and computers.

  • Member server -- The computer is not operating as a domain controller but has joined a domain in which it has a membership account in the Active Directory database.

  • Stand-alone server -- The computer is not operating as a domain controller or a member server in a domain. Instead, the server computer is made known to the network through a specified workgroup name, which can be shared by other computers, but is used only for computer browsing purposes and not to provide secured logon access to shared domain resources.

If you deploy Active Directory, all computers operating as DHCP servers must be either domain controllers or domain member servers before they can be authorized and provide DHCP service to clients.

Although it is not recommended, you can use a stand-alone server as a DHCP server as long as it is not on a subnet with any authorized DHCP servers. When a stand-alone DHCP server detects an authorized server on the same subnet, it automatically stops leasing IP addresses to DHCP clients.

Additional Resources

For a list of Help topics providing related information, see Configuring DHCP Server Role Settings.


More about DHCPv6 stateless mode

Windows Server® 2008 supports stateless and stateful DHCPv6 server functionality. DHCPv6 stateless mode clients use DHCPv6 to obtain network configuration parameters other than the IPv6 address, such as DNS server addresses. Clients configure an IPv6 address through a non-DHCPv6 based mechanism such as IPv6 address auto-configuration (based on the IPv6 prefixes included in router advertisements), or static IP address configuration.

In DHCPv6 stateful mode, clients acquire both the IPv6 address as well as other network configuration parameters through DHCPv6.

Additional Resources

For a list of Help topics providing related information, see Configuring DHCP Server Role Settings.

For updated detailed IT pro information about DHCP and DHCPv6, see the Windows Server 2008 documentation on the Microsoft TechNet Web site.


DHCP network interface card bindings

A multihomed DHCP server is a computer running a Windows Server® 2008 operating system that uses the DHCP service for more than a single network connection. For a server computer to be multihomed, each network connection must attach the computer to more than a single physical network. This requires that additional hardware (in the form of multiple installed network adapters) be used on the computer.

A computer running a Windows Server 2008 operating system can perform as a multihomed DHCP server. For multihomed servers, the DHCP service binds to the first IP address statically configured for each network connection in use.

By default, the service bindings depend on whether the first network connection is configured dynamically or statically for TCP/IP. Based on the method of configuration it uses, reflected by its current settings in Internet Protocol (TCP/IP) properties, the DHCP Server service performs default service bindings as follows:

  • If the first network connection uses a manually specified IP address, the connection is enabled in server bindings. For this to occur, a value for IP address must be configured and the Use the following IP address option selected in Internet Protocol (TCP/IP) properties. In this mode, the DHCP server listens for and provides service to DHCP clients.

  • If the first network connection uses an IP address configured dynamically, the connection is disabled in server bindings. This occurs when the Obtain an IP address automatically option is selected in Internet Protocol (TCP/IP) properties. For computers running Windows Server 2008 operating systems, this is the default setting. In this mode, the DHCP server does not listen for and provide service to DHCP clients until a static IP address is configured.

  • The DHCP server will bind to the first static IP address configured on each adapter.

Note

  • By design, DHCP server bindings are enabled and disabled on a per-connection, not per-address basis. All bindings are based on the first configured IP address for each connection appearing in the Network Connections folder. If additional static IP addresses (for example, as set in Advanced TCP/IP properties) are configured for the applicable connection, these addresses are never used by DHCP servers running Windows Server 2008 and are inconsequential for server bindings.

  • DHCP servers running Windows Server 2008 never bind to any of the NDISWAN or DHCP-enabled interfaces used on the server. These interfaces are not displayed in the DHCP console under the current server bindings list because they are never used for DHCP service. Only additional network connections that have a primary static IP address configured can appear in the server bindings list (or be selectively enabled or disabled there).

Additional Resources

For a list of Help topics providing related information, see Configuring DHCP Server Role Settings.

For updated detailed IT pro information about DHCP and selectively enabling or disabling DHCP server bindings, see the Windows Server 2008 documentation on the Microsoft TechNet Web site.


Configuring Split Scopes

You can use this procedure to split a DHCP IPv4 scope.

Membership in the Administrators or DHCP Administrators group is the minimum required to complete this procedure.

To split a DHCP scope

  1. Open the DHCP Microsoft Management Console (MMC) snap-in.

  2. In the console tree, double-click the DHCP server you want to configure.

  3. Right-click IPv4 and then right-click the scope you want to split.

  4. Click Advanced and then click Split-Scope.

  5. Follow the instructions in the DHCP Split-Scope Configuration Wizard.

    Note

    The DHCP Split-Scope Configuration Wizard is only available for IPv4 scopes.

Additional Resources

For a list of Help topics providing related information, see Configuring DHCP Server Role Settings.

For updated detailed IT pro information about DHCP and selectively enabling or disabling DHCP server bindings, see the Windows Server 2008 documentation on the Microsoft TechNet Web site.


Configuring Name Protection

Name squatting occurs when a non-Windows-based computer registers in Domain Name System (DNS) with a name that is already registered to a Windows-based computer. The use of name protection in Windows Server prevents name squatting by non-Windows-based computers. Name squatting does not present a problem on a homogeneous Windows network where Active Directory Domain Services (AD DS) can be used to reserve a name for a single user or computer.

Name protection is based on the Dynamic Host Configuration Identifier (DHCID) in the Dynamic Host Configuration Protocol (DHCP) server, and support for the new DHCID RR (resource record) in DNS. DHCID RR is described by the Internet Engineering Task Force (IETF) in RFCs 4701 and 4703.

DHCID is a resource record (RR) stored in DNS that maps names to prevent duplicate registration. This RR is used by DHCP to store an identifier for a computer, along with other information for the name such as the A/AAAA records of the computer. The unique position of DHCP in the name registration process allows it to request this match, and then refuse the registration of a computer with a different address attempting to register a name with an existing DHCID record.

DHCID prevents the following name squatting situations:

  • Server name squatting by a client

  • Server name squatting by another server

  • Client name squatting by another client

  • Client name squatting by a server

In addition, support for DHCP Unique Identifier (DUID) will be added to the IPv4 registration on the DHCP client. DUID is described by the IETF in RFC 4361.

Name protection can be configured for IPv4 and IPv6 at the network adapter level or scope level. Name protection settings configured at the scope level take precedence over the setting at the IPv4 or IPv6 level. If Name protection at the scope level is not configured at all, then the setting at the IPv4 or IPv6 network adapter takes precedence. DHCID protects names on a first come-first served basis.

To enable name protection at the IPv4 or IPv6 node level

  1. Open the DHCP Microsoft Management Console (MMC) snap-in.

  2. In the console tree, double-click the DHCP server you want to configure, right-click IPv4 or IPv6, and then click Properties.

  3. Click DNS, click Advanced, and then check Enable Name Protection.
To enable name protection at the scope level

  1. Open the DHCP console.

  2. In the console tree, double-click the DHCP server you want to configure, double-click IPv4 or IPv6, right-click the scope you want, and then click Properties.

  3. Click DNS, click Configure, and then check Enable Name Protection.

Additional Resources

For a list of Help topics providing related information, see Recommended tasks for the DHCP server role.


Configuring Link Layer Filtering

Link layer filtering provides network access control for the issuance or denial of DHCP leases of IP addresses based on a media access control (MAC) address. Link layer filtering can be configured at the IPv4 node for all clients across all IPv4 scopes. This feature is currently available only for IPv4 networks.

To enable MAC address filtering

  1. Open the DHCP Microsoft Management Console (MMC) snap-in.

  2. In the console tree, double-click the DHCP server you want to configure, right-click IPv4, and then click Properties.

  3. Click Filters, and then select the Enable Allow List or the Enable Deny List check box.
To configure a new filter

  1. Open the DHCP snap-in.

  2. In the console tree, double-click the applicable DHCP server, double-click IPv4, double-click Filters, and then right-click Allow or Deny.

  3. Click New Filter, and then type a MAC Address and Description. Description is an optional field.
Notes
  • The MAC address can either be the full address or a MAC address pattern (wild card). Following are the valid MAC address wild cards:
    • 00-1C-23-*-*-*

    • 00-1C-23-20-AF-*

    • 00-1C-23-20-*-*

    • 001C2320AF4E

    • 001C*

Note

Deny filters supersede Allow filters.

To edit the hardware type exempted from filtering list

  1. Open the DHCP snap-in.

  2. In the console tree, double-click the DHCP server you want to configure, right-click IPv4, and then click Properties.

  3. Click Filters, click Advanced, and then select or clear the check boxes for the hardware types you want to edit.

Additional Resources

For a list of Help topics providing related information, see Configuring DHCP Server Role Settings.


Configuring a DHCP Scope

A scope is an administrative grouping of IP addresses for computers on a subnet that use the Dynamic Host Configuration Protocol (DHCP) service. The administrator first creates a scope for each physical subnet and then uses the scope to define the parameters used by clients. A scope has the following properties:

  • A range of IP addresses from which to include or exclude addresses used for DHCP service lease offerings.

  • A subnet mask, which determines the subnet for a specific IP address.

  • A scope name.

  • Lease duration values, which are assigned to DHCP clients that receive dynamically allocated IP addresses.

  • Any DHCP scope options configured for assignment to DHCP clients, such as Domain Name System (DNS) server, router IP address, and Windows Internet Name Service (WINS) server address.

  • Reservations, optionally used to ensure that a DHCP client always receives the same IP address.

Before adding scopes

A DHCP scope consists of a pool of IP addresses on a specific subnet, such as 192.168.0.1 to 192.168.0.254, that the DHCP server can lease to clients.

Each subnet can have only a single DHCP scope with a single continuous range of IP addresses. To use several address ranges within a single scope or subnet for the DHCP service, you must first define the scope and then set any required exclusion ranges:

  • Defining the scope

    Use the entire range of consecutive IP addresses that make up the local IP subnet for which you are enabling the DHCP service.

  • Setting exclusion ranges

    Set exclusion ranges for any IP addresses within the scope that you do not want the DHCP server to offer or use for DHCP assignment. For example, you can exclude the first 10 addresses in the previous example scope by creating an exclusion for 192.168.0.1 to 192.168.0.10.

    By setting an exclusion range for these addresses, you specify that DHCP clients are never offered these addresses when they request an IP address from the server. Excluded IP addresses can be active on your network, but only by manually configuring these addresses at hosts that do not use DHCP to obtain an address.

Creating scopes

You can use this procedure to create a new DHCP scope.

Membership in the Administrators or DHCP Administrators group is the minimum required to complete this procedure.

To create a new DHCP scope

  1. Open the DHCP Microsoft Management Console (MMC) snap-in.

  2. In the console tree, double-click the DHCP server you want to configure.

  3. Right-click IPv4 or IPv6 and then click New Scope.

  4. Follow the instructions in the New Scope Wizard.

Additional considerations

Before you create the scope, determine starting and ending IP addresses to be used within it.

Depending on the starting and ending IP addresses for your scope, the DHCP console suggests a default subnet mask useful for most networks. If you know a different subnet mask is required for your network, you can modify the value as needed.

When you finish creating a new scope, you might need to complete additional tasks, such as activating the scope for use or assigning scope options.

Using the 80/20 rule for scopes

For balancing DHCP server usage, a good practice is to use the "80/20" rule to divide the scope addresses between the two DHCP servers. If Server 1 is configured to make available most (approximately 80 percent) of the addresses, then Server 2 can be configured to make the other addresses (approximately 20 percent) available to clients. For more information, see Balance the load on your DHCP servers by using the 80/20 rule for scopes on the Microsoft TechNet Web site at http://go.microsoft.com/fwlink/?LinkId=125700.

Additional Resources

For a list of Help topics providing related information, see Configuring DHCP Server Role Settings.


Configuring a DHCP Multicast Scope

Multicasting is the sending of network traffic to a group of endpointsdestination hosts. Only those members in the group of endpoints hosts that are listening for the multicast traffic (the multicast group) process the multicast traffic. All other nodes hosts ignore the multicast traffic.

Multicast scopes are supported by using Multicast Address Dynamic Client Allocation Protocol (MADCAP), a protocol for performing multicast address allocation. The MADCAP protocol describes how multicast address allocation or MADCAP servers can dynamically provide IP addresses to other computers (MADCAP clients) on your network.

Typically, a MADCAP server is also a multicast server (MCS) used to support IP multicasting. An MCS manages the shared or group use of the allocated multicast IP address and streams data traffic to members that share the use of the specified group address.

After an MCS is configured and allocated a group address to use, any multicast clients that have registered their membership with the MCS can receive streams sent to this address. By registering with the MCS, clients can participate efficiently in the stream process, such as for real-time video or audio network transmissions. The MCS also manages the multicast group list, updating its membership and status so that multicast traffic is received by all current members.

You can use this procedure to create a multicast scope.

Membership in the Administrators or DHCP Administrators group is the minimum required to complete this procedure.

To create a multicast scope

  1. Open the DHCP Microsoft Management Console (MMC) snap-in.

  2. In the console tree, click the DHCP server you want to configure.

  3. On the Action menu, click New Multicast Scope.

  4. Follow the instructions in the New Multicast Scope Wizard.

Additional Resources

For a list of Help topics providing related information, see Configuring DHCP Server Role Settings.


Configuring a DHCP Superscope

A superscope is an administrative feature of Dynamic Host Configuration Protocol (DHCP) servers running Windows Server 2008 that you can create and manage by using the DHCP Microsoft Management Console (MMC) snap-in. By using a superscope, you can group multiple scopes as a single administrative entity. With this feature, a DHCP server can:

  • Support DHCP clients on a single physical network segment (such as a single Ethernet LAN segment) where multiple logical IP networks are used. When more than one logical IP network is used on each physical subnet or network, such configurations are often called multinets.

  • Support remote DHCP clients located on the far side of DHCP and BOOTP relay agents (where the network on the far side of the relay agent uses multinets).

In multinet configurations, you can use DHCP superscopes to group and activate individual scope ranges of IP addresses used on your network. In this way, the DHCP server can activate and provide leases from more than one scope to clients on a single physical network.

Superscopes can resolve specific types of DHCP deployment issues for multinets, including situations in which:

  • The available address pool for a currently active scope is nearly depleted, and more computers need to be added to the network. The original scope includes the full addressable range for a single IP network of a specified address class. You need to use another range of IP addresses to extend the address space for the same physical network segment.

  • Clients must be migrated over time to a new scope (such as to renumber the current IP network from an address range used in an existing active scope to a new scope that contains another range of IP addresses).

  • You want to use two DHCP servers on the same physical network segment to manage separate logical IP networks.

Superscope configurations for multinets

The following section shows how a simple DHCP network consisting originally of one physical network segment and one DHCP server can be extended to use superscopes for support of multinet configurations.

Example 1: Non-routed DHCP server (before superscope)

In this example, a small local area network (LAN) with one DHCP server supports a single physical subnet, Subnet A. The DHCP server in this configuration is limited to leasing addresses to clients on this same physical subnet.

The following illustration shows this example network in its original state. At this point, no superscopes have been added and a single scope, Scope 1, is used to service all DHCP clients on Subnet A.

Single subnet and DHCP server (before superscope)

Example 2: Superscope for non-routed DHCP server supporting local multinets

To include multinets implemented for client computers on Subnet A, the same network segment where the DHCP server is located, you can configure a superscope that includes as members the original scope (Scope 1) and additional scopes for the logical multinets for which you need to add support (Scope 2 and Scope 3).

This illustration shows the scope and superscope configuration to support the multinets on the same physical network (Subnet A) as the DHCP server.

Superscope for non-routed DHCP server

Example 3: Superscope for routed DHCP server with relay agent supporting remote multinets

To include multinets implemented for client computers on Subnet B, the remote network segment located across a router from the DHCP server on Subnet A, you can configure a superscope that includes as members the additional scopes for the logical multinets for which you need to add remote support (Scope 2 and Scope 3).

Because the multinets are for the remote network (Subnet B), the original scope (Scope 1) does not need to be part of the added superscope.

This illustration shows the scope and superscope configuration to support the multinets on the remote physical network (Subnet B) away from the DHCP server. A DHCP relay agent is used for DHCP servers to support clients on remote subnets.

Superscope for routed DHCP server

Create a superscope

You can use this procedure to create a DHCP superscope.

Membership in the Administrators or DHCP Administrators group is the minimum required to complete this procedure.

To create a superscope

  1. Open the DHCP snap-in.

  2. In the console tree, click the DHCP server you want to configure.

  3. On the Action menu, click New Superscope.

    This menu option only appears if at least one scope that is not currently part of a superscope has been created at the DHCP server.

  4. Follow the instructions in the New Superscope Wizard.

Additional Resources

For a list of Help topics providing related information, see Configuring DHCP Server Role Settings.


More About Predefined DHCP Options

Dynamic Host Configuration Protocol (DHCP) option classes offer an additional method for grouping configuration details for DHCP clients within a scope. There are two types of DHCP option classes:

  • User classes, for assigning options to clients identified as needing a similar DHCP options configuration.

  • Vendor classes, for assigning vendor-specific options to clients identified as sharing a commonly defined vendor type.

Managing user classes

User classes allow DHCP clients to differentiate themselves by specifying a User Class option. When available for client use, this option includes a user-determined class ID that can help to group clients of similar configuration needs within a scope. For example, you might support users and computers with mobile computing needs by configuring a user class at the DHCP server and setting the related class ID at the client computers.

A user class is useful when you need to keep separate options that cover the special needs of identifying client computers, such as providing a shorter lease time for portable computers that move frequently or use remote access often. In this example, you can configure the DHCP server to distribute options that are specific to the needs of those clients.

The user class feature gives you greater flexibility in configuring DHCP clients on your network, but is not required for standard DHCP use. If user-defined option classes are not configured, options are provided through the standard server, scope, or client option settings instead.

DHCP servers running Windows Server® 2008, which supports recognition of user class IDs, perform the following added steps when clients request an IP address:

  1. The server determines whether the user class identified by the client in its lease request is a recognized class, previously defined on the server.

    If a predefined user class exists at the server and is configured, class-based assignment is enabled. For other user classes, you must first add and configure them at the server before they are available for use.

  2. If the user class is recognized, the server determines whether any additional DHCP options are configured for this class in the active lease context (either the scope or a client reservation) where the server is leasing the client.

  3. If the scope or reservation context are configured to provide options for the user-defined class of the client, the server returns those options to the client as part of its DHCP acknowledgment (DHCPACK) message, which is sent to confirm the lease.

    Note

    In addition to configuring or adding user classes at the DHCP server, you can set a DHCP client class identifier with the ipconfig /setclassid command.

Additional user class examples

You can define user class identifiers to convey information about client software configuration, its physical location, or its user preferences. For example, an identifier can specify that DHCP clients are members of a user-defined class called "2nd floor, West," which has need for a special set of router, Domain Name System (DNS), and Windows Internet Name Service (WINS) server settings.

You can also use the Microsoft predefined user classes for isolating configuration details specific for clients with special needs, such as Bootstrap Protocol (BOOTP) or Routing and Remote Access service.

Notes
  • When you configure user classes at the DHCP server, make sure that the user class ID data you set at both the DHCP server and member client computers is identically matching binary or ASCII data.
  • The user class option only permits one class ID to be used for identifying clients. Each client computer can only be identified as a member of a single user class at the DHCP server. You can use additional user classes and make hybrids from your other user classes, as required.

Managing vendor classes

Vendor-defined option classes can be used by DHCP clients that identify themselves by their vendor type to the DHCP server when obtaining a lease. For a client to identify its membership in a vendor class, the client provides a value in the Vendor class identifier option when it requests or selects a lease from the server.

The vendor class identifier information is a string of character data interpreted by a DHCP server. Microsoft supports vendor class identification for its DHCP clients running Windows 7Windows Vista and Windows XP.

Other vendors might choose to define their own specific vendor class IDs for either conveying vendor-specific information or handling special needs for their DHCP clients.

DHCP servers running Windows Server 2008, which supports recognition of vendor class IDs, perform the following added steps when clients request an IP address:

  1. The server determines whether the vendor class identified by the client in its lease request is a recognized class, previously defined on the server.

    Only Microsoft vendor classes are predefined at the server. For other vendor classes, you must manually add and configure these options at your DHCP servers running Windows Server 2008 before they are available for use.

  2. If the vendor class is recognized, the server determines whether any additional DHCP options are configured for this class in the active lease context (either the scope or a client reservation) where the server is leasing the client.

  3. If the scope or reservation context are configured to provide options for the vendor-defined class of the client, the server returns those options by using the Vendor specific information option as part of its DHCP acknowledgment (DHCPACK) message, which is sent to confirm the lease.

Vendor classes permit other system vendors to support custom applications for DHCP in mixed vendor environments. Vendor-specific options, when provided, are used in addition to any of the standard DHCP options assigned or required for DHCP.

Notes
  • The default vendor class, DHCP standard options, can be useful for grouping any DHCP clients that do not specify vendor class IDs.
  • When you add new vendor classes at the DHCP server, make sure that the vendor class ID data you set at the server matches the vendor class ID used by clients for your vendor. For more information, contact the appropriate vendor.

Additional Resources

For a list of Help topics providing related information, see Configuring DHCP Server Role Settings.


Recommended tasks for the DHCP server role

Following are tasks that can increase the security, reliability and manageability of your DHCP Server role. Many of these tasks involve configuring your DHCP in conjunction with another Windows Server® 2008 technology or feature, such as Active Directory (AD) or Network Access Protection (NAP), and others describe how you can design your DHCP infrastructure for greatest efficiency:

  • Increase fault tolerance by splitting DHCP scopes

  • Eliminate manual updates of DNS records by configuring dynamic update and secure dynamic update

  • Allow remote administration of DHCP servers by configuring Windows Firewall ports

  • Prevent rogue DHCP servers on your network by authorizing DHCP servers in AD DS

  • Enforce network access policies for client health by configuring DHCP with Network Access Protection

  • Automate management of devices that have static IP addresses by creating DHCP reservations

  • Support multiple subnets with one DHCP server by configuring DHCP relay agents

  • Avoid reconfiguring DHCP on a new server by migrating an existing DHCP infrastructure

  • Balance the load on your DHCP servers by using the 80/20 rule for scopes

  • Centralize management of two or more DHCP servers as a single system by clustering DHCP servers

Additional Information

For updated detailed IT pro information about DHCP and server roles, see the Windows Server 2008 documentation on the Microsoft TechNet Web site.


Increase fault tolerance by splitting DHCP scopes

It is a good idea to split a scope between two or three servers. In this way, one can handle DHCP traffic flood more easily. In addition, if a server fails, the network is not affected. An 80/20 split seems to offer the optimum benefit.

For example, consider a Class B scope 132.255.0.0 with address range from 132.255.0.1-132.255.255.255 and subnet mask 255.255.0.0. One setup would be to distribute the load between two servers (SRV1 and SRV2). SRV1 has a scope of 132.255.0.1-132.255.255.255 with a mask of 255.255.0.0. The exclusion range for this scope is 132.255.128.0-132.255.255.255. SRV2 has a scope of 132.255.0.1-132.255.255.255 with a mask of 255.255.0.0. The exclusion range for this scope is 132.255.0.1-132.127.255.255. A scope can also be divided between three servers in a similar way.

Additional Resources

For a list of Help topics providing related information, see Recommended tasks for the DHCP server role.

For updated detailed IT pro information about DHCP, see the Windows Server® 2008 documentation on the Microsoft TechNet Web site.


Eliminate manual updates of DNS records by configuring dynamic update and secure dynamic update

With Windows Server 2008, a DHCP server can enable dynamic updates in the DNS namespace for any one of its clients that support these updates. Scope clients can use the DNS dynamic update protocol to update their host name-to-address mapping information whenever changes occur to their DHCP-assigned address. (This mapping information is stored in zones on the DNS server.) A Windows Server 2008–based DHCP server can perform updates on behalf of its DHCP clients to any DNS server.

How DHCP/DNS update interaction works

You can use the DHCP server to register and update the PTR and A resource records on behalf of the server's DHCP-enabled clients. When you do this, you must use an additional DHCP option, the Client FQDN option (option 81). This option lets the client send its FQDN to the DHCP server in the DHCPREQUEST packet. This enables the client to notify the DHCP server as to the service level it requires.

The FQDN option includes the following six fields:

  1. Code -- Specifies the code for this option (81).

  2. Len -- Specifies the length of this option. (This must be a minimum of 4.)

  3. Flags -- Specifies the type of service.

    • 0 -- Client will register the "A" (Host) record.

    • 1 -- Client wants DHCP to register the "A" (Host) record.

    • 3 -- DHCP will register the "A" (Host) record regardless of the client's request.

  4. RCODE1 -- Specifies a response code the server is sending to the client.

  5. RCODE2 -- Specifies an additional delineation of RCODE1.

  6. Domain Name -- Specifies the FQDN of the client.

If the client requests to register its resource records with DNS, the client is responsible for generating the dynamic UPDATE request per Request for Comments (RFC) 2136. Then, the DHCP server registers its PTR (pointer) record.

Assume that this option is issued by a qualified DHCP client, such as a DHCP-enabled computer that is running, Windows Vista, Windows 2000 or Windows XP. In this case, the option is processed and interpreted by Windows Server 2008–based DHCP servers to determine how the server initiates updates on behalf of the client.

Secure dynamic updates

For Windows Server 2008, DNS update security is available only for zones that are integrated into Active Directory. After you integrate a zone, you can use the access control list (ACL) editing features that are available in the DNS snap-in to add or to remove users or groups from the ACL for a specific zone or for a resource record.

By default, dynamic update security for Windows Server 2008–based DNS servers and clients is handled in the following manner:

  1. Windows Server 2008–based DNS clients try to use nonsecure dynamic updates first. If the nonsecure update is refused, clients try to use a secure update.

    Also, clients use a default update policy that lets them to try to overwrite a previously registered resource record, unless they are specifically blocked by update security.

  2. By default, after a zone becomes Active Directory-integrated, Windows Server 2008–based DNS servers enable only secure dynamic updates.

    By default, when you use standard zone storage, the DNS Server service does not enable dynamic updates on its zones. For zones that are either directory-integrated or use standard file-based storage, you can change the zone to enable all dynamic updates. This enables all updates to be accepted by passing the use of secure updates.

If you use multiple Windows Server 2008–based DHCP servers on your network and if you configure your zones to enable secure dynamic updates only, use the Active Directory Users and Computers snap-in to add your DHCP server computers to the built-in DnsUpdateProxy group. When you do this, all your DHCP servers have the secure rights to perform proxy updates for any one of your DHCP clients.

Caution
  • The secure dynamic updates functionality can be compromised if the following conditions are true:
  • •You run a DHCP server on a Windows Server 2008–based domain controller
  • •The DHCP server is configured to perform registration of DNS records on behalf of its clients.
  • To avoid this issue, deploy DHCP servers and domain controllers on separate computers, or configure the DHCP server to use a dedicated user account for dynamic updates.
Note

The secure dynamic update functionality is supported only for Active Directory-integrated zones. If you configure a different zone type, change the zone type, and then integrate the zone before you secure it for DNS updates. Dynamic update is an RFC-compliant extension to the DNS standard. The DNS update process is defined in RFC 2136, "Dynamic Updates in the Domain Name System (DNS UPDATE)."

Additional Resources

For a list of Help topics providing related information, see Recommended tasks for the DHCP server role.


Allow remote administration of DHCP servers by configuring Windows Firewall ports

Windows Firewall is a stateful host firewall that blocks all unsolicited incoming TCP/IP traffic, including Internet Protocol version 4 (IPv4) and Internet Protocol version 6 (IPv6) traffic. If you enable Windows Firewall on a server and you want to manage the server with a remote administration tool, usually you must configure Windows Firewall settings on the server so that the server can receive unsolicited traffic from the remote administration tool. You might also have to configure Windows Firewall settings on the computer that is running the remote administration tool if Windows Firewall is enabled on that computer. Although you can configure Windows Firewall settings manually, the recommended method is to use the Security Configuration Wizard (SCW).

To use a remote administration tool with Windows Firewall, you usually need to add a program or port to the Windows Firewall exceptions list. When you add a program or port to the exceptions list, you instruct Windows Firewall to allow unsolicited incoming traffic to reach the specified program or pass through the specified port. In some cases, you might need to configure a registry setting or enable one of the preconfigured Windows Firewall exceptions, such as the File and Printer Sharing exception or the Remote Administration exception.

Caution

The Remote Administration exception allows traffic through numerous ports, which can make your computer more accessible to attack. Be sure to read the Windows Firewall documentation so that you understand the risks of using the Remote Administration exception. Incorrectly editing the registry can severely damage your system. Before you make changes to the registry, you should back up any valued data on the computer.

To administer a DHCP server remotely from another DHCP server or to use the Administrative Tools Pack to administer a DHCP server remotely, add Tcpsvcs.exe and UDP ports 67 and 2535 to the Windows Firewall exceptions list on the target server.

The following firewall inbound exception rules are enabled during and after installation of the DHCP Server role to allow remote administration of the DHCP Server:

  • DHCP Server (RPC-In)

  • DHCP Server (RPCCS-In)

When the DHCP Server role is uninstalled, the firewall inbound exception rules will be removed, disallowing remote administration

Additional Resources

For a list of Help topics providing related information, see Recommended tasks for the DHCP server role.

For updated detailed IT pro information about DHCP and Windows Firewall, see the Windows Server® 2008 documentation on the Microsoft TechNet Web site.


Prevent rogue DHCP servers on your network by authorizing DHCP servers in AD DS

In Windows Server® 2008, the DHCP Server service is integrated with Active Directory to provide authorization for DHCP servers. An unauthorized DHCP server on a network can disrupt network operations by allocating incorrect addresses or configuration options. A DHCP server that is a domain controller or a member of an Active Directory domain queries Active Directory for the list of authorized servers (identified by IP address). If its own IP address is not in the list of authorized DHCP servers, the DHCP Server service does not complete its startup sequence and automatically shuts down.

This is a common issue for network administrators who attempt to install and configure a DHCP server in an Active Directory environment without first authorizing the server.

For a DHCP server that is not a member of the Active Directory domain, the DHCP Server service sends a broadcast DHCPInform message to request information about the root Active Directory domain in which other DHCP servers are installed and configured. Other DHCP servers on the network respond with a DHCPAck message, which contains information that the querying DHCP server uses to locate the Active Directory root domain. The starting DHCP server then queries Active Directory for a list of authorized DHCP servers and starts the DHCP Server service only if its own address is in the list.

How Authorization Works

The authorization process for DHCP server computers depends on the installed role of the server on your network. There are three roles or server types for which each server computer can be installed:

  • Domain controller -- The computer keeps and maintains a copy of the Active Directory database and provides secure account management for domain member users and computers.

  • Member server -- The computer is not operating as a domain controller but has joined a domain in which it has a membership account in the Active Directory database.

  • Stand-alone server -- The computer is not operating as a domain controller or a member server in a domain. Instead, the server computer is made known to the network through a specified workgroup name, which can be shared by other computers, but is used only for computer browsing purposes and not to provide secured logon access to shared domain resources.

If you deploy Active Directory, all computers operating as DHCP servers must be either domain controllers or domain member servers before they can be authorized and provide DHCP service to clients.

Although it is not recommended, you can use a stand-alone server as a DHCP server as long as it is not on a subnet with any authorized DHCP servers. When a stand-alone DHCP server detects an authorized server on the same subnet, it automatically stops leasing IP addresses to DHCP clients.

Additional Resources

For a list of Help topics providing related information, see Recommended tasks for the DHCP server role.


Enforce network access policies for client health by configuring DHCP with Network Access Protection

Network Access Protection (NAP) is a platform that provides policy enforcement components that help ensure that computers connecting to or communicating on a network comply with administrator-defined requirements for system health. Using DHCP NAP, you can choose to limit the access of computers that do not meet requirements to a restricted network. The restricted network contains resources needed to update computers so that they meet the health requirements for unlimited network access and normal communication.

With DHCP enforcement, a computer must be compliant to obtain an unlimited access IP address configuration from a DHCP server. For noncompliant computers, network access is limited by an IP address configuration that allows access only to the restricted network. DHCP enforcement enforces health policy requirements every time a DHCP client attempts to lease or renew an IP address configuration. DHCP enforcement also actively monitors the health status of the NAP client and renews the IPv4 address configuration for access only to the restricted network if the client becomes noncompliant.

How DHCP Enforcement Works

The following process describes how DHCP enforcement works for a NAP client that is attempting an initial DHCP configuration:

  1. The NAP client sends a DHCP request message containing its health state information to the DHCP server.

  2. The DHCP server sends the health state information of the NAP client to the NAP health policy server.

  3. The NAP health policy server evaluates the health state information of the NAP client, determines whether the NAP client is compliant, and sends the results to the NAP client and the DHCP server. If the NAP client is not compliant, the results include a limited access configuration for the DHCP server and health remediation instructions for the NAP client.

  4. If the health state is compliant, the DHCP server assigns an IP address configuration for unlimited access to the NAP client and completes the DHCP message exchange.

  5. If the health state is not compliant, the DHCP server assigns an IPv4 address configuration for limited access to the restricted network to the NAP client and completes the DHCP message exchange. The NAP client can send traffic only to the remediation servers on the restricted network.

  6. The NAP client sends update requests to the remediation servers.

  7. The remediation servers provision the NAP client with the required updates for compliance with health policy. The NAP client updates its health state information.

  8. The NAP client sends a new DHCP request message containing its updated health state information to the DHCP server.

  9. The DHCP server sends the updated health state information of the NAP client to the NAP health policy server.

  10. Assuming that all the required updates were made, the NAP health policy server determines that the NAP client is compliant and instructs the DHCP server to assign an IPv4 address configuration for unlimited access to the intranet.

  11. The DHCP server assigns an IP address configuration for unlimited access to the NAP client and completes the DHCP message exchange.

Additional Resources

For a list of Help topics providing related information, see Recommended tasks for the DHCP server role.

For updated detailed IT pro information about DHCP, see the Windows Server® 2008 documentation on the Microsoft TechNet Web site.


Automate management of devices that have static IP addresses by creating DHCP reservations

You can use a client reservation to ensure that a DHCP client computer always receives the same IP address lease at startup. If you have more than one DHCP server that can be reached by a reserved client, add the reservation at each of your other DHCP servers. This practice allows the other DHCP servers to honor the client IP address reservation made for the reserved client. Although the DHCP server will act upon the client reservation when the reserved address is part of the available address pool, having the same reservation for the same client on multiple servers will not usually cause any problems.

If you are reserving an IP address for a new client, or an address that is different from its current one, you should verify that the address has not already been leased by the DHCP server. Reserving an IP address in a scope does not automatically force a client currently using that address to stop using it.

If the address is already in use, the client using the address must first release is by issuing a DHCP release message (DHCPRELEASE). To make this happen, at the command prompt of a client computer, type ipconfig /release.

Reserving an IP address at the DHCP server also does not force the new client for which the reservation is made to immediately move to that address. In this case, too, the client must first issue a DHCP request message (DHCPREQUEST). To make this happen, at the command prompt of a client computer, type ipconfig /renew.

For clients using Windows 95 or Windows 98, you can use the Winipcfg.exe program to cause release or renewal of the reserved IP address in DHCP. For clients using MS-DOS, and some clients using other operating systems, a computer must be restarted for the change to take effect.

Once these changes are made, the reserved client is leased the IP address now reserved for its permanent use each time it renews its lease with the DHCP server.

Note

Reserved clients can have DHCP options configured specifically for their use. When options are configured for a reserved client, these values override any option type parameters distributed via server-based, scope-based, or class-based options assignment.

Note

You can create reservations 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 all addresses in the scope are excluded (80% at one server, 20% at the other), reservations still function properly.

You can use this procedure to add a client reservation.

Membership in the Domain Admins group, or equivalent, is the minimum required to complete this procedure.

To add a client reservation

  1. Open DHCP.

  2. In the console tree, click Reservations.

  3. On the Action menu, click New Reservation.

  4. In New Reservation, type the information required to complete the client reservation.

  5. To add the client reservation to the scope, click Add.

  6. Repeat the previous two steps for any other client reservations you want to add, and then click Close.

Additional Resources

For a list of Help topics providing related information, see Recommended tasks for the DHCP server role.

For updated detailed IT pro information about DHCP, see the Windows Server® 2008 documentation on the Microsoft TechNet Web site.


Support multiple subnets with one DHCP server by configuring DHCP relay agents

A relay agent is a small program that relays DHCP/BOOTP messages between clients and servers on different subnets. DHCP/BOOTP relay agents are part of the DHCP and BOOTP standards and function according to the Request for Comments (RFCs), standard documents that describe protocol design and related behavior.

In TCP/IP networking, routers are used to interconnect hardware and software used on different physical network segments called subnets and forward IP packets between each of the subnets. To support and use DHCP service across multiple subnets, routers connecting each subnet should comply with DHCP/BOOTP relay agent capabilities described in RFC 1542.

To be compliant with RFC 1542 and provide relay agent support, each router must be able to recognize BOOTP and DHCP protocol messages and process (relay) them appropriately. Because routers interpret DHCP messages as BOOTP messages (such as a UDP message sent through the same UDP port number and containing shared message structure), a router with BOOTP-relay agent capability typically relays DHCP packets and any BOOTP packets sent on the network.

If a router cannot function as a DHCP/BOOTP relay agent, each subnet must have either its own DHCP server or another computer that can function as a relay agent on that subnet. In cases where it is impractical or impossible to configure routers to support DHCP/BOOTP relay, you can configure a computer running Windows Server® 2008 to act as a relay agent by installing the DHCP Relay Agent service.

In most cases, routers support DHCP/BOOTP relay. If your routers do not, contact your router manufacturer or supplier to find out if a software or firmware upgrade is available to support this feature.

Additional Resources

For a list of Help topics providing related information, see Recommended tasks for the DHCP server role.


Avoid reconfiguring DHCP on a new server by migrating an existing DHCP infrastructure

You can move a DHCP database from one server computer (the source server) to another server computer (the destination server). To accomplish the migration of the DHCP database, first backup the source database and then restore the database on the destination DHCP server.

For more information, see More About DHCP Backup and Restore and More About Exporting and Importing the DHCP Database

Additional Resources

For a list of Help topics providing related information, see Recommended tasks for the DHCP server role.

For updated detailed IT pro information about DHCP, see the Windows Server® 2008 documentation on the Microsoft TechNet Web site.


Balance the load on your DHCP servers by using the 80/20 rule for scopes

You can use the 80/20 design rule for balancing scope distribution of addresses where multiple DHCP servers are deployed to service the same scope.

Using more than one DHCP server on the same subnet provides increased fault tolerance for servicing DHCP clients located on it. With two DHCP servers, if one server is unavailable, the other server can take its place and continue to lease new addresses or renew existing clients.

A common practice when balancing a single network and scope range of addresses between two DHCP servers is to have 80 percent of the addresses distributed by one DHCP server and the remaining 20 percent provided by a second.

Additional Resources

For a list of Help topics providing related information, see Recommended tasks for the DHCP server role.

For updated detailed IT pro information about DHCP, see the Windows Server® 2008 documentation on the Microsoft TechNet Web site.


Centralize management of two or more DHCP servers as a single system by clustering DHCP servers

The DHCP Server service is a cluster-aware application. You can implement additional DHCP (or MADCAP) server reliability by deploying a DHCP server cluster using the Cluster service.

By using clustering support for DHCP, you can implement a local method of DHCP server failover, achieving greater fault tolerance. You can also enhance fault tolerance by combining DHCP server clustering with a remote failover configuration, such as by using a split scope configuration.

Requirements for setting up a DHCP clustered resource

The DHCP Server service, when used in a server cluster, requires the following resource types:

  • Disk

  • IP address

  • Name

In this type of configuration, a virtual IP address is defined for the IP address resource using the Cluster Administrator tool. This address must be a static IP address, not one obtained from another DHCP server.

The DHCP Server service then binds to this virtual IP address. This IP address must then be used to authorize the DHCP Server service in Active Directory so it can function correctly and service clients on the network.

Once the virtual IP is set using cluster configuration, each network adapter installed on each node (that is, a server in the cluster) needs an IP address configuration. Because the DHCP Server service does not bind to adapter IP addresses, you can either provide them through DHCP or configure them statically. If you use static configuration, the IP addresses for each linked pair of network adapters (linked node-to-node) should be from the same subnet.

Addresses that are statically configured using TCP/IP properties from Network Center can also be viewed through server bindings properties in the DHCP console. However, for a DHCP server cluster, the bindings information that appears in these views does not correspond to the virtual IP address used for the server cluster. Therefore, these settings do not apply.

When a scope is created for a DHCP clustered server, the virtual IP addresses used in the cluster context must be excluded so that they are not distributed to clients. Additionally, you should configure the database path, audit log file path, and the database backup path using the Cluster Administrator tool on the shared disk.

Note

The Jet database upon which the DHCP Server service relies is not cluster aware. If the clustered DHCP database becomes inaccessible to the DHCP Server service, the service will report thousands of ESENT application log errors, and DHCP service by the cluster will be interrupted.

Note

If you need only to remotely manage DHCP server clusters that are deployed on remote computers, you can use Cluster Administrator to do this.

Additional Resources

For a list of Help topics providing related information, see Recommended tasks for the DHCP server role.


More About DHCP Backup and Restore

Maintaining a backup of the Dynamic Host Configuration Protocol (DHCP) database protects you from data loss if the DHCP database is lost (for example, due to hard disk failure) or becomes corrupted. There are three backup methods supported by the DHCP Server service:

  • Synchronous backups that occur automatically. The default backup interval is 60 minutes. You can change the backup interval by editing the following registry entry:

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DHCPServer\Parameters\BackupInterval

    Caution

    Incorrectly editing the registry might severely damage your system. Before making changes to the registry, you should back up any valued data on the computer.

  • Asynchronous (manual) backups that are performed by using the backup command on the DHCP console.

When a synchronous or asynchronous backup occurs, the entire DHCP database is saved, including the following:

  • All scopes, including superscopes and multicast scopes

  • Reservations

  • Leases

  • All options, including server options, scope options, reservation options, and class options

  • All registry keys and other configuration settings (for example, audit log settings and folder location settings) set in DHCP server properties. These settings are stored in the following registry subkey:

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DHCPServer\Parameters

Note

The Domain Name System (DNS) dynamic update credentials (user name, domain, and password) that the DHCP server uses when registering DHCP client computers in DNS are not backed up with any backup method.

Backup locations

This topic assumes that the DHCP database and its backup directories are located on the default drive and path locations. The default DHCP database backup path is %systemroot%\System32\Dhcp\Backup. You can change the database backup folder by selecting a different local folder during a manual backup or by changing the backup folder location in DHCP server properties.

When planning your backup strategy, consider the following:

  • Synchronous backups are performed while the DHCP service is running. Similarly, when you perform asynchronous (manual) backups, you do not need to stop the DHCP service unless you are moving your database to a new server.

  • The DHCP database backup folder location must be a local path.

  • Do not store DHCP server backups on the same hard drive on which the DHCP service is installed, and make sure that the access control list (ACL) for the backup folder contains only the Administrators group and the DHCP Administrators group as members. In addition to performing manual backups, back up to other locations, such as a tape drive, and make sure that unauthorized persons do not have access to your backup copies. You can use Windows Backup for this purpose.

Membership in the Administrators group or the DHCP Administrators group on the DHCP server is the minimum required to complete this procedure.

To back up the DHCP database

  1. Open the DHCP Microsoft Management Console (MMC) snap-in.

  2. In the console tree, click the DHCP server you want to configure.

  3. On the Action menu, click Backup.

  4. In the Browse For Folder dialog box, select the folder where you want to store the backup DHCP database, and then click OK.

Additional considerations

When you store a manually created backup of the DHCP database in the same location as the synchronous backup that the DHCP server creates every 60 minutes, the manual backup is overwritten when automatic backup occurs.

Restoring the DHCP database

Restoring the DHCP server database is useful in situations where the database has either become corrupted or lost. In order to successfully restore the database, you need to back up the database on a regular basis. By default, DHCP performs synchronous backups at a 60 minute interval to the %systemroot%\System32\Dhcp\Backup folder, but you can also perform manual backups, or use backup software to copy the database to other locations.

You can restore the DHCP database from a backup copy of the database file, Dhcp.mdb, by using the Restore command on the Action menu in the DHCP snap-in. When you restore the DHCP database from a backup copy of Dhcp.mdb, the following information is configured on the server:

  • All scopes, including superscopes and multicast scopes

  • Reservations

  • Leases

  • All options, including server options, scope options, reservation options, and class options

  • All registry keys and other configuration settings (for example, audit log settings and folder location settings) set in DHCP server properties.

Note

The DNS dynamic update credentials (user name, domain, and password) that the DHCP server uses when registering DHCP client computers in DNS are not backed up with any backup method, therefore they are not restored during the restore procedure. After restoring your DHCP database, configure credentials for your server and also set the state of the server.

Membership in the Administrators group or the DHCP Administrators group on the DHCP server is the minimum required to complete this procedure.

To restore the DHCP database

  1. Open the DHCP snap-in.

  2. In the console tree, click the DHCP server you want to configure.

  3. On the Action menu, click Restore.

  4. In the Browse For Folder dialog box, select the folder that contains the backup DHCP database, and then click OK.
Notes
  • To restore the DHCP database, the DHCP service is temporarily stopped. When it is stopped, DHCP clients cannot contact the DHCP server and obtain IP addresses.
  • Only DHCP databases from the same language version can be restored. For example, a DHCP database from a DHCP server running an English language version of the operating system cannot be restored to a DHCP server running a Japanese language version of the operating system.

You can also use this procedure to move a DHCP database from one server computer (the source server) to another server computer (the destination server).

Additional Resources

For a list of Help topics providing related information, see Recommended tasks for the DHCP server role.


More About Exporting and Importing the DHCP Database

You can use this procedure to move a DHCP database from one server computer (the source server) to another server computer (the destination server).

Membership in the Administrators group or the DHCP Administrators group on the source and destination DHCP servers is the minimum required to complete this procedure.

To move a DHCP database and configuration from a server that is running Windows Server 2003 to another server that is running Windows Server 2008 R2

  1. Log on to the source DHCP server.

  2. Click Start, click Run, type cmd in the Open box, and then click OK.

  3. On the Action menu, click Backup.

  4. Type netsh dhcp server export C:\dhcp.txt all, and then press ENTER.

  5. Install the DHCP server service on the destination DHCP server. For more information about installing DHCP, see Installing the DHCP Server Role.

  6. Log on to the destination DHCP server.

  7. Copy the exported DHCP database file to the local hard disk of the destination DHCP server.

  8. Verify that the DHCP service is started on the destination DHCP server.

  9. Click Start, click Run, type cmd in the Open box, and then click OK.

  10. Open DHCP.

  11. In the console tree, click DHCP.

  12. On the Action menu, click Authorize.

Additional Resources

For a list of Help topics providing related information, see Recommended tasks for the DHCP server role.


More About DHCP Security Groups

When you install the DHCP Server service, two domain local groups are created: DHCP Users and DHCP Administrators.

In versions of Windows prior to Windows Server 2008 R2, the Dynamic Host Configuration Protocol (DHCP) service ran in the Local System account and had privileges to create the groups in the Security Accounts Manager (SAM) database. The DHCP Server service in Windows Server 2008 R2 has been moved to the Network Service account, which has reduced privileges and cannot create the security accounts. To facilitate adding security groups and setting access control lists (ACLs), DHCP uses an application programming interface (API) called DhcpAddSecurityGroups. This API is implemented in Dhcpsapi.dll and the Role Management Tool starts this API after the DHCP Server server role installation is done.

DHCP Users group

Members of the DHCP Users group have read-only access to the server by using the DHCP Microsoft Management Console (MMC) snap-in, which allows them to view, but not to modify, server data, including DHCP server configuration, registry keys, DHCP log files, and the DHCP database. DHCP Users cannot create scopes, modify option values, create reservations or exclusion ranges, or modify the DHCP server configuration in any other way.

DHCP Administrators group

Members of the DHCP Administrators group can view and modify any settings on the DHCP server. DHCP Administrators can create and delete scopes, add reservations, change option values, create superscopes, or perform any other task required to administer the DHCP server, including export or import of the DHCP server configuration and database.

Members of the DHCP Administrators group do not have unlimited administrative rights. For example, if a DHCP server is also configured as a Domain Name System (DNS) server, a member of the DHCP Administrators group can view and modify the DHCP configuration but cannot modify DNS server configuration on the same computer.

Because members of the DHCP Administrators group have rights on the local computer only, DHCP Administrators cannot authorize or unauthorize DHCP servers in Active Directory Domain Services (AD DS). Only members of the Domain Admins group can perform this task. If you want to authorize or unauthorize a DHCP server in a child domain, you must have enterprise administrator credentials for the parent domain.

Note

To log on as an enterprise administrator, you must use a member account in the Enterprise Admins group. You can join this group by logging on as local administrator at the first domain controller created in your enterprise.

Additional Resources

For a list of Help topics providing related information, see Recommended tasks for the DHCP server role.


Distribute DHCP Leases Based on MAC Address

Link layer filtering provides network access control for the issuance or denial of DHCP leases of IP addresses based on a media access control (MAC) address. Link layer filtering can be configured at the IPv4 node for all clients across all IPv4 scopes. This feature is currently available only for IPv4 networks.

To enable MAC address filtering

  1. Open the DHCP Microsoft Management Console (MMC) snap-in.

  2. In the console tree, double-click the DHCP server you want to configure, right-click IPv4, and then click Properties.

  3. Click Filters, and then select the Enable Allow List or the Enable Deny List check box.
To configure a new filter

  1. Open the DHCP snap-in.

  2. In the console tree, double-click the applicable DHCP server, double-click IPv4, double-click Filters, and then right-click Allow or Deny.

  3. Click New Filter, and then type a MAC Address and Description. Description is an optional field.
Notes
  • The MAC address can either be the full address or a MAC address pattern (wild card). Following are the valid MAC address wild cards:
    • 00-1C-23-*-*-*

    • 00-1C-23-20-AF-*

    • 00-1C-23-20-*-*

    • 001C2320AF4E

    • 001C*

Note

Deny filters supersede Allow filters.

To edit the hardware type exempted from filtering list

  1. Open the DHCP snap-in.

  2. In the console tree, double-click the DHCP server you want to configure, right-click IPv4, and then click Properties.

  3. Click Filters, click Advanced, and then select or clear the check boxes for the hardware types you want to edit.

Additional Resources

For a list of Help topics providing related information, see Configuring DHCP Server Role Settings.


Prevent Name Squatting with Name Protection

Name squatting occurs when a non-Windows-based computer registers in Domain Name System (DNS) with a name that is already registered to a Windows-based computer. The use of name protection in Windows Server prevents name squatting by non-Windows-based computers. Name squatting does not present a problem on a homogeneous Windows network where Active Directory Domain Services (AD DS) can be used to reserve a name for a single user or computer.

Name protection is based on the Dynamic Host Configuration Identifier (DHCID) in the Dynamic Host Configuration Protocol (DHCP) server, and support for the new DHCID RR (resource record) in DNS. DHCID RR is described by the Internet Engineering Task Force (IETF) in RFCs 4701 and 4703.

DHCID is a resource record (RR) stored in DNS that maps names to prevent duplicate registration. This RR is used by DHCP to store an identifier for a computer, along with other information for the name such as the A/AAAA records of the computer. The unique position of DHCP in the name registration process allows it to request this match, and then refuse the registration of a computer with a different address attempting to register a name with an existing DHCID record.

DHCID prevents the following name squatting situations:

  • Server name squatting by a client

  • Server name squatting by another server

  • Client name squatting by another client

  • Client name squatting by a server

In addition, support for DHCP Unique Identifier (DUID) will be added to the IPv4 registration on the DHCP client. DUID is described by the IETF in RFC 4361.

Name protection can be configured for IPv4 and IPv6 at the network adapter level or scope level. Name protection settings configured at the scope level take precedence over the setting at the IPv4 or IPv6 level. If Name protection at the scope level is not configured at all, then the setting at the IPv4 or IPv6 network adapter takes precedence. DHCID protects names on a first come-first served basis.

To enable name protection at the IPv4 or IPv6 node level

  1. Open the DHCP Microsoft Management Console (MMC) snap-in.

  2. In the console tree, double-click the DHCP server you want to configure, right-click IPv4 or IPv6, and then click Properties.

  3. Click DNS, click Advanced, and then check Enable Name Protection.
To enable name protection at the scope level

  1. Open the DHCP console.

  2. In the console tree, double-click the DHCP server you want to configure, double-click IPv4 or IPv6, right-click the scope you want, and then click Properties.

  3. Click DNS, click Configure, and then check Enable Name Protection.

Additional Resources

For a list of Help topics providing related information, see Recommended tasks for the DHCP server role.


More About DHCP Audit and Event Logging

You can use this procedure to enable Dynamic Host Configuration Protocol (DHCP) server logging.

Membership in the Administrators or DHCP Administrators group is the minimum required to complete this procedure.

To enable DHCP server logging

  1. Open the DHCP Microsoft Management Console (MMC) snap-in.

  2. In the console tree, click the DHCP server you want to configure.

  3. On the Action menu, click Properties.

  4. On the General tab, select Enable DHCP audit logging, and then click OK.

Analyzing server log files

In Windows Server 2008, DHCP server log files are configured to manage log file growth and conserve disk resources by default. DHCP audit logs are located by default at %windir%\System32\Dhcp.

The following section outlines the format of these log files and how they can be used to gather more information about DHCP Server service operations on the network.

DHCP server log file format

DHCP server logs are comma-delimited text files with each log entry representing a single line of text. Following are the fields (and the order in which they appear) in a log file entry:

ID, Date, Time, Description, IP Address, Host Name, MAC Address

Each of these fields is described in detail in the following table:

Field | Description
ID | A DHCP server event ID code.
Date | The date on which this entry was logged on the DHCP server.
Time | The time at which this entry was logged on the DHCP server.
Description | A description of this DHCP server event.
IP Address | The IP address of the DHCP client.
Host Name | The host name of the DHCP client.
MAC Address | The media access control (MAC) address used by the network adapter hardware of the client.

DHCP server log: Common event codes

DHCP server audit log files use reserved event ID codes to provide information about the type of server event or activity logged. The following table describes these event ID codes in more detail.

Event ID | Description
00 | The log was started.
01 | The log was stopped.
02 | The log was temporarily paused due to low disk space.
10 | A new IP address was leased to a client.
11 | A lease was renewed by a client.
12 | A lease was released by a client.
13 | An IP address was found in use on the network.
14 | A lease request could not be satisfied because the address pool of the scope was exhausted.
15 | A lease was denied.
20 | A Bootstrap Protocol (BOOTP) address was leased to a client.

DNS dynamic update events

When the DHCP server is configured to perform Domain Name System (DNS) dynamic updates on behalf of DHCP clients, you can use the DHCP audit logs to monitor update requests by the DHCP server to the DNS server, DNS record update successes, and DNS record update failures. The following event IDs are used for DNS dynamic update events:

Event ID | Description
30 | DNS dynamic update request
31 | DNS dynamic update failed
32 | DNS dynamic update successful

The IP address of the DHCP client computer is included in the DHCP audit log so you can track the source in the event of a denial-of-service attack.

DHCP server logs: Server authorization events

The following are additional server log event ID codes and descriptions. These events can appear in logs made by DHCP servers running Windows Server 2008. They pertain to the specific DHCP server and its authorization status when deployed in Active Directory Domain Services (AD DS) environments.

Event ID Description

50

Unreachable domain

The DHCP server did not locate the specific domain for its configured Active Directory installation.

51

Authorization succeeded

The DHCP server was authorized to start on the network.

52

Upgraded to a Windows Server 2008 operating system

The DHCP server was recently upgraded to a Windows Server 2008 operating system, and, therefore, the unauthorized DHCP server detection feature (used to determine whether the server has been authorized in AD DS) was disabled.

53

Cached Authorization

The DHCP server was authorized to start using previously cached information. AD DS could not be found at the time the server was started on the network.

54

Authorization failed

The DHCP server was not authorized to start on the network. When this event occurs, it is likely followed by the server being stopped.

55

Authorization (servicing)

The DHCP server was successfully authorized to start on the network.

56

Authorization failure, stopped servicing

The DHCP server was not authorized to start on the network and was shut down by the operating system. You must first authorize the server in AD DS before starting it again.

57

Server found in domain

Another DHCP server exists and is authorized for service in the same domain.

58

Server did not find domain

The DHCP server did not locate the specified domain.

59

Network failure

A network-related failure prevented the server from determining if it is authorized.

60

No domain controller is directory service enabled

No domain controller running Windows Server 2008 was located. For detecting whether the server is authorized, a domain controller that is enabled for AD DS is required.

61

Server found that belongs to DS domain

Another DHCP server was found on the network that belongs to the Active Directory domain.

62

Another server found

Another DHCP server was found on the network.

63

Restarting rogue detection

The DHCP server is trying again to determine whether it is authorized to start and provide service on the network.

64

No DHCP enabled interfaces

The DHCP server has its service bindings or network connections configured so that it is not enabled to provide service. This usually means one of the following:

  • The network connections of the server are either not installed or not actively connected to a network.

  • The server has not been configured with at least one static IP address for one of its installed and active network connections.

  • All of the statically configured network connections for the server are disabled.

Example: Excerpt from a sample DHCP server audit log

The following is a brief excerpt of sample log activity from an audit log generated by the DHCP Server service:

ID Date,Time,Description,IP Address,Host Name,MAC Address
00,04/19/99,12:43:06,Started,,,
60,04/19/99,12:43:21,No DC is DS Enabled,,MYDOMAIN,
63,04/19/99,12:43:28,Restarting rogue detection,,,
01,04/19/99,13:11:13,Stopped,,,
00,04/19/99,12:43:06,Started,,,
55,04/19/99,12:43:54,Authorized(servicing),,MYDOMAIN,

In this sample, the DHCP server was not authorized when initially started and is subsequently stopped. After it is authorized, the server can then restart and service clients.

Additional Resources

For a list of Help topics providing related information, see Recommended tasks for the DHCP server role.