Restoring all domain controllers in a Windows domain (on vmware)

Recently I restored a single AD on my homelab without any problems.

However, it was not a production environment like yours.

Take a look on this article:

https://www.veeam.com/blog/active-directory-domain-controller-backup-recovery.html

I had to do it once; after a ransomware hit.

we restored the backup of the primary dc, it was only 12 hours before (old) backup, but we faced some issues in trust and Kerberos authentication, but just making the gpupdate / force in most pcs with the problem it was fine, just one of them (they were 200 clients) needed to be kicked out of the domain and adopted back in.

after restoration ok, we deployed a new secondary domain controller, not restoring the backup, to avoid authoritative or sync issues.

hopefully helps you.

cheers.

I did this recently mid day in a HUGE environment after someone blew it up. 100’s of VM’s and file servers were not accessible and critical infrastructure was all down.(stressful)

1. YES make hosts files. Have EVERY Veeam server or other server you will need in it, Proxies, storage, Veeam server, SQL server, ESXI host, vCenter, file shares etc. I now have an updated copy in multiple spots if it happens again. Also keep a list of all your Veeam IP’s on hand so if you ever lose DNS.
2. Consider separating your DC’s and DNS servers. They don’t need to stay together. this makes life much easier going forward.  (Still keep a host file available if you need it)
3. Call Veeam support for help if you need. 

4. The easiest way for me would be to power down ALL of the DC’s and restore the master as authoritative. I’d then restore the other/rest and let them sync. Having the roles on on DC going forward lets you know that that is your master and you should always use it for restores. 
5. There is a procedure for this, Call Veeam and see what they say if your app aware processing doesn’t work.  You will be ok, but i don’t know if the procedure changes. 

Those articles look great for restoring a single object - but I might have to restore the entire AD database (for reasons too deep to go into here).  I wonder if I just restore the entire vm image?

Also, I have another potential problem: one of the 3 DCs did not have application aware processing turned on so it does not even show up in the restore wizard - turning that on tonight!  I think there was initially problems with that DC and somehow then it never got fixed or at least turned on.

Albert

If the main DCs have application aware on restoring the VM would be ideal and then you will need to check AD with the tools required within windows.

hopefully Veeam support is faster than the usual response - but maybe if this is severity 1 I will get someone right away - going to try this on a long weekend starting Friday

-so in short, I power down all 3 DCs, restore the one which I think has the best data, issue a command at the command line or a registry setting to make this the authoratative server, then restore the other 2 servers right?

Scott wrote:

3. Call Veeeam support for help if you need
4. The easiest way for me would be to power down ALL of the DC’s and restore the master as authoritative. I’d then restore the other/rest and let them sync.

Yeah, I shudder at the thought of restoring all DC’s.  I’d honestly consider shutting down all of the DC’s, restoring one authoratively, and then cleaning up AD and building new DC’s for any remote systems.  Building a DC is practically throw-away anymore, especially since you don’t have to do metadata cleanups anymore.

Sorry for the super-long delay; after successfully doing the work on the server, I left a few days later for two weeks holidays (not that I like to do that - I would rather be around for a bit but they were booked and everything seemed okay!).  In short, was able to clean up AD for the “bad DC” instead of having to restore from Veeam.  Even though the below is not a “veaam” solution, thought a post-op summary would be informative to anyone reading this thread - and I still had a few questions re what happened - more for my info than anything.  I also still have some specific questions re being better prepared in case next time I have to restore from Veeam.  But for now, here is a log of what I did to do the cleanup.

>>>>>>>>>>>>>>>>>>>>>>>>>»

Reminder: we had one bad DC in our environment that we could not log into in any way so we could not demote it gracefully.  This happened about 3 weeks ago and we were starting to experience replication problems (changes not being replicated between DCs) so we really needed to get it fixed. 

Steps taken:

-shut down the bad DC; before this fix, doing so would cause a significant problem on one of our servers that was using LDAP to this server for authentication (could not get around this) even though this server was *hardcoded* to use LDAP on another DC (not the “bad” DC) (could not even get support for this product to figure out why LDAP not pointing to the correct server).

-go into ADUC (on the other DC at the same site) and delete the bad DC from the Domain Controllers OU

-go into DNS and see if bad DC was removed from DNS; result: only one instance was removed correctly (at the root) but all lower instances of it in all kinds of nodes were not removed; manually go through the forward and reverse trees and manually deleted all references to the bad DC; note that some might think this is extreme but we were going to permanently get rid of this DC anyhow (when we build back another DC, it will have a different name)

-go into Sites and Services (SaS) and remove the bad DC from the pertinent site; remove any connection objects between the bad DC and other DCs

-at this point I stopped and fired up the server that would always “choke” because it was looking for LDAP services from the bad DC; this time though, it worked fine without it - it reverted back to getting LDAP from the other DC at that site

-went into SaS again and fired the replication connections between the remaining DCs; at first I got an error message (sorry, did not record) but that eventually went away - not sure if somehow replication of the connection object finally happened enough to allow full replication to happen and I just needed to wait, or did all my poking about finally get it going.  I really did not know if I had to somehow fix things up for the sites or not - but finally it worked (if anyone has any insight into that, I would not mind knowing).

-at this point, replication seemed to be working correctly - tested by issuing repadmin /replsummary and dcdiag etc.

-all servers stopped having errors and nslookups and all tests seemed okay; newly created objects on the one DC finally showed up on the other DCs (and obviously changes as well);

-one interesting item was that just before the fix took place last week, a few users including myself, had our mapped network drives disappear to one of our servers and we could not re-create them at all; so somehow some trust relationship or something was starting to break down such that our mapped drives stopped working (if anyone has insight on this as well, would like to hear)

I still have a few dcdiag warnings to look at this morning - but when reading a bit on each, none seemed serious (more warnings for best practices etc.); I might post those as another post if they are related to this situation.

>>>>>>>>>>>>>>>>>>>>>

Thanks a lot everyone for the help.  I learned a lot more about what I might have needed to do for a Veeam restore of all DCs - glad I did not have to do it.  I also feel like I need to summarize some of the thread items here to have handy in case we need it.  Hopefully I can get to that before this gets too stale in my mind.

Albert (for McKITGuys)

In a smaller environment (35 workstations), with not a lot of new activity, what causes a trust relationship to get lost - are they renewed every few days or something?  Or would the only ones lost be those of any new PCs added to the domain?

More questions from excellent discussion above:

-netdom resetpwd - so I have a server or user PC that has lost its trust relationship: am I going to be able to log into that server to perform this command?  and if I do, say my server is named DC1 and my domain admin account is SkinnyAdmin, would the command be:

netdom resetpwd /s:DC1 /ud:mydomain.com\SkinnyAdmin /pd:bigFatPassword

-so I assume this from what I have read, since this is a machine password, gets a new generated password from the DC and updates that locally and also in that computer’s object in AD? just checking

-and I assume that this resets the trust relationship at the same time

DSRM password: I have taken over admin of a client’s  network: although I have the administrator passwords, I have not found any DSRM passwords recorded anywhere; I can guess by a list of commonly used passwords but cannot be sure; is that going to prevent a Veeam restore or does it just use the domain admin passwords stored in its credentials setup?  I know someone pasted a link to resetting the DSRM pwd but I would assume that only applies going forward, not going backwards when I do not have access to it.

Really nice topic which mix Veeam and AD knowledge. By luck I never had to restore all DCs of the infrastructure. But I ll keep all this precious advices in a corner. 

I have thought of that too - just restoring one DC, cleaning it up and then building others from that.  The DC with most likely the latest changes on it (password changes, trust relationships) though does not hold the FSMO roles.  So if I started with this, I would have to seize all the FSMO roles.

If I start with the server with the FSMO roles, it is at their head office but because most of their users log into VDI desktops at their data center, most likely there will be more broken trust relationships.

Anyhow, hopefully it does not come to this.  Here is my plan (for what it’s worth); I started this thread to get an understanding about recovering via Veeam backups but I am actually just going to try to get AD working again across sites.  As a reminder, the problem is there was a new DC being built that has become corrupted (not accessible) and the computer object in AD looks “messed up”.  No way to get into the DC to demote it and clean up.  But it is running and if I down it, one of our servers stops working.  I won’t go into more details but suffice to say, I need to get that DC out of the domain, clean up AD and then promote a new one.  So here is my plan that if all goes well, there will be no restore from backup:

• down the problem DC
• delete all the references to it in AD manually
• AD synching seems to be somewhat stopped - repadmin says the DCs can connect but replication stopped due to errors
• issue commands to “force” replication between the good DCs
• hopefully all is well

Question: having said the above, if I just do the above, will the bad DC object just come back from one of the other DCs?  Do I need to delete it on all DCs manually before forcing the replication?  or should I maybe down all DCs except one, make the deletion, set that DC as authoratative (via the registry setting I have read about), reboot that DC (I assume I need a reboot for the setting to take affect) and then bring up the other 2 DCs and force a replicate?  comments?