Source: http://www.windowsnetworking.com/articles-tutorials/windows-server-2012/windows-server-2012-dhcp-part1.html
Dynamic host configuration protocol (DHCP) is one of the most commonly implemented network services in today’s network environments. In this article we will review the deployment and configuration of the DHCP server role in Windows Server 2012. We will revise the DHCP leasing process, DHCP options, DHCPv4 and DHCPv6 scopes, and auto configuration.

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

Figure 11

Figure 12

Figure 13

Figure 14

Figure 15

Figure 16

Figure 17

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8
Dynamic host configuration protocol (DHCP) is one of the most commonly implemented network services in today’s network environments. In this article we will review the deployment and configuration of the DHCP server role in Windows Server 2012. We will revise the DHCP leasing process, DHCP options, DHCPv4 and DHCPv6 scopes, and auto configuration.
The Case for DHCP
DHCP is primarily used to automatically distribute critical IP configuration settings to network clients, eliminating the tedious and burdensome task of manually configuring hosts on TCP/IP-based networks. It also provides configuration information and interacts with other networking services such as domain name system (DNS), windows deployment services (Windows DS) and network access protection (NAP).
Without DHCP service, you have to individually configure each network client with the correct internet protocol settings, including the IP address, the network’s subnet mask, the default gateway, and the DNS server address. These settings are necessary for the network clients to communicate within and outside their network locations. You have to repeat this manual configuration process any time you bring a new device to the network or you move one to a different subnet.
Many organizations manage hundreds or thousands of network client devices, including smart phones, tablets, desktop computers, and laptops. The DHCP service helps to ensure that all network clients have correct configuration settings, eliminating fat fingers and other human errors that may occur when we have to enter the information manually. Network configuration changes can be updated on the DHCP server without having to change the information directly on each client computer.
DHCP Server Authorization
In an active directory infrastructure, to prevent an incorrectly configured DHCP server or a rogue DHCP server from distributing IP addresses, DHCP servers are not allowed to start servicing clients before they are authorized to operate in the network. DHCP authorization is the process of registering the DHCP Server in the active directory database to service DHCP clients. An enterprise administrator account is necessary to authorize Windows Server 2012 DHCP servers; once it is authorized, the DHCP server can support multiple domains in the same active directory forest.
A standalone (no domain member) Windows Server 2012 DHCP server can detect an authorized DHCP server in a domain. When that happens, the standalone DHCP server does not lease IP addresses and shuts down automatically.
Deploying the DHCP Server Role
These are the steps necessary to add the DHCP server role to a Windows Server 2012 computer:
- In Server Manager, click Add roles and features.

Figure 1
- In the Add Roles and Features Wizard, click Next.

Figure 2
- On the Select installation type page, click Next.

Figure 3
- On Select destination server page, click Next.

Figure 4
- On the Select server roles page, select the DHCP Server check box.

Figure 5
- In the Add Roles and Features Wizard, click Add Features, and then click Next.

Figure 6
- On the Select features page, click Next.

Figure 7
- On the DHCP Server page, click Next.

Figure 8
- On the Confirm installation selections page, click Install.

Figure 9
- On the Installation progress page, wait until the Installation succeeds.

Figure 10
Once the installation completes, you can proceed to authorize the DHCP server or start configuring the DHCP scopes.
DHCPv4 Scopes
By configuring DHCP scopes, you make IP addresses available to the DHCP clients. A DHCP scope is a pool or range of IP addresses that are available for lease from the DHCP server. Usually a DHCP scope is limited to the IP addresses in a prearranged IP subnet. DHCP scopes must be activated before their IP addresses become available in the network.
On Windows Server 2012, you configure a DHCP scope along with the following settings:
Name and description. This is used to identify the scope. The name is mandatory, the description is optional.
IP address range. This is the starting pool of IP addresses that are available for lease. This pool usually lists the entire range of addresses for a defined IP subnet.
Subnet mask. This property provides space to configure the bit length and the decimal notation for the subnet mask.
Both fields are automatically filled when you enter the IP address range. You may need to change those values when using non default class A, B, or C networks. The subnet mask is used to separate the network ID from the host ID component in the IP address; this allows TCP/IP hosts to determine their location in the network.
Exclusions. Here you list single addresses or range of addresses that belong to the IP address pool, but that will not be offered for lease usually because they have been manually assigned to servers in the network. For example, if the DHCP server is deployed to the same subnet, it will need at least one IP address from the pool. That IP address should be excluded from the scope.
Subnet Delay. This is the amount of time in milliseconds that the DHCP server waits before sending a DHCPOFFER. The default value is 0; when having two DHCP servers servicing the same IP subnet, you may change the default settings on your lower-priority DHCP server by increasing the subnet delay value.
Lease duration. This is the amount of time for which clients are allowed to use the IP addresses without renewal. It is recommended to use shorter durations for scopes with limited IP addresses or a significant number of mobile clients, and longer durations for more static networks.
DHCP Reservations:
A DHCP reservation is a given IP address from within a scope that is set aside for lease to a specific DHCP client. DHCP reservation ensures that the IP addresses that you reserve from a configured scope are not leased to any other device in the network. A DHCP reservation also ensures that devices with reservations are certain to have their IP address even if a scope runs out of available IP addresses. The device’s network interface media access control (MAC) address or physical address is necessary to configure a reservation. If the client is already leasing an IP address from a Windows Server 2012 DHCP server, its MAC address will be available from the DHCP management console.
DHCP Options:
DHCP options are configuration settings that are applied to the DHCP clients when they lease or renew their IP addresses from a DHCP server. An option code identifies the DHCP options; many DHCP options are available, among the most common ones are:
- * Option 003 – Router (the default gateway for the subnet)
- * Option 006 – Domain Name System (DNS) servers
- * Option 015 – DNS suffix
On a Windows Server 2012, you can configure DHCP options at the server, scope, reserved client, and class levels. When troubleshooting the DHCP service, it is critically important that you understand the order in which DHCP applies these options to client computers. DHCP options are applied in the following order:
- Server level. A server-level option is assigned to all DHCP clients of the DHCP server. Server options can be superseded by scope, class, and client-assigned options.
- Scope level. These settings are applied to clients that obtain a lease within that specific scope. Scope options consistently apply to all computers acquiring a lease from a given scope unless they are superseded by class or reserved client options.
- Class level. Client class can be user-defined or vendor-defined. A class-level option is assigned to all clients that identify to the DHCP server as members of a class. Class options can be superseded by reserved client level options.
- Reserved client level. This is a reservation-level option that is assigned to one DHCP client. If DHCP option settings are configured at each level and they conflict, then the option that is applied last overrides the previously applied setting. Because the reserved client options are the last one to apply, they will override all the previous levels in case of conflicting settings.
DHCP Lease Generation Process
Understanding the steps involved in the lease and renewal of IP addresses helps you troubleshoot problems when clients cannot obtain their configuration from a DHCP server. There are four steps in the DHCP lease process:
- DHCPDISCOVER. The DHCP client broadcasts a DHCPDISCOVER packet in the subnet. All computers in the subnet receive this packet; however, only the DHCP server responds. If there is no DHCP server in the subnet, then a computer or router configured as DHCP Relay agent forwards the message to a DHCP server located in another subnet
- DHCPOFFER. All DHCP servers that receive the client DHCPDiscover packet reply with a DHCPOffer packet. This packet contains IP configuration settings including an available IP address and subnet mask.
- DHCPREQUEST. The client might receive DHCPOFFER packets from more than one DHCP server; if that is the case, the DHCP client typically selects the DHCP server that responded first to its DHCPDISCOVER packet. The client then broadcasts a DHCPREQUEST identifying the DHCP server from which is willing to lease the IP settings. This broadcast reaches all other the DHCP servers so they know which server’s DHCPOFFER the client has accepted.
- DHCPACK. The selected DHCP server stores the IP address client information in the DHCP database and sends back a DHCPACK message and any optional configuration parameters. It is possible for the DHCP server to send a DHCPNAK message; this may happen if the IP address is invalid or it is being used by another computer. In this case the client begins the lease process again.
DHCP clients try to renew their leases after every reboot or startup. This is a great feature, especially for mobile devices since users may move their laptops or tables to different locations or subnets and those devices can automatically obtain the right IP configuration to operate in the new environment. The lease period is reset after each renewal. You can force a renewal by executing the following command: ipconfig /renew. If a device stays on, it will attempt to renew its lease when 50% of its lease time has elapsed. This is a transparent background process in which the DHCP client broadcasts a DHCPREQUEST message. If the DHCP server that leased the IP addresses is available, it will send a DHCPACK message back to the client. If some options have changed since the original lease, the DHCP server includes the new values with the DHCPACk message.
If the DHCP client cannot talk with the DHCP server, then the client waits until 87.5 percent of the lease time passes and then tries to renew again. If 100 percent of the lease time has expired and the renewal is unsuccessful, the client goes into autoconfiguration mode.
DHCPv4 Autoconfiguration
If a DHCP server is not available and the previous lease has expired, the client computer executes an automatic private IP addressing (APIPA) process to assign itself a valid IPv4 address from the 169.254.0.0 subnet with a mask of 255.255.0.0. Before it starts using the new IPv4 address, the client performs an address resolution protocol (ARP) test to ensure that the selected IP address is not being used by any other client in that network. After it configures itself with its new APIPA address, the client keeps sending broadcasts every five minutes to the network, trying to contact a DHCP server. Whenever a DHCP server responds, the client negotiates a new lease, and configures the NIC with the new IPv4 address obtained from the DHCP server.
DHCPv6 Scopes
On Windows Server 2012, DHCPv6 scopes are created and configured separately from IPv4 scopes. Let’s review the step-by-step configuration of a DHCPv6 scope.
- On the DHCP Server console, right click IPv6 and select New Scope.

Figure 11
- On the Welcome to the New Scope Wizard, click Next

Figure 12
- On the Scope Name, enter Name and Description information.

Figure 13
- On the Scope Prefix, enter the corresponding prefix for your IPv6 network. If you have multiple DHCPv6 servers, the preference value can be modified to indicate your priority among the servers. The lower this value, the higher the priority.

Figure 14
- On the Add Exclusions, enter any IPv6 address that belongs to that scope but has been manually assigned to other devices in the network. This includes the IPv6 address that is manually configured on the DHCPv6 server itself. Additional exclusion can be added after the initial DHCPv6 scope has been configured.

Figure 15
- On the Scope Lease, configure two settings:
- Preferred Life Time is the length of time that a valid IPv6 address is preferred. When this time expires, the address becomes deprecated but it is still valid.
- Valid Life Time is the length of time that an IPv6 is in the valid state. The address becomes invalid after the valid life time expires. The valid life rime must be equal or greater than the preferred life time.

Figure 16
- On the Completing the New Scope Wizard, click Finish to activate the scope.

Figure 17
As on IPv4 scopes, you can configure exclusions, reservations, and DHCP options on IPv6 scopes. However, DHCPv6 clients do not use their MAC addresses when contacting a DHCP server. Instead a device unique identifier (DUID) is used by clients to get an IP address from a DHCPv6 server.
DHCPv6 Autoconfiguration
IPv6 supports both stateful address configuration and stateless address configuration. Stateful address configuration happens when a DHCPv6 server assigns the IPv6 address to the DHCPv6 client in conjunction with additional DHCP configuration options.
Stateless address configuration is an autoconfiguration process by which IPv6 clients assign themselves IPv6 address without ever talking to a DHCPv6 server. It is possible to use a combination of both. For example, you may configure your DHCPv6 client in stateless mode so that they don’t need a DHCPv6 server to obtain an IP address, but you may assign the DNS server address to the same clients using a DHCPv6 server.
Even though routers play an important role in the aotuconfiguration process of DHCPv6 clients, even without a router present, hosts in the same subnet can automatically configure themselves with IPv6 addresses based on the link-local prefix of FE80::/64; this allows the clients to communicate in the local subnet without manual configuration. Before using an auto-selected link-local unicast IPv6 address, a duplicate address detection process is performed to ensure that the select IP address is not being used by another host in the subnet. If the duplicate address detection is successful, the link-local address is initialized for the interface.
In this article we concentrated on the deployment of the DHCP server role on Windows Server 2012 and how the DHCP server scopes and autoconfiguration play an important role for IPv4 and IPv6 clients in the network. In our next article we will focus on the DHCP service availability and some of the new features on Windows Server 2012.
The DHCP Database
Guarding and maintaining the DHCP database is important for system administrators not only to provide consistent performance, but also to minimize unscheduled downtime due to unexpected server or network snags.
The DHCP database is a dynamic database that stores the DHCP configuration information and the lease data for clients that have leased an IP address from the DHCP server; this includes DHCP options, scope configuration, address leases, exclusion, and reservations. By default, the following DHCP database files are stored in the %systemroot%\System32\Dhcp folder.
* Dhcp.mdb – This is the DHCP server database file.
* Dhcp.tmp – A temporary file that the DHCP database uses as a swap file during database index maintenance operations.
* J50.log and J50#####.log – These are logs of all database transactions. These logs may be used by the DHCP server for data recovery.
* J50.chk – A checkpoint file that is updated every time data is written to the DHCP.mdb database file. This checkpoint file can be used during recovery to indicate where the recovery or replaying of data should begin.
Backup and Restore
By default, the DHCP database and associated registry entries are backed up automatically at 60-minute intervals. There is no GUI to change the backup interval; however if you want to change the default settings, you can do so in the following registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DHCPServer\Parameters
You can also back up a DHCP database manually at any time. There is no need to stop the DHCP service to perform a backup of the database. The default path for the DHCP backup is systemroot\System32\Dhcp\Backup. It is possible to modify this path in the server properties to point to another hard drive. Backing up the DHCP database over the network is not possible.
You can use the “restore” function in the DHCP server console to restore the database. When performing a restore, after you select the location, the DHCP service stops and the database is restored. You must be a member of the administrators group or the DHCP administrators group to perform a DHCP database restore.
Reconciling scopes helps to resolve inconsistencies on the DHCP database. The DHCP Server service stores detailed IP address lease information in the DHCP database and summary IP address lease information in the Windows Server registry. When you reconcile the DHCP scopes, the detail and summary entries are compared to verify inconsistencies. During this process, the DHCP service may restore those inconsistent IP addresses to the original clients, or it may set aside those IP addresses in the form of temporary reservations with duration equal to the lease time assigned to the scope.
Using DHCP Relay Agents to provide DHCP service across multiple subnets.
DHCPv4 uses IP broadcasts and DHCPv6 uses multicasts; in both cases, DHCP servers are limited to communication within their IP subnet. If your organization has a large number of subnets, you have to either deploy a DHCP server on each subnet or provide DHCP service across multiple subnets by configuring DHCP relay.
Using DHCP relay means that you configure a DHCP relay agent on each subnet where a DHCP server is not present. A DHCP relay agent is a computer or router that listens for DHCPv4 broadcasts from DHCPv4 or DHCPv6 multicast from DHCPv6 clients and then relays them to DHCP servers in different subnets. DHCPv4 and DHCPv6 need separate DHCP relay configurations. In either case however, you cannot deploy the DHCP relay agent component on a Windows Server that is running the DHCP service; the network address translation (NAT) routing protocol component with automatic addressing enabled, or Internet connection sharing (ICS).
DHCP Service Availability
Even though you may be able to service thousands of clients from a single DHCP server, it is a best practice to implement at least two DHCP servers to improve reliability and fault tolerance with the additional benefit in some cases of configuring load balancing to distribute the workload across multiple DHCP servers.
One possible approach is to configure the DHCP service using the Windows Server 2012 cluster feature or a third-party clustering solution. If one DHCP server fails, the DHCP service can fail over to another DHCP server in the cluster. In this implementation, the DHCP servers have access to a storage area network (SAN) where the DHCP database and related files are stored.
To improve availability and load balancing, there are two other Windows Server 2012 DHCP native solutions that are less complicated than deploying Windows Server clusters; they are split scopes and DHCP Failover.
DHCP Split Scopes
Split scope allows you to improve the load balancing and fault tolerance of the DHCP service by configuring two DHCP servers that serve the same subnet without IP address overlapping. This feature is only available for IPv4 and cannot be configured on IPv6 scopes.
Using a wizard-based configuration, you use two stand-alone DHCP servers to make a certain percentage of a scope’s IP addresses available on one DHCP server while the remaining IP addresses are assigned to the second DHCP server. For this to work, each DHCP server is configured with the same scope range but with different exclusions within that range. The exclusions are necessary because the DHCP servers do not share their lease database information. Each server must be configured to assign only a subset of the available IP address from a given scope.
Let’s say that you have a scope of 192.168.1.0 /24 and you want to configure a split scope using two DHCP servers: DHCP1 and DHCP2. You want to assign 70% of the IP addresses in the subnet to DHCP1 and the other 30% to DHCP2.
The DHCP scope may be configured as follows:
DHCP1 Scope configuration:
Range: 192.168.1.1 to 192.168.1.254
Exclusion: 192.168.1.178 to 192.168.1.254
Exclusion: 192.168.1.178 to 192.168.1.254
DHCP2 Scope configuration:
Range: 192.168.1.1 to 192.168.1.254
Exclusion: 192.168.1.1 to 192.168.1.177
Exclusion: 192.168.1.1 to 192.168.1.177
As part of the split-scope implementation, you need to specify the second DHCP server involved in the process. Running the Split-scope Configuration wizard on DHCP1 allows you to allocate the IP address pool in the right proportion; the wizard automatically creates the scope and the corresponding exclusions on DHCP2. You still need to activate the scope on DHCP2 before its IP addresses become available to DHCP clients in the network. The figure below show the DHCP split-scope configuration wizard being run from DHCP1.

Figure 1
It is possible to configure a time delay on the DHCP2 server (see figure below). The delay in DHCP Offer allows DHCP2 to wait before responding to DHCP DISCOVER requests from DHCP clients, permitting the DHCP1 server to respond to and accept the DHCPOFFER first. In the event that DHCP1 becomes unavailable, DHCP2 can continue distributing addresses until DHCP1 is available to service clients again.

Figure 2
In our example, DHCP1 manages 70% of the IP addresses in the 192.168.1.0 /24 subnet. This may be a problem if DHCP1 fails and stays out of service for a prolonged period of time, because DHCP2 is responsible only for 30% of the IP addresses within the scope and it could run out of assignable IP addresses quickly.
Wouldn’t it be great if DHCP2 could also manage the other 70% of the address space? How about if both DHCP1 and DHCP2 could manage 100% of the IP address range within the scope in coordination with each other? This is now possible by configuring DHCP failover on Windows Server 2012.
DHCP Failover
DHCP failover allows two Windows Server 2012 DHCP servers to share a common pool of IP addresses in which both servers can have access to 100% of the IP address range in a given scope and either one of them may assign IP addresses to network clients. As the lease information is replicated between the servers, there is no risk of duplicate IP address distribution. Because both DHCP servers are enabled to provide IP addresses and option configuration to the same subnet or scope, the availability and redundancy of the DHCP service is greatly improved.
There are some caveats worth mentioning before you get too excited about DHCP failover and try to implement it in your network. Windows Server 2012 permits only two DHCP servers for failover; this feature applies to IPv4 scopes and subnets and there is no way to configure it on IPv6 scopes. A single DHCP server can have multiple failover relationships with other DHCP servers, but each configuration must be assigned a unique name for the partnerships to work. DHCP failover is time-sensitive so time synchronization is critically important; a time difference between the partners greater than one minute will result in a critical error and the failover process will stop.
DHCP failover can be configured in two different modes: load sharing or hot standby.
In Load Sharing mode (default) both DHCP servers provide IP settings to clients concurrently. By configuring the load distribution ratio you determine your priorities on how the servers respond to IP configuration requests.
In Hot Standby mode you specify a primary DHCP server that actively dispenses IP settings for the scope or subnet and a secondary DHCP server that will only distribute IP settings if the primary server becomes unavailable. You must configure a percentage of the IP address range to be assigned to the standby server. These addresses are delivered during the maximum client lead time (MCLT) interval if the primary server is down. The secondary server takes control of the entire IP range after the MCLT interval expires.
It is important to remind you that whether you are configuring load sharing or hot standby mode, the configured scope is still shared between the two servers. In either case, if one server fails, the other DHCP server will be able to manage the whole pool of IP addresses because the lease information has been replicated all along.
Here are the steps to configure DHCP failover:
- In the DHCP console, right-click the IPv4 node, and then click Configure Failover.

Figure 3
- In the Configure Failover Wizard, click Next. Any scope that you are configuring for failover must not exist on the partner DHCP server.

Figure 4
- On the Specify a partner server to use for failover page, in the Partner Server box, enter the other DHCP server host name or IP Address.

Figure 5
- On the Create a new failover relationship page, in the Relationship Name box, enter a unique name and review and/or configure these settings before clicking Next.
- Maximum Client Lead Time (MCLT): This parameter determines the amount of time a DHCP server should wait when a partner is unavailable, before assuming control of the address range. It also specifies the amount of time for which a DHCP lease may be renewed by either failover peer without previously contacting the other.
- Mode: Load balance or standby. Load balance gives the option to assign the load balance percentage for each server. Hot standby allows you to set the role of the partner as active or standby and to allocate a percentage of addresses to the standby server.
- State switchover interval: This option specifies the time interval before a DHCP server is automatically transitioned to a “partner down” state when network communication is interrupted and the DHCP partner is no longer available. By default you must manually switch the status of a DHCP Server to a “partner down” state using the DHCP Management console or PowerShell.
- Enable Message Authentication: Use to enable or disable authentication of failover replication traffic between servers.
- Shared Secret: Enter a password to authenticate the failover connection between servers.

Figure 6
- Click Finish, and then click Close.

Figure 7
- After the wizard runs on DHCP1, we can verify that the failover scope has been created and activated on the DHCP2 server. (See figure below.)

Figure 8
Here we have used the DHCP management console to configure DHCP failover; it is possible to complete the same configuration using Windows PowerShell.
In this article we focused on the Windows Server 2012 DHCP service performance and accessibility issues. We reviewed the DHCP database maintenance, using DHCP relay agents, and the configuration alternatives to improve availability, load balancing and fault tolerance.
Listing All DHCP Servers
Want to know the DNS names and IP addresses of all DHCP servers on your network? If you're using Active Directory it's easy, just open a command prompt and type netsh dhcp show server and a list of DHCP servers authorized in AD will be displayed.
But what about rogue DHCP servers? These are not displayed, and the only way you can scan for such DHCP servers is to use a sniffer like Network Monitor to capture all DHCP broadcast traffic on your network. Leave Network Monitor running for some time however to do this since most DHCP leases are 8 days or so.
Use jetpack.exe to compress WINS and DHCP databases
WINS and DHCP use a costume version of Microsoft Access database, and like any database, it is subject to table fragmentation. This will cause a slow down. To alleviate this problem, WINS and DHCP databases need to be compressed using jetpack.exe. Microsoft recommends that this be done when the size of the db approaches 30M. Jetpack is a utility shipped with NT Server 4.0.
No comments:
Post a Comment