Auto DHCP Reservation System

What is it?

The Auto DHCP Reservation System is a script written in Kixtart. Its main purpose is to manage DHCP address reservations across several site DHCP servers. It takes into consideration the types of devices that belong to the DHCP scope, and selectively adds them based on their function and or connectivity (wired / wireless)


In the recent past, a need in my organization was brought up to create DHCP reservations for multiple reasons, some of which are:

  • To allow specific access through our firewall and web filter
  • To scope out GPOs to allow special access to specially reserved address.

There is another utility out there called rmanage.vbs, provided by Microsoft, which does allow for DHCP reservations on multiple scope. It does have its advantages, however, there are a few key issues with it that prompted the creation of my tool:

  • rmanage dealt mainly with full scopes, rather than subsection of a scope, so unless a scope is dedicated to be a reserved scope, rmanage will not handle that.
  • rmanage does not differentiate devices. Meaning, if a client is a desktop, in most cases, it does not need reservations on different sites, only mobile devices ( laptops, iPhone, iPad, Android, etc…) will need a reservation on multiple sites. Similarly, rmanage does not handle the type of connectivity. If a scope exists, solely for wireless ranges, then ideally, a wired device would not have a reservation in that address space. rmanage does not handle that.

That said, if there isn’t a need for granular control, then rmanage will work well, and does have a system to synchronize DHCP scope entry, as long as they are targeting the full scope. It also has a nice feature to allow dumping of an exiting DHCP list into a text file, in order to convert it to a reservation scope.

How does it work?

The tool is built on a menu system, so there isn’t a need to learn command line arguments. For the time being, the input file for it is INI file based. (this is a native config file that Kixtart uses.) If this tool increases in popularity, I may consider porting the address databases into some sort of database, perhaps MySql.

The script takes in all the information from different sections in the INI file. Those section include information about the different networks, subnets, DHCP servers, their types (wireless, wired, or hybrid) , as well as the information regarding the devices to add to the reservation lists.

The script will then display a menu to give an option to add 1 IP to 1 scope, 1 IP to all scopes, all IPs to scope, and all IPs to all scopes. same options exist for removing those IPs from the scopes as well.


Though I am a seasoned admin, and this script is proven to work, I still consider myself a ‘functional scripter’. People who have programming experience will likely find much better ways to do what I did from a programming perspective. I provide the script AS-IS, and am happy to help you get it to work if you’re having problems with it.


  • KIX32 engine (  All that is needed is the kix32.exe placed somewhere within your system path. i.e: c:\windows
  • netsh: the script uses a native tool , netsh to perform DHCP operations. It has been tested on Windows XP and Windows 7.


  • Easy to navigate config file for easy configuration.
  • INI file validation: Helps avoid typos in complex line entries in the INIs. validation points user to actual line and problem that exists in the config.
  • Multiple configurations: Easy to switch between different INI configuration files for different DHCP scopes or purposes
  • Logging to both console, and/or file: Console logging provides color coded display, to allow for easy spotting of failed adds/removes or warnings.
  • Target devices based on their Chassis (Desktop/Laptop etc ), or connection types (Wired, Wireless), and their site locations.


Due to the nature of the script, and to avoid overlapping of IPs, as well as keeping the program efficient. It is only possible to add a mask. Meaning, only 254 devices can be added per INI file. That said, these 254 devices can target an unlimited number of sites/scopes. This limitation will become clearer as you read the documentation about how it works. I just ask that you take the time to read the documentation first before asking.


  • rsvmanage.kix : this is the main script engine.
  • config.ini: contains some configurations for logging. In most cases, the values in this file are controlled by the menu system. though sometimes it is necessary to fix those by hand.
  • reservations.ini: This is the reservation list. An unlimited number of reservation files can exist. Once the file is created, the script will display any valid files, formatted as an acceptable INI for processing.


Usage Instructions


DirLocation: This is the base path (do not include the actual ini filename) to where the INIs exist. This will allow for placing a list of INIs in a shared central location for multiple admins to manage.

ReservationFileName: This is the currently active reservation filename being used. This will change upon selecting a different one. the list gets read from the base path in DirLocation

Output: Specifies whether the output is to the console, or to a LogFile

LogFileLocation: This is only applicable if the Output is set to ‘LogFile’


The name of this file is a placeholder. It can actually be named anything that could be relevant to your purposes, maybe includes site name, site code, etc …

The INI file has 3 main sections:

Reservations: This contains the list of devices and their reservation information.

Each reservation entry in that section should be in the following format:

<index> = <Last octet IP Address>,<FQDN for reservation>,<MAC address>, <Friendly Name>| <Chassis Type: [Desktop/Laptop/VM/iPhone /iPad]>|<Connection Type: Wired/Wireless| <User Name>,<Connection Type Code: e/w, <Site Code>


0 = 1,,0003efac82,user1-pc | Laptop | Wireless | John Smith,w,300


Please note that the index numbers for these entries have to be sequential. (not the actual IP address, but rather the index, to the left of the “=” sign”.) The validation file will catch those and warn you about them for fixing before it processes anything else. But it is good to be aware of them.

This is essentially the only section that will have to be modified across different INIs.

NetworkInfo: This section is the definition of your network parameters. These will need to be entered only once, and any time anything in your network infrastructure changes, (i.e: DHCP server changed, subnet mapping changed, etc … ) these don’t happen often, so it’s a more or less permanent setup.

Each NetworkInfo entry in that section should be in the following format:

<site name> = <DHCP Scope>,<DHCP Server IP>,<site code>


Headquarter s=,,000


For a site that has its own wireless scope, create an entry for that site, appending the word “Wireless” to the site name, so, the above example for Headquarter wireless, for a subnet of and a DHCP server of Add this entry:

Headquarters Wireless =,,000

Note: the DHCP servers don’t necessarily have to be on the same subnet. If there is a DHCP relay somewhere, they can definitely be used.

TargetScope:This section is where the specific scopes are determined.

Each Target Scope entry in that section should be in the following format:

<index> = <site name>,<target DHCP Reservation subnet>,<connection type:e|w|ew>


0 = Headquarters,,ew


Like the reservation section, the indexes have to be sequential. The validation process will also warn you in case there is any discrepancies.

Also, in the “Connection type”:

  • e: wired : means that the scope only houses wired devices
  • w: wireless: means that the scope houses wireless devices
  • ew: Hybrid: means that the scope can house both wired and wireless devices.

It is important to note one important thing: the <site name> HAS to match the site name in the “Network Info” section. Except for the word “Wireless” that is appended in the Network Info section. Let’s clarify.

If I enter the following in the TargetScope


It would have to correspond to in the Network Info section:

Headquarters =,,000

Also, if I enter the following in the TargetScope


it would have to correspond go in the [Network Info] section:

Headquarters Wireless =,,000

Please note that the need for the “Target Scope” specification will be more obvious when a network is a Class A network.

For instance:

if we have a Class A /21 in the network info:, this would include the range: –

If we are looking to specify a subset of this Class A network to be reserved, the corresponding entry to that class A in the “Target Scope” section. (assuming we’re wanting to be a DHCP reservation:

0 = Headquarters,,e

This will assign – for DHCP reservations within the main scope.








Print Friendly, PDF & Email
Subscribe By Email for Updates.