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?
2 Answers
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– Rich M2018-04-10 14:12:56 +00:00Commented Apr 10, 2018 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– Rich M2018-04-10 14:14:11 +00:00Commented Apr 10, 2018 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– Rich M2018-04-10 14:20:50 +00:00Commented Apr 10, 2018 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 strategy2018-04-10 14:23:06 +00:00Commented Apr 10, 2018 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– Rich M2018-04-10 14:42:07 +00:00Commented Apr 10, 2018 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
Regards,
- 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– Rich M2018-04-10 14:37:41 +00:00Commented Apr 10, 2018 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– Rich M2018-04-10 14:48:12 +00:00Commented Apr 10, 2018 at 14:48
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.