Restoring a domain controller
-
As a DR test, I restore a backup of our PDC into our lab network, using Veeam 6.5.
It initially boots to a recovery menu and after a few seconds automatically boots with "start Windows normally". It then says "Applying computer settings". After a few minutes it then reboots. After the second boot it brings up a logon screen and I can logon. This is what I expected to happen according to Veeam documentation.
When I first go into Active Directory Users & Computers, everything looks fine.
However, when I try and go in after a few minutes, I get an error "Naming information cannot be located because: The specified domain either does not exist or could not be contacted."
I followed a KB from Microsoft that involved setting BurFlags to D4 in the registry and restarting the File Replication server and this allows me to open Active Directory Users & Computers ok. However, the NETLOGON share has disappeared.
When I did this a few weeks ago, after doing the BurFlags thing, I was able to add a new PC to the domain, so I was reasonably confident that I could recover AD (although not happy about it as I shouldn't have to do any of this, it should just restore). Now, I don't seem to be able to add a new PC. So I'm not confident I can recover at all.
I've got someone coming in on Monday to look at it. But they've been in before and haven't found anything wrong.
I ran dcdiag without any parameters and it passed everything except replication (understandable as I haven't restored the BDC) and RidManager where it says "the DS has corrupt data". When I open DNS Manager, it hangs.
Any suggestion on where to start looking at fixing this? I think I've setup my Veeam backup and recovery jobs correctly.
-
I'm on 7 and remember getting that before. When running a restored DC in my virtual lab, I need to set the recovery checks to include the DC scripts. It took some head banging to figure that out. I think they are similar in 6.5. So when you do something like SureBackup to Lab, either in the Application Group or the backup file, you need to set the Verification options to let Veeam know it is a DC here:
-
Also, don't bring up multiple DCs in the same test lab at the same time. Apparently there will be a death cage fight and no one wins in that lab.
-
I'm not using SureBackup, I'm physically restoring our backup on a separate physical host running on a different network. So there are no verification options.
-
@Carnival-Boy said:
I'm not using SureBackup, I'm physically restoring our backup on a separate physical host running on a different network. So there are no verification options.
Sorry about that. I just assumed since you referenced a lab environment in the OP. It's weird. I have a separate physical host and always restore for testing in the isolated Veeam Test Lab using SureBackup. Anyway, and I'm sure you've seen this thread, but if you didn't (and yes I know it is for an older version, but I do know that Veeam uses the same restore method in 6/7), I'll link it just in case: http://forums.veeam.com/veeam-backup-replication-f2/veeam-b-r-v5-recovery-of-a-domain-controller-t7000.html
-
Or perhaps check out http://support.microsoft.com/kb/947022/en-us referenced in http://www.experts-exchange.com/Software/Server_Software/Active_Directory/Q_28188083.html. But I think you probably should run it by Veeam though.
-
Yeah, I read that, but it doesn't help. I think it's a problem with AD rather than anything that Veeam is doing wrong.
-
I was thinking that. Have you tried a different restore point? Anyway good luck. The SureBackup Labs are an awesome resource, especially for lab testing. I spin things up including SQL and Exchange to test stuff before rolling out to production. Worth it's weight in gold. I also use them to test every backup. Have you tried to use replication instead of restore to the other host that you are using?
-
I haven't. I imagine replication would work fine, but it doesn't solve my problem.
-
@Carnival-Boy
Maybe not your current issue, but from what I read, you need a functional DC in a test lab that is isolated from your production network, yes? A replica on a different vswitch might fit the bill. Just trying to think outside of the proverbial box. -
No, all I want to do is test that in a disaster I will be able to restore my domain from a backup. At the moment, I can't do that - which is freaking me out.
-
Test DNS. Is it working properly? Can the problematic DC resolve itself and does it look to itself?
-
@scottalanmiller said:
Test DNS. Is it working properly? Can the problematic DC resolve itself and does it look to itself?
When I first read this thread, I was thinking this same question - but further conversation drove me away from it. Yet here it is any how
-
@Carnival-Boy said:
No, all I want to do is test that in a disaster I will be able to restore my domain from a backup. At the moment, I can't do that - which is freaking me out.
That would. It seems that most people tend to associate this issue with DNS failures.
-
My guy isn't coming until the end of month now. So I'm hoping ML can solve it!
DNS sounds like a good place to start. How exactly should I test it?
I ran nslookup on the restored DC and it lists itself as the server. I ran nslookup server_ip_address and it displays its name, and nslookup server_name and it displays its IP address.
I ran dcdiag /test:DNS on the live server, and it fails with TEST: Basic (Basc) Warning: no DNS RPC connectivitiy (error or non Microsoft DNS server is running)
I mentioned earlier that when I opened DNS manager on the restored DC it hangs. I think is because it is looking for our second DNS server on our other DC. After a while it says it can't find it (which it won't because I haven't restored that DC) and loads DNS manager normally.
Please hold my hand here....
-
When I run nslookup from a command prompt, it works ok (displays the default server and address).
However, when I run nslookup from within DNS manager (right click on the server and select "Launch nslookup" it says:
Default Server: UnKnown
Address: fe80::704f::3fe7:6795:d3c7That address is an IPV6 address, right?
Also, in DNS manager, there are NS entries for our old DC, which is no longer part of the domain, and also an NS entry for our file server which used run DNS but doesn't any more. Should I delete this entries. Do they make a difference?
-
Once DNS Manager loads, have you manually switched it to look at your restored DC instead of the other one?
Also, did you look at your manually configured DNS settings (control panel > network and Sharing Center > Change adapter settings (on the left), etc, etc... ) and made sure that the DC is pointing to itself as the first and only DNS server? By default that would not be the case. this server should be pointing to your other DNS, and the other to this one...this allows you to reboot more quickly as they will use DNS from the other (hopefully) online DNS server. But in the case of your restore, this would not be the case, and you'd need to manually change it.
-
I have removed the other DNS server from the network adapter. But it shouldn't be necessary should it? Isn't one of the features of having two DNS servers listed that if one is not contactable the other will be used?
I'm not sure what you mean by manually switching to look at the restored DC. On the live DC, DNS manager only lists the DC on the left hand side. However, on the restored DC, DNS manager lists the IP address of the other DNS server and the DC. The other DNS server is listed with a red cross against it. I have removed it, but AD is still not working.
I don't think I should have to do anything to DNS after recovery, should I? So long as one DNS server is up, it should just work? I think the problems are on the live servers, and not a problem with the restore workflow or with Veeam.
-
@Carnival-Boy said:
I have removed the other DNS server from the network adapter. But it shouldn't be necessary should it? Isn't one of the features of having two DNS servers listed that if one is not contactable the other will be used?
Yep it should, but that isn't always the case - at least in my experience. I've had windows clients that took 20+ mins to log into the domain because they had two DNS entries and the first one was offline. Once I changed the DNS order, the problem went away. (different time, but similar problem if the Primary DNS entry on the only remaining DC wasn't pointing to itself (either it's own IP or 127.0.0.1).
@Carnival-Boy said:
I'm not sure what you mean by manually switching to look at the restored DC. On the live DC, DNS manager only lists the DC on the left hand side.
Which DC is it listing? To help our understanding let's use some names: DC-01 and DC-02, assuming you only have two DCs. We'll also assume that you're restoring DC-01.
When you launch DNS Manger on DC-01, which server shows up there? FYI, it could be either DC-01 or DC-02. You can change it to look at the other by right clicking on DNS at the top, then choose connect to DNS server.
If for example, before the backup was taken of DC-01, you opened DNS Manager and pointed DNS Manager at DC-02, then took a backup and did a restore - the restored server should be trying to open DNS Manger pointing to DC-02, which in your case will fail because it's not part of your temp network. This is why I suggest that after DNS Manger is open on the restored DC-01, that you make sure it's pointed to itself - then close it, and reopen it. It should open faster this time. If not, you have other DNS issues (probably the one noted above).
-
What are the chances that DC-01 does not have all the FSMO roles? You're restoring into a vacuum and might be missing other critical roles on other servers.
