Tuning Large Windows DHCP Servers
I’ve been involved in setting up some very large Windows DHCP deployments during my time working as a Consultant at Long View Systems. Along the way I’ve found some interesting challenges and caveats of using Windows DHCP, especially so anytime your working with DHCP enabled dynamic DNS updates. I wanted to have a quick post about this for my own reference and hopefully might come in handy for others as well.
- DHCP Failover Scopes
- Administration Overhead
DHCP Failover Scopes
I’ve covered this topic extensively in my Windows Server 2012 R2 – DHCP High Availability / Fail-over Setup Guide series. Basically, if you are deploying Windows DHCP on a 2012+ server then you should be using DHCP Failover (not to be confused with split-scope or ms-clustering).
If you’re working with more than 100 scopes using only the default DHCP MMC-snap in’s, you’re gonna have a bad time.
Performing administration tasks in the console with a large number of scopes becomes very repetitive and time consuming as each task normally requires many clicks. Making mass-changes is also very difficult or next to impossible. You may find yourself becoming familiar with Powershell scripting to resolve this problem. The DHCP Server Cmdlets in Windows PowerShell are very easy to use and Microsoft has great documentation on this. I found myself making Powershell scripts to make mass-changes much easier and less vulnerable to human error due to the very repetitive nature of the default GUI.
I found a small issue with sorting when you have a large number of scopes in the DHCP administration GUI. When the GUI first loads sometimes you’ll find the scopes are out of order, or some are missing entirely. It sometimes takes a few refreshes (spamming F5) to get the DHCP scopes list to sort and load properly.
I would highly recommend a DDI tool to manage the DHCP infrastructure of large deployments. The Microsoft default MMC snap-ins are not appropriate for managing large-scale deployments of DNS or DHCP.
The default deployment of DHCP requires some tuning of the registry to properly handle a larger environment. The default for this registry setting is way too low if you have a busy DHCP server. The DhcpLogFilesMaxSize registry setting specifies the maximum combined size of one week’s worth of DHCP audit logs. If the audit logs exceed the size specified by this value, DHCP stops writing to the audit log until sufficient space becomes available. The default is 7MB, which would be equal to 1MB per day.
This registry setting needs to be tuned to your specific environment. Most of the time I’ve see the daily log files between 4MB t0 20MB. A setting of 256MB or higher would be ideal for starting off. Determine what your daily average log file size is, then multiple by 7. The DHCP service must be restarted following registry changes.
This particular registry tune I found to very notional among the IT communities. Depending where you look you always seem to get mixed opinions and answers. I think part of the reason for this is because it’s quite difficult to determine whether adjusting this registry value helps or not. This is just one of the many variables to consider if you’re having issues with DHCP performing dynamic DNS updates. However I have personally found increasing this value to be beneficial. Especially on higher volume DHCP servers that are doing a lot of dynamic DNS updates (wireless client or low lease duration scopes). The DHCP service must be restarted following registry changes. Again, this needs to be tuned specifically for the server.
This is a new registry tune (not enabled by default) that was introduced in Windows Server 2016 and patched for Windows 2012 R2 in Monthly Quality Rollup for Windows Server 2012 R2 (KB3197875). This helps keep the DNS registration queue small by only attempting registration once, instead of attempting 3 consecutive retries by default. In my experience the retires almost always fail as well which ends up clogging up the DNS registration queue.
A background process (scavenger) in DHCP server wakes up every hour, goes through the lease database and calls the DNS client API to register leases where the DNS update status is “Pending”. These attempts also go to the same DNS client queue mentioned above. If the queue becomes full, scavenger does not call the DNS registration API and moves to process the next unregistered IP address in the lease database.
- Create a new key called “DnsRegistrationMaxRetries” of type DWORD under HKLM\System\CurrentControlSet\Services\DhcpServer\Parameters
- Set the value of “DnsRegistrationMaxRetries” to 0
- Restart the DHCP service
- Note: If you already have KB3197875 installed, the “DnsRegistrationMaxRetries” may exist with value 3. You need to change the value to 0 and reboot the DHCP Server.
Do you have experience with large DHCP deployments? Comment below!