It might not be a particularly exciting technology, but DHCP and similar services are a key part of your ability to deliver a service to your users, just like Active Directory, DNS, time synchronisation, and the core network itself. It’s easy to become complacent about the basics when you’re focussed on the next big thing.
Discover, Offer, Request, Acknowledgement. How many of us remember learning that brief conversation between a computer and server as it joins the network?
Chances are if you have even a small network DHCP is running on some device somewhere. It’s probably been left untouched since the network was set up and barely given a thought. In an Enterprise network some thought would have been given at the time to where the service should run, and it’s probably on several Windows servers across the organisation quietly getting on with giving IP addresses to all those mobile devices as they come and go. Until one day it isn’t.
The problem with networks services is that they’re often ignored until they break. They don’t form part of the exciting world of cloud computing, microservices, DevOps and AI. Even so, it’s definitely worth taking a few moments to review your key infrastructure services and confirm that they are still the efficient, reliable services you envisaged. Some of these services cannot be operated in public cloud environments, and DHCP is one of them.
So you’ve had a quick look in Active Directory at your authorised DHCP servers. Hopefully they’re all as expected and no new ones have sprouted up since you last looked. They are of course all running on modern supported versions of the Windows Server OS. If their not virtual (why not?), the hardware is all fully supported and spares are available? Great!
Back to basics
Now, how many servers do you have, and how many do you need? If they’ve been around a few years it may be that DHCP was installed as part of a remote branch server on the other end of a WAN link along with maybe an RODC, Endpoint Configuration Manager distribution point, file server with BranchCache, local print server, etc. With the increasing centralisation of IT infrastructure the ability for a remote site to function without the WAN has become more limited, and branch servers are hardware you need to manage to the same standards as the rest of your infrastructure….somehow. Is that effort still justified?
When the scopes were originally defined, was it on a much earlier version of the Windows OS? If so, perhaps it’s worth looking at the scope configuration. There’s the usual checks on IP ranges, exclusions, reservations, scope options and such, and pruning any old configuration. Then there may be new features available – the DHCP service in Windows has come a long way since the early days and we now have active/active scopes for resilience, and the ability to back-up the configuration via the GUI and via PowerShell.
Trying to avoid IP address clashes when moving DHCP scopes between servers used to be a headache. Now PowerShell cmdlets exist which can export and import active lease information, smoothing the migration process.
Keeping an eye on things
Monitoring DHCP activity is pretty straightforward. The Windows Event Log has all the information you’ll ever need, but then it’s only useful if someone is looking at it. Ensure that logs are integrated with your SIEM tooling. Consider Azure ARC to integrate your on-premises servers with Azure for management, metrics and alerts. Logs can be forwarded to a Log Analytics workspace and provide insights across the entire infrastructure.
Fringe benefits
In addition to being able to sleep easier, there are financial benefits of spending a little time reducing technical debt. You may be able to remove that old hardware and remove it from the hardware maintenance contract, as well as reduce the effort required by support staff to maintain it. Even if you don’t move anything, removing accumulated cruft will make any future problems far easier to troubleshoot, improving recovery times and reducing business impact.
