DHCP Database Restore Hell

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

Currently rated 5.0 by 1 people

  • Currently 5/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Tags: ,

Comments