The Raven Report

It appears Microsoft may have dropped DHCP Failover from the Windows 2008 R2 release.  Hopefully they come to their senses, but we’ll see. Feel free to continue reading to see what might have been.

DHCP server services are used to provide automated IP configuration for network endpoints.  Traditionally DHCP lease information is stored in a single database, and this single computer is prone to be a single point of failure. Now you can Cluster the DHCP service, but this still leaves you venerable if the DHCP database gets corrupted.   In the past the only way to elevate this was to use something like a split of the DHCP Scope between 2 servers. This did improve the reliability, but this option didn’t fit in many environments do to the need to have many extra addresses in every subnet.

In Windows Server 2008 R2, the DHCP Failover feature has been included to allieviate outages due to single server failure. The DHCP Failover feature is an implementation of the DHCP Failover protocol.

With DHCP Failover, the servers providing DHCP Server services synchronize DHCP lease information between each other. One computer is designated as the primary DHCP server and the other as the secondary DHCP server.

When computers request IP configuration, the primary DHCP server will respond. In the event that the primary DHCP server is unavailable, the secondary DHCP server will service the request. The big difference here is the secondary server knows about the current leases that the primary server made, and will be able to renew existing leases, and not be forced to give out a new address. This also eases administration and the DHCP scopes do not need to be split between servers.  The DHCP Failover feature will also support two-way syncing to support load-balancing between the primary and secondary DHCP servers.

Now granted there have been some appliances in the market that supported this functionality for the past few years, but this is a great addition to the Window Server feature set. This was something that was lacking from the original Windows 2008 release, but appears to be making it in the R2.

Background

A few months back we had an issue with our clustered DHCP server. It appears that the virus scanner lost its exceptions on the DHCP logs & database files.  During the built in DHCP backup, which normally happens once and hour, corrupted not only the backup, but the DHCP database itself.  Since the issue didn’t actually kill the DHCP service, our SCOM didn’t catch the failure.  Actually SCOM doesn’t monitor DHCP in a cluster very well, since the management pack doesn’t detect cluster installs.  Because the problem occurred in the middle of the night no one was aware of the joy that waited on arrival to the office.  Long story short, we had about 2 hours of real live, no one working downtime. All the servers and applications were running clients they just couldn’t get addresses to connect.

The Question

How do we restore to a new none clustered server in the event that the entire cluster is unavailable, and do it quickly with minimal impact?

The Answer

To restore the DHCP database in a clustered environment or where the DHCP database is not installed in the default location, your new system must the same path available that was on the original DHCP server.  

So say you have DHCP in a cluster and the data base and log files are in the S:\DHCPDATA you will not be able to restore, unless you have a S:\DHCPDATA available on the new box, since the database in the backup folder isn’t a real database and has the path hard coded into the dhcp.mdb, dhcp.pat & log file.  You can actually mount the dhcp.pat in regedit and modify it, but  since the path is also hardcoded in the database, in the end it doesn’t help us in this situation.

This is all well in good except if you are restoring to a server that has an S:\, but what if that isn’t the case?

Workaround

Use the following command on the DHCP server as part of your backup process

netsh dhcp server export C:\dhcp.txt all

Then use the following command to restore on the new server

netsh dhcp server import C:\dhcp.txt all

This option looks great at first, but when you run this command the DHCP server service stops and then restarts. In a cluster this causes the resource to go offline and back online, which in turn triggers alerts. So either we put the system in maintenance mode or look for other options. Also what if I didn’t implement this, and all I have are the backups from tape?

Now to the heart of the problem:

All we have is the built in backup files, and we need to restore to a server with a S:\

1.    Create a folder called DHCP and share on the C:\ giving system full control

2.    Make sure the file structure matches what you had on your original server.  In our case: dhcpdata\back\new.

3.    Restore your backup files in this directory

4.    Create a persistent drive mapping from the server to itself as the system account

a.    How/Why the hell do I do this?
Well DHCP runs as system so we have to have the drive S:\ available for it
This can be accomplished by doing the following

                                       i.   Open a Command prompt

                                       ii.    Type:
AT <future Time> /interactive cmd /k
this will open a cmd window running  as system

                                       iii. Type the following in the system command window:
Net use s:  \\servername\DHCP  /PERSISTENT:YES

5.    Now that we have a S:\ available to system all we need to do is initiate a restore from the DHCP management tool and browse to the backup files.

Additions Info:

Technet Managing DHCP Databases

How to move a DHCP database