2012R2 DC FSMO Holder Restore in LAB (Testing DR)

[Wad4iPod]

Must be missing something
https://www.veeam.com/kb2119

2-site <vpn> forest; on different subnets.
D/F started as a 2003 functional level. It has transitioned from 2003 > 2008R2 > 2012R2.
Still at FRS vs. D-FRS.

LAB Efforts: Restoring a Standalone FSMO holder (and) Replications partner -- fails to become/advertise as a DC.
The VEEAM article above mentions performing an 'authoritative restore' of AD to overcome the lack of replication partner. Looks like the 'Authoritative Restore' via ntdsutil was deprecated in W2008.
https://social.technet.microsoft.com/Fo ... inserverDS

Adding the HKLM\System\CurrentControlSet\Services\NTDS\Parameters\Repl Perform Initial Synchronizations =0 doesn't seem to resolve lack of replication partner and allow AD DS to work. Unless I need to wait a few hours?
https://standalonelabs.wordpress.com/20 ... ntrollers/

- BTW: If I restore the replication partner in my lab along with the FSMO - all is well in AD DS.

IN the LAb I am about to remove the replication partner from the FSMO DC to see that will allow AD DS to work.

Anyone have a suggestion and/or process to get a VEEAM (App Aware backup) 2012R2 DC (fsmo) forest replication partner to start AD DS without its replication partner online?

Thanks in advance.
-K

[Wad4iPod]

Looks like I am not the only one noticing this 'New issue/process'?
I test many different forest/domain/site/plant restores (offsite DR scenario) once in a while. The single DC or SBS restores still go off without a hitch. The multi DC restores seem to now behave differently.
In my current lab restore - this is the behavior - I am not expecting to see.

I restore the DC - 1 of 2. This one is the Main site in a 2 site Forest/Domain and it holds all of the FSMO roles, and still using FRS to replicate SYSVOL as the Domain began at 2003 and DFRS migration has yet to be performed..
Power it on. Windows boots, sits for about 1-3 minutes and then reboots. I login to the server console. **For the next steps I have about 5 minutes of AD DS successful operation(s) until things begin to fail.
--** I suspect this may be why folks using Sure Backup may get successfully passed a failure result?

I check for Sysvol Share - Yes, Netlogon and Sysvol are shared - and NLA tells me I am on a Domain Network. I launch (any of the) AD DS tools and they work fine.
I keep my \\servername explorer window open. Then I notice that the Netlogon and sysvol are gone; no longer shared. Checking the Sysvol\domain folder the scripts and policies folders are gone, replaced by a ntfrs_preexisting___see_eventlog.

All AD DS tools and such fail from here on out.

I can no(t) -longer- perform a Sysvol Authoritative restore (burflags=4).

I am beginning to think that the VEEAM magic automatic Non-Authoritative restore is messing things up. Since the second DC and its replication are not available for any 'election' process, or authoritative reconciliation

Today I am going across town to get the 2nd DC/site VEEAM backup. I will restore it in my lab as well. If both DC restorations prove to bring AD DS back alive - this may be a revelation.

Basically, I am UNABLE to restore a Crashed multi-DC Forest without at least 2 DCs in the restoration. Could this be Microsoft's "That's Just the Way it is" worldly response?

Other folks that test DR are encountering the same issues (validating my results).
https://forums.veeam.com/vmware-vsphere ... 48568.html

[Wad4iPod]

Hope this helps save someone else time
A recent (I do these a few times a year for most clients) VEEAM (non-production:lab) recovery of a FRS [ding, ding, ding – danger Will Robinson: FRS] multi-site forest (effectively a crashed forest recovery) – presented the challenge of: you MUST press ‘F8’ before the SECOND reboot.

This after the first automatic reboot. Then enter DSRM. You will need to change the VEEAM automatic entry of the (FRS) Burflags from D2 (non-authoritative) to D4 (authoritative), or to perform an authoritative synchronization of DFSR-replicated SYSVOL (like "D4" for FRS).

If you miss this opportunity to catch the F8– you’ll have to re-restore the DC and try again. *You have to be quick on the ‘F8’.
In my test restore – The DC’s were all non-authoritative – ‘No One in Charge’. The DC’s would not replicate without one being authoritative.


Interestingly enough – without an ‘F8’ intervention - the VEEAM non-authoritative DC restore process takes about 5-minutes after the second reboot to complete. At this point (10 minutes after the completed second reboot) the DC is no longer a DC. None of the AD DS tools work, no shared Sysvol or NETlogon folder, etc.
--This is where I believe Sure Backup indicates a successful backup – as the DC is Authoritative long enough to pass SB tests.

VEEAM’S article is a bit lacking in its process. NTDSUTIL ‘Restore Database’ was deprecated with W2K8.

https://www.veeam.com/kb2119