Active Directory and DR Site

[joeymartin]

Hi folks,

I have 2 domain controllers backed up with Veeam 4.1.2 with VSS integration. What is the proper way to restore these in my completely separate DR location?

It's not just as simple as turning on the domain controllers after restore is it?

Joe

[Gostev]

Hi Joe, actually with Veeam, it is in fact as simple as turning on the restored VM (granted, you have made backup with Veeam VSS enabled). Our advanced application-aware processing logic will take care of proper restore.

Just make sure to restore both if you are restoring into a different site, as each DC, once restored will be looking for another to sync with, and if DC cannot connect to partner after some time, it will stop processing logons.

By the way, if you are using AD-integrated DNS, you can easily test this. Just restore both DCs and put them on different isolated VLAN before powering on.

[joeymartin]

I have confirmed my backups where made with VSS (set during backup job properties) I assume this is all that has to be done to "enable" it?

I have restored both DC's and am gettign numerous errors and eventually failure of AD. When my first DC boots after restore it goes to the Windows 2008 R2 login prompt...stays at applying settings for a while and then reboots and evetually comes up with CTRL-ALT-DELETE to login.

My other DC which is Windows 2003 boots into safe mode, does its thing and then reboots and looks like everything comes up as per normal. Communication is happening between the two but AD still seems to be broken. As a reslt Exchange can't see AD and down the line.

Anything I might be missing here?

Joe

[Gostev]

Sorry, long day for me... I totally missed the fact that both DCs are doing non-authoritative restore here, but there are no other DCs available. In this case, you should perform authoritative restore of first DC you are restoring. To do that, follow the procedure described here. After this is done, start second DC normally. This will work.

[joeymartin]

I thought this might be the issue based on the other posts here. Thanks for the reply...I am running Windows 2008 R2 as the main domain controller and it seems some commands in NTDSUTIL are different or missing. For example..."restore database" does not work. Anyone familiar with doing an authoritative restore on win 2k8 r2? In the meantime...I'm going to go dig into technet soem more.

Joe

[joeymartin]

OK, I've been trying to find a way to do an authoritative restore on full database on my Windows 2008 R2 Domain Controller with no luck so far. Will this scenario work?

Restore my other domain controller which is Windows 2003, perform an authoritative restore on this one. Then restore my Windows 2k8 Domain controller in non-authoritative mode and let it get its updates from the 2003 Domain controller. Some notes:

Win 2008 DC hold ALL FSMO roles but both are GC.

I realize this is not a Veeam issue as such but I think hashing this procedure out is important for Veeam customers looking to restore AD in a DR environment.

Thanks

Joe

[Gostev]

Hi Joe, yes based on my knowledge this should work just fine.

[tsightler]

I have a question, why do you need to preform an "authoritative restore" in this scenario? For a DR restore, assuming the complete loss of all domain controllers, you actually don't need to preform an authoritative restore of AD. Authoritative restores of AD is generally only required for cases where a domain is damaged in some way (for example a major schema change gone awry, etc) and you're wanting to restore an AD database and force all remaining AD controllers to accept your changes.

For a "complete loss of all domain controllers" scenario you can simply restore the first domain controller using a non-authoritative restore (which should happen automatically with a Veeam restore) and then you do need to preform an "authoritative SYSVOL" restore on the first domain controller that you bring up. For Windows 2008R2 Microsoft is really pushing people to use the wbadmin.exe tool (windows backup) for these types of operations, but you can still use the tried and true "BurFlags method".

The information available at http://technet.microsoft.com/en-us/libr ... 10%29.aspx is probably the best guide for 2008R2 AD recovery. The section on "Recovering Your Active Directory Forest" is invaluable and includes all of the information you need to perform a AD DR restore with Veeam. For example, when restoring a domain controller with Veeam the following information applies:

In some situations, you might choose to perform a full server recovery instead of restoring system state. It is not possible to perform an authoritative restore of SYSVOL during a full server recovery. If you perform a full server recovery, you might have to start the restored domain controller in normal mode and then restart it in DSRM before you can perform an authoritative restore of SYSVOL. If the restored domain controller is not restarted in normal mode after a full server recovery, the health report for SYSVOL may say "waiting for initial sync" and you cannot add more domain controllers to the domain.

[Gostev]

Well, I did similar test by restoring a single domain controller (of a few existing), and after restoring the DC in non-authoritative mode, it would work for some time, but then it would stop processing logons. I then found that this does not happen if I do authoritative restore, which is why I suggested this above.

I did not know abouth this other option of doing non-authoritative DC restore, followed by authoritative SYSVOL restore. Thanks for pointing that out.

[tsightler]

An authoritative restore should not be required if you are truly recovering your entire DC infrastructure. Think about it this way, what if, instead of backing up the servers, you had simply turned off all of the servers at that time. Would you need to preform an authoritative restore when you power all of your servers back on? Restoring the all of the systems from backup and powering them on is not significantly different than if they had been simply powered off since the backup was taken.

Now, if you're only restoring a single DC from a multi DC environment, you do need to pick your restored DC with some thought. For example, if you have two DC's, and one of them owns the schema, domain naming, or relative ID operations master roles, then you'd be best to restore the DC that owned these roles. If you restore the DC that did not own these FSMO roles, then you will need to seize these roles manually on the restored DC and you may stil have issue if you eventually restore the DC that originally owned these roles.

I suspect in your case the DC fired up and initially worked OK, but, because it was a "non-authoritative" restore, attempted to force a netlogon full resync and, when that failed, removed the netlogon share and quit servicing logins.

That being said, my experience is almost all with Windows 2003 and earlier. Windows 2008 has made some significant changes to the AD restore process, but conceptually I don't think much has changed. As far as I know preforming an "authoritative" restore in Windows 2008 can only be done at the object level. You perform a non-authoritative restore of the database, after which point you can authoritatively restore SYSVOL and, optionally, authoritatively restore the entire the entire domain subtree, but I'll admit I've only played with this in the lab a little bit.

[joeymartin]

Doing an authoritative restore on my Windows 2003 DC and the non authoritative on Windows 2008 r2 dc worked. I as well wondered why an AR was required as this was a completely new site. I suspect as Tom pointed out, that an authoritative SYSVOL restore would be all that is required. I'll test a little later and let you know the results.

Thanks for all your help everyone, great discussion....and great product.

Joe

[JailBreak]

Hi

Sorry i pick this threat to ask a question.

I have read all the messages, and if I understand if I need to restore both of my 2 DCs, i just need to restore in a normal way?? Do not need to perform any post restore tasks?

I understand this is the same of power off the 2 DCs, but in my case is a restore with 2 days old. Any problem with this? We did add any machines into the AD between this 2 days. So I think here we have no problem, but some users may have changed the password etc.

Do you think that restoring this 2 DCs with 2 days old, will be an issue?

Thank you

[tsightler]

If you are restoring 2 DC's, and that's all of the DC's you have, then of course you will loose any changes in the last 2 days, that's it. I would suggest restoring the "most recent" DC first, that's one of the most critical issues since otherwise you might restore one DC from 7PM, and another DC from 9PM. The "9PM" DC will not know how to handle the changes that occurred between 7PM and 9PM because it will have newer change sets that don't match.

On the other hand, if you restore the "9PM" DC first, then restore the "7PM" DC, the "9PM" DC will simply sync all of it's changes to the "7PM" DC and all is good.

Of course you still may have issues with machines domain membership since some machines may have updated their machine account passwords (and as you stated some users may have changed passwords), but this is usually pretty easy to remedy.

[JailBreak]

Hi

tsightler thank you for the reply. I have the same opinion. Just need to have a second opinon
And regarding restore the most recent, did no think about that, that's a very good point.

Once again, thank you for the reply.

Jail

[JailBreak]

Hi

Again joeymartin sorry to use your question. But since this is similar, it can help others.

OK i have restore the 2 DCs. Some minor errors, but nothing special. After the restore, jut need to wait about 10/15 for both work properly. Then restart 1st, then restart 2st. And all is ok.

Replication is working.
DNS is working(internal and external domain).
And also fileserver with the permissions and users etc(other VM) is working without any problem with permissions, access etc.

Thank you tsightler for the help

Jail

[Gostev]

Veeam and Tom are here to rescue any Active Directory deployment

[Moebius]

Reviving an old thread here but with some variations.

I am setting up a test lab with some restored VMs and this will have to go on for months. Of the 8 DCs of the production environment I initially did a non-authoritative restore of just one (with all the principal roles on); as Gostev said it ran for some time and then stopped servicing logons because it couldn't sync with any other source.
I ended up deleting the restored DC and doing another non-authoritative restore of TWO (both with the principal roles). It seems to be running fine for now. Should I expect problems in this case? Should I remove the other DCs from the restored AD?
All DCs are Win2008 R2.

[foggy]

Lucio, please review this post for the answers. Thanks.

[Moebius]

Alexander, thank you. The post you reference is highly informative. It's a shame such pieces of knowledge have to stay buried deep in thousands of forum pages. A KB would be highly welcome.

So, I was totally missing the fact that the Surebackup does an authoritative restore of the DC in the application group while the normal restores (both instant and full) do a non-authoritative restore (if I'm getting this right).

So, to quickly perform an authoritative restore of a DC, it would be possible to start a Surebackup job with the DC as the only VM in the application group, leave the app group powered on, and then storage-motion the vm into its test environment?

[foggy]

So, I was totally missing the fact that the Surebackup does an authoritative restore of the DC in the application group while the normal restores (both instant and full) do a non-authoritative restore (if I'm getting this right).

Yes, you're getting it right.

So, to quickly perform an authoritative restore of a DC, it would be possible to start a Surebackup job with the DC as the only VM in the application group, leave the app group powered on, and then storage-motion the vm into its test environment?

Yes, this should be possible.

[foggy]

However, there's a chance that the migrated VM will be removed on Surebackup job completion, so probably performing authoritative restore manually would be a safer option.