1.What is DHCP and how does it works. #

DHCP Technical Overview



Basic DHCP process[12]

  1. When a DHCP client connects to a network, it sends a broadcast query message to find the DHCP servers on the network.
  2. All DHCP servers on the network that receive the message and contain a valid address configuration for the client send an IP address offer back to the DHCP client.
  3. From the offers received, the client chooses an IP address configuration to use. The server that sent the offer the client selected, receives a broadcasted request message to use the selected configuration. The other DHCP servers that sent offers receive this broadcasted message, realize the request for another server, and reclaim the offered IP address.
  4. The DHCP server selected by the client, assigns the IP address configuration to the DHCP client and sends an acknowledgement message to the client to verify the acceptance.[5]

Lease Renewal

Address Allocation Policies

Generally, depending on the implementation, there are three methods for a DHCP Server to allocate IP-addresses. It is also possible to combine these methods, in a hybrid allocation policy.[7]

Manual (or Static) Allocation

The DHCP Server’s administrator manually assigns a permanent IP address to a client, usually using a MAC address for the client identifier. The subsequent client identifier/IP address pair is stored in a table. Only requesting clients in this table will be given configuration information. This method of allocation is functionally equivalent to BOOTP though the protocol is incompatible.

Dynamic Allocation

The DHCP Server’s administrator specifies a pool of IP addresses to be automatically assigned to clients for a specified limited period of time. IP address that are not renewed before the period of time ends or have their lease canceled are reclaimed and can be reallocated.[2,3]

Automatic Allocation

The DHCP Server’s administrator specifies a pool of IP addresses to be permanently assigned to clients. Upon request, a free IP address in this range is automatically assigned to a client. Once associated with a client, the IP address is permanently assigned to the client until the server’s administrator intervenes. Many DHCP Servers do not implement this method of allocation, as it can be approximated with long lease times in dynamic allocation.[2,3]

Hybrid Allocation Policies

There are various hybrid allocation possibilities with DHCP. One common one is the DHCP Server’s administrator creates a list of allowed clients without assigning them fixed IP addresses. These allowed clients can then acquire a dynamically allocated IP address whenever they connect. This allows the administrator to limit the use of DHCP without the need for manual intervention every time a client moves.[2,3]

Technical Details

DHCP Message

The basic format of a DHCP message is shown below. Most of the fields are self explanatory. The OP field defines if the message is a request or a reply. The HTYPE field specifies the network hardware type. HLEN is the length of the hardware address. The HOPS field is set to 0 by the client. If the machine receives the message and relays it to another machine, it increases the HOP count by 1. The Transaction ID contains an integer used to match responses with requests. The Seconds field is the number of seconds since the client began the address acquisition. The Flags field is used to specify if the message is broadcasted or not. The Router IP address is used for any relays between the server and client.The Boot FileName field is used for diskless embedded clients so they can download a specific memory image. The Options field is used for additional DHCP options.[8]

A DHCP Message [8]
0 8 16 2431
Transaction ID
Seconds Flags
Client IP Address
Your IP Address
Server IP Address
Router IP Address
Client Hardware Address (16 OCTETS)
Server HostName (64 OCTETS)
Boot FileName (128 OCTETS)

DHCP State Diagram

DHCP is a stateful protocol.Refer to the folowing diagram in the following explanations.

DHCP state diagram[8]

DHCP Initialization

DHCP Discovery

DHCP Offers

DHCP requests

DHCP acknowledgement

Lease Renewal

DHCP information

DHCP releasing

DHCP Options

2.DHCP Install role 2012R2 #

1. Install and Configure DHCP Server Role

To install DHCP Serve go to Dashboard on Server Manager and click Manage then click Add Rules and Features.

Server Manager Dashboard

Server Manager Dashboard

In the Role installation window select Role-based or feature-based installation the click Next.

DHCP Server Destination Server

DHCP Server Destination Server

Choose the server you want to install DHCP from the Server pool. Here we have one server and select by default.

Add DHCP Server Role

Add DHCP Server Role

From the Roles list select DHCP Server. When the Add Roles and Features Wizard Page opened, click Add Features then Click Next. That will install required features for DHCP Server.

Windows Features

Windows Features

In the Features window, do not change anything, just click Next.

DHCP Server Information

DHCP Server Information

Once read the information about DHCP Server and click Next button.

Restart automatically

Restart automatically

In the Confirm Installation page, select Restart the destination server automatically if required. Click Yes the warning window and click Install.

configure dhcp server

DHCP Installation Process

The installation will take a minute,when it has completed successfully click Complete DHCP Configuration link.

DHCP Post-Install

DHCP Post-Install

Read DHCP Post-Install configuration wizard description and click Next.

DHCP Authorization

DHCP Authorization

Set the appropriate user for management of DHCP Server. Here I leave it by default because the administrator (Shais) has the right privilege to perform DHCP Server configuration.

DHCP Summary

DHCP Summary

On the DHCP summary window clicks Close and close the DHCP Installation page also.

3.Configure DHCP Scope #

Configure DHCP Server and Create Scope

Now try to set up the installed DHCP server and create Scope to lease IP address for clients.

DCHP Management Console

DCHP Management Console

Type dhcpmgmt.msc in Windows Run and press enter to open DHCP management console.

Nov 10, 2017

Create New Scope

Create New Scope

On DHCP console window expends the domain name and IPv4.  Right, click the IPv4 the click New Scope.

New Scope Wizard

New Scope Wizard

Click Next on the New Scope Wizard page.

Scope Name and Description

Scope Name and Description

In the Scope, name defines the name of Scope and write any description then click Next.

IP Address Range

IP Address Range

Assign the start IP address range and the end IP address range. I have set from to which is a class C IP address. Leave the length 24 by default and click Next.

Add Exclusiion

Add Exclusion

Add the exclusive range prevent them from leasing to the client by DHCP Server. The IP address range which reserved is use for Network Servers and popular workstation. Here I add to  Just set the IP address and click Add button then click Next.

DHCP Lease Duration

DHCP Lease Duration

Let the Lease Duration by default and click Next.

Configure DHCP Options

Configure DHCP Options

Only click Next the Configure DHCP Options, and YesI want to configure these options now must be checked.

Router IP Address

Router IP Address

If you have a router in your network, set the router IP address and click Add button, then click Next.

Domain Name and DNS Server

Domain Name and DNS Server

Type your domain name, and it’s IP address then click Next.

WINS Servers

WINS Servers

Do nothing for WINS Servers, because we don’t use WINS Server ether. Just click Next.

Configure DHCP Server

Active Scope

In Active Scope, windows click Next. Be sure the Yes, I want to active this scope now must check.

Completing the New Scope Wizard

Completing the New Scope Wizard

Finally, click Finish to close and finalize the installation of DHCP Server in Windows Server 2012 R2.

DHCP Server

DHCP Server

Now you can assign the IP address to your network clients automatically trough this DHCP Server.

4.How to Migrate the DHCP Scope #

DHCP Scope’s migrate to another server.

When you have installed a new server and installed the DHCP server role then you are ready to migrate the scope, scope options, server options and leases to another server.

Old (source) server.

Open PowerShell in administrator mode.

Export-DhcpServer –ComputerName computer.domain.com -Leases -File C:\DHCP_computername.xml –verbose

Stop DHCP Services under services.

Copy the file located in C:\ to the new server to the C:\

Filename is: DHCP_computername.xml

On the new (target) server.

Open PowerShell in administrator mode.

Import-DhcpServer –ComputerName computer.domain.com -Leases –File C:\ DHCP_computername.xml -BackupPath C:\dhcpbackup –Verbose

Be sure your scope is activated and authorize your Server to be a DHCP server.


In the same screen to authorize your new server also unauthorized your old server.


The Same process can also been done (from 2012R2 and up) with the Gui.


  • In your old DHCP server right click the server and choose backup.
  • Choose a destination directory and copy the backup folder to the new server.
  • In your new server rights click the server in the DHCP console and choose restore.
  • Be sure your scope is activated and authorize your Server to be a DHCP server.

5.DHCP restore from backup. #

DHCP restore from backup.

Every Windows system backup contains a backup of the DHCP server with the database DHCP leases and the DHCP settings. However, many backup solutions only allow you to restore the complete system state but not specific system data such as those of the DHCP server. If you only have problems with the DHCP server, restoring a complete system state is usually not what you would want because it might affect other services.

You have to follow a different procedure to back up a Windows DHCP server. Windows stores the DHCP data in a database located at %SystemRoot%\System32\backup. The most important file is dhcp.mdb, which can’t just be copied with backup software because it is open while the DHCP server is running. Using the Volume Shadow Copy Service to secure the data is usually not a good idea for any kind of database system.

DHCP backup server - dhcp.mdb in use

Automatic DHCP server backup ^

However, Windows automatically creates a backup of the DHCP database in %SystemRoot%\System32\dhcp\backup every 60 minutes; this backup can be copied by your backup software. The backup time interval can be changed in the Windows Registry in HKLM\System\CurrentControlSet\Services\DHCPServer\Parameters through the BackupInterval parameter. Sixty minutes is usually sufficient, but if you use a CDP backup solution to secure your server, you might want to configure a shorter backup interval.

Manual DHCP server backup ^

You can also run backups manually through the DHCP management console. This feature can be useful if you intend to make major changes to your DHCP settings. You can back up the database to a location other than the default folder. Note that this won’t change the location of the regular automatic backups. This setting can only be changed in the Windows Registry with the BackupDatabasePath parameter.

6.Client Lead Time (MCLT) and Auto State Switchover Interval #

Client Lead Time (MCLT) and Auto State Switchover Interval

A look at Maximum Client Lead Time (MCLT) and Auto State Switchover Interval

Systems administrators often have questions about DHCP failover in Windows Server 2012, specifically about how the Auto State Switchover Interval timer and the Maximum Client Lead Time (MCLT) timer work together. At first glance, both timers appear to do the same job—and this idea is reinforced in the Microsoft literature.

“The administrator configures the MCLT parameter to determine the amount of time a DHCP server should wait when a partner becomes unavailable, before assuming control of the address range.”

This sounds straightforward. If you configure the MCLT to 60 minutes, then 1 hour after the server loses contact with its partner, it will assume control of the DHCP scope. However, the Microsoft Official Curriculum for Course 2041C also says this about the Auto State Switchover Interval:

“A communication interrupted state occurs when a server loses contact with its partner. Because the server has no way of knowing what is causing the communication loss, it remains in the communication interrupted state until the administrator manually changes it to a partner down state. The administrator can also enable automatic transition to partner down state by configuring the auto state switchover interval.”

In addition, the TechNet DHCP Failover Settings page suggests:

“When operating in PARTNER DOWN state, a server assumes that its failover partner is not operating. The server responds to all DHCP client requests that it receives.”

So, if the Auto State Switchover Interval is set and a server loses contact with its partner, after the configured time period it will transition to the Partner Down state. Once in Partner Down state it will respond to all client Discover packets that it sees.

The Auto State Switchover Interval timer and the MCLT timer have been the subject of much debate among delegates in my classroom. At first glance, they seem to be performing a similar, if not the same, function; however, there must be a distinction in what they do—otherwise, why would they both exist?

An Example of DHCP Failover

Let’s look at a scenario in which two servers have been configured to provide DHCP failover for a single scope. In our example, which Figure 1 shows, we use two DHCP servers (DHCP1 and DHCP 2) that have a single scope configured. The scope is configured in a hot standby relationship with DHCP1 as the active server and DHCP2 as the standby server. The MCLT and the Auto State Switchover Interval have been set to 5 minutes and 30 minutes, respectively.

DHCP Failover Configured for a Single Scope Figure 1: DHCP Failover Configured for a Single Scope

As you probably know, the default lease duration is 8 days. In our example, if a client leases an address from DHCP1, then DHCP1 will inform DHCP2 about the client and the address that it leased. If DHCP2 takes over running the entire scope, it will know that the address has been leased out and not attempt to lease it to another client.

But what if just as our client leases its address for 8 days, DHCP1 fails and cannot share the new lease with DHCP2? In theory, if DHCP2 takes over the entire scope, it will presume that the address our client is using is still available for lease and that it can assign it to a new client. This is the problem that the MCLT is designed to prevent.

Our MCLT is set to 5 minutes. When DHCP1 is approached by Client 1 to lease it an address, instead of leasing an address for 8 days it leases an address to Client 1 for 5 minutes. DHCP1 then informs DHCP2 that Client 1 has leased an address. DHCP2 can add the details of Client 1 to its DHCP database, but crucially marks the lease as 8 days. After 5 minutes, Client 1 contacts DHCP1 again and receives the same address, but this time with an 8-day lease. Both DHCP1 and DHCP2 now know this address is leased to Client 1 for 8 days.

MCLT During DHCP1 Failure

Let’s take a look at how MCLT works during a failure of DHCP1. DHCP1 is approached by Client 1 to lease it an address. DHCP1 leases an address for 5 minutes (based on the MCLT), but before DHCP1 can share this information with DCHP2, DHCP1 fails. DHCP1 and DHCP2 had been maintaining a persistent TCP connection with each other over port 647, but now that DHCP1 is no longer there, DHCP2 will transition the scope to Communication Interrupted state.

When Client 1 attempts to contact DHCP1 after 5 minutes, it will fail and subsequently send out a general message for any DHCP server to respond. This will be registered by DHCP2, which will recognize that Client 1 has an address that was provided by its failed partner using the MCLT. This will cause DHCP2 to lease Client 1 the same address for the full 8 days and add the details to its database even though it hasn’t taken over running the entire scope yet.

Without the MCLT, Client 1 would have been given an address for 8 days. Client 1 wouldn’t have tried to renew its lease, and when DHCP2 took over the entire scope, DHCP2 would believe the address was available for lease. This could result in a duplicate IP address being leased out.

Auto State Switchover Interval

Our example DHCP failover relationship has several states that it can be in:

  •  Normal. This is the preferred state, with both members of the relationship servicing clients based on the failover mode they are in.
  •  Communication Interrupted. If a communication issue occurs between two servers configured with DHCP failover, each server will transition to the Communication Interrupted state.
  •  Partner Down. In the Partner Down state, a DHCP server assumes that the failover partner isn’t operational and the running partner can take over running the entire scope.

Getting to the Partner Down state is accomplished in one of two ways—either manually by an administrator when he or she realizes that the active server is no longer there, or automatically after the period of time configured by the Auto State Switchover Interval.

The Auto State Switchover Interval’s purpose is to automatically transition from the Communication Interrupted state to the Partner Down state. However, that’s not the end of the story. If the Auto State Switchover Interval is set to 30 minutes, then after 30 minutes of no communication the partners will transition to Partner Down state but the running partner won’t actually take over the entire scope until the MCLT has also run out. Therefore, using our timers (30 minutes and 5 minutes), it will actually be 35 minutes after going into the Communication Interrupted state before DHCP2 takes over running the entire scope.


7.DHCP Failover Configure with Gui #

Configure DHCP Failover server

I am assuming that two DHCP servers are installed and  one scope is configure already.

So let’s go ahead and configure failover for given scope:


In the resulting dialog, you can either select all scopes that exist or select scopes you want to provide failover for:


On next page, you need to provide partner server. This is the server where scope information will be replicated to:


After selecting partner server, you need to configure failover relationship parameters (you can read more detailed description on TechNet article: http://technet.microsoft.com/en-us/library/dn338985.aspx):

  • Relationship name is descriptive and can be anything that helps you identify the relationship
  • Maximum client lead time defines how much time extension a partner server can provide to a client, based on time known by partner server
  • Mode allows you to choose between hot standby mode and load balance mode. In hot standby mode only one server services DHCP requests from clients. Load balance mode allows both servers in partnership to serve DHCP clients
  • If you select load balance mode, you can define how each server will serve DHCP clients by defining percentage per server
  • State switchover interval controls how long standby server waits after losing communication with primary server before assuming active state and servicing DHCP clients. In load balance mode it may not be important factor as both servers can serve clients based on defined percentage of scope IP addresses. In Hot standby mode, it will be important to select, or the standby server will never switchover automatically
  • To secure communications between DHCP partner servers, you have an option to enable message authentication between servers. If enabled, you must specify shared secret.


After configuring failover mode and parameters, you are provided with summary page:


When you click finish, you will see progress dialog, informing you of status of failover configuration steps:


If all steps are successful, you now have a working DHCP failover pair, with no clustering required.

8.DHCP failover with powershell #

9.DHCP Failover Configure with Powershell #

DHCP failover with Powershell

DHCP failover is a new approach to ensuring DHCP availability that is included in Windows Server 2012. With this approach, two DHCP servers can be configured to provide leases from the same pool of addresses. The two servers then replicate lease information between them, which enables one server to assume responsibility for providing leases to all clients on the subnet when the other server is unavailable. The result of implementing this approach is to ensure DHCP service availability at all times, which is a key requirement for enterprise networks.

The current implementation of DHCP failover in Windows Server 2012 has the following limitations:

  • It only supports using a maximum of two DHCP servers.
  • The failover relationship is limited to IPv4 scopes and subnets.

DHCP server failover can be implemented in two different configurations:

  • Load sharing mode Leases are issued from both servers equally, which ensures availability and provides load balancing for your DHCP services (this is the default DHCP server failover configuration).
  • Hot standby mode Leases are issued from the primary server until it fails, whereupon the lease data is automatically replicated to the secondary server which assumes the load.

Load sharing mode

A typical scenario for implementing the load sharing approach is when you want to have two DHCP servers at the same physical site. If the site has only a single subnet, then all you need to do is enable DHCP failover in its default configuration. If there are multiple subnets, deploy both DHCP servers in the same subnet, configure your routers as DHCP relay agents (or deploy additional DHCP relay agents in subnets), and enable DHCP server failover in its default configuration.

Hot standby mode

When implementing the hot standby mode approach, you can configure a DHCP server so that it acts as the primary server for one subnet and secondary server for other subnets. One scenario where this approach might be implemented is for organizations that have a central hub site (typically the data center at the head office) connected via WAN links to multiple remote branch office sites. Figure 6-1 shows an example of an organization that has DHCP servers deployed at each branch office and at the head office. Branch office servers are configured to lease addresses to clients at their branch offices, while the central server leases addresses to clients at the head office. Each branch office server has a failover relationship with the central server, with the branch office assuming the role as primary and the central server as secondary. That way, if a DHCP server fails at a branch office, the central server can take up the slack for the remote site. For example, the DHCP server at Branch Office A is the primary server for the scope while the DHCP server at the Head Office is the secondary for that scope.

Figure 1: Implementing DHCP failover in hot standby mode in a hub and spoke site scenario.

Implementing DHCP failover using Windows PowerShell

In this exercise you will ensure DHCP availability for clients in the corp.contoso.com domain by using Windows PowerShell to install the DHCP Server role on both servers, create a scope on SERVER1, and configure and verify DHCP failover.

  1. Log on to SERVER1, open Server Manager, select the All Servers page and make sure that both servers are displayed in the Servers tile. If SERVER2 is not displayed, add it to the server pool.
  2. Open a Windows PowerShell prompt and run the following command to install the DHCP Server role on both servers:
    Invoke-Command -ComputerName SERVER1,SERVER2 -ScriptBlock {Install-WindowsFeature `
    -Name DHCP -IncludeManagementTools -Restart}

Note that although you specified the -Restart parameter, the servers did not restart after role installation because a restart was determined as being unnecessary.

  1. Authorize both DHCP servers in Active Directory by executing the following commands:
    Add-DhcpServerInDC -DnsName SERVER1
    Add-DhcpServerInDC -DnsName SERVER2
  2. Use the Get-DhcpServerInDC cmdlet to verify that the servers have been authorized in Active Directory.
  3. Create a new scope on SERVER1 and activate the scope by running the following command:
    Add-DhcpServerv4Scope -ComputerName SERVER1 -StartRange `
    -EndRange -Name “corp clients” -SubnetMask -State Active
  4. Use the Get-DhcpServerv4Scope cmdlet to verify that the new scope has been created on SERVER1 and is active.
  5. Use Get-DhcpServerv4Scope -ComputerName SERVER2 to verify that SERVER 2 currently has no scopes on it.
  6. Run the following command to create a DHCP failover relationship in load balance mode between the two servers with SERVER 2 as the partner server and failover implemented for the newly created scope:
    Add-DhcpServerv4Failover -Name “SERVER1 to SERVER2” -ScopeId `
    -PartnerServer SERVER2 -ComputerName SERVER1 -LoadBalancePercent 50 `
    -AutoStateTransition $true
  7. Use the Get-DhcpServerv4Failover cmdlet to view the properties of the new failover relationship.
  8. Use Get-DhcpServerv4Scope -ComputerName SERVER2 to verify that the scope has been replicated from SERVER1 to SERVER2.
  9. Turn on CLIENT1 and log on to the client computer.
  10. Open a command prompt and use the ipconfig command to view the current IP address of the computer. If the client computer is currently using an address in the APIPA range (169.254.x.y) then use ipconfig /renew to acquire an address from a DHCP server on your network. Verify that the address acquired comes from the scope you created earlier.
  11. Verify that the client computer’s address is recorded as leased in the DHCP database of SERVER1 by executing the following command:
    Get-DhcpServerv4Lease -ComputerName SERVER1 -ScopeId
  12. Verify that the client computer’s address is recorded as leased in the DHCP database of SERVER1 by executing the following command:
    Get-DhcpServerv4Lease -ComputerName SERVER1 -ScopeId

10.DHCP Failover status #

DHCP Failover States of Operation in Windows Server 2012

This article provides information on the operational states of servers in a DHCP failover relationship.

A server participating in a DHCP failover relationship will be in one of the operational states listed below. A brief description of each state is given, along with a list of the states to which a server may transition from the state in question.

  • STARTUP: This is the initial operational state of a server in a DHCP failover relationship. A server will not respond to DHCP clients while in this state. The server assumes that its partner is functioning changed since the last contact. If the partner’s state has indeed changed, the local server may have to take action (for example, retrieve database updates from the partner) prior to servicing clients.

    Possible transitions:
    A server in the STARTUP state can transition to nearly any operational state. An algorithm determines its next state based on its partner’s current state (if the partner can be contacted) and its own last known operational state.

  • NORMAL: In this state, the server is able to communicate with its partner and is operating according to the relationship mode and its role in the relationship.

    Possible transitions:

    • COMMUNICATIONS INTERRUPTED: Contact is lost with the partner server or the partner server transitions into the PAUSED state.
    • PARTNER DOWN: The partner server executes an orderly shutdown while communications are intact.
  • COMMUNICATIONS INTERRUPTED: When a server is unable to contact its partner, it will enter this state. Since the server has no way to know whether its partner is still running, it assumes that it is and operates in a manner designed to prevent potential conflicts, such as both servers leasing the same IP address to different clients. The behavior of a server in this state will be determined by the relationship mode and its role in the relationship:
    • In a load balancing relationship, the server, regardless of its role, will continue issuing addresses to new clients in its own address pool, as in the NORMAL state. However, it will also issue addresses from its own address pool to clients in the other server’s address pool. Renewal requests from clients in the server’s own address pool will be handled normally, and renewal requests from the other server’s address pool will be granted a temporary lease whose duration is equal to the maximum client lead time (MCLT).
    • In a hot standby relationship, the active server will continue servicing all clients normally in this state. The standby server will begin servicing clients which don’t already have leases by using the addresses in its reserve percentage, if any are available. If it runs out of reserve addresses while still in this state, it will be unable to lease addresses to new clients. Clients which have existing leases will be issued temporary renewals which have a lease duration equal to the MCLT.


Possible transitions:

    • NORMAL: Communication with the partner is restored, and the partner is in the NORMAL, COMMUNICATIONS INTERRUPTED, or RECOVER DONE state.
    • POTENTIAL CONFLICT: Communication with the partner is restored, and the partner is in PARTNER DOWN, POTENTIAL CONFLICT, CONFLICT DONE, or RESOLUTION INTERRUPTED.
    • PARTNER DOWN: The automatic state transition interval (if enabled) expires, or an administrator manually places the server in PARTNER DOWN.
  • PARTNER DOWN: A server in the COMMUNICATIONS INTERRUPTED state will transition to the PARTNER DOWN state when one of two things happens: the state switchover interval (if configured) expires, or an administrator manually places the server in the PARTNER DOWN state. The latter can only be done on a server in the COMMUNICATIONS INTERRUPTED state and is the only way to transition a server into PARTNER DOWN if automatic state switchover is not enabled. Unlike COMMUNICATIONS INTERRUPTED, the PARTNER DOWN state implies that a server’s partner is no longer operating. When a server enters the PARTNER DOWN state, a timer is set to the value of the MCLT and begins counting down. During this countdown, the server responds to clients as it would in the COMMUNICATIONS INTERRUPTED state. When the timer expires, the server, regardless of its role or the relationship mode, begins servicing all clients using the entire address pool. For this reason, both partners in a failover relationship should never be placed into the PARTNER DOWN state at the same time, as conflicts may arise.

    Possible transitions

    • NORMAL: Communication with the partner is restored, and the partner is in the RECOVER-DONE state.
  • POTENTIAL CONFLICT: When a server in the PARTNER DOWN state receives a message from its partner indicating that the partner is running in a state which could result in conflicts, it will enter the POTENTIAL CONFLICT state. This state indicates that communications between the servers have been restored, but conflicts may have occurred due to the previous operating state of one of the servers. Servers in the POTENTIAL CONFLICT state will not service clients. In this state, the primary server (the server designated as the “active” server in a hot standby relationship, or the server on which a load balance relationship was initially created) will request that its partner send it all updates to the binding database which have occurred since the two servers were last in contact with each other. The secondary server will simply wait in this state for such a request from the primary server.

    Possible transitions:

    • CONFLICT DONE (primary server only): The primary server received a message from the secondary server indicating that all requested updates have been sent.
    • NORMAL (secondary server only): The secondary server receives a message from the primary server indicating that all requested updates have been sent.
    • RESOLUTION INTERRUPTED: Communication with the partner is lost.
  • CONFLICT DONE: When a primary server in the POTENTIAL CONFLICT state receives a message from its partner indicating that all binding updates have been sent, it will enter the CONFLICT DONE state. A server in this state will service all clients in the same manner as it would in the COMMUNICATIONS INTERRUPTED state. In a load sharing relationship, this means that the primary server will temporarily service clients from both address pools. Only the primary server in a relationship should ever enter this state.

    Possible transitions:

    • NORMAL: The primary server receives a message from the secondary server indicating that it has transitioned to the NORMAL state.
  • RESOLUTION INTERRUPTED: A server enters this state when it loses contact with its partner while in the POTENTIAL CONFLICT state, allowing the server to respond to client requests. In this state, a server services clients as it does in the COMMUNICATIONS INTERRUPTED state.

    Possible transitions:

    • POTENTIAL CONFLICT: Communication is restored with the partner.
    • PARTNER DOWN: An administrator manually places the server in the PARTNER DOWN state.
  • RECOVER: If a server in the STARTUP state discovers that its partner entered the PARTNER DOWN state at some point after the local server was last operational, it will enter the RECOVER state. A server can also enter this state if it is made aware that it has lost its binding database. In this state, a server will not respond to client requests at all and will attempt to retrieve all necessary binding database updates (which may include the entire database) from its partner. If communications are lost while in the RECOVER state, a server will remain in this state while attempting to re-establish contact with its partner.

    Possible transitions:

    • RECOVER WAIT: A message is received from the partner indicating that all requested updates have been sent.
    • POTENTIAL CONFLICT: Communication with the partner is restored, and the partner is in POTENTIAL CONFLICT, RESOLUTION INTERRUPTED, or CONFLICT DONE.
  • RECOVER WAIT: A server which successfully receives all needed database updates in the RECOVER state will enter the RECOVER WAIT state. A server in this state ignores all client requests and simply waits for the duration of the MCLT.

    Possible transitions:

    • RECOVER DONE: The timer has expired.
  • RECOVER DONE: Once a server has been in the RECOVER WAIT state for the duration of the MCLT, it will enter the RECOVER DONE state. A server in this state will only respond to client renewal or rebinding requests; it will not service new clients. The main purpose of this state is to notify the partner server that recovery has completed. The partner can then enter the NORMAL state, after which the local server will do the same.

    Possible transitions:

    • NORMAL: A message is received from the partner indicating that the partner has entered the NORMAL or RECOVER DONE state.


The DHCP failover draft specification also provides for PAUSED and SHUTDOWN states, which are not listed here. The only purpose of these states is to inform the other server of a brief or extended outage, respectively, of its partner so that it may change its own state to either COMMUNICATIONS INTERRUPTED or PARTNER DOWN and continue servicing clients with no interruption.

The diagram below illustrates all of the possible transitions between states. For clarity, the STARTUP, SHUTDOWN, and PAUSED states are not shown.


    • Relationship Name: Enter a descriptive name to describe this DHCP Failover relationship or accept the default value.


11.DNS registration and Log files #

Check the settings on your DHCP server for registration into DNS.

Check the settings on your DHCP server. You can set the DHCP server to register on behalf of clients with the following 2 options:
(tick) Enable DNS dynamic updates

[ ] Dynamically update DNS A and PTR records only if requested by the DHCP clients.

[*] Always dynamically update DNS A and PTR records

The first option will register clients with DNS if the clients request it. The second option will register clients whether they request it or not.

Make sure you have a valid DNS suffix set (yourinternal.domain not yourdomain). Depending on your security you might need to setup credentials for the DHCP server to use to do dynamic DNS updates (see advanced tab on the DHCP settings).

If the client doesn’t have a valid DNS suffix being passed to the DHCP server and/or the DNS server nothing will get registered. Run wireshark, you should see the client sending an option 81 with the FQDN of the machine (machine.yourinternal.domain). Looking at a network trace you should see:

1. DHCP discover request from the client machine.
2. DHCP offer request from the DHCP server with an IP.
3. DHCP request from the client with all the required options (such as its DNS suffix if it is to be registered in DNS as per the register this connection in DNS setting on the client). It will also request all the options it wants (gateway…etc).
4. DHCP acknowledge from the server saying the lease has been granted.

In the DHCP server logs (turn on debugging) you should see whether the server is successfully registering names in DNS.

The DHCP server should be registering, updating and deleting DNS A and PTR records as clients request leases, renew leases and also release leases or let leases expire. On top of this the client machines should be trying to renew their DNS records every 24 hours or on changes like IP changes or DHCP renewals.

DHCP Audit Logging

You can enable DHCP audit logging if necessary. Open DHCP MMC menu, right-click on the relevant DHCP server select Properties. You will see the window shown below:

DHCP MMC showing Enable DHCP audit logging.

Audit logging is enabled by selecting the check box. The log files are stored in %windir%\system32\Dhcp by default. Windows will create a log file for each day of the week in a rolling seven-day rotation so that excessive disk space is not consumed

by the logs. A log file created on Wednesday would be named DhcpSrvLog-Wed. The log files are comma delimited and will produce a code for each DHCP transaction.

The Windows DHCP help files include a key to the codes, eg: an event code of 62 indicates that another DHCP server was found on the network and an event code of 51 indicates that the DHCP attempted to authorise and it succeeded.

DHCP Log Codes:

  • 00 – indicates the log was started.
  • 01 –  indicates the log was stopped.
  • 02 –  indicates that the log was temporarily paused due to low disk space.
  • 10 – indicates that a new IP address was leased to a client.
  • 11 –  indicates that a client renewed the lease.
  • 12 –  indicates that a client released a lease.
  • 13 –  indicates that an IP address was detected to be in use on the network.
  • 14 –  indicates a lease request could not be satisfied due to the scope’s address pool being exhausted.
  • 15 – indicates that a lease was denied.
  • 16 – indicates that a lease was deleted.
  • 17 – indicates that a lease was expired.
  • 20 –  indicates that a BootP address was leased to a client.
  • 21 – indicates that a dynamic BOOTP address was leased to a client.
  • 22 – indicates that a BOOTP request could not be satisfied because the scope’s address pool for BOOTP is exhausted.
  • 23 –  indicates that a BOOTP IP address was deleted after confirming it was not being used.
  • 24 – indicates that an IP address cleanup operation has started.
  • 25 –  indicates IP address cleanup statistics.
  • 30 – indicates a DNS update request.
  • 31 – indicates that the DNS update failed.
  • 32 – indicates that the DNS update was successful.

The following DHCP server log event ID codes are not described in the DHCP log file. These DHCP server log event ID codes relate to the DHCP server’s Active Directory authorization status:

  • 50 – Unreachable domain: The DHCP server could not locate the applicable domain for its Active Directory installation.
  • 51 – Authorization succeeded: The DHCP server was authorized to start on the network.
  • 52 – Upgraded to a Windows Server 2003 operating system: The DHCP server was recently upgraded to a Windows Server 2003 OS, therefore, the unauthorized DHCP server detection feature (used to determine whether the server has been authorized in Active Directory) was disabled.
  • 53 – Cached authorization: The DHCP server was authorized to start using previously cached information. Active Directory was not visible 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 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: The DHCP server was not authorized to start on the network and Windows Server 2003 OS shut it own. Users must first authorize the server in the directory before re-starting it.
  • 57 – Server found in domain: Another DHCP server exists and is authorized for service in the same Active Directory domain.
  • 58 – Server could not find domain: The DHCP server could not locate the specified Active Directory domain.
  • 59 – Network failure: A network-related failure prevented the server from determining if it is authorized.
  • 60 – No DC is DS enabled: No Active Directory DC was located. For detecting whether the server is authorized, a domain controller that is enabled for Active Directory is needed.
  • 61 – Server found that belongs to DS domain: Another DHCP server that belongs to the Active Directory domain was found on the network.
  • 62 – Another server found: Another DHCP server was found on the network.
  • 63 – Restarting rogue detection: The DHCP server is trying once more 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


Help Guide Powered by Documentor
Suggest Edit