Ensuring High Availability of DHCP using Windows Server 2012 DHCP Failover


Ensuring high availability of critical network services like DHCP figures high in the list of priorities for any enterprise. In an environment where clients get their IP addresses and network configuration automatically, uninterrupted network connectivity is dependent on the availability of DHCP service at all times. Let us consider for a moment what high availability of DHCP server is intended for:

–         Any authorized computer which connects to the network should be able to obtain its IP address and network configuration from the enterprise DHCP service at all times.

–         After obtaining an IP address, a computer shouldbe able to renew its lease and continue using the same IP address so that there is no glitch in connectivity.

Windows Server 2012 DHCP provides a new high availability mechanism addressing these critical aspects. Two DHCP servers can be set up to provide a highly available DHCP service by entering into a failover relationship. A failover relationship has a couple of parameters which govern the behavior of the DHCP servers as they orchestrate the failover. One of them is the mode of the failover operation – I will describe this shortly. The other is the set of scopes that are part of the failover relation. These scopes are set up identically between the two servers when failover is configured. Once set up in this fashion, the DHCP servers replicate the IP address leases and associated client information between them and thereby have up-to-date information of all the clients on the network.  So even when one of the servers goes down – either in a planned or in an unplanned manner – the other DHCP server has the required IP address lease data to continue serving the clients.

Modes of Failover Operation

There are two modes of configuring DHCP failover to cater to the various deployment topologies:  Load Balance and Hot Standby. The Load Balance mode is essentially an Active-Active configuration wherein both DHCP servers serve client requests with a configured load distribution percentage. We will look at how the DHCP servers distribute client load in a later post.

The Hot Standby mode results in an Active-Passive configuration. You will be required to designate one of the two DHCP servers as the active server and the other as standby. The standby server is dormant with regard to serving client requests as long as the active server is up. However, the standby server receives all the inbound lease updates from the active DHCP server and keeps its database up to date.

The DHCP servers in a failover relationship can be in different subnets and can even be in different geographical sites.

Deployment Topologies

The support of these two modes enables a wide range of deployment topologies. The most rudimentary one is where two servers in a Load Balance or Hot Standby mode serve a set of subnets which are in the same site.

A slightly more involved deployment where failover is being deployed across two different sites is illustrated in Figure 1. Here, the Hyderabad and the Redmond  site each have a local DHCP server servicing clients in that site. To ensure high availability of the DHCP service at both the sites, one can setup two failover relationships in Hot Standby mode. One of the failover relationships will comprise all subnets/scopes at Hyderabad. It will have the local DHCP server as the active server with the DHCP server at Redmond as the standby. The second failover relationship will comprise all subnets/scopes at Redmond. It will have the local DHCP server as the active server and the DHCP server at Hyderabad as the standby.

                   Figure 1: DHCP Failover Deployed Across Two Sites

This deployment construct of two DHCP servers backing up each other for two different set of scopes via two failover relationships is extensible to more than two sites. One can visualize a ring topology involving multiple sites where a server at each site – in addition to being the active server for the local network – is the standby server for another site. The failover relationships can be set up to form a ring topology through the DHCP servers at different sites.

Hub-and-Spoke is another multi-site deployment topology which lends itself quite well to how organizations are looking to deploy failover. Here, a central DHCP server acts as the standby for multiple active DHCP servers each of which serves a different branch office.

Better than earlier HA mechanisms

Windows DHCP server has so far met the HA requirement by enabling hosting of the DHCP server on a Windows Failover Cluster or by split scope deployments. These mechanisms have their own disadvantages. The split scope mechanism relies on configuring identical scopes on two DHCP servers and setting up the exclusion ranges in such a fashion that 80% of a subnet’s IP range is used for leasing out IP addresses by one of the servers (primary) and remaining 20% by the other server (secondary). The secondary server is often configured to respond to clients with a slightly delayed response so that clients use IP addresses from the primary server whenever it is available. Split scope deployments suffer from two problems. IPv4 subnets often run at utilization rates above 80%. In such subnets, split scope deployment is not effective given the low free pool of IP addresses available. The other issue with split scope is the lack of IP address continuity for clients in case of an outage of the primary server. Since the IP address given out by the primary DHCP server would be in the exclusion range of the secondary server, the client will not be able to renew the lease on the current IP address and will need to obtain a new IP address lease from the secondary server. In the case of split scope, the two DHCP servers are oblivious to each other’s presence and do not synchronize the IP address lease information.

To host the DHCP server on a Windows Failover Cluster, the DHCP database needs to be hosted on a shared storage accessible to both nodes of a cluster in addition to the deployment of the cluster itself. DHCP servers running on each node of the cluster operate on the same DHCP database hosted on the shared storage. In order to avoid the shared storage being the single point of failure, a storage redundancy solution needs to be deployed. This increases the complexity as well as the TCO of the DHCP high availability deployment.

The Windows Server 2012 DHCP failover mechanism eliminates these shortcomings and provides a vastly simplified deployment experience. Moreover, DHCP failover is supported in all editions (Foundation, Standard, Data Center) of Windows Server 2012.  As one of the server reviewers aptly put it, this is high availability of DHCP on a low budget!

Management interfaces

DHCP failover can be configured using the DHCP MMC as well as the DHCP PowerShell cmdlets. Everything you can do via the MMC for DHCP failover is achievable via the DHCP PowerShell cmdlets as well. The DHCP MMC provides a Failover Setup wizard which greatly eases the setup of failover. There are two launch points in the DHCP MMC from which a user can start the wizard. The right click menu options on the IPv4 node now have a Configure failover… option. If launched from here, all the scopes on the server which are not yet setup for failover are selected for failover configuration. Alternatively, if you select one or more scopes and right click, you will see the same Configure Failover… option. If launched in this fashion, only the selected scopes are configured for failover. Please see the step by step guide to setup failover using DHCP MMC. You can download the “Understanding and Troubleshooting guide” here.

For the command line users, DHCP PowerShell provides the following PowerShell cmdlets for setting up and monitoring failover:

  • Add–DhcpServerv4Failover  – Creates a new IPv4 failover relationship to a DHCP server
  • Add–DhcpServerv4FailoverScope   – Adds the specified scope(s) to an existing failover relationship
  • Get–DhcpServerv4Failover   – Gets the failover relationships configured on the server
  • Remove–DhcpServerv4Failover   – Deletes the specified failover relationship(s)
  • Remove–DhcpServerv4FailoverScope – Removes the specified scopes from the failover relationship
  • Set–DhcpServerv4Failover   – Modifies the properties of an existing failover relationship
  • Invoke-DhcpServerv4FailoverReplication – Replicates scope configuration between failover partner servers

In addition to these, Get–DhcpServerv4ScopeStatistics cmdlet which returns scope statistics has a “-failover” switch. Specifying this switch causes the cmdlet to return failover specific statistics for scopes which are configured for failover.

In conclusion, DHCP failover in Windows Server 2012 provides a high availability mechanism for DHCP which is very easy to deploy and manage and caters to the critical requirements of continuous availability of DHCP service and IP address continuity for the clients. Early adopters of the feature have shared our enthusiasm for this critical DHCP functionality and feedback from them has been very positive.

Give it a spin on Windows Server 2012 Release Candidate and we hope that you will find it useful!

Other Links


Comments (57)

  1. Anonymous says:

    There is an error in the text: There is no Enterpise Edition for Windows Server 2012.

    Quote: "DHCP failover is supported in all editions (Foundation, Standard, Enterprise, Data Center) of Windows Server 2012.  As one of the server reviewers aptly put it, this is high availability of DHCP on a low budget!"

  2. Bryan Organ says:

    DHCP team, I am assuming based on the content that DHCP logs are not replicated. I would just like to confirm this. Thanks!

  3. Anonymous says:

    Thanks Thorsten for noting that! The reference to enterprise edition has now been removed from the blog.

  4. Anonymous says:

    Thanks for this. One other question, can the setup be reversed? You describe the scenario for the schools being active and the central server being passive. Can we reverse that and have the central server be the active server and the school sites be passive and only become active if communication to the central server goes down?

  5. Anonymous says:

    Hi Dan, Thanks for sharing your feedback. We have shared a script which is integrated with Windows task scheduler and provides for automatic synchronization of scope configuration like options, reservations, range etc. You can download it from –


    Please do let us know if this will help address the scenarios that you pointed out.

  6. Anonymous says:

    Hi Jlinesmn,

    Yes. You can have school server as standby and central server as active.

  7. Anonymous says:


    Windows Server 2012 as well as Windows Server 2012 R2 does not support DHCP failover relationship between more than 2 servers for the same scope(s). A server can however participate in multiple failover relationship with the same or different partner servers but each relationship will have to be for a different set of scopes.

    For your deployment, you can use a combination of DHCP failover and Windows Failover cluster. For example, you Site 1 you can configure DHCP server on a Windows Failover cluster and likewise for Site 2. Then you can setup a DHCP failover relationship between the 2 clustered DHCP server instances. Is this solution acceptable for your deployment.

  8. Anonymous says:

    Hi David,

    The statistics are not updated to reflect the fact that second DHCP server has taken ownership of the entire address pool of a scope. So, you will not see address available on the second server go to 100% after MCLT expiry in PARTNER DOWN state.

  9. Anonymous says:

    @Stewart, Agreed it is SO nice to see code changes on bits of the OS that haven't seen an update like this since NT4!

  10. Anonymous says:

    You can  replicate any scope configuration including lease duration, options, reservations etc using the "Replicate scope" action provided in DHCP MMC. This will replicate the scope configuration to the partner DHCP server.

  11. Anonymous says:

    Andrew, this would happen if one of your servers is domain joined (standard ?) and the other server is workgroup (essentials?). The workgroup server checks for the presence of any domain joined DHCP server and stops itself if it finds one. You can get around this by adding the registry param DisableRogueDetection (DWORD) and setting it to 1 under HKEY_LOCAL_MACHINESystemCurrentControlSetServicesDHCPServerParameters on the workgroup server.

  12. Anonymous says:

    Hi Jlinesnm,

    Yes – you can use active-passive (hot standby) mode or active-active (load balance) mode on more than 2 servers. But this will have to be for a different set of scopes. Here is how I see it getting deployed in your scenario. Lets say each of the 12 schools have few scopes/subnets e.g. School1_scope1 and School1_scope2 for school1. You will deploy one DHCP server at each of the 12 schools. The DHCP server at each school will have scopes of that school configured e.g. School 1 DHCP server will have  School1_scope1 and School1_scope2. Likewise for each of the 12 schools. You will then configure a failover relation in hot standby mode from each of the school DHCP servers to the central DHCP server e.g you will create a failover relation – School1-Central which has  School1_scope1 and School1_scope2 as part of that failover relation. Likewise for each of the 12 schools. The central DHCP server now will have 12 failover relations each of which is with a different school DHCP server. The central DHCP server will be standby server for each of the failover relation. The DHCP server at each school will have a single failover relation for which it will be the active server.

    With this deployment, the DHCP server local to the school will lease IP addresses to the computers/devices at that school. If the DHCP server local to the school goes down, the clients at that school will get DHCP service from the central DHCP server which would have now turned "active" but only for the scopes of that specific school.

    This deployment topology is referred to as hub-and-spoke. You can read a blog about it here – blogs.technet.com/…/multi-site-deployment-topologies-for-dhcp-failover.aspx.

    You will need to ensure that the DHCP relays at each school are configured to relay DHCP client messages to both the DHCP servers – central server and local server.

    Let us know if this deployment topology would work for you.

  13. e-micra says:

    Just for your information DHCP team: we implemented DHCP in load balanced configuration with two central DHCP/DNS/WINS (year 2003 or 2004) servers. Both servers had the same scopes with full address covering or in configuration 80-80 (yes, 80% – 80%, so
    near 20% were really available for each server exclusively) and it was working.

    It wasn’t small implementation, it was for near fifty to sixty thousands (50000 to 60000) workstations and servers, and practically it was working perfectly – Windows 2003 with ICMP testing availability of addresses worked perfectly. I’m not absolutely sure,
    but probably leases were for 16 hours. Now we are at the beginning of much smaller implementation – up to six thousands workstations and now it will use failover mode on two or three DHCP servers.

  14. teamdhcp says:

    Hi Bryan, you are correct – DHCP logs are not replicated. Events to the respective DHCP log file are logged independently by each DHCP server.

  15. teamdhcp says:

    John, for the subnets at the remote site, you can create a failover relationship with active/active configuration between the servers at primary and secondary site. This will cause client load to be distributed in the ratio that you specified (default
    50:50). When one of the server is not reachable from the remote site, clients will retransmit the requests. This is normal DHCP client behavior. The second server will notice that the clients are retransmitting and respond to the client requests. So, the clients
    will be able to extend the lease. New clients coming up will also be able to get a new lease.

  16. teamdhcp says:

    Hi Jason, 20010 is ERROR_DHCP_OPTION_NOT_PRESENT – The specified option does not exist on the DHCP server. The error codes are documented at
    http://msdn.microsoft.com/en-us/library/windows/desktop/aa363378(v=vs.85).aspx. In which step are you getting this error ? during import or while creating the failover relationship

  17. teamdhcp says:

    Hi Jason,
    You seem to be doing the right thing by using export and import. Can you give us the step by step detail of what you are doing so that we can pin-point the problem better.


  18. Anonymous says:

    Is the failover has a AD requirement ? it seems not but i would like to be sure because I have a 2003 AD, .

    thanks for your blog.

  19. Anonymous says:

    Hi Ross, DHCP failover does not provide for replication of server level/wide configuration. Allow/Deny MAC filter is a server level/wide configuration. The reason this is not provided for is because a DHCP serve can participate in more than one failover relationships with different partner DHCP servers. In such scenarios, replicating server level configuration can lead to undesirable resultant server level/wide configuration. If your server has a single failover relationship or a allow/deny MAC address filter list that applies to all servers, you can setup a regular sync between the DHCP servers by writing a simple PowerShell script and integrating it with Windows Task Scheduler so that it runs on a periodic basis.

    Let us know if you have further questions.

  20. Anonymous says:

    Hi Nadeem,

    You need to add IP addresses of both the DHCP servers in your network switches as IP helper addresses. This will ensure that DHCP client requests (broadcast messages) reach both the DHCP servers. If you have configured a load balanced failover, only one of the servers will respond to a given client when the failover relationship is in NORMAL state i.e. both servers are up and running and able to communicate with each other. The servers compute a hash of the MAC address of the client and have an a-priori understanding of which hash will be served by which server. When one of the servers goes down , the failover relation moves into COMMUNICATION INTERRUPTED state (Lost contact with partner). While in this state, the server will respond to all client requests.



  21. Anonymous says:

    Hi Chris, No – you are not required to move these scope options to server options. This error seems to indicate that the data type (string/integer/binary/…) for one of the options is different between the 2 servers. This will not happen for standard options like router, DNS or any of the built in options – unless the data type for these has been modified by the DHCP admin. If you have added a custom option definition with different data type on the 2 servers, you are likely to see this error.

  22. teamdhcp says:

    Robb, thanks for sharing your observation. The automatic sync script relies on DHCP server events being logged for a configuration change. The event serves as a trigger to sync the scope(s) to the partner DHCP server. For an IP range change event, there
    is no event logged by the DHCP server. Hence, it will not get replicated immediately. However, the script runs a replication every 30 minutes in any case. At that time, the IP range will get replicated. 30 minutes interval can be changed to lower//higher in
    the script.

  23. teamdhcp says:

    Ben, IPAM takes care of updating both copies of a failover scope when a reservation, option or any other scope level configuration is updated. It does not keep the server level configuration in sync. For MAC address list, you could achieve sync by writing
    a PowerShell script using DHCP Server PowerShell cmdlets for MAC addresses.

  24. Anonymous says:

    DHCP Failover in Windows Server 2012 has no dependency on Active Directory. You can configure DHCP failover with workgroup DHCP servers also.

  25. Anonymous says:


    I was wondering if the Active-Passive mode can be used on more than two servers. We currently have a centralized DHCP server. One of our schools had their fiber cut and could not log in to local resources. We would have 12 schools that fall in to this scenario. So, could we set up Active-Passive with that many servers? Thanks.

  26. Stewart says:

    Great stuff. Been wanting something like this for quite some time…

  27. Scott says:

    Also, if you change the lease duration for a scope in one server, it won't replicate to the other server. You have to micromanage that setting along with the other settings that I mentioned, on each server.

  28. Nadeem says:

    Dear All,

    I have configured the two windows 2012 std server on two different site with DHCP fail-over service. i just want to know how the fail over works.. ? should i need to add the partner IP in my network switches (Ip helper address) so that in case of primary server fail host can reach up to partner server ??

    Your urgent response in this regard will be highly appreciated..  



  29. Ross Harvey says:

    Erm, replication of allowdeny MAC filter?  I'm surprised this feature was completely missed out, we rely upon this in our organisation to prevent anyone from just plugging a device in, it seems this is the only aspect the Server 2012 replication doesnt handle, am I mistaken?



  30. David says:


    I'm currently testing this new feature and It's a great improvement from clustering DHCP with 2008r2.

    One issue though – I've configured a hot standby failover setup for my DHCP servers. For testing purposes I've set state switchover interval to 10mins, and MCLT to 5 minutes.

    I see from the event logs the relationship status changes from:


    then 10mins after:


    Which is expected. However, 5mins after that I should expect my second DHCP server to take ownership of the scopes I've specified. However, the DHCP MMC snap in tells me that I only have 5% of address available in the secondary DHCP server's pool for both scopes. Am I right in assuming this should go to 100% after the MCLT time has expired?


  31. Dan says:

    Are there any plans to improve scope replication? Currently only replicating lease info is limiting. If we decide to change scope level DHCP options like:DNS, gateway, reservations, scope range… those all need to be manually replicated after the change, or manually set on both servers. If a change gets made on the scope on serverA, and a different change gets made on serverB forcing a scope replication will cause the change on one side to be deleted. In an environment where we have several admins making changes, I can see this leading to problems is adminA adds a reservation and replicates it, but doesn't know adminB made a change on the partner server, thus deleting adminB's change. All this info is replicated at cluster creation, why not put in a mechanism to always replicate it? Seems like a huge oversight to me.

  32. AndrewChapman says:

    I am attempting to configure DHCP failover using load balancing with an Essentials and a Standard server.  I have everything configured and working but I am facing an issue.  If I try to start the DHCP services on the Essentials server and the DHCP services on the Standard server are already started it will not start and I get error 1053 The DHCP/BINL service has encountered another server on this network with IP Address,, belonging to the domain: . in the event log on the Essentials serve. Any dieas why this is?

  33. Jose Manuel says:

    Are you planning to allow scope replication to more than one server?.

    In my current scenario I must run a metro-cluster with 4 nodes to ensure High Availability. It's a good design for High Availability, but adds a lot of dependencies to an infrastructure service like  DHCP. I would prefer to have a pair of servers in the same site with Active/Active replication and Active/Passive with the remote site couple.

  34. Chris Brennan says:

    I go to configure failover on Windows 2012 Server however get error 20103 Conflict in types for the same option on Host and Added DHCP Server.

    I have scope options set for Router, DNS etc should I move these to Server Options?  This is the only thing I can think of.

  35. Martin says:

    Hey DHCP team…DFACS question for you

    if i setup the DFACS on the first node to sync to the second one, everything works as designed, meaning all the config gets replicated to the second node, but lets say i go and change something on the second DHCP node, then on the next timed sync (as per xml config file), the node 1 will overwrite the changes on node 2, unless i manually click on node 2 gui to sync, before the xml time config does.

    the PS documentation itself says 2 instances of the script cannot be executed in parallel.

    so…whats the trick here ? should i only make changes on the first node all the time ? to make it consistent ? or is there a way to always keep these boxes talking to each other, regardless if the admin clicked on the replicate gui ?

    thanks !


  36. teamdhcp says:

    Hello Martin,

    As mentioned in the DFACS guide, the configuration changes for scopes in a failover relationship need to be made on only one of the DHCP servers in the failover relationship.

    Making configuration changes on both DHCP failover servers with DFACS is not supported.

    In your scenario, would the admin be performing configuration changes on both the DHCP failover servers.

  37. Martin says:

    Hi DHCP team, thanks for the quick reply in regards to the DFACS.

    what happens if i put IPAM role on a third box doing the discovery on both nodes ? and run the discovery on all my DHCP servers, can i tell IPAM only to make the changes on node 1 ? or i should not even discover node 2 to make it consistent ?

    so let's say, i create scope 1 on both at the same time ? or will this conflict with the DFACS ?

    if i dont have DFACS running on node 1, will the creation of a scope for example within IPAM trigger a replication ? or do i still need to have it running to keep it in sync ?



  38. teamdhcp says:

    Hi Martin, if you are using IPAM 2012 R2 then you do not need DFACS. When you update/edit a failover scope using IPAM 2012 R2, IPAM automatically updates the configuration of the scope on both the DHCP failover servers.

    Regarding your question related to adding a new scope – a new scope added to a DHCP failover server does not automatically get added to the failover relationship. You will need to add it the failover relationship. Once added to the failover relationship, any further configuration changes on the scope will automatically be performed on both the DHCP failover servers by IPAM.

  39. Henry Osorio O says:


    Please your help

    Install DHCP Failover (Active, Passive), but left the fortigate DHCP IP ACTIVE assets at the time of testing the client can not renew IP The steering, using the  DHCP PASIVE, because I find that I set change?

  40. teamdhcp says:

    Hello Henry, I did not follow your question completely. Are you saying the client is not able to lease an IP address from the Passive (standby) DHCP server of the failover relationship. In a Hot standby (Active-Passive) failover relationship, only the active DHCP server will lease IP addresses to the clients, Only when the active DHCP server goes down, the standby DHCP server will start leasing IP addresses. Another thing to keep in mind is to configure IP addresses of both DHCP servers on the DHCP relay or IP helper.

    It will help if you elaborate on what steps you tried and what failed.

  41. Henry Osorio O says:

    Hi Team


    1. DHCP Active

    2. DHCP Pasive

    3. In the Fortigate, is configuring the rule of DHCP Server, its (DHCP Active)

    4. in the test, disconnect server Active

    5. Client no find DHCP Pasive server

    6. Client, IP renew not working

    Thank for your help

  42. teamdhcp says:

    Thanks for the details, Henry. I assume Fortigate is acting as a DHCP relay – forwarding the DHCP client message to the DHCP server. To ensure that the DHCP client message goes to both DHCP servers, you will need to configure Fortigate with both DHCP server IP addresses – and The passive server will not respond to the DHCP client message while the Active server is still up and running.

    Hope that helps.

  43. Henry Osorio O says:

    thank you, very much, excelent,

  44. Lukus says:

    I have two 2012 DHCP servers in Active Passive HA mode (1 in Primary site and other in secondary site). I also have a remote office with the router having both DHCP servers IP helpers defined. My question is…if there is a network connection issue to remote site and the Primary site, will the secondary DHCP be aware of this and issue/renew an IP to the client based on the second IP helper off the remote site router? What's the best setup to account for remote-primary site WAN failures?

  45. Jason Lehr says:

    I am trying to configure failover from a 2012 R2 to another 2012 R2 server. It keeps giving me a "specified option does not exist error 20010". I've configured the custom options and even tried importing the source servers config from both netsh and powershell's
    import-dhcpserver cmdlet. something in there is hidden or corrupted and we have many scopes not feasible to recreate them on the source server…

  46. Jason Lehr says:

    I had originally imported a 2003 server DHCP database using netsh to our new W2012 R2 DHCP server. It seems there is something hidden/corrupt or possibly there is some database schema from the 2003 server that carried over, and causing it to choke. Would
    be great if there were any way to get a verbose error instead of just "error 20010".

    I had tried to manually create all the custom options (like option 150 for instance) and also just imported the whole config of the server and deleting all the scopes on the target. nothing works

  47. Robb says:

    Unless something is broken on my system, it seems that I was under the mistaken impression that the replication of the scope also replicate scope parameters. I have been making changes to the start IP of some scopes only to find out that this edit didn't
    replicate over to the other server. It might be important to call out exactly what is included in the replication.

  48. john says:

    Thanks for all the great info herein. I have the same question as "Lukus" above (7 Mar 2014), and noticed there was no response to that question. My assumption would be that in the situation described, one would want to use Active/Active Load-Balancing
    configuration, so that if the WAN link to the primary server goes down, the secondary server will respond to the remote site's DHCP request even though the link between the primary and secondary DHCP servers is up and the primary is thus seen as being in a
    "NORMAL" state by its partner node. Is this correct or would you recommend a different config?

  49. Ben says:

    "DHCP failover does not provide for replication of server level/wide configuration" (in response to Ross, 2-18-2013)
    Can IPAM Server do this? If so, can you point me to docs that detail how? I want to maintain two master lists of MAC addresses (one allow & one deny) for Link Layer Filtering and have those two lists apply to two DHCP servers in an active/active relationship
    (or, better, multiple scopes on those two DHCP servers).

  50. Wendy Schaeffer says:

    Hi DHCP Team, I have a backup question…I work in an Enterprise environment and we are using Netbackup for the backup of our servers. I currently have the backups set for System State full weekly with a 1 month retention, but I need to create a backup
    for the C:windowssystem32dhcpbackup folder as well. I was wondering what the best plan would be for the DHCP database, I believe a weekly full would suffice, but just wanted an expert opinion on this.



  51. Sean Sobey says:

    Great article, question, I have 3 2012 R2 DHCP servers. 2 in my main site, 1 at my DR site. I want to configure failover load balance for the 2 servers at my main site and hot-standby at my DR site… Is this possible?

  52. teamdhcp says:

    Sean, for a set of scopes DHCP failover can be configured only between 2 DHCP servers. A DHCP server can have multiple failover relationships with different partner DHCP servers but those will have to be for distinct scopes.
    For your scenario, 2 servers at main site and one at DR site, you can consider using a combination of Failover clustering and DHCP failover.

  53. teamdhcp says:

    Sean, please see this link
    https://technet.microsoft.com/en-us/library/dn338983.aspx#cluster for how DHCP failover can be used in conjunction with Windows failover cluster.

  54. Nazir Shah says:

    We are using split scope mechanism, but it seems one of the server is not at all being used for providing IP’s

  55. teamdhcp says:

    Nazir, in split scope deployment typically the second server is configured with a delay. So, only the leases given by one server reach the client early and are accepted. The second server comes to play only when the first server goes down.
    If you are on Windows Server 2012 or 2012R2, I would suggest using DHCP failover instead of split scope.

  56. BenB says:

    Can you have a DHCP server on a workgroup failover with a DHCP server on a domain? We've got one on a workgroup and have been attempting to add one onto a domain server, but the domain server says we have to authorise it.

  57. teamdhcp says:

    BenB, yes you can have a failover relationship between a workgroup DHCP server and domain-joined DHCP server. Domain-joined DHCP server will have to be authorized so that it starts responding to client requests.