Windows Server 2012 DHCP Failover feature is really something we should have a long time ago. Before this feature, when we wanted to achieve DHCP service redundancy, we had to have at least two DHCP servers and we had to split each of our scopes into two. For example, if we had a 192.168.0.0/24 scope, we set up one DHCP server to hand out addresses from 192.168.0.1 to 192.168.0.129 and another DHCP server handing out addresses from 192.168.0.129 to 192.168.0.254. This is just an example. And it is an easy one. If had network such as /27 or /21, a math could be a little bit more complicated.
Thankfully, this is over. Now we can have one DHCP server setup correctly for a particular scope, let’s say 192.168.0.0/24, handing out all addresses from 192.168.0.1 to 192.168.0.254, and add another DHCP server that can hand out addresses if primary server fails, or handing out addresses along with the primary server. We can achieve this with only few mouse clicks!
So, here is our scenario…
We have two domain controllers running Windows 2012R2 Server Core with DHCP server role installed. Both DHCP servers are authorized to the domain. Only the DC-CORE-1 is setup with a test scope:
And we can verify that our client received the IP parameters from DC-CORE-1:
Before we create our failover, let’s add some custom DHCP options to our first server. These options are common in many enterprises and will help us later to see how they can cause us problems.
These custom options we will create:
- 150 TFTP Servers
- 161 Wyse FTPServers
- 162 Wyse FTP Starting Path
First option lists TFTP servers for IP phones, for example, and last two are used for VDI environment, or Virtual Desktop Infrastructure. These are just examples. We can have other options as well, such as option that LWAP access points use for finding a wireless LAN controller. Bottom line is we have these options and they can cause problems, as we shall see.
Let’s create option 150…
In the DHCP Manager, expand DC-CORE-1.popravak.local, right click IPv4 and click “Set Predefined Options…“:
Then we click Add and create our TFTP custom option:
Then we add our TFTP servers:
This is just example of creating a custom option. Other options are created in a similar fashion…
Now let’s try setting up our DHCP Failover Cluster.
Right click the scope and click “Configure Failover…“:
Then complete the wizard…
We select scope or scopeS.
Then chose our partner server.
Give a name to this relationship, select if we want active/passive or active/active mode and percentage of IP address distribution. We also give a shared secret to be used for authentication purposes.
Finally, we complete the wizard.
We can see that the failover setup was successful.
Fine. But before we test the failover, let’s add custom attributes into play. For this we will create another scope for IP phones. This scope will use 192.168.0.0/24 address space and each IP phone requires one ore more TFTP server’s IP addresses. So we add previously created option 150.
Now let’s replicate this pool with our partner server.
We can see that now the failover of our pool that uses custom options failed with the error message:
Configure failover failed. Error: 20010. The specified option does not exist.
This will happen with any scope that has one or more custom DHCP attributes. This is what causes our replication to fail:
Because we have to have these attributes, what are we going to do? Well, we have to create the same custom attributes on our partner server and then try to replicate our scope. We don’t need to create scopes on partner server, because they will replicate, but just create the attributes that will be used in particular scope we are trying to replicate. The 150 attribute in this case. So we go through the “Set Predefined Options…” on the partner server. Once we do that, we can try to replicate our IP phones scope.
Now we have a success!
We don’t have the same parameters within the custom attributes we create in our partner scope. For example, IP addresses of TFTP servers don’t have to match those on the primary server. Perhaps types don’t have to match either. Only Code has to match. A setup such as this may or may not make sense, but that’s another story.
Now, let’s shutdown the DHCP service on primary server.
This will simulate the DC-CORE-1 server failure. From the DHCP standpoint of course. Now we renew our IP address. And we can see that we received our IP address from the partner server.
Very nice feature 🙂