Restore AD controller always seems to go poorly - what am I doing wrong?

[mvalpreda]

Hyper-V on Server 2016, made a backup with Veeam 9.5u3 of an 2008 R2 DC and then restored it to a different 2016 Hyper-V host with a 'segmented' network in Hyper-V. Restore seemed to go fine, but when I start up the machine, it takes anywhere between 5-20 minutes to get a login screen - sits on 'Applying computer settings...' the whole time. When I do finally log in, it will sit on 'Preparing desktop' for a while and once I finally get in.....neither AD nor DNS works.

Have done this in the past for other DR testing and seen where AD seems to take 30-45 minutes before it 'works' again. This time it doesn't seem to be working. I can't imagine this is how it is supposed to be. All services are started and this server holds all the FSMO roles. Lots of errors in the Event Viewer about not being able to contact a DC. What is interesting is the NETLOGON and SYSVOL shares are present.

Am I doing something wrong with my restore? Maybe the backup? I am using AAP and the backups are always successful.

[Mike Resseler]

Hey Mark,

Did you check this article: https://www.veeam.com/kb2119

Could you let us know what scenario you are trying?

[HErceg]

Hi Mike,

I read instructions from provided link, but I don't see an explanation how to first boot restored DC in DSRM mode?From what I understand restored DC must be booted first in DSRM mode?
I can do it once DC is booted, but how to do it before?

[Mike Resseler]

Hey HErceg,

Press F8 immediately after the POST process completes to bring up the Advanced Boot Options menu.
Select Directory Services Restore Mode from the menu. The DC will boot into DSRM.

That should do the trick (which means you need to start the DC and look at the console in Hyper-V to see it booting)

[Rumple]

If your IP range has changed in that isolated segment, that would certainly explain the issues since AD just does not work at all once the IP is changed. I would also recommend setting up the local windows backups to just dump a system state to the local drive as a CYA..then you can restore the VM as indicated, use the DSRM and worse case, restore the system state and that should make AD all happy...assuming of course its restoring into the same network subnet and the DC is configured to talk to itself first for networking and the networking is active.

Personally though, I never restore AD controllers except in very small environments. I just run multiple controllers on different boxes so the restore is for catastrophic issues like crypto...and then I have a backup and a good system state.

[Mike Resseler]

Mark,

I am a believer of the same. When a DC is going crazy, spin-up a clean one, promote it and cleanly remove the old one. However, as you said yourself, in smaller environments with only 1, maybe 2 DCs...

[HErceg]

One sidenote about DC restoration.POST process is needed, but choosing it during first boot can be missed.Usually it goes fast and I know a lot of people that didn't press F8 in time, but they manage to do it in second or third attempt.
What would happen in that case?

[Mike Resseler]

Not much actually... It will boot, contact the other domain controllers and figure out that it is behind and will try to start the replication to get up-to-date with the others

[HErceg]

So basically POST is not must-do for restoring DC?

[Mike Resseler]

Not if you have other domain controllers that are still good. Then you can consider that domain controller as a domain controller that had a really long reboot
Well, at least with Veeam. This blogpost: https://www.veeam.com/blog/how-to-recov ... ction.html still stands so it should give you a good insight in the inner workings

[bhagen]

As I'm learning to use virtual labs (and after many phone calls with support to figure the whole thing out), I've run across an issue that's very consistent: when I add a windows server 2016 domain controller from a replica to an application group, and then add that application group to a surebackup job, and then run the job, this happens:
(I'm watching the boot process from a VMware Remote Console)
The DC loads to a login screen, but the network icon in the bottom right has a red X in it. This takes maybe 10-15 seconds.
It stays at the boot screen for about 30 seconds, and then reboots
It comes up to the "Applying computer settings" screen, and sits there for - literally - an hour. I've timed it. Several times.
After an hour, the login screen appears.
Other VMs in the application group boot up as expected; to a login screen, and I can get logged in.

Any ideas why this is happening, and/or how to change it?

Settings for the DC in my application group are:
No roles
Startup Options
Memory 100%
Max allowed boot time 300 sec
App init timeout 60 sec
No boot verification (because if either of these are checked, the job will fail...unless I set App init timeout to over an hour)
No Test Scripts running
Domain Admin credentials

Any insight into this "applying computer settings" issue would be awesome. Thanks!!

[Regnor]

Can you assign your DC the role 'Domain Controller (Authoritative Restore)' and retry your Surebackup Job?

[bhagen]

Interesting thought. Does that box actually cause the dc to be authoritative? Or is it just saying to run the script that runs checks on an authoritative dc?

[PTide]

Hi @bhagen,

The issue might not be directly related to SureBackup. Moreover, I've seen several discussions out there in the Web that describe the same behaviour even without Veeam in place.

Kindly review this thread (make sure to check the KB in this post) and let us know how it goes.

Thanks!

[Regnor]

Yes, the DC checkboxes define how the DC boots; either authoritative or non-authoritative.
Without either checkbox the DC won't be operational.

[ChrisGundry]

We found adding a 2nd DC to the lab made a big difference. We have 2 DCs in our lab, the first is configured as authoritative restore and the 2nd is not configured as a DC in the lab settings. This boots both DCs pretty quickly, I have not timed it but it is up and running from backups within 5-10 minutes I would say.

When we tested with just a single DC we found that it would take a lot longer to start up, often fail and 90% of the time VMs within the lab would boot up and set their FW to public/private not domain mode, so would fail to ping etc.

[bhagen]

Interesting! I, too, discovered that if I add a 2nd DC things go "better". First DC I made authoritative, 2nd I made non-authoritative. Still takes over 30 minutes. I'm going to try making the 2nd DC "not" a dc and see what happens.

This is only in a single-host scenario; I still can't get multi-host to work, but I saw your post in my other thread about that so I'm going to go check that out. Thanks!