Replicating a Domain Controller

[marius roma]

After replicating a Windows Server 2008 R2 Domain Controller I start the replica and I get a black screen with the option to start the VM normally or in command line mode.
At replication time the source VM is up and running.
I select to start Window normally and the VM starts, but when I try to logon with any domain user account I get an error saying that "There are no logon servers available to service the logon request".
If I clone the replica VM the clone starts with no problem an I can logon with no problem...
Given the source DC cannot be powered off at repliuca time, what is the best practice to replicate a DC and allow the replica work as expected?
Regards
marius

[Jfmoots]

On the Guest Processing page of your replication job, do you have a check in the box to "Enable application-aware image processing"?

What type of vNIC to you have configured on this machine?

What are you doing to make it safe to boot this DC in your enviroment? Are you "breaking" network connectivity to this replica when you boot it? Bringing up a copy of a production DC in production is scary to me...

How exactly are you starting the replica? Through the Veeam console by selecting "Failover" or are you manually starting it from the VI Client?

[Gostev]

Basically, you cannot pull a single DC from a multi-DC environment, and expect it to work in the isolated environment. Because what happens is it will fail to find replication partners (other DCs), and will stop the NETLOGON service.

Also, keep in mind that you must wait for the DC to automatically reboot (after it completes the VSS restore process) before attempting to logon.

One of these 2 points is likely the cause for your issue.

Please search the existing topics for more information and the detailed description of the DC restore.

[marius roma]

Thank you for the messages.

Let me provide somer further information:

- The DC is the only DC in its own forest
- The vNIC is E1000
- I try to start the replica from the vSphere client and the replica starts in black screen with the options to start in save mode or normally; I select to start Windows normally and Windows starts; should I start in safe mode?
- I start the VM replice from the vSphere client; consider I really don't want to start it (the source is up and running), I only want to be sure that the replica process was successfully and that the replica can start if I need it; should I start it from the Veeam console? Can I start the replica fron the Veeam console without creating problems to the source VM?
- There are no other DCs as the DC is the only DC in its own forest
- I don't configure the DC to automatically reboot as I don't want to reboot it; I only want to perform a test to see if the replica can reboot in case of need...

Any further help will be strongly apreciated...
Marius

[tkrajewski]

Hi Marius,
Do I understand it correctly, that at some point in time, you have two DCs, with the same names, IPs, MAC addresses, SIDs, etc, running in the same network? Or do you try to isolate replica before starting up in some non-production network?

Tomasz

[Vitaliy S.]

- I try to start the replica from the vSphere client and the replica starts in black screen with the options to start in save mode or normally; I select to start Windows normally and Windows starts; should I start in safe mode?

Please check an existing topic for the answer: Veeam B&R v5 recovery of a domain controller

[habibalby]

Hello,
I have created this document for my environment; hope it's applicable to yours.

Thanks,

Restoring Active Directory / Domain Controller using Veeam Backup & Replication

When Domain Controller backed up with Veeam software, the backup runs with VSS integration which will back up the NTDS database by butting the Active Directory Database into backup state like any other backup software or when System State runs.
Below is the procedure to restore Domain Controller after successfully backed up using veeam software.

1. Restore the Virtual Machine to the datastore that accessible by ESX host where the VM will run.
2. Once restoration is successful, make sure before you Power On the VM to put it in a private PortGroup. This will avoid conflicting the machine name / IP address with the production VM.
3. First boot it goes into safe mode Non-Authoritative Restore it’s by default
4. Second boot it goes into Directory Restore Mode. This will ask you to provide the local username and password of the domain controller / during DS setup:
a. Username: Administrator
b. PWD: Password
5. Third boot it goes again into Directory Restore Mode. If this is the case here's the trick. It goes into DRM because it doesn't uncheck the Safe Mode and Active Directory Repair in the Boot Option under the MSConfig System Configuration.
6. Run MSConfig and unchecked the Safe Mode boot and reboot the machine
7. At this step, the DC starts normally and it gives the below indications as the restoration successfully done.


Event ID Source Description
1004 DFSR The DFS Replication Service Started
6102 DFSR The DFS Replication Service successfully registered with WMI
1206 DFSR The DFS Replication Service successfully contacted Domain Controller “Name”
1000 ActiveDirectory_DomainService Microsoft Active Directory Domain Service Startup Completes
1394 ActiveDirectory_DomainService All problem preventing updates to the Active Directory Domain Services database has been cleared.

Note: This procedure tested on a “Test” Primary Domain Controller and an Additional Domain Controller that backed up from production ADC. If this procedure will be tested on a private environment where the Primary Domain Controller doesn’t exist or the Primary Domain Controller is Physical and doesn’t want to be interrupted it, then Sezing the FSMO Roles is required to have full function of Active Directory Service.

[dellock6]

Great how-to, thanks for it!

Luca.

[habibalby]

Great how-to, thanks for it!

Luca.

Thanks dear

[marius roma]

Many thanks to everybody for the answers and the support.
Lert me ask for some further clarification and provide some further details.

Hi Marius,
Do I understand it correctly, that at some point in time, you have two DCs, with the same names, IPs, MAC addresses, SIDs, etc, running in the same network? Or do you try to isolate replica before starting up in some non-production network?

Tomasz

I have two separate vSphere infrastructures in two separate places, with different IP addresses.
What I expect, from replica, is being able to power on my DC (I repeat, it's the only DC in its own forest...) in the replica site in the simplest possible way.

In topic "Veeam B&R v5 recovery of a domain controller" (see http://forums.veeam.com/viewtopic.php?f ... er+restore) Gostev says:

1. DC will always boot in non-authoritative mode, which is exactly what you want most of the time. You should not need to perform authoritative restore in most cases unless your Active Directory corrupts or something because, authoritative restore reverts AD to the earlier point in time and can cause too many additional issues by itself. It is really the last resort. But if you need to perform it from Veeam backup, there are existing discussion with verified procedure posted on this forum that you can refer to.

Should I presume that my AD got corrupted during the replica process? I think I don't need to boot in non-authoritative mode, as I presume that my AD is not corrupted.
Can I just skip the AD recovery process and boot my replica normally?

Thanks to habibalby for the detailed instuctions, but is there a way to skip the suggested procedure?

1. Restore the Virtual Machine to the datastore that accessible by ESX host where the VM will run.
2. Once restoration is successful, make sure before you Power On the VM to put it in a private PortGroup. This will avoid conflicting the machine name / IP address with the production VM.
3. First boot it goes into safe mode Non-Authoritative Restore it’s by default
4. Second boot it goes into Directory Restore Mode. This will ask you to provide the local username and password of the domain controller / during DS setup:
a. Username: Administrator
b. PWD: Password
5. Third boot it goes again into Directory Restore Mode. If this is the case here's the trick. It goes into DRM because it doesn't uncheck the Safe Mode and Active Directory Repair in the Boot Option under the MSConfig System Configuration.
6. Run MSConfig and unchecked the Safe Mode boot and reboot the machine
7. At this step, the DC starts normally and it gives the below indications as the restoration successfully done.

To resume, given I have a DC in une site and I need to have a replica in a replica site, and given I must be able to start the replica in the simplest and fastest way, is replica the right tool?
Should I do anything else?
By the way a made a test and cloned the replica using vShpere tools. The clone of the replica boots normaly with no visible problem. But it's, obviously, a complicated solution...
Regards
marius

[habibalby]

AD is a complicated product of microsoft and purely depends on USN even cloning it is not supported at all or snapshoting it. But veeam the excellent backup product of Virtualization, made MicroCrap to beleive is a supported product to backup application-aware of MicroCrap products.

Alternative methods you can replicate your DC and on your production DC, make a System State backup and restore it on a daily basis to the Replica DC. It's over complicated than backing your DC up with Veeam, shifted to DR/Remote Site and get it restored over there.

[Vitaliy S.]

Should I presume that my AD got corrupted during the replica process? I think I don't need to boot in non-authoritative mode, as I presume that my AD is not corrupted.

Your AD is not corrupted during replication process.

Can I just skip the AD recovery process and boot my replica normally?

To boot your DC in consistent and "working" state, these steps are required. Please look through this blog post for additional details:
http://www.veeam.com/blog/vss-and-vmwar ... g-you.html

[marius roma]

I hope that the question is not too much stupid...
Given a DC that is the only DC in its own forest (nothing to replicate with other DCs), what is supposed to happen if I replicate or backup it while it is powered off?
Should I expect it to start in safe mode or to start normally?
Mainly, should I expect to start AD recovery or just to start normally?
Regards
marius

[Vitaliy S.]

I believe replicating powered off DC won't require any extra recovery steps, so it should boot up normally (same situation as you would have just power off, and then power on the DC VM later).

[marius roma]

Many thanks to everybody.
I made a test performing a backup (I will try a replica as well, but I presume the results are the same) and the DC restored from the backup powered up without any problem.

My only trouble, now, is that it looks like backup and replica of powered off VM looks slooooooower that backup and replicas of powered on VM. Is it my feeling or is it the standard behavior?
If so, does it depend on the missing VSS support (in powered off VMs)? Is there any way to speed up the backup and the replica of powered off VM?

Let me ask another question: imagine I perform a replica of my VM every night.
The very first replica takes a lot of time (because I need to replicate the whole VM), further replicas are faster and faster (because I transfer only updates).
If I usually replicate my VM while it is powered on and one night I power my VM down before replicating it, should I expect the replica to be fast as usually or to take the same time as the very first (when the whole of the VM had been replicated)?
Regards
marius

[Vitaliy S.]

My only trouble, now, is that it looks like backup and replica of powered off VM looks slooooooower that backup and replicas of powered on VM. Is it my feeling or is it the standard behavior?
If so, does it depend on the missing VSS support (in powered off VMs)? Is there any way to speed up the backup and the replica of powered off VM?

VM power state doesn't matter for the backup/replication job performance, furthermore since "application aware image processing"cannot be used for the powered off VM, the job should complete a little bit faster, but virtual disk data processing/moving performance should be the same in both cases.

If I usually replicate my VM while it is powered on and one night I power my VM down before replicating it, should I expect the replica to be fast as usually or to take the same time as the very first (when the whole of the VM had been replicated)?

It should be the same as for powered on VM state given that CBT is enabled for this VM.

[kamalkant]

Not sure if this is the right page to post my issue. But the issue is quite similar. I have one replica job running . Target host is the same as my source host. i have only changes in my windows server and replica are:
1) replica does not connect to network after power on ( option disabled in Vmware VM edit setting)
2) the name of replica is server_replica.

Lets not talk about fail-over or any operation from Veeam server. when i start my replica I see the error " windows did not shutdown successfully blah blah...start in safe mode .. normally etc.."

Question is why my replica simply dont start?

[foggy]

when i start my replica I see the error " windows did not shutdown successfully blah blah...start in safe mode .. normally etc.."

Actually, this is expected behavior as from OS perspective, the VM did not shutdown normally as it was snapshotted from a running state.

[habibalby]

Do you get Microsoft Directory Restore Mode when it boots? If not, the VSS might be not configured correctly.

[Vitaliy S.]

1) replica does not connect to network after power on ( option disabled in Vmware VM edit setting)

Do you mean that the VM is not connected to any of your networks when you power it on?

[kamalkant]

so what i have understood form foggy that its an normal behavior, there is no way to avoid this? any method, settings can be made to avoid improper shutdown warning?
Thanks Vitaliy, yes it does not connect to any network.
Thanks Habibalby: It does not go to Microsoft Directory Restore Mode when it boots

[habibalby]

Does the back up works fine? "I mean you back this VM "DC" have you ever tried restoring it" ?
I would suggest to do a test backup of this VM then try to use Instant Recovery, change the network portrgoup and see whether you are going to the DS restore mode or not. Just make sure you are configuring the VSS correctly.

Thanks,

[jodiety11]

Thanks. It works for me..

[Vitaliy S.]

so what i have understood form foggy that its an normal behavior, there is no way to avoid this? any method, settings can be made to avoid improper shutdown warning?

I'm not aware of any Windows tweaks that can prevent this message from showing up.

Thanks Vitaliy, yes it does not connect to any network.

In this case, I would suggest contacting our technical team for further investigation.

Thanks Habibalby: It does not go to Microsoft Directory Restore Mode when it boots

Do you have "application-aware image processing" enabled for this VM?

[kamalkant]

Thanks Vitaliy... yes application aware image processing is enabled. ...
......................
it does not connect to any network because this is the way we want to start our replica. that's fine.
.........................................................

[habibalby]

What is the vNIC type, e1000, vmxNet?

[kamalkant]

its VMXNET2 ( Enhanced)

[yizhar]

My only trouble, now, is that it looks like backup and replica of powered off VM looks slooooooower that backup and replicas of powered on VM. Is it my feeling or is it the standard behavior?
If so, does it depend on the missing VSS support (in powered off VMs)? Is there any way to speed up the backup and the replica of powered off VM?

marius

Hi.

The sloooooooooooooower backup performance might be related to the DC (and other services such as DNS) being down.
This might have side effects.

You should look for replicating the DC while online.

I suggest that you try either with or without Application Aware processing,
and check the bottom line results.

Yizhar

[veremin]

I suggest that you try either with or without Application Aware processing, and check the bottom line results.

I wouldn’t recommend backing up/replicating domain controller with Application Aware Image Processing being disabled. The only thing that can be achieved by backing up VM running VSS-aware applications without this option is crash consistent backup, which means that data in the backup is in “crash-consistent” state, as it would be after a system failure or power outage. It, as you can imagine, might led to unfortunate results of further recovery process.

Recovery of Active Directory domain controller from non-VSS (AAIMP disabled) snapshot will be nothing but a headache task, unless you have specific knowledge and/or experience of thoughtful AD administration and manual recovery.

Hope this helps.
Thanks.

[kamalkant]

yes I agree ... i always select "application aware image processing"