Can I have multiple DHCP servers on one network?

Is it possible to have more than one DHCP server on the same LAN? What are the implications of doing this?

1. What happens if there is more than one DHCP server available? How do my clients know which one to use?
2. How can I have DHCP servers supplying addresses to more than one subnet\network segment?
3. How can I configure multiple DHCP servers to supply addresses for the same subnet.

DHCP on a simple network works using the DORA principle.

• Discovery - the client broadcasts a message on the local network segment its connected to, to discover available DHCP servers.
• Offer - a suitably configured DHCP server receives a request from a client, and offers it an address from its pool of available addresses.
• Request - The client replies to the offer, requesting the address received in the Offer.
• Acknowledgement - The server acknowledges the request, marking the address as used in its pool of addresses, and informs the client of how long the address lease is valid for, and any other information needed.

Any device on a network segment can be a DHCP server; it doesn't have to be the router or the domain controller or any other "special" device on the network.
When the devices on your network first request an IP address or reach the end of their leases (or you force them to check their lease is still valid) they will simply broadcast a request for a DHCP server, and will accept an offer from the first DHCP server to reply. This is important to remember as we look at the options for multiple DHCP servers below.

Multiple DHCP servers PT 1: Spanning multiple subnets.

If you have several VLANs or physical network segments that are separated into different subnets, and you want to provide a DHCP service to devices in all those subnets then there are two ways of doing this.

1. If the router / layer 3 switch separating them can act as a BOOTP/DHCP relay agent, then you can continue to keep all your DHCP server(s) in one or two central parts of your network and configure your DHCP server(s) to support multiple ranges of addresses. In order to support this, your router or layer 3 switch must support the BOOTP relay agent specification covered in section 4 of RFC 1542.
2. If your router does not support RFC 1542 BOOTP relay agents, or if some of your network segments are geographically dispersed over slow links, then you will need to place one or more DHCP server in each subnet. This ‘local’ DHCP server will only serve its own local segment’s requirements, and there is no interaction between it and other DHCP servers. If this is what you want then you can simply configure each DHCP server as a standalone server, with the details of the address pool for its own subnet, and not worry about any other DHCP servers on other parts of the network. This is the most basic example of having more than one DHCP server on the same network.

Multiple DHCP servers PT 2: DHCP servers that serve the same network segment.

When most people ask about “multiple DHCP Servers on the same network”, what they are usually asking for is this; they want more than one DHCP server issuing the same range of network addresses out to clients, either to split the load between multiple servers or to provide redundancy if one server is offline.

This is perfectly possible, though it requires some thought and planning.
From a “network traffic” point of view, the DORA process outlined at the start of this answer explains how more than one DHCP server can be present on a network segment; the client simply broadcasts a Discovery request and the first DHCP server to respond with an Offer is the ‘winner’.
From the server’s point of view, each server will have a pool of addresses that it can issue to clients, known its address scope. DHCP servers that are serving the same subnet should not have a single “shared” scope, but rather they should have a “split” scope.

In other words, if you have a range of DHCP addresses to issue to clients from 192.168.1.100 to 192.168.1.200, then both servers should be configured to serve separate parts of that range, so the first server might use parts of that scope from 192.168.1.100 to 192.168.1.150 and the second server would then issue 192.168.1.151 to 192.168.1.200.

Splitting the scope – best practice

One thing you’ll hear mentioned as best practice is the 80/20 rule for splitting a DHCP scope, which means that one server will serve 80% of the addresses in that scope and the other DHCP server, which is effectively ‘in reserve’ will serve 20% of the addresses.
The idea behind splitting the addresses 80/20 is because 80% of the addresses available should hopefully be adequate for all the addresses needed on a subnet, and DHCP leases are typically issued for several days; so if your main DHCP server goes down for a few hours then it's unlikely that more than 20% of the machines on that subnet will need to renew their addresses during the downtime, making the 20% pool of addresses sufficient.
This is still reasonable advice, but it assumes two things:

1. That you can solve any problem with your “main” DHCP server quickly enough to avoid exhausting the small pool of addresses on your reserve DHCP server.
2. That you’re not interested in load balancing.

These days (as you can see from my examples) I tend to prefer 50/50 splits, which I think are a more realistic answer to the above points.
Another thing to consider when creating your scopes on the DHCP servers is configuring the full scope into each server and excluding the range given out by the other DHCP server. This has the benefit of “self-documenting” the DHCP info for the full subnet on each DHCP server which will improve clarity for anyone else trying to understand what is going on, and also in the event of one of your DHCP servers being offline for some time, you can temporarily reconfigure the exclusion range on the other server to allow it to pick up the slack.

Combining these ideas

Lastly, its worth remembering that you can combine the principles discussed above - you can place all your DHCP servers into one or more "central server" VLANs and use BOOTP relay agents on all your routers to send all DHCP requests from a very large and segmented network to a centralised DHCP service (which is what I do, see below). Or you can have DHCP servers distributed throughout your network, with a "main" DHCP server in its local subnet and a "reserve" DHCP server on a "nearby" network segment providing a small amount of addresses as a backup - you could even have two DHCP servers in their own network segments configured to provide an 80/20 range of addresses for each other. The most sensible choice will depend on how your physical and logical networks map to each other.

What are your favorite SysAdmin tools for Windows?

And here a short list of my favorites tools :

• Notepad++
• RSAT (Remote Server Administration Tools for Windows 10)
• Tools from the Sysinternals Suite, AccessChk, Autoruns, Process Explorer, Process Monitor and others.
• PingInfoView (Nirsoft), a small utility that allows you to easily ping multiple host names and IP addresses, and watch the result in one table
• TreeSize
• USB Disk Ejector, allows you to quickly remove USB (and firewire) drives in Windows.
  DeviceTool, a Device Manager for administrators. DeviceTool can enable and disable devices remotely – and run on Windows 10.
• Rufus, a small portable tool to create bootable USB Flash drives, includes an option to download the Windows.
• Microsoft WSUS Client Diagnostic Tool, designed to aid the WSUS administrator in troubleshooting client machines which may be failing to report back to the WSUS Server.
• Putty
• RVTools, windows .NET 4.6.1 application which uses the VI SDK to display information about your virtual environments. Interacting with VirtualCenter.
• vCenter Converter, quickly converts local and remote physical machines into virtual machines without any downtime.
• Starwind V2V Converter, makes VM and virtual disk migration between different hardware sets easier by booting the migrated VM in Windows Repair Mode.
• mRemoteNG – Free tabbed remote desktop management tool.  Allows you to save different credentials for various machines.  I just wish they had a search.
• SecureCRT – paid ssh management tool – remote into switches, routers, etc.
• PDQ Deploy/Inventory – paid application management software, scan machines to see what’s out there, update install or remove software on a schedule.
• ASG Remote Desktop – best RDP tool I know – free for max 3 connections, unlimited connections + option to have connections/credentials in SQL database in paid version
• Powershell ISE
• ISE-Steroids – paid plugin to ISE
• Keepass – ultimate tool for password management, amazing auto-type feature
• Greenshot – really nice, rich, easy and free print screen tool
• f.lux – adapts screen color temperature based on day time – eye saver
• Ditto  – easy clipboard manager
• Filezilla – FTP client/server
• WinSCP – transfer files over SSH
• PAL 2.0 – performance log analyzer
• Regshot – capture Registry snapshot allowing to compare the Registry before and after some changes
• TreeSizePortable – disk space info
• BlueScreenView – BSOD dump analyzer

Offline activate the built-in administrator on Windows 10 without signing in

If you no longer have access to a Windows 10 computer, say because you forgot the password of your Microsoft account or because the trust relationship between the workstation and the Active Directory domain failed, you need a local account with administrator rights. If you haven’t used the local account for a while, you also might not remember its name and its password. It is also possible that no other local account exists on the computer for security reasons.

In such situations, you can follow the procedure described below to offline activate the built-in administrator account.

1. Boot from your Windows 10 setup media. You might have to change the boot order in the BIOS of the computer if Windows 10 starts after you inserted the media. After Windows setup has started, you have to press SHIFT+F10 to open a command prompt.
   
2. Next, find the drive letter of the drive where Windows 10 is installed. The drive letter might be different from the one you use when you boot up Windows 10. The Windows setup media is usually on X: and, in most cases, Windows 10 is located on drive D:. To get an overview of the available drives you can run echo list volume | diskpart. You can recognize the correct drive by viewing its contents with the dir command (dir d:\users). The date of your profile folder should show the last date you logged on.
   
3. You can now replace the utilman.exe file with cmd.exe in the system32 folder of the Windows 10 system directory. But first you have to create a copy of utilman.exe so that you can restore it after you activate the administrator account. Make sure you use the drive letter that you found in step 2:
   
   
   

   move d:\windows\system32\utilman.exe d:\ copy d:\windows\system32\cmd.exe d:\windows\system32\utilman.exe

   1 2	move d:\windows\system32\utilman.exe d:\ copy d:\windows\system32\cmd.exe d:\windows\system32\utilman.exe

   
   
4. Now, remove the boot media and reboot:
   
   
   

   wpeutil reboot

   1	wpeutil reboot

   
   
5. Wait until Windows 10 boots up, press a key, and then click the Accessibility options A command prompt should open on the login screen. At this point, you have full access to your Windows 10 installation without having signed in. You could also reset the password of any account.
   
6. You can now enable the built-in administrator account. You should also set a password because, by default, the administrator account password is blank:
   
   
   

   net user administrator /active:yes net user administrator <your password>

   1 2	net user administrator /active:yes net user administrator <your password>

   
   
7. After you close the command prompt, you can sign in with the newly activated administrator account. If the computer does not belong to an Active Directory domain, you can just enter “administrator” as the user name after you click Other user. If the computer is a domain member, you should add “.\” in front of the name (.\administrator) to ensure that you log on locally:
   

After you sign in, you might want to restore the original utilman.exe. To do so, you have to boot again from your Windows 10 setup media and open a command prompt as explained in step 1. Then, you have to enter this command to restore utilman.exe:

move /y d:\utilman.exe d:\windows\system32\

1	move /y d:\utilman.exe d:\windows\system32\