Failover DHCP. Unsuccessful test history

Greetings, habrozhiteli.

After my favorite old “server” burned down the power supply, which led to idle time in half a day, I once again thought about fault-tolerant DHCP.
Of course, many now say that the cluster taxis. I even agree with the fact that now the cluster organization is simpler, because there is no need for a SAN or the purchase of an external hard drive, it is quite suitable for us, built, for example, on FreeNAS with a configured iSCSI connector ... But:
1. I do not have a platform for us (as well as the need for it).
2. I have no desire to raise the cluster exclusively for DHCP, but for the other needs I do not need a cluster yet.

Having glanced in MSDN (where without it), I saw that the second way offered by small for the organization of a fail-safe configuration, setup of 2 servers by the principle 80/20, i.e. the first server will serve 80% of the workspace, the second the remaining 20%. It is tempting, but (I like to list everything point by point):
1. Such an organization will not allow the full use of DHCP functionality (for example, restricting access to a proxy server by IP).
2. It is necessary to maintain 2 servers, which requires more man-hours.
3. In networks with a high range utilization rate, the remaining 20% ​​may simply not be enough to meet the needs of all customers.
')
Well, and we, after all, are “not made with a finger,” savvy for what?

So I thought to myself and gave birth to a “brilliant” thought. And what if you create a DFS resource, connect 2 servers to it and host the DHCP configuration storage on it. No sooner said than done.
2 servers are raised on a virtual platform, a domain is configured, replication is configured, a resource is created and loop replication is started between 2 linked servers. DHCP is raised and rebuilt to the appropriate resource. Hurray, the first server is running. It's time to test.
We stop the first server, almost instantly there is a replication of data between resources, go to the second one, start the service and experience the first surge of enthusiasm - it works!
Half done. We stop the backup, start the first one, create a new reservation and brutally shut down the main server. Moving on to the second, we are launching the service, and the first feeling of happiness is replaced by a bewilderment, if not to say “stronger” ...
Yes, DHCP does not start, is turned off and in every way swears at the log files and the database (it was necessary to read MSDN more carefully, this problem is described in the section on clusters).
The result - a backup "server", near which you need to run half a day to start it to work. Moreover, it will be completely absent any changes that occurred after stopping the service.

But the idle mind does not stop there.
As you know, the server on timeout produces backup of the entire database (by default, every 60 minutes), therefore you can move only the backup folder to DFS and “I will be happy”.
Reconfiguration took 10 minutes. Testing - an extra half day.
The result is again pitiable. Backups are made and DFS honestly transfers the available files to the backup server, but the system continues to hold their configuration file, without which backups lose all meaning.
The result is a working DHCP, which can be started after the “crash” of the Wizard, but which lacks all the changes. Those. performance slightly above 0.

The output of course was found. Banal, as always.
Hourly, the script exports a DHCP dump to a text file:

netsh dhcp server 192.168.0.1 dump > C:\Dhcp\Dhcpcfg.dmp

The file rests on the DFS-ball (somewhere without it, somehow I already intermarried with it after everything I experienced together), which is successfully replicated between both servers.
At one hour on the second server, a dump is simply imported:

netsh exec dhcpcfg.dmp

and the server is ready to go.
The only negative - different class names on systems with different languages. But, it is simply “cured” by the usual replacement in the file. Besides, I have systems with the same languages, so the problem has bypassed me.

Why am I all this ...
Yes, just so that someone read and immediately decided for himself all without tests.
Someone understood some things that did not understand before.
Someone reread MSDN more attentively.
And we all decided that a negative result is also a result, because contains invaluable experience.

Actually, MSDN.