In this article, we’ll review the necessary information for how to backup and restore information from a Microsoft Windows DHCP server database.
Depending on how familiar you are with this procedure, you may or may not be aware that there’s more to it than just a simple “backup and restore the database”. Besides wanting a full copy of your database, sometimes you may want to only backup specific scope info, or you might want to only backup your reservations.
Whatever the need, I’ve got ya covered in this article ;). My examples will be demonstrated from a Windows Server 2008 R2 installation, but this information will basically be the same or similar in Windows 2012 and beyond.
Table Of Contents
- 1. DHCP Backup & Restore Introduction
- 2. Backup & Restore (GUI & CLI)
- 3. Export & Import (CLI Only)
- 4. Dump & Exec (CLI Only)
- 5. Bonus: Extra DHPC Management Tricks
- 6. Summary
1. DHCP Backup & Restore Introduction
It goes without saying that it’s important to keep backups of critical data, and DHCP is definitely one of those critical items. It’s important to have good backups available because you never know when unforeseen disaster is going to strike (i.e. data corruption, hardware failure, etc). While my own backup preference may seem a little overkill to some (I keep a backup, an export and occasionally a dump file), I like the peace of mind of knowing that I’ve got multiple options, just in case something ever goes wrong.
NOTE 1: It’s assumed that you have Administrative rights (and any necessary remote access to source and destination servers) to perform the steps laid out in this article. Membership in the Administrators group or the DHCP Administrators group is the minimum required permissions in order to successfully complete these procedures.
Let’s get started with some basics first, then I’ll cover all the details of the pertinent info that you’ll want to be aware of as we continue to move forward in the article.
1.1. DHCP Backup Basics 101
To keep things simple, I’m going to present some of Microsoft’s info in my own terms and from my own perspective because I’d like to make this info as easy to understand as possible, for both experienced admins and fresh admins alike. For instance, there are basically two methods of backups that you should be aware of: automatic (“synchronous”) and manual (“asynchronous”).
Anytime you setup a Windows DHCP server, backups will automatically occur every 60 minutes by default, and they’re always saved to the following folder:
Keep in mind that only one backup copy is stored at any given time (the existing backup is overwritten every 60 minutes with the latest backup copy), so it’s recommended that you keep a copy of this database somewhere other than the default location (i.e. Copy the folder to a file share on your storage server).
NOTE: The DHCP database backup folder location must be a local path. You can copy the backup to a network location after it’s completed, but the backups have to be saved to a local path first.
Also, if you’d like to change the backup time interval, you can either set it with the following command (subsitute “60” with whatever time in minutes you’d like to adjust it to):
netsh dhcp server set databasebackupinterval 60
Or you can modify the following registry key:
If you’d like to maintain extra or multiple copies of your DHCP database, you can either manually copy the folder at whatever time interval you prefer, you could create a scheduled task (covered in Step 5), or you could use something like RoboCopy (Or a combination of a scheduled task and RoboCopy! This will be covered in Step 5.6.4).
1.2. DHCP Backup Basics 201
When a DHCP backup occurs (whether it’s automatic or manual), the entire DHCP database is saved, including the following data/information:
- All scopes, including superscopes and multicast scopes
- All options, including server options, scope options, reservation options, and class options
- All related registry keys and other configuration settings
NOTE: If you use DNS dynamic update credentials, this information is not saved as part of the backup; so you’ll have to manually re-enter these credentials again if you ever restore from a backup. This can be done via CLI, using the following command syntax:
netsh dhcp server set dnscredentials <username> <domain> <password>
Or via the DHCP MMC (DHCP Management Console):
Right-click “IPv4” under the server you want to add the credentials to, choose “Properties”, click the “Advanced” tab, click the “Credentials…” button, then enter the appropriate information. Refer to Figure 0 below:
1.3. DHCP Backup Basics 301
There are three main groups of commands that are used when backing up DHCP server database information from CLI (all of which are associated with the “Netsh” command-line tool). I’ll list them and give a brief breakdown of each set of commands.
NOTE: There is a lot of information online pertaining to each of these commands/options! I’ve extensively researched them all and will provide my perspective on what I’ve found. For now, I’ll just list them along with a brief explanation of each, and I’ll provide more details and examples beginning with Step 2.3.
1.3.1. “Backup” & “Restore”
These are the equivalent of the GUI commands for backup and restore (the GUI commands are covered in more detail in Step 2). Command syntax is as follows:
netsh dhcp server backup <backup folder location>
netsh dhcp server restore <backup folder location>
1.3.2. “Export” & “Import”
This is the most widely used set of commands for backing up and restoring a DHCP server database, and it’s the “best practice” and commonly recommended method referenced by Microsoft. As you could likely expect, there can arise some confusion about the difference between “Backup & Restore” vs “Export & Import”. The key difference to be aware of is this: “Backup” & “Restore” can be used to backup & restore a DHCP server database from and to the same OS version, whereas “Export” & “Import” can be used for both backing up and restoring from and to the same server, as well as between different server versions.
To re-iterate and clarify this, if you want to backup a Windows Server 2008 R2 database and restore it to either the same server or to a different Windows Server 2008 R2 installation, you can use “backup & restore” or “export & import”. However, if you want to backup a Windows Server 2008 R2 database and restore it to a Windows Server 2012 R2 server installation, you’ll want to only use the “export” & “import” commands. Export/Import will be covered in more detail in Step 3. Command syntax is as follows:
netsh dhcp server export <backup folder location & filename> <scope info to export> (use "all" for ALL scope info, or specify specific scope(s))
netsh dhcp server import <backup folder location & filename> <scope info to import> (use "all" for ALL scope info, or specify specific scope(s))
1.3.3. “Dump” & “Exec”
The “dump” command is essentially used to export the configuration info of a server (not the entire database), and it’s generally only used for advanced troubleshooting and/or configuration scenarios. While you could use these commands to export/import configuration info from one server to another (with the same OS version or different OS version), I personally would only recommend using it to make changes to the same server that the information was exported from (or at least to the same OS version if your primary DHCP server dies).
Let me help clarify this some more: There are multiple scenarios where using dump and exec can be handy. One example is that you could manually create a template file (a simple .txt file with all of your DHCP configuration info) and then use exec to import that configuration info into one or more servers. This process can save some configuration and deployment time in a “multiple DHCP server deployment” scenario.
Another example of where the dump command can be handy is if you’d like to make a change to a DHCP scope. For example, if you’d like to change the subnet mask of a scope, this can’t be done without deleting the scope and recreating it. However, if there are a lot of customizations in the scope (like reservations and scope options), it’s going to be a lot of extra work to recreate all of that information. But with the dump command, you can export the configuration info for that specific scope, make modifications, then safely delete the scope from the DHCP MMC, and finally re-import all of the updated configuration info using the exec command. Dump/Exec will be covered in more detail in Step 4. Command syntax is as follows:
(Dump – two examples)
netsh dhcp server scope <scopeaddress> dump > <backup folder location & filename>
netsh dhcp server dump > <backup folder location & filename>
netsh exec <path location of dump file>
NOTE 1: The single “>” after “dump” acts as a redirect which outputs all of the configuration info to a file.
NOTE 2: Before using the dump command, it’s recommended that you verify and reconcile any database inconsistencies (so your dump file is “clean”). I’ll cover “reconcile” and other cool tricks in more detail in Step 5.
2. Backup & Restore (GUI & CLI)
In this first main section, I’ll detail the steps for doing a backup and restore from both the GUI and from the command line. Let’s start with the GUI steps first.
2.1. Backup via GUI
The first backup option I’ll cover is a full backup from the GUI, via the DHCP management console. Again, as stated earlier in the article, this type of backup is ideal for either restoring to the same server and OS version, or to another server running the same OS version. On the server that you want to backup DHCP from, launch the DHCP MMC by navigating to it in the Administrative Tools menu. Refer to Figure 1 below:
After the console window opens, your server should be listed. If not, right-click on “DHCP” and choose “Add Server”. A new window opens and your server should be listed in the box under “This authorized DHCP server:”. Select it and click “OK”. Refer to Figure 2a and 2b below:
Once your server has been added to the list, right-click on it and choose “Backup”. A “Browse For Folder” window will open, and it will have the default backup folder location already selected (C:\Windows\System32\dhcp\backup); Click “OK”. Refer to Figure 3a and 3b below:
Unfortunately, the Windows OS does not give you any prompt or indication that the backup “completed successfully!”. However, you can open Windows Explorer and navigate to the backup folder and verify that the files have the appropriate date and timestamp. Refer to Figure 3c below:
Remember to store a copy of this backup somewhere else besides the default backup location (as previously referenced in the Note in Step 1.1).
2.2. Restore via GUI
Before doing the restore, I would recommend copying the folder from the saved backup (located on your storage server for instance; as referenced in step 1.1) to the desktop of the user profile of the admin account that you’re using to logon to the DHCP server. In my example, I’ve stored a copy of the backup in a folder named “dhcp”. Refer to Figure 4 below:
NOTE: Before running the restore, if the old server will no longer be used to host DHCP services, you should either stop and disable the DHCP Server service, de-activate the scopes, or unauthorize the server (I would recommend this last option I mentioned). Refer to Figure 5a and 5b below:
NOTE: I would also recommend verifying the correct permissions on the backup folder that you copied to the desktop before beginning the restore process (Refer to Figure 6f further down).
Now it’s time to restore to the new server. To restore a backup, you would basically follow the same steps that were referenced in section 2.1, but choose “restore” instead of “backup”. As referenced in figure 2a and 2b, launch the DHCP MMC and make sure your new server is listed (if it’s not, add it).
Once your server is available in the DHPC MMC, you should see some red down arrow emblems over the icons for IPv4 and IPv6 (indicating that the server is connected but not authorized). Authorize the new server by right-clicking on it and choosing “Authorize”. Refer to Figure 5c below:
It will take a few moments for the server authorization to fully take effect. You can click “Action” from the menu and choose “Refresh” to update the status. When it’s successfully updated, you should see the emblems on the icons change from red down arrows to green check marks (indicating that the server is connected and active). Refer to Figure 5d below:
If the status doesn’t successfully update, open the Services MMC (via Administrative Tools) and restart the DHCP Server service (the far right toolbar button, or right-click the service and choose “Restart”). Once the service has been successfully restarted, it should look like this (Refer to Figure 5e below):
Be sure to check the console again and verify that the server is authorized (refer back to Figure 5d). Once the server is successfully authorized, you can perform a restore. Right-click your server and choose “Restore…”. Refer to Figure 6a below:
You will be prompted that the service must be restarted for the changes to take effect (this is normal); choose “Yes”. Refer to Figure 6b below:
Once the backup has been successfully restored, you’ll see a confirmation message. Refer to Figure 6c below:
NOTE: There are times when certain variables in the restore process are not quite right, which can cause various error messages. For instance, if the backup folder on the desktop does not have proper permissions configured, you could see messages like these (Refer to Figure 6d and 6e below):
Sometimes DHCP will prompt you that it can attempt to repair the permissions. But if that fails, or you need to verify/set them manually, right-click on the backup folder on the desktop, choose “Properties”, click the “Security” tab, then click the “Edit” button. Verify that the user account you’re currently logged on with has “Allow” permissions for “Full control”. Refer to Figure 6f below:
Try the restore again after you’ve set the correct permissions on the folder that you’re restoring from.
If you ever get a service error message (Refer to Figure 6g below), you can wait a moment, restart the DHCP Server service, then try again:
2.3. Backup via CLI
This is essentially the same procedure as in step 2.1, but done entirely from CLI using Netsh. The backup process via CLI is fast and simple compared to the GUI method (granted, neither method is difficult, but the CLI method is much shorter in terms of steps involved, and more efficient in my opinion). This process can be done by remotely connecting to the DHCP server via a command prompt, but I prefer to directly logon to the server and run the commands from the server’s CLI.
Open an admin command prompt by searching for “cmd” or “command prompt” via the Start menu, right-click on the search result, and choosing “Run as administrator”. Refer to Figure 7a below:
NOTE: If you’re prompted by UAC, click “Yes”. Refer to Figure 7b below:
Once the command prompt is open, doing a backup is as simple as typing the following command syntax:
netsh dhcp server backup <backup folder location>
In the example below, I backup the database to a folder named “dhcp” under “C:\Users\Admin\Desktop\” (Refer to Figure 8 below):
That’s it! Much faster via CLI!
Before you proceed to the next section, if you’re no longer going to use your old server to provide DHCP services, unauthorize the server by typing the following command syntax:
netsh dhcp delete server <ServerDNS> <ServerIP>
Refer to my example in Figure 9 below:
2.4. Restore via CLI
The restore process is also a shorter process than its GUI counterpart, but there are a couple of extra steps on this one. Remote to the new server and login, then copy the backup folder to the desktop (in my example, the folder is named “dhcp”). Be sure to verify the permissions on the backup folder (refer back to Figure 6f from Step 2.2).
Launch an admin command prompt (refer back to step 2.3) and use the following command syntax to authorize the server:
netsh dhcp add server <ServerDNS> <ServerIP>
Refer to my example in Figure 10a below:
You can also run a command to verify which and how many servers are authorized to provide DHCP services (If the information in the directory service is up to date) by running the following command:
netsh dhcp show server
Refer to my example in Figure 10b below:
Bonus Tip! Verify that the DHCP Server service is running. This can be done with the following command:
sc query dhcpserver
The output should look similar to my example in Figure 11 below:
If you ever need to start the service, you can do it like this:
sc start dhcpserver
Once everything looks good, you can perform the restore. This can be done with the following syntax:
netsh dhcp server restore <backup folder location>
Refer to my example in Figure 12 below:
3. Export & Import (CLI Only)
The “export” command saves the database to a single file, rather than a folder (like “Backup” does). Refer back to Step 1.3.2 if you’d like to review the primer for the export/import commands. Also, in an effort to prevent this article from being too long, I won’t be covering some of the info that repeats because it would just create duplicate content (i.e. if a previous server is being unauthorized, authorizing the new server, verifying the DHCP server service, etc). Since everything beginning in Step 2.3 and beyond is all done via CLI, all of the same commands apply for the info that would count as repeat content.
As with all of the commands that involve using CLI, logon to the DHCP server and launch an admin command prompt to begin. Once the command prompt is open, perform an export like this (substituting the filename and path with whatever matches your environment/preference); Refer to Figure 13 below:
NOTE: The filename and extension can be named whatever you want (.log, .txt, .cfg, etc). I personally like to use “.dat” because it’s essentially a copy of the entire database stored inside a single file.
To import the data from your previous export, the command is nearly identical; just change “export” to “import”. Refer to Figure 14 below:
As you could see in my export and import examples, I used the command “all” at the end of each full command, because my intention was to export everything from the database. I’ll give some examples in Step 5 where this command would be modified to export/import specific info instead of “all” info.
4. Dump & Exec (CLI Only)
OK, so a quick reminder about dump: You really shouldn’t ever consider using a dump file as a way to restore a DHCP server or to migrate a lot of DHCP data from one server to another. A dump file should generally only be used in situations where you’re wanting to do some fine-tuned configuring of a server.
Bonus Tip! You can dump database information directly to the command window (instead of a file), but it’s not very practical in most situations (unless you’re using the command to view some brief information). Here’s an example syntax reference (If “10.10.20.0” was one of the scopes that’s configured on the server, the following command would dump all related information related to the 10.10.20.0 scope):
netsh dhcp server scope 10.10.20.0 dump
4.1. Dump (+ Reconcile)
NOTE 1: As stated in the primer earlier (Note 2 in step 1.3.3), you should reconcile your scopes prior to dumping the configuration. There can be a lot of output when running the reconcile command, so I’m not going to provide screenshot examples; but I’ll at least provide you with the commands you need to know, as well as what to look for.
Verify the integrity of your scopes with the following command:
netsh dhcp server initiate reconcile
If everything is good, you should see a message for every scope that you have configured. The messages will each look like this:
"No database-registry inconsistencies detected for scope <Scope-IP>" (where "Scope-IP" would be an address like "10.10.20.0")
If there are any problems, you may see a message indicating that there are inconsistencies, along with specific IP addresses that were found. In those cases, you can “fix” the issue by running a command like this:
"netsh dhcp server scope <Scope-IP> intitiate reconcile fix" (where "Scope-IP" would be a specifc address like "10.10.20.129")
After running the reconcile fix command for any/all inconsistencies found, you can run the original command again to re-verify the database integrity (“netsh dhcp server initiate reconcile”). Once the database looks good, you’re ready to run the dump command.
The dump command is simple and straight-forward, and nearly as powerful as the “export” command (dump exports the same information as the “export” command, with the exception of lease info). Here’s a general example of the dump command (Refer to Figure 15 below):
NOTE 2: Again, the filename and extension can be named whatever you want (.log, .txt, .cfg, etc). I personally like to use “.cfg” for dump files because it’s dumping configuration information to a single file.
NOTE 3: You’ll also notice that, for whatever reason, Microsoft didn’t program any kind of notification into the dump command to indicate that the command was successful; it just returns to the command prompt. The dump file is “readable” though, so you can easily open it with a text editor and view the information that was dumped.
As you may have already guessed, the “exec” command is short for “execute” (as in “execute this script or configuration file”), and in our example, it’s used to essentially import the contents of a dump file into a DHCP server.
NOTE: If you thought there was a lot of command output when running the reconcile command, it’s nothing compared to the amount of output you can see when executing a dump file! With that said, I won’t be providing any screenshots of what you would see, other than an example reference of running the command. Refer to Figure 16 below:
5. Bonus: Extra DHPC Management Tricks
5.1. Trick #1
Show MAC/IP reservations for a specific scope:
netsh dhcp server scope <Scope-IP> show reservedip
Example command with output:
C:\Windows\system32>netsh dhcp server scope 10.10.20.0 show reservedip Changed the current scope context to 10.10.20.0 scope. =============================================================== Reservation Address - Unique ID =============================================================== 10.10.20.56 - 00-e0-4b-39-ab-56- 10.10.20.63 - 18-a9-05-2f-8e-15- 10.10.20.80 - 00-20-4a-05-18-5d- 10.10.20.92 - 00-0c-29-4c-81-25- No of ReservedIPs : 4 in the Scope : 10.10.20.0. Command completed successfully.
5.2. Trick #2
Dump database information to a file, then use “Find” to search the dump file and output all MAC-IP reservations to a CSV file:
netsh dhcp server dump > reservations.txt find "Add reservedip" "c:\users\admin\desktop\reservations.txt" > "c:\users\admin\desktop\reservations.csv"
5.3. Trick #3
Show general scope info:
netsh dhcp server show scope
Example command (geared towards remote access):
netsh dhcp server <server_name_or_ip> show scope
================================================================================= Scope Address - Subnet Mask - State - Scope Name - Comment ================================================================================= 10.10.10.0 - 255.255.255.0 -Active -001_VOICE -VLAN 10 10.10.20.0 - 255.255.255.0 -Active -002_VOICE -VLAN 20 10.10.30.0 - 255.255.255.0 -Active -003_VOICE -VLAN 30 10.10.40.0 - 255.255.255.0 -Active -004_VOICE -VLAN 40 10.10.50.0 - 255.255.255.0 -Active -005_VOICE -VLAN 50 10.10.60.0 - 255.255.255.0 -Active -006_VOICE -VLAN 60 10.10.70.0 - 255.255.255.0 -Active -001_IT -VLAN 70 10.10.80.0 - 255.255.255.0 -Active -001_STF -VLAN 80 10.10.90.0 - 255.255.255.0 -Active -002_STF -VLAN 90 10.10.100.0 - 255.255.255.0 -Active -003_STF -VLAN 100 10.10.110.0 - 255.255.255.0 -Active -004_STF -VLAN 110 10.10.120.0 - 255.255.255.0 -Active -005_STF -VLAN 120 10.10.130.0 - 255.255.255.0 -Active -006_STF -VLAN 130 10.10.140.0 - 255.255.255.0 -Active -007_STF -VLAN 140 10.10.150.0 - 255.255.255.0 -Active -008_STF -VLAN 150 Total No. of Scopes = 15 Command completed successfully.
5.4. Trick #4
Show general MIB info:
netsh dhcp server show mibinfo
Example syntax (geared towards remote access):
netsh dhcp server <server_name_or_ip> show mibinfo
Discovers = 63561. Offers = 8. Delayed Offers = 0. Requests = 626. Acks = 86588. Naks = 3. Declines = 0. Releases = 2. ServerStartTime = Thursday, January 19, 2017 1:03:35 PM Scopes = 15. Scopes with Delay configured= 0. Subnet = 10.10.10.0. No. of Addresses in use = 71. No. of free Addresses = 80. No. of pending offers = 0. Subnet = 10.10.20.0. No. of Addresses in use = 36. No. of free Addresses = 115. No. of pending offers = 0. Subnet = 10.10.30.0. No. of Addresses in use = 27. No. of free Addresses = 124. No. of pending offers = 0. Subnet = 10.10.40.0. No. of Addresses in use = 27. No. of free Addresses = 124. No. of pending offers = 0. Subnet = 10.10.50.0. No. of Addresses in use = 11. No. of free Addresses = 140. No. of pending offers = 0. Subnet = 10.10.60.0. No. of Addresses in use = 13. No. of free Addresses = 138. No. of pending offers = 0. Subnet = 10.10.70.0. No. of Addresses in use = 5. No. of free Addresses = 45. No. of pending offers = 0. Subnet = 10.10.80.0. No. of Addresses in use = 15. No. of free Addresses = 61. No. of pending offers = 0. Subnet = 10.10.90.0. No. of Addresses in use = 23. No. of free Addresses = 76. No. of pending offers = 0. Subnet = 10.10.100.0. No. of Addresses in use = 31. No. of free Addresses = 69. No. of pending offers = 0. Subnet = 10.10.110.0. No. of Addresses in use = 12. No. of free Addresses = 89. No. of pending offers = 0. Subnet = 10.10.120.0. No. of Addresses in use = 40. No. of free Addresses = 61. No. of pending offers = 0. Subnet = 10.10.130.0. No. of Addresses in use = 2. No. of free Addresses = 99. No. of pending offers = 0. Subnet = 10.10.140.0. No. of Addresses in use = 6. No. of free Addresses = 94. No. of pending offers = 0. Subnet = 10.10.150.0. No. of Addresses in use = 7. No. of free Addresses = 93. No. of pending offers = 0.
5.5. Trick #5
Scenario: You have two DHCP servers running in the stereotypical “80/20” rule, but you’d rather manage all of the DHCP scopes from one server instead.
Solution: Export the scopes from the server that’s managing 20% of the services, then import them into the server that’s managing the other 80% of the services (thus consolidating all of the scopes info into one server).
Example command to export the scopes from the source server:
netsh dhcp server export "c:\users\admin\desktop\dhcp.dat" 10.10.10.0 10.10.20.0 10.10.30.0
netsh dhcp server import "c:\users\admin\desktop\dhcp.dat" 10.10.10.0 10.10.20.0 10.10.30.0
5.6. Trick #6
Performing a daily backup of the DHCP server database via a scheduled task:
I’m going to explain the details of how I have mine setup, which you can then use/modify for your own environment. Here’s a brief outline of the solution I’m using:
A PowerShell script that performs the daily backup:
On the local hard drive of the DHCP server, I have a folder where I store my scripts (C:\Scripts). Here’s the code for the PowerShell script (stored in a file named “dhcp_daily_backup.ps1”):
$file = "C:\DHCP_Backups\dhcp-$((Get-Date).tostring("yyyy-MM-dd-HH-mm-ss")).dat" netsh dhcp server export $file all
A folder on the local hard drive where the script stores the daily backup:
A scheduled task that runs the script each night:
- Task name = DHCP_Daily_Backup
- Description = Performs a daily backup of the DHCP server database
- Security options = Run whether user is logged on or not
- Configure for = Windows 7, Windows Server 2008 R2
- Trigger = Daily at 1am / Recur every 1 days
- Action = Start a program: C:\Scripts\dhcp_daily_backup.ps1
A scheduled task that uses RoboCopy to archive the daily backup each night (RoboCopy is already natively included with Windows Server 2008!):
- Task name = DHCP_Daily_Backup_Archive
- Description = Archives each daily DHCP backup to our storage server
- Security options = Run whether user is logged on or not
- Configure for = Windows 7, Windows Server 2008 R2
- Trigger = Daily at 2am / Recur every 1 days
- Action = Start a program: robocopy / Add arguments = “C:\DHCP_Backups” “\\srv-storage\IT_Share\DHCP_Backups” /copy:DAT /r:10 /w:30 /maxage:1 /log+:C:\!Central\Logs\dhcp-backup-archive.log
Managing a Windows DHCP server can be complex and a little time consuming initially (especially if you’re just diving into learning how to do it), but once you have your bearings, it’s really not difficult (and can actually be fun!). Hopefully this article has given you a lot of great info that will empower you to “level up” in your skills, understanding and experience of managing a DHCP server!