Windows

Backup & Restore DHCP Server Database Information

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.

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.

NOTE 2:  It’s assumed that you already have a DHCP server configured and running.

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:

C:\Windows\System32\DHCP\Backup

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:

HKLM\SYSTEM\CurrentControlSet\Services\DHCPServer\Parameters\BackupInterval

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
  •  Reservations
  •  Leases
  •  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:

Figure 0: Setting Dynamic DNS Credentials via GUI

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>

(Exec)

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:

Figure 1: DHCP MMC via Admin Tools menu

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:

Figure 2a: Add your DHCP server
Figure 2b: Select the appropriate DHCP server

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:

Figure 3a: Backup via the GUI
Figure 3b: Selecting the default backup folder location

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:

Figure 3c: Backup complete (verify date/timestamps)

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:

Figure 4: DHCP backup copied to desktop

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:

Figure 5a: Unauthorize old DHPC server
Figure 5b: Confirm unauthorize old DHPC server

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:

Figure 5c: Authorize the new server

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:

Figure 5d: Server successfully authorized

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):

Figure 5e: DHCP Server service successfully restarted

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:

Figure 6a: Restoring the DHCP backup

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:

Figure 6b: Prompt for restart of services

Once the backup has been successfully restored, you’ll see a confirmation message. Refer to Figure 6c below:

Figure 6c: Database successfully restored

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):

Figure 6d: Insufficient permissions on the backup folder
Figure 6e: Cannot find the file specified (permissions issue)

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:

Figure 6f: Verifying proper folder permissions

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:

Figure 6g: DHCP Server service error

When the restore has completed successfully, you’ll be able to verify that all of the database information exists under “IPv4” (and “IPv6” if applicable) in your DHCP MMC.

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:

Figure 7a: Command Prompt via searching from Start menu

NOTE:  If you’re prompted by UAC, click “Yes”. Refer to Figure 7b below:

Figure 7b: UAC prompt

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):

Figure 8: CLI backup

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:

Figure 9: Unauthorize DHCP server via CLI

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:

Figure 10a: Authorizing a DHCP server via CLI

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:

Figure 10b: Verifying authorized DHCP servers via CLI

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:

Figure 11: Verify DHCP Server service via CLI

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:

Figure 12: CLI restore

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.

3.1. Export

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:

Figure 13: CLI export

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.

3.2. Import

To import the data from your previous export, the command is nearly identical; just change “export” to “import”. Refer to Figure 14 below:

Figure 14: CLI import

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):

Figure 15: CLI dump

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.

4.2. Exec

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:

Figure 16: CLI exec

 

 

5. Bonus: Extra DHPC Management Tricks

In this section, I’m going to be covering some cool additional commands you can run which will hopefully help extend your ability to manage a Windows DHCP server.

5.1. Trick #1

Show MAC/IP reservations for a specific scope:

Example syntax:

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:

Example commands:

netsh dhcp server dump > reservations.txt
find "Add reservedip" "c:\users\admin\desktop\reservations.txt" > "c:\users\admin\desktop\reservations.csv"

NOTE:  I’m not exactly sure why, but the “A” in the word “Add” has  to be capitalized, otherwise the command will fail.

5.3. Trick #3

Show general scope info:

Example command:

netsh dhcp server show scope

Example command (geared towards remote access):

netsh dhcp server <server_name_or_ip> show scope

Example output:

=================================================================================
 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:

Example command:

netsh dhcp server show mibinfo

Example syntax (geared towards remote access):

netsh dhcp server <server_name_or_ip> show mibinfo

Example output:

        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

Example command to import the scopes into the destination server:

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:

5.6.1.

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

5.6.2.

A folder on the local hard drive where the script stores the daily backup:

C:\DHCP_Backups

5.6.3.

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

5.6.4. (Bonus!)

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

6. Summary

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!

John Schuepbach

I've been tinkering with computers since 1984 and have been working professionally in the field of IT since 2005. I love learning about new technology and always enjoy figuring out how things work. People also say that I'm a freak about detail and organization - I take that as a compliment ;). I'm commonly known as "Shuey". I'm known for my passionate obsession of all things that interest me; particularly computers, video games (like Tetris), music, art, etc.
Subscribe
Notify of
guest

This site uses Akismet to reduce spam. Learn how your comment data is processed.

0 Comments
Oldest
Newest Most Voted
Inline Feedbacks
View all comments
Back to top button