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:
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:
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.
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.
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 255.255.255.0 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.
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,user1-pc.example.com,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= 192.168.1.0,192.168.1.1,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 192.168.5.0 and a DHCP server of 192.168.5.1 Add this entry:
Headquarters Wireless = 192.168.5.0,192.168.5.1,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,192.168.1.0,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”:
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 = 192.168.1.0,192.168.1.1,000
Also, if I enter the following in the TargetScope
it would have to correspond go in the [Network Info] section:
Headquarters Wireless = 192.168.5.0,192.168.1.5.1,000
Please note that the need for the “Target Scope” specification will be more obvious when a network is a Class A network.
if we have a Class A /21 in the network info: 10.10.0.0, this would include the range: 10.10.0.1 – 10.10.7.254
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 10.10.6.1-10.10.6.254 to be a DHCP reservation:
0 = Headquarters,10.10.6.0,e
This will assign 10.10.6.1 – 10.10.6.254 for DHCP reservations within the main scope.