4

We have four DCs (Windows 2008 R2) running on VMware, backed up with Veeam.

Currently doing some DR testing. If I restore a DC (full VM) from backup (obviously isolated from our production environment) I cannot log in. I receive the error message:

There are currently no logon servers available to service your request

If I remove the NIC, I can log in.

Once in I can add a new NIC but I'm still seeing a lot of SRV record errors. But that aside, if I reboot with the new NIC I get the same problem, need to remove it otherwise I can't log in.

What is happening here? I haven't tried DSRM, is that basically our only option, supported or otherwise?

UPDATE: Booting into DSRM and doing an authoritative restore seems to have no effect. We can still not boot into the DC unless we remove the NIC.

Also, after logging in and giving the NIC the IP addresses of all four DCs, restored clients don't function correctly, even though they can ping the domain by NETBIOS name and FQDN.

Matt
  • 1,893
  • 5
  • 28
  • 40
  • This sounds like serious AD problems - possibly the DC isn't functional at all. Does `dcdiag` turn up with any problems on either the original or the recovered VM? DNS records all in order? – Zac67 Sep 20 '17 at 20:03
  • We have a script that runs dcdiag every day on all our DCs and raises an alert if there are any errors, so all is fine in our LIVE environment. I'll check the recovered and report back. – Matt Sep 20 '17 at 23:19

1 Answers1

2

According to this Veeam document, and implied by this Microsoft document, a restored (or cloned) DC will boot into DSRM, and there's no way to tell from the login screen. It does flash up briefly stating this is what's happening (even if you select "Start Windows Normally"), but you have to be quick to see it.

Logging in (successfully) with the DSRM password confirmed this was the case.

The Veeam article suggests opening a command prompt and running the following:

bcdedit /deletevalue safeboot
shutdown -t 01 -r

The MS article advises the same but doesn't give the commands.

Rebooting after this allowed a successful login with domain credentials.

Matt
  • 1,893
  • 5
  • 28
  • 40