Specifies the time and date format used in balloon messages. The default is %b %d, %H:%M.

[Settings]
BalloonTimeFormat=        ; Default: %b %d, %H:%M

This feature was an added in V2.9.2.0.
The format supports the following (strftime style) sepcifications:

Specify an empty BalloonTimeFormat=, in case no timestamp shall be shown in the balloon message.

Specifies the other DHCP server to load data from. This is a new feature in V2.9 and allows to setup redundant configurations for DNS. The idea is when you setup the split scope redundancy, as described in the FAQ, then you need to handle local DNS requests. See the FAQ for more information.

[Settings]
SyncServer=other-server:80  ; load data from other-server

In order for this to work you need to configure the HTTP function on the other server. IP addresses or names are allowed optionally followed by a colon and the port number of the server.

Specifies the size of the windows UDP receive buffer in KBytes. The default is 64, which should be enough to allow 256 clients to request an IP address at the same time. It should only be necessary to change this in very rare cases.

[Settings]
ReceiveWindow=8        ; Default: 64 [KBytes]

This feature was an added in V2.7.

Specifies the maximum size of the trace file (dhcptrc.txt) See also Trace. Once the trace file reached the specified limit in size, it is copied to dhcptrc.bak and a new trace file is created.

[Settings]
TraceFileMaxSize=256000        ; Default: 128000

This feature was an added in V2.6.0.

When ReadOnly is set to 1, then no changes to the INI file will be made by the DHCP server. All newly recognized clients will get an IP address assigned but the respective client entry is not created. Which has the effect that the same IP address will be used next time for another client! This might be useful for test labs, that test one device after the other and explicitly want to assign the same IP address to each one.

[Settings]
ReadOnly=1        ; Default: 0

This feature was an added in V2.6.0.

All newly created clients will get an entry in the client section Index=n where n is the number of the IPBIND_n. If the same client tries to acquire a new IP address but from a different IPBIND_k interface then the software will recognize that n != k meaning the client section is created from a different IPBIND. In that situation and when DeleteClientsFromWrongIndex is 1, then DHCP server will delete the client entry and create a new one. Please keep in mind that this will work only, when the client section includes the Index=n entry which is only the case after the client has been acquiring a new lease.

[Settings]
DeleteClientsFromWrongIndex=1        ; Default: 0

This feature was an added in V2.6.0.

Controls the behavior of the DHCP Server when offering an IP address to the client. In case of ReserveByOffer=1, the client section is written to the INI file with a lease time of 1 second when answering with a DHCPOFFER message. In case of 0, no INI file entry is made at the time of offering an IP address. Only the actual assignment (reaction to DHCPREQUEST) of the IP address creates a client section. Of course, the lease time is updated upon assignment to the requested lease time.

[Settings]
ReserveByOffer=0          ; Default: 1

This was an undocumented feature until V2.5.0.

Configure a VENDORCLASS.

[Settings]
VENDORCLASS=MSFT 5.0          ; Default: -

If a VENDORCLASS is specified as an entry in the [Settings] section, then only clients with the same vendor class defined in their DHCP request get an IP address assigned.

Enabling the Trace.

[Settings]
Trace=1          ; Default: 0
TraceFile=c:\temp\dhcptrc.txt

You can switch the trace on by putting a Trace=1 entry into the [Settings] section. The trace file is called dhcptrc.txt and is written into the same folder as the dhcpsrv.exe and the dhcpsrv.ini files. I recommend to switch the trace on, if you encounter any problems and attach the trace file to the e-mail that you are sending to me to report it. If you want the trace to have a different name (and/or directory) then use TraceFile for that. Example:

[Settings]
Trace=1  ; 1= enable,  0=disable
TraceFile=c:\temp\dhcptrc.txt  ; this is where the trace goes

If the TraceFile setting in not set then the default is dhcptrc.txt in the dhcpsrv.exe directory. TraceFile is a new feature in V1.5.2. Since V2.7 you may also use a relative path to specifiy the trace file name. Relative paths are interpreted relative to the INI file location.

Customizing the tray icon.

[Settings]
TRAYICON=someicon.ico          ; Default: default icon

Since V2.1 it is possible to change the tray icon of the dhcp server. The default tray icon is still avaible as a default. You can either choose “None”, “Default” or a filename.

TRAYICON=Default  ; use the built in default icon. 
TRAYICON=None   ; use no icon at all.

To set the tray icon to NONE is not recommended because the process can only be stopped using task manager if there is no tray icon.
TRAYICON=filname.ico loads the given icon file as the try icon.

All this is of course only effective if dhcpsrv.exe is started as an application (not as a service). The intended purposes to choose the tray icon is to bo able to distinguish the processes in the tray in case you are running dhcpsrv.exe multiple times.

Limit the DHCP Server to one instance.

[Settings]
SingleInstanceApp=1          ; Default: 0

Since V2.2.3 it is possible to limit the DHCP Server to one instance if run in application mode. If SingleInstanceApp is not configured or set to 0 then the server can be started multiple times. If set to 1 then the second instance will only show a dialog inidicating that it’s a second instance and will terminate after confirming the dialog box.

Customizing the service name.

[Settings]
SERVICENAME=DHCP Server          ; Default: DHCP Server
SERVICEDISPLAYNAME=DHCP Server   ; Default: DHCP Server

Since V1.9 the DHCP server supports customizing the service name entries. This is useful when the service is to be installed several times (different INI file needed) or in combination with an already existing DHCP server with the same service name.

Configure the sname field.

[Settings]
ServerName=Name of server  ; Default: Windows computer name

Since V2.4 it is possible to define the content of the sname (server name) field in the DHCP reply packets. The default is the computer name as it is configured in Windows (return value of Win32 API GetComputerName).

Disabling balloon messages.

[Settings]
ShowBalloonMessages=1  ; Default: 1

Since V1.7 the DHCP server shows balloon messages in the tray if run in application mode. This can be disabled by setting ShowBalloonMessages=0.

Enabling advanced features of the relay agent.

[Settings]
RelayAgentAdvanced=1  ; Default: 1

Since V2.1.3 this setting allows to alter the behavior of the relay agent. With RelayAgentAdvanced=0, the relay agent runs in a compatible mode and can be used in conjunction with other DHCP servers such as Windows 2003 Server. With the default setting of RelayAgentAdvanced=1, the relay agent adds option 82 to all requests. This allows the DHCP Server to distinguish between the link selection information and the address of the relay agent.

Changing the port number for certain services in the DHCP server.

[Settings]
PORT_53=53  ; Default: 53 (DNS)
PORT_67=67  ; Default: 67 (DHCP)
PORT_68=68  ; Default: 68 (DHCP)
PORT_69=69  ; Default: 69 (TFTP)
PORT_80=80  ; Default: 80 (HTTP)

These options are new in V1.6.5 and allows to customize the IP ports the DHCP Server is supposed to use. Default is 67 or 68 respectively. Port 53 is the default port for the DNS Server. Port 69 is the default port of the TFTP Server. Port 80 is the default port of the HTTP Server (available since V2.0). If no relay agent function is in use, then this setting has no effect.

[Settings]
PacketValidation=0  ; Default: 1

PacketValidation allows to switch off the packet validation routine that filters malformed DHCP requests. Added in V2.2. This setting exists only to bypass a too aggressive validation that falsly identifies correct requests as malformed.

[Settings]
PADDING=0  ; Default: 0

PADDING is new in V1.8 and enables to add PAD bytes (0) after each DHCP option, if the next option would otherwise be stored at a non WORD aligned offset. Some older BOOTP clients require this.

In order to enable padding please set PADDING=1 in the [Settings] section.

[Settings]
OverwriteBroadcastFlag=0  ; Default: broadcast-flag as set by the client request

OverwriteBroadcastFlag is new in V1.9.1. It allows to overwrite the broadcast flag set by the client. (See also EnableSendRawUnicast setting). The default behavior if this setting is not present or commented out, is to act according to the DHCP specification. If OverwriteBroadcastFlag is present then the behavior is to always broadcast the response (= 0) or to always try to unicast the response first (= 1). If unicast fails, then the DHCP Server defaults to broadcast.

[Settings]
ObeyParamReqList=0  ; Default: 0

ObeyParamReqList is new in V2.4.1. If set to 1, then the DHCP responses will only include options that the client requested in his option 55.

The DHCP Server automatically recognizes changes in the IP configuration in Windows. This is done based on the Windows API NotifyAddrChange. This API tells the DHCP Server when an IP configuration is changing. The DHCP Server acts on this by internally shutting down and restarting itself. Upon restart, the new configuration is used. In order to not shutdown and restart unneccessarily the DHCP Server uses a timeout mechanism to delay the shutdown after NotifyAddrChange events.

[Settings]
NotifyTimeout=5000  ; Default: 1000 (milliseconds)

The default of this timeout is 1 second (1000 millisends). Some network cards are very slow and require a longer delay before they are actually ready to run. Set the NotifyTimeout value to a larger timeout period to compensate for this.

[Settings]
NAKMessage="Info text for DHCPNAK" ; Default: -

Since V2.2.1 NAKMessage allows to specify an info text that is added to DHCPNAK replies as option 56. This info text is visible in some DHCP clients. It is very rarely used and should usually be omitted. Default behavior if NAKMessage is not specified is to not add option 56 in the reply.

[Settings]
MINPACKETLENGTH=300 ; Default: 300

This option is new in V1.6 and allows to specify a minimum packet length that the DHCP server is supposed to respond with. Default is 300 bytes. Some clients were not happy with a too short response. The remainder of the packet is filled with 0.

[Settings]
IPSCOPE_0=string-expression  ; Default: -
…
IPSCOPE_9=string-expression

IPSCOPE_n defines based on the client request if this scope matches or not. Continue reading →

[Settings]
IPRELAY_0=192.168.2.1  ; Default: -
…
IPRELAY_9=192.168.10.1

IPRELAY_x is the definition of the DHCP Server address where the relay agent sends all requests coming in from IPBIND_x. Please see the description in the INI file overview about relay agents to learn more. IPRELAY_x is supported since V2.0.

From version 1.5 on the auto configuration is supported:

[Settings]
IPPOOL_0=123.45.56.78-90
IPPOOL_1=123.45.57.0-254
IPPOOL_2=AUTO

The above enables three IP pools for DHCP clients. Unknown clients are automatically configured by adding the appropriate client sections to the INI file. IP pools of size 1 (e.g. 123.45.56.78-78) are allowed and are very useful if you want to assign the same IP address to all clients.
The new feature in V1.8 is: AUTO. If AUTO instead of a numerical IP-Pool configuration is used then the IP Pool is automatically chosen to cover the complete IP Range based on the IPBIND_x IP address and the network mask. This works best together with a name based IPBIND_x configuration.

From V1.9 on the IPPOOL_x numerical IP-Pool definition is enhanced with a comma syntax. This allows to define IP pools such as:

[Settings]
IPPOOL_0=123.45.56.78-90,92,94

This adds 123.45.56.92 and 123.45.56.94 to the IPPOOL_0.

Since V2.3.1 it is also possible to define a class A/B network by using IPPOOL_1=10.45.3.1-10.45.5.254. This defines, in accordance with the subnet mask, all IP addresses from 10.45.3.1 through 10.45.5.254 as the IP pool.

[Settings]
InstallAsService=2  ; Default: -

This is used internally by the DHCP Server to remember the checkbox “Don’t ask this question again” on startup of the software.

[Settings]
IgnoreUnknownClients=1  ; Default: 0

Setting this to 1 tells the DHCP server not to answer to requests from clients that are not configured in the client sections. DHCP requests from unknown clients are declined, if IgnoreUnknownClients is set to 0 (default).

HBA provides a basic load balancing concept according to RFC3074. HBA stands for hash bucket allocation and defines whether the DHCP Server is responsible for a client or not. The HBA consists of 32 hex values separated by a single blank. Every hex number represents eight bits, one bit per hash bucket. The DHCP server calculates a hash value for every client that asks for an IP address. The hash value is between 0 and 255. If the correspondig HBA bit for that hash value is 1, then the client is serviced. If it is 0 then the client is not serviced. Please assume the following example:

[Settings]
HBA=FF FF FF FF FF FF 00 00 FF FF FF FF FF FF FF FF 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

This restricts the DHCP Server to service clients whose hash value is 0 through 47 or 64 through 127. The server servicing the rest of the clients should have the exact opposite HBA. The HBA logic kicks in only for clients that are unknown (not yet in the INI file) to the DHCP Server. Clients who are already known are serviced regardless of the HBA.

ExpiredLeaseTimeout defines a time value in seconds.

[Settings]
ExpiredLeaseTimeout=4294967  ; Approx. 49 days

The mechanism that checks expired leases is triggered by this. Regardless of when the next lease expires, the mechanism is scheduled at least in the time interval specified by ExpiredLeaseTimeout. This is useful when the INI file entries get changed manually and the DHCP server may not be aware of already expired leases. By this, the INI file gets cleaned up cyclically.

The EnableSendRawUnicast setting is new in V1.9.1.

[Settings]
EnableSendRawUnicast=0  ; Default : 0

The DHCP protocol allows the client to specify a broadcast flag. If this flag is not set, then the DHCP server is asked to unicast the response. Unfortunatly, there is no standard mechanism based on the winsock programming interface that would allow the DHCP server to send unicasts solely based on mac address addressing scheme. In V1.9.1 the usage of the winpcap library got implemented. In situations where a unicast is required without having an IP address of the client at hand, the wpcap.dll function pcap_sendpacket is used. The EnableSendRawUnicast setting enables this functionality. Please set to 1 only if there are really problems with clients in that situation. Clients actually should be also fine with receiving responses as broadcast, which is the default behavior if EnableSendRawUnicast is not set or the wpcap dll is not installed. This has been tested with winpcap Version V4.1.1. Please also see the description of the OverwriteBroadcastFlag setting for even more advanced options to set.

The Database setting allows to split the dhcpsrv.ini file into two parts. (Available since V1.7)

[Settings]
Database=d:\database.ini  ; Default : -

Part 1 is for everything in the [Settings] section. This stays in the dhcpsrv.ini file. All the rest [General], [General_x] or client section goes into the Database.ini file. This allows a clean distinction between real settings and configuration for the DHCP server and the IP assignment database in which the client configurations are managed.
New in V1.9.2: If no [General] or [General_x] section is found in the Database.ini file, then the dhcpsrv.ini config file is used for that instead.
If no Database setting is defined, then the DHCP server assumes that the database is part of the dhcpsrv.ini file.

The file name can be specified with relative paths since V2.7. In that case, the path is interpreted relative to the INI file.

Setting ClearClientsOnStartup=1 basically removes all clients from the INI file every time the DHCP Server is started.

[Settings]
ClearClientsOnStartup=1  ; Default : 0

This is not recommended in general usage but might be useful in special cases.

Associate the IP pools with the respective IP binds.

[Settings]
AssociateBindsToPools=1  ; Default : 0

If the DHCP Server is configured to use more than one NIC with a separate subnet each (see Example 3 in the overview) then this entry associates the IPPOOL_x with the IPBIND_x. The two entries with the same number “x” belong together. Clients on subnet IPBIND_x get IP addresses assigned only from the pool defined by IPPOOL_x.
The default behavior (AssociateBindsToPools=0) is to view all IPPOOL_x as one big pool of IP addresses which can be assigned to any client regardless of the subnet IPBIND_x.

Binding to certain IP addresses (or NIC cards).

[Settings]
IPBIND_0=123.45.56.78            ; Default: -
IPBIND_1="Local Area Connection" ; name of connection 
IPBIND_2=192.168.2.1  
…
IPBIND_9=192.168.10.2

This restricts the DHCP server to bind only to certain LAN connections. All other IP addresses are ignored. This is very important if you want to restrict the DHCP server to particular cards in your computer. You have already two IP addresses, as soon as the computer is on the internet using a dial up connection.
The DHCP server will bind to all IP addresses if no IPBIND_x is found. IPBIND_0 to IPBIND_9 are supported.
Starting with V1.8 the value of an IPBIND_x entry can also be specified as a LAN connection name. These are the names Windows is using to specifiy network connections. In case a name based IPBIND_x is configured, then subnet mask, ip address and all other windows configured data such as DNS server addresses etc. are obtained automatically and don’t need to be explicitly specified in the ini file anymore. See also the AUTO feature in IPPOOL_x.

[Settings]
UseClientID=1 ; Default: 0

If UseClientID is set to 1, then clients can be recognized based on their Option 61 specification “client-identifier”. Option 61 allows several client id formats. Two of them are supported by the DHCP Server: type=0 and type=1. Type 1 is treated as the mac address of the client and just uses the mac address given by option 61 instead of the chaddr field of the DHCP packet.
Type 0 is treated as an ascii string. The client section is created with the client identifier instead of the mac address. Also the manual specification of client sections need to be based on the client-idendifier, if UseClientID is set to 1. This option is new in V1.7.

[Settings]
ConfigureUnknownClients=1  ; Default: 1

ConfigureUnknownClients is available since V1.7. Setting this to 1 tells the DHCP server to automatically configure unknown clients. Since this is the default, there is no change to previous versions. If ConfigureUnknownClients is set to 0, then a client is assigned an IP address only if the client is already specified in the INI file. Note: Important difference to IgnoreUnknownClients. IgnoreUnknownClients only controls how the DHCP Server behaves when no IP address is assigned (declining request or keep quiet). What makes a client a “known client” is an existing entry in the INI file such as:

[00-01-02-03-04-05] ; mac address
AutoConfig=1

or

[00-01-02-03-04-??] ; mac address with wildcards
AutoConfig=1

or

[client-identifier] ; client identifier (option 61)
AutoConfig=1

The DeleteOnRelease setting is new in V1.9.

[Settings]
DeleteOnRelease=0  ; Default: 1

It defines whether a client entry in the databse is deleted upon DHCPRELEASE, or not. The default behavior is to automatically delete the entry in the database. The effect is that when the same client comes back after some time and asks for an IP address, no information about it’s previous IP address is available. Even if the old IP address is available, it would most likely not being chosen. With DeleteOnRelease set to 0, the entry only gets an expired lease timestamp and can therefore be reactivated at a later time.

In addition to this the DeleteOnRelease setting also controls the bahvior for expired leases. When DeleteOnRelease is set then expired leases are also automatically deleted from the INI file same as DHCPRELEASE from client. This is new in V1.9.3 and is based on a timeout mechansim. The timeout is set to the time when the next client lease expires. This is updated every time a DHCP action is happening.

AddStandardEntries is a new setting in V2.3.4.

[Settings]
AddStandardEntries=1  ; Default: 1

It allows to control the behaviour of the DHCP Server with respect to DNS_x, WINS_x and ROUTER_x entries in the replies from the server to the client. The default behaviour (AddStandardEntries=1) is to automatically add the standard values from the Windows configuration to the reply message. This is convenient, because it makes it unneccessary to repeat all the DNS_x, WINS_x and ROUTER_x settings that were already made in Windows IP configuration. If the server should not take the standard values from Windows, then set AddStandardEntries=0.