We help IT Professionals succeed at work.

Why won't my 'authorised' clustered DHCP server recognise on the network?

TJR80 asked
Hey all,

I'm running a Windows 2003 R2 File/Print/DHCP 2-server cluster, and everything's working ok except for DHCP. There is an existing DHCP server there (also running 2003(, and I've set this new one up to have exactly the same ranges/reservations etc., not by importing/exporting but by setting it up manually to be the same. DHCP rolls successfully from server to server, as do the rest of the clustered services.

Once we were completely ready to roll, I unauthorised the existing DHCP server, waited until it was no longer running, then authorised the new DHCP server (a virtual name), which popped into the authorised list and appears to be running - this is where the problem lies...

I am a domain admin, but NOT an enterprise admin. I know that that normall stops authorisation, but in this case I've checked AD Sites and Services, and for this site Domain Admins have all rights except 'delete all child objects'. Both servers are unregistering and registering without throwing up any errors (although it takes about 25mins - worldwide network, can be slow?), however the new DHCP server cannot be found by any workstations on the network. The cluster itself can see everything on the network, and the virtual name can be seen by everyone once a fixed IP is assigned, and re-authorising the original DHCP server will return fnuctionality to the network, but I cannot for the life of me figure out why this new one will not return any leases.

I've tried waiting for an hour, rebooting the workstations time and time again, checking Group Policy to make sure there's nothing interfering, checking Microsoft walkthroughs and other questions here to make sure I haven't missed anything obvious, and no luck. The only two things I can think of are the Enterprise Admins thing, and I found a single reference to DHCP servers being in a router's IPhelper table, but to my knowledge that hasn't needed to be done before. I have previously changed DHCP over to clusters on 4 sites (WITHOUT changing the server name - just used a virtual name of the same for it to run off) without a hitch, however in this case the original server cannot move or change for various reasons, but we do need to cluster DHCP.

Any help is GREATLY appreciated, thanks!
Watch Question


Run a cluster MPS report from here:

Post the following files from the generated CAB file.
Cluster MPS Information.txt
Cluster Resources.txt


Here're the results (Edited for Servername and IP addresses as appropriate) - thanks


This may be obvious, but anyway - DHCP is currently disabled as it's the same range as the existing server, and the print spooler is disabled because of an unrelated thing.
Most Valuable Expert 2019
Most Valuable Expert 2018
To start with gthe basics: have you checked if a machine in the same network as your DHCP server can obtain an IP address (create a temporary scope, if necessary)?
As far as "and I found a single reference to DHCP servers being in a router's IPhelper table, but to my knowledge that hasn't needed to be done before" is concerned: this may be obvious, too, but it seems as if the new DHCP server has a different IP address than the old one; if this is the case, then you will have to change the IP helper addresses on your routers, otherwise workstations in another network won't be able to find the DHCP server, because the routers will continue to forward the DHCP requests to the old server.
You have two options to change that:
1. Add the new DHCP server's address to all routers as secondary target for DHCP queries; this is usually possible, and if the first server doesn't react, the next one will be used. That way, you have all the time in the world to change your routers, and when that is done, you can just shutdown the old DHCP service and use the one on the cluster.
2. Shut down the old DHCP server (or change its IP address), then use its old IP address for the DHCP cluster resource.
And just in case: in the properties of the clustered DHCP server, make sure it's (only) listening on the public IP address you want to use.


Hmmm....ok, that makes sense - unfortunately I know next to nothing about networking, so the IPhelper table is a bit foreign to me, but I'll get it done somehow. You're right - the new DHCP server is a different name and IP from the current one, but I had assumed that since it was in the list of authorised servers on the domain, that it would be the first target for workstations in the same site.

I can't change the IP of the current DHCP server for unrelated reasons (it's a specialized app server too), but I'll give the IPhelper table updating a shot in a few hours and let you know how it goes.

Thanks a million for the help - I REALLY appreciate it!


Oh, I forgot to mention too - with the 'can a machine on the same network find a dhcp address' - they can with the current dhcp server, however the new server on the same network (just different IP), and they can't. The Server and the workstations are on a different vlan (.196.xxx / .197.xxx), as the server vlan is not dhcp and the workstation one is - is that what you meant by 'the same network', or did you mean the same physical network?

Again, my apologies - I'm pretty useless on the whole networking thing.
Most Valuable Expert 2019
Most Valuable Expert 2018

A different VLAN is basically the same as a different physical net; so yes, that's what I meant.
The workstations can't get their DHCP server information from AD - DHCP happens way before AD access (no IP address, no AD, and the IP address is coming through DHCP ...). DHCP is broadcast based, so in order for the workstations to find a DHCP server in another subnet, they needs an instance in the local subnet that will handle the local requests for them and forward them to a real DHCP server, and that's done (usually) with the IP helper addresses in the router. If the router doesn't have the (correct) IP address of the DHCP server, it obviously can't forward the DHCP requests, and the workstation won't get an address.

Looking over the setup, I see one major issue - You dont have a heartbeat connection setup. You should have one network card that handles the server requests and another one that only takes care of the communication between the servers.

Here is an article on how to setup your heartbeat connection.

It also looks like you are using the BASP virtual adapter (maybe BCOM team??)- This should be a physical connection and not the Virtual bus driver (Should read something like BCOM 57xx Gigabit adapter). Running DHCP on a team is not necessarily the best thing to do either. I could see how that could cause troubles. Running the NICs as a team, and not having a heartbeat, is not good at all - the heartbeat cannot be teamed and you are currently running the heartbeat over the teamed interface. (See Cluster networks information on the mps information file - you are running all comm through the prob team network. Ideally you should have one physical interface as heartbeat - private communication 1 on network priority. Another nic as the all comm. with priority of 2)

The above 2, are the most likely problems causing the DHCP not to work. Unfortunately, you will also probably have to start from scratch on your cluster setup to get this working (at least easily - there is always a manual method for everything).

There are some other general cluster possible issues as well...
I am not sure if these have anything to do with the issue that you are seeing, but it will help your cluster be more stable once you get it up and running.

You really should not have anything other than your quorum resorces on the physical disk/disk array that your quorum is stored on. Currently you have the R: drive on there as well.

Cluster groups should also be seperated out into seperate resources with one disk group per resource (or more depending on the type of service(s), like exchange / sql - seperate disks for transaction logs / DB - which doesnt apply here.)

With what you are trying to do, I would probably have the following groups:
Cluster Resource Group
  Cluster IP Address
  Cluster Name
  Disk q: (do not partition the remainder of the disk - recommend using the smallest disks available for this)
File Server Group / Print / DHCP group (combined only due to lack of available physical disks)
  Disk S
  Group Name
  Group IP address
  File Share(s)
  Print Spooler
  DHCP Service

(Ideally, you could seperate these out so that the File server, print spooler, and dhcp service have their own resource groups but this would require more seperate shared physical disks).

This will allow you to fail over any one of these groups to troubleshoot or perform maintenence on the cluster.

I would also look over the following documents in depth to make sure that you have everything setup properly:


Let me know if you have any additional questions.


The update in the IPhelper table was exactly the thing needed - you're a life saver! Sincere thanks for taking your time and effort.


Thanks to everyone for helping - oBdA's solution was the one that got me running, so thanks again oBdA!

brent_caskey - thanks for giving extra information; that will come in handy in the future for sure (I'm a relative novice with building clusters, only built 4). With the disks, I know what you mean about the quorum resource, however I didn't mention that the servers are hooked up to a SAN, so no matter how I format the LUNs they'll still be spread over the same physical disks (I believe). This is a relatively small site too - those groups that you mentioned are split up to a much finer degree on one of the larger sites I support, with individual LUNs for Printing, DHCP, several file shares etc., so I agree with you in principle; just that this is only a failover config and not performance-oriented, so everything will move at once if a server goes down, negating the need (as I see it) for many smaller groups.

Once again, thanks to all - GREATLY appreciated!

Explore More ContentExplore courses, solutions, and other research materials related to this topic.