Restoring a domain controller
-
CB - if you can afford the downtime, take DC-01 offline and make an image of it using something like Clonezilla. Then restore that image into your test environment and see if you have the same issues.
-
I can shut the server down, back it up, and then restore it, and it works just fine. It's just backing it up whilst online that causes the problem.
-
Have you opened a case with Veeam? Since a cold image works it definitely sounds like an issue with the way Veeam is backing things up.
-
I'm not sure about that. If I shut it down, services are shut down cleanly. If I backup live, it needs to boot into AD services non-authoritative restore mode. My understanding is that this is a Windows process and not really anything to do with Veeam.
I'd rather hold off calling Veeam until I've explored a few more avenues. I could test it with another backup product like Unitrends, I suppose. That could eliminate Veeam being the cause.
-
Some success:
I restored the PDC and let it boot twice and do it's non-authoritive restore thingy. As I mentioned in the OP, AD initially looks ok but after a few minutes it fails and I can't open AD users & computers.
I then restored the second DC. This DC doesn't have any primary roles.
After restoring the second DC, everything appears to be working. I can open AD users & computers on both DCs and I can add a PC to the domain.
I shouldn't have to restore the second DC, should I? The PDC should fix itself if it can't find it, shouldn't it?
So what do you think might be going on?
-
Correct, restoring a secondary DC is not recommended. Once a main DC is up and working, subsequent DCs should be built fresh rather than restored to avoid database issues.
-
are you sure of the locations of all of the roles including the Global Catalog?
-
I'm not sure of anything! Will check and report back.....
-
netdom /query FSMO shows that all roles are on the PDC.
AD Sites & Services shows that both DCs are Global Catalogs.
Anything else I should check?
-
When the restored DC is failing, what does Active Directory Best Practices Analyzer tell you is going on?
-
On both the live and restored DC, BPA is only giving one error - "The PDC emulator operations master in this forest is not configured to correctly synchronize time from a valid time source"
Could time be an issue?
Other than that, there are two other warnings on both the live and restored DC - "All OUs in this domain should be protected from accidental deletion" and "The DC should comply with the recommended best practices guidelines because it is running on a VM"
I also get a few warnings on the restored DC relating to the fact that AD hasn't been backed within the last 8 days, which I assume is because I'm restoring an old backup, and can be safely ignored.
-
Whoops. I ran BPA too soon and didn't give AD time to properly fail. Ran it again and get a load of errors beginning with "BPA is not able to collect data about...". The first one being "BPA is not able to collect data about.the name of the forest from the domain controller DC-01." and so on and so on.
I guess it can't analyze AD if AD isn't working.
-
This is just odd.
I'm currently out of ideas. I'd say open a case with Veeam and/or Microsoft (yeah it will cost ya).
-
@Carnival-Boy said:
I can shut the server down, back it up, and then restore it, and it works just fine. It's just backing it up whilst online that causes the problem.
That's just how databases work. They can't be backed up live reliably. They need to be taken offline to get a reliable backup typically.
-
@Dashrender said:
Have you opened a case with Veeam? Since a cold image works it definitely sounds like an issue with the way Veeam is backing things up.
Veeam doesn't handle the snapshot, that is the hypervisor. Veeam backs up what it is given.
-
Not sure that I saw what the hypervisor is here. Is it Vmware or HyperV?
If VMware, are the VMTools definitely installed?
-
@Carnival-Boy said:
On both the live and restored DC, BPA is only giving one error - "The PDC emulator operations master in this forest is not configured to correctly synchronize time from a valid time source"
Could time be an issue?
Yes, if the time is off, DCs cannot sync.
-
@Carnival-Boy said:
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?
Yes that is IPv6
Sounds like DNS is misconfigured and can't do a lookup on its own.
-
@Carnival-Boy said:
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?
I completely missed this post. As Scott pointed out, it does look like DNS is what's not working - this probably explains why when you restore the other DC things work as you desire because DC-1 is relying on DC-2 to make DNS work correctly (though that wouldn't explain why an offline backup that's restored works - so that's still odd).
What happens if you skip the non authoritative restore after restoring the backup?
-
On either server, if I type** nslookup DC-01 DC-01** I get
DNS request time out
Server: UnKnown
Address: fe80::704f:3fe7:6795:d3c7
Name: DC-01
Address: 10.1.2.13whereas if I type nslookup DC-01 10.1.2.13 I get
Server: DC-01
Address: 10.1.2.3
Name: DC-01
Address: 10.1.2.13So it seems it can resolve when specifying the IPv4 address of the DNS server, but otherwise it thinks the DNS Server is at an IPv6 that it can't find?
That address is the IPv6 address of DC-01 and it resolves if I type** ping DC-01**.
In otherwords, is this an IPv6 issue?
