Restored DC fails to start AD

[tfloor]

Hello,

I'm testing a virtual lab.
I have add our 2 domaincontrollers (2003/2008r2) to an application group and start the job.

When everything is started up. (without dc test-scripts)
I try to start "Active directory users and computers" and get the following error:
Naming information cannot be located because:
The specified domain either does not exist or could not be contacted.

Is that normal? That you have todo something before domaincontrollers are starting correctly after restore of a veeam snapshot?
Those are the only DC's i have and they also do DNS, so i thought everything that is required to run is in the application group.

Any idea's?

Regards,

Tristan.

[Gostev]

Hi, definitely not normal. Something may not be setup right, this needs closer investigation by our support. Thanks!

[tfloor]

That's a short answer , (this one also)

[Cokovic]

Hey Tristan,

why didn't you choose the DC Test scripts? That will ensure that Active Directory is running. Did you ever tried it with the test scripts? Maybe you should give it a try. Please check Domain Controller, Global Catalog and DNS roles in your application group for these VMs (i know it will extend the boot time) and try it again.

[tsightler]

The fact that he has "no test script" might be the issue. When you say this, do you mean that you have not selected the "Domain Controller" role for these VMs when configuring the application group? If not, then when the lab is run we will not perform the "Configuring DC" portion of the lab startup. This portion contains the "magic" that makes domain controllers actually boot up in a reasonable time in an isolated environment. Without this step it can take 45-60 minutes for domain controllers to actually become operational.

[tfloor]

Hi,

I had removed those test scripts (indeed the roles) because my job was failing at that moment and the vm's were shutdown, so i couldn't do some testing.
But i will select the roles again, and put both dc's on. I will post the results here.

[tfloor]

Damn, that's working.

What's that "magic" inside that, i thought it was for testing only.... but it looks like it is doing more ....

[Gostev]

Actually, not using test script is totally fine (which is why this fact did not catch my attention). However, the DC role MUST be assigned, so that SureBackup engine knows it deals with DC and reconfigures it appropriately to work correctly in the isolated environment.

[tsightler]

Yep, script itself is not really important, however, when you check/uncheck the "Role" a test script is added/removed automatically so many users associate the two together, which was my suspicion in this case. You can always select the "Role" and then manually remove the test script.

[tfloor]

Ah that explains.
Very good to know that I can remove the script but use the role checkbox

Thanks for the fast solution.

[NightBird]

Actually, not using test script is totally fine (which is why this fact did not catch my attention). However, the DC role MUST be assigned, so that SureBackup engine knows it deals with DC and reconfigures it appropriately to work correctly in the isolated environment.

How does it work ? I have a virtual lab and SureBackup Job for a remote site (100Mbits/s line) and the Surebackup job stuck to Configuring DC for a while !!!

Veeam server at the main site, and Veeam proxy/repo at the remote site.
I think that the Veeam server on the main site must open the .vmdk file of the remote DC to make the "Configure DC" ?

Thx
Boris

[Vitaliy S.]

Yes, you're right. Veeam backup console opens/mounts .vmdk file to edit the registry settings, but the traffic consumed by this process is minimal, so your 100 Mbit line is more than enough for this kind of operation.

The reason why it takes so long to Configure DC should be clearly seen in the SB log files, so please contact our support team for logs review assistance.

[NightBird]

For information, about 40mn to Configure DC, I see VeeamAgent.exe process with a maximal network Throughtput between 300ko/s - 1Mo/s really slow !!!
I will open a support case

[Aremac]

I've started having an issue identical to this. The surebackup job includes the role and the script and passes however when I try to load ADUC I get the message reported at the beginning of this thread. Any suggestions for troubleshooting this?

Thanks

[veremin]

Hi, Sam.

Do you have Application Aware Image Processing option enabled in the job settings? What if you try to test DC restoration, using Instant VM Recovery, will you get the experience a similar issue?

Anyway, if you can confirm that the corresponding Application Group is configured properly, i.e. the required roles are assigned, the scripts are selected, you might want to open a ticket with our support team and let them investigate it directly.

Thanks.

[Aremac]

Thank you,

I do have Application Aware Image Processing enabled. I haven't tried Instant VM recovery but it there much difference in restore process from a surebackup boot and instant VM recovery (other than vmotion to production datastore?) I did see that the sysvol and netlogon shares are not present. A previous post on a similar matter suggested the following:

Command line: net stop ntfrs
Regedit: hklm\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore\Process at Startup - Set the burflags to d4
Command line: net start ntfrs

I performed this and the shares were restored and I was able to bring up ADUC. But this isn't normal operation and I haven't tested further to see if it had larger impact. As this used to work properly I am wondering if a group policy or other change that may have been pushed down may be causing this. However, I'm not aware of what change could/would impact Veeam DC restore process.

Thanks.

[tsightler]

The Surebackup process should be adding the burflags settings automatically. In the GUI if you open that Surebackup status and click the DC VM, in the logs, there should be a step labeled "Configuring DC" between the "Registering" and "Powering on" step. Do you see this step and does it show as completing successfully?

[Aremac]

The "Configuring DC" entry is completing successfully. Is it possible to get a list of settings that change during this step so I can verify they are actually being made.

[tsightler]

You can find them in the job logs. Probably a good idea to open a support case as well.

[Aremac]

So I checked the logs and every entry that references a registry key change has a number injectec in the key string such as:

+[HKEY_LOCAL_MACHINE\System6321f50d17f348f5bd888b26802584e2\ControlSet001\.......

Is this normal? If not any ideas?

[Aremac]

Also, Checking the VM from a surebackup job the registry changes are not being made (the keys from above don't exist)

[veremin]

Kindly please open a support ticket, since the team behind this forum cannot assist you effectively with technical issues requiring debug logs investigation. Thanks.

[wbauer84]

Executing these steps in registry and rebooting the DC removed me the AD problem as described by the poster on Windows Server 2012 R2:
https://support.microsoft.com/en-us/kb/947022/en-us

By the way: We use Veeam 8.0 and replicate our domain controller to a remote site. Is there also an option of DC processing, like discussed in this thread?

[foggy]

If you enable application-aware image processing on the replication job, everything should be fine. The discussed option relates to backups recoverability with SureBackup.