We have two VMware virtualised DCs which have just undergone a scheduled Windows Update round and reboot. The secondary DC completed with no problems but the primary failed to reboot and ultimately the VM had to be rebuilt using the virtual hard disks from the original VM. Now, DHCP on the primary is not working.
The ESXi host is on 6.5.0, virtual hardware is v13 and VMware Tools is 10.1.15. DC OS is Server 2008 R2 Std. SP2.
DHCP is working on the secondary DC but this is located at another site and on a different subnet so as a workaround, we've had to enable the DHCP server on the firewall. Everything looks okay on the primary and there is nothing to indicate what has gone wrong. We've re-created the DHCP scope and rebooted the server but this has had no effect.

Has anyone experienced anything similar?

  • With this little information it is pretty hard to make a remote diagnosis. Can you check the eventlog for more information? I'm pretty sure you'll find the reason there. – Makorus Apr 10 '18 at 10:27
  • I appreciate that this is a difficult one to resolve or even aid with! There were no DHCP-specific events and nothing else indicating a problem with the DHCP services in the Event Viewer following the initial reboot. We have now reinstalled the DHCP service but are encountering a new problem with DHCP not authorising. Error 0x80074e54 (looking this up now). – Rich M Apr 10 '18 at 11:20
  • ultimately the VM had to be rebuilt using the virtual hard disks from the original VM. Now - What does that mean exactly? Give us details. I suspect that's where your problem lies. – joeqwerty Apr 10 '18 at 11:23
  • A new VM was created (rebuilt) through vCentre and the .vmdk files (virtual hard disks) from the old DC used in place of creating new ones. I did not do this myself. The old DC was having DHCP problems before the new one was built. – Rich M Apr 10 '18 at 12:52

Are you able to go in your DNS's console and such ? I suspect your AD was screwed up with your recovery method, especially if you VMDK is older than 6 months's old, as you end up with a tombstone DC in the best scenario, as it can be an USN rollback too (See more info there)

I would create another VM to DCPromo it and link it to the remote DC server, to phase out that problematic DC.

Never do a file level recovery for a DC that way, use systemstate backup please with like wbadmin.

  • We could access the DNS and DHCP consoles. It did seem like the DHCP server was encountering problems before we 'restored' though. I had read about the pitfalls of restoring a vDC and the USN problem but it wasn't actually me who did the restore. I think we're building a brand new 2012 R2 vDC to replace the broken one.... – Rich M Apr 10 '18 at 14:12
  • Can someone please advise what could go wrong with creating a new VM and simply attaching the old VMDK's? – Rich M Apr 10 '18 at 14:14
  • Puzzling thing is, everything else on the DC seemed fine: AD, DNS, printing, etc. It was only DHCP which was affected. – Rich M Apr 10 '18 at 14:20
  • @RichM Strange, but the VMDK are how much old ? Check the article I link for the USN roll back, that will explain what can go wrong with that strategy – yagmoth555 Apr 10 '18 at 14:23
  • They would have been no more than an hour old. Besides, all I have read on the USN problem suggests that this would affect the DC as a whole, not just a specific service such as DHCP? – Rich M Apr 10 '18 at 14:42

Did yours vms lost its static IP after patch?

DHCP server requires a static IP, check if you were affected by this issue: https://support.microsoft.com/en-us/help/4099950/nic-settings-are-replaced-or-static-ip-address-settings-are-lost-after


  • DHCP 'relies' on static IP? Can you explain what you mean by this please? Yes, we have been experiencing the loss-of-IP-address problem following Windows Update reboots, do you think that this could have caused the DC to lose its IP address and this, in turn, affected the DHCP server? (also, how on earth do you add a line break? The help says two spaces at the end of a line but this clearly does not work!) – Rich M Apr 10 '18 at 14:37
  • The link you've posted identifies the updates which cause the NIC/IP loss problem, but unfortunately (thanks Microsoft!) doesn't provide any solution. – Rich M Apr 10 '18 at 14:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.