Skip to main content

DHCP Error : Delete failover relationship failed. Error 1722


I came across an issue where I was trying to delete a failover relationship between two DHCP server (Windows 2012 R2) because one of the servers had a hardware fault and we couldn’t recover the server. We knew we had to built a new one so one of the steps I tried to initially take was to mark the failed server as “partner down” in the relationship. 

Upon click the button I get this message which is promising

And then the final message to tell me its not going to happen

Now depending on how you set you DHCP failover modes you could run in to issues if your setting was like the one I had where it was set at “Load Balance Mode” with 50/50 and I was unable to change the partner status to down.

This is Microsoft explanation of the difference of “Lost contact” vs “Partner down”
In load balancing mode, when a DHCP server loses contact with its failover partner it will begin granting leases to all DHCP clients. If it receives a lease renewal request from a DHCP client that is assigned to its failover partner, it will temporarily renew the same IP address lease for the duration of the MCLT. If it receives a request from a client that was not previously assigned a lease, it will grant a new lease from its free IP address pool until this is exhausted, and then it will begin using the free IP address pool of its failover partner. If the DHCP server enters a partner down state, it will wait for the MCLT duration and then assume responsibility for 100% of the IP address pool.

As you can see if you do not change the status of the failed server to “Partner down” then the working DHCP server will not be responsible for the full 100% of the scope. You need to be careful that overall that you don’t use more than 50% of the scope on average so that if you do have any issues with one of the DHCP servers then you don’t need to panic to quickly fix the issue. The above recommendation is my personal view and would only apply based on my setting that I have on this article.

As I couldn’t change the status of the failed server I decided to try and delete the relationship as we would need to create a new relationship as the new server might not be using the same server name.

So back at the IPv4 properties of the DHCP server under the failover tab I decided to hit the delete button for the relationship

Which I followed the process to have all scopes to be removed from the partner server


You then get this message below which states the obvious where the other DHCP server is not contactable or running with a error code of 1722


At this point I tried to do a bit of googling of this error code of 1722 and looked at the event viewer but didn’t get anything useful. I then did a quick search to see if there was command line to delete the relationship and came across a forum where someone used a cmdlet;
remove-dhcpserverv4failover -computername %ComputerName% -Name %RelationshipName% -Force

You would need to replace %ComputerName% with the FQDN of the working DHCP server, %RelationshipName% would be the name of the relationship that you would like to delete
Once you run the command you will receive an error message like below saying the relationship has not been deleted but when you look back at the failover properties it is deleted.



Hopefully this can help people where they have struggled to delete the relationship whether it is due to a server that has failed or have done a DHCP database restore  onto a different server. It all comes down to using powershell 😊 to save the day

Comments

Popular posts from this blog

Rolling back a version of ESXi

There is an option in VMware where after you have performed an major upgrade of ESXi you can roll back to your previous version. The benefit of this is that you would not need to reinstall your ESXi and its configuration if you had issues with the new software. I had to do this on one occassion in my lab where I upgraded from 6.5 to 6.7 and my VMs would not run because the CPU was not supported in 6.7. Please remember if you are using ISO method to upgrade ESXi please ensure you select "Upgrade ESXi, preserve VMFS datastore". Selecting "Install ESXi, preserve VMFS datastore" does not mean preserving datastore means retaining ESXi as it will still do a clean install of ESXi. This method does not work for vSphere 7.0 as there are changes to the partitions on the boot device. Below are the steps to roll back to a previous version which is quite straight forward. As always perform an backup of your host configuration before you upgrade or rollback ( KB2042141 ). I have

Configuring ESXi 6 host to send logs to Syslog Server

In my previous post I talked about configuring VMware Syslog server for Windows which is installed and enabled by default on installation of vCenter 6 for Windows. I will now describe the basic configuration that is required on an ESXi 6 host to be able to send logs out to a syslog server using my vCenter as the example. 1) Navigate to your ESXi host within vCenter. Go to "Manage" tab and select "Settings" followed by "Advanced System Settings". Look for the settings "Syslog.global.loghost" and highlight this settings. Click the pencil icon to edit the configuration for this setting. 2) You can now add the host name or ip address of your syslog server/s. You can enter just hostname or IP address, use udp://hostname:514 or ssl://hostname:1514 to be more specific on the port and protocol to be used. If you have multiple hosts then you use the comma (,) to separate each server i.e. udp://192.168.0.1:514,udp://192.168.0.2:514 3)We n

Custom ESXi Image - ISO using PowerCLI

There comes a time when you have purchased a new hardware to run your ESXi software and discover that the installable base media provided by VMware does not include the drivers or the drivers are out of date. In the world of Windows (Plug and Play) it would discover the hardware and prompt you to provide the drivers so that Windows would install/update the drivers for the hardware. For ESXi if the drivers are not present during load time then the hardware will possibly not work. VMware uses VIB (vSphere Installation Bundle) as a way for vendors to distribute their drivers. To install these VIBs you can either use Update Manager or command line (esxcli). Now this is all good but it does mean you have to first install the base ESXi then use one of the steps above to install/update the drivers.   Some people might feel that it is OK to update the drivers using the above methods but what if it was the network card that was the new hardware and you needed new drivers. Without the net