Since version 2.0 of the DHCP Server the $(section\name) syntax can be used in the INI file. This helps to keep the INI file simple and prevents repeating information such as IP addresses in many places. Here is an example of a typical INI file:

[Settings]
IPBIND_1=192.168.17.2
IPPOOL_1=192.168.17.2-50
AssociateBindsToPools=1

[DNS-Settings]
EnableDNS=1

[General]
SUBNETMASK=255.255.255.0
DNS_1=192.168.17.2

A clean and simple INI file with one IP pool and DNS enabled. If the IPBIND_1 interface ever changes, then one would need to change the IP address 192.168.17.2 in three places. No big deal but can be avoided with the following INI file utilizing the $(section\name) syntax:

[Settings]
IPBIND_1=192.168.17.2
IPPOOL_1=$(Settings\IPBIND_1)-50
AssociateBindsToPools=1

[DNS-Settings]
EnableDNS=1

[General]
SUBNETMASK=255.255.255.0
DNS_1=$(IPBIND_1)

If the interface ever changes then only IPBIND_1 needs to be edited. $(IPBIND_1) is equivalent to $(Settings\IPBIND_1). Settings is sort of the default section. $(section\name) can be used for everything in the INI file. It can even be used for INI file entries that the DHCP Server doesn’t even know. Here is an example showing the usage for directories:

[Settings]
BaseDir="d:\dhcpsrv" ; dhcpsrv.exe resides here 
IPBIND_1=192.168.17.2
IPPOOL_1=$(Settings\IPBIND_1)-50
AssociateBindsToPools=1
Trace=1
TraceFile="$(BaseDir)\dhcptrc.txt" ; trace file

[DNS-Settings]
EnableDNS=1

[General]
SUBNETMASK=255.255.255.0
DNS_1=$(IPBIND_1)

[TFTP-Settings]
EnableTFTP=1
Root="$(BaseDir)\wwwroot" ; use wwwroot for http and tftp 

[HTTP-Settings]
EnableHTTP=1
Root="$(BaseDir)\wwwroot" ; use wwwroot for http and tftp 

This way the base dírectory of DHCP Server can be changed easily in one single place and the trace file and all the other entries that refer to files are always correct.

A client section can be specified based on wildcards (since V1.7). Please use this with care. Recommendation is to not use client-id based specifications (UseClientID=0) and also to make sure that no interference with IPOOLs is possible, because the DHCP Server is not able to check this. This is how it works:

A client section can be defined based on wildcards like this:

[00-01-02-03-04-??]
IPADDR=192.168.17.%m5

What happens is that if a client that matches the above wildcard asks for an IP address, that the IP address assigned is automatically composed by using mac address byte 5 (%m5). The resulting mac address for client [00-01-02-03-04-6A] will be 192.168.17.106. (6A hex is 106 dec).
Mac address byte 0 through 5 are accessed accordingly with %m0 through %m5. The wildcard match algorithm searches in the following order and takes the first matching entry:

[00-01-02-03-04-6A]
[00-01-02-03-04-??]
[00-01-02-03-??-??]
[00-01-02-??-??-??]
[00-01-??-??-??-??]
[00-??-??-??-??-??]
[??-??-??-??-??-??]

In addition to the %m0 through %m5, since V2.3.1 there are further macros available. These are %ip0 through %ip3. They allow to access the IP address of the IPBIND_n address used by the current DHCP request. If IPBIND_1 is defined as IPBIND_1=192.168.5.1, then the macros are extended to: %ip0=192, %ip1=168, %ip2=5 and %ip3=1.

The DHCP server supports custom options in addition to the above options. This allows to specify all possible DHCP options in client and general sections. (New in V1.7)

The syntax for custom options is:

[00-01-02-03-04-6A]
OPTION_nn="whatever text"     ; text
OPTION_nn=02:03:04:05         ; hex bytes
OPTION_nn=192.168.2.1         ; IP address
OPTION_nn= 01 "whatever text" ; combination of hex byte and text

nn is the option number (decimal) such as OPTION_66 for TFTP server IP address. Leading zeros, such as OPTION_060, will cause problems in earlier versions. Version 2.7 and newer support leading zeros.
Please note that all the examples above have a trailing comment in each line. This is necessary and is not optional. The comment even if it is only the semi-colon (;) is needed.

OPTION_nn=”whatever text” ;

If there is no comment symbol at the end then the OPTION_nn setting will not be recognized correctly and is treated as malformed and therefore ignored.

The custom option syntax understands hex bytes as two digit values, IP addresses as a group of four decimal numbers separated by ‘.’, and “text”. As separators are allowed: blanks and colons (:). Two special syntax features make it easier to deal with custom options (available since V2.4). The first is the auto-len prefix for everything inside of parentheses (). You can group all data (hex bytes, IP addresses and text) as you whish and put parentheses around them. The resulting encoding will automatically prefix the data with a length field. An example can be seen in the FAQ.
The second new feature in V2.4 is related to IP address encodings. Sometimes it is necessary to encode, e.g. in OPTION_121, a network ID in a compact form. Example:

OPTION_121= 10.10.30.0/24 10.10.20.254 ; encodes to 18 0A 0A 1E 0A 0A 14 FE

This defines a classless static route for all addresses in the 10.10.30.0/24 network to be routed via 10.10.20.254. The encoding for this is an 8 byte octect sequence as shown above, where the first 4 octects are a compact CIDR syntax. Compact CIDR syntax means, that 10.10.30.0/24 only consists of the relevant octets for the network id. The relevant octets in this case are 3, because /24 makes the 4th octet of 10.10.30.0 irrelevant.